A quantum key pool on-demand charging and quality of service guarantee method and system

Abstract

The application provides a quantum key pool on-demand charging and quality of service guarantee method and system. The method comprises the following steps: obtaining quantum key demand information of a user terminal through a sensing adaptation layer; determining a target charging mode through a scene matcher based on the demand information; constructing a three-dimensional dynamic rate adjustment model to calculate a real-time rate; determining a key distribution strategy based on the real-time rate through a quantum communication service station and distributing quantum keys in combination with a quality of service guarantee strategy, and simultaneously collecting a key actual use state in real time through a two-chain synchronization mechanism of a quantum key chain and a charging data chain; performing charging settlement based on the key actual use state and the real-time rate to generate a charging detail; synchronizing the charging detail to a block chain storage node after encryption to generate a storage record; and thereby realizing closed-loop linkage of charging and key distribution, improving charging flexibility and transparency, and guaranteeing the quality of service of the quantum key pool.

Description

Technical Field

[0001] This application relates to the field of quantum communication technology, and more specifically, to a method and system for on-demand billing and quality of service assurance for quantum key pools. Background Technology

[0002] With the advent of quantum computers, traditional asymmetric cryptographic algorithms face the potential risk of being cracked. Quantum Key Distribution (QKD) technology, based on the fundamental principles of quantum physics, can achieve unconditionally secure key distribution over public channels, ensuring from a fundamental level that any eavesdropping will be detected. Based on this, quantum secure communication technology has received widespread attention and application.

[0003] Currently, quantum key distribution technology is upgrading from the traditional "point-to-point" communication model to a "networked, pooled" service model. As an innovative key management architecture, quantum key pools utilize virtualization technology to achieve centralized storage, dynamic scheduling, and on-demand distribution of quantum keys, providing flexible and efficient key resource support for large-scale quantum communication networks. Against this backdrop, the reasonableness of quantum key pool billing and the stability of service quality have become critical issues that urgently need to be addressed in the field of quantum communication.

[0004] In the prior art, invention patent CN114519598B discloses a billing method and system for quantum key distribution networks based on digital currency. This method uses quantum communication service stations to issue quantum keys with monetary value to users, and completes billing and settlement during key usage through digital currency. However, the billing basis of this method is the number of keys issued, and users are charged before actually using the keys, which easily leads to idle and wasted keys; moreover, its billing model is singular and does not distinguish the billing responsibility between the communication initiator and the receiver, making it unable to adapt to the differentiated needs of different scenarios such as IoT terminals, cross-domain financial transactions, and long-term encryption in government affairs.

[0005] Furthermore, invention patent CN116418489B discloses a blockchain-based quantum key billing system. This system includes a quantum key management terminal, a blockchain-based distributed storage system, a quantum service support system, and quantum key application devices. It uses blockchain to achieve distributed storage of billing information, avoiding data loss due to single-point device failure. However, the system's billing logic is based solely on the quantum key output and subscribed packages, lacking a dynamic rate adjustment mechanism. It cannot dynamically adjust rates according to real-time network conditions such as quantum key pool inventory, relay node load, and peak / valley times. Simultaneously, the system lacks a service quality assurance solution, failing to address key issues in QKD network operation such as multi-link concurrency conflicts, unstable key supply rates, and traffic congestion.

[0006] In summary, existing technologies are insufficient in terms of billing model flexibility, billing and key distribution process coordination, rate dynamic adjustment capability, and service quality assurance, making it difficult to meet the requirements for billing accuracy, transparency, and service quality stability in large-scale commercial scenarios of quantum key pools.

[0007] Effective technical solutions are urgently needed to address the above problems. Summary of the Invention

[0008] The purpose of this application is to provide a method and system for on-demand billing and quality of service assurance for quantum key pools, which realizes closed-loop linkage between billing and key distribution, improves billing flexibility and transparency, and ensures the quality of service of quantum key pools.

[0009] This application provides a method for on-demand billing and quality of service assurance for quantum key pools, including the following steps: The quantum key requirement information of the user terminal is obtained through the perception adaptation layer. The quantum key requirement information includes the key quantity, security level and timeliness requirements. Based on the quantum key demand information, a target billing mode is determined by a preset scenario matcher. The target billing mode includes billing based on usage, billing based on routing node consumption, billing based on duration, or package billing. Based on the target billing mode, scenario dimension parameters, load dimension parameters and time dimension parameters are obtained through the preset rate management module, and a three-dimensional dynamic rate adjustment model is constructed to calculate the real-time rate. The key distribution strategy is determined by the preset quantum communication service station based on the real-time rate, and the quantum key is distributed from the quantum key pool in combination with the preset service quality assurance strategy. At the same time, the actual key usage status is collected in real time through the two-chain synchronization mechanism of quantum key chain and billing data chain, and the actual key usage status is synchronized to the billing engine. Based on the actual usage status of the key and the real-time rate, the billing engine performs billing and settlement, generates billing details, and refines the billing details to the relay node level. The billing details are encrypted by the encryption service module and then synchronized to the blockchain evidence storage node to generate an immutable evidence storage record.

[0010] Optionally, in the quantum key pool on-demand billing and quality of service assurance method described in this application, the step of obtaining the user terminal's quantum key demand information through the perception adaptation layer includes the key demand quantity, security level, and timeliness requirements, specifically including: The user terminal adaptation module in the perception adaptation layer collects the terminal type identifier and historical usage records of the user terminal. The terminal type identifier includes IoT terminals, financial terminals and government equipment. Based on the terminal type identifier and the historical usage record, the user terminal's key requirement, security level, and timeliness requirements are extracted by the demand identification engine in the perception adaptation layer to generate quantum key requirement information.

[0011] Optionally, in the quantum key pool on-demand billing and quality of service assurance method described in this application, the step of determining the target billing mode based on the quantum key demand information through a preset scenario matcher specifically includes: The scenario type is matched using a preset scenario matcher based on the key requirement quantity and security level in the quantum key requirement information; When a user does not have a current billing mode, or when the billing mode corresponding to the scenario type is inconsistent with the user's current billing mode, the scenario matcher determines the billing mode corresponding to the scenario type as the target billing mode. The target billing model is synchronized to the billing engine and linked with historical billing data to ensure the continuity of billing data.

[0012] Optionally, in the quantum key pool on-demand billing and quality of service assurance method described in this application, the step of obtaining scenario-dimensional parameters, load-dimensional parameters, and time-dimensional parameters through a preset rate management module based on the target billing mode, and constructing a three-dimensional dynamic rate adjustment model to calculate the real-time rate specifically includes: The preset rate management module queries the preset configuration table to obtain scenario-dimensional parameters, including security level rate coefficient and purpose subsidy coefficient. The quantum key chain sends query requests to the quantum key pool and relay nodes to obtain load dimension parameters, including the stock ratio of the quantum key pool and the load rate of the relay nodes. Obtain the current time and compare it with the preset peak and valley time period division table to obtain time dimension parameters, including peak time period identifier and valley time period identifier; The real-time rate is calculated based on scenario-dimensional parameters, load-dimensional parameters, and time-dimensional parameters, using preset rate calculation rules. When the stock ratio of the quantum key pool is higher than the preset high stock threshold or the load rate of the relay node is lower than the preset low load threshold, the preferential rate is triggered. Peak rates are triggered when the stock ratio of the quantum key pool is lower than the preset low stock threshold or the load rate of the relay node is higher than the preset high load threshold. When both the preferential rate and peak rate trigger conditions are met, the result of the relay node load rate determination shall prevail.

[0013] Optionally, in the quantum key pool on-demand billing and quality of service assurance method described in this application, the step of determining the key distribution strategy based on the real-time rate through a preset quantum communication service station, distributing quantum keys from the quantum key pool in conjunction with the preset quality of service assurance strategy, and simultaneously collecting the actual key usage status in real time through a two-chain synchronization mechanism between the quantum key chain and the billing data chain, and synchronizing the actual key usage status to the billing engine, specifically includes: The real-time rate is compared with the preset rate range by using a preset quantum communication service station. The preset rate range includes a low rate range and a high rate range. When the real-time rate is in the low rate range, the key distribution strategy is determined to be the batch pre-distribution mode; When the real-time rate is in the high rate range, the key distribution strategy is determined to be the on-demand instant distribution mode; Key distribution path is selected based on the load rate of relay nodes; Quantum keys are distributed from the quantum key pool according to the determined key distribution strategy and key distribution path, combined with the quality of service assurance strategy. The quantum key chain collects the key distribution status of quantum communication service stations, quantum key pools and relay nodes in real time as the actual key usage status. The actual key usage status includes the number of keys distributed, the amount of keys consumed, the amount of keys remaining, the distribution timestamp and the relay node identifier, and synchronizes the actual key usage status to the billing engine. By using the billing data chain, the usage logs and pre-allocation records generated by the billing engine during the key distribution process are synchronized in real time to the blockchain storage node, so as to achieve the time sequence consistency between key distribution and original billing data.

[0014] Optionally, in the quantum key pool on-demand billing and quality of service assurance method described in this application, the quality of service assurance strategy includes key request priority allocation based on response weight factors, specifically: Based on the key requirements and security level of the user terminal, the request priority is determined by the response weight factor calculation formula. The response weighting factor is calculated using the following formula: Response weighting factor = Normalized key requirement value × α + (Preset highest security level) Security level) × β, where α and β are preset weighting coefficients; The order of requests and responses is determined by sorting them in ascending order of response weight factors; the smaller the response weight factor, the higher the priority of the request. When the amount of quantum key pool is lower than the preset replenishment threshold, keys are replenished from other quantum key pools during idle time slots.

[0015] Optionally, in the quantum key pool on-demand billing and quality of service assurance method described in this application, the step of replenishing keys from other quantum key pools further includes: A prediction model that combines recurrent neural networks and convolutional neural networks is used as input to output the predicted key consumption for a future preset time period, taking the historical key consumption data of a preset number of relay nodes as input. Based on the predicted key consumption and the current quantum key pool inventory, determine whether to trigger key replenishment and the amount to replenish.

[0016] Optionally, in the quantum key pool on-demand billing and quality of service assurance method described in this application, the method for determining the supplementary amount specifically includes: Using the quantum key pool stock and network load as constraints, the key supply rate for the next cycle is calculated using a linear programming algorithm. The fluctuation range of the key supply rate is limited to a preset elastic window. When the calculated supply rate exceeds the elastic window, it is truncated to the window boundary value.

[0017] Secondly, this application provides a quantum key pool on-demand billing and quality of service assurance system, implementing any of the described quantum key pool on-demand billing and quality of service assurance methods, including: The perception and adaptation module is used to obtain the quantum key requirement information of the user terminal through the perception and adaptation layer. The quantum key requirement information includes the key requirement quantity, security level and timeliness requirements. The scenario matching module is used to determine the target billing mode based on the quantum key requirement information through a preset scenario matcher. The target billing mode includes billing based on usage, billing based on routing node consumption, billing based on duration, or package billing. The dynamic rate calculation module is used to obtain scenario dimension parameters, load dimension parameters and time dimension parameters through the preset rate management module based on the target billing mode, and to construct a three-dimensional dynamic rate adjustment model to calculate the real-time rate. The key distribution and synchronization module is used to determine the key distribution strategy based on the real-time rate through the preset quantum communication service station, and distribute quantum keys from the quantum key pool in combination with the preset quality of service guarantee strategy. At the same time, it collects the actual key usage status in real time through the two-chain synchronization mechanism of quantum key chain and billing data chain, and synchronizes the actual key usage status to the billing engine. The billing and settlement module is used to perform billing and settlement through the billing engine based on the actual usage status of the key and the real-time rate, and generate billing details, which are refined to the relay node level. The blockchain evidence storage module is used to encrypt the billing details through the encryption service module and synchronize them to the blockchain evidence storage node to generate an immutable evidence storage record.

[0018] Optionally, in the quantum key pool on-demand billing and quality of service assurance system described in this application, the dynamic rate calculation module further includes: The scenario parameter acquisition submodule is used to query the preset configuration table through the preset rate management module to obtain scenario dimension parameters, including security level rate coefficient and purpose subsidy coefficient. The load parameter acquisition submodule is used to obtain load dimension parameters, including the stock ratio of the quantum key pool and the load rate of the relay nodes, by sending query requests to the quantum key pool and relay nodes through the quantum key chain. The time parameter acquisition submodule is used to obtain the current time and compare it with the preset peak and valley time period division table to obtain time dimension parameters, including peak time period identifier and valley time period identifier; The rate calculation submodule is used to calculate the real-time rate based on scenario dimension parameters, load dimension parameters, and time dimension parameters, according to preset rate calculation rules. The rate adjustment submodule is used to trigger a preferential rate when the stock ratio of the quantum key pool is higher than the preset high stock threshold or the relay node load rate is lower than the preset low load threshold, and to trigger a peak rate when the stock ratio of the quantum key pool is lower than the preset low stock threshold or the relay node load rate is higher than the preset high load threshold. When both the preferential rate and peak rate triggering conditions are met, the result of the relay node load rate determination shall prevail.

[0019] As can be seen from the above, the quantum key pool on-demand billing and quality of service assurance method and system provided in this application obtains the quantum key demand information of user terminals through the perception adaptation layer; determines the target billing mode based on the demand information through a scenario matcher; constructs a three-dimensional dynamic rate adjustment model to calculate the real-time rate; distributes quantum keys through a quantum communication service station based on the real-time rate and in combination with the quality of service assurance strategy, while simultaneously collecting the actual key usage status in real time through a two-chain synchronization mechanism between the quantum key chain and the billing data chain; performs billing settlement based on the actual key usage status and the real-time rate to generate billing details; and encrypts the billing details and synchronizes them to the blockchain storage node to generate storage records. This achieves a closed-loop linkage between billing and key distribution, improves billing flexibility and transparency, and ensures the quality of service of the quantum key pool. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1A flowchart illustrating the quantum key pool on-demand billing and quality of service assurance method provided in this application embodiment; Figure 2 A flowchart illustrating the determination of the target billing mode for the quantum key pool on-demand billing and quality of service assurance method provided in this application embodiment; Figure 3 A flowchart illustrating the construction of a three-dimensional dynamic rate adjustment model and real-time rate calculation for the quantum key pool on-demand billing and quality of service assurance method provided in this application embodiment. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0023] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a quantum key pool on-demand billing and quality of service (QoS) assurance method according to some embodiments of this application. This quantum key pool on-demand billing and QoS assurance method is used in a quantum key pool management system. The quantum key pool on-demand billing and QoS assurance method includes the following steps: S11. Obtain the quantum key requirement information of the user terminal through the perception adaptation layer. The quantum key requirement information includes the key requirement quantity, security level and timeliness requirements. S12. Based on the quantum key requirement information, a target billing mode is determined by a preset scenario matcher. The target billing mode includes billing based on usage, billing based on routing node consumption, billing based on duration, or package billing. S13. Based on the target billing mode, obtain scenario dimension parameters, load dimension parameters and time dimension parameters through the preset rate management module, and construct a three-dimensional dynamic rate adjustment model to calculate the real-time rate. S14. The key distribution strategy is determined based on the real-time rate by the preset quantum communication service station, and the quantum key is distributed from the quantum key pool in combination with the preset service quality assurance strategy. At the same time, the actual usage status of the key is collected in real time through the two-chain synchronization mechanism of the quantum key chain and the billing data chain, and the actual usage status of the key is synchronized to the billing engine. S15. Based on the actual usage status of the key and the real-time rate, perform billing and settlement through the billing engine to generate billing details, which are refined to the relay node level. S16. The billing details are encrypted by the encryption service module and then synchronized to the blockchain evidence storage node to generate an immutable evidence storage record.

[0025] It is important to emphasize that the quantum key pool on-demand billing and quality of service assurance method in this application takes the "full lifecycle value of quantum keys" as its core and constructs a closed-loop process of "perception adaptation - scenario matching - rate calculation - key distribution - billing settlement - secure storage". The data flow of the overall technical solution is as follows: the user terminal submits quantum key demand information → the scenario matcher determines the target billing mode based on the demand information → the rate management module constructs a three-dimensional dynamic rate adjustment model based on the target billing mode to calculate the real-time rate → the quantum communication service station determines the key distribution strategy based on the real-time rate and distributes the key, while collecting the actual key usage status through a two-chain synchronization mechanism → the billing engine performs billing settlement and generates billing details based on the actual key usage status and the real-time rate → the billing details are encrypted and synchronized to the blockchain for storage, forming a complete data flow closed loop between each step.

[0026] The perception and adaptation layer is the core of front-end interaction and requirement parsing. It includes a user terminal adaptation module, a requirement identification engine, and a scenario matcher. It is responsible for accurately capturing user key requirements (requirement quantity, security, and timeliness) and mapping them to the corresponding billing mode. Quantum key requirement information refers to the set of quantization parameters required by the user terminal during the use of quantum keys. Among them, the key requirement quantity refers to the amount of quantum key data (in bytes) required by the user terminal in a single or periodic use. The security level refers to the user terminal's required level of key confidentiality (e.g., ordinary, confidential, top secret). The timeliness requirement refers to the user terminal's constraints on key acquisition time (e.g., immediate acquisition or delayed acquisition). The target billing mode refers to the billing method determined based on the user's requirement characteristics, including four types: billing by usage (suitable for low-traffic, high-frequency scenarios), billing by routing node consumption (suitable for high-traffic scenarios across multiple relay nodes), billing by duration (suitable for long-term, fixed scenarios), and package billing (suitable for stable, high-frequency scenarios). The three-dimensional dynamic rate adjustment model is a mathematical model that calculates rates in real time by combining three dimensions: scenario-based parameters (security level rate coefficient, usage subsidy coefficient), load-based parameters (key pool inventory ratio, relay node load rate), and time-based parameters (peak time period identifier, valley time period identifier). The quantum key chain is the data link connecting the quantum communication service station, the quantum key pool, and the relay nodes. It is used to synchronize the key distribution status to the billing engine, ensuring the authenticity of the billing basis. The billing data chain is the data link connecting the billing engine and the blockchain notarization node. It is used to synchronize billing details and payment records to the blockchain in real time, achieving consistency in the "distribution-billing-notarization" time sequence. The two-chain synchronization mechanism refers to the collaborative work of the quantum key chain and the billing data chain, ensuring that the key distribution status and billing data remain consistent in the time series, solving the problem of "disconnection between key status and billing data" in traditional solutions. The actual key usage status refers to the status data generated during the actual use of the key, including the number of keys distributed, the amount of keys consumed, the amount of keys remaining, the distribution timestamp, and the relay node identifier. Quality of Service (QoS) assurance strategies refer to resource allocation and traffic control strategies designed to meet the high security and low latency requirements of different scenarios. These strategies include priority allocation based on response weight factors, key consumption prediction and elastic supply, dynamic allocation of master-slave storage, and backpressure traffic control mechanisms.

[0027] The core logic of the quantum communication service station's key distribution strategy based on real-time rates is as follows: when the real-time rate is low (indicating ample network resources), a batch pre-distribution mode is adopted to reduce user waiting time; when the real-time rate is high (indicating strained network resources), an on-demand real-time distribution mode is adopted to avoid resource waste. Billing details are refined to the relay node level. This means that for key distribution scenarios across multiple relay nodes, the billing engine calculates the cost separately based on the actual consumption of each node, generating a "total bill + node detailed bill," allowing users to clearly understand the cost composition. The encryption service module uses "quantum key + AES-256" dual encryption, with the key dynamically updated during transmission to prevent interception and cracking; the blockchain evidence storage node adopts a consortium blockchain architecture, generating a unique hash value and timestamp for each billing data, supporting multi-party auditing. This application's embodiments, through the above technical solutions, achieve closed-loop linkage between billing and key distribution, avoiding the problem of "billing before use"; adapt to the differentiated needs of different scenarios through four types of billing modes; realize real-time dynamic adjustment of rates through a three-dimensional dynamic rate adjustment model; ensure that the billing basis is the actual amount of key consumption through a two-chain synchronization mechanism; and ensure that the billing data is tamper-proof through blockchain notarization, thereby improving the security, flexibility, and transparency of the billing system.

[0028] According to an embodiment of the present invention, in step S11, the quantum key requirement information of the user terminal is obtained through the sensing adaptation layer. The quantum key requirement information includes the key requirement quantity, security level, and timeliness requirements, specifically including: The user terminal adaptation module in the perception adaptation layer collects the terminal type identifier and historical usage records of the user terminal. The terminal type identifier includes IoT terminals, financial terminals and government equipment. Based on the terminal type identifier and the historical usage record, the user terminal's key requirement, security level, and timeliness requirements are extracted by the demand identification engine in the perception adaptation layer to generate quantum key requirement information.

[0029] It is important to emphasize that the user terminal adaptation module is the front-end component of the perception adaptation layer, responsible for ensuring compatibility with the access and data collection of multiple types of terminal devices. Terminal type identification refers to the identification information used to distinguish the categories of user terminal devices. Different terminal types correspond to different key usage characteristics and security requirements: IoT terminals (such as environmental monitoring sensors and smart wearable devices) typically have characteristics of low traffic, high frequency, and low security level; financial terminals (such as bank transaction terminals) typically have characteristics of medium to high traffic, high security level, and strict timeliness requirements; government equipment (such as government office systems) typically have characteristics of high traffic, top-secret security level, and stable usage cycle. Historical usage records refer to the key usage data of user terminals in past periods, including information such as average daily key usage, usage frequency, and usage time distribution. Based on the terminal type identification and historical usage records, the demand identification engine extracts key demand (e.g., predicting current demand based on historical average daily usage), security level (e.g., mapping security level based on terminal type), and timeliness requirements (e.g., determining whether immediate acquisition is needed based on the application scenario) through preset rules or models, generating structured quantum key demand information. This application embodiment is compatible with multiple types of terminal devices through a user terminal adaptation module, and accurately extracts demand information based on terminal type and historical records through a demand identification engine, providing an accurate data foundation for subsequent scenario matching and billing mode selection, thereby improving the matching accuracy of billing modes.

[0030] For example, taking a cross-regional financial transaction scenario: A bank's transaction terminal, through a user terminal adaptation module, is identified as a "financial terminal." Historical usage records show an average daily key usage of 500KB, an average daily usage frequency of 50 times, and usage concentrated between 9:00 and 17:00. The demand identification engine, based on the "financial terminal" type identifier, extracts the security level as "confidential," based on the historical average daily usage of 500KB, extracts the key requirement as 500KB, and based on the concentrated usage time, extracts the timeliness requirement as "instant acquisition," ultimately generating quantum key demand information {key requirement: 500KB, security level: confidential, timeliness requirement: instant acquisition}.

[0031] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating the determination of the target billing mode in some embodiments of the quantum key pool on-demand billing and quality of service assurance method. According to an embodiment of the present invention, step S12, determining the target billing mode based on the quantum key demand information using a preset scenario matcher, specifically includes: The scenario type is matched using a preset scenario matcher based on the key requirement quantity and security level in the quantum key requirement information; When a user does not have a current billing mode, or when the billing mode corresponding to the scenario type is inconsistent with the user's current billing mode, the scenario matcher determines the billing mode corresponding to the scenario type as the target billing mode. The target billing model is synchronized to the billing engine and linked with historical billing data to ensure the continuity of billing data.

[0032] It is important to emphasize that the scenario matcher is a core component of the perception adaptation layer, with built-in mapping rules between scenario types and billing modes. Scenario type refers to the application scenario category categorized based on key demand and security level. For example: when the key demand is less than a preset small-volume threshold (e.g., 10KB) and the security level is normal, it matches as an "IoT small-volume scenario," with a billing mode of usage-based pricing; when the key demand is greater than a preset large-volume threshold (e.g., 100KB) and involves cross-domain transmission, it matches as a "cross-domain large-volume scenario," with a billing mode of pricing based on routing node consumption; when the security level is top-secret and the usage duration exceeds a preset duration threshold (e.g., 1 day), it matches as a "long-term encryption scenario," with a billing mode of time-based pricing; when historical usage records show stable daily key usage and a request frequency greater than a preset frequency threshold (e.g., 1000 times / day), it matches as a "high-frequency stable scenario," with a billing mode of package pricing. When a user is using the service for the first time (no current billing mode exists) or when the billing mode corresponding to the scenario type is inconsistent with the user's current billing mode, a mode switch is triggered, and the newly matched billing mode is determined as the target billing mode. Upon receiving the target billing mode, the billing engine automatically integrates the user's historical billing data (such as pre-allocated but unused key amounts, prepaid amounts, etc.) to ensure no data gaps occur during the mode switch. The scenario matcher also supports two mode switching methods: manual switching and automatic switching. Users can manually select the billing mode through their terminals; when scenario characteristics change (such as a change in terminal type or a sudden change in key requirements), the scenario matcher automatically triggers a mode switch and pushes a confirmation reminder to the user. After the switch, the billing engine automatically integrates historical data to avoid data gaps.

[0033] This application embodiment uses a scenario matcher to automatically match billing modes based on key demand and security level, and supports dynamic switching between multiple modes and integration with historical data. This allows the billing mode to accurately adapt to the differentiated needs of different scenarios, avoiding resource waste or unreasonable billing caused by traditional single billing modes. For example, taking a government daily office system scenario: the initial billing mode of a certain government office system is "billing by time" (because the system was initially a long-term encryption scenario). As business expands, the average daily key usage increases from 50MB to 150MB, and the request frequency reaches an average of 1500 times per day. Based on the key demand of 150MB and the high-frequency characteristics in historical usage records, the scenario matcher matches the scenario type as "high-frequency stable scenario," and the corresponding billing mode as "package billing." Since the current billing mode (billing by time) is inconsistent with the matching result (package billing), the scenario matcher determines "package billing" as the target billing mode and synchronizes it to the billing engine. After receiving the data, the billing engine converts the remaining valid time of the user under the time-based billing mode into a package credit, and connects it with historical billing data to ensure billing continuity.

[0034] Please refer to Figure 3 , Figure 3 This document presents a flowchart illustrating the construction of a three-dimensional dynamic rate adjustment model and real-time rate calculation for a quantum key pool on-demand billing and quality of service assurance method provided in this application embodiment. According to this embodiment, step S13, based on the target billing mode, involves obtaining scenario dimension parameters, load dimension parameters, and time dimension parameters through a preset rate management module, constructing a three-dimensional dynamic rate adjustment model, and calculating the real-time rate. Specifically, this includes: The preset rate management module queries the preset configuration table to obtain scenario-dimensional parameters, including security level rate coefficient and purpose subsidy coefficient. The quantum key chain sends query requests to the quantum key pool and relay nodes to obtain load dimension parameters, including the stock ratio of the quantum key pool and the load rate of the relay nodes. Obtain the current time and compare it with the preset peak and valley time period division table to obtain time dimension parameters, including peak time period identifier and valley time period identifier; The real-time rate is calculated based on scenario-dimensional parameters, load-dimensional parameters, and time-dimensional parameters, using preset rate calculation rules. When the stock ratio of the quantum key pool is higher than the preset high stock threshold or the load rate of the relay node is lower than the preset low load threshold, the preferential rate is triggered. Peak rates are triggered when the stock ratio of the quantum key pool is lower than the preset low stock threshold or the load rate of the relay node is higher than the preset high load threshold. When both the preferential rate and peak rate trigger conditions are met, the result of the relay node load rate determination shall prevail.

[0035] It is important to emphasize that the three-dimensional dynamic rate adjustment model achieves dynamic rate adjustment through three dimensions: scenario, load, and time, avoiding the rigidity of traditional fixed rates. The security level rate coefficient refers to the rate multiplier set according to the key's security level; for example, 1.0 times for ordinary level, 1.5 times for confidential level, and 2.0 times for top secret level. The usage subsidy coefficient refers to the rate adjustment coefficient set according to the purpose of key use; for example, 0.8 times (subsidized) for government scenarios, 0.9 times for public service scenarios, and 1.0 times for commercial scenarios. The quantum key pool inventory ratio refers to the ratio of the number of available keys in the current key pool to the total capacity of the key pool. The relay node load rate refers to the ratio of the current processing load of a relay node to its maximum processing capacity. Peak and valley time identifiers are used to distinguish the rate multipliers for different time periods; for example, the rate multiplier for peak time (8:00-20:00) is 1.0, and the rate multiplier for valley time (20:00-8:00 the next day) is 0.8.

[0036] The formula for calculating real-time rates is: Real-time rate = base rate × security level rate coefficient × purpose subsidy coefficient × load adjustment coefficient × time period adjustment coefficient; The base rate refers to the unit rate benchmark value determined according to the billing model (e.g., the base rate for usage-based billing is 0.01 yuan / KB); the load adjustment coefficient is determined based on the load dimension parameter, taking 0.9 when a preferential rate is triggered, 1.2 when a peak rate is triggered, and 1.0 otherwise; the time-period adjustment coefficient is determined based on the time dimension parameter, taking 1.0 for peak periods and 0.8 for valley periods. The linear programming algorithm uses "maximizing the sum of resource utilization and user satisfaction" as the objective function, with constraints that "the rate adjustment range is within a preset interval" and "the product of the load adjustment coefficient and the time-period adjustment coefficient is within a preset range," to solve for the optimal rate combination.

[0037] The preset high inventory threshold refers to the upper limit of the key pool inventory ratio that triggers the preferential rate (e.g., 80%), and the preset low load threshold refers to the lower limit of the relay node load rate that triggers the preferential rate (e.g., 50%). When the key pool inventory ratio is higher than 80% (sufficient resources) or the relay node load rate is lower than 50% (light load), the preferential rate is triggered (load adjustment coefficient is 0.9) to encourage users to use it. The preset low inventory threshold refers to the lower limit of the key pool inventory ratio that triggers the peak rate (e.g., 20%), and the preset high load threshold refers to the upper limit of the relay node load rate that triggers the peak rate (e.g., 90%). When the key pool inventory ratio is lower than 20% (scarce resources) or the relay node load rate is higher than 90% (overloaded), the peak rate is triggered (load adjustment coefficient is 1.2) to regulate demand through the pricing mechanism. When the key pool inventory ratio is higher than 80% (meeting preferential conditions) and the relay node load rate is higher than 90% (meeting peak conditions), the relay node load rate (i.e., peak rate) will be used as the standard to ensure network stability, since the relay node load rate directly affects the key distribution performance.

[0038] This application embodiment achieves real-time dynamic adjustment of rates based on three dimensions: scenario, load, and time through a three-dimensional dynamic rate adjustment model. It solves the optimal rate combination through a linear programming algorithm, achieves supply and demand balance through the triggering mechanism of preferential rates and peak rates, and ensures network stability by using conflict arbitration rules (based on the load rate of relay nodes). It effectively adapts to the distributed characteristics and dynamic network environment of quantum key pools.

[0039] For example, a user terminal uses a confidential key for commercial communication. The current time is 14:00 (peak hour). The quantum key pool's inventory level is 85%, and the relay node load rate is 35%. The base rate is 0.01 yuan / KB, the security level rate coefficient is 1.5 (confidential level), and the usage subsidy coefficient is 1.0 (commercial scenario). Because the key pool inventory level of 85% is higher than the preset high inventory threshold of 80%, a preferential rate is triggered, and the load adjustment coefficient is set to 0.9. The time period is peak hour, and the time period adjustment coefficient is set to 1.0. The real-time rate = 0.01 × 1.5 × 1.0 × 0.9 × 1.0 = 0.0135 yuan / KB.

[0040] For example, a user terminal uses a top-secret key for government communication. The current time is 22:00 (off-peak period). The quantum key pool has a stock ratio of 15%, and the relay node load rate is 95%. The base rate is 0.01 yuan / KB, the security level rate coefficient is 2.0 (top-secret), and the usage subsidy coefficient is 0.8 (government scenario). Because the key pool stock ratio of 15% is lower than the preset low stock threshold of 20% and the relay node load rate of 95% is higher than the preset high load threshold of 90%, the peak rate is triggered, and the load adjustment coefficient is set to 1.2. The time period is off-peak, and the time period adjustment coefficient is set to 0.8. The real-time rate = 0.01 × 2.0 × 0.8 × 1.2 × 0.8 = 0.01536 yuan / KB.

[0041] According to an embodiment of the present invention, step S14, which involves determining a key distribution strategy based on the real-time rate through a preset quantum communication service station and distributing quantum keys from the quantum key pool in conjunction with a preset quality of service assurance strategy, while simultaneously collecting the actual key usage status in real time through a two-chain synchronization mechanism between the quantum key chain and the billing data chain, and synchronizing the actual key usage status to the billing engine, specifically includes: The real-time rate is compared with the preset rate range by using a preset quantum communication service station. The preset rate range includes a low rate range and a high rate range. When the real-time rate is in the low rate range, the key distribution strategy is determined to be the batch pre-distribution mode; When the real-time rate is in the high rate range, the key distribution strategy is determined to be the on-demand instant distribution mode; Key distribution path is selected based on the load rate of relay nodes; Quantum keys are distributed from the quantum key pool according to the determined key distribution strategy and key distribution path, combined with the quality of service assurance strategy. The quantum key chain collects the key distribution status of quantum communication service stations, quantum key pools and relay nodes in real time as the actual key usage status. The actual key usage status includes the number of keys distributed, the amount of keys consumed, the amount of keys remaining, the distribution timestamp and the relay node identifier, and synchronizes the actual key usage status to the billing engine. By using the billing data chain, the usage logs and pre-allocation records generated by the billing engine during the key distribution process are synchronized in real time to the blockchain storage node, so as to achieve the time sequence consistency between key distribution and original billing data.

[0042] It is important to emphasize that the technical solution in this embodiment solves the problem of dynamic linkage between key distribution strategy and rate. The quantum communication service station compares the real-time rate with a preset rate range, which includes a low rate range and a high rate range. The low rate range refers to the range where the rate is lower than a preset low rate threshold (corresponding to a state of sufficient network resources), and the high rate range refers to the range where the rate is higher than a preset high rate threshold (corresponding to a state of strained network resources). When the real-time rate is in the low rate range, network resources are sufficient, and a batch pre-distribution mode is adopted—that is, a key quantity greater than the current demand is pre-allocated to user terminals at once (pre-allocated quantity = estimated usage × 1.2), reducing the frequency of subsequent user requests and waiting time. When the real-time rate is in the high rate range, network resources are strained, and an on-demand real-time distribution mode is adopted—that is, a precise number of keys are allocated only when the user actually initiates a request, avoiding resource occupation and waste caused by pre-allocation. The quantum communication service station selects the optimal key distribution path based on the load rate of each relay node, prioritizing the path of nodes with lower load rates to achieve load balancing. When distributing keys, a quality of service (QoS) assurance strategy (such as priority ranking based on response weight factors) is incorporated to ensure that requests from high-priority users are responded to first. The quantum key chain refers to a real-time data link connecting the quantum communication service station, the quantum key pool, and relay nodes. Its function is to continuously collect key status data from each node during key distribution. The specific content of the actual key usage status includes: the number of keys distributed (the total amount distributed from the key pool), the amount of keys consumed (the amount actually used by user terminals), the amount of keys remaining (the amount pre-allocated but unused), the distribution timestamp (the timestamp of each distribution operation), and the relay node identifier (the number of the relay node participating in the distribution). This status data is synchronized in real-time to the billing engine through the quantum key chain, enabling the billing engine to perform billing based on the actual key consumption rather than the pre-allocated amount. The billing data chain synchronizes the usage logs (recording detailed information about each key usage) and pre-allocation records (recording the pre-allocated key amount and its recovery status) generated by the billing engine during key distribution to the blockchain notarization node in real-time, ensuring that the key distribution operation and the original billing data are completely consistent in time series, achieving time-series synchronization of "distribution-billing-notarization". When the three-dimensional dynamic rate adjustment model triggers a peak rate, the real-time rate is usually higher than the preset high rate threshold and enters the high rate range.

[0043] The core design of the two-chain synchronization mechanism is as follows: the quantum key chain is responsible for "state acquisition"—reporting the key distribution status of the physical layer to the billing engine in real time; the billing data chain is responsible for "data storage"—uploading the raw billing data generated by the billing engine to the chain for storage in real time. The two chains run in parallel, and the timestamp alignment mechanism ensures that the recording time of the same key distribution event is consistent on both chains, thereby achieving time synchronization between the key distribution status and the billing data. This fundamentally solves the problem of "billing before use" caused by the "separation of key status and billing data" in traditional schemes.

[0044] This application's embodiments achieve real-time linkage between key distribution and billing data through a rate-driven key distribution strategy selection and a two-chain synchronization mechanism. This ensures that billing is based on the actual key consumption, load balancing is achieved by selecting the distribution path based on relay node load rates, and the immutability of the original billing data is ensured through blockchain notarization. For example, in a cross-regional financial transaction scenario: a bank needs to distribute keys across regions through three relay nodes (node ​​A, node B, and node C), requiring 500KB of keys. The quantum communication service station obtains a real-time rate of 0.06 yuan / KB, and after comparing it with the preset rate range, determines that it falls within the high rate range (assuming a high rate threshold of 0.05 yuan / KB), thus determining the on-demand instant distribution strategy. The quantum communication service station obtains the load rates of each relay node: node A at 70%, node B at 40%, and node C at 55%, and selects the path of node B with the lowest load rate for distribution. Following the on-demand instant distribution mode and service quality assurance strategy, 500KB of quantum keys are accurately distributed from the quantum key pool to the user terminal. During the distribution process, the quantum key chain collects the key distribution status in real time: key distribution quantity 500KB, key consumption 0KB (just distributed), remaining key quantity 500KB, distribution timestamp is the current moment, relay node identifier is "Node B", and synchronizes it to the billing engine. After the user terminal uses the key, the billing data chain synchronizes the usage log (key ID, usage time, usage quantity) and pre-allocation records to the blockchain evidence storage node.

[0045] According to an embodiment of the present invention, the quality of service assurance strategy includes key request priority allocation based on response weight factors, specifically: Based on the key requirements and security level of the user terminal, the request priority is determined by the response weight factor calculation formula. The response weighting factor is calculated using the following formula: Response weighting factor = Normalized key requirement value × α + (Preset highest security level) Security level) × β, where α and β are preset weighting coefficients; The order of requests and responses is determined by sorting them in ascending order of response weight factors; the smaller the response weight factor, the higher the priority of the request. When the amount of quantum key pool is lower than the preset replenishment threshold, keys are replenished from other quantum key pools during idle time slots.

[0046] It is important to emphasize that, in this embodiment, the core mechanism of the quality of service assurance strategy is the priority allocation of key requests based on response weighting factors. When the quantum key pool receives multiple key requests from different user terminals simultaneously, it needs to determine the response order of the requests according to scientific and quantifiable priority ranking rules in order to maximize the quality of security services under the constraint of limited key resources. Specifically, for each key request arriving at the quantum key pool, the system first extracts two key attribute information of the user terminal associated with the request: key demand and security level. Key demand refers to the number of quantum keys (unit: bits or key blocks) that the request needs to obtain from the key pool, reflecting the scale of resource consumption of the request; security level refers to the level of security assurance required by the user terminal in the quantum key distribution process, usually represented by a preset number of levels, such as 1 to 10, with a higher value indicating a higher security requirement. Based on the above two attribute information, a comprehensive score value is calculated for the request using the following response weighting factor calculation formula: Response weighting factor = Normalized key requirement value × α + (Preset highest security level) Security level) × β; Wherein, α and β are preset weighting coefficients, both positive values, used to adjust the contribution of key demand and security level difference to the final weighting factor, respectively. In this embodiment, the value of α ranges from 0.3 to 0.5, and the value of β ranges from 0.5 to 0.7, which can be dynamically adjusted according to the scenario (e.g., β is set to 0.7 in industrial sensor scenarios to emphasize security, and β is set to 0.5 in ordinary monitoring terminal scenarios to balance demand and security). The preset maximum security level refers to the maximum value (e.g., 10) among all security levels supported by the system, which is a fixed parameter preset by the system. The security level is the actual security level value required by the request. (Preset maximum security level) The security level reflects the "security gap" between the security level of the request and the highest security level of the system; the higher the security level, the smaller this difference.

[0047] The calculation logic of the response weighting factor has the following intuitive meaning: When two requests have the same key requirement, the request with the higher security level will be weighted (based on the preset highest security level). A lower security level (α) corresponds to a lower response weight factor, thus receiving a higher response priority. When two requests have the same security level, the request with a smaller key requirement has a smaller response weight factor due to the lower key requirement × α, resulting in a higher response priority. This design principle reflects a resource scheduling strategy that prioritizes high-security-level, small-batch key requests, maximizing security service coverage with limited key resources.

[0048] After calculating the response weight factors for all pending requests, the requests are sorted in ascending order (i.e., from smallest to largest response weight factor) to determine their response priority. The sorting rule is: the smaller the response weight factor, the higher the priority of the request, and the system will allocate quantum key resources to that request first. If multiple requests have the same response weight factor, they can be reordered according to their arrival time, or a fair scheduling strategy such as round-robin can be used.

[0049] According to an embodiment of the present invention, the step of replenishing the key from other quantum key pools further includes: A prediction model that combines recurrent neural networks and convolutional neural networks is used as input to output the predicted key consumption for a future preset time period, taking the historical key consumption data of a preset number of relay nodes as input. Based on the predicted key consumption and the current quantum key pool inventory, determine whether to trigger key replenishment and the amount to replenish.

[0050] It is important to emphasize that this embodiment achieves accurate prediction of key consumption through a machine learning model, providing data support for key replenishment decisions. The prediction model, a fusion of Recurrent Neural Network (RNN) and Convolutional Neural Network (CNN), employs a parallel dual-branch architecture, including an input layer, an RNN branch, a CNN branch, a fusion layer, and an output layer. It is a hybrid neural network model that combines the advantages of RNN in processing time-series data with the ability of CNN to extract local features. The input layer receives historical key consumption data from a predetermined number of relay nodes and organizes it into a two-dimensional data matrix. The rows of the matrix correspond to each relay node (spatial dimension), and the columns correspond to the hourly consumption at each time step (time dimension). The input layer then passes this two-dimensional data matrix to the RNN branch and the CNN branch for parallel processing. The RNN branch uses a Long Short-Term Memory (LSTM) network structure, containing two LSTM layers with 128 hidden units per layer. The RNN branch reads the historical consumption data sequence of each relay node step by step along the time dimension, learning the time dependence of consumption at each node (such as intraday periodic fluctuations and weekly trend changes). The hidden state output of the RNN branch at the final time step is a 128-dimensional time feature vector. The CNN branch contains two one-dimensional convolutional layers and one max pooling layer. The first convolutional layer has a kernel size of 3 and 64 kernels, the second convolutional layer has a kernel size of 3 and 32 kernels, and the max pooling layer has a pooling window size of 2. The CNN branch performs one-dimensional convolution operations on the consumption data of each relay node at the same time step along the spatial dimension, extracting spatial correlation features between multiple relay nodes (such as the mutual influence of consumption between nodes), and outputs a 32-dimensional spatial feature vector after dimensionality reduction by the max pooling layer. The fusion layer concatenates the 128-dimensional temporal feature vector output from the RNN branch with the 32-dimensional spatial feature vector output from the CNN branch, resulting in a 160-dimensional fused feature vector. This fused feature vector is then integrated through a fully connected layer with 64 neurons, using the ReLU activation function. The output layer is also a fully connected layer, taking the 64-dimensional output of the fusion layer as input and outputting the predicted key consumption amount (scalar value) for a future preset time period. The preset number of relay nodes refers to the number of relay nodes covered by the model input (e.g., 5). Historical key consumption data refers to the hourly consumption sequence of each relay node over a preset duration (e.g., 7 days). The future preset time period refers to the predicted time window (e.g., 1 to 2 hours in the future). The triggering condition and replenishment amount calculation for key replenishment are based on a unified logic of "total demand and available supply comparison": the safety margin refers to the extra key amount reserved to cope with prediction errors, taken as a preset proportion of the predicted key consumption amount (e.g., 10%), i.e., safety margin = predicted key consumption amount × 10%.Total demand = Predicted key consumption + Security margin. When the total demand exceeds the current quantum key pool inventory (i.e., predicted key consumption + security margin > current inventory), it indicates that the currently available keys are insufficient to cover the predicted consumption and security margin, triggering key replenishment. Replenishment amount = Total demand. Current inventory = Predicted key consumption + Security margin The current stock is set, and the replenishment amount is set to max(0, replenishment amount) to ensure that the replenishment amount is not lower than zero. When the total demand does not exceed the current stock (i.e., predicted key consumption + security margin ≤ current stock), it indicates that the currently available keys are sufficient to cover the predicted consumption and security margin, and key replenishment is not triggered, maintaining the current stock level. The design logic of the above triggering condition and replenishment amount formula is as follows: the triggering condition "total demand > current stock" and the replenishment amount formula "replenishment amount = total demand". The "current stock" is mathematically identical—when the triggering condition is met, total demand > current stock, and replenishment = total demand. The current stock is always positive, so replenishment is performed. When the triggering condition is not met, the total demand is less than or equal to the current stock, the replenishment amount is calculated to be zero or negative, and max(0, replenishment amount) is taken as 0, so no replenishment is performed. This ensures that there is no logical contradiction between the triggering condition and the replenishment amount calculation. This application embodiment achieves accurate prediction of key consumption through a prediction model that combines RNN and CNN, which can predict key demand trends in advance and proactively replenish keys, avoiding service interruptions caused by key exhaustion and improving the supply stability and resource utilization of the quantum key pool.

[0051] For example, consider a scenario with insufficient key inventory: A quantum key pool currently has 80MB of key inventory. An RNN / CNN fusion model, using hourly consumption data from five relay nodes over the past seven days as input, predicts key consumption of 90MB for the next two hours. The security margin is 90 × 10% = 9MB, and the total demand is 90 + 9 = 99MB. The system determines that the total demand (99MB) exceeds the current inventory (80MB), triggering key replenishment. The replenishment amount is calculated as max(0, 99...). 80) = 19MB, meaning the system replenishes 19MB of keys from other quantum key pools, bringing the total storage to 99MB, which can cover the predicted consumption of 90MB and the security margin of 9MB.

[0052] According to an embodiment of the present invention, the method for determining the supplementary amount specifically includes: Using the quantum key pool stock and network load as constraints, the key supply rate for the next cycle is calculated using a linear programming algorithm. The fluctuation range of the key supply rate is limited to a preset elastic window. When the calculated supply rate exceeds the elastic window, it is truncated to the window boundary value.

[0053] It is important to emphasize that this embodiment uses a linear programming algorithm to dynamically calculate and flexibly control the key supply rate, avoiding network instability caused by sudden increases or decreases in the rate. The next cycle refers to the calculation cycle of the key supply rate (e.g., 5 minutes), which can be dynamically adjusted. The mathematical model of the linear programming algorithm is as follows: Objective function: Maximize min(supply rate, predicted consumption rate), that is, make the supply rate as close as possible to the predicted consumption rate while satisfying the constraints. Constraints: (1) Supply rate × cycle duration + current stock ≥ predicted consumption + safety margin; (2) Supply rate ≤ maximum rate of key generation device; (3) Supply rate ≥ 0; (4) Network load rate ≤ preset load limit.

[0054] The supply rate refers to the rate at which the quantum key generation device replenishes keys to the key pool per unit time (in KB / s). The predicted consumption rate is the consumption rate per second calculated based on the predicted consumption output of the RNN and CNN fusion model. The current stock refers to the amount of available keys in the key pool at the current moment, and the safety margin refers to the additional amount of keys reserved to cope with prediction errors. The preset elastic window refers to the range within which the supply rate is allowed to fluctuate, with a fluctuation range of ±20% based on the supply rate of the previous cycle. When the supply rate calculated by the linear programming algorithm exceeds the upper limit of the elastic window (i.e., the previous cycle rate × 1.2), it is truncated to the upper limit value; when the calculated supply rate is lower than the lower limit of the elastic window (i.e., the previous cycle rate × 0.8), it is truncated to the lower limit value. This mechanism ensures that the supply rate will not suddenly increase due to sudden demand, nor will it suddenly decrease due to a drop in demand, maintaining the stability of network operation.

[0055] This application embodiment calculates the optimal supply rate by using a linear programming algorithm under the premise of satisfying the existing constraints and network load constraints. It limits the rate fluctuation range by using an elastic window mechanism, thereby achieving adaptive matching of key supply and demand and avoiding network instability caused by sudden rate changes.

[0056] For example, a quantum key pool currently has 60MB of key reserves, a network load rate of 65%, a supply rate of 100KB / s in the previous cycle, and an elastic window of ±20% (i.e., 80KB / s to 120KB / s). The predicted key consumption for the next cycle (5 minutes) is 35MB (equivalent to a consumption rate of approximately 116.7KB / s), with a security margin of 3.5MB. A linear programming algorithm solves this by satisfying: supply rate × 300s + 60MB ≥ 35MB + 3.5MB, i.e., supply rate ≥ (38.5...). Since 60) / 300 < 0, the constraint is automatically satisfied. Maximizing min(supply rate, 116.7), under the constraints of supply rate ≤ maximum device rate 200KB / s and network load rate 65% ≤ 90%, the optimal supply rate is 116.7KB / s. Since 116.7KB / s is within the elastic window [80, 120]KB / s, no truncation is needed, and the final supply rate is 116.7KB / s.

[0057] Furthermore, according to an embodiment of the present invention, the quality of service assurance strategy further includes a master-slave storage dynamic allocation mechanism, specifically: Each relay node is configured with a primary storage and a secondary storage. The primary storage is used to store frequently used local keys, and the secondary storage is used to store backup keys. When a user terminal initiates a key reservation request, the key is allocated in the primary storage through a confirmation-based reservation process, and the allocation status is synchronized to the secondary storage. When the key in the primary storage is insufficient, the backup key is retrieved from the secondary storage, triggering a synchronization update between the primary and secondary storage.

[0058] It is important to emphasize that the master-slave storage dynamic allocation mechanism is a crucial component of this application's service quality assurance strategy, designed to resolve multi-link concurrency conflicts and key duplication issues. Master storage refers to the local, frequently used key storage area set up by each relay node, used to store the quantum keys distributed daily by that node, and possesses high read / write performance. Slave storage refers to the backup key storage area set up by each relay node, used to store mirror backups of the master storage and additional backup keys, providing supplementation when the master storage keys are insufficient. The confirmation-based reservation process means that after a user terminal initiates a key reservation request, the quantum communication service station must return confirmation information before the reservation can be completed, ensuring end-to-end key exchange consistency.

[0059] The master-slave storage mechanism works as follows: Under normal conditions, relay nodes allocate keys to user terminals from the master storage, and each allocation operation is synchronously recorded in the slave storage to maintain data consistency between the master and slave storage. When the number of available keys in the master storage falls below a preset warning threshold (e.g., 20% of the master storage capacity), a key transfer from the slave storage to the master storage is triggered—the spare key in the slave storage is migrated to the master storage. Simultaneously, a complete synchronization update between the master and slave storage is triggered to ensure that the spare key status in the slave storage is consistent with that in the master storage. This mechanism avoids the problem of the same key being repeatedly allocated (because the master and slave storage are synchronized in real time, the allocation status is visible in both storage systems), while also reducing cross-node key transmission (because each node has a local spare key), thus lowering the risk of secret proliferation.

[0060] This application embodiment achieves redundant backup and conflict avoidance of key storage through a master-slave storage dynamic allocation mechanism, ensuring reliable processing of key reservation requests, reducing the difficulty of confidentiality management of relay nodes, and solving the problem of multi-link concurrent conflicts.

[0061] For example, a relay node has a main storage capacity of 100MB, currently available keys of 80MB, a secondary storage capacity of 50MB, and a spare key of 50MB. User terminal A initiates a 10MB key reservation request. After the quantum communication service station returns confirmation, the relay node allocates 10MB of key from the main storage, updating the available main storage capacity to 70MB and synchronizing the allocation status to the secondary storage. User terminal B then initiates a 15MB key reservation request. The relay node continues to allocate 15MB from the main storage, updating the available main storage capacity to 55MB and synchronizing it to the secondary storage.

[0062] Furthermore, according to an embodiment of the present invention, the blockchain evidence storage node adopts a consortium blockchain architecture, specifically including: Billing details, key issuance events, and payment records are used as data for the entire billing process. They are then encrypted using quantum keys by the encryption service module and uploaded to the consortium blockchain node. A unique hash value and timestamp are generated for each billing data. When the proportion of nodes that have failed in the consortium blockchain does not exceed a preset ratio, the billing data is restored through the remaining nodes. Generate hierarchical logs, including user-level logs, system-level logs, and audit-level logs, supporting multi-dimensional traceability by key identifier, time, and user identifier.

[0063] It is important to emphasize that the consortium blockchain architecture is the core design of the secure evidence storage layer in this application, designed to address the single point of failure and data tampering issues inherent in traditional centralized storage. A consortium blockchain refers to a blockchain network jointly maintained by multiple authorized nodes (including user representatives, operators, regulatory bodies, etc.). Unlike the complete openness of public blockchains and the unilateral control of private blockchains, consortium blockchains achieve a balance between decentralization and performance. The aforementioned full-process billing data refers to all key data generated during the quantum key billing process, including billing details (fee breakdown records for each relay node), key issuance events (records of key distribution from the key pool to user terminals), and payment records (user payment amount, payment method, payment time, etc.). The encryption service module uses quantum keys to encrypt the full-process billing data before uploading it to the consortium blockchain nodes, ensuring data confidentiality during transmission and storage. Quantum key encryption ensures zero risk of plaintext leakage; even if an attacker intercepts the encrypted data, they cannot decrypt it. Each billing data entry automatically generates a unique hash value (calculated using hash algorithms such as SHA-256) and a timestamp after being uploaded to the consortium blockchain. The hash value serves as the unique fingerprint of the data for integrity verification, and the timestamp records the precise time the data was uploaded to the blockchain. The preset ratio refers to the upper limit of the proportion of faulty nodes allowed by the consortium blockchain (e.g., 30%). When the proportion of faulty nodes does not exceed 30%, the billing data of the faulty nodes is restored using data copies from the remaining normal nodes, ensuring that no data is lost. Tiered logs are divided into three levels according to users and auditing needs: user-level logs (for end users, recording business data such as bills and usage), system-level logs (for system administrators, recording system operations such as rate adjustments and key distribution), and audit-level logs (for auditors, recording sensitive information such as abnormal operations and security events). It supports multi-dimensional traceability and querying by key identifier (key ID), time (time range), and user identifier (user ID).

[0064] This application implements distributed storage and tamper-proof notarization of billing data through a consortium blockchain architecture, ensures data confidentiality through quantum key encryption, ensures data integrity and traceability through hash values ​​and timestamps, ensures high system availability through a fault tolerance mechanism (data can still be recovered even if 30% of nodes fail), and supports multi-dimensional audit traceability through hierarchical logs. It effectively solves the problems of single point of failure, data tampering, and reconciliation disputes in traditional centralized billing storage.

[0065] For example, a quantum key billing transaction generates a billing detail (total cost 5.6 yuan, including a base fee of 0.5 yuan + loss fee of 1.2 yuan for node A, a base fee of 0.5 yuan + loss fee of 0.8 yuan for node B, and a base fee of 0.2 yuan + loss fee of 2.4 yuan for node C), a key issuance event (issuance time: July 13, 2026, 10:30 AM, issuance amount: 500KB), and a payment record (user ID: U001, payment amount: 5.6 yuan, payment method: digital currency). The encryption service module uses quantum key encryption and uploads it to the 7 nodes of the consortium blockchain. Each piece of data generates a hash value (e.g., SHA-256 hash value a3f8b2c1...) and a timestamp (2026-07-13T10:30:15Z).

[0066] Furthermore, according to an embodiment of the present invention, the quality of service assurance strategy further includes a backpressure flow control mechanism, specifically: Each quantum key distribution node maintains an independent queue for different user streams. Based on the detected stable link capacity, when the queue length exceeds a preset proportion of the stable link capacity, a request restriction instruction is triggered, and new key distribution requests are temporarily rejected. A fair scheduling strategy is used to allocate bandwidth to multiple user streams in a round-robin fashion. When the preset rate management module times out, it automatically switches to a rule-based rate determination strategy to ensure the billing process runs normally.

[0067] It is important to emphasize that the backpressure flow control mechanism is a key design feature for network congestion protection in this application's quality of service assurance strategy. An independent queue refers to a separate request queue maintained by each quantum key distribution node for each user stream (i.e., the key request stream of each user terminal), ensuring that requests from different user streams do not interfere with each other. The stable link capacity refers to the maximum stable transmission rate of the link obtained through the AUTO protocol (Automatic Discovery and Probe Protocol), reflecting the link's carrying capacity under current network conditions. The preset ratio refers to the proportion of the queue length threshold that triggers request limiting to the stable link capacity (e.g., 80%). When the queue length of a user stream exceeds 80% of the stable link capacity, it indicates that the link is about to become congested, and the system triggers a request limiting instruction—temporarily rejecting new key distribution requests from that user stream until the queue length falls back to a safe level.

[0068] A fair scheduling strategy refers to a scheduling mechanism that allocates bandwidth to multiple user flows in a round-robin fashion, ensuring that each user flow receives fair bandwidth resources. Specifically, it allocates a time slice of bandwidth to each user flow sequentially in a round-robin manner, allowing all user flows to take turns receiving service opportunities, thus preventing one flow from monopolizing bandwidth and causing starvation for other flows. When the rate management module times out on real-time rate calculation due to network latency, data anomalies, or other reasons (i.e., the calculation time exceeds a preset timeout threshold, such as 5 seconds), it automatically switches to a rule-based rate determination strategy—that is, using the most recently successfully calculated rate or a preset default rate for billing, ensuring that the billing process is not interrupted due to calculation timeout. This degradation mechanism guarantees the continuous availability of the system under abnormal conditions.

[0069] The "backpressure" in the backpressure flow control mechanism means that when the queue of a downstream node (such as a relay node) is close to full capacity, it sends a "pressure" signal back to the upstream node (such as a quantum communication service station). The upstream node then reduces the rate at which it sends key distribution requests to the downstream node, forming a feedback control loop from downstream to upstream to prevent network congestion from continuing to worsen.

[0070] This application embodiment achieves proactive protection against network congestion through a backpressure flow control mechanism, ensures resource fairness among multiple users through a fair scheduling strategy, and ensures the continuous availability of the system under abnormal conditions through a degradation mechanism for rate calculation timeout, effectively improving the service quality stability of the quantum key pool in high-concurrency scenarios.

[0071] For example, a quantum key distribution node maintains independent queues for three user streams (stream A, stream B, and stream C). The stable link capacity detected by the AUTO protocol is 1000KB / s. At a certain moment, the queue length of stream A is 850KB / s (accounting for 85% of the stable link capacity, exceeding the preset ratio of 80%). The system triggers a request restriction command for stream A, temporarily rejecting new key distribution requests from stream A. At the same time, it uses a fair scheduling strategy to allocate bandwidth to streams B and C in a round-robin fashion—allocating 500KB / s of bandwidth to each stream B and stream C in each time slice (e.g., 100ms). When the queue length of stream A drops back to 700KB / s (below 80%), the request restriction is lifted, and stream A resumes receiving new requests.

[0072] The present invention also discloses a quantum key pool on-demand billing and quality of service assurance system, including a memory and a processor. The memory stores a quantum key pool on-demand billing and quality of service assurance method program. When the quantum key pool on-demand billing and quality of service assurance method program is executed by the processor, it implements the steps of the quantum key pool on-demand billing and quality of service assurance method.

[0073] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0074] The units described above as separate components are not limited to being physically separate, and the components shown as units are not limited to physical units; they can be located in one place or distributed across multiple network units; some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0075] In addition, in the various embodiments of the present invention, each functional unit can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0076] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0077] Alternatively, if the integrated units of this invention are implemented as software functional modules and sold or used as independent products, they can also be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

Claims

1. A method for on-demand billing and quality of service assurance for quantum key pools, characterized in that, Includes the following steps: The quantum key requirement information of the user terminal is obtained through the perception adaptation layer. The quantum key requirement information includes the key quantity, security level and timeliness requirements. Based on the quantum key demand information, a target billing mode is determined by a preset scenario matcher. The target billing mode includes billing based on usage, billing based on routing node consumption, billing based on duration, or package billing. Based on the target billing mode, scenario dimension parameters, load dimension parameters and time dimension parameters are obtained through the preset rate management module, and a three-dimensional dynamic rate adjustment model is constructed to calculate the real-time rate. The key distribution strategy is determined by the preset quantum communication service station based on the real-time rate, and the quantum key is distributed from the quantum key pool in combination with the preset service quality assurance strategy. At the same time, the actual key usage status is collected in real time through the two-chain synchronization mechanism of quantum key chain and billing data chain, and the actual key usage status is synchronized to the billing engine. Based on the actual usage status of the key and the real-time rate, the billing engine performs billing and settlement, generates billing details, and refines the billing details to the relay node level. The billing details are encrypted by the encryption service module and then synchronized to the blockchain evidence storage node to generate an immutable evidence storage record.

2. The quantum key pool on-demand billing and quality of service assurance method according to claim 1, characterized in that, The process of obtaining the user terminal's quantum key requirement information through the perception adaptation layer includes the key requirement quantity, security level, and timeliness requirements, specifically including: The user terminal adaptation module in the perception adaptation layer collects the terminal type identifier and historical usage records of the user terminal. The terminal type identifier includes IoT terminals, financial terminals and government equipment. Based on the terminal type identifier and the historical usage record, the user terminal's key requirement, security level, and timeliness requirements are extracted by the demand identification engine in the perception adaptation layer to generate quantum key requirement information.

3. The quantum key pool on-demand billing and quality of service assurance method according to claim 1, characterized in that, The step of determining the target billing mode based on the quantum key requirement information and through a preset scenario matcher specifically includes: The scenario type is matched using a preset scenario matcher based on the key requirement quantity and security level in the quantum key requirement information; When a user does not have a current billing mode, or when the billing mode corresponding to the scenario type is inconsistent with the user's current billing mode, the scenario matcher determines the billing mode corresponding to the scenario type as the target billing mode. The target billing model is synchronized to the billing engine and linked with historical billing data to ensure the continuity of billing data.

4. The quantum key pool on-demand billing and quality of service assurance method according to claim 1, characterized in that, Based on the target billing mode, the process involves obtaining scenario-dimensional parameters, load-dimensional parameters, and time-dimensional parameters through a preset rate management module, constructing a three-dimensional dynamic rate adjustment model, and calculating the real-time rate. Specifically, this includes: The preset rate management module queries the preset configuration table to obtain scenario-dimensional parameters, including security level rate coefficient and purpose subsidy coefficient. The quantum key chain sends query requests to the quantum key pool and relay nodes to obtain load dimension parameters, including the stock ratio of the quantum key pool and the load rate of the relay nodes. Obtain the current time and compare it with the preset peak and valley time period division table to obtain time dimension parameters, including peak time period identifier and valley time period identifier; The real-time rate is calculated based on scenario-dimensional parameters, load-dimensional parameters, and time-dimensional parameters, using preset rate calculation rules. When the stock ratio of the quantum key pool is higher than the preset high stock threshold or the load rate of the relay node is lower than the preset low load threshold, the preferential rate is triggered. Peak rates are triggered when the stock ratio of the quantum key pool is lower than the preset low stock threshold or the load rate of the relay node is higher than the preset high load threshold. When both the preferential rate and peak rate trigger conditions are met, the result of the relay node load rate determination shall prevail.

5. The quantum key pool on-demand billing and quality of service assurance method according to claim 1, characterized in that, The process involves determining a key distribution strategy based on the real-time rate through a preset quantum communication service station, distributing quantum keys from the quantum key pool in conjunction with a preset quality of service assurance strategy, and simultaneously collecting the actual key usage status in real time through a two-chain synchronization mechanism between the quantum key chain and the billing data chain, and synchronizing the actual key usage status to the billing engine. Specifically, this includes: The real-time rate is compared with the preset rate range by using a preset quantum communication service station. The preset rate range includes a low rate range and a high rate range. When the real-time rate is in the low rate range, the key distribution strategy is determined to be the batch pre-distribution mode; When the real-time rate is in the high rate range, the key distribution strategy is determined to be the on-demand instant distribution mode; Key distribution path is selected based on the load rate of relay nodes; Quantum keys are distributed from the quantum key pool according to the determined key distribution strategy and key distribution path, combined with the quality of service assurance strategy. The quantum key chain collects the key distribution status of quantum communication service stations, quantum key pools and relay nodes in real time as the actual key usage status. The actual key usage status includes the number of keys distributed, the amount of keys consumed, the amount of keys remaining, the distribution timestamp and the relay node identifier, and synchronizes the actual key usage status to the billing engine. By using the billing data chain, the usage logs and pre-allocation records generated by the billing engine during the key distribution process are synchronized in real time to the blockchain storage node, so as to achieve the time sequence consistency between key distribution and original billing data.

6. The quantum key pool on-demand billing and quality of service assurance method according to claim 1, characterized in that, The quality of service assurance strategy includes key request priority allocation based on response weight factors, specifically: Based on the key requirements and security level of the user terminal, the request priority is determined by the response weight factor calculation formula. The response weighting factor is calculated using the following formula: Response weighting factor = Normalized key requirement value × α + (Preset highest security level) Security level) × β, where α and β are preset weighting coefficients; The order of requests and responses is determined by sorting them in ascending order of response weight factors; the smaller the response weight factor, the higher the priority of the request. When the amount of quantum key pool is lower than the preset replenishment threshold, keys are replenished from other quantum key pools during idle time slots.

7. The quantum key pool on-demand billing and quality of service assurance method according to claim 6, characterized in that, The step of replenishing keys from other quantum key pools also includes: A prediction model that combines recurrent neural networks and convolutional neural networks is used as input to output the predicted key consumption for a future preset time period, taking the historical key consumption data of a preset number of relay nodes as input. Based on the predicted key consumption and the current quantum key pool inventory, determine whether to trigger key replenishment and the amount to replenish.

8. The quantum key pool on-demand billing and quality of service assurance method according to claim 7, characterized in that, The method for determining the amount of replenishment specifically includes: Using the quantum key pool stock and network load as constraints, the key supply rate for the next cycle is calculated using a linear programming algorithm. The fluctuation range of the key supply rate is limited to a preset elastic window. When the calculated supply rate exceeds the elastic window, it is truncated to the window boundary value.

9. A quantum key pool on-demand billing and quality of service assurance system, implementing the quantum key pool on-demand billing and quality of service assurance method as described in any one of claims 1-8, characterized in that, include: The perception and adaptation module is used to obtain the quantum key requirement information of the user terminal through the perception and adaptation layer. The quantum key requirement information includes the key requirement quantity, security level and timeliness requirements. The scenario matching module is used to determine the target billing mode based on the quantum key requirement information through a preset scenario matcher. The target billing mode includes billing based on usage, billing based on routing node consumption, billing based on duration, or package billing. The dynamic rate calculation module is used to obtain scenario dimension parameters, load dimension parameters and time dimension parameters through the preset rate management module based on the target billing mode, and to construct a three-dimensional dynamic rate adjustment model to calculate the real-time rate. The key distribution and synchronization module is used to determine the key distribution strategy based on the real-time rate through the preset quantum communication service station, and distribute quantum keys from the quantum key pool in combination with the preset quality of service guarantee strategy. At the same time, it collects the actual key usage status in real time through the two-chain synchronization mechanism of quantum key chain and billing data chain, and synchronizes the actual key usage status to the billing engine. The billing and settlement module is used to perform billing and settlement through the billing engine based on the actual usage status of the key and the real-time rate, and generate billing details, which are refined to the relay node level. The blockchain evidence storage module is used to encrypt the billing details through the encryption service module and synchronize them to the blockchain evidence storage node to generate an immutable evidence storage record.

10. The quantum key pool on-demand billing and quality of service assurance system according to claim 9, characterized in that, The dynamic rate calculation module also includes: The scenario parameter acquisition submodule is used to query the preset configuration table through the preset rate management module to obtain scenario dimension parameters, including security level rate coefficient and purpose subsidy coefficient. The load parameter acquisition submodule is used to obtain load dimension parameters, including the stock ratio of the quantum key pool and the load rate of the relay nodes, by sending query requests to the quantum key pool and relay nodes through the quantum key chain. The time parameter acquisition submodule is used to obtain the current time and compare it with the preset peak and valley time period division table to obtain time dimension parameters, including peak time period identifier and valley time period identifier; The rate calculation submodule is used to calculate the real-time rate based on scenario dimension parameters, load dimension parameters, and time dimension parameters, according to preset rate calculation rules. The rate adjustment submodule is used to trigger a preferential rate when the stock ratio of the quantum key pool is higher than the preset high stock threshold or the relay node load rate is lower than the preset low load threshold, and to trigger a peak rate when the stock ratio of the quantum key pool is lower than the preset low stock threshold or the relay node load rate is higher than the preset high load threshold. When both the preferential rate and peak rate triggering conditions are met, the result of the relay node load rate determination shall prevail.

Images