A dynamic adaptive QKD network comprehensive test method

Abstract

This invention discloses a dynamic adaptive QKD network comprehensive testing method, belonging to the field of quantum communication network testing technology. The method establishes a test architecture including dynamic control, hardware testing, software simulation, attack scenario replication, and data acquisition and analysis modules. It collects the network state parameters under test to complete initial configuration, sets and dynamically updates test baseline thresholds, matches test scenarios to the network state and generates test cases, determines differentiated testing strategies, executes full-process collaborative testing, processes test data to locate performance bottlenecks, and outputs test reports and optimization solutions. This method is adaptable to QKD networks of different sizes and networking modes, balancing test accuracy and cost, enabling dynamic adjustment of the test process and accurate identification of performance bottlenecks, providing support for network operation and optimization.

Description

Technical Field

[0001] This invention relates to the field of quantum communication network testing technology, and in particular to a dynamic adaptive QKD network comprehensive testing method. Background Technology

[0002] Quantum key distribution (QKD) technology relies on the physical properties of quantum states to achieve secure key distribution. It has been applied in communication systems across several key industries, becoming a crucial component of communication security systems. With the continuous advancement of engineering applications, the scale of QKD network construction is gradually expanding, and network topologies are becoming increasingly diversified. Trusted relay and relay-free networking modes are widely deployed in various scenarios. The number of nodes and links in the network continues to grow, and dynamic adjustments to the network topology have become common operations in daily maintenance. Simultaneously, testing and verification of QKD networks are also developing, with related testing methods and tools constantly being improved to support network deployment and acceptance, daily maintenance, performance optimization, and other tasks. The testing coverage and indicators are also gradually expanding.

[0003] Current QKD network testing methods are mostly designed for fixed network configurations and static network topologies, making it difficult to adapt to network operating scenarios with dynamically adjusted node sizes and continuously fluctuating link states. The matching degree between the testing process and the actual network operating state is insufficient. Most testing solutions use fixed test procedures and test cases, failing to flexibly adjust test configurations according to different network sizes and configurations, making it difficult to comprehensively and accurately evaluate network performance. In large-scale network testing scenarios, full hardware testing is costly and time-consuming, while pure software simulation results are difficult to guarantee reliability. Existing technologies lack effective means to balance testing costs and accuracy, and also lack dynamic testing mechanisms linked to network states, making it impossible to synchronously adjust test benchmarks and strategies according to network state changes. This hinders the accurate identification and targeted optimization of network performance bottlenecks. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of the prior art and provide a dynamic adaptive QKD network comprehensive testing method.

[0005] The objective of this invention is achieved through the following technical solution: A dynamic adaptive QKD network synthesis and testing method is provided, which includes the following steps: S1. Build a dynamic adaptive QKD network testing architecture. The dynamic adaptive QKD network testing architecture includes a dynamic control module, a hardware testing module, a software simulation module, an attack scenario replication module, and a data acquisition and analysis module. The dynamic control module is used to sense the network status and adjust the test parameters, the hardware testing module is used to perform actual test verification, the software simulation module is used to simulate the network operating status, the attack scenario replication module is used to simulate attack scenarios, and the data acquisition and analysis module is used to process test data. S2. Collect the state parameters of the QKD network under test, complete the initial configuration of the dynamic adaptive QKD network test architecture, set the test baseline threshold, and establish the dynamic update rules for the test baseline threshold; S3. Based on the collected state parameters of the QKD network under test, match the corresponding test scenario, generate suitable test cases, and determine differentiated test strategies; S4. Perform collaborative testing throughout the entire process according to test cases and differentiated testing strategies, collect indicator data during the testing process, process the indicator data, locate performance bottlenecks, and output test reports and optimization solutions.

[0006] Furthermore, in step S1, a dynamic control module, a hardware testing module, a software simulation module, an attack scenario replication module, and a data acquisition and analysis module are set up. The dynamic control module is used to sense changes in network topology and link operation status, adjust test parameters, generate test cases, control the test process, and update test benchmark thresholds. The hardware testing module is used to perform test verification on the key generation and key negotiation stages, adapting to trusted relay networking mode and relayless networking mode. The software simulation module is used to simulate the QKD network operation status under different node scales and different link bit error rates, simulating extreme link environments. The attack scenario replication module is used to simulate various network attack scenarios and adjust the attack intensity level. The data acquisition and analysis module is used to collect test indicator data, perform data noise reduction and data standardization processing, locate performance bottlenecks, and issue early warning prompts for potential risks.

[0007] Furthermore, step S2 includes the following sub-steps: S2.1. Establish a communication connection with the QKD network under test through a classical channel, and collect the status parameters of the QKD network under test. The status parameters include node size, number of links, key generation baseline rate, initial value of link bit error rate, and network mode. S2.2. Based on the collected status parameters, adjust the operating parameters of each module in the dynamic adaptive QKD network test architecture. The adjustment includes the number of node terminals in the hardware test module and the simulation parameters in the software simulation module, and complete the initial configuration of the dynamic adaptive QKD network test architecture. S2.3. Set multiple test benchmark thresholds, including security thresholds, efficiency thresholds, and stability thresholds; set dynamic update trigger conditions for the test benchmark thresholds, and automatically update the test benchmark thresholds when the QKD network under test meets the trigger conditions.

[0008] Furthermore, step S3 includes the following sub-steps: S3.1. Based on the collected node scale parameters, classify the test scenario types; S3.2. Match the test case set corresponding to the test scenario type, generate test cases adapted to the current QKD network under test, and the test cases cover all test items of the corresponding test scenario; determine the differentiated test strategy according to the test scenario type. The differentiated test strategy includes the configuration rules for the proportion of hardware actual test and software simulation, as well as the configuration rules for test redundancy.

[0009] Furthermore, step S4 includes the following sub-steps: S4.1. According to the test cases and differentiated testing strategies, execute the key generation performance test, key negotiation efficiency test, topology adaptability test and security protection test in sequence; the security protection test simulates the attack scenario through the attack scenario replication module; collect various indicator data in the test process, monitor the running status of the QKD network under test in real time, and adjust the test parameters in a synchronous manner. S4.2. Perform noise reduction and standardization processing on the collected index data, compare the processed index data with the test benchmark threshold, mark the qualified and unqualified indicators, and calculate the deviation between the unqualified indicators and the test benchmark threshold. S4.3. Establish a correlation model between indicator data and network performance through correlation analysis algorithms to identify bottleneck types and locate the corresponding nodes or links; S4.4. Generate a standardized test report that includes test parameters, test data, bottleneck location results, and optimization suggestions.

[0010] Furthermore, in step S2, the dynamic update triggering conditions for the test baseline threshold include the topology change reaching a set value and the link bit error rate fluctuation reaching a set value; when the QKD network under test meets any one of the triggering conditions, the test baseline threshold is automatically updated; the updated test baseline threshold is adapted to the changed operating state of the QKD network under test.

[0011] Furthermore, in step S3, the differentiated testing strategy configures the usage ratio of the hardware testing module and the software simulation module according to the test scenario type; the first type of test scenario corresponds to the QKD network under test with the node size in the first set range, and the corresponding test mainly uses the operation of the hardware testing module and is supplemented by the operation of the software simulation module; the second type of test scenario corresponds to the QKD network under test with the node size in the second set range, and the corresponding test is based on the operation of the software simulation module, and a portion of the set nodes are selected to be verified through the hardware testing module.

[0012] Furthermore, in step S4, before performing the full-process collaborative test, synchronous calibration operations are performed on the dynamic control module, hardware testing module, attack scenario replication module, and data acquisition and analysis module. The calibration operations include calibrating the QKD device transmission rate fluctuation, the authenticity of the attack scenario replication, and the data acquisition error. The calibration operations adjust the operating parameters of each module so that the deviation of the operating parameters of each module is within the set range. If the calibration fails, the parameters of the corresponding module are adjusted, and the calibration operation is re-executed until it passes.

[0013] Furthermore, in step S4, the noise reduction of the indicator data is performed using the 3σ criterion to remove outlier data that deviates from the average value by more than a set multiple of the standard deviation; the indicator data is standardized to map indicator data of different dimensions and magnitudes to a set interval, unifying the data magnitude and facilitating multi-indicator comparative analysis.

[0014] Furthermore, in step S4, a corresponding optimization scheme is generated based on the bottleneck type obtained from the location. The bottleneck types include key generation bottlenecks, link transmission bottlenecks, security protection bottlenecks, and topology adaptation bottlenecks. Key generation bottlenecks correspond to optimizing the QKD device's operation parameters, link transmission bottlenecks correspond to adjusting the link bandwidth and bit error rate control strategies, security protection bottlenecks correspond to strengthening the node encryption mechanism and adding an attack detection module, and topology adaptation bottlenecks correspond to optimizing the network topology scheduling algorithm.

[0015] The beneficial effects of this invention are: (1) By building a multi-module collaborative dynamic adaptive test architecture, combined with the network status collection and test strategy dynamic generation mechanism, the test process can be adapted to the QKD network operation status, and the compatibility of the test method with different network scenarios can be improved. (2) A differentiated testing method combining hardware testing and software simulation is adopted. The proportion of the two types of tests can be adjusted according to the network scale, so as to control the test cost and test cycle while ensuring the reference value of the test results. (3) It covers multi-dimensional test items and full-process data processing links, can identify the type of performance bottleneck and locate the corresponding position, output targeted optimization solutions, and provide effective support for network operation and maintenance and performance upgrade. Attached Figure Description

[0016] Figure 1 A flowchart illustrating the steps of a dynamic adaptive QKD network comprehensive testing method; Figure 2 The flowchart illustrates the specific steps of a dynamic adaptive QKD network comprehensive testing method provided in this embodiment. Detailed Implementation

[0017] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Example 1 See Figure 1 This embodiment provides a dynamic adaptive QKD network comprehensive testing method, which includes the following steps: S1. Build a dynamic adaptive QKD network testing architecture. The dynamic adaptive QKD network testing architecture includes a dynamic control module, a hardware testing module, a software simulation module, an attack scenario replication module, and a data acquisition and analysis module. The dynamic control module is used to sense the network status and adjust the test parameters, the hardware testing module is used to perform actual test verification, the software simulation module is used to simulate the network operating status, the attack scenario replication module is used to simulate attack scenarios, and the data acquisition and analysis module is used to process test data. S2. Collect the state parameters of the QKD network under test, complete the initial configuration of the dynamic adaptive QKD network test architecture, set the test baseline threshold, and establish the dynamic update rules for the test baseline threshold; S3. Based on the collected state parameters of the QKD network under test, match the corresponding test scenario, generate suitable test cases, and determine differentiated test strategies; S4. Perform collaborative testing throughout the entire process according to test cases and differentiated testing strategies, collect indicator data during the testing process, process the indicator data, locate performance bottlenecks, and output test reports and optimization solutions.

[0019] In some embodiments, step S1 includes setting up a dynamic control module, a hardware testing module, a software simulation module, an attack scenario replication module, and a data acquisition and analysis module. The dynamic control module is used to sense network topology changes and link operating status, adjust test parameters, generate test cases, control the test process, and update test benchmark thresholds. The hardware testing module is used to perform test verification on the key generation and key negotiation stages, adapting to trusted relay networking and relay-free networking modes. The software simulation module is used to simulate the QKD network operating status under different node scales and different link bit error rates, simulating extreme link environments. The attack scenario replication module is used to simulate various network attack scenarios and adjust the attack intensity level. The data acquisition and analysis module is used to collect test indicator data, perform data noise reduction and data standardization processing, locate performance bottlenecks, and issue potential warnings.

[0020] In some embodiments, step S2 includes the following sub-steps: S2.1. Establish a communication connection with the QKD network under test through a classical channel, and collect the status parameters of the QKD network under test. The status parameters include node size, number of links, key generation baseline rate, initial value of link bit error rate, and network mode. S2.2. Based on the collected status parameters, adjust the operating parameters of each module in the dynamic adaptive QKD network test architecture. The adjustment includes the number of node terminals in the hardware test module and the simulation parameters in the software simulation module, and complete the initial configuration of the dynamic adaptive QKD network test architecture. S2.3. Set multiple test benchmark thresholds, including security thresholds, efficiency thresholds, and stability thresholds; set dynamic update trigger conditions for the test benchmark thresholds, and automatically update the test benchmark thresholds when the QKD network under test meets the trigger conditions.

[0021] In some embodiments, step S3 includes the following sub-steps: S3.1. Based on the collected node scale parameters, classify the test scenario types; S3.2. Match the test case set corresponding to the test scenario type, generate test cases adapted to the current QKD network under test, and the test cases cover all test items of the corresponding test scenario; determine the differentiated test strategy according to the test scenario type. The differentiated test strategy includes the configuration rules for the proportion of hardware actual test and software simulation, as well as the configuration rules for test redundancy.

[0022] In some embodiments, step S4 includes the following sub-steps: S4.1. According to the test cases and differentiated testing strategies, execute the key generation performance test, key negotiation efficiency test, topology adaptability test and security protection test in sequence; the security protection test simulates the attack scenario through the attack scenario replication module; collect various indicator data in the test process, monitor the running status of the QKD network under test in real time, and adjust the test parameters in a synchronous manner. S4.2. Perform noise reduction and standardization processing on the collected index data, compare the processed index data with the test benchmark threshold, mark the qualified and unqualified indicators, and calculate the deviation between the unqualified indicators and the test benchmark threshold. S4.3. Establish a correlation model between indicator data and network performance through correlation analysis algorithms to identify bottleneck types and locate the corresponding nodes or links; S4.4. Generate a standardized test report that includes test parameters, test data, bottleneck location results, and optimization suggestions.

[0023] In some embodiments, in step S2, the dynamic update triggering conditions for the test baseline threshold include the topology change reaching a set value and the link bit error rate fluctuation reaching a set value; when the QKD network under test meets any one of the triggering conditions, the test baseline threshold is automatically updated; the updated test baseline threshold is adapted to the changed operating state of the QKD network under test.

[0024] In some embodiments, in step S3, the differentiated testing strategy configures the usage ratio of the hardware testing module and the software simulation module according to the test scenario type; the first type of test scenario corresponds to the QKD network under test with the node size in the first set range, and the corresponding test mainly uses the operation of the hardware testing module and is supplemented by the operation of the software simulation module; the second type of test scenario corresponds to the QKD network under test with the node size in the second set range, and the corresponding test is based on the operation of the software simulation module, and a portion of the set nodes are selected to be verified by the hardware testing module.

[0025] In some embodiments, in step S4, before performing the full-process collaborative test, a synchronous calibration operation is performed on the dynamic control module, hardware testing module, attack scenario replication module, and data acquisition and analysis module. The calibration operation includes calibrating the QKD device transmission rate fluctuation, the authenticity of the attack scenario replication, and the data acquisition error. The calibration operation adjusts the operating parameters of each module so that the deviation of the operating parameters of each module is within the set range. If the calibration fails, the parameters of the corresponding module are adjusted, and the calibration operation is re-executed until it passes.

[0026] In some embodiments, in step S4, the noise reduction of the indicator data adopts the 3σ criterion to remove abnormal data that deviates from the average value by more than a set multiple of the standard deviation; the standardization of the indicator data maps indicator data of different dimensions and different magnitudes to a set interval, unifies the data magnitude, and facilitates multi-indicator comparative analysis.

[0027] In some embodiments, in step S4, a corresponding optimization scheme is generated based on the bottleneck type obtained from the location. The bottleneck types include key generation bottlenecks, link transmission bottlenecks, security protection bottlenecks, and topology adaptation bottlenecks. Key generation bottlenecks correspond to optimizing the QKD device operation parameters, link transmission bottlenecks correspond to adjusting the link bandwidth and bit error rate control strategies, security protection bottlenecks correspond to strengthening the node encryption mechanism and adding an attack detection module, and topology adaptation bottlenecks correspond to optimizing the network topology scheduling algorithm.

[0028] Example 2 This embodiment provides a specific implementation process for a dynamic adaptive QKD network comprehensive testing method. By constructing a multi-module collaborative testing system, it achieves adaptive testing of QKD networks of different scales and networking modes, ensuring the matching of the testing process with the actual network operating state. Figure 2 As shown, the specific implementation process is as follows: Step 1. Set up the test architecture: Step 1.1. Configure the dynamic control module: The dynamic control module serves as the scheduling unit for the testing process. It detects network topology changes and link operational status, adjusts test parameters, generates test cases, controls the testing process, and updates test baseline thresholds. Detecting network topology changes is achieved by collecting node access status and link connectivity data at a set sampling frequency, allowing for timely acquisition of information on network structural changes. Adjusting test parameters includes adjusting the sampling frequency, the execution order of test items, and the range of nodes for data collection. Generating test cases is based on preset test case templates, which are then populated with corresponding parameters according to network status parameters to generate suitable test cases. Controlling the testing process involves scheduling the start, run, and stop of other modules according to a set time sequence, ensuring the test process executes sequentially. Updating the test baseline thresholds involves calculating new thresholds based on changes in network status according to set rules and replacing the original thresholds, ensuring the thresholds are compatible with the network status.

[0029] In some specific implementations, the dynamic control module collects network operating parameters according to a set sampling frequency. The collected data includes network topology changes, link operating status, and key operating parameters. Through continuous sampling, it achieves continuous control over the network status and provides data support for test parameter adjustment, test case generation, and test process scheduling.

[0030] Step 1.2. Set up the hardware testing module and the software simulation module: The hardware testing module performs practical tests and verifications on the key generation and key negotiation stages, adapting to both trusted relay network and relay-free network modes. The key generation stage test collects data on the key generation process of the connected QKD devices, recording all key generation metrics. The key negotiation stage test monitors the key negotiation interaction process between different nodes, recording negotiation latency and success rate. The trusted relay network mode is a key forwarding network method including relay nodes, while the relay-free network mode is a point-to-point direct connection network method. The hardware testing module supports test data collection for both network modes. The software simulation module simulates the QKD network operation under different node sizes and link error rates, simulating extreme link environments. Simulating different node sizes is achieved by adding or deleting node units in the simulation environment; simulating different link error rates is achieved by setting the error parameters of the simulated link; and simulating extreme link environments involves setting link parameters beyond the normal operating range to test the network's operation under extreme conditions. The software simulation module is built upon the NS-3 simulator integrated with the QKD NetSim plugin. NS-3 is a discrete event network simulator that can be used to construct network communication simulation scenarios. The QKD NetSim plugin is a simulation extension component adapted to the characteristics of QKD networks, capable of simulating link characteristics and key generation processes in quantum key distribution. In this embodiment, the NS-3 simulator provides the basic network simulation environment, while the QKDNetSim plugin supplements the relevant simulation functions for quantum key distribution. The combination of the two enables the simulation of QKD network operation.

[0031] In some specific implementations, the hardware testing module connects to the core operating components of the QKD network, collecting data during actual operation to avoid discrepancies between simulation data and the actual network operating status; the software simulation module can simulate node scale and link bit error rate parameters within a set range, covering network scenarios with high hardware testing costs, and can also simulate link environments beyond the normal operating range, expanding the test coverage.

[0032] In some specific implementations, the software simulation module is built on the NS-3 simulator integrated with the QKD NetSim plugin. It can simulate up to 1000 nodes and has a configurable link error rate range of 0.01 to 0.05, covering parameter ranges for both normal operating scenarios and some degraded scenarios. The NS-3 simulator is a discrete event network simulation tool capable of modeling and simulating network nodes, links, and traffic. The QKD NetSim plugin is a simulation extension component for quantum key distribution networks, supplementing the simulation capabilities for quantum channel noise, key generation processes, and key forwarding logic. When combined, different network topologies can be built by configuring the number of nodes, different quality quantum channels can be simulated by configuring the link error rate, and trusted relay and relay-free network modes can be simulated by adjusting node forwarding rules. This configuration addresses the issues of excessively high testing costs and long deployment cycles for all nodes in large-scale QKD networks. It covers the testing requirements of the entire link through simulation, requiring only a small number of nodes for actual testing and verification to ensure the reference value of the test results. While controlling testing costs, it expands the coverage of test scenarios and adapts to the testing needs of networks of different sizes.

[0033] Step 1.3. Set up the attack scenario replication module: The attack scenario replication module simulates four types of network attack scenarios and adjusts the attack intensity level. The simulated network attack scenarios include quantum channel eavesdropping, node tampering, denial-of-service attacks, and key theft. The quantum channel eavesdropping scenario simulates eavesdropping by inserting measurement operations into the channel; the node tampering scenario simulates a tampered node state by modifying the key data forwarded by the node; the denial-of-service attack scenario simulates a channel blockage state by sending a large amount of invalid data; and the key theft scenario tests key protection capabilities by simulating the illegal acquisition of key data. Attack intensity levels are divided into low, medium, and high, each corresponding to different attack frequencies and attack intensity parameters. Adjusting the attack intensity level allows selecting the appropriate attack parameters based on testing requirements and loading them into the test environment.

[0034] In some specific implementations, the attack scenario replication module can dynamically adjust the attack intensity level according to the security level of the QKD network under test. Different attack intensities correspond to different attack frequencies and attack ranges, which can adapt to the protection capability testing needs of networks with different security levels.

[0035] In some specific implementations, the attack scenario replication module can simulate four core attack scenarios: quantum channel eavesdropping, node tampering, denial-of-service attacks, and key theft. It also sets three attack strength levels: low, medium, and high. The quantum channel eavesdropping scenario simulates third-party interception and measurement of quantum signals by inserting measurement nodes into a simulated or tested quantum channel. The node tampering scenario simulates abnormal operation after a node is illegally controlled by modifying the key forwarding rules and data content of relay nodes. The denial-of-service attack scenario simulates channel congestion and resource occupation by injecting a large number of invalid signals into classical or quantum channels. The key theft scenario tests the protection capabilities of key storage and access control by simulating illegal access to the key storage process. Low strength corresponds to a lower attack frequency and a smaller attack impact range; medium strength corresponds to a regular attack frequency and a moderate impact range; and high strength corresponds to a higher attack frequency and a larger impact range. This configuration can cover typical security threats faced during QKD network operation. By adjusting the attack strength in stages, it adapts to the testing needs of networks with different security levels, comprehensively tests the network's security protection capabilities, and identifies weaknesses in security protection links.

[0036] Step 1.4. Set up the data acquisition and analysis module: The data acquisition and analysis module collects test indicator data, performs data denoising and standardization, locates performance bottlenecks, and issues early warnings of potential problems. Test indicator data is collected synchronously from the hardware testing module, software simulation module, and attack scenario replication module, ensuring data time synchronization. Data denoising removes outliers from the collected data, reducing the impact of interference. Data standardization unifies the numerical ranges of different indicators, facilitating comparative analysis of multi-dimensional indicators. Performance bottlenecks are located by identifying the links and locations affecting network performance through data analysis, providing direction for optimization. Early warnings are generated for indicators approaching thresholds to detect potential problems in advance.

[0037] In some specific implementations, the data acquisition and analysis module supports the simultaneous acquisition of multiple core indicators. The acquired data is stored according to the set precision, and the error in the acquisition process is controlled within the set range. The module has built-in data noise reduction algorithm and correlation analysis algorithm, which can complete the processing of test data and interpretation of results.

[0038] In some specific implementations, the data acquisition and analysis module supports the simultaneous acquisition of 12 core indicators: key generation rate, key negotiation latency, key leakage rate, link error rate, network throughput, key forwarding latency, node access response time, link failure recovery time, attack detection response time, key negotiation success rate, node scaling performance degradation rate, and network stable operation time. The acquired data is stored with three decimal places, and the error during the acquisition process is controlled within a set range to ensure data accuracy and consistency. The module incorporates a 3σ data denoising algorithm and a correlation analysis algorithm. The 3σ data denoising algorithm calculates the mean and standard deviation of the dataset, eliminating outliers that deviate from the mean by more than three standard deviations, thus removing interference from environmental fluctuations and acquisition anomalies. The correlation analysis algorithm calculates the correlation coefficients between each indicator and the overall network performance, establishing a relationship between the indicators and performance. This configuration enables the simultaneous acquisition and unified processing of multi-dimensional test data, improving the efficiency and accuracy of data processing, providing complete data support for subsequent bottleneck identification and performance evaluation, and ensuring the reliability of test analysis results.

[0039] Step 2. Network Status Awareness and Initialization Configuration: Step 2.1. Collect network status parameters: A communication connection is established with the QKD network under test via a classical channel to collect its state parameters, including node size, number of links, key generation baseline rate, initial link error rate, and network topology. The classical channel is a traditional wired or wireless communication channel used to transmit non-quantum control and state data. In this embodiment, a communication link is established between the test architecture and the management node of the network under test via a classical channel to transmit state data and control commands. Node size refers to the number of QKD nodes in the network under test; number of links refers to the total number of quantum and classical links between nodes in the network under test; key generation baseline rate refers to the reference value of the key generation rate under normal network operation; initial link error rate refers to the initial value of the link error rate before the test begins; and network topology refers to whether the network uses a trusted relay or no relay network.

[0040] In some specific implementations, a communication connection is established with the management node of the QKD network under test through a classic channel to realize the transmission of status data and control commands between the test architecture and the network under test, ensuring the real-time nature of status acquisition and the effective issuance of control commands.

[0041] Step 2.2. Complete the test architecture initialization configuration: Based on the collected status parameters, adjust the operating parameters of all modules in the dynamic adaptive QKD network test architecture. This adjustment includes the number of node terminals in the hardware test modules and the simulation parameters in the software simulation modules, completing the initial configuration of the dynamic adaptive QKD network test architecture. Adjusting the number of node terminals in the hardware test modules involves adjusting the number of terminal devices connected to the test environment according to the node scale of the network under test, ensuring it matches the test requirements. Adjusting the simulation parameters in the software simulation modules involves setting the number of nodes, link parameters, and network topology in the simulation environment based on the collected network status parameters, ensuring the simulation environment matches the initial state of the network under test. After completing the initial configuration, perform connectivity tests between modules to ensure all modules can normally receive scheduling commands and transmit data.

[0042] In some specific implementations, the initialization configuration process adjusts the adaptation mode of the hardware test module and the network topology of the software simulation module based on the collected network mode parameters, so that the operating mode of the test architecture is consistent with the network mode of the network under test.

[0043] Step 2.3. Set the test baseline threshold and update rules: Three types of test baseline thresholds are set: security thresholds, efficiency thresholds, and stability thresholds. Dynamic update trigger conditions are set for these test baseline thresholds; when the QKD network under test meets the trigger conditions, the test baseline thresholds are automatically updated. Security thresholds include key leakage rate thresholds and attack protection success rate thresholds; efficiency thresholds include key generation rate thresholds and key negotiation latency thresholds; and stability thresholds include link error rate thresholds and performance degradation rate thresholds. Dynamic update trigger conditions include topology change reaching a set value and link error rate fluctuation reaching a set value. Topology change refers to the proportion of the number of nodes or links in the network that has changed relative to the original number; link error rate fluctuation refers to the difference between the current link error rate and the initial link error rate. When any trigger condition is met, the test baseline thresholds are automatically updated according to the set calculation rules to adapt the thresholds to the changed network state.

[0044] In some specific implementations, the test benchmark thresholds cover multiple indicators such as key generation rate, key negotiation latency, key leakage rate, link error rate, and node scaling performance degradation rate. All thresholds can be fine-tuned according to actual test requirements to adapt to different test scenarios.

[0045] Step 3. Test Case Generation and Strategy Determination: Step 3.1. Divide the test scenario types: Based on the collected node size parameters, test scenario types are categorized. The node size parameters are compared with pre-defined intervals to classify the network under test into different test scenario types. The first and second pre-defined intervals are pre-defined ranges for the number of nodes, used to distinguish test scenarios for networks of different sizes.

[0046] In some specific implementations, the classification of test scenario types is based on the range of node size and the range of link quantity. Combining these two parameters, the scenario type of the network under test is determined, thereby improving the rationality of scenario classification.

[0047] Step 3.2. Generate test cases and determine the test strategy: A test case set is matched to the corresponding test scenario type to generate test cases adapted to the current QKD network under test. These test cases cover all test items for the corresponding test scenario. A differentiated testing strategy is determined based on the test scenario type. This strategy includes configuration rules for the proportion of hardware testing and software simulation, as well as configuration rules for test redundancy. The test case set is matched by selecting all test items for the corresponding scenario from a pre-set test case library to generate adapted test cases. Network state parameters are substituted into the test case template to generate specific test steps and parameters that conform to the current network conditions, ensuring the completeness of the test content. The configuration rules for the proportion of hardware testing and software simulation specify the respective proportions of test content undertaken by hardware testing and software simulation in different scenarios. The configuration rules for test redundancy specify the proportion of repeated tests, used to balance test accuracy and test time. The differentiated testing strategy configures the usage ratio of hardware testing modules and software simulation modules according to the test scenario type. The first type of test scenario corresponds to the QKD network under test with the node scale in the first set range. The corresponding test mainly uses the operation of the hardware testing module and is supplemented by the operation of the software simulation module. The second type of test scenario corresponds to the QKD network under test with the node scale in the second set range. The corresponding test is based on the operation of the software simulation module, and a portion of the selected nodes are verified by the hardware testing module.

[0048] In some specific implementations, the differentiated testing strategy also configures test redundancy parameters, with different redundancy control ranges corresponding to different test scenarios. This ensures the reliability of test results while reducing unnecessary test time.

[0049] Step 4. Collaborative Testing and Result Output: Step 4.1. Perform pre-test calibration: Before performing full-process collaborative testing, synchronous calibration operations are performed on the dynamic control module, hardware testing module, attack scenario replication module, and data acquisition and analysis module. The calibration operations include calibrating the QKD device's transmission rate fluctuations, the realism of the attack scenario replication, and data acquisition errors. The calibration operations adjust the operating parameters of all modules to ensure that the deviations of all module operating parameters are within the set range. If the calibration fails, the parameters of the corresponding module are adjusted, and the calibration operation is repeated until it passes. Calibrating the QKD device's transmission rate fluctuations involves outputting a standard rate test signal to detect the deviation between the rate data acquired by the hardware testing module and the standard value. Calibrating the realism of the attack scenario replication involves loading a standard attack scenario and comparing the deviation between the actual operating parameters of the attack scenario and the standard parameters. Calibrating data acquisition errors involves inputting standard test data and comparing the deviation between the data output by the data acquisition and analysis module and the standard data. The calibration process first outputs a standard test signal, collects the output data of all modules, compares it with the standard value to calculate the deviation, and if the deviation is within the set range, the calibration is considered successful.

[0050] In some specific implementations, the synchronous calibration operation requires that the transmission rate fluctuation of the QKD device be within a set range, the matching degree between the operation status of the attack scenario replication and the standard scenario meet the set requirements, and the data acquisition error be within a set range; only after all three calibration items are qualified can the formal testing process be started.

[0051] In some specific implementations, the pre-test synchronization calibration operation includes three core calibration items: QKD device transmission rate fluctuation calibration, attack scenario replication fidelity calibration, and data acquisition error calibration. The calibration pass standards are: QKD device transmission rate fluctuation not exceeding 5%, attack scenario replication fidelity not less than 95%, and data acquisition error not exceeding 1%. QKD device transmission rate fluctuation calibration involves outputting a test key stream at a standard rate, collecting rate data recorded by the hardware testing module, comparing and calculating the actual fluctuation value. If the fluctuation exceeds the range, the device's clock synchronization parameters and data sampling parameters are adjusted until the fluctuation meets the requirements. Attack scenario replication fidelity calibration involves loading a standard attack scenario template, comparing the attack parameters output by the attack scenario replication module with the parameters of the standard template, and adjusting the attack module's parameter configuration if the deviation exceeds the range until the matching degree meets the requirements. Data acquisition error calibration involves inputting a test dataset with standard values, comparing the processing results output by the data acquisition and analysis module with the standard dataset, and adjusting the sampling accuracy and data conversion parameters of the acquisition module if the deviation exceeds the range until the error meets the requirements. This calibration process can unify the operating benchmarks of each module before formal testing, eliminate system deviations between modules, ensure the consistency of test data and the reliability of test results, and avoid test result distortion due to equipment parameter deviations.

[0052] Step 4.2. Perform full-process testing and collect data: Following test cases and differentiated testing strategies, key generation performance testing, key negotiation efficiency testing, topology adaptability testing, and security protection testing were executed sequentially. Security protection testing simulated attack scenarios using an attack scenario replication module. All performance metrics were collected synchronously during the testing process, and the operational status of the QKD network under test was monitored in real time, with test parameters adjusted accordingly. Key generation performance testing ensured stable operation of the network under test, collecting key generation data under different link error rates and calculating the average and fluctuation values ​​of the key generation rate. Key negotiation efficiency testing simulated key negotiation scenarios between nodes at different locations, collecting the latency and success rate of each negotiation and calculating the average value. Topology adaptability testing simulated two scenarios: node scaling and link failure, collecting data on network throughput, performance degradation rate, and fault recovery time. Security protection testing loaded corresponding attack scenarios using an attack scenario replication module to test the network's protection capabilities under different attack scenarios. All performance metrics were collected synchronously during the testing process to ensure data time synchronization. The operational status of the QKD network under test was monitored in real time, and test parameters were adjusted synchronously when the network status changed, ensuring the adaptability of the testing process to the network status.

[0053] In some specific implementations, during the key generation performance test, the QKD network under test is kept in a stable operating state, different link bit error rate levels are switched sequentially, and each bit error rate level is continuously tested for a set duration. Key generation data is collected within the corresponding duration, the average value and fluctuation value of the key generation rate are calculated, and the calculation results are compared with the corresponding benchmark threshold to determine the compliance status of the test.

[0054] Step 4.2.1 Key generation rate calculation formula: When conducting key generation performance testing, to quantify the impact of link error rate and system loss on the effective key generation rate, a secure key generation rate calculation model based on the binary entropy function is adopted. This model, combined with measured link and system parameters, calculates the theoretical secure key generation rate. Comparing the calculated results with the measured key generation rate further pinpoints the sources of performance loss in the key generation process, distinguishing between inherent losses from channel loss and additional losses from equipment parameters, thus improving the accuracy of bottleneck identification. The formula for calculating the secure key generation rate is: ; in, is the secure key generation rate, and is the effective key generation rate after removing error loss and error correction loss; is the original key generation rate, and is the original key generation rate obtained after decoding the quantum signal; The system transmission efficiency is the percentage of the quantum signal that is effective after transmission through the channel and attenuation by the device. is the link bit error rate, and is the proportion of errors in signal transmission in the quantum channel; is the error correction efficiency coefficient, and is the proportion of additional key loss caused by the error correction algorithm. This is a binary entropy function used to quantify the amount of information leakage caused by bit errors. This corresponds to the bit error rate value; This is a logarithmic operation with base 2. The formula comprehensively considers three factors affecting key generation efficiency: channel transmission loss, error information leakage, and error correction algorithm loss. It can calculate the theoretical upper limit of the secure key generation rate. Comparing the theoretical calculated value with the measured key generation rate can determine whether the current device's key generation capability has reached the expected level. If the measured value deviates significantly from the theoretical value, it indicates that there is room for optimization of the device parameters. This can serve as an auxiliary basis for judging key generation bottlenecks and provide a quantitative reference for parameter optimization of QKD devices.

[0055] Step 4.2.2 Formula for calculating performance degradation rate: When conducting node scaling tests for topology adaptability, the impact of network size changes on operational performance is quantified by calculating the performance degradation rate. The performance degradation rate reflects the percentage decrease in core network performance indicators after node number adjustments and is a core parameter for evaluating network topology adaptability. The performance degradation rate is calculated by comparing network performance data at the initial scale with performance data under stable operating conditions after scaling. The degree of degradation is obtained through ratio calculation. This indicator directly reflects the network's tolerance to scale changes and provides a quantitative basis for determining topology adaptation bottlenecks. The formula for calculating the node scaling performance degradation rate is: ; in, The node scaling performance degradation rate is used to characterize the degree of performance decline after network size adjustment; These are baseline performance values ​​for the network during stable operation at the initial node scale, taken from core performance indicators such as throughput or key generation rate in the initial state of the network. This represents the performance value of the network after the node size adjustment and the network has returned to stable operation. It is taken from the corresponding performance indicators after the node scaling is completed and the network status is stable. This formula calculates the relative attenuation ratio based on the initial performance, which can unify the performance attenuation evaluation standard for networks of different sizes and avoid evaluation bias caused by differences in the basic network performance. The calculated performance attenuation rate can be directly compared with the corresponding test benchmark threshold to determine whether the topology adaptability index meets the standard. At the same time, it can also serve as the basis for identifying topology adaptation bottlenecks, supporting subsequent bottleneck location and optimization scheme generation, and improving the objectivity and accuracy of topology adaptability evaluation.

[0056] In some specific implementations, topology adaptability testing includes two types of test scenarios: node scaling and link failure. The node scaling test gradually adjusts the initial node size to a set multiple and records the network performance changes during the adjustment process. The link failure test simulates the scenario of one or more links being interrupted and records the network recovery process after the failure occurs. Both tests collect network throughput, performance degradation rate and failure recovery time data to evaluate the network's topology adaptability.

[0057] Step 4.3. Test Data Processing and Comparison: The collected indicator data undergoes noise reduction and standardization processing. The processed indicator data is then compared with a test benchmark threshold, marking compliant and non-compliant indicators, and calculating the deviation of non-compliant indicators from the test benchmark threshold. Noise reduction employs the 3σ criterion to remove outliers exceeding a set multiple standard deviations from the average. The 3σ criterion is an outlier removal method based on the statistical characteristics of normal distribution. In a normal distribution, most data points are concentrated around the average, and data deviating from three times the average has an extremely low probability of occurrence, thus being identified as outliers. In this embodiment, by calculating the average and standard deviation of the collected data, outliers exceeding a set multiple standard deviations from the average are removed, reducing the impact of outliers on the test results. Standardization mapping indicator data of different dimensions and magnitudes to a set interval unifies the data magnitude, facilitating multi-indicator comparative analysis. The processed indicator data is then compared with the test benchmark threshold one by one, marking compliant and non-compliant indicators, and calculating the deviation of non-compliant indicators from the test benchmark threshold to clarify the degree of deviation.

[0058] Step 4.3.1 Data Standardization Calculation Formula: When standardizing test indicator data, a linear normalization method is used to map the original data to a set numerical range, eliminating differences in dimensions and magnitudes between different indicators. This provides a basis for horizontal comparison of test indicators across different dimensions, facilitating subsequent multi-indicator comprehensive analysis and bottleneck correlation calculations. Standardization is performed independently for each test indicator, completing the numerical mapping based on the extreme values ​​of the corresponding indicator's dataset. The processed data retains the distribution patterns and relative differences of the original data, without altering the inherent relationships between the data, thus ensuring the accuracy of subsequent analysis results. The formula for data standardization is: ; in, These are standardized indicator values, with values ​​within a set range, used for horizontal comparison and comprehensive calculation of multiple indicators. These are the original index values ​​before standardization processing, and the test data directly collected by the data acquisition and analysis module. The minimum value within the corresponding indicator dataset is taken from all collected data for the same test indicator during the complete test period. The maximum value within the corresponding indicator dataset is also taken from all collected data for the same test indicator throughout the complete test period. This formula achieves data uniformity through linear transformation, requires no complex calculations, and has high processing efficiency. It is suitable for batch standardization of multiple indicators in QKD network testing. The processed indicator data can be directly used to calculate the deviation from the benchmark threshold, or for multi-indicator weighted comprehensive evaluation, providing a unified data foundation for subsequent performance bottleneck localization and improving the convenience of multi-dimensional indicator comparison and the reliability of analysis results.

[0059] In some specific implementations, data standardization processes map test data of different dimensions and magnitudes to a numerical range of zero to one, unifying the data magnitude standard and enabling horizontal comparison and comprehensive analysis of different types of indicator data.

[0060] Step 4.3.2 Network comprehensive performance score calculation formula: After standardizing the test data, a weighted summation method is used to calculate the overall performance score of the QKD network. This integrates multi-dimensional test indicators into a single comprehensive score, facilitating a direct comparison of the overall performance level under different network conditions. It can also be used to compare the performance changes of the same network at different optimization stages, providing a unified quantitative standard for evaluating optimization effectiveness. The formula for calculating the network's comprehensive performance score is: ; in, The network's overall performance score is a quantitative value of overall performance obtained by weighting multiple dimensions of indicators. The higher the value, the better the overall network performance. The number of test metrics used in the calculation is denoted by , and the total number of core performance metrics selected is denoted by . For the first The weight coefficients corresponding to each indicator represent the importance of that indicator in the comprehensive performance evaluation, and the sum of all weight coefficients is 1. For the first The standardized values ​​of each indicator have a range consistent with the set interval of the standardization process, eliminating the dimensional differences of the original indicators. This formula allows for flexible adjustment of the proportion of different indicators in the comprehensive evaluation through weight configuration, adapting to the evaluation focus of different testing scenarios. For example, in security testing scenarios, the weight of security-related indicators can be increased, while in performance testing scenarios, the weight of efficiency-related indicators can be increased. The calculated comprehensive performance score can be directly used for horizontal comparison of different network solutions, and can also be used to record performance changes before and after network optimization, quantifying the actual effect of optimization measures and providing intuitive quantitative results to support performance evaluation in test reports.

[0061] Step 4.4. Performance bottleneck identification: A correlation analysis algorithm is used to establish a model linking indicator data and network performance, identifying bottleneck types and locating corresponding nodes or links. Correlation analysis is a statistical method used to analyze the degree of correlation between two or more types of variables, quantifying the strength of the correlation by calculating the correlation coefficient. In this embodiment, by analyzing the correlation between all test indicators and overall network performance, the main factors affecting network performance are identified, and bottleneck types are determined. Bottleneck types include key generation bottlenecks, link transmission bottlenecks, security protection bottlenecks, and topology adaptation bottlenecks. Based on the correlation analysis results, bottlenecks are located to corresponding nodes or links, clarifying the specific problem location.

[0062] Step 4.4.1 Pearson correlation coefficient calculation formula: In some specific implementations, when conducting correlation analysis for performance bottleneck localization, the Pearson correlation coefficient is used to quantify the correlation strength between various test indicators and the overall network performance. By calculating the correlation coefficient between each individual indicator and the overall performance indicator, the degree of influence of different indicators on the overall network performance is determined, and the indicator with the greatest impact on performance is identified. This helps to determine the bottleneck type and improve the objectivity and accuracy of bottleneck localization. The formula for calculating the Pearson correlation coefficient is: ; in, As an indicator With indicators The Pearson correlation coefficient ranges from -1 to 1, with a larger absolute value indicating a stronger correlation between the two indicators. The number of test data samples is denoted as , and the total number of valid data points collected for the same indicator is denoted as . For the first sample points The indicator values ​​are the actual measured data for a single test indicator; for The average of all samples of the indicator is The arithmetic mean of all sample data for the indicator; For the first sample points The numerical value of the indicator is usually the corresponding value of the overall network performance indicator; for The average of all samples of the indicator is the arithmetic mean of all sample data of the comprehensive performance indicator. The summation operator represents the summation of the corresponding calculation results for all sample points; The square root operator is used to perform square root operations on the summation result. The correlation coefficient directly reflects the degree of linear correlation between two indicators. When the absolute value of the correlation coefficient is close to 1, it indicates a strong linear correlation between the two indicators; when the correlation coefficient is close to 0, it indicates a weak linear correlation. During bottleneck localization, the correlation coefficients between each test indicator and the overall network performance indicator are calculated. The link corresponding to the indicator with the largest absolute value of the correlation coefficient is selected as the main bottleneck link. This reduces the subjectivity of manual judgment, improves the reliability of bottleneck localization results, and provides quantitative support for the generation of subsequent optimization schemes.

[0063] In some specific implementations, when locating bottlenecks, if the key generation rate is below standard while the link error rate is within the normal range, the bottleneck is determined to be a key generation bottleneck, and the corresponding source of the problem is the operation parameter configuration of the QKD device. Through correlation analysis, the problem can be located to a single or multiple specific devices, improving the targeting of optimization.

[0064] Step 4.5. Generate test report and optimization plan: Generate a standardized test report containing test parameters, test data, bottleneck location results, and optimization suggestions; generate corresponding optimization solutions based on the identified bottleneck types. The standardized test report covers basic test information, configuration parameters for all modules, test case content, full-process test data, metric compliance status, and bottleneck location results, providing a clear overview of the complete test process and results. Based on the identified bottleneck types, corresponding optimization solutions are generated: for key generation bottlenecks, optimize QKD device operation parameters and adjust key generation settings to improve key generation capabilities; for link transmission bottlenecks, adjust link bandwidth and bit error rate control strategies to improve link transmission conditions and reduce the bit error rate; for security protection bottlenecks, strengthen node encryption mechanisms and add attack detection modules to enhance network attack protection capabilities; for topology adaptation bottlenecks, optimize network topology scheduling algorithms to improve the flexibility of node scaling and the speed of fault recovery.

[0065] In some specific implementations, the standardized test report includes six core contents: basic test information, test architecture configuration, test parameters and test cases, full-process test data, indicator compliance status, and bottleneck location results. The report supports exporting to a standardized format and can be used in various scenarios such as project acceptance and operation and maintenance records.

[0066] This embodiment establishes a multi-module collaborative dynamic adaptive testing architecture, combined with a real-time network status awareness and dynamic update mechanism for test benchmark thresholds. This enables dynamic adaptation of the testing process to the actual operating status of the QKD network, making it applicable to QKD network testing scenarios of different scales and networking modes. Through differentiated testing strategies, the ratio of hardware testing to software simulation is rationally configured for different network scales, ensuring the reference value of test results while reducing testing costs and time consumption in large-scale network scenarios and improving the execution efficiency of the testing process. The testing process covers four dimensions of network operating status: key generation performance, key negotiation efficiency, topology adaptability, and security protection. Through standardized data processing and correlation analysis, it can identify and locate performance bottlenecks, outputting referential network optimization directions to support the daily operation and maintenance and performance upgrades of QKD networks. Simultaneously, the pre-test synchronous calibration process ensures the stable operation of all test modules, reduces system errors during testing, and improves the reliability of test results. The overall testing process forms a complete execution loop, from initial network status awareness and test plan generation to test execution, data processing, and finally result output and optimization suggestions. The process is seamless and can be directly applied to various work scenarios such as QKD network acceptance testing, daily operation and maintenance, and performance optimization.

[0067] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A dynamic adaptive QKD network synthesis and testing method, characterized in that, Includes the following steps: S1. Build a dynamic adaptive QKD network testing architecture. The dynamic adaptive QKD network testing architecture includes a dynamic control module, a hardware testing module, a software simulation module, an attack scenario replication module, and a data acquisition and analysis module. The dynamic control module is used to sense the network status and adjust the test parameters, the hardware testing module is used to perform actual test verification, the software simulation module is used to simulate the network operating status, the attack scenario replication module is used to simulate attack scenarios, and the data acquisition and analysis module is used to process test data. S2. Collect the state parameters of the QKD network under test, complete the initial configuration of the dynamic adaptive QKD network test architecture, set the test baseline threshold, and establish the dynamic update rules for the test baseline threshold; S3. Based on the collected state parameters of the QKD network under test, match the corresponding test scenario, generate suitable test cases, and determine the differentiated test strategy; S4. Perform collaborative testing throughout the entire process according to test cases and differentiated testing strategies, collect indicator data during the testing process, process the indicator data, locate performance bottlenecks, and output test reports and optimization solutions.

2. The method according to claim 1, characterized in that, In step S1, a dynamic control module, a hardware testing module, a software simulation module, an attack scenario replication module, and a data acquisition and analysis module are set up. The dynamic control module is used to sense network topology changes and link operation status, adjust test parameters, generate test cases, control the test process, and update test benchmark thresholds. The hardware testing module is used to perform test verification on the key generation and key negotiation stages, and adapt to trusted relay networking mode and relayless networking mode. The software simulation module is used to simulate the QKD network operation status under different node scales and different link bit error rates, and simulate extreme link environments. The attack scenario replication module is used to simulate various network attack scenarios and adjust the attack intensity level. The data acquisition and analysis module is used to collect test index data, perform data noise reduction and data standardization, locate performance bottlenecks, and issue early warnings of potential problems.

3. The method according to claim 1, characterized in that, Step S2 includes the following sub-steps: S2.

1. Establish a communication connection with the QKD network under test through a classical channel, and collect the status parameters of the QKD network under test. The status parameters include node size, number of links, key generation baseline rate, initial value of link bit error rate, and network mode. S2.

2. Based on the collected status parameters, adjust the operating parameters of each module in the dynamic adaptive QKD network test architecture. The adjustment includes the number of node terminals in the hardware test module and the simulation parameters in the software simulation module, and complete the initial configuration of the dynamic adaptive QKD network test architecture. S2.

3. Set multiple test benchmark thresholds, including safety thresholds, efficiency thresholds, and stability thresholds; Set dynamic update trigger conditions for the test baseline threshold. When the QKD network under test meets the trigger conditions, the test baseline threshold will be automatically updated.

4. The method according to claim 1, characterized in that, Step S3 includes the following sub-steps: S3.

1. Based on the collected node scale parameters, classify the test scenario types; S3.

2. Match the test case set corresponding to the test scenario type, generate test cases that are suitable for the current QKD network under test, and the test cases cover all test items of the corresponding test scenario; Differentiated testing strategies are determined based on the type of test scenario. These strategies include configuration rules for the proportion of actual hardware testing and the proportion of software simulation, as well as configuration rules for test redundancy.

5. The method according to claim 1, characterized in that, Step S4 includes the following sub-steps: S4.

1. According to the test cases and differentiated testing strategies, execute the key generation performance test, key negotiation efficiency test, topology adaptability test and security protection test in sequence; the security protection test simulates the attack scenario through the attack scenario replication module; collect various indicator data in the test process, monitor the running status of the QKD network under test in real time, and adjust the test parameters in a synchronous manner. S4.

2. Perform noise reduction and standardization processing on the collected index data, compare the processed index data with the test benchmark threshold, mark the qualified and unqualified indicators, and calculate the deviation between the unqualified indicators and the test benchmark threshold. S4.

3. Establish a correlation model between indicator data and network performance through correlation analysis algorithms to identify bottleneck types and locate the corresponding nodes or links; S4.

4. Generate a standardized test report that includes test parameters, test data, bottleneck location results, and optimization suggestions.

6. The method according to claim 1, characterized in that, In step S2, the dynamic update triggering conditions for the test baseline threshold include the topology change reaching a set value and the link bit error rate fluctuation reaching a set value; when the QKD network under test meets any one of the triggering conditions, the test baseline threshold is automatically updated; the updated test baseline threshold is adapted to the changed operating state of the QKD network under test.

7. The method according to claim 1, characterized in that, In step S3, the differentiated testing strategy configures the usage ratio of the hardware test module and the software simulation module according to the test scenario type; the first type of test scenario corresponds to the QKD network under test with the node scale in the first set range, and the corresponding test mainly uses the operation of the hardware test module and secondarily uses the operation of the software simulation module. The second type of test scenario corresponds to the QKD network under test with the node scale within the second set range. The corresponding test is based on the operation of the software simulation module, and a portion of the set nodes are selected for verification through the hardware test module.

8. The method according to claim 1, characterized in that, In step S4, before performing the full-process collaborative test, synchronous calibration operations are performed on the dynamic control module, hardware testing module, attack scenario replication module, and data acquisition and analysis module. The calibration operations include calibrating the QKD device transmission rate fluctuation, the authenticity of the attack scenario replication, and the data acquisition error. The calibration operations adjust the operating parameters of each module so that the deviation of the operating parameters of each module is within the set range. If the calibration fails, the parameters of the corresponding module are adjusted and the calibration operation is re-executed until it passes.

9. The method according to claim 1, characterized in that, In step S4, the noise reduction of the indicator data is performed using the 3σ criterion to remove outlier data that deviates from the average value by more than a set multiple of the standard deviation. The indicator data is then standardized to map indicator data of different dimensions and magnitudes to a set interval, unifying the data magnitude and facilitating comparative analysis of multiple indicators.

10. The method according to claim 1, characterized in that, In step S4, corresponding optimization schemes are generated based on the bottleneck types identified. The bottleneck types include key generation bottlenecks, link transmission bottlenecks, security protection bottlenecks, and topology adaptation bottlenecks. Key generation bottlenecks correspond to optimizing the QKD device's operational parameters, link transmission bottlenecks correspond to adjusting link bandwidth and bit error rate control strategies, security protection bottlenecks correspond to strengthening node encryption mechanisms and adding attack detection modules, and topology adaptation bottlenecks correspond to optimizing network topology scheduling algorithms.

Images