A graph-computing-oriented optical switch configuration pipeline scheduling method and system

Abstract

The application provides a light switch configuration pipeline scheduling method and system for graph computing, comprising: obtaining a graph computing task optical path configuration request and normalizing processing, and generating standardized configuration request data; decomposing the light switch configuration into four independent processing stages of prediction, verification, configuration and confirmation, configuring corresponding processors, and constructing a pipeline configuration management architecture through an asynchronous message queue; extracting task features to calculate a comprehensive priority and sort, identifying resource dependencies and constraints, detecting resource conflicts, and completing arbitration allocation based on a value function model; clustering historical communication modes, pre-generating a light switch configuration template, and generating a final configuration instruction through pattern matching; and collecting pipeline performance indicators in real time, identifying bottlenecks, and dynamically adjusting resource allocation and scheduling strategies. The application improves the network configuration efficiency and resource utilization rate of the graph computing task, and reduces the configuration delay.

Description

Technical Field

[0001] This invention relates to the field of optical network communication, and in particular to a graph-oriented computation-based optical switch configuration pipeline scheduling method and system. Background Technology

[0002] Optical switching technology, as a key infrastructure for data center network communication, plays a crucial role in data-intensive applications such as graph computing. With the continuous growth in the scale and complexity of graph data, optical switching networks require frequent reconfiguration to adapt to dynamically changing communication needs. The highly dynamic nature of communication patterns in graph data processing, especially in large-scale graph neural network (GNN) training, places higher demands on the configuration efficiency of optical switches.

[0003] Currently, common switch configuration methods in optical networks fall into two categories: centralized configuration and distributed configuration. Centralized configuration involves a central controller managing all optical switch resources, such as an optical path control system based on software-defined networking (SDN). This approach enables global optimization but has a longer configuration response time. Distributed configuration, on the other hand, allows each node to make configuration decisions based on local information, such as an automatic optical path establishment mechanism based on the GMPLS protocol. This approach offers faster response times but struggles to achieve global optimization.

[0004] More advanced optical switch configuration technology employs a request-response model. When a graph computing task requires data transmission, it sends an optical path configuration request to the control system. The control system calculates configuration parameters based on the current network status and sequentially executes operations such as optical switch setup, wavelength allocation, and route confirmation, returning confirmation information upon completion. This method is highly efficient when handling single requests. However, in scenarios with dense concurrent requests, such as graph computing, the serial execution of the configuration process forces subsequent requests to wait for the complete processing of preceding requests, creating a significant processing bottleneck and limiting the scheduling and processing efficiency of computing tasks within the computing network.

[0005] Traditional serial configuration methods have two main technical drawbacks: First, there are time dependencies between the various stages of optical switch configuration. For example, optical path verification must wait for the physical setup of the optical switch to be completed, and requests of different priorities cannot be processed differently, which may cause high-priority graph computation tasks to be delayed due to waiting for the completion of low-priority tasks. Second, for frequently occurring similar graph computation patterns, the entire configuration process needs to be recalculated each time. The lack of a configuration reuse mechanism results in a large number of redundant operations and wasted resources. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a pipeline scheduling method and system for optical switch configuration oriented to graph computing. By decomposing the configuration process into functionally independent processing stages, a pipeline architecture is constructed to achieve parallel processing of multiple requests, breaking through the performance bottleneck of traditional serial configuration. At the same time, technologies such as priority scheduling mechanism, resource conflict arbitration, and configuration instruction pre-compilation are introduced to improve the efficiency of optical switch configuration and meet the dynamic requirements of graph computing tasks for optical network resources.

[0007] To achieve the above objectives, the present invention provides the following technical solution:

[0008] This invention provides a graph-oriented computation-based optical switch configuration pipeline scheduling method, comprising:

[0009] Obtain the optical path configuration request for the graph computing task. The optical path configuration request includes communication requirement parameters, task type identifier, and timestamp. Perform normalization processing on the optical path configuration request to generate standardized configuration request data.

[0010] Based on the standardized configuration request data, the optical switch configuration process is decomposed into four functionally independent processing stages: prediction stage, verification stage, configuration stage, and confirmation stage. A corresponding processor is configured for each processing stage, and data transfer between processors is realized through asynchronous message queues to build a pipeline configuration management architecture.

[0011] Based on the pipeline configuration management architecture, task feature parameters are extracted from the standardized configuration request data, a comprehensive priority score is calculated and the configuration request queue is sorted, the dependencies and constraints between resources are identified, resource conflicts are detected, the conflicting tasks are valued based on the value function model and arbitration decisions are executed, and a resource allocation scheme is generated.

[0012] According to the resource allocation scheme, cluster analysis is performed on the communication patterns of the historical graph calculation task to identify recurring communication patterns. Optical switch configuration templates are pre-generated for the recurring communication patterns. Pattern matching is performed on the input configuration requests. When a match is successful, the configuration instruction is invoked to generate the final configuration instruction.

[0013] Based on the final configuration instructions, the performance indicators of each stage of the pipeline are collected in real time, the stage with the lowest processing capacity is identified as the pipeline bottleneck, and the resource allocation ratio and scheduling strategy parameters of each stage are dynamically adjusted to obtain an optimized pipeline configuration management architecture.

[0014] Furthermore, based on the standardized configuration request data, the optical switch configuration process is decomposed into four functionally independent processing stages: prediction, verification, configuration, and confirmation. A corresponding processor is configured for each processing stage, and data transfer between processors is achieved through asynchronous message queues, constructing a pipelined configuration management architecture, including:

[0015] Based on the standardized configuration request data, the communication requirements of the graph computing task are analyzed. A prediction processor is configured and a first computing resource and a first cache space are allocated for the prediction stage. The prediction processor is used to generate a preliminary optical path plan. A verification processor is configured and a second computing resource and a second cache space are allocated for the verification stage. The verification processor is used to check the feasibility and resource availability of the preliminary optical path plan. A processor is configured and a third computing resource and a third cache space are allocated for the configuration stage. The configuration processor is used to execute hardware setting instructions. A verification processor is configured and a fourth computing resource and a fourth cache space are allocated for the confirmation stage. The verification processor is used to detect whether the configuration is successful, resulting in four processors and their corresponding resource configurations.

[0016] Based on the four processors and their corresponding resource configurations, a first asynchronous message queue is configured between the prediction processor and the verification processor, a second asynchronous message queue is configured between the verification processor and the configuration processor, and a third asynchronous message queue is configured between the configuration processor and the confirmation processor. A request description format is designed, which includes a request identifier, optical path parameters, priority flags, and timestamps, thus obtaining an asynchronous communication mechanism.

[0017] Based on the asynchronous communication mechanism, after the prediction processor completes the processing of a configuration request, it encapsulates the processing result into a message conforming to the request description format and places it into the first asynchronous message queue. The prediction processor then begins processing the next configuration request. The verification processor retrieves the message from the first asynchronous message queue, verifies it, and places the verification result into the second asynchronous message queue. The configuration processor retrieves the verification result from the second asynchronous message queue, configures it, and places the configuration result into the third asynchronous message queue. The confirmation processor retrieves the configuration result from the third asynchronous message queue and confirms it. This enables parallel processing of multiple configuration requests in four stages, resulting in the pipelined configuration management architecture.

[0018] Furthermore, based on the aforementioned asynchronous communication mechanism, multiple configuration requests are processed in parallel across four stages, including:

[0019] Based on the asynchronous communication mechanism, the prediction processor obtains a first configuration request from the configuration request queue, parses the communication requirement parameters of the first configuration request, generates a first preliminary optical path plan, encapsulates the first processing result containing the first preliminary optical path plan into a first message conforming to the request description format and puts it into the first asynchronous message queue, the prediction processor obtains a second configuration request and starts generating a second preliminary optical path plan, thus obtaining the first stage of parallel processing;

[0020] According to the first stage of parallel processing, the verification processor retrieves the first message from the first asynchronous message queue, extracts the first preliminary optical path plan, checks the feasibility and resource availability of the first preliminary optical path plan, generates the first verification result and encapsulates it into the second message and puts it into the second asynchronous message queue. At the same time, the prediction processor continues to process the second configuration request, realizing the parallel execution of the prediction processor and the verification processor, and obtaining two-stage parallel processing.

[0021] Based on the two-stage parallel processing, the configuration processor retrieves the second message from the second asynchronous message queue, extracts the first verification result, executes hardware setting instructions based on the first verification result, generates a first configuration result, and encapsulates it into a third message and places it into the third asynchronous message queue. The confirmation processor retrieves the third message from the third asynchronous message queue, extracts the first configuration result, and detects the configuration success condition. This enables four processors to process different stages of different configuration requests simultaneously, resulting in a complete parallel processing mechanism.

[0022] Further, the step of extracting task feature parameters from the standardized configuration request data based on the pipeline configuration management architecture and calculating a comprehensive priority score includes:

[0023] Based on the pipeline configuration management architecture, the task type, computation priority, time urgency, and resource requirement are extracted from the standardized configuration request data. The task types are classified into real-time tasks and batch processing tasks. A first type weight is assigned to the real-time tasks, and a second type weight is assigned to the batch processing tasks. The computation priority, time urgency, and resource requirement are quantified to obtain priority scores, urgency scores, and requirement scores, thus obtaining multi-dimensional evaluation parameters.

[0024] Based on the multi-dimensional evaluation parameters, the comprehensive priority score is calculated using a weighted summation algorithm. The comprehensive priority score is equal to the weighted sum of the first type weight or the second type weight, the priority score, the urgency score, and the demand score.

[0025] Furthermore, the calculation of the comprehensive priority score and the sorting of the configuration request queue includes:

[0026] Based on the comprehensive priority score, all configuration requests in the configuration request queue are sorted from high to low according to the comprehensive priority score to obtain a pre-sorted configuration request queue.

[0027] Based on the pre-sorted configuration request queue, a preemptive queue-jumping mechanism is provided for the real-time tasks. When a new real-time task arrives and its corresponding comprehensive priority score is higher than the task waiting in the queue, the new real-time task is inserted at the head of the queue. A batch processing mechanism is provided for the batch processing tasks. When the processor resource utilization is lower than a preset idle threshold, multiple batch processing tasks are combined into a batch for processing, resulting in a configuration request queue with differentiated scheduling.

[0028] Based on the differentiated scheduling configuration request queue, the waiting time of each configuration request is monitored, and tasks with a comprehensive priority score lower than a preset priority threshold in the differentiated scheduling configuration request queue are identified as tasks to be promoted. When the waiting time of a task to be promoted exceeds the preset waiting threshold, the comprehensive priority score of the task to be promoted is dynamically increased. The increase in the comprehensive priority score is proportional to the waiting time, resulting in a sorted configuration request queue.

[0029] Furthermore, the process of identifying dependencies and constraints between resources, detecting resource conflicts, evaluating the value of conflicting tasks based on a value function model, executing arbitration decisions, and generating resource allocation schemes includes:

[0030] Based on the sorted configuration request queue, the optical switch network topology is obtained, the wavelength resources, port resources and optical path resources in the optical switch network topology are identified, the dependencies between resources are analyzed, and the constraints are determined, including that the same port cannot be allocated to multiple optical paths at the same time, the same wavelength on the same optical fiber cannot be used by multiple optical paths at the same time, and the establishment of an optical path requires that the source port and the target port are available at the same time, thus obtaining a resource dependency model.

[0031] Based on the resource dependency model, a resource occupancy matrix is ​​constructed. The rows of the resource occupancy matrix correspond to configuration requests, the columns correspond to resources, and the matrix elements represent the occupancy status, including unoccupied, occupied, and reserved states. Based on the resource occupancy matrix, a resource maintenance availability time window is established. The availability time window records the resource occupancy status of each time slice from the current moment to a preset future time period. When a new configuration request arrives, the target resource required by the new configuration request is extracted, and the occupancy status of the target resource in the resource occupancy matrix and the availability time window is queried. When the occupancy status of the target resource is occupied or reserved, it is identified as a resource conflict, and a resource conflict detection result is obtained.

[0032] Based on the resource conflict detection results, the value function model is constructed. The value function model comprehensively considers latency tolerance, computation priority, and historical waiting time. For configuration requests with resource conflicts, the latency tolerance, computation priority, and historical waiting time are extracted. The task value score is calculated according to the value function model. The task value scores of multiple configuration requests with resource conflicts are compared. The configuration request with the highest task value score is selected to be allocated the target resource first. The remaining configuration requests are reallocated or delayed to obtain the resource allocation scheme.

[0033] Furthermore, after evaluating the value of the conflict task based on the value function model and executing arbitration decisions to generate the resource allocation scheme, the process further includes:

[0034] Based on the resource allocation scheme, the optical switch configuration operation is performed, the configuration execution result is monitored, and when a configuration failure is detected, failure data containing failure type, occurrence stage, associated resources and environmental parameters is captured. The failure data is then structured and integrated with device logs, performance indicators and topology status to obtain multimodal failure data.

[0035] Based on the multimodal failure data, data mining algorithms are applied to identify recurring failure patterns and construct a failure association graph. The failure association graph displays the causal relationships and temporal dependencies between different failure events. Cluster analysis is performed on the multimodal failure data to obtain a failure pattern library.

[0036] Based on the failure mode library, extract the current feature vector for the current failure event, calculate the similarity between the current feature vector and the feature vectors of each failure mode category in the failure mode library, select the failure mode category with the highest similarity as the matching failure case, extract the historical recovery path and success rate of the matching failure case, select the historical recovery path with the highest success rate as the target recovery path, the target recovery path includes resource reallocation, configuration parameter adjustment and alternative optical path selection, and obtain a backtracking decision scheme;

[0037] Based on the backtracking decision scheme, the recovery operation in the target recovery path is executed, the recovery process and recovery result are recorded, and when the recovery result meets the preset recovery success conditions, the backtracking decision scheme is added to the failure handling knowledge base, the success rate statistics of the matching failure cases in the failure mode library are updated, and the updated failure mode library is obtained.

[0038] Furthermore, the applied data mining algorithm identifies recurring failure patterns and constructs a failure association graph. This graph displays the causal relationships and temporal dependencies between different failure events. Cluster analysis is then performed on the multimodal failure data to obtain a failure pattern library, including:

[0039] Based on the multimodal failure data, feature vectors of failure events are extracted. The feature vectors include the failure occurrence time, failure stage identifier, resource identifier, system load status, and configuration parameter values. The feature vectors are encoded by encoding the failure stage identifier as a numerical value, encoding the resource identifier as a resource type code, and quantifying the system load status as a load percentage to obtain the encoded feature vectors.

[0040] Based on the encoded feature vectors, the Apriori association rule mining algorithm is applied, a minimum support threshold and a minimum confidence threshold are set, the association relationship between the encoded feature vectors is analyzed, the support and confidence of each feature combination are calculated, and feature combinations whose support and confidence both exceed the minimum support threshold and the minimum confidence threshold are identified as repeated co-occurring failed feature combinations, thus obtaining the failure mode feature set;

[0041] Based on the failure mode feature set, a directed graph structure is constructed. Each failure event in the failure mode feature set is used as a node. The failure occurrence time of the failure event is extracted. When the failure occurrence time of the first failure event is earlier than the failure occurrence time of the second failure event and the time difference is less than a preset time window, a temporal dependency edge from the first failure event to the second failure event is established. When the resource identifier involved in the first failure event is a precondition of the second failure event, a causal relationship edge is established to obtain the failure association graph.

[0042] Based on the failure association graph, the Louvain graph clustering algorithm is applied to identify modular communities in the failure association graph. Each modular community corresponds to a failure mode category. A mode description is generated for each failure mode category to obtain the failure mode library.

[0043] Furthermore, based on the standardized configuration request data, the optical switch configuration process is decomposed into four functionally independent processing stages: prediction, verification, configuration, and confirmation. The prediction stage generates a preliminary optical path plan by analyzing the communication requirements of the task through a prediction processor's graph calculation, including:

[0044] Based on the standardized configuration request data, the prediction processor parses the communication requirement parameters, extracts the source node, target node, bandwidth requirement and latency requirement, obtains the current optical network topology status and resource availability information, and generates network status data.

[0045] Based on the network state data, a heuristic search algorithm is applied to generate multiple candidate optical path configuration schemes. Each candidate optical path configuration scheme includes an optical path, wavelength allocation, and port allocation. The performance indicators of each candidate optical path configuration scheme are calculated, including estimated latency, resource consumption, and path hop count, to generate a candidate scheme set.

[0046] Based on the candidate scheme set, a multi-dimensional scheme evaluation framework is constructed to score each candidate optical path configuration scheme from the perspectives of throughput, latency, and resource efficiency. The candidate optical path configuration scheme with the highest score is selected as the preliminary optical path planning, and prediction stage output data is generated.

[0047] Based on the output data of the prediction stage, during the configuration process of the prediction processor, the deviation between the actual configuration effect and the prediction result is monitored in real time. When the deviation exceeds a preset threshold, the configuration parameter fine-tuning is triggered to dynamically adjust the wavelength allocation or path selection in the preliminary optical path planning, so as to obtain the self-corrected optical path planning.

[0048] Furthermore, based on the candidate scheme set, a multi-dimensional scheme evaluation framework is constructed to score each candidate optical path configuration scheme from the perspectives of throughput, latency, and resource efficiency. The candidate optical path configuration scheme with the highest score is selected as the preliminary optical path planning, including:

[0049] Based on the candidate scheme set, a throughput score is calculated for each candidate optical path configuration scheme, the throughput score being based on the maximum data transmission rate that the candidate optical path configuration scheme can support; a latency score is calculated, the latency score being based on the end-to-end transmission latency of the candidate optical path configuration scheme; and a resource efficiency score is calculated, the resource efficiency score being based on the number of wavelengths and ports occupied by the candidate optical path configuration scheme, generating multi-dimensional scoring data.

[0050] Based on the multi-dimensional scoring data, a comprehensive score is calculated for each candidate optical path configuration scheme. The comprehensive score is a weighted sum of the throughput score, the latency score, and the resource efficiency score. All candidate optical path configuration schemes are sorted according to the comprehensive score to generate a scoring ranking result.

[0051] Based on the scoring and ranking results, an automatic stopping condition is set. The automatic stopping condition includes the difference between the comprehensive score of the current optimal solution and the comprehensive score of the second-best solution being greater than a preset improvement threshold, or the search time exceeding the time budget determined according to the task type. When the automatic stopping condition is met, the solution search is stopped, and the candidate optical path configuration scheme with the highest comprehensive score in the scoring and ranking results is selected as the preliminary optical path planning to obtain the prediction stage output data.

[0052] Furthermore, before calculating the comprehensive priority score by extracting task feature parameters from the standardized configuration request data according to the pipeline configuration management architecture, the process also includes:

[0053] Based on the standardized configuration request data and historical configuration data, a causal graph model for optical network resource allocation is constructed. The causal graph model includes causal variable nodes and causal relationship edges. The causal variable nodes include task priority, resource availability, network load, and configuration success rate. Variable values ​​are extracted from the historical configuration data, and causal relationship parameters are learned by applying structural equation modeling to obtain a causal knowledge base.

[0054] Based on the causal knowledge base, for the input configuration request, the causal inference engine is applied to calculate the impact of different priority assignments on the configuration success rate based on the causal graph model. Causal variable nodes directly related to the configuration success rate are extracted from the causal graph model. The causal effect strength of each causal variable node on the configuration success rate is calculated. The causal variable node with the strongest causal effect strength is identified as the key causal factor, and the causal analysis results are obtained.

[0055] Based on the causal analysis results, the weight coefficients of the task feature parameters in the calculation of the comprehensive priority score are adjusted according to the key causal factors, and a decision boundary representation model is constructed. The decision boundary representation model defines the effective value range of the comprehensive priority score. When the network load status changes, the decision boundary of the decision boundary representation model is adjusted through a causal intervention mechanism to obtain an optimized priority evaluation model.

[0056] Further, after adjusting the weight coefficients of the task feature parameters in the comprehensive priority score calculation based on the key causal factors and constructing the decision boundary representation model, the process includes:

[0057] Based on the decision boundary representation model, within the effective range of the comprehensive priority score, the optimization problem of the weight coefficients is modeled as a constrained optimization problem. The objective function is to maximize the configuration success rate, and the constraint condition is that the sum of the weight coefficients is 1 and all are greater than 0. The optimal weight combination is solved iteratively by applying the optimization algorithm, and the weight coefficients in the optimized priority evaluation model are updated to obtain the updated priority evaluation model.

[0058] Based on the updated priority evaluation model, at preset intervals, the system throughput, average latency, and configuration success rate before and after adopting the causal intervention mechanism are compared to calculate the performance improvement percentage. When the performance improvement percentage is lower than a preset validity threshold, the causal inference engine is re-executed, the causal effect strength is recalculated based on the causal graph model, the key causal factors are updated, the values ​​of the causal variable nodes set in the causal intervention mechanism are adjusted, and the effective value range of the comprehensive priority score is updated to obtain a continuously optimized priority evaluation model.

[0059] Further, the step of performing cluster analysis on the communication patterns of historical graph calculation tasks according to the resource allocation scheme, identifying recurring communication patterns, and pre-generating optical switch configuration templates for the recurring communication patterns includes:

[0060] Based on the resource allocation scheme, communication pattern data of historical graph computing tasks are collected from historical configuration records. The communication pattern data includes computing type, data flow topology, communication node pairs and traffic characteristics. Feature vectors of the communication pattern data are extracted, and clustering algorithms are applied to perform cluster analysis on the feature vectors to identify the communication patterns corresponding to the cluster centers, thereby obtaining a graph computing pattern feature library.

[0061] Based on the graph computing pattern feature library, an optical switch configuration process is executed for each communication pattern identified in the graph computing pattern feature library. The optical path planning parameters generated in the prediction stage, the resource check results in the verification stage, the hardware setting instructions in the configuration stage, and the verification steps in the confirmation stage are recorded. The optical path planning parameters, the resource check results, the hardware setting instructions, and the verification steps are encapsulated into an optical switch configuration template. Applicable condition tags and resource requirement descriptions are added to the optical switch configuration template to obtain a configuration template library.

[0062] Based on the configuration template library, a multi-dimensional index structure is established. When a new configuration request is received, the calculation type, data flow topology, and traffic characteristics of the new configuration request are extracted. The multi-dimensional index structure is used to search the configuration template library. The feature similarity between the new configuration request and each optical switch configuration template in the configuration template library is calculated. The optical switch configuration template with the highest feature similarity is selected as the matching configuration template to obtain the matching result.

[0063] Based on the matching result, the actual parameters of the new configuration request are extracted, and the actual parameters are used to replace the parameter placeholders in the matched configuration template. It is verified whether the replaced optical path planning parameters are available in the current network topology, and whether the replaced resource check results conflict with the current resource status. When the verification is successful, the final configuration instruction is generated based on the matched configuration template.

[0064] Furthermore, based on the final configuration instruction, the process of collecting performance indicators of each stage of the pipeline in real time, identifying the stage with the lowest processing capacity as the pipeline bottleneck, and dynamically adjusting the resource allocation ratio and scheduling strategy parameters of each stage includes:

[0065] Based on the final configuration instruction, the entry time, start time and completion time of each configuration request at each stage are recorded in real time. The processing time is calculated, and the average processing time is calculated as the average processing time. The length changes of the waiting queue at each stage are monitored to obtain performance monitoring data.

[0066] Based on the performance monitoring data, the processing capacity of each stage is calculated. The processing capacity is defined as the number of configuration requests completed per unit time. The processing capacity of each stage is compared, and the stage with the smallest processing capacity is identified as the potential bottleneck stage. The waiting queue length of the potential bottleneck stage is analyzed. When the waiting queue length of the potential bottleneck stage continues to increase within a consecutive preset time window, the potential bottleneck stage is confirmed as the pipeline bottleneck, and the bottleneck identification result is obtained.

[0067] Based on the bottleneck identification results, a performance bottleneck model is constructed. The performance bottleneck model quantifies the impact of the pipeline bottleneck on the overall system throughput. Through simulation experiments, the processing capacity of the pipeline bottleneck is increased by a preset percentage. The overall system throughput after the increase is evaluated, and a bottleneck analysis report is obtained.

[0068] Based on the bottleneck analysis report, an optimization strategy is determined, the resource allocation ratio of the bottleneck stage of the pipeline is dynamically adjusted, the scheduling strategy parameters are adjusted, and the optimized pipeline configuration management architecture is obtained.

[0069] The present invention also provides a graph-oriented computational optical switch configuration pipeline scheduling system, comprising:

[0070] The configuration request processing module is used to obtain the optical path configuration request of the graph computing task. The optical path configuration request includes communication requirement parameters, task type identifier and timestamp. The module performs normalization processing on the optical path configuration request to generate standardized configuration request data.

[0071] The pipeline architecture building module is used to decompose the optical switch configuration process into four functionally independent processing stages—prediction, verification, configuration, and confirmation—based on the standardized configuration request data. A corresponding processor is configured for each processing stage, and data transfer between processors is achieved through an asynchronous message queue, thereby building a pipeline configuration management architecture.

[0072] The resource scheduling arbitration module is used to extract task feature parameters from the standardized configuration request data according to the pipeline configuration management architecture, calculate the comprehensive priority score and sort the configuration request queue, identify the dependencies and constraints between resources, detect resource conflicts, evaluate the value of conflicting tasks based on the value function model and execute arbitration decisions, and generate a resource allocation scheme.

[0073] The configuration template generation module is used to perform cluster analysis on the communication patterns of historical graph calculation tasks according to the resource allocation scheme, identify recurring communication patterns, pre-generate optical switch configuration templates for the recurring communication patterns, perform pattern matching on the input configuration requests, and call the configuration instruction when the matching is successful to generate the final configuration instruction.

[0074] The performance optimization and adjustment module is used to collect performance indicators of each stage of the pipeline in real time based on the final configuration instruction, identify the stage with the lowest processing capacity as the pipeline bottleneck, and dynamically adjust the resource allocation ratio and scheduling strategy parameters of each stage to obtain an optimized pipeline configuration management architecture.

[0075] Compared with the prior art, the advantages of the present invention are:

[0076] 1. The optical switch configuration process is decomposed into four independent stages: prediction, verification, configuration, and confirmation. A pipeline architecture is built to achieve parallel processing of multiple requests, breaking through the performance bottleneck of traditional serial configuration.

[0077] 2. Design a priority scheduling mechanism based on multi-dimensional evaluation to support queue processing of high-priority graph computation tasks and batch processing of low-priority tasks, thereby achieving differentiated services;

[0078] 3. Construct a task value function model that comprehensively considers factors such as latency tolerance, computation priority, and historical waiting time to make optimal allocation decisions when resource conflicts occur;

[0079] 4. Develop a pre-compilation and template mechanism for configuration instructions, and directly call pre-stored templates for recurring graph computation patterns to reduce configuration computation overhead;

[0080] 5. Achieve real-time monitoring and adaptive optimization of pipeline status, dynamically adjust resource allocation and processing strategies at each stage, and maintain optimal system performance. Attached Figure Description

[0081] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0082] Figure 1 A flowchart illustrating the graph-oriented computation-based optical switch configuration pipeline scheduling method provided by this invention.

[0083] Figure 2 This invention provides a flowchart illustrating the optimization of configuration request queue sorting and scheduling based on comprehensive priority.

[0084] Figure 3 This invention provides a schematic diagram of the structure of an optical switch configuration pipeline scheduling system for graph-oriented computation. Detailed Implementation

[0085] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0086] Example 1

[0087] like Figure 1 As shown, this invention provides a graph-oriented computational method for pipelined scheduling of optical switch configuration, comprising:

[0088] Step S1: Obtain the optical path configuration request for the graph computing task. The optical path configuration request includes communication requirement parameters, task type identifier and timestamp. The optical path configuration request is normalized to generate standardized configuration request data.

[0089] Step S2: Based on the standardized configuration request data, the optical switch configuration process is decomposed into four functionally independent processing stages: prediction stage, verification stage, configuration stage, and confirmation stage. A corresponding processor is configured for each processing stage, and data transfer between processors is realized through asynchronous message queues to build a pipeline configuration management architecture.

[0090] Step S3: Based on the pipeline configuration management architecture, extract task feature parameters from the standardized configuration request data, calculate the comprehensive priority score and sort the configuration request queue, identify the dependencies and constraints between resources, detect resource conflicts, evaluate the value of conflicting tasks based on the value function model and execute arbitration decisions, and generate a resource allocation scheme.

[0091] Step S4: According to the resource allocation scheme, perform cluster analysis on the communication patterns of the historical graph calculation task, identify the recurring communication patterns, pre-generate optical switch configuration templates for the recurring communication patterns, perform pattern matching on the input configuration requests, and call the configuration instruction when the matching is successful to generate the final configuration instruction.

[0092] Step S5: Based on the final configuration instruction, collect the performance indicators of each stage of the pipeline in real time, identify the stage with the lowest processing capacity as the pipeline bottleneck, dynamically adjust the resource allocation ratio and scheduling strategy parameters of each stage, and obtain the optimized pipeline configuration management architecture.

[0093] Specifically, first, optical path configuration requests for graph computing tasks are obtained. These configuration requests originate from graph computing applications that require large-scale data processing and analysis, such as social network analysis, knowledge graph processing, and scientific computing. Each optical path configuration request contains three core types of information: communication requirement parameters, task type identifier, and timestamp. The communication requirement parameters detail the technical requirements of the network connection, including source and target node identifiers, bandwidth requirements (usually in Gbps), latency requirements (in milliseconds), connection duration, and quality of service level. These parameters define the basic network performance metrics that the optical path must meet.

[0094] The task type identifier indicates the type of graph computation task to which the configuration request belongs, such as graph traversal, shortest path computation, community detection, or graph clustering. Different types of graph computation tasks have different communication characteristics and resource sensitivities; task type information helps the system understand the context and priority of the request. The timestamp records the generation time and expected execution time of the configuration request, providing a time-dimensional reference for scheduling decisions. The system receives these configuration requests through network service interfaces or message queues, ensuring reliable delivery and unified management of requests.

[0095] After obtaining configuration requests, they are normalized, converting requests from different sources and formats into standardized configuration request data. Normalization includes three stages: format unification, parameter validation, and information supplementation. Format unification converts various input formats (such as JSON, XML, or binary formats) into the system's internal standard data structure, ensuring consistency in subsequent processing. Parameter validation checks the completeness and validity of request parameters, such as verifying the existence of node identifiers and whether bandwidth requirements are within the system's supported range, filtering out invalid requests and improving system reliability.

[0096] Information supplementation is based on the basic information of the request, automatically adding missing parameters and context information using the system knowledge base. For example, it automatically sets default service quality parameters based on the task type, or infers unspecified latency requirements based on historical data. Through these three steps, standardized configuration request data with a complete structure and uniform format is generated, laying the foundation for subsequent pipeline processing. The standardized data is stored using an optimized in-memory structure, which facilitates fast access and modification, and supports efficient serialization and deserialization, adapting to the processing needs of each stage of the pipeline.

[0097] Based on standardized configuration request data, an innovative pipelined configuration management architecture was designed and built. The core idea of ​​this pipelined architecture is to decompose the complex optical switch configuration process into multiple functionally independent, sequentially executed processing stages. Each stage focuses on a specific function, achieving parallelization and specialization of processing. The optical switch configuration process is decomposed into four key stages: prediction, verification, configuration, and confirmation, each undertaking different processing responsibilities.

[0098] The prediction phase is responsible for analyzing communication requirements and generating preliminary optical path planning schemes. This phase receives standardized configuration request data, combines it with network topology information and resource status, and uses path calculation algorithms to generate candidate optical path schemes that meet the requirements. The prediction processor considers various factors, such as link capacity, latency characteristics, and wavelength availability, to optimize path selection and resource allocation, ensuring that the generated schemes both meet communication requirements and achieve efficient resource utilization.

[0099] The verification phase is responsible for checking the feasibility and compliance of the prediction scheme. The verification processor receives the optical path scheme output from the prediction phase and performs resource conflict detection, constraint verification, and performance estimation. This phase ensures that the allocated resources are actually available, the scheme complies with system policies and technical limitations, and the expected performance meets the requirements. If verification finds problems, the verification processor generates a detailed error report and feeds it back to the prediction phase for scheme adjustment.

[0100] The configuration phase is responsible for translating the validated scheme into specific device configuration instructions. The configuration processor analyzes the scheme details and generates command sequences suitable for specific devices and protocols, such as wavelength setting, switching matrix configuration, and connection establishment. These instructions use device-recognizable formats and syntax to ensure correct execution by network devices. The configuration processor also considers the order and dependencies of operations, optimizing the instruction sequence to reduce configuration latency and error risks.

[0101] The verification phase is responsible for validating the actual effectiveness of the configuration, ensuring successful optical path establishment and achieving the expected performance. The verification processor assesses configuration completion and service quality by monitoring device status, analyzing performance data, and executing test traffic. If configuration failures or substandard performance are detected, the verification processor initiates a recovery process, including problem diagnosis, configuration rollback, or alternative solution trials, to ensure final service quality.

[0102] To achieve efficient collaboration among these four stages, each processing stage is configured with an independent processor, which may be dedicated hardware, a virtual machine, or a container instance, flexibly allocated according to processing needs and resource availability. Data is transferred between processors via asynchronous message queues. This loosely coupled communication mechanism has three key advantages: First, it supports independent processor operation and load balancing, allowing each stage to adjust its workload based on its own processing speed and queue conditions; second, it provides a natural buffering mechanism, smoothing out differences in processing speed and improving overall throughput; and finally, it simplifies error handling and recovery mechanisms, ensuring that when a processor fails, messages remain in the queue and can be processed by the recovered or backup processor.

[0103] The asynchronous message queue is implemented using high-performance message middleware, such as RabbitMQ, Kafka, or a custom in-memory queue, selected based on system size and performance requirements. Queue configuration considers message priority, timeout mechanisms, and persistence strategies to ensure critical requests are processed first, long-unprocessed requests are detected and addressed, and system recovery capabilities are maintained after crashes. Through this carefully designed pipelined architecture, the system achieves high concurrency, high throughput, and high reliability in configuration processing, providing robust network configuration support for complex graph computation tasks.

[0104] Based on the pipeline architecture, an intelligent priority assessment and resource allocation mechanism is implemented. First, task characteristic parameters are extracted from standardized configuration request data, including task type, data size, time sensitivity, and resource requirement characteristics. These characteristic parameters reflect the business characteristics and resource demand patterns of the configuration requests and are crucial for priority assessment. A multi-dimensional scoring model is employed to calculate a comprehensive priority score for each configuration request, considering factors such as task importance, urgency, resource efficiency, and service commitment, generating a standardized score from 0 to 100.

[0105] Priority calculation employs a weighted summation method, assigning different weights to different feature parameters based on their importance. These weights can be dynamically adjusted according to system strategies and business needs. For example, for real-time analytics tasks, the weight of time sensitivity might be increased; for critical business applications, the weight of task importance might be increased. Based on the calculated priority scores, the configuration request queue is sorted, with higher-priority requests receiving processing and network resources first, ensuring the quality of service for critical tasks.

[0106] The sorting process incorporates a starvation prevention mechanism by introducing waiting time into the priority calculation, ensuring that low-priority requests are not postponed indefinitely. The priorities of requests in the queue are periodically recalculated; when a request's waiting time exceeds a threshold, its priority is gradually increased until it receives a processing opportunity, thus balancing the needs of efficiency and fairness.

[0107] Based on priority ranking, the system performs in-depth resource analysis and allocation. First, it identifies the dependencies and constraints between resources, constructing a resource constraint graph model. This model captures the interdependencies and usage limitations of resources such as wavelength channels, switching ports, and optical amplifiers, providing a complete view for resource allocation. Based on the constraint graph model, the system detects potential resource conflicts. When multiple requests compete for the same resource, the system identifies the conflict points and prepares an arbitration decision.

[0108] Resource conflict detection employs a multi-level checking strategy: First, a rapid resource pre-occupancy check is performed to filter out obvious conflicts; then, a detailed spatiotemporal conflict analysis is conducted on potentially feasible solutions, considering factors such as time overlap, space sharing, and performance interference; finally, fine-grained configuration parameter verification is performed to ensure that all technical constraints are met. This multi-level detection strategy ensures comprehensive detection while avoiding unnecessary computational overhead, thus improving detection efficiency.

[0109] When resource conflicts are detected, the conflicting tasks are valued based on a value function model. The value function considers various factors, such as request priority, resource requirements, configuration complexity, expected service duration, and business impact, calculating a comprehensive value score for each request. An arbitration decision is then made based on the value assessment results, typically prioritizing resource allocation to the task with the highest value, while alternative solutions or rescheduling are sought for other tasks.

[0110] Arbitration decisions are not simple binary choices, but rather solutions that seek to maximize overall value. The system may employ strategies such as time-sharing resource reuse, dynamic bandwidth adjustment, or path replanning to attempt to meet the needs of high-value tasks while simultaneously satisfying the basic requirements of other tasks, thus achieving efficient resource sharing. Through these intelligent evaluation and decision-making mechanisms, a balanced and efficient resource allocation scheme is generated, ensuring both the quality of service for critical tasks and maximizing resource utilization.

[0111] Based on the generated resource allocation scheme, an innovative communication pattern recognition and configuration template pre-generation mechanism was implemented. In-depth analysis of communication patterns in historical graph computation tasks was conducted. By extracting communication features and applying clustering algorithms to classify a large amount of historical data, frequently occurring communication patterns were identified. Multiple communication features were considered, such as topology (star, ring, grid, etc.), traffic characteristics (burst, stable, periodic, etc.), bandwidth demand distribution, and latency sensitivity, to construct multi-dimensional feature vectors that support fine-grained pattern differentiation.

[0112] Cluster analysis employs improved K-means or DBSCAN algorithms to group communication instances based on the similarity of feature vectors, forming distinct communication pattern categories. Analyzing the clustering results identifies frequently occurring communication patterns, which typically represent common communication needs in graph computing tasks, such as "large-scale data broadcasting," "neighborhood information exchange," and "central node aggregation."

[0113] For recurring communication patterns identified, optical switch configuration templates are pre-generated. A configuration template is a parameterized set of configuration instructions, containing the framework of path planning, resource allocation, and control instructions required to implement a specific communication pattern. However, key parameters (such as specific nodes and wavelength selection) are retained as variables, to be replaced upon actual request. The process of pre-generating templates involves the system pre-executing a complete configuration pipeline, recording the decisions and outputs at each stage, and forming a reusable template structure, significantly reducing the computational burden of real-time configuration.

[0114] The template generation process considers various scenarios, creating multiple variant templates for the same communication mode suitable for different network states and resource conditions, thus improving the template's applicability and success rate. All generated templates are organized into a structured template library, supporting efficient indexing and querying for easy real-time use. Metadata tags, such as applicable conditions, resource requirements, and performance characteristics, are added to each template to help the system quickly select suitable templates.

[0115] When a new configuration request is input into the system, communication pattern matching is first performed, attempting to compare the request characteristics with known communication patterns. The matching process uses feature vector similarity calculation, combined with template applicability criteria, to evaluate whether the request meets the application conditions of existing templates. When a highly matching pattern is found, the system selects the corresponding configuration template and replaces the variables in the template with the actual parameters from the request, quickly generating customized configuration instructions.

[0116] If a match is successful, the pre-generated configuration instructions are invoked directly, skipping the time-consuming prediction and partial verification processes, significantly accelerating the configuration process. If a match fails, the process reverts to the standard pipeline processing flow, ensuring all requests are handled appropriately. This template-based configuration strategy greatly improves the system's response speed to common communication patterns while maintaining its ability to handle novel requests, balancing efficiency and flexibility. Through template matching and invocation, accurate and efficient final configuration instructions are generated, ready for application to actual network devices.

[0117] Based on the generated final configuration instructions, a comprehensive performance monitoring and dynamic optimization mechanism was established. Key performance indicators at each stage of the pipeline are collected in real time, including processing time, queue length, resource utilization, and success rate, constructing a complete performance profile. Each processor is configured with a performance monitoring point to record request arrival time, processing start time, and completion time in real time, calculating processing latency and throughput to reflect processing efficiency. Simultaneously, the changing trends of the queue at each stage are monitored to identify potential congestion and bottlenecks.

[0118] Performance data acquisition employs a low-overhead embedded monitoring mechanism to ensure that the monitoring activities themselves do not significantly impact system performance. Collected data is aggregated and analyzed to transform it into meaningful performance metrics, supporting system self-assessment and optimization decisions. Particular attention is paid to the differences in processing capacity at each stage; processing capacity is defined as the number of configuration requests completed per unit of time, directly reflecting the efficiency of that stage.

[0119] By comparing the processing capabilities of each stage, the stage with the lowest processing capability is identified as a potential pipeline bottleneck. Further analysis of the waiting queue length changes at the bottleneck stage confirms that this stage is the true pipeline bottleneck and requires priority optimization when the queue continuously grows within a consecutive time window. Bottleneck identification combines both static processing capability and dynamic queue status to ensure the accuracy and representativeness of the identification results.

[0120] For identified bottleneck stages, implement dynamic resource adjustment strategies. Reassess the resource requirements and utilization efficiency of each stage, and dynamically adjust resource allocation ratios, such as increasing the number of processor instances in the bottleneck stage, increasing their memory or computing resource quotas, and adjusting their processing priorities. Resource adjustments are based on performance monitoring data and resource benefit analysis to ensure that adjustments effectively improve overall throughput and avoid blind adjustments and resource waste.

[0121] Simultaneously, scheduling strategy parameters are optimized, such as adjusting request batch size, modifying queue priority mechanisms, and updating timeout and retry strategies, to improve processing efficiency and stability during bottleneck phases. The scheduling strategy adjustments consider request characteristics and processing patterns, employing different optimization methods for different types of bottlenecks to achieve precise optimization. For example, for compute-intensive bottlenecks, parallelism and batch size may be increased; for I / O-intensive bottlenecks, data access patterns and caching strategies may be optimized.

[0122] By combining resource allocation adjustments and scheduling strategy optimizations, an optimized pipeline configuration management architecture was obtained. This optimized architecture, with more balanced resource allocation and more efficient scheduling strategies, achieves higher overall throughput and lower end-to-end latency, providing superior network configuration services for graph computing tasks. Optimization is not a one-off process; continuous monitoring of performance changes and periodic repetition of bottleneck identification and optimization processes ensure the continuous evolution and improvement of the architecture.

[0123] Through the five core steps detailed above—configuration request normalization, pipeline architecture construction, priority evaluation and resource allocation, pattern recognition and template generation, and dynamic performance optimization—the optical switch configuration pipeline scheduling method for graph computing proposed in this embodiment achieves efficient, reliable, and intelligent optical network resource management, significantly improves the network configuration efficiency and service quality of graph computing applications, and provides strong network infrastructure support for large-scale graph data processing.

[0124] Example 2

[0125] In this embodiment, based on the standardized configuration request data, the optical switch configuration process is decomposed into four functionally independent processing stages: prediction, verification, configuration, and confirmation. A corresponding processor is configured for each processing stage, and data transfer between processors is achieved through asynchronous message queues, constructing a pipelined configuration management architecture, including:

[0126] Based on the standardized configuration request data, the communication requirements of the graph computing task are analyzed. A prediction processor is configured and a first computing resource and a first cache space are allocated for the prediction stage. The prediction processor is used to generate a preliminary optical path plan. A verification processor is configured and a second computing resource and a second cache space are allocated for the verification stage. The verification processor is used to check the feasibility and resource availability of the preliminary optical path plan. A processor is configured and a third computing resource and a third cache space are allocated for the configuration stage. The configuration processor is used to execute hardware setting instructions. A verification processor is configured and a fourth computing resource and a fourth cache space are allocated for the confirmation stage. The verification processor is used to detect whether the configuration is successful, resulting in four processors and their corresponding resource configurations.

[0127] Based on the four processors and their corresponding resource configurations, a first asynchronous message queue is configured between the prediction processor and the verification processor, a second asynchronous message queue is configured between the verification processor and the configuration processor, and a third asynchronous message queue is configured between the configuration processor and the confirmation processor. A request description format is designed, which includes a request identifier, optical path parameters, priority flags, and timestamps, thus obtaining an asynchronous communication mechanism.

[0128] Based on the asynchronous communication mechanism, after the prediction processor completes the processing of a configuration request, it encapsulates the processing result into a message conforming to the request description format and places it into the first asynchronous message queue. The prediction processor then begins processing the next configuration request. The verification processor retrieves the message from the first asynchronous message queue, verifies it, and places the verification result into the second asynchronous message queue. The configuration processor retrieves the verification result from the second asynchronous message queue, configures it, and places the configuration result into the third asynchronous message queue. The confirmation processor retrieves the configuration result from the third asynchronous message queue and confirms it. This enables parallel processing of multiple configuration requests in four stages, resulting in the pipelined configuration management architecture.

[0129] Specifically, based on standardized configuration request data, this embodiment decomposes the optical switch configuration process into four functionally independent processing stages, allocates dedicated processor resources to each stage, and implements data transmission through asynchronous message queues, thus constructing a highly efficient pipelined configuration management architecture. This architecture allows multiple optical path configuration requests to be executed in parallel at different processing stages, significantly improving the overall system throughput.

[0130] First, a thorough analysis of the communication requirements for graph computing tasks is conducted. These requirements typically include parameters such as source and target node information, bandwidth requirements, latency constraints, and service priorities. These parameters reflect the specific network resource needs of the graph computing task and directly influence the choice of optical switch configuration strategy. Based on these requirements, a dedicated prediction processor is configured for the prediction phase, and it is allocated initial computing resources and initial cache space. As the first step in the pipeline, the prediction processor is responsible for analyzing the communication topology, assessing resource requirements, and generating a preliminary optical path planning scheme.

[0131] The predictive processor employs a multi-objective path planning algorithm, comprehensively considering bandwidth requirements, latency constraints, and optical network resource status to calculate a satisfactory optical path planning scheme. This scheme includes detailed routing information, wavelength allocation strategies, and port usage plans. Because the prediction phase requires complex path calculations, the first allocated computing resources typically possess strong computational capabilities, while the first cache space is used to store network topology information and temporary calculation results to improve the efficiency of path calculation.

[0132] A verification processor is configured for the verification phase, and secondary computing resources and a secondary cache space are allocated. The primary responsibility of the verification processor is to check the feasibility and resource availability of the preliminary optical path plan generated in the prediction phase. The verification process includes checking multiple aspects such as wavelength conflicts, port occupancy status, path connectivity, and compatibility with existing optical paths. The verification processor accesses a real-time resource status database to obtain the current network resource occupancy and compares it with the planning scheme to ensure that the resources used in the planning are available in the actual network.

[0133] The secondary computing resources allocated to the verification processor typically have faster I / O processing capabilities because the verification process mainly involves data querying and comparison operations. The secondary cache space is used to store resource status information and verification results, ensuring efficient execution of the verification process. The verification processor detects potential resource conflicts, including wavelength conflicts, port conflicts, and optical path crossover conflicts, and provides feasibility assessment results.

[0134] A dedicated configuration processor is allocated for the configuration phase, along with third-party computing resources and a third-party cache. The configuration processor is the link in the pipeline that directly interacts with the hardware, responsible for executing the actual optical switch hardware setup instructions. The configuration process includes a series of hardware operations such as sending port configuration commands, setting wavelength parameters, and activating optical path connections. The configuration processor needs to communicate with various types of optical switch devices, supporting different control protocols and interface specifications.

[0135] The third computing resources allocated to the configuration processor typically have real-time processing capabilities, ensuring timely instruction issuance and execution. The third cache space is used to store device control instruction sequences and configuration status information. The configuration processor employs a transaction processing model to ensure the atomicity and consistency of configuration operations; that is, a set of related configuration instructions either all execute successfully or all are rolled back, preventing network resources from being in an inconsistent state.

[0136] A verification processor is configured for the verification phase, and a fourth set of computing resources and a fourth set of cache space are allocated. The verification processor's responsibility is to verify the actual execution effect of the configuration operations and to detect whether the configuration was successfully completed and achieved the expected goals. The verification process includes operations such as collecting optical path status information, measuring optical signal parameters, and verifying end-to-end connectivity. The verification processor interacts with the monitoring system to obtain real-time optical path status data and compares it with the expected goals.

[0137] The fourth computing resource allocated to the confirmation processor is primarily used for data analysis and status assessment, while the fourth cache space is used to store monitoring data and confirmation results. The confirmation processor implements closed-loop configuration control, enabling it to promptly detect configuration anomalies and trigger corresponding repair mechanisms, ensuring the reliability and stability of the optical path configuration. Through the above configuration, four dedicated processors and their corresponding resource configurations are obtained, forming the basic structure of the processing pipeline.

[0138] Based on the four processors and their corresponding resource configurations, a data transfer mechanism between the processors is further constructed. A first asynchronous message queue is configured between the prediction processor and the verification processor as a data exchange channel between the two processing stages. Asynchronous message queues are an efficient inter-process communication mechanism that allows the sender to continue executing subsequent operations immediately after writing a message, without waiting for the receiver to complete processing, thereby achieving decoupling and parallel execution of the processing.

[0139] The first asynchronous message queue uses a first-in, first-out (FIFO) data structure to ensure that the optical path plans generated by the prediction processor are processed by the verification processor in the order they are submitted. The queue has a buffer function to balance the processing speed difference between the prediction processor and the verification processor. When the rate at which the prediction processor generates planning schemes temporarily exceeds the processing capacity of the verification processor, the excess planning schemes can be temporarily stored in the queue, waiting for the verification processor to process them when it is idle.

[0140] A second asynchronous message queue is configured between the verification processor and the configuration processor. This second asynchronous message queue transmits the verified optical path plan and its resource check results, allowing the configuration processor to execute the actual hardware settings. Similarly, this asynchronous communication mechanism allows the verification processor to immediately return to processing the next planning scheme after placing the verification result in the queue, without waiting for the configuration processor to complete its configuration operation.

[0141] A third asynchronous message queue is configured between the configuration processor and the confirmation processor. This third asynchronous message queue transmits the execution results and status information of the configuration operation, allowing the confirmation processor to verify the configuration effect. These three asynchronous message queues together form the data path between the various stages of the pipeline, enabling continuous progress of the processing flow.

[0142] To ensure the consistency and integrity of messages transmitted across all stages, a unified request description format was designed. This format includes key information such as a request identifier, optical path parameters, priority flags, and timestamps. The request identifier is a unique identifier for each configuration request, used to track the request's processing status in the pipeline; optical path parameters contain technical details such as routing information, wavelength allocation, and port settings; the priority flag reflects the request's processing priority and is used for scheduling decisions during resource contention; and the timestamp records the request's submission time and the processing time of each stage, used for performance monitoring and timeout detection.

[0143] Through the above asynchronous message queue and request description format, a complete asynchronous communication mechanism was established, laying the foundation for parallel execution of each stage of the pipeline. Based on the established asynchronous communication mechanism, the system implemented a parallel processing flow for multiple configuration requests in four stages. After the prediction processor completes the processing of a configuration request, it encapsulates the generated preliminary optical path plan into a message conforming to the request description format, containing detailed routing plans, wavelength allocation schemes, and port usage arrangements.

[0144] The encapsulated message is placed in the first asynchronous message queue. The prediction processor does not need to wait for the completion of subsequent processing steps and immediately begins processing the next configuration request, achieving continuous processing. The verification processor then retrieves a message from the first asynchronous message queue, extracts the preliminary optical path planning content, verifies resource availability and planning feasibility, and encapsulates the verification results into a new message, placing it in the second asynchronous message queue.

[0145] The configuration processor retrieves the validated configuration plan from the second asynchronous message queue, executes the actual hardware configuration operation, and places the configuration result into the third asynchronous message queue. The confirmation processor retrieves the configuration result from the third asynchronous message queue, performs final configuration effect verification, and completes the closed-loop control of the entire configuration process. This pipelined design enables the simultaneous processing of multiple configuration requests at different stages, significantly improving the overall throughput and efficiency of optical switch configuration, ultimately forming a highly efficient pipelined configuration management architecture.

[0146] Example 3

[0147] In this embodiment, based on the asynchronous communication mechanism, multiple configuration requests are processed in parallel across four stages, including:

[0148] Based on the asynchronous communication mechanism, the prediction processor obtains a first configuration request from the configuration request queue, parses the communication requirement parameters of the first configuration request, generates a first preliminary optical path plan, encapsulates the first processing result containing the first preliminary optical path plan into a first message conforming to the request description format and puts it into the first asynchronous message queue, the prediction processor obtains a second configuration request and starts generating a second preliminary optical path plan, thus obtaining the first stage of parallel processing;

[0149] According to the first stage of parallel processing, the verification processor retrieves the first message from the first asynchronous message queue, extracts the first preliminary optical path plan, checks the feasibility and resource availability of the first preliminary optical path plan, generates the first verification result and encapsulates it into the second message and puts it into the second asynchronous message queue. At the same time, the prediction processor continues to process the second configuration request, realizing the parallel execution of the prediction processor and the verification processor, and obtaining two-stage parallel processing.

[0150] Based on the two-stage parallel processing, the configuration processor retrieves the second message from the second asynchronous message queue, extracts the first verification result, executes hardware setting instructions based on the first verification result, generates a first configuration result, and encapsulates it into a third message and places it into the third asynchronous message queue. The confirmation processor retrieves the third message from the third asynchronous message queue, extracts the first configuration result, and detects the configuration success condition. This enables four processors to process different stages of different configuration requests simultaneously, resulting in a complete parallel processing mechanism.

[0151] Specifically, first, the prediction processor retrieves the first configuration request from the configuration request queue. The configuration request queue is the entry point for the system to receive optical path configuration requirements from graph computation tasks. It employs a priority queue data structure to ensure that high-priority requests receive processing resources first. After retrieving the first configuration request from the head of the queue, the prediction processor immediately parses and processes it to extract key communication requirement parameters.

[0152] Communication requirement parameters typically include source node identifier, destination node identifier, bandwidth requirement, maximum acceptable latency, and quality of service (QoS) level. These parameters collectively define the specific requirements of graph computation tasks for optical network resources. Based on these parameters, combined with the current network topology and resource distribution, the prediction processor initiates an optical path planning algorithm to generate a preliminary optical path plan for the first configuration request.

[0153] Optical path planning is a multi-constraint optimization process that requires simultaneous consideration of multiple technical factors. The predictive processor applies heuristic path search algorithms, such as the improved K-shortest path algorithm, to compute multiple candidate paths from the source node to the target node. For each candidate path, the processor evaluates its latency characteristics, resource consumption, and reliability metrics, selecting the path that best meets the requirements as the basis for optical path planning. After the path is determined, the processor further performs wavelength allocation and port planning to form a complete optical path configuration scheme.

[0154] After generating the initial optical path plan, the prediction processor encapsulates the first processing result of the plan into a first message conforming to the request description format. The message encapsulation process includes adding a request identifier, timestamp, priority flag, and detailed optical path parameters. The optical path parameters section details the routing node sequence, selected wavelength channels, specified input / output ports, and corresponding quality parameter estimates. The encapsulated first message is placed in the first asynchronous message queue, awaiting further processing by the verification processor.

[0155] Crucially, after placing the first message into the queue, the predictive processor does not need to wait for the message to be processed by the verification processor. Instead, it immediately returns to the configuration request queue, retrieves the second configuration request, and begins generating the second preliminary optical path plan. This non-blocking processing mode enables the predictive processor to process multiple configuration requests continuously and efficiently without becoming idle due to processing delays in subsequent stages, thus achieving parallel processing capabilities in the first stage.

[0156] As the prediction processor continues to process new configuration requests, the verification processor simultaneously retrieves the first message previously placed in the first asynchronous message queue. The verification processor first parses the message content, extracts detailed parameters for the initial optical path plan, and then performs a series of verification checks. The verification process first confirms the basic validity of the optical path plan, including path connectivity, topology consistency, and parameter validity.

[0157] Next, the verification processor performs resource conflict detection by querying the real-time resource database to check the current availability of wavelengths, ports, and optical path resources specified in the plan. Resource conflict detection is efficiently represented using a resource occupancy matrix, where rows correspond to different time periods, columns correspond to different network resources, and matrix element values ​​represent the resource occupancy status within a specific time period. By querying the matrix, the verification processor can quickly determine whether resource conflicts exist in the planning scheme.

[0158] The verification processor also evaluates the performance metrics of the proposed solution, including end-to-end latency, bandwidth guarantee, and reliability, to ensure that the solution meets all technical requirements for communication. After completing comprehensive verification, the verification processor generates a first verification result, recording the specific conclusions of the verification and suggested parameters that may need adjustment. The first verification result is encapsulated into a second message and placed in a second asynchronous message queue, awaiting processing by the configuration processor.

[0159] It is worth noting that while the verification processor processes the first message, the prediction processor continues to process the second configuration request. The two processors execute their respective tasks in parallel without interfering with each other. This parallel execution mode makes full use of the system's computing resources, improves processing efficiency, and forms a two-stage parallel processing workflow.

[0160] As the verification processor and prediction processor continue to work in parallel, the configuration processor retrieves the second message from the second asynchronous message queue and extracts the first verification result. The configuration processor first checks the status of the verification result to confirm that the planning scheme has passed the verification check. For schemes that have passed verification, the configuration processor begins preparing for the actual hardware configuration operation.

[0161] Based on the optical path parameters in the verification results, the configuration processor generates a series of specific hardware configuration commands. These commands include wavelength selection commands, optical switch port configuration commands, connection establishment commands, etc., and are formatted according to a specific device control protocol. After the commands are generated, the configuration processor sends these commands sequentially to the relevant network devices through the device management interface to execute the actual hardware configuration operations.

[0162] The configuration process employs a transaction processing model, ensuring that a set of related configuration operations either all execute successfully or all are rolled back. The configuration processor monitors the execution status of each instruction, recording the execution results and any potential error messages. After completing all configuration operations, the configuration processor generates a first configuration result, containing the execution status of the configuration, the actual parameter values ​​set, and any possible exception information. This first configuration result is encapsulated as a third message and placed into a third asynchronous message queue.

[0163] Simultaneously, the confirmation processor retrieves the third message from the third asynchronous message queue and extracts the first configuration result. The core task of the confirmation processor is to verify the actual effect of the configuration operation and ensure that the optical path configuration achieves the expected goals. The confirmation processor first checks the execution status of the configuration result to confirm that all configuration operations have been successfully completed. Then, it obtains the actual status data of the configured optical path through the network monitoring system, including optical signal quality parameters, end-to-end connectivity status, and performance indicators.

[0164] The verification processor compares the actual state data with the expected target to evaluate the effectiveness of the configuration and the degree of performance achievement. If the actual state meets the preset success conditions, the verification processor marks the configuration as successfully completed; if there are deviations or anomalies, it determines whether to trigger an adjustment or reconfiguration process based on the degree of deviation. The verification processor's work completes the closed-loop control of the entire optical path configuration, ensuring the reliability and effectiveness of the configuration process.

[0165] This design enables four processors to handle different configuration requests simultaneously at different stages: the prediction processor may be processing the fourth configuration request, the verification processor is simultaneously processing the third configuration request, the configuration processor is processing the second configuration request, and the confirmation processor is processing the first configuration request. This complete parallel processing mechanism significantly improves the system's configuration throughput, reduces configuration latency, and better meets the dynamic demands of graph computing tasks on optical network resources.

[0166] Example 4

[0167] In this embodiment, the step of extracting task feature parameters from the standardized configuration request data and calculating a comprehensive priority score based on the pipeline configuration management architecture includes:

[0168] Based on the pipeline configuration management architecture, the task type, computation priority, time urgency, and resource requirement are extracted from the standardized configuration request data. The task types are classified into real-time tasks and batch processing tasks. A first type weight is assigned to the real-time tasks, and a second type weight is assigned to the batch processing tasks. The computation priority, time urgency, and resource requirement are quantified to obtain priority scores, urgency scores, and requirement scores, thus obtaining multi-dimensional evaluation parameters.

[0169] Based on the multi-dimensional evaluation parameters, the comprehensive priority score is calculated using a weighted summation algorithm. The comprehensive priority score is equal to the weighted sum of the first type weight or the second type weight, the priority score, the urgency score, and the demand score.

[0170] Specifically, based on a pipelined configuration management architecture, this embodiment illustrates how to extract task feature parameters from standardized configuration request data and calculate priority scores through multi-dimensional comprehensive evaluation, providing a decision-making basis for subsequent request scheduling. This priority calculation method considers various characteristics of graph computation tasks and achieves differentiated processing for different types of requests.

[0171] First, four key task characteristic parameters are extracted from standardized configuration request data: task type, computation priority, time urgency, and resource requirements. These four parameters describe the important characteristics of graph computation tasks from different perspectives and jointly determine the priority that a task should receive in resource scheduling. Task type reflects the basic category of graph computation operations, such as graph traversal, path analysis, community detection, or feature extraction. Different types of tasks have different degrees of dependence on network resources and different real-time requirements.

[0172] Tasks are categorized into two main types: real-time tasks and batch processing tasks. Real-time tasks typically have strict time constraints and high response requirements, such as real-time graph analysis and interactive queries; batch processing tasks, on the other hand, are relatively more lenient and can tolerate some processing latency, such as full-graph statistical analysis and offline feature extraction. To reflect this difference in priority calculation, the system assigns a first-type weight to real-time tasks and a second-type weight to batch processing tasks.

[0173] The first type of weight is typically significantly higher than the second type of weight, reflecting the priority of real-time tasks. In practice, the first type of weight might be set to a high value between 0.8 and 0.9, while the second type of weight is set to a lower value between 0.3 and 0.5. This weighting ensures that even relatively low-priority real-time tasks receive priority processing opportunities compared to high-priority batch processing tasks, thus guaranteeing the system's responsiveness to real-time requirements.

[0174] The computation priority is the priority level explicitly declared in the configuration request, typically specified directly by the graph computing application or the user. This parameter reflects the importance of the task at the business level and is the direct input for priority calculation. The original computation priority is quantized and converted into a standardized priority score. The quantization process usually uses linear or non-linear mapping functions to convert the original priority level (such as high, medium, low, or numerical level) into a standardized value within the range of 0-100.

[0175] Time urgency reflects a task's sensitivity to processing delays and the strictness of time constraints. Time urgency can be derived from several factors, including the task's deadline, elapsed waiting time, and estimated processing time. Based on these time-related parameters, an urgency coefficient is calculated and converted into a standardized urgency score. The calculation of time urgency uses the time window ratio method, which is the ratio of the task's remaining available time to its estimated processing time; a smaller ratio indicates a more urgent task.

[0176] Resource demand describes the intensity and scale of a task's demand for optical network resources, including the number of wavelength channels, bandwidth requirements, and connection duration. Resource demand is a crucial indicator for measuring the resource occupancy cost of a task and influences the system's resource allocation decisions. Resource demand is quantitatively assessed and converted into standardized demand scores. The quantification of resource demand employs a multi-resource weighted method, comprehensively considering the demand and scarcity of different types of resources to generate a unified demand index.

[0177] Through the above processing, multi-dimensional evaluation parameters were obtained, including task type weights, priority scores, urgency scores, and demand scores. These parameters describe the characteristics and requirements of graph computing tasks from different perspectives, providing comprehensive input data for overall priority calculation. Based on the multi-dimensional evaluation parameters, the system applies a weighted summation algorithm to calculate the overall priority score.

[0178] Weighted summation is a classic multi-indicator comprehensive evaluation method that integrates multiple evaluation dimensions into a single priority metric. In this embodiment, the formula for calculating the comprehensive priority score is designed as a weighted sum of task type weights and other scores. Specifically, for real-time tasks, the comprehensive priority score is equal to the weighted sum of the first type weight, priority score, urgency score, and demand score; for batch processing tasks, a similar calculation is performed using the second type weight.

[0179] In the weighted summation calculation, priority score, urgency score, and demand score are each assigned a weight coefficient, reflecting their relative importance in priority assessment. A typical weight configuration might be a priority score weight of 0.5, an urgency score weight of 0.3, and a demand score weight of 0.2, indicating that business priority is the most important consideration, followed by time urgency, while resource demand has a relatively smaller impact. These weight coefficients can be dynamically adjusted according to system operating status and business characteristics to adapt to different scheduling needs.

[0180] A weighted summation algorithm is used to calculate a comprehensive priority score for each configuration request. This score is a single numerical value that comprehensively considers multiple dimensions of characteristics, typically ranging from 0 to 100. A higher score indicates a higher processing priority for the configuration request, meaning it should receive more priority processing opportunities during resource scheduling. This priority calculation method based on multi-dimensional evaluation can comprehensively reflect the characteristics and demand differences of graph computation tasks, providing a scientific basis for subsequent request scheduling decisions.

[0181] The weighting coefficients of each score can be dynamically adjusted based on actual operating conditions to optimize scheduling performance. For example, when the system load is light, the weight of the priority score can be increased to better differentiate business priorities; when the system load is heavy, the weight of the urgency score can be increased to prioritize tasks with strict time constraints; and when resource competition is fierce, the weight of the demand score can be increased to prioritize tasks with lower resource requirements, thereby improving resource utilization efficiency.

[0182] This multi-dimensional priority evaluation method, compared to the traditional single-dimensional priority mechanism, can more comprehensively consider task characteristics, achieve more refined scheduling control, and better meet the dynamic scheduling needs of optical network resources in graph computing scenarios. By comprehensively evaluating priority scores, it can effectively distinguish and sort configuration requests of different types and characteristics, providing a decision-making basis for subsequent request queue management and resource allocation.

[0183] Example 5

[0184] In this embodiment, as Figure 2 As shown, the calculation of the comprehensive priority score and the sorting of the configuration request queue includes:

[0185] Step S31: Based on the comprehensive priority score, sort all configuration requests in the configuration request queue from high to low according to the comprehensive priority score to obtain a pre-sorted configuration request queue.

[0186] Step S32: Based on the configuration request queue after preliminary sorting, a preemptive queue-jumping mechanism is provided for the real-time tasks. When a new real-time task arrives and its corresponding comprehensive priority score is higher than the task waiting in the queue, the new real-time task is inserted at the head of the queue. A batch processing mechanism is provided for the batch processing tasks. When the processor resource utilization is lower than the preset idle threshold, multiple batch processing tasks are combined into a batch for processing to obtain a configuration request queue with differentiated scheduling.

[0187] Step S33: Based on the differentiated scheduling configuration request queue, monitor the waiting time of each configuration request, identify tasks in the differentiated scheduling configuration request queue whose comprehensive priority score is lower than a preset priority threshold as tasks to be promoted, and dynamically increase the comprehensive priority score of the tasks to be promoted when the waiting time of the tasks to be promoted exceeds the preset waiting threshold. The increase in the comprehensive priority score is proportional to the waiting time, and the sorted configuration request queue is obtained.

[0188] Specifically, firstly, based on the comprehensive priority score calculated in the aforementioned embodiments, all requests in the configuration request queue are initially sorted. The sorting employs an efficient priority queue data structure, arranging all configuration requests from highest to lowest comprehensive priority score. This priority-based sorting ensures that requests with higher importance, tighter time constraints, or greater business value receive priority processing opportunities.

[0189] The sorting process employs an improved quicksort algorithm with a time complexity of O(n log n), enabling efficient handling of large-scale request queues. The algorithm also considers request arrival time; when two requests have the same or very close overall priority scores (the difference is less than a preset threshold), the request that arrives first receives a higher ranking position, ensuring scheduling fairness. This initial sorting results in a priority-organized configuration request queue, providing the foundation for subsequent differentiated scheduling.

[0190] Based on the initially sorted configuration request queue, differentiated scheduling strategies for different task types are further implemented. For real-time tasks, a preemptive queue-jumping mechanism is provided. Preemptive queue-jumping is a special scheduling optimization that allows newly arriving high-priority real-time tasks to be directly inserted at the front of the queue without waiting for all existing tasks in the queue to be processed. This mechanism is particularly suitable for handling sudden, critical tasks and can significantly reduce the response latency of critical tasks.

[0191] Specifically, when a new real-time task arrives, its overall priority score is first calculated, and then compared with the overall priority scores of tasks waiting in the queue. If the new task's score is higher than some tasks in the queue, the new task is inserted before the first task with a lower priority in the queue. If the new task's priority score is higher than all waiting tasks in the queue, it is directly inserted at the head of the queue and becomes the next task to be processed.

[0192] Preemptive queue-jumping mechanisms ensure that high-priority real-time tasks are processed promptly by partially adjusting the queue order, preventing response delays caused by a large number of low-priority tasks already in the queue. This is particularly important for latency-sensitive tasks in graph computing, such as real-time analysis and interactive queries, guaranteeing the system's real-time responsiveness.

[0193] For batch processing tasks, a batch processing mechanism is used, which is a resource utilization optimization strategy for low-priority tasks. The core idea of ​​batch processing is to combine multiple similar batch processing tasks together for processing when system resources are relatively idle, reducing the switching overhead between tasks and improving the overall processing efficiency of the system.

[0194] By monitoring processor resource utilization, it is determined whether batch processing is suitable. When processor resource utilization falls below a preset idle threshold (typically set to 30%-50%), batch processing tasks with similar priorities and resource requirements are identified from the queue and grouped into batches for processing. Tasks within a batch share certain configuration operations and resource allocation decisions, reducing redundant computations and resource fragmentation, and improving resource utilization efficiency.

[0195] Batch processing mechanisms are particularly well-suited for handling large numbers of similar graph analysis tasks, such as batch graph feature extraction and multi-object graph search. By packaging these tasks, network resources can be utilized more efficiently, increasing overall throughput. Furthermore, batch processing helps reduce frequent switching of optical switch configurations, lowering configuration overhead and error risks.

[0196] By employing two differentiated scheduling strategies—preemptive queueing and batch processing—a configuration request queue capable of simultaneously meeting both real-time and efficiency requirements is created. This differentiated scheduling ensures rapid response for high-priority tasks while also improving the system's processing efficiency for low-priority tasks, achieving overall optimization of resource allocation.

[0197] However, purely priority-based scheduling may result in low-priority tasks not receiving processing opportunities for extended periods, leading to a phenomenon known as "starvation." To address this issue, this embodiment introduces a dynamic priority boosting mechanism to ensure that all configuration requests are processed within a reasonable timeframe.

[0198] Based on the differentiated scheduling of the configuration request queue, the waiting time of each request is continuously monitored. The waiting time refers to the time interval from when the request enters the queue to the current moment, and is an important indicator for measuring the fairness of request processing. Special attention is paid to tasks whose overall priority score is lower than the preset priority threshold. These tasks are marked as "tasks to be promoted" because they may not be processed for a long time due to their low priority.

[0199] For each task to be promoted, check whether its waiting time exceeds a preset waiting threshold. The waiting threshold is usually set based on the system's processing capacity and task characteristics, and may range from a few seconds to several minutes. When the waiting time of a task exceeds the preset waiting threshold, a dynamic priority promotion mechanism is activated, increasing the task's overall priority score according to certain rules.

[0200] Priority boosts are directly proportional to waiting time, and the calculation formula is typically designed to multiply the portion of the waiting time exceeding a threshold by a boost factor. This design ensures that tasks with longer waiting times receive greater priority boosts, increasing their chances of being processed. However, the boost factor setting must also comprehensively consider system load and task characteristics to avoid excessive boosting that could lead to scheduling disorder.

[0201] The dynamic priority promotion mechanism prevents low-priority tasks from suffering prolonged starvation, ensuring fairness and predictability in scheduling. Even low-priority tasks, if they wait long enough, can receive sufficient priority promotion and eventually get a chance to be processed. This mechanism guarantees that high-priority tasks are processed first, while also providing protection for low-priority tasks, making the system's scheduling behavior more balanced and robust.

[0202] After three stages of processing—priority sorting, differentiated scheduling strategies, and dynamic priority boosting—the system ultimately obtains an optimized configuration request queue. This queue reflects both the inherent priority differences of tasks and considers the needs for real-time response and fair processing, providing a scientific scheduling basis for subsequent resource allocation and conflict arbitration.

[0203] Example 6

[0204] In this embodiment, the steps of identifying dependencies and constraints between resources, detecting resource conflicts, evaluating the value of conflicting tasks based on a value function model and executing arbitration decisions to generate a resource allocation scheme include:

[0205] Based on the sorted configuration request queue, the optical switch network topology is obtained, the wavelength resources, port resources and optical path resources in the optical switch network topology are identified, the dependencies between resources are analyzed, and the constraints are determined, including that the same port cannot be allocated to multiple optical paths at the same time, the same wavelength on the same optical fiber cannot be used by multiple optical paths at the same time, and the establishment of an optical path requires that the source port and the target port are available at the same time, thus obtaining a resource dependency model.

[0206] Based on the resource dependency model, a resource occupancy matrix is ​​constructed. The rows of the resource occupancy matrix correspond to configuration requests, the columns correspond to resources, and the matrix elements represent the occupancy status, including unoccupied, occupied, and reserved states. Based on the resource occupancy matrix, a resource maintenance availability time window is established. The availability time window records the resource occupancy status of each time slice from the current moment to a preset future time period. When a new configuration request arrives, the target resource required by the new configuration request is extracted, and the occupancy status of the target resource in the resource occupancy matrix and the availability time window is queried. When the occupancy status of the target resource is occupied or reserved, it is identified as a resource conflict, and a resource conflict detection result is obtained.

[0207] Based on the resource conflict detection results, the value function model is constructed. The value function model comprehensively considers latency tolerance, computation priority, and historical waiting time. For configuration requests with resource conflicts, the latency tolerance, computation priority, and historical waiting time are extracted. The task value score is calculated according to the value function model. The task value scores of multiple configuration requests with resource conflicts are compared. The configuration request with the highest task value score is selected to be allocated the target resource first. The remaining configuration requests are reallocated or delayed to obtain the resource allocation scheme.

[0208] Specifically, firstly, based on the sorted configuration request queue, the system obtains the current optical switch network topology and resource distribution. Network topology is typically represented by a graph data structure, where nodes represent network devices (such as optical switches, wavelength division multiplexers, etc.), edges represent fiber optic connections, and each edge may have multiple wavelength channels. The system analyzes the network topology to identify three key resource categories: wavelength resources, port resources, and optical path resources.

[0209] Wavelength resources refer to the different wavelength channels available in an optical fiber, each capable of carrying an independent data stream. In dense wavelength division multiplexing (DWDM) systems, a single optical fiber may support dozens or even hundreds of wavelength channels, each representing an allocatable network resource. A key characteristic of wavelength resources is that the same wavelength on the same fiber can only be used by one optical path at any given time, and different wavelengths are independent of each other.

[0210] Port resources refer to the input / output ports on optical switching equipment, used to connect optical fibers and process optical signals. Port resources are a critical component of optical path establishment; a single port can only serve one optical path connection at a time. Limitations in port resources directly impact network connectivity and topology flexibility.

[0211] Optical path resources refer to established end-to-end optical connections, including occupied wavelength channels, ports, and intermediate nodes. Optical path resources can also be considered as an allocable resource, especially in systems supporting optical path multiplexing or time-division multiplexing. Detailed records of the specific resources used by each optical path are kept for collision detection and resource optimization.

[0212] Based on the identification of these three types of resources, the dependencies and constraints between resources are further analyzed. Dependencies describe the usage restrictions and mutual influences between resources, and are the core constraints of resource allocation. Three key constraints were identified: the same port cannot be allocated to multiple optical paths simultaneously; the same wavelength on the same optical fiber cannot be used by multiple optical paths simultaneously; and establishing an optical path requires both the source port and the destination port to be available simultaneously.

[0213] These constraints collectively define the feasible space for resource allocation, and any allocation scheme that violates these constraints is unacceptable. These resources and their constraints are modeled as a resource dependency model, represented by a graph structure. Nodes represent various types of resources, edges represent dependencies between resources, and the attributes on the edges describe the specific constraints and dependency types.

[0214] Based on the established resource dependency model, a resource occupancy matrix is ​​constructed. This is an efficient data structure used to represent and query the occupancy status of resources. Rows in the resource occupancy matrix correspond to different configuration requests, columns correspond to different network resources, and matrix elements represent the resource occupancy status. Occupancy status is divided into three categories: unoccupied, occupied, and reserved.

[0215] The unoccupied state indicates that the resource is currently free and can be allocated by a new configuration request; the occupied state indicates that the resource has been occupied by a configuration request and cannot be allocated to other requests; the reserved state is an intermediate state, indicating that the resource has been reserved by a configuration request but has not yet been officially occupied, and is usually used to support resource reservation mechanisms.

[0216] The resource occupancy matrix not only records the current resource status but also predicts resource availability over a future period through an available time window mechanism. The available time window is a temporal extension of the resource occupancy matrix, recording the resource occupancy status for each time slice within a preset future time period from the current moment. Time windows are typically divided into fixed time slices, such as every 5 seconds or every 10 seconds, while the total window length is set according to system requirements, potentially ranging from several minutes to several hours.

[0217] By maintaining a time window for resource availability, it is possible not only to detect resource conflicts at the current moment but also to predict potential conflicts in the future, providing a basis for resource reservation and scheduling optimization. This spatiotemporal resource management approach is particularly suitable for handling graph computation tasks that are long-lasting or require pre-planning.

[0218] When a new configuration request arrives, the target resources required by the request are first extracted, including specific wavelengths, ports, and possible intermediate nodes. Then, the resource occupancy matrix and available time window are queried to check the occupancy status of these target resources within the requested time period. If any target resource is occupied or reserved within the corresponding time period, it is identified as a resource conflict, indicating that the current resource allocation request is competing with existing allocations or reservations.

[0219] The results of resource conflict detection include the type of conflicting resource, the time period of the conflict, and other conflicting configuration requests. This information provides detailed decision-making basis for subsequent conflict arbitration. Based on the resource conflict detection results, a value function model is constructed for value assessment and arbitration decisions regarding conflict tasks.

[0220] The value function model is a multi-objective decision-making tool used to quantify the value or utility of resources acquired through different tasks, enabling optimal allocation decisions during resource competition. In this embodiment, the value function model comprehensively considers three key factors: latency tolerance, computational priority, and historical waiting time.

[0221] Latency tolerance describes how well a task can tolerate processing delays, typically calculated by dividing the difference between the task's deadline and the current time by the task's estimated processing time. A lower latency tolerance indicates a more sensitive task to latency and should receive higher priority in resource allocation. The latency tolerance is extracted from the time parameters of the configuration request and quantified into a standardized value from 0 to 100.

[0222] Computational priority reflects a task's importance at the business level and is typically extracted directly from configuration requests. The raw computational priority is quantified into a standardized numerical value, which serves as the input parameter for the value function. Computational priority reflects the inherent importance of a task and is a core factor in value assessment.

[0223] Historical waiting time is the cumulative waiting time of a task since it entered the system, reflecting the time cost the task has already invested in the system. The longer the historical waiting time, the longer the task has occupied system resources (such as queue positions). From the perspective of resource utilization efficiency, it should be given a higher completion priority to avoid previous waiting becoming "sunk costs".

[0224] For all configuration requests that experience resource conflicts, these three key parameters are extracted, and then a task value score is calculated for each request based on the value function model. The value function model uses a weighted scoring method, combining latency tolerance, computation priority, and historical waiting time with specific weights to form a comprehensive value score.

[0225] The calculated task value score is directly used for conflict arbitration decisions. The task value scores of multiple configuration requests with resource conflicts are compared, and the request with the highest value score is prioritized for allocation of the target resource. This value-based arbitration mechanism ensures maximum economic efficiency in resource allocation, prioritizing the tasks with the most urgent and highest-value resource needs.

[0226] For other requests that fail to receive priority resource allocation, two processing options are provided: resource reallocation or deferred processing. Resource reallocation involves finding alternative resources for the request, such as different wavelengths, ports, or routing paths, to meet its basic functional requirements, although this may come at the cost of performance or efficiency. Deferred processing, on the other hand, temporarily suspends the request, waiting for the target resource to become available before processing it. This is suitable for non-urgent tasks with high latency tolerance.

[0227] Through the above resource conflict detection and value assessment arbitration mechanism, an optimized resource allocation scheme was finally generated, realizing efficient scheduling and allocation in a resource competition environment, ensuring the rational use of system resources and maximizing task value.

[0228] Example 7

[0229] In this embodiment, after evaluating the value of the conflict task based on the value function model and executing arbitration decisions to generate the resource allocation scheme, the method further includes:

[0230] Based on the resource allocation scheme, the optical switch configuration operation is performed, the configuration execution result is monitored, and when a configuration failure is detected, failure data containing failure type, occurrence stage, associated resources and environmental parameters is captured. The failure data is then structured and integrated with device logs, performance indicators and topology status to obtain multimodal failure data.

[0231] Based on the multimodal failure data, data mining algorithms are applied to identify recurring failure patterns and construct a failure association graph. The failure association graph displays the causal relationships and temporal dependencies between different failure events. Cluster analysis is performed on the multimodal failure data to obtain a failure pattern library.

[0232] Based on the failure mode library, extract the current feature vector for the current failure event, calculate the similarity between the current feature vector and the feature vectors of each failure mode category in the failure mode library, select the failure mode category with the highest similarity as the matching failure case, extract the historical recovery path and success rate of the matching failure case, select the historical recovery path with the highest success rate as the target recovery path, the target recovery path includes resource reallocation, configuration parameter adjustment and alternative optical path selection, and obtain a backtracking decision scheme;

[0233] Based on the backtracking decision scheme, the recovery operation in the target recovery path is executed, the recovery process and recovery result are recorded, and when the recovery result meets the preset recovery success conditions, the backtracking decision scheme is added to the failure handling knowledge base, the success rate statistics of the matching failure cases in the failure mode library are updated, and the updated failure mode library is obtained.

[0234] Specifically, first, after making resource allocation decisions based on the value function model, the actual optical switch configuration operation begins. This configuration operation involves sending and executing a series of hardware control commands, including setting the optical switch port status, adjusting the wavelength selector, and configuring optical amplifier parameters. These operations are executed by the configuration processor, and the configuration execution results are monitored in real time by the network monitoring system.

[0235] In real-world environments, configuration operations may fail for various reasons, such as hardware failure, resource conflicts, and parameter mismatches. When the system detects a configuration failure event, it immediately initiates a failure data collection process to capture failure data containing rich contextual information. Failure data typically includes four key categories of information: failure type, stage of occurrence, associated resources, and environmental parameters.

[0236] The failure type describes the specific nature of the error, such as "port not responding," "wavelength lock failure," or "abnormal optical power." This type information helps to quickly pinpoint the technical area and possible causes of the problem. The occurrence stage records which part of the configuration process the failure occurred at, such as the prediction, verification, configuration, or confirmation stage. This helps to determine the priority and scope of problem handling.

[0237] The associated resources record the network resources directly related to the failure, such as specific optical switching devices, wavelength channels, and fiber optic links. This information helps determine the physical location and scope of the failure. Environmental parameters record the system state and operating environment at the time of the failure, including network load, temperature conditions, and system uptime, providing crucial background information for failure analysis.

[0238] The collected failure data undergoes structured processing, converting unstructured error logs and alarm information into a standardized data format for easier subsequent analysis and processing. Simultaneously, the system integrates multi-source data, including device logs, performance metrics, and topology status, forming a multimodal failure dataset. Multimodal data fusion technology unifies the representation and processing of data from different sources and formats, providing a more comprehensive view of the failures.

[0239] Structured multimodal failure data forms the foundation for system learning and analysis. Data mining algorithms, particularly association rule mining and sequence pattern mining, are applied to identify recurring failure patterns from historical failure data. Failure patterns refer to combinations of failure events that frequently occur together under specific conditions; identifying these patterns helps discover potential causes of failures and preventative measures.

[0240] Association rule mining algorithms, such as Apriori and FP-growth, can discover frequent itemsets and association rules from large amounts of transaction data, making them suitable for analyzing co-occurrence relationships among failure events. Sequence pattern mining algorithms, such as PrefixSpan and SPADE, can discover frequent sequence patterns in time-series data, making them suitable for analyzing the temporal evolution of failure events. These algorithms enable the extraction of valuable pattern information from complex failure data.

[0241] Further, a failure association graph is constructed, a directed graph structure used to represent the causal relationships and temporal dependencies between different failure events. In the failure association graph, nodes represent failure events, and edges represent the relationships between events. The types of edges include causal relationship edges and temporal dependency edges; the former indicates that one event causes another event to occur, and the latter indicates the time sequence of events.

[0242] Failure correlation diagrams not only display individual failure events, but more importantly, reveal the correlation structure between failure events, helping the system understand the propagation path and root cause of the fault. For example, by analyzing the failure correlation diagram, the system may find that "optical power fluctuation" events often lead to "signal quality degradation" events, which in turn may trigger "connection loss" events. This chain relationship is crucial for fault diagnosis and prevention.

[0243] In addition to correlation analysis, cluster analysis is performed on multimodal failure data to categorize similar failure events into different pattern categories. Cluster analysis employs K-means clustering, hierarchical clustering, or density-based clustering algorithms to group failure events in the feature space, forming different failure pattern clusters. Each cluster represents a specific failure pattern with similar failure characteristics and processing methods.

[0244] Through data mining algorithms, failure correlation graph construction, and cluster analysis, a complete failure mode library was ultimately formed. This library is a structured knowledge base that records information such as the characteristic descriptions, typical cases, occurrence conditions, scope of impact, and handling methods for various failure modes. The failure mode library provides knowledge support for subsequent failure handling and is the core foundation of the system's intelligent recovery capabilities.

[0245] When a new failure event is encountered, a feature vector is first extracted from the current failure event. The feature vector of a failure event typically includes multi-dimensional information such as failure type code, resource identifier, occurrence time, and system state parameters. The feature vector extraction process employs feature engineering techniques to convert the raw failure data into standardized numerical vectors, facilitating similarity calculation and matching.

[0246] Calculate the similarity between the feature vector of the current failed event and the feature vectors of each failed mode category in the failure mode library. Similarity calculation typically uses metrics such as cosine similarity, Euclidean distance, or Mahalanobis distance, measuring the degree of similarity between events based on the "distance" of feature vectors in the feature space. The similarity calculation results are used for failure mode matching and identification.

[0247] The failure pattern category with the highest similarity is selected as the best match for the current failure event. This matching process is similar to case-based reasoning (CBR) problem-solving, which involves finding the most similar cases in a historical case library and referencing their solutions. The matched failure pattern is considered a "reference case" for the current failure event, and its historical handling methods and recovery experience can provide guidance for the current problem.

[0248] Historical recovery paths and success rates are extracted from the matched failure cases. Historical recovery paths refer to the technical methods and operational steps used in handling similar failures in the past, including resource reallocation strategies, configuration parameter adjustment schemes, and alternative optical path selection methods. The success rate records the proportion of success for each recovery path in historical applications, reflecting the reliability and effectiveness of the recovery method.

[0249] The historical recovery path with the highest success rate is selected as the target recovery path for the current failure event. This decision-making method based on historical success fully utilizes the system's accumulated knowledge, avoids repeated trial and error, and improves recovery efficiency and success rate. The target recovery path may include three types of operations: resource reallocation, configuration parameter adjustment, and alternative optical path selection.

[0250] Resource reallocation refers to finding alternative network resources to meet configuration requirements, such as changing wavelength channels, ports, or routing paths. Configuration parameter adjustment refers to modifying the operating parameters of optical switches, such as adjusting optical power, changing signal modulation formats, or updating control timing. Alternative optical path selection involves finding completely different network paths, which may require a larger-scale network reconstruction but can bypass faulty areas and provide service continuity.

[0251] The selected target recovery path and its detailed operational steps are organized into a structured backtracking decision plan, serving as an execution guide for the current failure recovery. The backtracking decision plan includes not only specific operational instructions but also expected results, success indicators, and alternative solutions, forming a complete recovery strategy.

[0252] Based on the generated backtracking decision scheme, the recovery operations in the target recovery path are executed. These recovery operations are typically performed in a predetermined order, and the effectiveness of each operation is monitored in real time, recording state changes and intermediate results during the recovery process. This fine-grained process monitoring helps evaluate the effectiveness of the recovery operations and provides detailed data for future case analyses.

[0253] After the recovery process is complete, assess whether the recovery result meets the preset success conditions. Success conditions typically include several aspects such as restoration of service connectivity, achievement of performance targets, and elimination of error states. If all conditions are met, the recovery process is marked as successful; otherwise, alternative recovery paths or upgrade procedures may need to be attempted.

[0254] When the recovery result meets the preset success conditions, the current backtracking decision plan is added to the failure handling knowledge base. The failure handling knowledge base is a collection of fault handling experience accumulated by the system over a long period of time, recording successful handling methods and best practices for various failure scenarios. By continuously enriching the knowledge base, the system can continuously improve its fault handling capabilities and intelligence level.

[0255] Simultaneously, the success rate statistics for matching failed cases in the failure mode library are updated. If the current recovery is successful, the success count for the corresponding recovery path is increased; if it fails, it is recorded as a failed case. This statistical update ensures the real-time accuracy of the success rate data, providing a more reliable basis for future recovery path selection.

[0256] Through the complete process of failure data processing, pattern recognition, case matching, and knowledge accumulation, a continuously self-improving historical perception and backtracking mechanism is formed, which can efficiently handle various optical switch configuration failures, improve the system's fault recovery capability and service stability, and provide more reliable optical network resource guarantees for graph computing tasks.

[0257] Example 8

[0258] In this embodiment, the applied data mining algorithm identifies recurring failure patterns and constructs a failure association graph. This graph displays the causal relationships and temporal dependencies between different failure events. Cluster analysis is then performed on the multimodal failure data to obtain a failure pattern library, including:

[0259] Based on the multimodal failure data, feature vectors of failure events are extracted. The feature vectors include the failure occurrence time, failure stage identifier, resource identifier, system load status, and configuration parameter values. The feature vectors are encoded by encoding the failure stage identifier as a numerical value, encoding the resource identifier as a resource type code, and quantifying the system load status as a load percentage to obtain the encoded feature vectors.

[0260] Based on the encoded feature vectors, the Apriori association rule mining algorithm is applied, a minimum support threshold and a minimum confidence threshold are set, the association relationship between the encoded feature vectors is analyzed, the support and confidence of each feature combination are calculated, and feature combinations whose support and confidence both exceed the minimum support threshold and the minimum confidence threshold are identified as repeated co-occurring failed feature combinations, thus obtaining the failure mode feature set;

[0261] Based on the failure mode feature set, a directed graph structure is constructed. Each failure event in the failure mode feature set is used as a node. The failure occurrence time of the failure event is extracted. When the failure occurrence time of the first failure event is earlier than the failure occurrence time of the second failure event and the time difference is less than a preset time window, a temporal dependency edge from the first failure event to the second failure event is established. When the resource identifier involved in the first failure event is a precondition of the second failure event, a causal relationship edge is established to obtain the failure association graph.

[0262] Based on the failure association graph, the Louvain graph clustering algorithm is applied to identify modular communities in the failure association graph. Each modular community corresponds to a failure mode category. A mode description is generated for each failure mode category to obtain the failure mode library.

[0263] Specifically, firstly, feature extraction is performed on each failure event based on the collected multimodal failure data. Multimodal failure data is a comprehensive dataset containing various information types and sources, including device logs, alarm information, performance metric records, and configuration history. Extracting standardized feature vectors from this data is the foundation for subsequent pattern analysis. Five core features are extracted: failure occurrence time, failure stage identifier, resource identifier, system load status, and configuration parameter values.

[0264] The failure occurrence time refers to the precise point in time when the failure event is detected by the system, typically accurate to the millisecond level. This timing information is crucial for analyzing the temporal relationships and causal chains of failure events. The failure stage identifier indicates which processing stage in the optical switch configuration pipeline the failure occurred in, including the prediction, verification, configuration, and confirmation stages. The causes and handling methods for failures often differ significantly across stages; therefore, stage identifiers are an important basis for failure classification.

[0265] Resource identifiers specify the particular network resource associated with the failure, such as a specific optical switch ID, wavelength channel number, port identifier, or optical path connection identifier. Resource identifiers help the system pinpoint the physical location and scope of the failure, which is crucial for fault isolation and recovery. System load status reflects the workload level of the network and processing system at the time of the failure, including metrics such as processor utilization, memory usage, and network traffic levels. This status information helps analyze the potential correlation between system load and the failure.

[0266] The configuration parameter values ​​record the specific parameter settings involved in the failed operation, such as wavelength, optical power level, and switching delay parameters. These parameter values ​​are crucial for analyzing the relationship between parameter configuration and failure, potentially revealing patterns where certain parameter combinations lead to failure. After extracting these five core features, the system needs to standardize and encode the feature vectors, converting them into a format suitable for machine learning algorithms.

[0267] The feature encoding process includes three main steps: encoding the failure stage identifier as a numerical value, encoding the resource identifier as a resource type code, and quantifying the system load status as a load percentage. The failure stage identifier is encoded using an integer mapping method; for example, prediction stage is mapped to 1, verification stage to 2, configuration stage to 3, and confirmation stage to 4. This numerical encoding facilitates algorithm processing while preserving the sequential relationship between stages.

[0268] The encoding of resource identifiers is more complex, requiring the conversion of different types of resource identifiers into resource type codes in a unified format. The encoding format typically adopts a hierarchical structure of "resource type-device ID-component ID," such as "SW-001-P03," which represents port 03 on an optical switch with ID 001. This hierarchical encoding structure preserves the physical hierarchy of resources while facilitating the calculation of similarity and correlation. The quantification of system load status involves standardizing various load indicators into percentage values ​​ranging from 0-100%, facilitating unified measurement and comparison.

[0269] Through the above encoding process, each failure event is represented as a structured feature vector, laying the foundation for subsequent data mining and pattern recognition. Based on the encoded feature vector set, the Apriori association rule mining algorithm is applied to discover the associations between failure features. The Apriori algorithm is a classic association rule mining technique specifically designed to discover frequent co-occurrence patterns between items in large datasets.

[0270] The core idea of ​​the Apriori algorithm is based on the principle that "any subset of a frequent itemset is also frequent," and it uses a layer-by-layer search, candidate generation, and pruning approach to discover frequent itemsets. In this embodiment, an "item" corresponds to a specific value of a failing feature, such as "stage = configuration stage" or "resource type = wavelength channel." The algorithm first finds all frequent 1-itemsets (sets where a single feature value appears more frequently than a threshold), then constructs candidate 2-itemsets based on the frequent 1-itemsets, filters out frequent 2-itemsets, and so on, gradually building larger frequent itemsets.

[0271] Before applying the Apriori algorithm, two key thresholds need to be set: the minimum support threshold and the minimum confidence threshold. Support refers to the frequency with which an itemset appears in all transactions, calculated as the number of transactions containing that itemset divided by the total number of transactions. In failure analysis, high support means that a certain feature combination frequently appears in failure events, potentially representing a common failure pattern. The minimum support threshold is typically set between 5% and 15%, with the specific value depending on the dataset size and application requirements.

[0272] Confidence level refers to conditional probability, representing the probability that itemset B will also occur given that itemset A has occurred. It is calculated as the number of transactions containing both A and B divided by the number of transactions containing A. In failure analysis, high confidence indicates a strong correlation between feature A and feature B, meaning that the occurrence of A is highly likely to lead to the occurrence of B. The minimum confidence threshold is typically set between 50% and 80% to ensure that the discovered rules have sufficient reliability.

[0273] The Apriori algorithm is applied to analyze the encoded feature vector set, calculating the support and confidence of all possible feature combinations. During the calculation, the algorithm generates a large number of candidate option sets and verifies the support of each set to ensure it exceeds a threshold. Support calculation involves scanning the entire dataset, making it the most computationally intensive part of the algorithm. To improve efficiency, hashing techniques and transaction compression are employed to reduce the number of data scans and memory usage.

[0274] By filtering feature combinations where both support and confidence exceed preset thresholds, recurring co-occurring failure feature combinations are identified, and these combinations are considered feature sets of failure modes. For example, it might be found that the three features "configuration phase failure," "high load state," and "specific wavelength value" frequently appear together, forming a typical failure mode feature set. These feature sets provide crucial information for understanding common failure modes and lay the foundation for constructing failure correlation graphs.

[0275] Based on the identified failure pattern feature set, a failure association graph is further constructed. This is a directed graph structure used to represent the temporal and causal relationships between failure events. In constructing the association graph, each failure event is treated as a node, and the node attributes contain the complete feature vector of that event. Then, the relationships between events are analyzed, establishing two types of edges: temporal dependency edges and causal relationship edges.

[0276] Temporal dependency edges represent the sequential relationship between events. When a first failure event is detected to occur earlier than a second failure event, and the time difference between the two is less than a preset time window, a temporal dependency edge is established from the first event to the second event. The size of the time window depends on the system's time scale characteristics and may range from milliseconds to minutes. The establishment of temporal dependency edges follows the unidirectional nature of time and will not create circular references.

[0277] The preset time window is a crucial parameter. Setting it too small may cause connections between related events to be ignored, while setting it too large may introduce spurious correlations between irrelevant events. Statistical analysis methods are typically used to determine the appropriate time window size, such as analyzing the typical time interval distribution of related events in historical data and selecting a time range that covers the main distribution as the window size.

[0278] Causal edges represent the logical dependencies and influence relationships between events. When the resource involved in the first failure event is a necessary or precondition for the second failure event, a causal edge is established from the first event to the second event. For example, if a wavelength conflict event leads to an optical path establishment failure event, then a causal edge exists between the two. Determining causality typically requires combining domain knowledge and historical data analysis to identify resource dependencies and logical relationships.

[0279] By constructing temporal dependency edges and causal relationship edges, a complete failure correlation graph was obtained. This graph reflects both the temporal evolution of failure events and describes the logical influence paths between events. The correlation graph provides an intuitive and visual representation for understanding complex failure scenarios and also provides a structured data foundation for subsequent pattern analysis.

[0280] Based on the constructed failure association graph, the Louvain graph clustering algorithm is applied to identify modular communities in the graph. The Louvain algorithm is a community detection algorithm based on modularity optimization, which is particularly suitable for handling the problem of community structure identification in large-scale complex networks. This algorithm divides the network into tightly connected node groups by iteratively optimizing the modularity index. The nodes within each group are densely connected, while the connections between groups are sparse.

[0281] The Louvain algorithm executes in two alternating phases: local optimization of modularity and community aggregation. In the first phase, the algorithm considers the relationship between each node and its neighbors, calculates the impact of moving a node to different communities on modularity, and selects the move operation that maximizes the modularity gain. This process is repeated for all nodes until the modularity no longer increases.

[0282] In the second phase, the algorithm merges nodes within the same community into a "supernode," constructing a new network where the edge weights between supernodes are the sum of the edge weights between all original nodes. Then, the algorithm returns to the first phase to continue optimizing the modularity on the new network. These two phases are executed alternately until the modularity no longer increases or the preset maximum number of iterations is reached.

[0283] The Louvain algorithm identifies multiple modular communities in the failure correlation graph, each corresponding to a set of closely related failure events. These communities typically represent different types of failure modes, such as hardware failure modes, resource conflict modes, and parameter configuration modes. Community identification helps the system decompose the complex failure correlation graph into manageable subgraphs, facilitating further analysis and processing.

[0284] For each identified modular community (failure mode category), a detailed pattern description is generated. The pattern description includes the pattern's basic characteristics, typical triggering conditions, associated event chains, scope of impact, and common handling methods. Common characteristics of nodes within the community are analyzed, and core feature combinations are extracted as pattern identifiers. The distribution and strength of edges within the community are analyzed to identify key causal paths and event chains. Considering the community's size and connection patterns, the scope and severity of the pattern's impact are assessed.

[0285] The pattern descriptions are presented in a structured format, including quantitative indicators and qualitative descriptions, facilitating both automated system processing and human understanding and review. For example, for the "wavelength locking failure" pattern, the description might include typical optical power range, temperature conditions, preceding event chains, and recommended recovery operations. These descriptions provide valuable reference information for subsequent failure identification and handling.

[0286] Through the complete process of feature extraction, association rule mining, association graph construction, and modular community discovery, a failure mode library containing multiple failure mode categories and their detailed descriptions was finally obtained. This library is the core knowledge foundation for the system's failure handling capabilities, supporting key functions such as fault prediction, rapid diagnosis, and intelligent recovery, significantly improving the stability and reliability of the optical switch configuration system.

[0287] Example 9

[0288] In this embodiment, based on the standardized configuration request data, the optical switch configuration process is decomposed into four functionally independent processing stages: prediction stage, verification stage, configuration stage, and confirmation stage. The prediction stage generates a preliminary optical path plan by analyzing the communication requirements of the graph calculation task through the prediction processor, including:

[0289] Based on the standardized configuration request data, the prediction processor parses the communication requirement parameters, extracts the source node, target node, bandwidth requirement and latency requirement, obtains the current optical network topology status and resource availability information, and generates network status data.

[0290] Based on the network state data, a heuristic search algorithm is applied to generate multiple candidate optical path configuration schemes. Each candidate optical path configuration scheme includes an optical path, wavelength allocation, and port allocation. The performance indicators of each candidate optical path configuration scheme are calculated, including estimated latency, resource consumption, and path hop count, to generate a candidate scheme set.

[0291] Based on the candidate scheme set, a multi-dimensional scheme evaluation framework is constructed to score each candidate optical path configuration scheme from the perspectives of throughput, latency, and resource efficiency. The candidate optical path configuration scheme with the highest score is selected as the preliminary optical path planning, and prediction stage output data is generated.

[0292] Based on the output data of the prediction stage, during the configuration process of the prediction processor, the deviation between the actual configuration effect and the prediction result is monitored in real time. When the deviation exceeds a preset threshold, the configuration parameter fine-tuning is triggered to dynamically adjust the wavelength allocation or path selection in the preliminary optical path planning, so as to obtain the self-corrected optical path planning.

[0293] Specifically, first, the prediction processor parses communication requirement parameters and extracts key information based on standardized configuration request data. Configuration request data is typically passed in in a structured format, containing rich descriptions of communication requirements. The prediction processor first extracts four core parameters: source node, target node, bandwidth requirement, and latency requirement. The source and target nodes are network identifiers of the communicating parties, usually represented by device IDs or network addresses, explicitly specifying the start and end points of the communication.

[0294] Bandwidth requirements describe the throughput needs of data transmission, typically measured in bits per second (bps), and are the primary basis for configuring optical path capacity. For graph computation tasks, bandwidth requirements can range from hundreds of Mbps to tens of Gbps, depending on the size of the graph data and the type of processing. Latency requirements define the maximum acceptable latency for end-to-end data transmission, typically measured in milliseconds, reflecting the application's sensitivity to network response time. Real-time graph analysis generally requires low latency, while batch graph processing can tolerate higher latency.

[0295] In addition to these four core parameters, the prediction processor may also extract additional information, such as quality of service level, connection duration, and security requirements. These parameters provide a more comprehensive description of communication needs, helping to generate more accurate configuration schemes. While extracting communication requirement parameters, the prediction processor also needs to obtain the current optical network topology and resource availability information to ensure that the generated configuration scheme matches the actual network environment.

[0296] Network status data contains three key types of information: topology, resource status, and performance metrics. Topology describes the physical connections of the network, typically represented by a graph data structure where nodes represent network devices and edges represent fiber optic connections. Resource status records the current usage and available capacity of various network resources (such as wavelength channels, switching ports, and optical amplifiers). Performance metrics provide operational status data for different parts of the network, such as link quality, latency levels, and bit error rate.

[0297] The predictive processor retrieves this information by querying the network management system or resource database to ensure it has the latest network status. To ensure the real-time nature and accuracy of the data, the system typically employs a combination of proactive querying and asynchronous notification, periodically refreshing the status data and receiving immediate updates when significant network changes occur. By integrating communication requirement parameters and network status data, the predictive processor generates a complete network status dataset, which serves as the foundational input for optical path planning.

[0298] Based on the generated network state data, the prediction processor applies a heuristic search algorithm to generate multiple candidate optical path configuration schemes. Heuristic search is an algorithmic strategy that combines problem-specific knowledge to reduce the search space and improve search efficiency, and is particularly suitable for handling path planning problems under complex constraints, such as optical networks. In this embodiment, the prediction processor uses an improved A* algorithm as the core search mechanism.

[0299] The A* algorithm is a graph search algorithm that combines breadth-first search and heuristic evaluation. It determines the search direction using an evaluation function f(n) = g(n) + h(n), where g(n) is the actual cost from the starting point to the current node, and h(n) is the estimated cost (heuristic function) from the current node to the target. The key to the A* algorithm lies in designing an effective heuristic function. In optical path planning, heuristic functions are typically designed based on factors such as physical distance, link capacity, and wavelength availability.

[0300] To generate diverse candidate solutions, the prediction processor employs a multi-starting point and multi-constraint search strategy. It not only starts the search from a specified source node but also considers multiple possible entry points; it considers not only the shortest path but also various paths satisfying different constraints (such as minimum latency, minimum hop count, and minimum resource consumption). This diversified search strategy ensures the breadth and representativeness of the candidate solution set, providing rich choices for subsequent solution optimization.

[0301] During the search, the algorithm dynamically constructs a path tree, where each node represents a potential intermediate device and edges represent fiber optic links between devices. The algorithm selects the most promising nodes for expansion based on the value of the evaluation function, gradually building a complete path from the source node to the target node. To improve search efficiency, pruning techniques are employed to promptly eliminate obviously suboptimal branches, reducing computational overhead.

[0302] After the path is determined, the prediction processor still needs to perform wavelength allocation and port allocation. Wavelength allocation uses algorithms such as First-Fit or Least-Loaded to allocate appropriate wavelength channels to each link in the path while satisfying wavelength continuity and collision avoidance constraints. Port allocation considers the availability and performance characteristics of device ports to select suitable connection ports for the two ends and intermediate nodes of the optical path.

[0303] Through the three stages of path planning, wavelength allocation, and port allocation, the prediction processor generates a complete technical solution for each candidate optical path configuration scheme, including detailed optical path, wavelength allocation table, and port allocation table. These schemes together constitute the candidate scheme set, providing a foundation for subsequent scheme evaluation and optimization.

[0304] For each generated candidate optical path configuration, the prediction processor calculates three key performance indicators: estimated latency, resource consumption, and path hop count. Estimated latency is the expected time for end-to-end data transmission, composed of propagation delay, switching delay, and processing delay, and is a core indicator for evaluating the real-time performance of the scheme. Resource consumption measures the degree to which the scheme consumes network resources, typically considering the number of wavelength channels, fiber segments, and switching ports, reflecting the resource efficiency of the scheme. Path hop count is the number of switching nodes traversed by the optical path, a simple indicator of the scheme's complexity and reliability.

[0305] The performance metrics are calculated using a combination of network models and empirical formulas. For example, propagation delay is calculated based on fiber length and the speed of light in the medium, while switching delay is estimated based on equipment model and load conditions. These calculation results are appended to each candidate scheme to form a complete set of candidate schemes, providing a data foundation for multi-dimensional evaluation.

[0306] Based on the generated candidate solution set, the predictive processor constructs a multi-dimensional solution evaluation framework to comprehensively score each candidate solution from three perspectives: throughput, latency, and resource efficiency. The multi-dimensional evaluation framework is a decision-making tool that balances multiple optimization objectives, comprehensively considering various performance indicators of a solution to find the optimal balance point. In this framework, throughput reflects the solution's ability to meet bandwidth requirements, latency reflects its ability to meet real-time requirements, and resource efficiency reflects the solution's economy and scalability.

[0307] The scoring process employs standardization and weighted summation. First, each performance indicator is converted into a standard score of 0-100 through linear or nonlinear mapping, eliminating dimensional differences. Then, based on the characteristics of communication requirements and system strategy, weight coefficients are assigned to each indicator, and a weighted total score is calculated. Different types of graph computation tasks may use different weight configurations; for example, real-time graph analysis may place greater emphasis on latency, while large-scale graph processing may prioritize throughput.

[0308] Through multi-dimensional evaluation, a comprehensive score is calculated for each candidate scheme, reflecting its overall advantages. The prediction processor selects the candidate scheme with the highest score as the initial optical path plan. This plan not only meets the basic requirements of communication needs but also achieves an optimal balance across multiple performance dimensions. The selected scheme is formatted as output data for the prediction phase, containing detailed technical parameters and performance estimates for reference in subsequent processing phases.

[0309] During actual configuration execution, the predictive processor implements a real-time monitoring and adaptive adjustment mechanism. It continuously monitors the deviation between the actual configuration effect and the predicted result, including differences between actual and estimated latency, and between actual and estimated bandwidth. This real-time monitoring is based on a network telemetry system, which evaluates the configuration effect by collecting performance data from key points.

[0310] When the detected deviation exceeds a preset threshold (typically set at 10%-20% of the estimated value), a configuration parameter fine-tuning mechanism is triggered. This fine-tuning process is a closed-loop control that dynamically adjusts key parameters in the optical path planning based on the nature and extent of the deviation. For example, if the actual latency is significantly higher than the estimated value, the optical path may be adjusted or a lower-latency wavelength channel may be switched; if the actual bandwidth does not meet the requirements, additional wavelength resources may be allocated or a higher-capacity port may be selected.

[0311] The fine-tuning mechanism employs a gradual strategy, adjusting only a small number of parameters at a time to avoid instability caused by drastic changes. Simultaneously, it records the effect of each adjustment, learns the relationship between parameter changes and performance improvements, and continuously optimizes the adjustment strategy. This self-correcting mechanism can cope with changes in network state and prediction errors, ensuring that the final configuration matches the expected requirements, thus improving the accuracy and reliability of optical path configuration.

[0312] Example 10

[0313] In this embodiment, the step of constructing a multi-dimensional scheme evaluation framework based on the candidate scheme set, scoring each candidate optical path configuration scheme from the perspectives of throughput, latency, and resource efficiency, and selecting the candidate optical path configuration scheme with the highest score as the preliminary optical path planning includes:

[0314] Based on the candidate scheme set, a throughput score is calculated for each candidate optical path configuration scheme, the throughput score being based on the maximum data transmission rate that the candidate optical path configuration scheme can support; a latency score is calculated, the latency score being based on the end-to-end transmission latency of the candidate optical path configuration scheme; and a resource efficiency score is calculated, the resource efficiency score being based on the number of wavelengths and ports occupied by the candidate optical path configuration scheme, generating multi-dimensional scoring data.

[0315] Based on the multi-dimensional scoring data, a comprehensive score is calculated for each candidate optical path configuration scheme. The comprehensive score is a weighted sum of the throughput score, the latency score, and the resource efficiency score. All candidate optical path configuration schemes are sorted according to the comprehensive score to generate a scoring ranking result.

[0316] Based on the scoring and ranking results, an automatic stopping condition is set. The automatic stopping condition includes the difference between the comprehensive score of the current optimal solution and the comprehensive score of the second-best solution being greater than a preset improvement threshold, or the search time exceeding the time budget determined according to the task type. When the automatic stopping condition is met, the solution search is stopped, and the candidate optical path configuration scheme with the highest comprehensive score in the scoring and ranking results is selected as the preliminary optical path planning to obtain the prediction stage output data.

[0317] Specifically, firstly, based on the candidate scheme set, a throughput score is calculated for each candidate optical path configuration scheme. Throughput is a fundamental indicator of network performance, reflecting the data transmission rate capability. The throughput score is calculated based on the maximum data transmission rate that the candidate scheme can support, which is determined by multiple factors on the optical path, including wavelength channel capacity, optical signal quality, and the processing capacity of the switching equipment.

[0318] The throughput performance of a solution is evaluated from two key aspects: absolute throughput and relative satisfaction. Absolute throughput is the raw bandwidth that the solution can provide, usually measured in Gbps, and directly reflects the transmission capacity of the optical path. Relative satisfaction is the ratio between the solution's throughput and the required bandwidth, reflecting the degree to which the solution meets the requirements. An ideal solution should provide throughput that matches the requirements, neither significantly insufficient nor excessively wasteful.

[0319] Throughput scores are calculated using a segmented scoring method, with different scoring rules set for different relative satisfaction ranges. When the relative satisfaction is below 1 (throughput is insufficient to meet demand), the score increases linearly with satisfaction, reflecting the importance of meeting demand. When the relative satisfaction is between 1 and 1.5 (throughput moderately exceeds demand), the highest score is given, reflecting the value of moderate redundancy. When the relative satisfaction exceeds 1.5 (throughput excessively exceeds demand), the score decreases slightly with increasing satisfaction, reflecting the waste of resources due to over-allocation. This scoring mechanism emphasizes meeting basic needs while avoiding excessive resource allocation.

[0320] Second, calculate the latency score for each candidate solution. Latency is a key metric for measuring network real-time performance, and it is particularly important for time-sensitive applications such as interactive graph analysis. The latency score is calculated based on the end-to-end transmission latency of the candidate solution, which comprises four components: optical signal propagation latency, node processing latency, queueing latency, and protocol conversion latency.

[0321] Optical signal propagation delay is the time required for an optical signal to travel through an optical fiber. It is related to the fiber length and the speed of light in the medium and typically constitutes the majority of the total delay. Node processing delay is the time it takes for an optical signal to be processed within a switching node. It is related to the node's hardware performance and current load. Queueing delay is the time it takes for data packets to wait in a network queue for processing, reflecting network congestion. Protocol conversion delay is the time required to convert between different network protocols and may exist in complex networks.

[0322] Taking into account these four latency factors, the total latency of the candidate solutions is calculated and compared with the latency requirements of the communication needs. The latency score is calculated using an inverse proportional relationship: the score is inversely proportional to the latency, with lower latency resulting in a higher score. Simultaneously, the satisfaction of latency requirements is also considered; full marks are awarded when the total latency is below the requirement threshold, and the score drops rapidly when it exceeds the requirement. This scoring mechanism emphasizes the importance of meeting latency requirements, especially for real-time applications.

[0323] Third, calculate the resource efficiency score of the candidate schemes. Resource efficiency reflects the utilization of network resources by a scheme and is an important indicator for evaluating the economy and scalability of a scheme. The resource efficiency score is mainly calculated based on the number of wavelengths and ports occupied by the candidate schemes, which are usually the most valuable and constrained resources in optical networks.

[0324] Wavelength resource efficiency is calculated as the ratio of supported bandwidth to the number of wavelengths used, reflecting the bandwidth output per unit wavelength resource. Efficient solutions can provide higher bandwidth with fewer wavelengths used by optimizing wavelength allocation and routing. Port resource efficiency is calculated as the ratio of supported bandwidth to the number of ports used, reflecting the bandwidth output per unit port resource. Efficient solutions can reduce port usage by optimizing port allocation and connection topology.

[0325] The resource efficiency score considers both wavelength efficiency and port efficiency, employing a geometric mean method to calculate the overall efficiency index, which is then converted into a standard score through normalization. This scoring mechanism encourages resource conservation and efficient utilization, contributing to improved overall network capacity and scalability. Through the calculation of these three dimensions, multi-dimensional scoring data including throughput, latency, and resource efficiency scores is generated, providing a comprehensive perspective for the overall evaluation of the solution.

[0326] Based on multi-dimensional scoring data, a comprehensive score is calculated for each candidate optical path configuration scheme. The comprehensive score is a weighted sum of throughput score, latency score, and resource efficiency score, with weight coefficients reflecting the relative importance of different performance dimensions in the evaluation. The weights are typically determined based on the type of communication requirement and system strategy. For example, for real-time interactive applications, latency score may be assigned a higher weight (e.g., 0.5); for high-data-volume applications, throughput score may be assigned a higher weight (e.g., 0.6); and in resource-constrained network environments, resource efficiency score may be assigned a higher weight (e.g., 0.4).

[0327] In practical implementation, an adaptive weighting mechanism may be adopted, dynamically adjusting the weight coefficients based on network conditions and application characteristics. For example, when network resource utilization is high, the weight of resource efficiency scores is increased; when handling latency-sensitive tasks, the weight of latency scores is increased. This dynamic weight adjustment allows the scoring system to adapt to different network environments and business needs, improving the flexibility and adaptability of the evaluation.

[0328] After the comprehensive score is calculated, all candidate optical path configuration schemes are sorted from highest to lowest according to their comprehensive scores, forming a score ranking result. The ranking process employs efficient sorting algorithms, such as quicksort or heapsort, ensuring rapid sorting even with a large number of candidate schemes. The ranking result clearly demonstrates the relative advantages of each scheme, providing an intuitive reference for the final selection.

[0329] Based on the scoring and ranking results, automatic stopping conditions are set to determine when to end the solution search process. Automatic stopping conditions are an important control mechanism in the optimization search process, enabling timely termination of the search when a sufficiently good solution is obtained, avoiding unnecessary consumption of computational resources. In this embodiment, two types of stopping conditions are set: a scoring improvement threshold condition and a time budget condition.

[0330] The scoring improvement threshold is based on the score difference between the optimal and second-best solutions. When the difference between the overall score of the current optimal solution and the overall score of the second-best solution exceeds a preset improvement threshold, a solution significantly superior to other solutions is considered to have been found, and further searching can stop. The improvement threshold is set depending on the required scoring accuracy and the typical differences between solutions, typically set at 5%-10% of the total score. A higher threshold requires more significant improvement, leading to stricter stopping conditions and potentially extending the search time; a lower threshold allows for stopping the search with minor improvements, speeding up decision-making but potentially missing better solutions.

[0331] The time budget condition is based on the time already consumed in the search process. A reasonable time budget is determined according to the task type; for example, a shorter time budget (e.g., 50-100ms) might be set for real-time response tasks, while a longer time budget (e.g., 500ms-1s) could be set for planning tasks. When the search time exceeds the set time budget, further searching stops, and the currently found optimal solution is returned. This time-based constraint ensures that the system can make decisions within the expected timeframe, meeting real-time requirements.

[0332] These two stopping conditions can be used in combination to form an "OR" relationship: the search will stop as long as either condition is met. This combined strategy ensures both the quality of the solution (by improving the threshold through scoring) and the timeliness of the decision (by time budgeting), achieving a good balance between efficiency and effectiveness.

[0333] When the automatic stopping condition is met, the scheme search stops, and the candidate optical path configuration scheme with the highest comprehensive score in the scoring ranking results is selected as the preliminary optical path planning. The selected scheme contains complete technical parameters, such as routing path, wavelength allocation table, port configuration, and performance prediction. This information is organized into structured prediction stage output data and passed to the next stage of the pipeline (verification stage) for processing.

[0334] The output data in the prediction phase not only includes the basic technical parameters of the plan, but also includes scoring information and alternative plans, providing rich decision support for subsequent phases. For example, if the verification phase finds that the optimal plan has resource conflicts, the second-highest-scoring alternative plan can be tried directly without restarting the entire planning process, thus improving the system's response efficiency and fault tolerance.

[0335] Through the complete process of multi-dimensional evaluation, comprehensive scoring calculation and automatic stopping conditions, the scientific evaluation and efficient selection of candidate optical path configuration schemes are realized, ensuring that the preliminary optical path planning is optimal in multiple dimensions such as performance, efficiency and reliability, and providing a reliable guarantee for meeting the communication needs of graph computing tasks.

[0336] Example 11

[0337] In this embodiment, before extracting task feature parameters from the standardized configuration request data according to the pipeline configuration management architecture and calculating the comprehensive priority score, the following steps are also included:

[0338] Based on the standardized configuration request data and historical configuration data, a causal graph model for optical network resource allocation is constructed. The causal graph model includes causal variable nodes and causal relationship edges. The causal variable nodes include task priority, resource availability, network load, and configuration success rate. Variable values ​​are extracted from the historical configuration data, and causal relationship parameters are learned by applying structural equation modeling to obtain a causal knowledge base.

[0339] Based on the causal knowledge base, for the input configuration request, the causal inference engine is applied to calculate the impact of different priority assignments on the configuration success rate based on the causal graph model. Causal variable nodes directly related to the configuration success rate are extracted from the causal graph model. The causal effect strength of each causal variable node on the configuration success rate is calculated. The causal variable node with the strongest causal effect strength is identified as the key causal factor, and the causal analysis results are obtained.

[0340] Based on the causal analysis results, the weight coefficients of the task feature parameters in the calculation of the comprehensive priority score are adjusted according to the key causal factors, and a decision boundary representation model is constructed. The decision boundary representation model defines the effective value range of the comprehensive priority score. When the network load status changes, the decision boundary of the decision boundary representation model is adjusted through a causal intervention mechanism to obtain an optimized priority evaluation model.

[0341] Specifically, firstly, a causal graph model for optical network resource allocation is constructed based on standardized configuration request data and historical configuration data. A causal graph model is a directed acyclic graph (DAG) structure used to represent causal relationships between variables and is a fundamental tool for causal reasoning. In the field of optical network resource allocation, causal graph models can reveal the influence mechanisms between different factors, providing a deeper understanding and guidance for resource scheduling.

[0342] The causal graph model comprises two core elements: causal variable nodes and causal relationship edges. Causal variable nodes represent key variables in the system, primarily including four categories in this embodiment: task priority, resource availability, network load, and configuration success rate. Task priority reflects the importance of configuration requests at the business level and is typically specified by the application or user, serving as a crucial input for resource allocation decisions. Resource availability describes the current availability of various network resources (such as wavelength channels and switching ports), directly impacting the feasibility of the configuration scheme.

[0343] Network load represents the overall usage of the current network, including metrics such as traffic levels, resource utilization, and processing queue length, reflecting the system's stress level. Configuration success rate is the core output variable of the entire model, representing the probability of successful optical switch configuration operations, and is a key indicator for evaluating system performance. In addition to these four main types of variables, the causal graph model may also include other related variables, such as configuration complexity, hardware status, and environmental factors, further refining the description of causal relationships.

[0344] Causal edges are directed edges connecting variable nodes, representing a causal relationship from cause to effect. For example, an edge from "resource availability" to "configuration success rate" indicates that resource availability directly affects configuration success rate; an edge from "task priority" to "resource availability" indicates that task priority may affect resource availability through resource reservation mechanisms. These causal edges not only indicate the direction of the influence but also represent the strength and form of the influence through weights or functional relationships.

[0345] The first step in building a causal graph model is to determine the model structure, that is, to determine which variables should be included in the model and what causal relationships exist between the variables. This step is usually accomplished by combining domain expert knowledge and data analysis to ensure that the model conforms to both theoretical understanding and actual data. From a large number of candidate variables, the variables with the most explanatory and predictive value are selected as model nodes, while causal connections between variables are initially determined based on expert knowledge and temporal relationships.

[0346] After determining the model structure, variable values ​​are extracted from historical configuration data to provide a data foundation for model parameter learning. Historical configuration data consists of accumulated configuration operation records during the long-term operation of the system, containing the actual values ​​of variables under various configuration scenarios. This raw data is cleaned, normalized, and its features are extracted, transforming it into a structured dataset suitable for model learning. To ensure the representativeness and completeness of the data, a stratified sampling strategy is adopted, covering samples from different time periods, different load levels, and different configuration types.

[0347] Based on a prepared dataset, structural equation modeling (SEM) is applied to learn causal relationship parameters. SEM is a statistical method used to estimate causal relationship parameters between variables and is a key technology for quantifying causal graphs. SEM represents the relationships between variables through a set of linear or nonlinear equations, where each equation describes how an outcome variable is influenced by its direct cause variables.

[0348] In this embodiment, the core task of structural equation modeling is to estimate the parameter values ​​along each causal relationship edge. These parameters reflect the degree and form of influence of the causal variable on the outcome variable. The learning process employs maximum likelihood estimation or Bayesian estimation methods to optimize the parameters by minimizing the error between the model prediction and the actual observation. To improve learning efficiency and prevent overfitting, regularization techniques and cross-validation strategies are used to ensure that the learned parameters not only fit the current data but also have good generalization ability.

[0349] Through structural equation modeling, a complete causal knowledge base was obtained, including a causal graph structure and quantified causal relationship parameters. This causal knowledge base not only describes "which factors influence the configuration success rate" but also quantifies "the extent of these factors' influence," providing a scientific basis for subsequent causal reasoning and decision optimization. The causal knowledge base is stored in a structured format, supporting efficient querying and updates, and can be continuously improved and optimized as new data accumulates.

[0350] Based on the established causal knowledge base, a causal inference engine is applied to the input configuration request to analyze the impact of different decisions on the configuration success rate. A causal inference engine is a computer system that uses causal models for reasoning and prediction, capable of answering intervention questions such as "If we change X, how will Y change?", which goes beyond the capabilities of traditional correlation analysis.

[0351] The core task of causal inference is to calculate the impact of different priority assignments on configuration success rate based on a causal graph model. First, key parameters, such as task type, resource requirements, and time constraints, are extracted from the configuration request and mapped to corresponding variables in the causal graph model. Then, different priority assignment scenarios are simulated, and the expected change in configuration success rate under each assignment is calculated using the causal graph model. This "hypothetical intervention" analysis can assess the potential effects of different decisions and provide scientific guidance for priority setting.

[0352] In the causal reasoning process, the focus is on causal variable nodes directly related to the configuration success rate, i.e., variables directly connected to the "configuration success rate" node in the causal graph. These directly related variables have a direct impact on the configuration success rate and are the main objectives of optimization decisions. The strength of the causal effect of each directly related variable on the configuration success rate is calculated, quantifying the magnitude and importance of its influence.

[0353] The strength of the causal effect is calculated using the average treatment effect (ATE) or conditional average treatment effect (CATE) method to assess the average impact of changes in variable values ​​on the outcome. During the calculation, other variables are kept constant, and only the value of the target variable is changed. The average effect value is obtained through multiple simulations. To improve computational efficiency, techniques such as Monte Carlo simulation or variational inference are employed to accelerate the calculation process while maintaining accuracy.

[0354] By calculating and comparing the causal effect strength of different variables, the variables with the strongest causal effect strength are identified as key causal factors. Key causal factors are those that have the greatest impact on configuration success rate; optimizing these factors yields the most significant performance improvements. These key factors and their impact strength are recorded as causal analysis results, providing a basis for subsequent weight adjustments and decision optimization.

[0355] Based on the causal analysis results, the weighting coefficients of task feature parameters in the comprehensive priority score calculation are adjusted according to the identified key causal factors. Traditional weighting settings are usually based on experience or static rules, lacking a deep understanding of actual causal relationships. Causal analysis can identify which feature parameters have a greater actual impact on configuration success rate, thus allowing for a more scientific allocation of weights.

[0356] The principle of weight adjustment is to increase the weight of parameters corresponding to key causal factors and decrease the weight of non-key factors, so that the priority calculation can better reflect the actual causal relationship. For example, if "resource demand" is found to be the most critical factor affecting the configuration success rate, the weight of resource demand-related parameters in the priority calculation will be increased; conversely, if the causal effect of some parameters is small, their weight will be reduced to reduce their impact on the priority.

[0357] Based on the adjusted weighting coefficients, a decision boundary representation model is constructed. The decision boundary representation model is a mathematical model that defines and describes the effective decision range; in this embodiment, it is used to define the effective range of comprehensive priority scores. By delineating upper and lower boundaries or feasible regions, this model helps the system identify which priority values ​​are reasonable and effective, and which may lead to resource waste or configuration failure.

[0358] The decision boundary is set based on two key factors: the priority distribution of historically successful configurations and the current network state. The system analyzes the priority distribution characteristics of historical successful cases to identify priority intervals with a high probability of success; at the same time, it considers the current network load and resource availability, dynamically adjusting the boundary position. For example, when the network load is light, the decision boundary can be widened, allowing for a wider range of priority values; when the network load is heavy, the boundary is tightened, concentrating resources on the most valuable requests.

[0359] Of particular note is the implementation of a causal intervention mechanism, which automatically adjusts the decision boundary based on changes in network load. Causal intervention is a core concept in causal reasoning, referring to observing the impact of manually setting the values ​​of certain variables on the outcome. In this embodiment, when a significant change in network load is detected, the system adjusts the decision boundary parameters through the causal intervention mechanism, allowing priority assessment to better adapt to the new network environment.

[0360] For example, when network load suddenly increases, this change is identified, and the impact of the load increase on the success rate of various resources and configurations is inferred through a causal graph model. Then, the decision boundaries are tightened accordingly, and priority thresholds are increased to ensure that only the most critical tasks receive resource allocation. Conversely, when the load decreases, the boundaries are relaxed, allowing more tasks to obtain resources and improving overall throughput.

[0361] Through the complete process of constructing the causal graph, learning parameters, inferring causal reasoning, and optimizing the decision boundary, the optimized priority evaluation model was finally obtained. This model is not only based on data statistics but also incorporates deep causal knowledge, enabling it to more accurately assess task priorities, provide more scientific decision support for resource allocation, and significantly improve the efficiency and success rate of optical network resource allocation.

[0362] Example 12

[0363] In this embodiment, after adjusting the weight coefficients of the task feature parameters in the comprehensive priority score calculation based on the key causal factors and constructing the decision boundary representation model, the process includes:

[0364] Based on the decision boundary representation model, within the effective range of the comprehensive priority score, the optimization problem of the weight coefficients is modeled as a constrained optimization problem. The objective function is to maximize the configuration success rate, and the constraint condition is that the sum of the weight coefficients is 1 and all are greater than 0. The optimal weight combination is solved iteratively by applying the optimization algorithm, and the weight coefficients in the optimized priority evaluation model are updated to obtain the updated priority evaluation model.

[0365] Based on the updated priority evaluation model, at preset intervals, the system throughput, average latency, and configuration success rate before and after adopting the causal intervention mechanism are compared to calculate the performance improvement percentage. When the performance improvement percentage is lower than a preset validity threshold, the causal inference engine is re-executed, the causal effect strength is recalculated based on the causal graph model, the key causal factors are updated, the values ​​of the causal variable nodes set in the causal intervention mechanism are adjusted, and the effective value range of the comprehensive priority score is updated to obtain a continuously optimized priority evaluation model.

[0366] Specifically, firstly, based on the decision boundary representation model, the optimization problem of the weight coefficients is modeled as a constrained optimization problem. Constrained optimization is an important branch of mathematical optimization, specifically studying how to find the optimal solution of an objective function under certain constraints. In this embodiment, the goal of the weight optimization problem is to maximize the configuration success rate while satisfying the rationality constraints of the weight coefficients themselves.

[0367] The defined objective function is the configuration success rate, which is the probability that the system successfully completes the optical switch configuration under a given weight combination. The configuration success rate is a complex function influenced by various factors and cannot be directly expressed as an explicit function of the weights. To address this issue, a surrogate model approach is adopted, establishing a mapping relationship between weight combinations and the configuration success rate based on historical data, serving as an approximate expression of the objective function.

[0368] The surrogate model is constructed using advanced machine learning techniques, such as support vector regression, random forest, or neural networks. The system uses weight combinations from historical configuration data as input features and the corresponding configuration success rates as output labels to train a model capable of predicting the configuration success rate under a given weight combination. This surrogate model considers both the interactions between weights and captures non-linear relationships, providing a computational foundation for subsequent optimization.

[0369] Along with defining the objective function, two core constraints were also set: the sum of the weight coefficients must be 1, and all weight coefficients must be greater than 0. The sum of the weights being 1 is a normalization constraint, ensuring that the weight coefficients have a consistent scale and comparability; the weights being greater than 0 ensures that each feature parameter has the opportunity to contribute to the priority evaluation, avoiding the complete neglect of some potentially valuable features.

[0370] In addition to these two basic constraints, other constraints may be set, such as upper weight limits (to prevent a single feature from excessively dominating the decision) and weight change rate constraints (to ensure the smoothness of weight adjustments), to further standardize the optimization space and improve the stability and practicality of the optimization results. Based on the objective function and constraints, the system constructs a complete constrained optimization model, laying the foundation for solving the optimal weight combination.

[0371] For the constrained optimization problem, an optimization algorithm is applied iteratively to find the optimal weight combination. Considering the characteristics of the problem (non-convex, multivariable, constrained), an optimization algorithm suitable for this type of problem is selected. In this embodiment, the Bayesian optimization algorithm is mainly used, which is a global search method particularly suitable for black-box function optimization.

[0372] The core idea of ​​Bayesian optimization is to establish a probabilistic model of the objective function, efficiently searching the parameter space by balancing exploration and exploitation. The algorithm first selects several initial points in the parameter space for evaluation, then constructs a Gaussian process model based on the evaluation results of these points to predict the distribution of function values ​​across the entire parameter space. In each iteration, the algorithm uses an acquisition function, such as expected improvement or an upper confidence interval, to determine the next evaluation point, balancing the need to explore unknown regions with the need to exploit known good regions.

[0373] Bayesian optimization is particularly suitable for scenarios with limited computational resources and high function evaluation costs, such as the configuration success rate evaluation in this embodiment. Compared to traditional grid search or random search, Bayesian optimization can find better solutions with fewer function evaluations, greatly improving optimization efficiency. In implementing Bayesian optimization, efficient open-source libraries such as GPyOpt or BoTorch were used, and customized improvements were made for specific problems.

[0374] To enhance the robustness of the optimization, a multi-starting-point strategy and cross-validation techniques were also employed. The multi-starting-point strategy refers to starting the optimization from different combinations of initial weights to avoid getting trapped in local optima; cross-validation, on the other hand, evaluates the performance on different subsets of data to ensure that the optimization results have good generalization ability, applicable not only to historical data but also to future scenarios.

[0375] Through iterative optimization, a set of optimal weight coefficients was obtained, which achieved the highest configuration success rate based on historical data. These optimal coefficients were then used to update the optimized priority evaluation model, replacing the original weight settings and completing the model parameter update. The updated model not only retains the structure and framework of the original model but also incorporates data-driven optimization results, achieving an organic combination of empirical knowledge and data analysis.

[0376] To evaluate the actual effectiveness of the optimized model and ensure its continued effectiveness, a regular performance monitoring mechanism was established. At preset intervals, three key performance indicators (KPIs) were compared before and after the implementation of the causal intervention mechanism: system throughput, average latency, and configuration success rate. System throughput reflects the number of configuration requests successfully processed per unit time, directly reflecting the system's processing capacity; average latency measures the average time from request submission to configuration completion, reflecting the system's response speed; and the configuration success rate is the percentage of successfully completed configuration operations out of total requests, directly reflecting the system's reliability.

[0377] The performance comparison employs a before-and-after design, comparing performance data from the optimized model and the baseline model under the same load and similar request distribution. The percentage improvement for each metric is calculated as (performance after optimization - performance before optimization) / performance before optimization × 100%, providing a clear measure of improvement. A positive percentage improvement indicates performance enhancement, while a negative percentage indicates performance degradation; the absolute value of the percentage reflects the significance of the change.

[0378] Pay special attention to improvements in configuration success rate, as this is the direct goal of optimization. If the configuration success rate improves significantly while other metrics remain stable or also improve, the optimization is effective. If the configuration success rate improves but other metrics decline significantly, it may be necessary to rebalance the trade-offs between the metrics. If all metrics decline, the optimization strategy may have problems and needs to be adjusted promptly.

[0379] Performance monitoring not only evaluates the current optimization results but also serves as a trigger mechanism for continuous optimization. When the percentage performance improvement is detected to be lower than a preset effectiveness threshold (typically set at 3%-5%), the current optimization model is considered to no longer provide significant improvement and requires re-evaluation and adjustment. This effect-based automatic triggering mechanism ensures timely response to performance degradation and avoids the use of outdated optimization strategies.

[0380] When performance improvements are insufficient, the causal inference engine is re-executed to recalculate the causal effect strength of each factor based on the current causal graph model. This step re-evaluates the importance of each factor in the current environment, as key factors affecting configuration success rates may change over time and with environmental changes. For example, after a network upgrade, hardware performance may no longer be the bottleneck, while resource allocation strategies may become more important.

[0381] After recalculation and updating of key causal factors, new important factors may be discovered, or the importance of existing factors may change. Based on the updated understanding of causality, the values ​​of causal variable nodes set in the causal intervention mechanism are adjusted. Causal intervention is a reasoning method that simulates "how Y will change if we change X," predicting changes in outcomes by setting the values ​​of causal variables (rather than simply observing). Adjusting the intervention mechanism means that the system changes its understanding of "which factors need to be actively controlled," potentially focusing on different variables or setting variable values ​​in different ways.

[0382] For example, if "network load" is found to replace "resource availability" as the new key factor, intervention strategies may be adjusted to focus more on load balancing rather than resource reservation. This adjustment reflects an updated understanding of causality within the system, enabling interventions to target the most influential factors and improve their effectiveness.

[0383] Along with updating key factors and intervention mechanisms, the effective range of values ​​for the comprehensive priority score is also updated. The effective range defines the interval between priority scores that are considered reasonable; scores outside this range may be considered abnormal or invalid. As our understanding of causality deepens and the environment changes, the original range may no longer be applicable and needs to be readjusted.

[0384] The method for updating the value range is to analyze the priority distribution characteristics of successful configurations in the current environment and, combined with new causal understanding, determine a new reasonable range. For example, if it is found that lower-priority tasks can also achieve a good configuration success rate in the current environment, the lower limit of the effective range may be expanded; if it is found that only very high-priority tasks can succeed, the lower limit of the range may be increased to avoid wasting resources on low-priority tasks that are unlikely to succeed.

[0385] Through the complete process described above—reassessing causal relationships, updating key factors, adjusting intervention mechanisms, and optimizing the value range—a continuously optimized priority assessment model was generated. This model is not static or one-off, but dynamic and continuously evolving, capable of constantly improving itself as the environment changes and data accumulates, maintaining optimal performance.

[0386] The core value of continuous optimization mechanisms lies in their adaptability and self-improvement capabilities. In complex and ever-changing network environments, static models quickly become obsolete, while systems with continuous optimization capabilities can automatically detect performance changes, proactively adjust strategies, and ensure that the system always operates in an optimal state, maximizing resource utilization efficiency and configuration success rate.

[0387] Example 13

[0388] In this embodiment, the step of performing cluster analysis on the communication patterns of historical graph calculation tasks according to the resource allocation scheme, identifying recurring communication patterns, and pre-generating optical switch configuration templates for the recurring communication patterns includes:

[0389] Based on the resource allocation scheme, communication pattern data of historical graph computing tasks are collected from historical configuration records. The communication pattern data includes computing type, data flow topology, communication node pairs and traffic characteristics. Feature vectors of the communication pattern data are extracted, and clustering algorithms are applied to perform cluster analysis on the feature vectors to identify the communication patterns corresponding to the cluster centers, thereby obtaining a graph computing pattern feature library.

[0390] Based on the graph computing pattern feature library, an optical switch configuration process is executed for each communication pattern identified in the graph computing pattern feature library. The optical path planning parameters generated in the prediction stage, the resource check results in the verification stage, the hardware setting instructions in the configuration stage, and the verification steps in the confirmation stage are recorded. The optical path planning parameters, the resource check results, the hardware setting instructions, and the verification steps are encapsulated into an optical switch configuration template. Applicable condition tags and resource requirement descriptions are added to the optical switch configuration template to obtain a configuration template library.

[0391] Based on the configuration template library, a multi-dimensional index structure is established. When a new configuration request is received, the calculation type, data flow topology, and traffic characteristics of the new configuration request are extracted. The multi-dimensional index structure is used to search the configuration template library. The feature similarity between the new configuration request and each optical switch configuration template in the configuration template library is calculated. The optical switch configuration template with the highest feature similarity is selected as the matching configuration template to obtain the matching result.

[0392] Based on the matching result, the actual parameters of the new configuration request are extracted, and the actual parameters are used to replace the parameter placeholders in the matched configuration template. It is verified whether the replaced optical path planning parameters are available in the current network topology, and whether the replaced resource check results conflict with the current resource status. When the verification is successful, the final configuration instruction is generated based on the matched configuration template.

[0393] Specifically, firstly, based on the generated resource allocation scheme, communication pattern data of historical graph computing tasks is collected from historical configuration records. Communication pattern data is structured information describing how graph computing tasks use network resources, reflecting the network communication characteristics and demand patterns of the tasks. Four core types of information are collected: computation type, data flow topology, communication node pairs, and traffic characteristics.

[0394] Computation type refers to the algorithm category of a graph computation task, such as graph traversal, path analysis, community detection, or graph clustering. Different types of computation tasks often have different data access patterns and communication requirements, which are important bases for classifying communication patterns. Computation type information is extracted from task descriptions and algorithm identifiers and standardized and encoded to facilitate subsequent analysis.

[0395] Data flow topology describes how data flows and is exchanged between computing nodes, and is a core feature of communication patterns. Common data flow topologies include star topology (one central node communicates with multiple edge nodes), ring topology (nodes communicate sequentially in a ring), mesh topology (nodes communicate in a two-dimensional or multi-dimensional mesh), and fully connected topology (all nodes communicate with each other). The system identifies the type of topology used by the task by analyzing the data flow paths in historical communication records.

[0396] A communication node pair refers to the combination of a source node and a target node participating in communication, reflecting the specific participants in the communication. The system records the source and target node identifiers for each communication flow, constructing a complete list of communication node pairs. This node pair information not only reflects the participants in the communication but also reveals the communication frequency and importance of nodes through statistical analysis, helping to identify communication hotspots and bottlenecks.

[0397] Traffic characteristics describe the temporal and quantitative properties of communication data flows, including parameters such as data size, transmission rate, burstiness, and duration. Traffic statistics, such as average bandwidth, peak bandwidth, packet size distribution, and flow duration, are extracted from network monitoring data to construct a comprehensive traffic characteristic description. Traffic characteristics reflect the specific network resource requirements of a task and are an important input for configuration planning.

[0398] After collecting abundant communication pattern data, feature vector extraction is performed to transform unstructured or semi-structured pattern data into structured feature vectors suitable for machine learning processing. A feature vector is a multi-dimensional numerical array, with each dimension corresponding to a feature attribute, such as computation type encoding, topology type encoding, number of nodes, communication frequency, and bandwidth requirements. The feature extraction process combines domain knowledge and automated feature engineering techniques to ensure that the extracted features accurately represent the core characteristics of the communication patterns and can be effectively processed by clustering algorithms.

[0399] After constructing the feature vectors, a clustering algorithm is applied to perform cluster analysis on them. Cluster analysis is an unsupervised learning technique that can group similar data samples to discover inherent patterns and structures within a dataset. In this embodiment, the K-means++ clustering algorithm is mainly used, which is an improved version of the K-means algorithm. By optimizing the selection of initial cluster centers, it improves the stability and quality of clustering.

[0400] The K-means++ clustering algorithm first selects initial cluster centers based on a distance distribution probability, ensuring that the initial centers are relatively far apart. Then, the algorithm iteratively executes two steps: an assignment step (assigning each sample to the nearest cluster center) and an update step (recalculating the center point of each cluster). This process continues until the cluster center positions stabilize or the maximum number of iterations is reached. Through K-means++, the system is able to cluster similar communication patterns together, forming clear pattern categories.

[0401] A key challenge in clustering is determining the appropriate number of clusters, K. Too few clusters lead to the merging of different patterns, reducing template accuracy; too many clusters result in the dispersion of similar patterns, increasing the complexity of template management. Several methods are employed to determine the optimal K value, including the Elbow Method, the Silhouette Coefficient, and the Gap Statistic. The final chosen K value ensures both cluster compactness and maintains a reasonable number of templates, typically between 10 and 50, depending on the complexity and diversity of the historical data.

[0402] After clustering, the communication patterns corresponding to each cluster center are identified. These centers represent the most typical and representative pattern characteristics. The feature values ​​of the cluster centers are analyzed to interpret the core features and typical behaviors of each cluster, forming an interpretable pattern description. For example, a cluster center might represent a communication pattern such as "large-scale graph traversal task, using a star topology, moderate bandwidth requirements, and long duration." These identified typical patterns are recorded in the graph computation pattern feature library, providing a foundation for subsequent template generation.

[0403] The Graph Computing Pattern Feature Library is a structured knowledge base that records various communication patterns identified by the system and their feature descriptions. Each pattern entry in the feature library contains information such as a pattern identifier, feature vector, applicable scenarios, performance characteristics, and historical statistics, providing a comprehensive pattern profile. The feature library employs an efficient indexing structure, supporting fast queries and retrieval based on multiple conditions, facilitating rapid location of matching patterns when processing new requests.

[0404] Based on the established graph computing pattern feature library, an optical switch configuration process is executed for each identified communication pattern. The purpose of this step is to generate configuration schemes applicable to various typical patterns in advance, avoiding the repeated execution of time-consuming configuration calculation processes when actual requests arrive. The system takes pattern features as input and executes the configuration process according to a standard four-stage pipeline (prediction, verification, configuration, confirmation), but does not actually operate the hardware devices; instead, it records the key outputs and decisions at each stage.

[0405] During the prediction phase, the generated optical path planning parameters are recorded, including technical details such as routing paths, wavelength allocation schemes, and port settings. These parameters are the core content of the configuration template and directly reflect how to achieve the network configuration for a specific communication mode. During the verification phase, resource check results are recorded, including information such as resource availability verification, collision detection, and performance prediction. These results provide a reference for the applicability of the template.

[0406] During the configuration phase, hardware setup instructions are recorded, including device control commands, parameter setting instructions, and operation sequences. These instructions constitute the execution part of the template and define how to implement the configuration. During the verification phase, verification steps are recorded, including status checks, performance test points, and success conditions. These steps ensure that the validity of the configuration can be verified after the template is executed.

[0407] By recording key information from these four stages, a complete configuration process description for each communication mode was obtained. This information was further processed and organized to form a structured configuration template. Template encapsulation is a crucial step, integrating scattered configuration information into a logical whole, facilitating storage, retrieval, and application.

[0408] During the encapsulation process, the optical path planning parameters from the prediction phase, the resource check results from the verification phase, the hardware setting instructions from the configuration phase, and the verification steps from the confirmation phase are organized into a structured data packet, forming a complete optical switch configuration template. The configuration template adopts a standardized format, containing not only specific configuration data but also metadata and control information, supporting subsequent retrieval and application.

[0409] Of particular importance are the addition of two key tags to each configuration template: applicability tags and resource requirement descriptions. Applicability tags define the scenarios and limitations to which the template is applicable, including the range of applicable computing types, topology requirements, node quantity limits, and performance expectations. These conditions help the system quickly determine whether a template is suitable for a specific request, avoiding inappropriate application. Resource requirement descriptions detail the network resources required for template execution, including the number of wavelength channels, port types, bandwidth requirements, and connection duration, providing a basis for resource planning and conflict detection.

[0410] By generating and encapsulating configuration templates for each identified communication mode, a complete configuration template library was ultimately established. This library is an efficient template storage and management system, containing pre-generated configuration schemes applicable to various typical communication modes. The library employs a hierarchical storage structure, organizing templates according to mode category, complexity, and usage frequency. It supports flexible version management and update mechanisms, ensuring the accuracy and timeliness of template content.

[0411] To support efficient template retrieval and matching, a multi-dimensional index structure is built on top of the configured template library. Multi-dimensional indexing is a special data organization method that can quickly locate data based on features across multiple dimensions, making it ideal for template searching under complex conditions. Spatial index structures such as R-trees or KD-trees are used to organize templates into a hierarchical structure in the feature space, supporting range queries and nearest neighbor queries.

[0412] The multidimensional index is built based on the core feature dimensions of the template, such as computation type, topology, node size, and bandwidth level. An index is created for each dimension, and composite indexes support multi-condition joint queries. This index structure significantly improves the efficiency of template retrieval, enabling the system to quickly find the most matching candidate from a large number of templates, ensuring real-time response.

[0413] Upon receiving a new configuration request, key information such as the request's computation type, data flow topology, and traffic characteristics are first extracted to construct a request feature vector. Then, a multi-dimensional index structure is used to efficiently search the configuration template library and identify potential matching templates. The retrieval process employs a nearest neighbor search algorithm to find the template in the feature space closest to the request vector; commonly used distance metrics include Euclidean distance, Manhattan distance, or cosine similarity.

[0414] For each retrieved candidate template, the feature similarity between the new request and each template is calculated to quantify the degree of matching. The similarity calculation considers not only the overall distance between feature vectors but also assigns different weights to different feature dimensions, reflecting the relative importance of each feature in the matching process. For example, calculation type and topology may receive higher weights because they are key factors in pattern matching; while specific traffic values ​​may have lower weights because they have a degree of flexibility and variation in practical applications.

[0415] The template with the highest feature similarity is selected as the best match, generating the matching result. The matching result includes the selected template identifier, the matching score, and a list of parameters that may need to be adjusted, providing guidance for subsequent template applications. If multiple templates are found to have similar matching scores, the most recently used or most successful template may be selected to ensure the stability and reliability of the selection.

[0416] Based on the matching results, the actual parameters of the new configuration request are extracted, including specific node identifiers, precise bandwidth requirements, and actual time constraints. These actual parameters will replace the parameter placeholders in the matching template, concretizing the general template into a configuration scheme suitable for the current request. Parameter replacement is a critical step, requiring ensuring that the replaced configuration scheme maintains internal consistency and technical feasibility, avoiding parameter combination conflicts or logical errors.

[0417] After the parameter replacement is completed, two important verifications are performed: optical path planning parameter verification and resource check result verification. Optical path planning parameter verification ensures that the replaced routing path, wavelength selection, and port allocation are feasible in the current network topology, taking into account the actual status and connectivity of network devices. Resource check result verification ensures that the network resources required by the solution are available in the current state and do not conflict with existing allocations, taking into account resource occupancy and reservations.

[0418] Only when both verifications pass will the final configuration command be generated based on the matching configuration template. The final configuration command is a set of structured hardware control commands that will be sent directly to the relevant network devices for execution. These commands contain detailed operation steps, parameter settings, and timing requirements to achieve the requested network configuration goals. By using pre-generated templates, the complete four-stage configuration process is avoided, significantly reducing configuration latency and improving response efficiency.

[0419] Through the complete process of communication pattern recognition, template generation, multidimensional index construction, and template matching application, a pattern-based efficient configuration mechanism is realized, which can quickly respond to common graph computing communication needs and significantly improve the efficiency of resource allocation and the overall throughput of the system.

[0420] Example 14

[0421] In this embodiment, the step of collecting performance indicators of each stage of the pipeline in real time based on the final configuration instruction, identifying the stage with the lowest processing capacity as the pipeline bottleneck, and dynamically adjusting the resource allocation ratio and scheduling strategy parameters of each stage includes:

[0422] Based on the final configuration instruction, the entry time, start time and completion time of each configuration request at each stage are recorded in real time. The processing time is calculated, and the average processing time is calculated as the average processing time. The length changes of the waiting queue at each stage are monitored to obtain performance monitoring data.

[0423] Based on the performance monitoring data, the processing capacity of each stage is calculated. The processing capacity is defined as the number of configuration requests completed per unit time. The processing capacity of each stage is compared, and the stage with the smallest processing capacity is identified as the potential bottleneck stage. The waiting queue length of the potential bottleneck stage is analyzed. When the waiting queue length of the potential bottleneck stage continues to increase within a consecutive preset time window, the potential bottleneck stage is confirmed as the pipeline bottleneck, and the bottleneck identification result is obtained.

[0424] Based on the bottleneck identification results, a performance bottleneck model is constructed. The performance bottleneck model quantifies the impact of the pipeline bottleneck on the overall system throughput. Through simulation experiments, the processing capacity of the pipeline bottleneck is increased by a preset percentage. The overall system throughput after the increase is evaluated, and a bottleneck analysis report is obtained.

[0425] Based on the bottleneck analysis report, an optimization strategy is determined, the resource allocation ratio of the bottleneck stage of the pipeline is dynamically adjusted, the scheduling strategy parameters are adjusted, and the optimized pipeline configuration management architecture is obtained.

[0426] Specifically, firstly, a comprehensive real-time performance monitoring system is established based on the generated final configuration instructions. Performance monitoring is the foundation of system optimization; only by accurately understanding the real-time operation status of each stage can performance bottlenecks be identified and effective optimization strategies be formulated. The system focuses on recording three key time points for each configuration request at each stage of the pipeline: entry time, start processing time, and completion time. These three time points collectively define the processing lifecycle of the request at each stage.

[0427] Entry time refers to the precise moment a configuration request arrives at a certain processing stage, recording when the request enters the waiting queue for that stage. Accurate recording of entry times helps analyze the request flow path and overall processing flow, and is a crucial foundation for calculating end-to-end latency. By setting timestamp recording points at the entry points of each stage, the arrival time of each request is precisely captured, typically in milliseconds or microseconds, ensuring high precision in time recording.

[0428] The start processing time refers to the moment a request is selected from the waiting queue and begins actual processing. The difference between the start processing time and the entry time defines the request's waiting time, reflecting the busyness of the stage and scheduling efficiency. Recording the start processing time helps distinguish between waiting latency and processing latency, providing a basis for scheduling optimization decisions. This time point is recorded when the scheduler selects a request to enter a processing unit, also using a high-precision timestamp.

[0429] Completion time refers to the moment when a request is fully processed in the current stage and ready to proceed to the next stage. Completion time marks the end of request processing in that stage and is a key point for calculating actual processing time. The system records the completion time when the processing result is generated and ready for forwarding, ensuring accurate capture of the processing end point. By recording these three time points, the time distribution of requests in each stage can be clearly tracked, and key performance indicators can be accurately calculated.

[0430] Based on recorded time data, the processing time for each request at each stage is calculated. Processing time is defined as completion time minus start time, reflecting the actual time required for a processing unit to complete its work and serving as a direct indicator of processing efficiency. Statistical analysis is performed on the processing times of a large number of requests, calculating indicators such as the mean, median, standard deviation, and distribution characteristics to comprehensively understand the characteristics and patterns of change in processing time.

[0431] The average processing time is the arithmetic mean of the processing times for all requests, providing an overall estimate of processing efficiency. However, the average can be significantly affected by extreme values, so the system also focuses on the median (the middle value of processing time) and percentiles (such as the 90th or 95th percentile of processing times), which better reflect the actual experience for most requests. These statistical metrics help identify processing anomalies and performance fluctuations, allowing for the timely detection of potential problems.

[0432] In addition to processing time, the length of the waiting queue at each stage is also monitored. Queue length refers to the number of requests waiting to be processed, directly reflecting the load pressure at that stage. The waiting queue length at each stage is sampled periodically, typically recorded every second or every few milliseconds, forming time-series data on queue length. This data not only shows the current load situation but also reveals trends and patterns in load changes, helping to predict potential congestion and bottlenecks.

[0433] Multi-dimensional analysis of queue length data is performed to calculate indicators such as average queue length, peak queue length, and queue growth rate to identify queue anomalies and congestion risks. Of particular importance is the trend of queue length changes; a continuously growing queue indicates that the input rate exceeds the processing rate, a clear signal of a bottleneck; while a stable or fluctuating queue indicates that the system is in a balanced state and can effectively handle the current load.

[0434] By recording time, calculating processing time, and monitoring queue length, comprehensive performance monitoring data is generated, providing a solid foundation for subsequent bottleneck identification and optimization decisions. This data is stored in a structured format, supporting both real-time analysis and decision-making, as well as providing historical records for long-term performance evaluation and optimization. Time-series databases (such as InfluxDB or Prometheus) can be used to store this monitoring data, leveraging their efficient time-series data processing capabilities to support complex analysis.

[0435] Based on the collected performance monitoring data, the processing capacity of each stage is further calculated. Processing capacity is a core indicator of system performance, defined as the number of configuration requests completed per unit of time, usually measured in "requests per second". Processing capacity directly reflects the work efficiency and throughput of a stage and is a key basis for identifying bottlenecks. The system calculates processing capacity by statistically analyzing the number of requests completed within a specific time window (such as 1 minute or 5 minutes), ensuring that the measurement results reflect the current state without being excessively affected by short-term fluctuations.

[0436] When calculating the processing capacity at each stage, three key factors were considered: raw completion rate, resource utilization, and processing complexity. Raw completion rate is simply the number of requests completed within a time window, directly reflecting processing speed; resource utilization measures the busy / idle status of processing units, with a low completion rate under high utilization indicating insufficient resources or inefficiency; processing complexity takes into account the differences in request difficulty, and by assigning different weights to requests of different complexities, a fairer capacity assessment is obtained.

[0437] By comparing the processing capabilities of each stage, the stage with the lowest processing capability is identified as the potential bottleneck stage. In a pipeline structure, the stage with the lowest processing capability often becomes the limiting factor for overall throughput, similar to the shortest plank in the "barrel effect." The potential bottleneck stage is the stage with the worst performance in terms of processing capability metrics, but low processing capability alone is not enough to confirm it as a true bottleneck; further verification is needed in conjunction with queue status.

[0438] Analyze the waiting queue length during potential bottleneck stages, paying particular attention to the trend of queue length changes. True bottleneck stages typically manifest as continuously growing waiting queues because the input rate exceeds processing capacity, causing requests to accumulate. Set a preset time window (usually a few minutes to tens of minutes) and observe whether the queue during potential bottleneck stages continues to grow within this window. Determining continuous growth is usually based on linear regression or trend analysis to ensure that a true long-term trend is identified rather than short-term fluctuations.

[0439] When the waiting queue length of a potential bottleneck stage continues to increase within a preset time window, that stage is confirmed as a pipeline bottleneck. This dual confirmation mechanism (low processing capacity + continuously growing queue) ensures the accuracy and reliability of bottleneck identification, avoiding misjudgments due to temporary fluctuations. The confirmed bottleneck results include information such as bottleneck stage identification, processing capacity data, queue growth rate, and duration, providing clear targets for subsequent analysis and optimization.

[0440] Based on the bottleneck identification results, a detailed performance bottleneck model is constructed. The performance bottleneck model is a mathematical model that quantifies the impact of bottlenecks and can predict the effect of bottleneck improvement on overall system performance. Based on queuing theory and system modeling techniques, the model treats each stage of the pipeline as interconnected service nodes. By analyzing the data flow and processing characteristics between nodes, it assesses the limiting effect of bottlenecks on system throughput.

[0441] Performance bottleneck models primarily quantify two key metrics: bottleneck severity and improvement potential. Bottleneck severity measures the difference in processing capacity between the bottleneck stage and other stages, typically expressed as the ratio or difference between the bottleneck's processing capacity and the next lowest processing capacity. A higher bottleneck severity indicates a more severe bottleneck and a greater need for optimization. Improvement potential predicts the overall performance improvement that bottleneck improvement can bring, usually expressed as the expected increase in overall system throughput after a specific percentage increase in bottleneck processing capacity.

[0442] To accurately assess the potential for improvement, simulation experiments are used to model the effect of bottleneck improvements. Simulation experiments are a low-cost, low-risk evaluation method that can predict optimization effects without actually modifying system configurations. A simulation model of the pipeline is built, and the model parameters are calibrated using actual monitoring data. Then, the processing capacity of the bottleneck stage is increased by a preset percentage (usually 10%, 20%, or 50%) in the model, and the change in overall throughput is observed.

[0443] The simulation process employs discrete event simulation technology to model the flow and processing of requests within the pipeline. It generates a request flow similar to the actual load, allowing these requests to be passed and processed in the simulation model according to pipeline logic, and recording various performance metrics. By comparing the performance differences between a baseline scenario (without improving bottleneck processing capacity) and an optimized scenario (with improved bottleneck processing capacity), the effectiveness and value of bottleneck optimization can be objectively evaluated.

[0444] The simulation results generate a bottleneck analysis report, which includes a description of bottleneck characteristics, an analysis of the causes of bottleneck formation, performance predictions for each performance improvement percentage, and optimization suggestions. The report not only provides quantitative performance prediction data but also delves into the root causes of bottleneck formation, such as insufficient resources, low algorithm efficiency, or unbalanced load, offering guidance for targeted optimization. The bottleneck analysis report is a crucial basis for formulating system optimization strategies, ensuring that optimization measures are accurate and effective.

[0445] Based on the bottleneck analysis report, specific optimization strategies are determined. These strategies primarily include two aspects: resource allocation adjustment and scheduling strategy optimization. Resource allocation adjustment refers to changing the proportion of computing resources allocated to each processing stage, such as increasing the number of processor cores, memory capacity, or network bandwidth in the bottleneck stage. The system calculates the optimal resource reallocation scheme based on the bottleneck severity and potential for improvement. This typically involves appropriately reducing resources in non-bottleneck stages and shifting them to the bottleneck stage, achieving overall resource balance and optimal utilization.

[0446] Resource allocation adjustments need to consider resource portability and adjustment costs. Some resources (such as processor threads) are relatively easy to reallocate in a short period of time, while other resources (such as dedicated hardware) may be difficult to adjust dynamically. The system prioritizes the optimization of flexible and adjustable resources, implementing resource reallocation only when the adjustment cost is lower than the performance gain. At the same time, a certain amount of resource margin is reserved to cope with load fluctuations and sudden requests, ensuring system stability and resilience.

[0447] Scheduling strategy optimization focuses on the processing order and priority allocation of requests. Scheduling strategies have a significant impact on system performance, especially under resource constraints. To address the characteristics of bottleneck stages, several key scheduling parameters are adjusted, such as time slice length, priority weight, starvation threshold, and batch size, to optimize request processing flow and resource allocation.

[0448] For example, if the bottleneck phase is suitable for batch processing (e.g., multiple similar requests can be processed together to reduce overhead), the batch size parameter can be increased to allow more requests to be processed simultaneously. If there are requests with large differences in processing time during the bottleneck phase, the priority algorithm may be adjusted to prioritize short or critical tasks, thereby improving overall throughput and responsiveness. These fine-tuning of scheduling parameters can significantly improve the system's processing efficiency without increasing hardware resources.

[0449] A gradual adjustment strategy is adopted, initially applying small parameter changes, observing the effects, and then deciding whether to make larger adjustments. This conservative optimization strategy reduces the risks that large adjustments may bring, ensuring that the system always maintains stable operation. For each adjustment, changes in key performance indicators are monitored, the effectiveness of the adjustment is evaluated, optimization experience is accumulated, and the adjustment strategy is continuously improved.

[0450] Through a combination of resource allocation adjustments and scheduling strategy optimizations, the optimized pipeline configuration management architecture is ultimately obtained. This optimized architecture is not static but a dynamic structure that continuously adjusts itself based on load changes and performance feedback. Continuous monitoring of performance metrics and periodic repetition of bottleneck identification and optimization processes ensure that the architecture is always in an optimal state, capable of efficiently handling various workloads.

[0451] The optimized pipeline configuration management architecture demonstrates improvements in three aspects: more balanced resource allocation and better matching of processing capabilities at each stage, reducing resource waste and bottlenecks; more flexible and efficient scheduling strategies, which can dynamically adjust the processing order based on request characteristics and system status, improving resource utilization; and comprehensive optimization of system throughput and response time, enabling the processing of more requests and providing faster service responses under the same hardware conditions.

[0452] A key advantage of dynamic resource adjustment mechanisms is their adaptability and scalability. As business needs and load characteristics change, bottleneck locations may shift, requiring corresponding adjustments to optimization priorities. The system's automatic monitoring and adjustment capabilities ensure continuous performance optimization, avoiding the limitations of traditional static configuration. This dynamic awareness and adaptive adjustment approach significantly improves the throughput and responsiveness of optical switch configuration systems, providing more efficient network resource support for graph computing applications.

[0453] In practical deployments, machine learning techniques may be further integrated to enhance bottleneck prediction and optimization capabilities. By analyzing historical performance data and optimization results, patterns and effects of optimization decisions can be learned, gradually improving the accuracy and effectiveness of optimization decisions. For example, a mapping model between bottleneck characteristics and optimal optimization strategies can be built. When a specific type of bottleneck is identified, proven effective optimization solutions can be directly applied, reducing trial-and-error costs and accelerating the optimization process.

[0454] In summary, through systematic performance monitoring, accurate bottleneck identification, scientific performance modeling, and flexible dynamic adjustment, the pipeline bottleneck identification and dynamic resource adjustment method has enabled continuous optimization and efficient operation of the optical switch configuration system, providing a reliable guarantee for meeting the high-performance network requirements of graph computing.

[0455] Example 15

[0456] like Figure 3 As shown, the present invention also provides a graph-oriented optical switch configuration pipeline scheduling system, comprising:

[0457] The configuration request processing module 10 is used to obtain the optical path configuration request of the graph computing task. The optical path configuration request includes communication requirement parameters, task type identifier and timestamp. The module performs normalization processing on the optical path configuration request to generate standardized configuration request data.

[0458] The pipeline architecture building module 20 is used to decompose the optical switch configuration process into four functionally independent processing stages—prediction stage, verification stage, configuration stage, and confirmation stage—based on the standardized configuration request data. It configures a corresponding processor for each processing stage and realizes data transfer between processors through an asynchronous message queue to build a pipeline configuration management architecture.

[0459] The resource scheduling arbitration module 30 is used to extract task feature parameters from the standardized configuration request data according to the pipeline configuration management architecture, calculate the comprehensive priority score and sort the configuration request queue, identify the dependencies and constraints between resources, detect resource conflicts, evaluate the value of conflicting tasks based on the value function model and execute arbitration decisions, and generate a resource allocation scheme.

[0460] The configuration template generation module 40 is used to perform cluster analysis on the communication patterns of historical graph calculation tasks according to the resource allocation scheme, identify recurring communication patterns, pre-generate optical switch configuration templates for the recurring communication patterns, perform pattern matching on the input configuration requests, and call the configuration instruction when the matching is successful to generate the final configuration instruction.

[0461] The performance optimization and adjustment module 50 is used to collect performance indicators of each stage of the pipeline in real time based on the final configuration instruction, identify the stage with the lowest processing capacity as the pipeline bottleneck, dynamically adjust the resource allocation ratio and scheduling strategy parameters of each stage, and obtain an optimized pipeline configuration management architecture.

[0462] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A graph-oriented computation-based optical switch configuration pipeline scheduling method, characterized in that, include: Obtain the optical path configuration request for the graph computing task. The optical path configuration request includes communication requirement parameters, task type identifier, and timestamp. Perform normalization processing on the optical path configuration request to generate standardized configuration request data. Based on the standardized configuration request data, the optical switch configuration process is decomposed into four functionally independent processing stages: prediction, verification, configuration, and confirmation. A corresponding processor is configured for each processing stage, and data transfer between processors is achieved through asynchronous message queues, constructing a pipelined configuration management architecture. Specifically, this includes: based on the standardized configuration request data, analyzing the communication requirements of graph computing tasks; configuring a prediction processor and allocating first computing resources and a first cache space for the prediction stage (the prediction processor generates preliminary optical path planning); configuring a verification processor and allocating second computing resources and a second cache space for the verification stage (the verification processor checks the feasibility and resource availability of the preliminary optical path planning); configuring a processor and allocating third computing resources and a third cache space for the configuration stage (the configuration processor executes hardware setting instructions); configuring a confirmation processor and allocating fourth computing resources and a fourth cache space for the confirmation stage (the confirmation processor detects whether the configuration is successful), resulting in four processors and their corresponding resource configurations; and based on the four processors and their corresponding resource configurations, for... A first asynchronous message queue is configured between the prediction processor and the verification processor, a second asynchronous message queue is configured between the verification processor and the configuration processor, and a third asynchronous message queue is configured between the configuration processor and the confirmation processor. A request description format is designed, which includes a request identifier, optical path parameters, priority flags, and timestamps, thus obtaining an asynchronous communication mechanism. Based on the asynchronous communication mechanism, when the prediction processor completes the processing of a configuration request, it encapsulates the processing result into a message conforming to the request description format and puts it into the first asynchronous message queue. The prediction processor then starts processing the next configuration request. The verification processor retrieves the message from the first asynchronous message queue, verifies it, and puts the verification result into the second asynchronous message queue. The configuration processor retrieves the verification result from the second asynchronous message queue, configures it, and puts the configuration result into the third asynchronous message queue. The confirmation processor retrieves the configuration result from the third asynchronous message queue and confirms it, thereby realizing the parallel processing of multiple configuration requests in four stages, thus obtaining the pipelined configuration management architecture. Based on the pipeline configuration management architecture, task feature parameters are extracted from the standardized configuration request data, a comprehensive priority score is calculated and the configuration request queue is sorted, the dependencies and constraints between resources are identified, resource conflicts are detected, the conflicting tasks are valued based on the value function model and arbitration decisions are executed, and a resource allocation scheme is generated. According to the resource allocation scheme, cluster analysis is performed on the communication patterns of the historical graph calculation task to identify recurring communication patterns. Optical switch configuration templates are pre-generated for the recurring communication patterns. Pattern matching is performed on the input configuration requests. When a match is successful, the configuration instruction is invoked to generate the final configuration instruction. Based on the final configuration instructions, the performance indicators of each stage of the pipeline are collected in real time, the stage with the lowest processing capacity is identified as the pipeline bottleneck, and the resource allocation ratio and scheduling strategy parameters of each stage are dynamically adjusted to obtain an optimized pipeline configuration management architecture.

2. The method according to claim 1, characterized in that, Based on the aforementioned asynchronous communication mechanism, multiple configuration requests are processed in parallel across four stages, including: Based on the asynchronous communication mechanism, the prediction processor obtains a first configuration request from the configuration request queue, parses the communication requirement parameters of the first configuration request, generates a first preliminary optical path plan, encapsulates the first processing result containing the first preliminary optical path plan into a first message conforming to the request description format and puts it into the first asynchronous message queue, the prediction processor obtains a second configuration request and starts generating a second preliminary optical path plan, thus obtaining the first stage of parallel processing; According to the first stage of parallel processing, the verification processor retrieves the first message from the first asynchronous message queue, extracts the first preliminary optical path plan, checks the feasibility and resource availability of the first preliminary optical path plan, generates the first verification result and encapsulates it into the second message and puts it into the second asynchronous message queue. At the same time, the prediction processor continues to process the second configuration request, realizing the parallel execution of the prediction processor and the verification processor, and obtaining two-stage parallel processing. Based on the two-stage parallel processing, the configuration processor retrieves the second message from the second asynchronous message queue, extracts the first verification result, executes hardware setting instructions based on the first verification result, generates a first configuration result, and encapsulates it into a third message and places it into the third asynchronous message queue. The confirmation processor retrieves the third message from the third asynchronous message queue, extracts the first configuration result, and detects the configuration success condition. This enables four processors to process different stages of different configuration requests simultaneously, resulting in a complete parallel processing mechanism.

3. The method according to claim 2, characterized in that, The step of extracting task feature parameters from the standardized configuration request data based on the pipeline configuration management architecture and calculating a comprehensive priority score includes: Based on the pipeline configuration management architecture, the task type, computation priority, time urgency, and resource requirement are extracted from the standardized configuration request data. The task types are classified into real-time tasks and batch processing tasks. A first type weight is assigned to the real-time tasks, and a second type weight is assigned to the batch processing tasks. The computation priority, time urgency, and resource requirement are quantified to obtain priority scores, urgency scores, and requirement scores, thus obtaining multi-dimensional evaluation parameters. Based on the multi-dimensional evaluation parameters, the comprehensive priority score is calculated using a weighted summation algorithm. The comprehensive priority score is equal to the weighted sum of the first type weight or the second type weight, the priority score, the urgency score, and the demand score.

4. The method according to claim 3, characterized in that, The calculation of the comprehensive priority score and the sorting of the configuration request queue include: Based on the comprehensive priority score, all configuration requests in the configuration request queue are sorted from high to low according to the comprehensive priority score to obtain a pre-sorted configuration request queue. Based on the pre-sorted configuration request queue, a preemptive queue-jumping mechanism is provided for the real-time tasks. When a new real-time task arrives and its corresponding comprehensive priority score is higher than the task waiting in the queue, the new real-time task is inserted at the head of the queue. A batch processing mechanism is provided for the batch processing tasks. When the processor resource utilization is lower than a preset idle threshold, multiple batch processing tasks are combined into a batch for processing, resulting in a configuration request queue with differentiated scheduling. Based on the differentiated scheduling configuration request queue, the waiting time of each configuration request is monitored, and tasks with a comprehensive priority score lower than a preset priority threshold in the differentiated scheduling configuration request queue are identified as tasks to be promoted. When the waiting time of a task to be promoted exceeds the preset waiting threshold, the comprehensive priority score of the task to be promoted is dynamically increased. The increase in the comprehensive priority score is proportional to the waiting time, resulting in a sorted configuration request queue.

5. The method according to claim 4, characterized in that, The process of identifying dependencies and constraints between resources, detecting resource conflicts, evaluating the value of conflicting tasks based on a value function model, executing arbitration decisions, and generating resource allocation schemes includes: Based on the sorted configuration request queue, the optical switch network topology is obtained, the wavelength resources, port resources and optical path resources in the optical switch network topology are identified, the dependencies between resources are analyzed, and the constraints are determined, including that the same port cannot be allocated to multiple optical paths at the same time, the same wavelength on the same optical fiber cannot be used by multiple optical paths at the same time, and the establishment of an optical path requires that the source port and the target port are available at the same time, thus obtaining a resource dependency model. Based on the resource dependency model, a resource occupancy matrix is ​​constructed. The rows of the resource occupancy matrix correspond to configuration requests, the columns correspond to resources, and the matrix elements represent the occupancy status, including unoccupied, occupied, and reserved states. Based on the resource occupancy matrix, a resource maintenance availability time window is established. The availability time window records the resource occupancy status of each time slice from the current moment to a preset future time period. When a new configuration request arrives, the target resource required by the new configuration request is extracted, and the occupancy status of the target resource in the resource occupancy matrix and the availability time window is queried. When the occupancy status of the target resource is occupied or reserved, it is identified as a resource conflict, and a resource conflict detection result is obtained. Based on the resource conflict detection results, the value function model is constructed. The value function model comprehensively considers latency tolerance, computation priority, and historical waiting time. For configuration requests with resource conflicts, the latency tolerance, computation priority, and historical waiting time are extracted. The task value score is calculated according to the value function model. The task value scores of multiple configuration requests with resource conflicts are compared. The configuration request with the highest task value score is selected to be allocated the target resource first. The remaining configuration requests are reallocated or delayed to obtain the resource allocation scheme.

6. The method according to claim 5, characterized in that, After evaluating the value of the conflict task and executing arbitration decisions based on the aforementioned value function model, and generating the resource allocation scheme, the process further includes: Based on the resource allocation scheme, the optical switch configuration operation is performed, the configuration execution result is monitored, and when a configuration failure is detected, failure data containing failure type, occurrence stage, associated resources and environmental parameters is captured. The failure data is then structured and integrated with device logs, performance indicators and topology status to obtain multimodal failure data. Based on the multimodal failure data, data mining algorithms are applied to identify recurring failure patterns and construct a failure association graph. The failure association graph displays the causal relationships and temporal dependencies between different failure events. Cluster analysis is performed on the multimodal failure data to obtain a failure pattern library. Based on the failure mode library, extract the current feature vector for the current failure event, calculate the similarity between the current feature vector and the feature vectors of each failure mode category in the failure mode library, select the failure mode category with the highest similarity as the matching failure case, extract the historical recovery path and success rate of the matching failure case, select the historical recovery path with the highest success rate as the target recovery path, the target recovery path includes resource reallocation, configuration parameter adjustment and alternative optical path selection, and obtain a backtracking decision scheme; Based on the backtracking decision scheme, the recovery operation in the target recovery path is executed, the recovery process and recovery result are recorded, and when the recovery result meets the preset recovery success conditions, the backtracking decision scheme is added to the failure handling knowledge base, the success rate statistics of the matching failure cases in the failure mode library are updated, and the updated failure mode library is obtained.

7. The method according to claim 6, characterized in that, The applied data mining algorithm identifies recurring failure patterns and constructs a failure association graph. This graph displays the causal relationships and temporal dependencies between different failure events. Cluster analysis is then performed on the multimodal failure data to obtain a failure pattern library, including: Based on the multimodal failure data, feature vectors of failure events are extracted. The feature vectors include the failure occurrence time, failure stage identifier, resource identifier, system load status, and configuration parameter values. The feature vectors are encoded by encoding the failure stage identifier as a numerical value, encoding the resource identifier as a resource type code, and quantifying the system load status as a load percentage to obtain the encoded feature vectors. Based on the encoded feature vectors, the Apriori association rule mining algorithm is applied, a minimum support threshold and a minimum confidence threshold are set, the association relationship between the encoded feature vectors is analyzed, the support and confidence of each feature combination are calculated, and feature combinations whose support and confidence both exceed the minimum support threshold and the minimum confidence threshold are identified as repeated co-occurring failed feature combinations, thus obtaining the failure mode feature set; Based on the failure mode feature set, a directed graph structure is constructed. Each failure event in the failure mode feature set is used as a node. The failure occurrence time of the failure event is extracted. When the failure occurrence time of the first failure event is earlier than the failure occurrence time of the second failure event and the time difference is less than a preset time window, a temporal dependency edge from the first failure event to the second failure event is established. When the resource identifier involved in the first failure event is a precondition of the second failure event, a causal relationship edge is established to obtain the failure association graph. Based on the failure association graph, the Louvain graph clustering algorithm is applied to identify modular communities in the failure association graph. Each modular community corresponds to a failure mode category. A mode description is generated for each failure mode category to obtain the failure mode library.

8. The method according to claim 3, characterized in that, Based on the standardized configuration request data, the optical switch configuration process is decomposed into four functionally independent processing stages: prediction, verification, configuration, and confirmation. The prediction stage generates preliminary optical path planning by analyzing the communication requirements of the task through a prediction processor, including: Based on the standardized configuration request data, the prediction processor parses the communication requirement parameters, extracts the source node, target node, bandwidth requirement and latency requirement, obtains the current optical network topology status and resource availability information, and generates network status data. Based on the network state data, a heuristic search algorithm is applied to generate multiple candidate optical path configuration schemes. Each candidate optical path configuration scheme includes an optical path, wavelength allocation, and port allocation. The performance indicators of each candidate optical path configuration scheme are calculated, including estimated latency, resource consumption, and path hop count, to generate a candidate scheme set. Based on the candidate scheme set, a multi-dimensional scheme evaluation framework is constructed to score each candidate optical path configuration scheme from the perspectives of throughput, latency, and resource efficiency. The candidate optical path configuration scheme with the highest score is selected as the preliminary optical path planning, and prediction stage output data is generated. Based on the output data of the prediction stage, during the configuration process of the prediction processor, the deviation between the actual configuration effect and the prediction result is monitored in real time. When the deviation exceeds a preset threshold, the configuration parameter fine-tuning is triggered to dynamically adjust the wavelength allocation or path selection in the preliminary optical path planning, so as to obtain the self-corrected optical path planning.

9. The method according to claim 8, characterized in that, The step involves constructing a multi-dimensional scheme evaluation framework based on the candidate scheme set, scoring each candidate optical path configuration scheme from the perspectives of throughput, latency, and resource efficiency, and selecting the candidate optical path configuration scheme with the highest score as the initial optical path planning, including: Based on the candidate scheme set, a throughput score is calculated for each candidate optical path configuration scheme, the throughput score being based on the maximum data transmission rate that the candidate optical path configuration scheme can support; a latency score is calculated, the latency score being based on the end-to-end transmission latency of the candidate optical path configuration scheme; and a resource efficiency score is calculated, the resource efficiency score being based on the number of wavelengths and ports occupied by the candidate optical path configuration scheme, generating multi-dimensional scoring data. Based on the multi-dimensional scoring data, a comprehensive score is calculated for each candidate optical path configuration scheme. The comprehensive score is a weighted sum of the throughput score, the latency score, and the resource efficiency score. All candidate optical path configuration schemes are sorted according to the comprehensive score to generate a scoring ranking result. Based on the scoring and ranking results, an automatic stopping condition is set. The automatic stopping condition includes the difference between the comprehensive score of the current optimal solution and the comprehensive score of the second-best solution being greater than a preset improvement threshold, or the search time exceeding the time budget determined according to the task type. When the automatic stopping condition is met, the solution search is stopped, and the candidate optical path configuration scheme with the highest comprehensive score in the scoring and ranking results is selected as the preliminary optical path planning to obtain the prediction stage output data.

10. The method according to claim 1, characterized in that, Before calculating the comprehensive priority score by extracting task feature parameters from the standardized configuration request data according to the pipeline configuration management architecture, the process also includes: Based on the standardized configuration request data and historical configuration data, a causal graph model for optical network resource allocation is constructed. The causal graph model includes causal variable nodes and causal relationship edges. The causal variable nodes include task priority, resource availability, network load, and configuration success rate. Variable values ​​are extracted from the historical configuration data, and causal relationship parameters are learned by applying structural equation modeling to obtain a causal knowledge base. Based on the causal knowledge base, for the input configuration request, the causal inference engine is applied to calculate the impact of different priority assignments on the configuration success rate based on the causal graph model. Causal variable nodes directly related to the configuration success rate are extracted from the causal graph model. The causal effect strength of each causal variable node on the configuration success rate is calculated. The causal variable node with the strongest causal effect strength is identified as the key causal factor, and the causal analysis results are obtained. Based on the causal analysis results, the weight coefficients of the task feature parameters in the calculation of the comprehensive priority score are adjusted according to the key causal factors, and a decision boundary representation model is constructed. The decision boundary representation model defines the effective value range of the comprehensive priority score. When the network load status changes, the decision boundary of the decision boundary representation model is adjusted through a causal intervention mechanism to obtain an optimized priority evaluation model.

11. The method according to claim 10, characterized in that, After adjusting the weight coefficients of the task feature parameters in the comprehensive priority score calculation based on the key causal factors and constructing the decision boundary representation model, the process includes: Based on the decision boundary representation model, within the effective range of the comprehensive priority score, the optimization problem of the weight coefficients is modeled as a constrained optimization problem. The objective function is to maximize the configuration success rate, and the constraint condition is that the sum of the weight coefficients is 1 and all are greater than 0. The optimal weight combination is solved iteratively by applying the optimization algorithm, and the weight coefficients in the optimized priority evaluation model are updated to obtain the updated priority evaluation model. Based on the updated priority evaluation model, at preset intervals, the system throughput, average latency, and configuration success rate before and after adopting the causal intervention mechanism are compared to calculate the performance improvement percentage. When the performance improvement percentage is lower than a preset validity threshold, the causal inference engine is re-executed, the causal effect strength is recalculated based on the causal graph model, the key causal factors are updated, the values ​​of the causal variable nodes set in the causal intervention mechanism are adjusted, and the effective value range of the comprehensive priority score is updated to obtain a continuously optimized priority evaluation model.

12. The method according to claim 1, characterized in that, The step of performing cluster analysis on the communication patterns of historical graph calculation tasks according to the resource allocation scheme, identifying recurring communication patterns, and pre-generating optical switch configuration templates for the recurring communication patterns includes: Based on the resource allocation scheme, communication pattern data of historical graph computing tasks are collected from historical configuration records. The communication pattern data includes computing type, data flow topology, communication node pairs and traffic characteristics. Feature vectors of the communication pattern data are extracted, and clustering algorithms are applied to perform cluster analysis on the feature vectors to identify the communication patterns corresponding to the cluster centers, thereby obtaining a graph computing pattern feature library. Based on the graph computing pattern feature library, an optical switch configuration process is executed for each communication pattern identified in the graph computing pattern feature library. The optical path planning parameters generated in the prediction stage, the resource check results in the verification stage, the hardware setting instructions in the configuration stage, and the verification steps in the confirmation stage are recorded. The optical path planning parameters, the resource check results, the hardware setting instructions, and the verification steps are encapsulated into an optical switch configuration template. Applicable condition tags and resource requirement descriptions are added to the optical switch configuration template to obtain a configuration template library. Based on the configuration template library, a multi-dimensional index structure is established. When a new configuration request is received, the calculation type, data flow topology, and traffic characteristics of the new configuration request are extracted. The multi-dimensional index structure is used to search the configuration template library. The feature similarity between the new configuration request and each optical switch configuration template in the configuration template library is calculated. The optical switch configuration template with the highest feature similarity is selected as the matching configuration template to obtain the matching result. Based on the matching result, the actual parameters of the new configuration request are extracted, and the actual parameters are used to replace the parameter placeholders in the matched configuration template. It is verified whether the replaced optical path planning parameters are available in the current network topology, and whether the replaced resource check results conflict with the current resource status. When the verification is successful, the final configuration instruction is generated based on the matched configuration template.

13. The method according to claim 1, characterized in that, Based on the final configuration command, the system collects performance metrics for each stage of the pipeline in real time, identifies the stage with the lowest processing capacity as the pipeline bottleneck, and dynamically adjusts the resource allocation ratio and scheduling strategy parameters for each stage, including: Based on the final configuration instruction, the entry time, start time and completion time of each configuration request at each stage are recorded in real time. The processing time is calculated, and the average processing time is calculated as the average processing time. The length changes of the waiting queue at each stage are monitored to obtain performance monitoring data. Based on the performance monitoring data, the processing capacity of each stage is calculated. The processing capacity is defined as the number of configuration requests completed per unit time. The processing capacity of each stage is compared, and the stage with the smallest processing capacity is identified as the potential bottleneck stage. The waiting queue length of the potential bottleneck stage is analyzed. When the waiting queue length of the potential bottleneck stage continues to increase within a consecutive preset time window, the potential bottleneck stage is confirmed as the pipeline bottleneck, and the bottleneck identification result is obtained. Based on the bottleneck identification results, a performance bottleneck model is constructed. The performance bottleneck model quantifies the impact of the pipeline bottleneck on the overall system throughput. Through simulation experiments, the processing capacity of the pipeline bottleneck is increased by a preset percentage. The overall system throughput after the increase is evaluated, and a bottleneck analysis report is obtained. Based on the bottleneck analysis report, an optimization strategy is determined, the resource allocation ratio of the bottleneck stage of the pipeline is dynamically adjusted, and the scheduling strategy parameters are adjusted to obtain the optimized pipeline configuration management architecture.

14. A graph-oriented optical switch configuration pipeline scheduling system, using the graph-oriented optical switch configuration pipeline scheduling method as described in any one of claims 1-13, characterized in that, Includes the following modules: The configuration request processing module is used to obtain the optical path configuration request of the graph computing task. The optical path configuration request includes communication requirement parameters, task type identifier and timestamp. The module performs normalization processing on the optical path configuration request to generate standardized configuration request data. The pipeline architecture construction module is used to decompose the optical switch configuration process into four functionally independent processing stages—prediction, verification, configuration, and confirmation—based on the standardized configuration request data. A corresponding processor is configured for each processing stage, and data transfer between processors is achieved through asynchronous message queues, thus constructing a pipeline configuration management architecture. Specifically, it includes: analyzing the communication requirements of graph computation tasks based on the standardized configuration request data; configuring a prediction processor and allocating first computing resources and a first cache space for the prediction stage (the prediction processor generates preliminary optical path planning); configuring a verification processor and allocating second computing resources and a second cache space for the verification stage (the verification processor checks the feasibility and resource availability of the preliminary optical path planning); configuring a processor and allocating third computing resources and a third cache space for the configuration stage (the configuration processor executes hardware setting instructions); configuring a confirmation processor and allocating fourth computing resources and a fourth cache space for the confirmation stage (the confirmation processor detects whether the configuration is successful), resulting in four processors and their corresponding resource configurations; and configuring the four processors and their corresponding resource configurations. According to resource allocation, a first asynchronous message queue is configured between the prediction processor and the verification processor, a second asynchronous message queue is configured between the verification processor and the configuration processor, and a third asynchronous message queue is configured between the configuration processor and the confirmation processor. A request description format is designed, which includes a request identifier, optical path parameters, priority flags, and timestamps, thus obtaining an asynchronous communication mechanism. Based on the asynchronous communication mechanism, when the prediction processor completes the processing of a configuration request, it encapsulates the processing result into a message conforming to the request description format and puts it into the first asynchronous message queue. The prediction processor then starts processing the next configuration request. The verification processor retrieves the message from the first asynchronous message queue, verifies it, and puts the verification result into the second asynchronous message queue. The configuration processor retrieves the verification result from the second asynchronous message queue, configures it, and puts the configuration result into the third asynchronous message queue. The confirmation processor retrieves the configuration result from the third asynchronous message queue and confirms it, thereby realizing the parallel processing of multiple configuration requests in four stages, thus obtaining the pipelined configuration management architecture. The resource scheduling arbitration module is used to extract task feature parameters from the standardized configuration request data according to the pipeline configuration management architecture, calculate the comprehensive priority score and sort the configuration request queue, identify the dependencies and constraints between resources, detect resource conflicts, evaluate the value of conflicting tasks based on the value function model and execute arbitration decisions, and generate a resource allocation scheme. The configuration template generation module is used to perform cluster analysis on the communication patterns of historical graph calculation tasks according to the resource allocation scheme, identify recurring communication patterns, pre-generate optical switch configuration templates for the recurring communication patterns, perform pattern matching on the input configuration requests, and call the configuration instruction when the matching is successful to generate the final configuration instruction. The performance optimization and adjustment module is used to collect performance indicators of each stage of the pipeline in real time based on the final configuration instruction, identify the stage with the lowest processing capacity as the pipeline bottleneck, and dynamically adjust the resource allocation ratio and scheduling strategy parameters of each stage to obtain an optimized pipeline configuration management architecture.

Images