Dynamic resource scheduling method based on software-defined networks

Abstract

This application discloses a dynamic resource scheduling method based on software-defined networks (SDN), belonging to the field of network technology. By dynamically sensing the resource reservation behavior of each network domain, it identifies deviations in the understanding of user intent and uses this to calibrate the intent parsing benchmark, thus solving the problem of the disconnect between intent parsing and actual resource supply capacity in traditional SDN. As a result, the collaborative controller can continuously optimize its understanding of user intent, making subsequent cross-domain service flow scheduling decisions more aligned with the actual network resource status, reducing scheduling conflicts caused by intent misunderstanding deviations, and improving the accuracy and efficiency of cross-domain resource scheduling.

Description

Technical Field

[0001] This application relates to the field of network technology, and in particular to a method for dynamic resource scheduling based on software-defined networking. Background Technology

[0002] Software-defined networking (SDN) separates the control plane from the data plane, enabling centralized management and programmable scheduling of cross-domain resources. In related technologies, after receiving user intents, the collaborative controller parses the intents into scheduling constraints and distributes them to each network domain for execution. Each network domain then reserves resources based on its internal resource status, forming a unidirectional mapping link from intent to configuration.

[0003] The aforementioned one-way mapping mechanism has inherent flaws: Figure 1 Once the intent is parsed and distributed, changes in the actual resource supply capacity of each network domain no longer affect the way the intent is understood. The collaborative controller continuously uses a fixed intent parsing benchmark in multiple rounds of scheduling, and is unaware of the differences in the actual responses of each network domain to the same intent. When the scheduling execution result deviates from the intent expectation, this deviation information is only used to evaluate the execution effect and does not reversely correct the intent parsing method.

[0004] The aforementioned defects cause a persistent disconnect between the intent resolution benchmark of the collaborative controller and the actual resource supply capacity of each network domain. This results in repeated conflicts of the same type during cross-domain resource scheduling in multiple rounds of execution, and the conflicts cannot be automatically reduced as the number of scheduling rounds increases. Summary of the Invention

[0005] This application provides a method for dynamic resource scheduling based on software-defined networking, the technical solution of which is as follows: On the one hand, a resource dynamic scheduling method based on software-defined networking is provided, executed by the cooperative controller of the software-defined network, the method comprising: In response to the scheduling request of cross-domain service flow, the latency constraints and bandwidth requirements described by the user intent corresponding to the cross-domain service flow, as well as the amount of resources actually reserved by each network domain in the current scheduling round to meet the user intent, are compared and processed to obtain the inter-domain resource reservation behavior representation of each network domain. The persistent characteristics of the inter-domain resource reservation behavior in multi-round scheduling are correlated with the user intent to determine the comprehension bias patterns of each network domain in relation to the service level requirements described by the user intent. Using the understanding bias pattern and the user intent as joint inputs, a reverse calibration operation is performed on the intent parsing benchmark to obtain a calibrated intent parsing benchmark, which adjusts the semantic mapping threshold in the intent parsing benchmark corresponding to the service level requirement towards the actual resource supply capacity of each network domain. The user intents to be processed in the next scheduling round are semantically parsed based on the calibrated intent parsing benchmark, and the parsing results are used to drive the cross-domain path selection and cross-domain resource allocation of the cross-domain business flow. Attached Figure Description

[0006] 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.

[0007] Figure 1 This is a flowchart of a resource dynamic scheduling method based on software-defined networking provided in an embodiment of this application; Figure 2 This is a flowchart of another resource dynamic scheduling method based on software-defined networking provided in the embodiments of this application; Figure 3 This is a flowchart of another resource dynamic scheduling method based on software-defined networking provided in the embodiments of this application; Figure 4 This is a flowchart of another resource dynamic scheduling method based on software-defined networking provided in the embodiments of this application; Figure 5 This is a flowchart of another resource dynamic scheduling method based on software-defined networking provided in the embodiments of this application. Detailed Implementation

[0008] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0009] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor are there any restrictions on quantity or execution order.

[0010] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0011] In related technologies, when software-defined networks (SDNs) perform cross-domain resource scheduling, the coordinating controller receives user intentions, parses them into scheduling constraints, and distributes them to each network domain for execution. However, this one-way mapping mechanism has an inherent flaw: once the intention resolution benchmark is determined, it cannot perceive changes in the actual resource supply capacity of each network domain, leading to a continuous disconnect between the intention resolution benchmark and the actual resource supply capacity. Consequently, similar conflicts repeatedly occur in multiple rounds of cross-domain resource scheduling, and these conflicts do not automatically decrease with the increase of scheduling rounds, affecting scheduling efficiency and resource utilization.

[0012] To address this, this application proposes a dynamic resource scheduling method based on software-defined networks (SDNs), executed by the cooperative controller of the SDN. The method includes: In response to the scheduling request of cross-domain service flow, the latency constraints and bandwidth requirements described by the user intent corresponding to the cross-domain service flow, as well as the amount of resources actually reserved by each network domain in the current scheduling round to meet the user intent, are compared to obtain the inter-domain resource reservation behavior representation of each network domain.

[0013] A correlation analysis was conducted between the persistent characteristics of inter-domain resource reservation behavior representation in multi-round scheduling and user intent to identify the misunderstanding patterns of service level requirements described by user intent in each network domain.

[0014] Using the understanding bias pattern and user intent as joint inputs, a reverse calibration operation is performed on the intent parsing benchmark to obtain a calibrated intent parsing benchmark. This adjusts the semantic mapping thresholds in the intent parsing benchmark corresponding to service level requirements towards the actual resource supply capacity of each network domain.

[0015] The user intents to be processed in the next scheduling round are semantically parsed based on the calibrated intent parsing benchmark, and the parsing results are used to drive the cross-domain path selection and cross-domain resource allocation for cross-domain business flows.

[0016] For ease of understanding, the following explains some key terms in this embodiment: Software-defined networking (SDN) is a new type of network architecture. Its core idea is to separate the network control plane from the data plane and use a centralized controller to manage and flexibly schedule network resources.

[0017] The coordination controller is a core component in software-defined networking. It is responsible for receiving service requests from users or applications, converting them into network-executable scheduling instructions, and coordinating resource allocation and path selection among multiple network domains to achieve end-to-end deployment of cross-domain services.

[0018] Cross-domain service flows refer to network service data flows that need to traverse multiple independent management or technical domains. These service flows typically have specific quality of service requirements, such as latency and bandwidth.

[0019] User intent refers to an abstract description of a user's or application's quality of service (QoS) for the network. It is usually expressed in natural language or structured text and includes requirements for service levels such as latency, bandwidth, and reliability.

[0020] Latency constraints refer to the upper limit requirements that users intend for the end-to-end transmission latency of a service flow, such as requiring the latency to be lower than a certain specific value.

[0021] Bandwidth requirement refers to the lower limit of the bandwidth that a user intends to require for the transmission of a service flow, such as requiring bandwidth to be higher than a certain value.

[0022] Inter-domain resource reservation behavior representation is a quantitative indicator generated by the collaborative controller by comparing user intent with the actual resource reservation status of each network domain. It is used to reflect the actual behavioral characteristics of each network domain in meeting user intent, such as whether there is excessive or insufficient resource reservation.

[0023] Service level requirements are a core component of user intent, specifically describing the performance requirements of service flows in terms of latency, bandwidth, jitter, packet loss rate, etc.

[0024] The understanding deviation pattern is a systematic and persistent deviation identified by the collaborative controller in the understanding and execution of service level requirements described by user intent in each network domain, which is determined by analyzing the resource reservation behavior of each network domain.

[0025] Intent resolution baseline is a set of rules or models used by the collaborative controller to transform abstract service level requirements in user intents into specific network scheduling parameters, which includes a series of semantic mapping thresholds.

[0026] The semantic mapping threshold is a key parameter in the intent parsing benchmark, used to define the conversion boundary or range between ambiguous semantics in user intent (such as "low latency" or "high bandwidth") and specific numerical network parameters.

[0027] This embodiment provides a resource dynamic scheduling method based on software-defined networking, the execution of which is completed by the cooperative controller of the software-defined network. See [link to relevant documentation]. Figure 1 This includes the following steps.

[0028] 101. In response to the scheduling request of cross-domain business flow, the latency constraints and bandwidth requirements described by the user intent corresponding to the business flow, as well as the amount of resources actually reserved by each network domain in the current scheduling round to meet the user intent, are compared and processed to obtain the inter-domain resource reservation behavior representation of each network domain.

[0029] Specifically, the coordination controller can obtain the latency constraints and bandwidth requirements in the user's intent, and simultaneously collect the actual latency and bandwidth resources reserved by each network domain for that service flow in the current scheduling round. By calculating a simple ratio or difference between the actual reserved resources of each network domain and the user's intent requirements—for example, dividing the actual reserved bandwidth by the required bandwidth—and comparing the actual provided latency capability with the latency constraints, a numerical value or status identifier reflecting the resource reservation behavior of that network domain is directly generated as a representation of inter-domain resource reservation behavior. For example, if the actual reserved bandwidth far exceeds the demand, the representation may indicate "over-reservation." If the actual reserved bandwidth is insufficient, the representation may indicate "under-reservation."

[0030] 102. Correlation analysis of the persistent characteristics of inter-domain resource reservation behavior representation in multi-round scheduling with user intent is conducted to determine the comprehension bias patterns of each network domain in relation to the service level requirements described by user intent.

[0031] For example, the coordination controller can track the inter-domain resource reservation behavior of each network domain across multiple consecutive scheduling rounds. For instance, if a network domain's inter-domain resource reservation behavior indicates "over-reservation" in three consecutive scheduling rounds, it can be identified as a persistent characteristic. This persistent characteristic is then directly compared to the service level requirements in the user's intent. For example, if the user's intent is "low latency," but the network domain consistently exhibits "over-reservation" of latency resources, it can be preliminarily determined that the network domain has a misunderstanding of "low latency," and this can be identified as a misunderstanding pattern, such as a "latency over-reservation bias pattern."

[0032] 103. Using the understanding bias pattern and user intent as joint inputs, perform a reverse calibration operation on the intent parsing benchmark to obtain a calibrated intent parsing benchmark, so that the semantic mapping threshold corresponding to the service level requirements in the intent parsing benchmark is adjusted in the direction of the actual resource supply capacity of each network domain.

[0033] Specifically, when a pattern such as "excessive latency reservation deviation" is identified, the coordination controller adjusts the semantic mapping threshold related to latency service level requirements in the intent resolution benchmark based on this pattern. For example, if the pattern indicates that the network domain tends to over-reserve latency resources, the coordination controller can adjust the threshold in the intent resolution benchmark that maps "low latency" to a specific latency value by a fixed percentage, such as reducing the threshold by 5%. Conversely, if the pattern indicates "insufficient latency reservation deviation," the threshold can be adjusted by a fixed percentage. User intent is used in this process to clarify whether the adjustment is targeting specific service level indicators such as latency or bandwidth.

[0034] 104. Semantically parse the user intents to be processed in the next scheduling round based on the calibrated intent parsing benchmark, and use the parsing results to drive the cross-domain path selection and cross-domain resource allocation for cross-domain business flows.

[0035] For example, when a new cross-domain service flow scheduling request arrives, the coordination controller uses the intent resolution benchmark updated by the aforementioned reverse calibration operation to semantically parse the user intent. For instance, the description of "high bandwidth" in the user intent will be converted into a more accurate bandwidth value that is closer to the actual network capacity through the calibrated intent resolution benchmark. The coordination controller uses these parsed specific values ​​as scheduling constraints, selects paths that meet these constraints from the available cross-domain paths, and reserves and allocates resources on these paths according to the resource availability status of each network domain, thereby completing the deployment of cross-domain service flows.

[0036] This application addresses the disconnect between intent resolution and actual resource supply capacity in traditional software-defined networks by dynamically sensing the resource reservation behavior of each network domain, identifying deviations in its understanding of user intent, and using this to calibrate the intent resolution benchmark. As a result, the collaborative controller can continuously optimize its understanding of user intent, making subsequent cross-domain service flow scheduling decisions more aligned with the actual network resource status, reducing scheduling conflicts caused by intent interpretation deviations, and improving the accuracy and efficiency of cross-domain resource scheduling.

[0037] In some of the solutions mentioned above in this application, a comparison is made between the latency constraints and bandwidth requirements described by the user intent and the actual amount of resources reserved by each network domain to obtain a representation of the resource reservation behavior between domains, which is used to characterize the resource reservation behavior of each network domain. However, in its implementation process, without a specific comparison method, it may not be possible to fully and accurately quantify the resource reservation behavior, resulting in inaccurate subsequent deviation analysis and inability to resolve resource scheduling conflicts.

[0038] To address this, this application further proposes a dynamic resource scheduling method based on software-defined networking. This method compares the latency constraints and bandwidth requirements described by the user intent corresponding to cross-domain service flows with the actual amount of resources reserved by each network domain in the current scheduling round to satisfy the user intent, thereby obtaining a representation of the inter-domain resource reservation behavior of each network domain. (See [link to relevant documentation]). Figure 2 Specifically, it includes the following steps: 201. First, compare the amount of resources actually reserved by each network domain to meet the user's intent with the latency constraints and bandwidth requirements described by the user's intent to obtain the positive resource mapping matching degree of each network domain.

[0039] The first comparison aims to assess the degree of alignment between the actual resources reserved in each network domain and the user's explicitly stated service level requirements (such as latency and bandwidth). A higher positive resource mapping match indicates a more accurate response from the network domain to the user's intent. In practice, this can be achieved in several ways. For example, one approach is to calculate the degree of alignment between the actual reserved resources and each performance metric in the user's intent (such as latency cap or bandwidth cap), and then synthesize the results using a weighted average or minimum value to obtain the positive resource mapping match. Another approach is to construct a multi-dimensional matching function that takes the actual reserved resources and the user's intent requirements as input and outputs a match score between 0 and 1, with a higher score indicating a better match. A penalty factor can be applied to cases where the user's intent is not met.

[0040] 202. Perform a second comparison between the amount of available resources reported by each network domain in the current scheduling round and the amount of resources actually reserved by each network domain to obtain the reverse resource sufficiency of each network domain.

[0041] The second comparison measures the rationality and efficiency of each network domain's resource reservation behavior in fulfilling user intent, i.e., whether there is over-reservation or under-reservation. Reverse resource sufficiency reflects the network domain's remaining resources or the elasticity of resource utilization after meeting business needs. In practice, this can be achieved in various ways. For example, one approach is to calculate the ratio of actual reserved resources to available resources within the domain. A ratio that is too high may indicate resource shortages or over-utilization, while a ratio that is too low may indicate resource waste or under-reservation. Another approach is to analyze historical data to establish a resource utilization model, comparing the current actual reservation amount with the model's predicted reasonable utilization range to assess reverse resource sufficiency. For instance, if the actual reservation amount is far below the available amount, the sufficiency is high, but efficiency may be low. If it is close to the available amount, the sufficiency is low, but efficiency may be high.

[0042] 203. Combine the forward resource mapping matching degree and reverse resource sufficiency of each network domain, and integrate the differences in the forward resource mapping matching degree between each network domain to obtain the inter-domain resource reservation behavior representation of each network domain.

[0043] This step aims to combine the matching accuracy and resource efficiency of a single network domain with the coordination between cross-network domains to form a comprehensive behavioral profile. In practice, this can be achieved in several ways. For example, one approach is to perform a weighted sum or multiplication of the forward resource mapping matching degree and the reverse resource sufficiency degree to obtain the preliminary behavioral components for each network domain. Then, the statistical dispersion (e.g., standard deviation) of the forward resource mapping matching degree for all network domains is calculated, and this dispersion is used as a correction factor incorporated into the preliminary behavioral components to reflect the consistency of cross-domain behavior. Another approach is to construct a multi-objective optimization function that takes the forward resource mapping matching degree, the reverse resource sufficiency degree, and the cross-domain matching difference as inputs. The function outputs a comprehensive inter-domain resource reservation behavior representation that can simultaneously reflect the performance of a single domain and the status of cross-domain collaboration.

[0044] The above technical solution enables a comprehensive and accurate quantification of resource reservation behavior across network domains. The first comparison directly assesses the degree to which each network domain fulfills user intent, ensuring the accuracy of intent response. The second comparison further evaluates the rationality and efficiency of resource reservation in each network domain, avoiding resource waste or excessive strain. By combining and integrating the differences in positive resource mapping matching degrees between network domains, this application not only obtains the behavioral characteristics of individual network domains but also reveals potential inconsistencies or conflicts in cross-domain collaboration, thus forming a multi-dimensional, high-precision representation of inter-domain resource reservation behavior. This refined representation provides a solid data foundation for subsequent identification of patterns of misunderstanding of user intent by each network domain, enabling the collaborative controller to more accurately diagnose the root cause of problems and perform targeted intent parsing benchmark calibration operations. This resolves recurring conflicts in cross-domain resource scheduling, improving the intelligence and adaptability of resource scheduling.

[0045] In some of the solutions described above in this application, a first comparison is made between the actual reserved resource amount and the user's intended latency constraints and bandwidth requirements to obtain a positive resource mapping matching degree. However, in its implementation, if only an overall comparison is performed, it may not be able to accurately capture deficiencies in either latency or bandwidth. In particular, when the resource reservation amount in a certain dimension is lower than a preset threshold, the overall matching degree may be incorrectly overestimated, leading to resource scheduling decisions based on inaccurate matching information, thereby exacerbating cross-domain scheduling conflicts.

[0046] To this end, this application further proposes to first compare the amount of resources actually reserved by each network domain to satisfy the user's intent with the latency constraints and bandwidth requirements described by the user's intent, and obtain the positive resource mapping matching degree of each network domain, including: Based on the latency constraint described by the user's intent, the latency guarantee resource amount is extracted from the actual reserved resource amount in each network domain to guarantee the latency constraint.

[0047] The amount of resources guaranteed by the delay is compared with the delay constraint to obtain the delay dimension matching sub-quantity.

[0048] Based on the bandwidth requirements described by the user's intent, the bandwidth guarantee resources are extracted from the actual reserved resources of each network domain to ensure the bandwidth requirements.

[0049] By comparing the guaranteed bandwidth resources with the bandwidth requirement, a matching sub-quantity for the bandwidth dimension is obtained.

[0050] The latency dimension matching subquantity and the bandwidth dimension matching subquantity are coupled to obtain the forward resource mapping matching degree for each network domain. This coupling process applies suppression correction to the forward resource mapping matching degree when either dimension matching subquantity is lower than its corresponding preset threshold. When both dimension matching subquantities are not lower than their corresponding preset thresholds, the average of the latency dimension matching subquantity and the bandwidth dimension matching subquantity is taken as the forward resource mapping matching degree.

[0051] For example, when extracting latency-guaranteed resources from the actual reserved resources of each network domain based on the latency constraints described by the user's intent, this step aims to accurately identify and isolate the portion of resources actually allocated by each network domain to meet specific latency requirements. In practice, the coordination controller can filter resources explicitly marked as being used to guarantee low-latency services by querying the resource reservation records reported by each network domain, based on the latency constraints in the user's intent. Examples include the buffer size of a specific queue, priority scheduling bandwidth, or the computing power of a dedicated processing unit. Furthermore, a preset mapping relationship between resource types and latency-guaranteed capabilities can be used to convert general resource quantities into their equivalent latency-guaranteed capabilities, thereby extracting the latency-guaranteed resource quantities.

[0052] When comparing the latency guarantee resource quantity with the latency constraint to obtain the latency dimension matching sub-quantity, this step is used to quantify the degree to which each network domain satisfies the user's intent in the latency dimension. For example, the collaborative controller can numerically compare the extracted latency guarantee resource quantity with the latency constraint set by the user intent. For instance, it can calculate the ratio between the latency guarantee resource quantity and the latency constraint, or calculate the reciprocal of the difference between the two, to generate a matching score between 0 and 1. The higher the score, the closer the latency guarantee capability is to or exceeds the latency constraint. Another approach is to define a piecewise function that directly maps the relative magnitude of the latency guarantee resource quantity and the latency constraint to a preset latency dimension matching sub-quantity level.

[0053] When extracting bandwidth guarantee resources from the actual reserved resources of each network domain based on the bandwidth demand described by the user's intent, this step is similar to the extraction of latency guarantee resources, focusing on identifying the resources actually allocated by each network domain to meet specific bandwidth requirements. The coordinating controller can identify resources for guaranteeing specific data transmission rates from the resource reservation records of each network domain based on the bandwidth demand in the user's intent; for example, dedicated bandwidth for links, traffic shaper capacity, or bandwidth quotas for virtual network slices. Alternatively, a mapping model between resource types and bandwidth guarantee capabilities can be established to transform general resource quantities into their equivalent bandwidth guarantee capabilities, thereby extracting bandwidth guarantee resources.

[0054] When comparing the guaranteed bandwidth resources with the bandwidth requirement to obtain the bandwidth-dimensional matching sub-quantity, this step aims to quantify the degree to which each network domain meets the user's intent in the bandwidth dimension. For example, the coordinating controller can numerically compare the extracted guaranteed bandwidth resources with the bandwidth requirement set by the user's intent. For instance, it can calculate the ratio between the guaranteed bandwidth resources and the bandwidth requirement, or calculate the relative difference between the two, to generate a matching score between 0 and 1. A higher score indicates that the bandwidth guarantee capability is closer to or exceeds the bandwidth requirement. Alternatively, it can use fuzzy logic reasoning to map the matching degree between the guaranteed bandwidth resources and the bandwidth requirement to the membership degree of a fuzzy set, thereby obtaining the bandwidth-dimensional matching sub-quantity.

[0055] When coupling the matching sub-quantities of the latency dimension and the bandwidth dimension to obtain the positive resource mapping matching degree for each network domain, this coupling process applies a suppression correction to the positive resource mapping matching degree if the matching sub-quantity of either dimension is lower than the corresponding preset threshold. When the matching sub-quantities of both dimensions are not lower than the corresponding preset thresholds, the average of the matching sub-quantities of the latency dimension and the bandwidth dimension is taken as the positive resource mapping matching degree. This step aims to comprehensively consider the matching situation of both latency and bandwidth dimensions to generate a comprehensive positive resource mapping matching degree. The core of the coupling process lies in its non-linear correction mechanism; that is, when the matching sub-quantity of either dimension (latency or bandwidth) fails to meet the preset minimum requirement (preset threshold), even if the other dimension performs well, the overall matching degree will be reduced or suppressed. For example, a suppression factor can be set, and when the suppression condition is triggered, the matching degree is multiplied by this factor, or the matching degree can be directly set to a low fixed value. When both dimensions meet their respective preset thresholds, a more balanced calculation method is adopted, such as taking the arithmetic mean of the matching sub-quantities of the two dimensions, to reflect the overall good matching status. This approach ensures that overall resource allocation capabilities are not overestimated when there are shortcomings in key performance indicators.

[0056] Through the above technical solution, when performing the first comparison of user intent in cross-domain service flows, instead of simply conducting a coarse-grained overall comparison, the resource reservation is refined into latency-guaranteed resource quantity and bandwidth-guaranteed resource quantity, and then compared with the latency constraints and bandwidth requirements in the user intent, thereby obtaining latency-dimensional matching sub-quantities and bandwidth-dimensional matching sub-quantities. This multi-dimensional and refined comparison method can accurately capture the resource supply insufficiency of each network domain in either latency or bandwidth dimension, avoiding information distortion that may be caused by overall comparison. Furthermore, by coupling these two dimension matching sub-quantities, especially by applying suppression correction when the matching sub-quantity of either dimension is lower than a preset threshold, it effectively prevents the overall positive resource mapping matching degree from being incorrectly overestimated when there is a shortcoming in a certain key dimension. This enables the collaborative controller to obtain more accurate and reliable resource matching information, thereby making decisions based on more accurate input during subsequent processes such as understanding bias patterns and intent parsing benchmark calibration. This improves the accuracy and effectiveness of cross-domain resource scheduling, reduces scheduling conflicts caused by inaccurate resource matching information, and ultimately optimizes the dynamic resource scheduling performance in the entire software-defined network environment.

[0057] In some of the embodiments described above in this application, a second comparison is made between the amount of available resources reported by each network domain in the current scheduling round and the amount of resources actually reserved by each network domain to obtain the reverse resource sufficiency of each network domain, which is used to calculate the inter-domain resource reservation behavior representation. However, in its implementation, if the calculation of resource sufficiency does not take into account the mutual constraints between different resource dimensions, it may lead to overly optimistic or partial resource assessment results, which may fail to truly capture the resource bottleneck status of the network domain, thereby affecting the accuracy of subsequent intent parsing and adjustment.

[0058] To address this, this application further proposes a second comparison between the available resources reported by each network domain in the current scheduling round and the actual reserved resources of each network domain, to obtain the reverse resource sufficiency of each network domain. Specifically, this includes: extracting the available latency resources and available bandwidth resources from the available resources reported by each network domain in the current scheduling round; extracting the actually used latency resources and actually used bandwidth resources from the actual reserved resources of each network domain; comparing the available latency resources with the actually used latency resources to obtain a latency-dimensional sufficiency sub-quantity; comparing the available bandwidth resources with the actually used bandwidth resources to obtain a bandwidth-dimensional sufficiency sub-quantity; and comprehensively processing the latency-dimensional and bandwidth-dimensional sufficiency sub-quantities to obtain the reverse resource sufficiency of each network domain. This comprehensive processing adopts a method based on the shortest board principle to determine the reverse resource sufficiency.

[0059] Specifically, from the available resources reported by each network domain in the current scheduling round, the available latency and bandwidth resources within the domain are extracted. This aims to separate availability data from different resource dimensions, laying the foundation for subsequent dimensional comparisons and avoiding evaluation distortion caused by mixed resource types. For example, the coordinating controller can parse the structured resource data packets reported by the network domains and directly extract the explicit latency and bandwidth field values. Alternatively, if the reported data is unstructured, the coordinating controller can parse and classify the data through pattern matching, keyword recognition, or pre-trained machine learning models to identify and extract the available resources related to latency and bandwidth.

[0060] By extracting the actual latency and bandwidth resources used from the actual resource reservations of each network domain, we can obtain specific dimensional information on resource usage, provide an accurate occupancy benchmark, and ensure clear comparison targets. For example, when the coordination controller issues resource reservation instructions to a network domain, it simultaneously records the latency and bandwidth resources reserved by each network domain for a specific cross-domain service flow. These records can be directly used as the actual resource usage. Alternatively, after completing the resource reservation operation, a network domain can report the actual resource usage for a specific service flow to the coordination controller. This reported data also includes latency and bandwidth dimensional information for the coordination controller to extract.

[0061] By comparing the available latency resources within the domain with the actual latency resources used, a latency-dimensional sufficiency sub-quantity is obtained. This aims to quantify the resource sufficiency level in the latency dimension and capture the local resource status. This comparison can be implemented in various ways. For example, it can be calculated as (available latency resources within the domain - actual latency resources used) / available latency resources within the domain, yielding a percentage or proportion value representing the remaining proportion of latency resources. Alternatively, the two can be directly compared; if the available latency resources within the domain are greater than the actual latency resources used, the sufficiency sub-quantity is positive, otherwise it is negative. A Boolean value can also be set to indicate whether the latency resources meet the demand.

[0062] By comparing the available bandwidth resources within the domain with the actual bandwidth resources used, a bandwidth sufficiency sub-quantity is obtained. This aims to quantify the sufficiency of bandwidth resources and capture local resource status. Similar to the calculation of the latency sufficiency sub-quantity, the remaining proportion of bandwidth resources can be calculated as (available bandwidth resources within the domain - actual bandwidth resources used) / available bandwidth resources within the domain. Alternatively, the two can be directly compared; if the available bandwidth resources within the domain are greater than the actual bandwidth resources used, the sufficiency sub-quantity is positive, and otherwise negative. A Boolean value can also be set to indicate whether the bandwidth resources meet the demand.

[0063] The inverse resource sufficiency of each network domain is obtained by comprehensively processing the sufficiency components of latency and bandwidth dimensions. This comprehensive processing adopts the "shortest board" principle to determine the inverse resource sufficiency, aiming to use the most strained dimension as the determining factor for overall resource sufficiency, effectively identifying resource bottlenecks, preventing the advantages of a single dimension from masking the overall shortcomings, and thus improving the accuracy and reliability of the inverse resource sufficiency. The "shortest board" principle means directly selecting the smaller value between the latency and bandwidth sufficiency components as the inverse resource sufficiency of the network domain. For example, if the latency sufficiency component is 0.8 and the bandwidth sufficiency component is 0.6, then the inverse resource sufficiency of the network domain is determined to be 0.6. A penalty factor can also be further introduced to further attenuate the smaller value when the difference between the two dimensions is too large, to further emphasize the negative impact of resource imbalance.

[0064] The above technical solution, through a comprehensive processing mechanism incorporating the shortest board principle, solves the problem of potentially overlooking bottlenecks between dimensions in resource assessment, ensuring that the reverse resource sufficiency more accurately reflects the resource status of the network domain. For example, by separating and independently assessing latency and bandwidth resources and employing the shortest board principle, this application ensures that the calculated reverse resource sufficiency accurately reflects the most constrained resource dimension in the network domain. This effectively avoids the situation where sufficiency in one resource dimension masks a shortage in another critical dimension, thus providing a more accurate and conservative assessment of the actual resource supply capacity of the network domain. Therefore, based on this accurate reverse resource sufficiency, subsequent intent resolution benchmark adjustments will be more precise, effectively guiding the cooperative controller to correct its understanding of user intent, matching it with the actual resource limitations of the network, thereby reducing recurring resource conflicts and improving the overall efficiency and reliability of cross-domain resource scheduling.

[0065] In some of the embodiments described above in this application, a comprehensive processing of the latency dimension sufficiency quantity and the bandwidth dimension sufficiency quantity is proposed to obtain the reverse resource sufficiency. However, in its implementation, directly taking the smaller value as the candidate reverse resource sufficiency may ignore the short-term fluctuations and historical trend changes of network resource status, resulting in unstable or inaccurate reverse resource sufficiency evaluation results, thereby affecting the reliability of subsequent resource scheduling and the service quality assurance of cross-domain service flows.

[0066] To address this, this application further proposes a comprehensive processing method for the latency-dimensional sufficiency component and the bandwidth-dimensional sufficiency component to obtain the reverse resource sufficiency of each network domain. Specifically, this involves: comparing the latency-dimensional sufficiency component and the bandwidth-dimensional sufficiency component to determine the smaller of the two; using this smaller value as a candidate reverse resource sufficiency; and smoothing and correcting the candidate reverse resource sufficiency based on the historical trend of reverse resource sufficiency across multiple preceding scheduling rounds. Finally, the smoothed and corrected candidate reverse resource sufficiency is determined as the reverse resource sufficiency of each network domain.

[0067] The process involves comparing the sufficient quantity of latency with the sufficient quantity of bandwidth to determine the smaller value. This step aims to identify bottlenecks in network resources across the two key dimensions of latency and bandwidth. In network resource allocation, the overall performance of a system is often limited by its weakest link. By comparing the sufficient quantities of latency and bandwidth, the relatively insufficient dimensions in the current resource supply can be intuitively identified. One approach is to directly compare the values; for example, if the sufficient quantity of latency is 0.8 and the sufficient quantity of bandwidth is 0.7, then the smaller value is 0.7. Another approach is to introduce weighting factors for a weighted comparison. For example, different weights can be assigned based on the sensitivity of different service types to latency and bandwidth, and then the weighted values ​​are compared, but the smaller value representing the resource bottleneck is still selected.

[0068] The smaller value is used as a candidate reverse resource sufficiency. This step uses the identified resource bottleneck value as the preliminary reverse resource sufficiency assessment result. This candidate value reflects the weakest performance of the network domain's resource supply capacity in meeting the service level requirements of user intent in the current scheduling round. One implementation is to directly assign the smaller value obtained from the comparison to the candidate reverse resource sufficiency. Another implementation is to perform preliminary normalization or standardization on the smaller value based on the direct assignment, so that it falls within a preset numerical range, to facilitate subsequent smooth correction and comprehensive evaluation.

[0069] Based on the historical trends of reverse resource adequacy across multiple preceding scheduling rounds for each network domain, a smoothing correction is applied to the candidate reverse resource adequacy. This step aims to overcome the instability in assessment caused by instantaneous resource status fluctuations. By incorporating historical information, the assessment of reverse resource adequacy becomes more robust and accurate. Historical trends reflect the long-term behavior patterns of network domain resource supply, such as continuous improvement, continuous deterioration, or cyclical fluctuations. One approach is to use a moving average method, such as a simple moving average or a weighted moving average. By calculating the average of the reverse resource adequacy over the past N scheduling rounds, the current candidate value is smoothed, eliminating short-term noise. Another approach is to use exponential smoothing, such as single exponential smoothing or double exponential smoothing. This method assigns higher weights to recent data and lower weights to older data, better capturing trend changes while maintaining smoothness. Yet another approach is to use more complex prediction models, such as Kalman filtering, combining historical data and current observations to optimally estimate and correct the candidate reverse resource adequacy, addressing more complex dynamic changes.

[0070] The smoothed and corrected candidate reverse resource sufficiency is then used as the reverse resource sufficiency for each network domain. This step uses the candidate value, smoothed and corrected according to historical trends, as the determined reverse resource sufficiency for each network domain. This value not only considers the most scarce resource dimension at present but also incorporates historical stability information, making it a more reliable and predictive indicator. One implementation is to directly use the smoothed and corrected value as the reverse resource sufficiency. Another implementation is to further perform threshold judgment or range mapping on this value before determining it as the reverse resource sufficiency, based on business needs or network policies, to ensure that it meets specific scheduling decision criteria.

[0071] The above technical solution addresses the issue that directly selecting the smaller value when determining reverse resource sufficiency can lead to unstable or inaccurate evaluation results. By comparing the sufficiency components in the latency and bandwidth dimensions and determining the smaller value, the resource bottlenecks of the current network domain can be accurately identified, ensuring the relevance of the evaluation. Introducing a smoothing correction mechanism based on the historical reverse resource sufficiency change trends across multiple preceding scheduling rounds effectively filters out short-term fluctuations and instantaneous noise in network resource status, making candidate reverse resource sufficiency more stable and continuous. This correction method ensures that the determined reverse resource sufficiency not only reflects the current resource bottleneck but also incorporates the regularity of historical evolution, thus providing more accurate and reliable resource sufficiency evaluation results. This allows the collaborative controller to make decisions based on more robust resource status awareness in subsequent cross-domain path selection and cross-domain resource allocation, improving the reliability of resource scheduling and better guaranteeing the quality of service for cross-domain service flows.

[0072] In some of the embodiments described above in this application, a method is proposed to combine the forward resource mapping matching degree and the reverse resource sufficiency degree of each network domain to obtain a representation of inter-domain resource reservation behavior. However, in its implementation, the degree of difference in the forward resource mapping matching degree between each network domain is not considered, which makes it impossible to dynamically adjust the conflict indication weight in cross-domain resource scheduling. This may exacerbate resource conflicts and cause the deviation between the scheduling result and the user's intention to accumulate continuously without adaptive correction.

[0073] To address this, this application further proposes combining the forward resource mapping matching degree and the reverse resource sufficiency of each network domain, and integrating the differences in the forward resource mapping matching degree between network domains to obtain a representation of the inter-domain resource reservation behavior of each network domain. For example, the forward resource mapping matching degree and the reverse resource sufficiency of each network domain are multiplied, and the result of the multiplication is used as the single-domain resource reservation behavior component of each network domain. This step aims to comprehensively evaluate the performance of a single network domain in meeting user intent and service level requirements. The forward resource mapping matching degree reflects the degree of consistency between the actual reserved resources of the network domain and user intent requirements (such as latency constraints and bandwidth requirements), while the reverse resource sufficiency reflects the relationship between the available resources and the actual occupied resources within the network domain after these requirements are met, i.e., the sufficiency of resource supply. Through the multiplication operation, a more comprehensive single-domain resource reservation behavior component can be obtained, which considers not only the accuracy of resource reservation but also the rationality of resource supply. For example, linear multiplication can be used to directly multiply the normalized forward resource mapping matching degree by the reverse resource sufficiency degree. Alternatively, different weights can be assigned to the matching degree and sufficiency degree according to the actual business scenario before performing weighted multiplication to highlight the importance of a certain dimension.

[0074] Calculate the standard deviation of the positive resource mapping matching degree between each network domain, and use this standard deviation as the cross-domain matching difference component. This step is used to quantify the consistency or difference in resource reservation behavior among different network domains when satisfying the same user intent. The positive resource mapping matching degree is a key indicator for measuring the degree to which each network domain understands and responds to user intent. When multiple network domains collaboratively process a cross-domain service flow, their understanding of user intent and the accuracy of resource reservation may differ. By calculating the standard deviation of these matching degrees, the degree of dispersion in resource mapping between network domains can be intuitively reflected, i.e., the cross-domain matching difference component. The larger the standard deviation, the greater the difference in matching degree between network domains, and the greater the potential for misunderstanding or resource reservation incoordination. For example, the coordination controller can collect the positive resource mapping matching degree values ​​of all network domains participating in cross-domain service flow scheduling, and then calculate it according to the formula for calculating the statistical standard deviation. In addition to the standard deviation, other statistical dispersion indicators, such as variance, mean absolute deviation, or range, can also be used to characterize the degree of difference in the positive resource mapping matching degree between network domains and use it as the cross-domain matching difference component.

[0075] The inter-domain resource reservation behavior component of each network domain is weighted and fused with the cross-domain matching difference component to obtain the inter-domain resource reservation behavior representation of each network domain. This step aims to combine the performance of a single network domain with the coordination and consistency across network domains to form a comprehensive inter-domain resource reservation behavior representation. This representation not only reflects the resource reservation quality of each domain itself but also considers the potential inconsistencies in cross-domain collaboration. Through weighted fusion, the influence of single-domain performance and cross-domain differences in the representation can be adjusted according to actual needs. For example, a linear weighted sum can be used for fusion, where the inter-domain resource reservation behavior representation equals the product of a preset weight coefficient and the single-domain resource reservation behavior component, plus the product of another preset weight coefficient and the cross-domain matching difference component. Alternatively, a non-linear fusion function, such as based on the Sigmoid or Tanh function, can be used to map the two components to a specific interval before fusion to better capture the complex relationship between them and ensure that the numerical range and characteristics of the representation meet expectations.

[0076] The weighted fusion adjusts the conflict indication weight in the inter-domain resource reservation behavior representation based on the numerical change of the cross-domain matching difference component. The conflict indication weight is increased when the cross-domain matching difference component increases and decreased when it decreases. This step introduces a dynamic adaptive weight adjustment mechanism. The conflict indication weight is a parameter used to highlight or weaken potential conflicts in the inter-domain resource reservation behavior representation. When the cross-domain matching difference component increases, it indicates significant inconsistency in resource reservation among network domains. Increasing the conflict indication weight in this case makes the inter-domain resource reservation behavior representation more strongly reflect this inconsistency, thus prompting the cooperative controller to pay more attention to and resolve these potential conflicts. Conversely, when the difference component decreases, it indicates better cooperation among domains. Decreasing the conflict indication weight in this case avoids overreaction and makes the representation focus more on overall resource reservation efficiency. For example, a simple linear adjustment function can be designed so that the conflict indication weight increases with the increase of the cross-domain matching difference component and decreases with its decrease. Alternatively, piecewise functions or lookup tables can be used to adjust the cross-domain matching difference components into several intervals, with each interval corresponding to a preset conflict indication weight value.

[0077] The above technical solution enables a more accurate and dynamic characterization of inter-domain resource reservation behavior. For example, by multiplying the forward resource mapping matching degree of each network domain by the reverse resource sufficiency degree, a single-domain resource reservation behavior component can be obtained, comprehensively reflecting the resource reservation quality and supply capacity of a single network domain, avoiding the one-sidedness of evaluation from only a single dimension. By calculating the standard deviation of the forward resource mapping matching degree between each network domain, the degree of difference in understanding and responding to user intent among each network domain can be quantified, forming a cross-domain matching difference component, thereby capturing inconsistencies in cross-domain collaboration. This application further weights and fuses the single-domain resource reservation behavior component and the cross-domain matching difference component, and dynamically adjusts the conflict indication weight in the fusion process according to the numerical change of the cross-domain matching difference component. When the matching difference between network domains is large, the conflict indication weight is strengthened, so that the inter-domain resource reservation behavior characterization can more sensitively reflect potential conflicts and inconsistencies, prompting the collaborative controller to prioritize these issues. When the matching difference is small, the conflict indication weight is weakened to avoid excessive intervention. This adaptive weight adjustment mechanism enables the representation of inter-domain resource reservation behavior to more realistically reflect the actual situation of cross-domain resource scheduling, effectively avoiding repeated resource conflicts and continuous accumulation of deviations caused by ignoring cross-domain differences, thereby improving the accuracy of the collaborative controller's understanding of user intentions and its adaptive ability in cross-domain resource scheduling.

[0078] In some of the embodiments described above in this application, a method is proposed to analyze the numerical sequence of inter-domain resource reservation behavior in multi-round scheduling to extract trend features. However, the features extracted directly from the numerical sequence often only reflect numerical changes in a single dimension and cannot reveal the intrinsic relationship between these numerical changes and the specific service level requirements in the user's intent. This results in the system only being able to perceive that "a conflict is occurring," but not understanding "why the conflict is occurring," let alone determining whether the conflict stems from a cognitive bias in the network domains regarding latency constraints or a cognitive bias in their bandwidth requirements. This makes subsequent calibration lack a clear attribution direction, affecting the pertinence and effectiveness of reverse calibration.

[0079] To address this, this application further proposes a method to correlate the persistent characteristics of inter-domain resource reservation behavior representations with user intent in multi-round scheduling, thereby identifying patterns of misunderstanding of service level requirements described by user intent across different network domains. (See [link to relevant documentation]). Figure 3 The method includes: 301. Analyze the numerical sequence of inter-domain resource reservation behavior in multiple consecutive scheduling rounds and extract the trend characteristics of the numerical sequence evolution over time.

[0080] 302. Based on trend characteristics, identify the persistence characteristics of inter-domain resource reservation behavior representation from numerical sequences.

[0081] 303. Compare and correlate persistent features with the service level requirements described by the user's intent to determine whether there is a corresponding change relationship between persistent features and specific service level indicators in the service level requirements.

[0082] 304. Based on the results of correlation comparison, determine the patterns of misunderstanding in each network domain regarding the service level requirements described by the user's intent.

[0083] For example, analyzing the numerical sequence of inter-domain resource reservation behavior representations across multiple consecutive scheduling rounds aims to collect and organize data records of resource reservation behavior of each network domain within different scheduling cycles. This numerical sequence can be a discrete set of values ​​or a continuously changing curve. The analysis process may include, but is not limited to, preprocessing operations such as sampling, cleaning, and denoising of historical data to ensure data accuracy and usability. Alternatively, a time-series database can be constructed to store the inter-domain resource reservation behavior representation values ​​generated in each scheduling round in chronological order, forming a numerical sequence available for analysis.

[0084] Extracting the trend characteristics of the numerical sequence over time refers to identifying its patterns and regularities of change over time through in-depth analysis. These trend characteristics can reflect whether the inter-domain resource reservation behavior is continuously rising, continuously declining, fluctuating periodically, experiencing sudden changes, or remaining relatively stable. For example, statistical methods, such as calculating moving averages and exponential smoothing values, can be used to reveal long-term trends. Alternatively, signal processing techniques such as Fourier transforms and wavelet analysis can be used to identify periodic components and sudden events in the sequence.

[0085] Based on this trend characteristic, identifying the persistent features of resource reservation behavior across domains from this numerical sequence refers to further determining whether these trends are long-term and stable, thus classifying them as persistent features. Persistent features represent a relatively stable tendency or pattern in resource reservation behavior within a network domain, rather than short-term random fluctuations. For example, a duration threshold can be set; if a certain trend (such as consistently high or consistently low) remains unchanged across multiple consecutive scheduling rounds, it can be identified as a persistent feature. Alternatively, machine learning models, such as Support Vector Machines (SVMs) or decision trees, can be used to classify trend features and map them to predefined persistent feature types (such as consistently high, consistently low, or periodically fluctuating).

[0086] The goal of this correlation comparison is to establish a link between the actual behavior patterns of the network domain and the user's expected service quality by correlating the persistent characteristic with the service level requirements described by the user's intent. User intent typically includes explicit requirements for service level indicators such as latency and bandwidth. The correlation comparison process may include: parsing the specific service level indicators and their constraint values ​​from the user intent; comparing and analyzing the identified persistent characteristics representing inter-domain resource reservation behavior (e.g., consistently high or consistently low) with the historical performance data of these service level indicators to determine whether there is a synchronous or inverse relationship between them. For example, correlation analysis (such as Pearson correlation coefficient) can be used to quantify the correlation strength between persistent characteristics and specific service level indicators. Alternatively, through expert systems or pre-defined rules, it can be directly determined whether a certain persistent characteristic (e.g., "consistently high") has a logical correspondence with the actual performance of a certain service level indicator (e.g., "latency exceeds expectations").

[0087] Determining whether a persistent characteristic corresponds to a specific service level indicator (SLE) in the service level requirement involves clarifying the direction and extent of the persistent characteristic's influence on the specific SLE based on correlation comparison. For example, if the inter-domain resource reservation behavior is consistently high, and the latency indicator of the business flow also consistently exceeds user expectations, then it can be determined that there is a corresponding change relationship between the persistent characteristic and the latency indicator. This determination process can be based on preset logical rules; for example, if the persistent characteristic is "consistently high," and the corresponding SLE indicator (such as latency) fails to meet the standard in multiple scheduling rounds, then a corresponding relationship is considered to exist. Alternatively, a causal graph model can be constructed to analyze the potential causal chain between the persistent characteristic and the SLE indicator to determine whether a corresponding change relationship exists.

[0088] Based on the results of this correlation comparison, determining the understanding bias patterns of each network domain regarding the service level requirements described by the user's intent involves classifying and characterizing specific problems in the network domain's understanding of user intent based on the aforementioned correlation comparison and judgment results. Understanding bias patterns are abstract descriptions of the mismatch between network domain behavior and user intent, providing clear guidance for subsequent intent parsing benchmark calibration. For example, if a persistent characteristic shows "consistently high" and there is a corresponding change relationship with the "latency" indicator, the understanding bias pattern can be determined as "high latency constraint understanding." Or, if a persistent characteristic is "consistently low" and there is a corresponding change relationship with the "bandwidth" indicator, the understanding bias pattern can be determined as "low bandwidth requirement understanding." Determining these patterns helps the system accurately locate problems and take targeted calibration measures.

[0089] By establishing a multi-level analysis chain of "numerical sequence → trend features → persistence features → correlation comparison → understanding bias patterns" through the above technical solution, cross-domain resource mapping conflicts are reconstructed from "obstacles that need to be addressed" into "diagnosable cognitive bias signals," solving the problem that related technologies cannot extract attribution information from conflicts. Specifically, the numerical sequences representing inter-domain resource reservation behavior in multiple consecutive scheduling rounds are analyzed to extract the trend features of the numerical sequences over time. This step transforms the discrete conflict signals in a single round of scheduling into a continuous observation sequence with a time dimension, exposing the evolutionary pattern of the conflict and providing a temporal information foundation for subsequent pattern recognition. Based on the trend features, the persistence features of inter-domain resource reservation behavior are identified from the numerical sequences. This step further abstracts diagnostically significant behavioral patterns from the trend features, such as persistently high, persistently low, periodic fluctuations, or sudden jumps, enabling the system to not only know that "the values ​​are changing," but also "how the values ​​are changing," laying the foundation for the qualitative classification of understanding biases. By comparing persistent features with the service level requirements described by user intent, and determining whether there is a corresponding change relationship between persistent features and specific service level indicators in the service level requirements, this step establishes a cross-layer association between behavioral representation and semantic requirements. This allows the collaborative controller to pinpoint which specific service level indicator a deviation is associated with, rather than attributing it broadly to the overall intent, thus achieving a leap from "global perception" to "indicator-level attribution." Based on the association comparison results, the understanding bias patterns of the service level requirements described by user intent in each network domain are identified. This step consolidates the aforementioned analysis results into bias pattern types with clear semantics, providing a precise adjustment basis for the subsequent reverse calibration of the intent parsing benchmark. This allows calibration operations to be performed on specific indicators and specific bias directions, improving the targeting and effectiveness of the two-way collaborative evolution closed loop.

[0090] In some of the solutions described above in this application, the trend features of numerical sequences over time are extracted to analyze the persistence features of inter-domain resource reservation behavior. However, in this process, there is a lack of specific methods to accurately extract the trend features, which may lead to inaccurate identification of persistence features and affect the determination of the understanding bias pattern.

[0091] In response, this application further proposes a method for analyzing the numerical sequence of inter-domain resource reservation behavior representation across multiple consecutive scheduling rounds and extracting the trend characteristics of this numerical sequence over time, specifically including: Perform a difference operation on the values ​​of adjacent scheduling rounds in the numerical sequence, count the number of consecutive occurrences of the same-direction symbol in the result of the difference operation, and use the number of consecutive occurrences as the persistence direction feature.

[0092] The sign change frequency of the difference calculation results of adjacent scheduling rounds in the numerical sequence is statistically analyzed, and this sign change frequency is used as an oscillatory feature.

[0093] The value of the current scheduling round in the numerical sequence is compared with the value distribution of the numerical sequence in the historical sliding window to determine the degree of deviation. Cases where the degree of deviation exceeds a preset deviation threshold are identified as sudden features.

[0094] The persistent directional feature, the oscillatory feature, and the sudden feature are used as the trend features of the numerical sequence over time.

[0095] For example, when performing a difference operation on the values ​​of adjacent scheduling rounds in a numerical sequence, counting the number of consecutive occurrences of the same-direction symbol, and using this consecutive occurrence count as a characteristic of persistence direction, the difference operation aims to quantify the change in the numerical representation of inter-domain resource reservation behavior between adjacent scheduling rounds. By counting the consecutive occurrences of the same-direction symbol, a continuous upward or downward trend in the numerical sequence can be identified. For example, the difference between the current round's value and the previous round's value can be calculated. If multiple consecutive differences are all positive (or all negative), it indicates a continuous upward (or downward) trend. This consecutive occurrence count can serve as an indicator of the trend's stability and strength. Furthermore, techniques such as moving averages or exponential smoothing can be used to preprocess the numerical sequence, and then the difference operation can be performed on the smoothed sequence to reduce the impact of short-term fluctuations on persistence judgment, before counting the consecutive occurrences of the same-direction symbol.

[0096] When statistically analyzing the sign change frequency of the difference calculation results between adjacent scheduling rounds in a numerical sequence and using this sign change frequency as an oscillatory feature, the sign change frequency refers to the number of times the sign (positive or negative) of the difference calculation results between adjacent scheduling rounds changes within a certain time window. High-frequency sign changes indicate that the numerical sequence fluctuates violently, lacks a stable trend, and exhibits oscillation. For example, a sliding window can be set, and the number of times the difference sign changes from positive to negative or from negative to positive within the window can be counted, then divided by the window length to obtain the frequency. Another approach is to use signal processing techniques such as Fourier transform or wavelet analysis to analyze the frequency components of the numerical sequence, identify its periodic or oscillatory patterns, and extract the corresponding frequency features as oscillatory features.

[0097] When comparing the deviation of the current scheduling round's value in a numerical sequence with the distribution of values ​​within a historical sliding window, and identifying instances where the deviation exceeds a preset threshold as a sudden event, the aim of this deviation comparison is to detect outliers or sudden changes in the numerical sequence. The comparison between the current scheduling round's value and the distribution of values ​​within the historical sliding window can employ various statistical methods. For example, the deviation between the current value and the mean or median of values ​​within the historical sliding window can be calculated and normalized with the historical standard deviation or interquartile range to obtain the degree of deviation. When the deviation exceeds the preset threshold, a sudden event is considered to have occurred. Alternatively, machine learning-based anomaly detection algorithms, such as Isolation Forest or Local Outlier Factor (LOF), can be used to model the distribution of values ​​within the historical sliding window and determine whether the current value is an outlier, thereby identifying sudden events.

[0098] The persistent directional feature, the oscillatory feature, and the suddenness feature are considered as trend features of the numerical sequence over time. Combining these three types of features allows for a comprehensive characterization of the numerical sequence's trend over time from multiple dimensions. The persistent directional feature reflects the long-term direction and stability of the trend, the oscillatory feature reveals the volatility and periodicity of the trend, and the suddenness feature captures abnormal events within the trend. By integrating these three types of features, a complete and multi-layered understanding of the numerical sequence's trend can be formed. For example, these three features can be used as different dimensions of a vector to form a trend feature vector. Another approach is to assign different weights to these three features and perform weighted summation or use models such as decision trees or neural networks to fuse them, generating a comprehensive trend score or classification result as the trend feature.

[0099] Through the aforementioned technical solution, multi-dimensional analysis of the numerical sequence representing inter-domain resource reservation behavior is performed. By using difference calculations and continuous unidirectional sign statistics, the direction and strength of the trend are quantified, avoiding biases in subjective judgment and providing a foundation for subsequent identification of persistent features. By statistically analyzing the frequency of difference sign changes, the fluctuations in the numerical sequence are captured, oscillation patterns are identified, and the shortcomings of single-directional analysis are supplemented. By comparing the deviation of the current value from the distribution within the historical sliding window, outliers and sudden changes are effectively detected, ensuring timely perception of anomalies. These multi-dimensional features (persistent directional features, oscillatory features, and sudden features) are combined to form a comprehensive trend characterization of the numerical sequence's evolution over time. This multi-dimensional and refined trend feature extraction method solves the problem of inaccurate trend feature extraction when analyzing inter-domain resource reservation behavior. By comprehensively capturing the persistence, oscillation, and suddenness of the numerical sequence, misjudgments caused by single indicators or coarse analysis are avoided, thus supporting more accurate identification of the persistent features of inter-domain resource reservation behavior. By combining the aforementioned methods with the correlation analysis of persistent characteristics of inter-domain resource reservation behavior in multi-round scheduling and user intent, this accurate trend feature extraction improves the accuracy of persistent feature identification. When persistent features are more accurately identified, the accuracy and reliability of subsequent determination of patterns of misunderstanding of service level requirements described by user intent across different network domains also improve. This means that the collaborative controller can more accurately diagnose the discrepancy between network domain resource provisioning behavior and user intent, providing a solid data foundation for subsequent reverse calibration of intent parsing benchmarks, thereby effectively improving the scheduling performance of cross-domain service flows and reducing redundant scheduling conflicts.

[0100] In some of the embodiments described above in this application, a method based on trend feature identification of persistent features is proposed to determine the comprehension bias pattern. However, in its implementation, if the persistent feature identification is inaccurate, such as due to fluctuations in the numerical sequence, sudden anomalies, or ambiguity of direction leading to misjudgment, the comprehension bias pattern may be incorrect, thereby affecting the calibration effect of the intent parsing benchmark and failing to resolve the conflict problem in cross-domain resource scheduling.

[0101] In response, this application further proposes a method for identifying persistent characteristics of inter-domain resource reservation behavior representations from numerical sequences based on trend features, including: Based on the persistence direction feature in the trend characteristics, the numerical sequence is initially oriented to obtain the candidate persistence type of the numerical sequence.

[0102] Based on the oscillatory features in the trend characteristics, the confidence of candidate persistence types is verified. When the oscillatory features exceed the preset oscillation threshold, a decay correction is applied to the confidence of candidate persistence types.

[0103] Based on the suddenness feature in the trend characteristics, it is determined whether there are sudden jump points in the numerical sequence that deviate from the historical distribution range. When sudden jump points exist, the scheduling round in which the sudden jump point is located is marked as a deviation sample.

[0104] The candidate persistence types, verified by confidence, are combined with the labeled results of the deviation samples to obtain the persistence features representing inter-domain resource reservation behavior. When the number of deviation samples exceeds a preset threshold, the persistence feature is classified as a sudden deviation. When the number of deviation samples does not exceed the preset threshold, the candidate persistence types, verified by confidence, are used as the persistence features.

[0105] The initial orientation of the numerical sequence is based on the persistence direction characteristic within the trend features, yielding candidate persistence types. This step aims to preliminarily classify the numerical sequence according to its overall trend to identify potential persistence patterns. This initial orientation provides a foundation for subsequent refined analysis, avoiding blind searching through complex data. One approach is to calculate the average rate of change or slope of the numerical sequence within a certain time window and determine whether it is continuously rising, continuously falling, or relatively stable based on its sign and magnitude, thus identifying the candidate persistence type. For example, if the average rate of change is positive and exceeds a certain threshold, it can be initially oriented as "continuously growing." If it is negative and below a certain threshold, it is "continuously falling." Otherwise, it is "stable." Another approach is to use statistical methods, such as linear regression analysis of the numerical sequence, to determine the trend strength and direction based on the slope and goodness of fit of the regression line. For example, when the regression slope is positive and the R-squared value is high, it can be initially oriented as "positive persistence." When the slope is negative and the R-squared value is high, the orientation can be "negative continuation type". If the R-squared value is low, it may be "directionally ambiguous type".

[0106] Based on the oscillatory characteristics of the trend features, the confidence level of candidate persistence types is verified. When the oscillatory characteristics exceed a preset oscillation threshold, a decay correction is applied to the confidence level of the candidate persistence types. This step is used to assess the reliability of the preliminary orientation results. Oscillation characteristics reflect the degree of fluctuation in the numerical sequence. High oscillation may mean that the initially judged trend is unstable or contains a lot of noise interference. By decaying the confidence level, over-reliance on uncertain trends can be reduced, improving the accuracy of subsequent judgments. One implementation method is to calculate the standard deviation or variance of the numerical sequence within a specific time window and use it as the oscillatory characteristic. When the standard deviation or variance exceeds the preset oscillation threshold, the confidence level of the candidate persistence type is multiplied by a decay factor less than 1 (e.g., 0.8) to reduce its confidence level. Another implementation method is to use technical indicators such as Average True Range (ATR) to quantify oscillation. When the ATR value exceeds a preset threshold, the magnitude of the decay correction is dynamically adjusted according to the relative size of the ATR; for example, the larger the ATR, the smaller the decay factor, thus further reducing the confidence level.

[0107] Based on the sudden change characteristic in the trend features, this step determines whether there are sudden jump points in the numerical sequence that deviate from the historical distribution range. When sudden jump points are found, the scheduling rounds containing these points are marked as deviation samples. This step aims to identify potential outliers or sudden events in the numerical sequence. These events may not be part of the persistent trend but rather instantaneous changes caused by external factors. Marking these points as deviation samples can prevent them from interfering with the overall judgment of persistent features. One implementation method is to use statistical control charts (such as Shewhart control charts or cumulative sum control charts, CUSUM) to monitor the numerical sequence. When a data point exceeds the statistical control limits of historical data, it is judged as a sudden jump point, and its corresponding scheduling round is marked as a deviation sample. Another implementation method is to use robust statistics such as the median absolute deviation (MAD) or interquartile range (IQR) in a sliding window to detect outliers. A data point is marked as an abrupt change point when it deviates from the median or quartile range within the sliding window (e.g., exceeding the median ± 3 times MAD or exceeding the IQR range by 1.5 times).

[0108] The candidate persistence types, verified by confidence, are combined with the labeling results of deviation samples to determine the persistence feature representing inter-domain resource reservation behavior. When the number of deviation samples exceeds a preset threshold, the persistence feature is classified as a sudden deviation. When the number of deviation samples does not exceed the preset threshold, the candidate persistence types verified by confidence are used as the persistence feature. This step is crucial for determining the persistence feature, as it comprehensively considers the confidence level of the initial trend judgment and the existence of outliers. By setting a threshold for the number of deviation samples, a distinction can be made between normal fluctuations and real sudden events, ensuring that the identified persistence features reflect both long-term trends and provide a reasonable response to short-term anomalies. One implementation method is to count the total number of deviation samples after completing the confidence verification and deviation sample labeling. If this number exceeds the preset threshold (e.g., more than 3 out of 10 consecutive scheduling rounds are labeled as deviation samples), then regardless of the candidate persistence type, the persistence feature is classified as "sudden deviation," indicating that the sequence is mainly affected by sudden events. Otherwise, candidate persistence types that have undergone confidence verification (e.g., "continuous growth," "continuous decline," or "stable") are used as the persistence feature. Another approach is to introduce a weighted voting mechanism. One weight is assigned to the candidate persistence types that have undergone confidence verification, and another weight is assigned to the presence of deviation samples. When the number of deviation samples is small, the weight of the candidate persistence type dominates. When the number of deviation samples increases and exceeds a threshold, the weight of the deviation samples increases, thus making "sudden deviation" the prevailing determination. This approach allows for a more flexible balance between the influence of trends and anomalies.

[0109] The above technical solutions address the problem of inaccurate identification caused by fluctuations, sudden anomalies, or directional ambiguity in numerical sequences when identifying persistence features based on trend characteristics to determine patterns of comprehension bias. For example, by initially orienting the numerical sequence based on persistence directional features, its basic evolution direction can be quickly captured, providing a stable starting point for subsequent analysis and avoiding initial classification errors. Introducing oscillatory features to verify the confidence of candidate persistence types and applying attenuation correction when oscillation exceeds a preset oscillation threshold effectively suppresses the risk of misjudgment in high-fluctuation scenarios and improves the robustness of trend judgment. Furthermore, by identifying and labeling sudden jumps deviating from the historical distribution range using sudden features, this application can proactively identify and isolate abnormal events, preventing these sudden disturbances from distorting the judgment of persistence trends. The persistence feature type is determined by combining the confidence-verified candidate persistence types with the labeling results of deviation samples, based on whether the number of deviation samples exceeds a preset threshold. This combined determination mechanism ensures that the continuity trend of the sequence is preserved and accurately reflected when there are few outliers. When there are a large number of anomalies, they can be promptly identified as sudden deviations, thus adapting to data mutations. Overall, the solution proposed in this application, through a multi-step collaborative mechanism, comprehensively improves the accuracy and adaptability of persistent feature identification of inter-domain resource reservation behavior representation. This provides a more reliable and accurate input for subsequently determining the comprehension bias patterns of service level requirements described by user intent in each network domain, thereby supporting the effective calibration of intent parsing benchmarks and helping to solve recurring similar conflict problems in cross-domain resource scheduling.

[0110] In some of the solutions mentioned above in this application, a preliminary orientation of numerical sequences based on the persistence direction feature in the trend features is proposed to obtain candidate persistence types. However, in this process, due to the lack of specific extraction and judgment logic for the persistence direction feature, the orientation results may be inaccurate or inconsistent, leading to incorrect candidate persistence types, which in turn affects the accurate identification of persistence features, resulting in bias in the determination of the bias pattern and failing to effectively reflect the actual resource supply changes in each network domain.

[0111] In response, this application further proposes a preliminary orientation of the numerical sequence based on the persistence direction feature among the aforementioned trend characteristics, to obtain candidate persistence types of the numerical sequence, specifically including the following steps: From the persistence directional features of this trend characteristic, the evolution direction indicator and the directional persistence strength of the numerical sequence are extracted. The evolution direction indicator characterizes the overall trend of the numerical sequence, i.e., whether the numerical sequence tends to increase or decrease. For example, it can be calculated by comparing the differences between adjacent values ​​in the numerical sequence and counting the number of positive and negative differences. If the number of positive differences exceeds the number of negative differences, the indicator is positive; otherwise, it is negative. Alternatively, linear regression analysis can be performed on the numerical sequence, and the slope of the regression line can be used as the evolution direction indicator. The directional persistence strength characterizes the degree or stability of the continuous change in a certain evolution direction of the numerical sequence. The higher the strength, the more stable and less likely the change in that direction is to be reversed. For example, it can be measured by counting the number or proportion of consecutive changes in the same direction in the numerical sequence. If the number of consecutive scheduling rounds increases, the directional persistence strength is high. Alternatively, it can be evaluated by calculating the ratio of the cumulative change in a specific direction to the total change, or by analyzing the autocorrelation of the numerical sequence.

[0112] When the evolution direction indicator is positive and the intensity of that direction reaches a preset intensity threshold, the candidate persistence type is determined to be persistently high. This preset intensity threshold is a pre-defined value used to determine whether the directional persistence is sufficient to ascertain whether the numerical sequence has a clear persistent trend. This threshold can be set based on historical data analysis, expert experience, or system performance requirements; for example, it can be set as a minimum requirement for the number of consecutive changes in the same direction, or a lower limit for the cumulative change ratio. When the evolution direction indicator is positive and the directional persistence (e.g., the number of consecutive increases or the magnitude of increase) reaches the preset intensity threshold, it can be determined to be persistently high, indicating that the numerical sequence shows a sustained upward trend over a period of time, and that this upward trend has sufficient strength and stability.

[0113] When the evolution direction indicator is negative and the intensity of the direction reaches the preset intensity threshold, the candidate persistence type is determined to be persistently low. This indicates that when the evolution direction indicator is negative and the intensity of the direction reaches the preset intensity threshold, the numerical sequence shows a continuous downward trend over a period of time, and this downward trend has sufficient strength and stability.

[0114] When the directional persistence intensity does not reach the preset intensity threshold, the candidate persistence type is determined to be directionally ambiguous. This means that when the directional persistence intensity does not reach the preset intensity threshold, regardless of whether the evolution direction indicator is positive or negative, it can be determined to be directionally ambiguous. This includes situations with large fluctuations, no obvious trend, or unstable trends, ensuring accurate identification of unclear trends.

[0115] By clearly defining two quantitative indicators, "evolution direction indication" and "directional persistence strength," and setting a "preset strength threshold," the above technical solution provides an objective and quantifiable basis for the initial orientation of numerical sequences. This solves the problem of inaccurate or inconsistent orientation results caused by the lack of specific extraction and judgment logic for persistent directional features. This solution can accurately identify whether a numerical sequence is consistently high, consistently low, or directionally ambiguous, avoiding biases caused by subjective judgment and ensuring the accuracy of candidate persistence types. This makes the subsequent identification of persistence features more reliable, thereby improving the accuracy of understanding bias patterns. The solution also considers the case of insufficient directional persistence strength, classifying it as directionally ambiguous, avoiding misjudgments of unclear trends, and making the reflection of actual resource supply changes in each network domain more comprehensive and realistic. Combined with the step in the above method of analyzing the correlation between the persistence characteristics of inter-domain resource reservation behavior representation in multi-round scheduling and user intent, this solution can more accurately identify the bias patterns of network domains in understanding user intent, providing a solid foundation for the reverse calibration of subsequent intent parsing benchmarks.

[0116] In some of the solutions mentioned above in this application, a correlation comparison between persistent features and user intent service level requirements is proposed to determine the understanding bias pattern. However, in this process, there is a lack of a systematic method to accurately identify whether persistent features are related to specific service level indicators, resulting in insufficient accuracy in judging the bias pattern. It may misjudge the corresponding change relationship due to incomplete indicator extraction, missing historical data, or fuzzy trend comparison, thereby affecting the calibration effect of intent parsing benchmark.

[0117] To address this, this application further proposes a method to correlate and compare the persistent feature with the service level requirements described by the user's intent, determining whether the persistent feature corresponds to a specific service level indicator in the service level requirements. Specifically, this includes: extracting at least one service level indicator constituting the service level requirements from the user's intended service level requirements; obtaining historical resource mapping records for each service level indicator for each network domain in the consecutive scheduling rounds for that service level indicator; comparing the changing trend of the persistent feature with the historical resource mapping records corresponding to each service level indicator, determining whether the changing trend represented by the persistent feature and the changing trend of the resource mapping corresponding to the service level indicator show the same or opposite directions; and determining that a corresponding changing relationship exists between the persistent feature and any service level indicator when the persistent feature and any service level indicator show the same or opposite directions.

[0118] For example, from the service level requirements described by the user's intent, at least one service level indicator (SPI) constituting those requirements is extracted. This step aims to clarify the user's specific service quality requirements, such as latency, bandwidth, jitter, and packet loss rate. In practice, Natural Language Processing (NLP) technology can be used to perform semantic analysis on the user's input intent text to identify the contained SPI keywords and their quantitative requirements. For instance, if the user's intent is "requiring low latency and high bandwidth services," then "latency" and "bandwidth" can be extracted as SPIs. Another approach is for the system to provide predefined SPI templates or a structured input interface, allowing users to directly specify the required SPIs by selecting or filling in the information, thus avoiding a complex semantic parsing process.

[0119] For each service level indicator (SLE), historical resource mapping records for that SLE are obtained for each network domain across multiple consecutive scheduling rounds. The purpose of this step is to collect data on the actual resource allocation and performance of each network domain for a specific SLE in past scheduling rounds, providing a data foundation for subsequent trend comparisons. For example, data such as the actual amount of latency resources reserved and the actual latency performance achieved by each network domain in the past N scheduling rounds when user intents included specific latency requirements can be retrieved from the historical database of the coordination controller or network management system. Alternatively, a continuous network performance monitoring system can be used to collect performance data of each network domain in real time and associate it with the corresponding scheduling requests and SLE to form detailed historical resource mapping records.

[0120] The persistence feature is compared with the historical resource mapping record corresponding to each service level indicator to determine whether the trend represented by the persistence feature and the trend of the resource mapping corresponding to the service level indicator show the same or opposite changes. This step is the core of the correlation analysis, aiming to discover the dynamic relationship between the persistence pattern of inter-domain resource reservation behavior and the actual performance of a specific service level indicator. For example, time series analysis methods can be used, such as calculating the correlation coefficient (e.g., Pearson correlation coefficient) between the numerical sequence of the persistence feature and the numerical sequence of the historical resource mapping record of the service level indicator, to quantify the strength of their same or opposite changes. If the correlation coefficient is positive and reaches a preset threshold, it indicates that there is a same-direction change. If it is negative and reaches a preset threshold, it indicates that there is an opposite change. Another method is to use techniques such as sliding window averaging and exponential smoothing to extract the trend of the two numerical sequences, and then compare the shape of the extracted trend curves, such as determining whether they rise or fall simultaneously, or one rises while the other falls.

[0121] When a persistent feature and any service level indicator show a change in the same direction or in opposite directions, a corresponding relationship between the persistent feature and the service level indicator is determined. This step makes a clear judgment based on the comparison results, providing a basis for subsequent identification of the understanding bias pattern. For example, a correlation threshold can be set; when the absolute value of the correlation coefficient between a persistent feature and the historical resource mapping records of a certain service level indicator exceeds the threshold (e.g., 0.6 or 0.7), a corresponding relationship is considered to exist. Alternatively, a machine learning model (such as a classifier) ​​can be trained and used to judge the trend comparison results; when the model outputs a probability of correlation exceeding a preset confidence level, a corresponding relationship is determined to exist.

[0122] The above technical solution provides a systematic and data-driven method for accurately identifying the correlation between persistent characteristics of inter-domain resource reservation behavior and specific service level indicators (SLEs) described by user intent. By extracting at least one SLE from the user's intended SLE requirements, the comparison process is ensured to be based on the explicit requirements of the user intent, avoiding biased pattern recognition due to missing indicators. Historical resource mapping records for each network domain in multiple consecutive scheduling rounds are obtained for each SLE, providing solid data support for correlation analysis and solving the problem of missing or incomplete historical data. The changing trends of persistent characteristics and the historical resource mapping records corresponding to each SLE are compared to determine whether they show the same or opposite direction. This trend-based dynamic analysis method can more accurately capture the actual impact of persistent behavior patterns on SLEs, thus avoiding subjective misjudgments. When persistent characteristics and any SLE show the same or opposite direction, a corresponding relationship is determined, providing a reliable and refined basis for subsequently identifying the misunderstanding patterns of user intent SLE requirements in each network domain. This accurate correlation analysis enables the collaborative controller to more accurately understand the actual response of each network domain to user intent in multi-round scheduling, thereby enabling more effective calibration of the intent resolution benchmark. This solves the problem of the persistent disconnect between the intent resolution benchmark and the actual resource supply capacity of each network domain in the background technology, and improves the accuracy and adaptability of cross-domain resource scheduling.

[0123] In some of the solutions mentioned above in this application, a pattern of misunderstanding of service level requirements described by user intent in each network domain is determined based on the results of correlation comparison. This is used to analyze the differences in the understanding of intent among network domains and guide intent parsing calibration. However, in this process, when the correlation strength in the correlation comparison results is insufficient or the persistence characteristics are unclear, it is impossible to effectively distinguish and classify the specific types of deviation patterns. This results in the intent parsing calibration operation lacking pertinence and failing to accurately adapt to changes in the actual resource supply capacity of the network domain, thereby repeatedly triggering cross-domain resource scheduling conflicts.

[0124] To address this, this application further proposes a method to determine the comprehension bias patterns of service level requirements (SLRs) described by user intent in each network domain, based on the aforementioned correlation comparison results. Specifically, this includes: determining the correlation strength between persistent features and each SLR indicator in the SLR requirements based on the correlation comparison results; when the correlation strength of at least one SLR indicator reaches a preset strong correlation threshold, obtaining the candidate persistence type to which the persistent feature belongs, and determining the comprehension bias pattern of the SLR indicator based on the candidate persistence type; when the correlation strength of all SLR indicators does not reach the preset strong correlation threshold, and the persistent feature exhibits periodic changes, the comprehension bias pattern is determined to be a cross-indicator comprehensive effect type; when the correlation strength of all SLR indicators does not reach the preset strong correlation threshold, and the persistent feature does not exhibit periodic changes, the comprehension bias pattern is determined to be an undetermined type.

[0125] The determination of the correlation strength between persistent characteristics and various service level indicators in service level requirements aims to quantify the strength of the relationship between persistent characteristics representing inter-domain resource reservation behavior and various service level indicators describing user intent. This quantification provides objective data support for subsequent deviation pattern classification, avoiding subjective judgment. One approach is to use statistical correlation analysis methods, such as calculating the Pearson correlation coefficient or Spearman's rank correlation coefficient, to measure the linear or non-linear correlation between the time series data of persistent characteristics and the historical resource mapping records of each service level indicator. The larger the absolute value of the correlation coefficient, the stronger the correlation. Another approach is to construct a predictive model, such as a linear regression model or a decision tree model, using persistent characteristics as input to predict the resource mapping of each service level indicator. The model's prediction accuracy or feature importance score can be used as a measure of correlation strength.

[0126] When the correlation strength of at least one service level indicator (SPI) reaches a preset strong correlation threshold, the system acquires the candidate persistence type to which the persistence feature belongs, and determines the understanding bias pattern of the SPI based on the candidate persistence type. When a sufficiently strong correlation is found between one or more SPIs and a persistence feature, it indicates that the network domain's understanding or response to these specific indicators has a clear bias pattern. In this case, the system directly uses the previously identified persistence feature type (e.g., persistently high, persistently low, etc.) to define the understanding bias pattern for that SPI. For example, if the persistence feature is "persistently high" and strongly correlated with the bandwidth indicator, the understanding bias pattern for the bandwidth indicator can be determined as "persistently high bandwidth bias". Another implementation is to preset a rule base, which maps different candidate persistence types and specific SPI combinations to specific understanding bias pattern names. For example, the combination of "persistently low" and "latency" may be mapped to "insufficient latency guarantee bias".

[0127] When the correlation strength of all service level indicators (SSIs) fails to reach the preset strong correlation threshold, and the persistent feature exhibits periodic changes, the bias pattern is identified as a cross-indicator combined effect type. This step is used to handle more complex bias situations. When the correlation strength between a persistent feature and any single SSI is insufficient to reach the strong correlation threshold, but the persistent feature itself exhibits significant periodic changes, this usually means that the resource reservation behavior bias in the network domain is not caused by a single indicator, but is the result of the interaction between multiple SSIs or the influence of some periodic external factor. One approach is to perform time-frequency analysis on the numerical sequence of the persistent feature, such as using Fast Fourier Transform (FFT) or wavelet analysis to detect the presence of periodic components. If periodicity is detected, the bias pattern is classified as "cross-indicator combined effect type". Another approach is to use the autocorrelation function (ACF) or partial autocorrelation function (PACF) to analyze the periodicity of the persistent feature time series. When the ACF plot shows obvious periodic peaks, it can be determined as a periodic change.

[0128] When the correlation strength of all service level indicators fails to reach a preset strong correlation threshold, and the persistent characteristics do not exhibit periodic changes, the comprehension bias pattern is classified as indeterminate. This step serves as a fallback mechanism to identify bias patterns that cannot be clearly categorized. When the correlation strength between persistent characteristics and all service level indicators is weak, and the persistent characteristics themselves do not exhibit periodic changes, it indicates that the current analysis method cannot accurately capture its inherent patterns or attributions. Marking it as "indeterminate" can prevent the system from performing erroneous or invalid intent parsing calibrations. One implementation is to automatically mark the comprehension bias pattern as "indeterminate" after excluding the aforementioned two situations (i.e., strong correlation or periodic changes). Another implementation is to set up a confidence scoring mechanism; if the confidence score of all identified bias patterns is below a preset minimum threshold, the bias pattern is classified as "indeterminate," indicating the need for further data collection or a more complex analysis model.

[0129] The above technical solutions address the challenge of effectively classifying deviation patterns when correlation strength is insufficient or features are ambiguous. For example, quantifying the correlation strength between persistent features and various service level indicators provides an objective basis for identifying deviation patterns, avoiding subjective assumptions. When strong correlations exist, deviation patterns can be accurately bound to specific service level indicators, ensuring the targeted nature of intent resolution calibration. In cases without strong correlations but with periodic changes, "cross-indicator comprehensive effect" deviations are identified, revealing the complexity of multi-indicator interactions and preventing the neglect of potential systemic problems. For ambiguous cases that cannot be clearly categorized, they are marked as "undetermined," avoiding calibration errors caused by forced classification, thereby improving the accuracy and adaptability of deviation pattern classification. This meticulous deviation pattern recognition mechanism enables the collaborative controller to more accurately understand the actual resource supply capacity of each network domain, thereby guiding the calibration of intent resolution benchmarks, effectively reducing recurring conflicts of the same type in cross-domain resource scheduling, and improving the robustness and efficiency of the entire scheduling system.

[0130] In some of the embodiments described above in this application, a method for determining the understanding bias pattern based on the results of correlation comparison is proposed to identify the understanding bias of each network domain regarding service level requirements. However, in its implementation, it is impossible to distinguish whether the bias originates from a global coordination problem of all network domains or a local autonomy problem of only a specific network domain. This results in the lack of specificity in the calibration of the intent resolution benchmark and the inability to resolve the root causes of conflicts in cross-domain resource scheduling.

[0131] To address this, this application further proposes a method based on correlation comparison results to determine the understanding bias patterns of each network domain regarding the service level requirements described by the user's intent. Specifically, this includes: determining the domain-level persistent characteristics corresponding to each network domain based on the correlation comparison results; performing cross-domain comparisons of the domain-level persistent characteristics of each network domain to determine whether the domain-level persistent characteristics of each network domain exhibit cross-domain consistency; when the domain-level persistent characteristics of each network domain exhibit cross-domain consistency, the understanding bias pattern is determined to be a global collaborative bias type; when the domain-level persistent characteristics of each network domain do not exhibit cross-domain consistency, the network domains whose domain-level persistent characteristics differ from those of other network domains are marked as the source domains of the bias, and the understanding bias pattern is determined to be a local autonomous bias type of the source domain.

[0132] To more precisely identify the sources of deviation, this application determines the domain-level persistent characteristics corresponding to each network domain based on the results of correlation comparison. This step aims to independently analyze the long-term trends and patterns of resource reservation behavior in each network domain, rather than focusing solely on overall or aggregated cross-domain performance. For example, for each network domain, the process of correlation analysis between the persistent characteristics of inter-domain resource reservation behavior representation in multiple rounds of scheduling and user intent can be re-executed, but only using data from that specific network domain. For instance, the numerical sequence of the positive resource mapping matching degree and the negative resource sufficiency of the network domain itself in consecutive scheduling rounds can be analyzed to extract its trend characteristics over time (such as persistent directional characteristics, oscillatory characteristics, and burst characteristics), thereby identifying the persistent characteristics unique to that network domain. Another approach is that, if the overall inter-domain resource reservation behavior representation has already been calculated, a decomposition or filtering mechanism can be designed to extract and attribute the contribution of each independent network domain from the overall representation, thereby obtaining its domain-level persistent characteristics.

[0133] After obtaining the domain-level persistence features of each network domain, this application performs cross-domain comparisons of these features to determine whether they exhibit cross-domain consistency. This comparison aims to identify whether the deviation is prevalent across all network domains or limited to certain domains. For example, consistency can be determined by calculating the statistical similarity between the domain-level persistence features of each network domain, using indicators such as correlation coefficient, Euclidean distance, or cosine similarity. If the similarity exceeds a preset threshold, it is considered to exhibit cross-domain consistency. Furthermore, a series of pattern matching rules can be preset; for example, if the domain-level persistence features of all network domains consistently exhibit a "consistently high" or "consistently low" pattern, it is determined to be cross-domain consistent.

[0134] When the domain-level persistent characteristics of each network domain exhibit cross-domain consistency, this application identifies the understanding deviation pattern as a global collaborative deviation type. This indicates that all network domains exhibit a universal and systematic deviation in understanding the service level requirements of user intent, which may stem from a holistic deficiency in the intent parsing benchmark of the collaborative controller. For example, once the consistency of domain-level persistent characteristics is confirmed through the aforementioned cross-domain comparison, the system can directly label this deviation pattern as a global collaborative deviation type.

[0135] Conversely, when the domain-level persistent characteristics of various network domains do not exhibit cross-domain consistency, this application labels network domains whose domain-level persistent characteristics differ from those of other network domains as deviation source domains, and identifies the understanding deviation pattern as a local autonomous deviation type of the deviation source domain. This indicates that the deviation is not universal, but rather concentrated in one or a few network domains, possibly due to problems with the resource supply capacity, internal strategies, or local understanding of intent of these specific network domains. For example, anomaly detection algorithms (such as Z-score, isolated forest, etc.) can be used to identify those domains whose domain-level persistent characteristics deviate from the average level of other network domains and mark them as deviation source domains. Alternatively, a difference threshold can be set; when the difference between the domain-level persistent characteristics of a certain network domain and the average characteristics of the remaining network domains exceeds this threshold, it is identified as a deviation source domain, and the understanding deviation pattern is classified as a local autonomous deviation type of that deviation source domain.

[0136] The aforementioned technical solution enables precise differentiation of the nature of discrepancies in the understanding of user intent service level requirements across network domains during cross-domain service flow scheduling. For example, by independently analyzing and comparing the domain-level persistent characteristics of each network domain across different domains, the collaborative controller can identify whether the discrepancy stems from a global collaborative problem across all network domains or is caused solely by a local autonomous problem within a specific network domain. When identified as a global collaborative discrepancy, it indicates a potential widespread deviation in the overall semantic mapping threshold of the intent parsing benchmark, requiring global adjustment. Conversely, when identified as a local autonomous discrepancy, it accurately pinpoints the specific network domain causing the discrepancy, allowing for localized and targeted calibration only for the domain of origin or the intent parsing rules related to that domain. This fine-grained discrepancy pattern recognition avoids blind or excessive adjustments to the intent parsing benchmark, enhancing the targeting and effectiveness of benchmark calibration. This more efficiently resolves recurring conflicts in cross-domain resource scheduling, ensuring a dynamic match between the intent parsing benchmark and the actual resource supply capacity of each network domain, thereby optimizing the scheduling performance and user experience of cross-domain service flows.

[0137] In some of the solutions described above in this application, a reverse calibration operation is proposed to perform on the intent parsing benchmark using the understanding bias pattern and user intent as joint inputs, so as to calibrate the intent parsing benchmark and adjust it in the direction of actual resource supply capacity. However, in this process, since it is not specifically explained how to determine the bias direction and adjustment range based on the understanding bias pattern and user intent, the calibration operation may be inaccurate and cannot effectively eliminate the disconnect between the intent parsing benchmark and the actual resource supply capacity.

[0138] In response, this application further proposes a reverse calibration operation for intent resolution benchmarks, see [link to relevant documentation]. Figure 4 This operation includes: 401. Based on the understanding bias pattern, determine the specific service level indicator associated with the understanding bias pattern, and the direction of the deviation of the understanding bias pattern from the specific service level indicator.

[0139] 402. Extract the original semantic constraint values ​​from the user intent to describe the specific service level indicator.

[0140] 403. Based on the deviation direction and the original semantic constraint value, determine the adjustment direction and adjustment range of the semantic mapping threshold corresponding to the specific service level indicator in the intent parsing benchmark.

[0141] 404. Adjust the semantic mapping threshold corresponding to the specific service level indicator in the intent parsing benchmark according to the adjustment direction and adjustment magnitude.

[0142] 405. Update the adjusted semantic mapping threshold to the intent parsing benchmark to obtain the calibrated intent parsing benchmark.

[0143] For example, when determining the specific service level indicator (SLE) associated with this bias pattern, and the direction of deviation of the bias pattern from that specific SLE, the bias pattern is a pattern of misunderstanding between network domains regarding the SLE requirements described by the user's intent. This is identified by the collaborative controller during multi-round scheduling by comparing user intent with the actual resource reservation behavior of each network domain and analyzing its persistence characteristics. This pattern may indicate a bias in the network domain's understanding of specific SLE indicators such as latency and bandwidth. Determining the associated specific SLE indicator aims to clarify which specific performance parameter the calibration operation should target. Determining the direction of deviation (e.g., whether it is consistently high or consistently low) provides directional guidance for subsequent adjustment operations. One implementation method is through a predefined rule base or pattern matching algorithm. For example, if the bias pattern is identified as "consistently low" and strongly correlated with the "latency" indicator, then the specific SLE indicator is determined to be latency, and the deviation direction is negative (i.e., the actual latency is higher than expected). Another approach is to use machine learning models, such as classifiers or regression models, to train on historical comprehension bias pattern data. When a new comprehension bias pattern is input, the model can predict its associated service level indicators and the direction of its deviation.

[0144] When extracting the raw semantic constraint values ​​from a user intent describing a specific service level indicator (SLE), the user intent is a high-level abstract description of the user's service level requirements for the business flow, which includes raw semantic constraints on SLE indicators such as latency and bandwidth. Extracting these raw semantic constraint values ​​ensures that the calibration operation does not deviate from the user's original intent, using the user's initial, uninterpreted or untransformed requirements as a reference point when calibrating the intent parsing baseline. One approach is to use keyword matching, regular expressions, or semantic parsing techniques to identify and extract numerical values ​​or descriptive terms related to the specific SLE indicator (e.g., "low latency" might correspond to a default raw latency constraint value) if the user intent is submitted via a graphical user interface (GUI) or API in the form of structured data (such as JSON or XML), then the raw values ​​of the specific SLE indicator can be directly read from the corresponding fields.

[0145] When determining the adjustment direction and magnitude of the semantic mapping threshold corresponding to a specific service level indicator in the intent parsing benchmark based on the deviation direction and the original semantic constraint value, the semantic mapping threshold is a key parameter in the intent parsing benchmark. It defines how to map the ambiguous semantics in the user's intent (such as "low latency") to specific network configurable parameters (such as "latency less than 50 milliseconds"). Based on the determined deviation direction, it can be decided whether to amplify or reduce the threshold. Combined with the original semantic constraint value, the degree of adjustment can be quantified, ensuring that the adjustment corrects the deviation without excessively deviating from the user's original needs. One implementation approach is to use a rule-based adjustment strategy. For example, if the deviation direction is negative (actual resource supply is insufficient), the adjustment direction is to amplify the semantic mapping threshold. If the deviation direction is positive (actual resource supply is excessive), the adjustment direction is to reduce the semantic mapping threshold. The adjustment magnitude can be calculated linearly or non-linearly based on the sustained strength of the deviation or the proportion of the original semantic constraint value. Another implementation approach is to use an adaptive control algorithm. For example, a PID controller can be designed to take the deviation direction and the original semantic constraint value as input, and dynamically output the adjustment direction and magnitude of the semantic mapping threshold through iterative calculation, so as to gradually converge to the optimal mapping relationship.

[0146] When adjusting the semantic mapping threshold corresponding to the specific service level indicator in the intent parsing benchmark according to the adjustment direction and magnitude, this is the step of actually applying the calculated adjustment strategy to the intent parsing benchmark. By performing the adjustment operation, the coordination controller can dynamically modify its understanding of user intent to better reflect the actual resource availability of each network domain. One implementation is to directly modify the semantic mapping threshold stored in the database or configuration file. For example, if the current latency threshold is 50ms, the adjustment direction is amplification, and the adjustment magnitude is 10ms, then the threshold is updated to 60ms. Another implementation is to pass the new semantic mapping threshold parameter to the intent parsing module by calling the API interface provided by the intent parsing module, so that the new threshold is used in subsequent intent parsing processes.

[0147] When the adjusted semantic mapping threshold is updated to the intent parsing baseline to obtain the calibrated intent parsing baseline, the update operation ensures the persistence and effectiveness of the intent parsing baseline. The calibrated intent parsing baseline will be used in subsequent scheduling rounds to perform semantic parsing on new user intents, thereby achieving dynamic adaptation of the intent parsing baseline and avoiding the disconnect problem caused by a fixed baseline. One implementation is to write the adjusted semantic mapping threshold to the storage medium of the intent parsing baseline, such as a database, memory cache, or configuration file, and mark it as the latest version. Another implementation is, in a distributed system, to broadcast the updated intent parsing baseline to all relevant intent parsing service instances, ensuring that all instances use the latest calibration result.

[0148] The above technical solution provides an accurate and adaptive intent resolution benchmark calibration mechanism. Based on the identified understanding bias patterns, it can clearly pinpoint which specific service level indicator (SLE) (such as latency or bandwidth) has a misinterpretation, and the specific direction of the bias (whether the network domain tends to over-reserve or under-reserve). Semantic constraint values ​​extracted from the user's original intent ensure that the calibration operation is always anchored to the user's actual needs, avoiding blind or over-correction during the calibration process. By comprehensively considering the bias direction and the original constraints, the adjustment direction and magnitude of the semantic mapping threshold can be accurately calculated, making the calibration operation targeted and quantifiable. By actually executing the adjustment operation and updating the calibrated threshold to the intent resolution benchmark, the collaborative controller can dynamically correct its understanding of user intent, keeping it synchronized with the actual resource supply capacity of each network domain. This solves the problem of the continuous disconnect between the intent resolution benchmark and the actual resource supply capacity in related technologies, reduces recurring conflicts of the same type in cross-domain resource scheduling, thereby improving the accuracy and efficiency of resource scheduling and ensuring that the service level requirements of business flows are met more reliably.

[0149] In some of the embodiments described above in this application, a reverse calibration operation is proposed based on the understanding bias pattern to perform an intent parsing benchmark. However, the understanding bias pattern itself is a comprehensive judgment result, and the bias type information and indicator attribution information contained within it are not explicitly extracted and structurally expressed. This makes it impossible to accurately determine which service level indicator should be adjusted when determining the adjustment direction of the semantic mapping threshold, nor can it determine which direction to adjust in. As a result, the reverse calibration operation lacks a clear execution direction, making it difficult to achieve accurate indicator-level calibration.

[0150] To address this, this application further proposes a method for determining the specific service level indicator associated with the comprehension deviation pattern, and the deviation direction of the comprehension deviation pattern towards that specific service level indicator, based on the comprehension deviation pattern. The method includes: deconstructing the comprehension deviation pattern to extract deviation feature descriptions from the comprehension deviation pattern, the deviation feature descriptions including a pattern type identifier and indicator pointing information corresponding to the comprehension deviation pattern in the service level requirement described by the user intent; determining the specific service level indicator associated with the comprehension deviation pattern from multiple service level indicators included in the service level requirement based on the indicator pointing information; and determining the deviation direction of the comprehension deviation pattern towards that specific service level indicator based on the pattern type identifier, wherein a consistently high pattern type identifier corresponds to a positive deviation direction, and a consistently low pattern type identifier corresponds to a negative deviation direction.

[0151] For example, feature deconstruction of the comprehension bias pattern aims to break down this high-level abstract concept into more fundamental and easily processed components, facilitating subsequent refined analysis and manipulation. For instance, pattern recognition algorithms can be used to analyze the original data of the comprehension bias pattern or its intermediate states during generation, identifying and separating its inherent structured features. Alternatively, a predefined set of rules can be used to map different types of comprehension bias patterns to their corresponding feature description templates, thereby achieving feature deconstruction.

[0152] The deviation feature description is extracted from the comprehension deviation pattern. This description is a structured representation of the deconstructed pattern, containing its key attributes and serving as the foundation for determining subsequent adjustment directions and goals. The deviation feature description includes a pattern type identifier and the corresponding indicator information within the service level requirement described by the user's intent. The pattern type identifier indicates the nature or trend of the deviation, such as whether it is consistently high or consistently low. The indicator information clarifies which specific service level indicator the deviation is associated with, such as latency or bandwidth. These two parts together constitute a comprehensive, structured description of the deviation. The pattern type identifier can be an enumeration value, such as "consistently high," "consistently low," or "sudden deviation," or a string label. The indicator information can be a unique identifier for a service level indicator, such as "latency" or "bandwidth," or a pointer to a specific indicator field within the service level requirement.

[0153] Based on the information indicated by this indicator, the specific service level indicator associated with the comprehension bias pattern is determined from among the multiple service level indicators included in the service level requirement. This step aims to accurately locate the specific service level indicator in the user's intent based on the clues provided in the bias feature description, thus providing a clear target for subsequent semantic mapping threshold adjustments. For example, the corresponding service level indicator can be retrieved and matched by querying the service level requirement data structure based on the indicator information (such as indicator name or ID). Alternatively, if the indicator information is an index, the target indicator can be obtained directly by accessing the list of indicators stored in the service level requirement through the index.

[0154] Based on the pattern type identifier, the direction of deviation of this understanding bias pattern from the specific service level indicator is determined. The pattern type identifier reflects whether the network domain's response to user intent is "too high" or "too low," thus allowing inference on how the semantic mapping threshold should be adjusted (increased or reduced). For example, a lookup table or conditional rule can be established to directly map different pattern type identifiers (such as "consistently high" and "consistently low") to predefined deviation directions (such as "positive deviation direction" and "negative deviation direction"). Alternatively, a decision logic can dynamically derive the deviation direction based on the semantic meaning of the pattern type identifier. The pattern type identifier for "consistently high" corresponds to a positive deviation direction, and the pattern type identifier for "consistently low" corresponds to a negative deviation direction. A positive deviation direction can be understood as needing to "reduce" the semantic mapping threshold because the network domain's actual reserved resources are too high, indicating an overly lenient understanding of intent. A negative deviation direction can be understood as needing to "increase" the semantic mapping threshold because the network domain's actual reserved resources are too low, indicating an overly strict understanding of intent.

[0155] By introducing a structured intermediate representation—the deviation feature description—the aforementioned technical solution deconstructs the understanding of deviation patterns from a single judgment label into structured information containing pattern type identifiers and indicator pointing information, thus solving the problem of the lack of precise execution direction in reverse calibration operations. Specifically, the deviation pattern understanding is feature-deconstructed, extracting deviation feature descriptions, which include pattern type identifiers and indicator pointing information. This step breaks down the comprehensive judgment result of the deviation pattern understanding into two independent information units, separating the behavioral form of the deviation from the attribution object of the deviation. This provides a structured input basis for subsequent step-by-step analysis, avoiding the ambiguity of parsing multi-dimensional information from a single label. Based on the indicator pointing information, the specific service level indicator associated with the understanding of the deviation pattern is determined from multiple service level indicators included in the service level requirements. This step achieves indicator-level positioning of deviation attribution, enabling the collaborative controller to clearly know whether the deviation is specifically associated with latency or bandwidth indicators, rather than simply knowing "a deviation exists," providing a precise target index for the targeted adjustment of semantic mapping thresholds. Based on pattern type identifiers, the deviation direction of the understanding bias pattern on a specific service level indicator is determined. A pattern type identifier indicating a consistently high bias corresponds to a positive deviation direction, while a pattern type identifier indicating a consistently low bias corresponds to a negative deviation direction. This step establishes a mapping relationship between the deviation behavior pattern and the adjustment direction, enabling the collaborative controller to automatically determine whether to amplify or reduce the semantic mapping threshold based on the deviation type, thus achieving automated connection from deviation diagnosis to calibration action. Through the above three-layer progressive feature deconstruction and parsing mechanism, this application transforms the understanding bias pattern from an "identified result" into an "executable calibration instruction source," providing direct technical support for precise reverse calibration at the indicator level of intent parsing benchmarks, and improving the execution accuracy and automation level of the reverse calibration chain in the bidirectional collaborative evolution closed loop.

[0156] In some of the solutions described above in this application, a feature deconstruction of the understanding deviation pattern is proposed to extract deviation feature descriptions for calibrating the intent parsing benchmark. However, in its implementation, how to accurately construct the deviation feature descriptions based on the persistent features and related indicators on which the understanding deviation pattern is determined, to ensure that it accurately reflects the actual understanding deviation pattern in the network domain, and to avoid the failure of intent parsing benchmark calibration due to incomplete feature deconstruction or incorrect identification of deviation direction, thus failing to solve the recurring conflict problem in cross-domain resource scheduling.

[0157] To address this, this application further proposes a feature deconstruction method for understanding deviation patterns, extracting deviation feature descriptions from these patterns. Specifically, this includes: determining candidate persistence type identifiers for the understanding deviation pattern based on the type attribution of persistent features used in its determination process; determining indicator pointing information for the understanding deviation pattern based on specific service level indicators associated with it during the determination process; and combining the candidate persistence type identifiers and indicator pointing information to obtain the deviation feature descriptions of the understanding deviation pattern.

[0158] The process involves classifying persistent features used in determining bias patterns to identify candidate persistence type identifiers. This aims to identify the basic behavioral patterns exhibited by the network domain's misunderstanding of user intent. This classification reflects the persistence trend of the bias in multiple rounds of scheduling, such as consistently high, consistently low, ambiguous direction, or sudden deviation. In practical implementation, one approach is to directly use the persistent feature types identified during bias pattern determination as candidate persistence type identifiers. For example, if a bias pattern is determined to be "consistently high," it is directly used as the identifier. Another approach is for the collaborative controller to classify bias patterns based on their internal attributes or historical evolution data using a pre-defined rule set or machine learning model, thereby inferring the most suitable persistence type identifier. For example, analyzing the mean, variance, and trend slope of the bias values ​​can determine its type.

[0159] Based on the specific service level indicators (SPIs) associated with the determination of the understanding bias pattern, this study aims to determine the indicator-related information of the understanding bias pattern. The goal is to clarify which SPI(s) in the user's intent the understanding bias pattern specifically affects. For example, user intent might include latency constraints and bandwidth requirements, while the understanding bias pattern might primarily manifest as a persistent deviation from latency constraints. In practical implementation, one approach is to directly extract the associated SPIs from the understanding bias pattern's internal structure or associated metadata when it is determined. Another approach is to trace the current understanding bias pattern back to the key SPIs involved in its formation process by querying historical association records or performing contextual analysis, thereby determining its indicator-related information.

[0160] By combining candidate persistence type identifiers and indicator pointing information, a deviation feature description for understanding deviation patterns is obtained. This aims to structurally integrate the "nature" and "object" of the deviation into a comprehensive and actionable description. In practical implementation, one approach is to encapsulate both into a structured data object, such as a JSON object or tuple containing "type" and "indicator" fields, facilitating subsequent programmatic processing. Another approach is to concatenate them into a string with a specific format, such as "type_indicator," as a unique identifier. This combination ensures that the deviation feature description includes both the dynamic trend information of the deviation and the specific service level dimension information of its effect.

[0161] The above technical solution enables accurate feature deconstruction of understanding bias patterns, generating a comprehensive and structured description of bias features. This description not only clarifies the persistence type of the network domain's understanding bias of user intent (e.g., whether it is a persistent overestimation or underestimation of resources), but also precisely identifies the specific service level indicator associated with this bias (e.g., latency or bandwidth). Therefore, when performing reverse calibration on the intent parsing benchmark subsequently, the semantic mapping thresholds corresponding to specific service level indicators in the intent parsing benchmark can be adjusted in a targeted manner based on this accurate bias feature description. For example, if the bias feature description indicates "persistently high" and is associated with the "bandwidth" indicator, the system will adjust the bandwidth semantic mapping threshold accordingly to better reflect the actual bandwidth supply capacity of the network domain. This precise calibration avoids blind or generalized adjustments, thereby resolving the recurring conflicts caused by the disconnect between the intent parsing benchmark and actual resource supply capacity in cross-domain resource scheduling, and improving the accuracy of the collaborative controller's understanding of user intent and the effectiveness of resource scheduling in multi-round scheduling.

[0162] In some of the solutions described above in this application, the adjustment direction and adjustment magnitude of the semantic mapping threshold are proposed for reverse calibration of the intent parsing benchmark. However, in this process, the adjustment magnitude may be inaccurate, leading to over-calibration or under-calibration, and failing to adapt to the persistence intensity of the deviation or the historical adjustment frequency, thereby affecting the accuracy and stability of the calibration.

[0163] To address this, this application further proposes a method for determining the adjustment direction and magnitude of the semantic mapping threshold corresponding to the specific service level indicator in the intent parsing benchmark, based on the deviation direction and the original semantic constraint value. The method includes: mapping the deviation direction to the adjustment direction of the semantic mapping threshold, wherein a positive deviation direction corresponds to reducing the semantic mapping threshold, and a negative deviation direction corresponds to increasing the semantic mapping threshold. The method also involves obtaining the deviation persistence intensity corresponding to the understanding deviation pattern, which is determined based on the number of consecutive scheduling rounds in which the persistence feature associated with the understanding deviation pattern persists. Based on the deviation persistence intensity and the original semantic constraint value, the method determines the adjustment magnitude of the semantic mapping threshold, wherein a larger deviation persistence intensity corresponds to a larger adjustment magnitude, and a larger original semantic constraint value corresponds to a larger adjustment magnitude. Finally, the method obtains historical adjustment records of the semantic mapping threshold in historical scheduling rounds, and when the historical adjustment records indicate that the semantic mapping threshold has been adjusted more than a preset number of times within a preset time window, applies a decay correction to the adjustment magnitude.

[0164] For example, the deviation direction is mapped to the adjustment direction of the semantic mapping threshold, where a positive deviation direction corresponds to decreasing the semantic mapping threshold, and a negative deviation direction corresponds to increasing the semantic mapping threshold. This step aims to establish a direct logical relationship between the detected deviation direction and the required adjustment direction of the semantic mapping threshold, ensuring that the calibration operation proceeds in the correct direction. For instance, when a positive deviation direction is detected (which may mean that the resources actually provided by the network domain exceed the user's intent, or that the user's intent description is too lenient), the system will adjust the semantic mapping threshold to decrease, making it more stringent. Conversely, when a negative deviation direction is detected (which may mean that the resources actually provided by the network domain are insufficient to meet the user's intent, or that the user's intent description is too stringent), the system will adjust the semantic mapping threshold to increase, making it more lenient. This can be achieved through a simple conditional judgment or lookup table mechanism; for example, if the deviation direction is positive, the adjustment factor is less than 1; if the deviation direction is negative, the adjustment factor is greater than 1.

[0165] The persistence strength of the comprehension bias pattern is obtained, determined based on the number of consecutive scheduling rounds in which the associated persistent feature persists. This step quantifies the persistence or entrenched nature of the detected comprehension bias pattern. A higher persistence strength indicates a longer duration of the bias pattern across multiple scheduling rounds, potentially leading to a more profound impact on the intent resolution benchmark, thus requiring further adjustments. For example, the collaborative controller can maintain a historical record of the number of times each comprehension bias pattern and its associated persistent feature appear in consecutive scheduling rounds; this number serves as the persistence strength. Alternatively, weighted averaging or exponential smoothing methods can be used to comprehensively evaluate the occurrence of persistent features in recent scheduling rounds to obtain a more dynamic persistence strength.

[0166] Based on the persistence of the bias and the original semantic constraint value, the adjustment magnitude of the semantic mapping threshold is determined, wherein the greater the persistence of the bias and the greater the original semantic constraint value, the greater the adjustment magnitude. This step provides a dynamically adaptive adjustment magnitude calculation mechanism. It ensures that the calibration force adequately responds to the persistence of the bias and the importance of the original constraint described by the user intent. For example, a function can be designed that takes the persistence of the bias and the original semantic constraint value as input and outputs the adjustment magnitude. This function can be linear, such as the adjustment magnitude being equal to the weighted sum of the two input parameters. It can also be non-linear, for example, where the adjustment magnitude grows exponentially when both the persistence of the bias and the original semantic constraint value reach high levels.

[0167] The system retrieves historical adjustment records of the semantic mapping threshold in historical scheduling rounds. When these records indicate that the threshold has been adjusted more than a preset number of times within a preset time window, a decay correction is applied to the adjustment magnitude. This step serves as a stabilization mechanism to prevent system oscillations caused by frequent or excessive adjustments. If a semantic mapping threshold is frequently adjusted within a short period, it may indicate that previous adjustments were ineffective or too aggressive. The decay correction reduces the magnitude of the current adjustment, stabilizing the system. For example, the co-controller can maintain an adjustment log, recording the timestamp and adjustment amount for each semantic mapping threshold. After calculating the initial adjustment magnitude, the system checks the number of times the threshold has been adjusted in the most recent N scheduling rounds or within the past T time period. If the number of adjustments exceeds a preset threshold, the calculated adjustment magnitude is multiplied by a decay factor (e.g., 0.5 or 0.8), thereby reducing the actual adjustment amount.

[0168] The above technical solution accurately determines the adjustment direction and magnitude of the semantic mapping threshold in the intent parsing benchmark, thus solving the problems of inaccurate adjustment, over-calibration, or under-calibration during the calibration process. For example, directly mapping the deviation direction to the adjustment direction ensures the correctness of the calibration operation and avoids invalid adjustments due to incorrect direction. By obtaining the deviation persistence intensity corresponding to the understood deviation pattern and combining it with the original semantic constraint value to dynamically determine the adjustment magnitude, the calibration intensity can adaptively respond to the persistence of the deviation and the importance of the business flow, ensuring the sufficiency and rationality of the adjustment. In addition, the introduction of historical adjustment records and the application of attenuation correction mechanism effectively prevents system oscillations and over-calibration caused by frequent adjustments, improving the accuracy and stability of intent parsing benchmark calibration. This enables the collaborative controller to more accurately perceive the actual resource supply capacity of each network domain and continuously optimize the intent parsing method, thereby effectively reducing cross-domain resource scheduling conflicts in multi-round scheduling and improving overall scheduling efficiency and user experience.

[0169] In some of the embodiments described above in this application, a reverse calibration operation is proposed to perform on the intent parsing benchmark based on the understanding bias pattern and user intent, in order to adjust the semantic mapping threshold to match the actual resource supply capacity of the network domain. However, in its implementation, direct adjustment may be unverified, resulting in invalid adjustment or the introduction of new problems. It cannot be ensured that the calibrated benchmark truly improves resource scheduling behavior, and may instead exacerbate cross-domain resource conflicts or waste scheduling resources.

[0170] In response, this application proposes a method for adjusting the semantic mapping threshold corresponding to a specific service level indicator in the intent parsing benchmark by adjusting the direction and magnitude of the adjustment. The method includes: Based on the adjustment direction and magnitude, candidate adjustment values ​​for the semantic mapping threshold are generated. This step aims to calculate a new, potential semantic mapping threshold based on a previously determined adjustment direction (e.g., scaling up or down) and adjustment magnitude (e.g., a specific value or percentage). For example, a linear adjustment method can be used, setting the candidate adjustment value to the current semantic mapping threshold plus or minus the adjustment magnitude. Alternatively, a proportional adjustment method can be used, multiplying the current semantic mapping threshold by a scaling factor based on the adjustment magnitude. Furthermore, a lookup table or non-linear function can be used to select the most suitable candidate value from a preset set of thresholds based on the adjustment direction and magnitude.

[0171] This step involves retrieving historical resource mapping records for each network domain across different scheduling rounds, targeting specific service level indicators (SLEs). The purpose of this step is to provide authentic historical data support for subsequent verification. The coordinating controller can query its maintained historical database, which stores information such as the actual resource reservation amounts, user intent descriptions, and corresponding inter-domain resource reservation behavior representations for each network domain across different scheduling rounds, targeting specific SLEs (e.g., latency, bandwidth). Alternatively, by analyzing the historical operation logs of the coordinating controller or each network domain, resource allocation decisions and actual execution results related to specific SLEs can be extracted and compiled to form historical resource mapping records. In large-scale network environments, this historical data can also be retrieved and aggregated from distributed storage systems.

[0172] The process involves replacing the current semantic mapping threshold in the intent parsing baseline with candidate adjustment values, and then performing backtracking simulations on historical scheduling rounds corresponding to historical resource mapping records. This calculates the degree of improvement in the inter-domain resource reservation behavior representation in historical scheduling rounds if the candidate adjustment values ​​were used. This step evaluates the potential effect by hypothetically applying the new threshold to historical scenarios. For example, a lightweight scheduling simulator can be built, loading historical user intents and network domain states, and using candidate adjustment values ​​for intent parsing. The simulator recalculates the inter-domain resource reservation behavior representation in each historical scheduling round based on the new parsing results. The degree of improvement can be quantified as the difference between the simulation results and actual historical results, such as the reduction in conflict indication components in the inter-domain resource reservation behavior representation, or the increase in positive resource mapping matching degree. Another approach is to utilize offline computing frameworks, such as Spark, to batch process historical data, inputting the candidate adjustment values ​​as parameters into an offline version of the intent parsing module to re-evaluate the inter-domain resource reservation behavior representation.

[0173] When the improvement reaches a preset improvement threshold, the semantic mapping threshold is updated with candidate adjustment values. This step is the decision point for actually adopting the adjustment. The collaborative controller compares the improvement calculated by backtracking simulation with the preset improvement threshold. For example, if the improvement is defined as the percentage reduction of conflict components in the inter-domain resource reservation behavior representation, when this reduction percentage reaches or exceeds a preset threshold (e.g., 10%), the system will perform an update operation, officially replacing the current semantic mapping threshold in the intent resolution baseline with candidate adjustment values. This ensures that only verified adjustments that bring actual improvement are applied.

[0174] If the improvement level does not reach the preset improvement threshold, the adjustment operation is abandoned, and the comprehension deviation pattern is marked as "verification failed." This step serves as a risk control mechanism; if the results of the backtracking simulation fail to meet the expected improvement standards, the system will not adopt the adjustment. The system will mark the corresponding comprehension deviation pattern as "verification failed." This not only avoids introducing invalid or potentially harmful changes but also provides important feedback for subsequent diagnosis and optimization, suggesting that the identification or adjustment strategy for this comprehension deviation pattern may need to be re-examined.

[0175] The above technical solution introduces a backtracking simulation-based verification mechanism to address the potential blindness and uncertainty in intent resolution benchmark adjustments. Before adjusting the semantic mapping thresholds in the intent resolution benchmark, the collaborative controller can conduct "sandbox" testing using historical scheduling data to evaluate the potential impact of candidate adjustment values ​​on the representation of inter-domain resource reservation behavior. This pre-verification approach ensures that only adjustments that can actually improve resource scheduling behavior and reduce cross-domain conflicts are adopted, thus avoiding the negative impact of ineffective adjustments on system performance and resource waste. Labeling interpretation bias patterns that fail verification provides the collaborative controller with valuable learning opportunities, enabling it to more accurately identify and handle interpretation biases in network domains, continuously optimize the accuracy and robustness of intent resolution, and ultimately improve the scheduling efficiency and resource utilization of cross-domain service flows.

[0176] In some of the solutions mentioned above in this application, semantic parsing of user intents to be processed in the next scheduling round is performed based on a calibrated intent parsing benchmark. The parsing results are then used to drive cross-domain path selection and cross-domain resource allocation for cross-domain service flows to achieve intent-driven resource scheduling. However, in its implementation, the lack of an accurate extraction mechanism for service level requirement descriptions may lead to inaccurate semantic parsing. The lack of a defined method for converting semantic mapping thresholds into executable constraint parameters makes it difficult to directly use the parsing results for path selection. Furthermore, the failure to consider the actual resource availability status of the network domain during path selection and resource allocation can easily lead to a disconnect between scheduling decisions and network domain capabilities, resulting in low resource reservation efficiency and repeated conflicts in cross-domain service flows.

[0177] To address this, this application further proposes to perform semantic parsing on the user intents to be processed in the next scheduling round, based on a calibrated intent parsing benchmark, and use the parsing results to drive the cross-domain path selection and cross-domain resource allocation for the cross-domain service flow. See [link to relevant documentation]. Figure 5 This includes the following steps.

[0178] 501. Perform semantic recognition on the user intent to be processed in the next scheduling round, and extract the service level requirement description contained in the user intent.

[0179] Semantic recognition aims to accurately understand a user's Quality of Service (QoS) requirements from natural language or structured text input. This can be achieved in various ways. For example, rule-based pattern matching algorithms can be used to predefine keywords and phrases to identify QoS indicators such as latency, bandwidth, and jitter, along with their modifiers. Alternatively, Natural Language Processing (NLP) techniques, such as word embeddings, recurrent neural networks (RNNs), or Transformer models, can be used to perform deep semantic analysis of user intent, thereby more accurately capturing their implicit QoS requirements. Extracting the QoS description involves transforming the identified semantic information into structured data suitable for subsequent processing. For example, it can be represented as key-value pairs (such as "latency: low", "bandwidth: high") or a predefined data structure.

[0180] 502. Match the service level requirement description with the calibrated intent parsing benchmark to determine the semantic mapping threshold corresponding to the service level requirement description in the intent parsing benchmark.

[0181] This step aims to transform abstract service level requirement descriptions into concrete, quantifiable technical indicators. The matching process can employ a lookup table-based approach, mapping specific service level requirement descriptions (such as "low latency") to preset semantic mapping threshold ranges or specific values. Alternatively, fuzzy logic matching can be used, dynamically calculating the mapping threshold that best matches the current semantics based on the degree of fuzziness in the requirement description within a calibrated intent resolution benchmark. The calibrated intent resolution benchmark is the core of this method; it reflects the actual resource supply capacity of each network domain, making the determined semantic mapping thresholds more practically relevant.

[0182] 503. Based on the semantic mapping threshold, generate structured service level constraint parameters, and use the service level constraint parameters as the parsing result of the semantic parsing.

[0183] The purpose of generating structured constraint parameters is to transform semantically mapped thresholds into quantitative indicators that can be directly used for network scheduling decisions. For example, for latency thresholds, a specific number of milliseconds can be generated as the end-to-end latency upper limit. For bandwidth thresholds, a specific value in Mbps can be generated as the end-to-end bandwidth lower limit. These parameters can be encapsulated into a unified data format, such as a JSON object or an XML document, containing information such as service level indicator type (e.g., latency, bandwidth), constraint value, and unit, ensuring that they can be directly parsed and applied by subsequent scheduling modules.

[0184] 504. Using the service level constraint parameter as the scheduling constraint, perform cross-domain candidate path screening on the cross-domain business flow to obtain a set of candidate paths that meet the service level constraint parameter.

[0185] The purpose of path selection is to identify all potential paths that meet user service level requirements from a complex cross-domain network topology. This can be achieved through various graph algorithms. For example, an improved Dijkstra's algorithm or the K-shortest path algorithm can be used to search for paths that meet the requirements while considering constraints such as latency and bandwidth. Alternatively, a constraint-based programming (CSP) approach can be employed, using service level constraints as conditions to find feasible solutions in the network topology graph. During the selection process, the end-to-end performance metrics (such as latency and available bandwidth) of each path are evaluated in real time and compared with the service level constraints to ensure that the selected paths meet the user's intent.

[0186] 505. In the candidate path set, based on the intra-domain resource availability status of each network domain in the next scheduling round, perform cross-domain resource allocation to determine the carrying path of the cross-domain service flow and the resource reservation amount of each network domain.

[0187] This step aims to select the optimal path from the eligible paths and make actual resource reservations. The availability of resources within a domain can be obtained through periodic reports from each network domain, such as resource utilization and remaining capacity, ensuring that scheduling decisions are based on the latest network conditions. Resource allocation can employ various strategies. For example, it can be optimized based on the overall cost of the path (e.g., hop count, load, resource utilization) and use greedy algorithms or linear programming models to determine the specific resource reservation amount for each network domain. Alternatively, it can combine machine learning models to predict the performance of each path based on historical scheduling data and the current network state, and select the path that best meets service level constraints and has the highest resource utilization.

[0188] The above technical solution solves the problems of inaccurate intent parsing and disconnect between scheduling decisions and the original intent. By semantically recognizing user intents and extracting service level requirement descriptions, it ensures the accurate capture of key needs from the original intent, avoiding parsing deviations caused by information omissions or misinterpretations, and providing reliable input for subsequent accurate matching. Matching the extracted requirement descriptions with a calibrated intent parsing benchmark determines semantic mapping thresholds. This fully utilizes the dynamic adjustment characteristics of the calibration benchmark, ensuring that the determined thresholds more accurately reflect the actual resource supply capacity of each network domain, thereby reducing the deviation between intent parsing and actual network capacity. Based on the semantic mapping thresholds, structured service level constraint parameters are generated, transforming the abstract intent thresholds into quantifiable and executable scheduling conditions, greatly facilitating the subsequent scheduling decision-making process and allowing the parsing results to be directly used for path selection. Using these structured service level constraint parameters as conditions to select cross-domain candidate paths ensures that the selected paths strictly meet the service level requirements of the user intent, improving the efficiency and accuracy of path selection. In the candidate path set, cross-domain resource allocation is performed by combining the intra-domain resource availability status of each network domain in the next scheduling round. This allows scheduling decisions to fully consider real-time network resource conditions, optimize resource utilization efficiency, and effectively reduce repeated conflicts caused by the disconnect between resource allocation and network capabilities. Overall, this application achieves seamless connection and efficient transformation from user intent to network resource scheduling by refining each step of semantic parsing and scheduling-driven processes, thereby improving the accuracy, adaptability, and overall performance of cross-domain resource scheduling.

[0189] In some of the embodiments described above in this application, a method is proposed to match the service level requirement description with a calibrated intent parsing benchmark to determine a semantic mapping threshold, so as to achieve accurate parsing of user intent and drive resource scheduling. However, in the implementation process, the natural language description of user intent may contain ambiguous words or complex expressions, which makes it impossible for the matching process to accurately identify the specific meaning and constraint degree of the service level indicators. This results in inaccurate setting of the semantic mapping threshold, affecting the accuracy of subsequent cross-domain path selection and resource allocation, and causing scheduling conflicts and resource waste.

[0190] To address this, this application further proposes matching the service level requirement description with the calibrated intent parsing benchmark to determine the semantic mapping threshold corresponding to the service level requirement description in the intent parsing benchmark. This includes: performing word segmentation on the service level requirement description, extracting service level indicator words and constraint degree modifiers from the segmentation results; comparing the service level indicator words with each service level indicator included in the calibrated intent parsing benchmark to determine the target service level indicator corresponding to the service level indicator word in the intent parsing benchmark; determining the value tendency of the semantic mapping threshold corresponding to the target service level indicator based on the constraint degree modifier; and obtaining the semantic mapping threshold corresponding to the target service level indicator under this value tendency in the intent parsing benchmark.

[0191] For example, the service level requirement description is segmented into words to extract service level indicator terms and constraint modifiers. This aims to decompose the user's service level requirement, expressed in natural language, into identifiable and actionable atomic units. Word segmentation is a fundamental step in natural language processing, dividing a continuous text sequence into words with independent semantics. Service level indicator terms describe specific service quality parameters, such as "latency," "bandwidth," and "jitter." Constraint modifiers quantify or limit these service quality parameters, such as "high," "low," "minimum," "maximum," "strict," and "lenient." This segmentation can be implemented in various ways. For instance, a dictionary- and rule-based approach can be used, pre-constructing a dictionary containing service level indicator terms and constraint modifiers, and then matching and extracting them using grammatical rules. Alternatively, a machine learning-based approach can be used, training a sequence labeling model (such as a Conditional Random Field (CRF), Recurrent Neural Network (RNN), or Transformer model) to automatically identify and extract service level indicator terms and constraint modifiers from the user's intent description.

[0192] The service level indicator (SLE) term is compared with each SLE indicator included in the calibrated intent parsing benchmark to determine the target SLE indicator corresponding to the SLE term in the intent parsing benchmark. The purpose of this step is to establish an accurate correspondence between the natural language expression of the user's intent and the standardized SLE indicators within the system. Through comparison, the collaborative controller can accurately understand the specific service quality parameters referred to by the user, even if the user uses different expressions. This comparison process can be implemented using various techniques. For example, precise string matching can be performed to ensure that the user's vocabulary is completely consistent with the indicators defined in the benchmark. Fuzzy matching techniques (such as edit distance and Jaccard similarity) can also be used to address potential spelling errors or the use of synonyms. Furthermore, word vectors or semantic similarity models can be used to determine the best-matching target SLE indicator by calculating the semantic similarity between the SLE term and each indicator in the benchmark.

[0193] Based on the constraint degree modifier, the tendency of the semantic mapping threshold corresponding to the target service level indicator is determined. This step transforms the qualitative or relative constraint description in the user's intent into a quantitative tendency for adjusting the semantic mapping threshold. For example, when the constraint degree modifier is "high" and the service level indicator is "bandwidth," the tendency might be "amplify" or "maximize." When the constraint degree modifier is "low" and the service level indicator is "latency," the tendency might be "reduce" or "maximize." This tendency can be determined through preset mapping rules. For example, a mapping table can be constructed to directly associate different constraint degree modifiers with specific tendencyes. Alternatively, for modifiers with varying degrees (such as "very high" or "slightly low"), a grading mechanism can be designed to map the intensity of the modifier to different tendency levels.

[0194] In this intent resolution benchmark, the semantic mapping threshold corresponding to the target service level indicator under the given value tendency is obtained. This step involves retrieving or calculating the numerical semantic mapping threshold from the calibrated intent resolution benchmark based on the aforementioned analysis results. The intent resolution benchmark may store a series of preset thresholds for each service level indicator, which may be categorized according to different value tendencies (such as "strict," "general," and "lenient"). The collaborative controller can directly look up the corresponding threshold from the benchmark based on the determined target service level indicator and value tendency. Alternatively, if the benchmark stores a threshold range or a generating function, the collaborative controller can select an appropriate value within that range based on the value tendency, or calculate the threshold using a function.

[0195] The above technical solution addresses the ambiguity and complexity inherent in the natural language description of user intent. By segmenting the service level requirement description and extracting service level indicator words and constraint degree modifiers, user intent is transformed from unstructured natural language into structured key information, thus eliminating ambiguity caused by vague vocabulary or complex expressions. Comparing the extracted service level indicator words with the calibrated intent parsing benchmark ensures the collaborative controller accurately identifies the service level indicator referred to by the user, avoiding deviations in indicator interpretation. Furthermore, by determining the tendency of semantic mapping threshold values ​​based on constraint degree modifiers, the collaborative controller can accurately grasp the strength and direction of the user's service level constraints, thereby obtaining the semantic mapping threshold that best matches the user's actual needs from the calibrated intent parsing benchmark. Therefore, this application improves the accuracy of user intent parsing, ensuring that the set semantic mapping threshold accurately reflects the user's service level requirements. This provides more accurate scheduling constraints for subsequent cross-domain path selection and cross-domain resource allocation, effectively avoiding scheduling conflicts and resource waste caused by inaccurate threshold settings, thereby improving the efficiency and reliability of the entire cross-domain business flow scheduling.

[0196] In some of the embodiments described above in this application, structured service level constraint parameters are proposed to convert semantic mapping thresholds into operable scheduling constraints. However, in the implementation process, due to the lack of distinction between service level indicator types (such as latency type and bandwidth type), improper setting of constraint parameters may occur (such as misusing the latency threshold as the lower limit or the bandwidth threshold as the upper limit), thereby affecting the accuracy of cross-domain path selection and the efficiency of resource allocation, and exacerbating scheduling conflicts.

[0197] To address this, this application further proposes a method for generating structured service level constraint parameters based on a semantic mapping threshold, comprising: obtaining the service level indicator type corresponding to the semantic mapping threshold, wherein the service level indicator type includes latency type and bandwidth type; when the service level indicator type is latency type, using the semantic mapping threshold as the upper limit value of the end-to-end latency constraint to generate latency constraint parameters; when the service level indicator type is bandwidth type, using the semantic mapping threshold as the lower limit value of the end-to-end bandwidth constraint to generate bandwidth constraint parameters; and combining the latency constraint parameters and the bandwidth constraint parameters to form structured service level constraint parameters.

[0198] For example, when obtaining the service level indicator (SPI) type corresponding to a semantic mapping threshold, this SPI type includes latency type and bandwidth type. This step aims to identify the essential attributes of the SPI represented by the semantic mapping threshold, which is the foundation for the correct application of constraints subsequently. One implementation is to pre-define a type identifier (e.g., through enumeration values ​​or string labels) for each semantic mapping threshold in the intent parsing benchmark, and synchronously read its associated type identifier when a semantic mapping threshold is obtained. Another implementation is to dynamically infer the SPI type based on the name, source, or contextual information of the semantic mapping threshold in the user's intent using a rule engine or machine learning model. For example, thresholds associated with keywords such as "low latency" and "fast response" can be identified as latency type, while thresholds associated with keywords such as "high throughput" and "large capacity" can be identified as bandwidth type.

[0199] When the service level indicator type is latency-related, the semantic mapping threshold is used as the upper limit of the end-to-end latency constraint to generate latency constraint parameters. This step ensures that latency-sensitive services can obtain low latency guarantees that meet user expectations. One implementation is to directly use the semantic mapping threshold value as the upper limit of the latency constraint parameter. For example, if the threshold is 50ms, the latency constraint parameter is set to "latency ≤ 50ms". Another implementation is to fine-tune the semantic mapping threshold based on historical network performance data or preset safety margins, in addition to direct assignment. For example, the 50ms threshold can be adjusted to 48ms as the upper limit to cope with network fluctuations, thereby generating more robust latency constraint parameters.

[0200] When the service level indicator type is bandwidth-based, the semantic mapping threshold is used as the lower limit of the end-to-end bandwidth constraint to generate bandwidth constraint parameters. This step ensures that bandwidth-demanding services can obtain resources that meet their minimum throughput requirements. One implementation is to directly use the semantic mapping threshold value as the lower limit of the bandwidth constraint parameters. For example, if the threshold is 100Mbps, the bandwidth constraint parameter is set to "bandwidth ≥ 100Mbps". Another implementation is to appropriately increase the semantic mapping threshold, considering network protocol overhead or conversion loss between the application layer and the network layer, to ensure that actual network resources can meet the effective bandwidth required by the application. For example, the 100Mbps threshold can be adjusted to 105Mbps as the lower limit, thereby generating bandwidth constraint parameters that better meet actual needs.

[0201] The latency and bandwidth constraints are combined into a structured service level constraint parameter. This step aims to integrate constraints from different dimensions into a unified, easily processed data structure so that subsequent scheduling modules can use it efficiently. One implementation is to encapsulate the latency and bandwidth constraints in a composite data object (e.g., a JSON object, XML structure, or a struct in a programming language), containing explicit fields representing the upper and lower limits of latency and bandwidth. Another implementation is to format these parameters into standard-compliant data packets or message bodies according to a predefined API interface specification or network management protocol (such as NETCONF / YANG) data model, so that they can be directly passed to the path calculation engine or resource orchestrator.

[0202] The above technical solution accurately identifies the service level indicator type represented by the semantic mapping threshold and converts it into the correct constraint form (latency upper limit, bandwidth lower limit) based on its inherent characteristics (such as latency minimization and bandwidth maximization). This effectively avoids the problem of improper constraint parameter settings caused by type confusion, such as misusing the latency threshold as the lower limit or the bandwidth threshold as the upper limit, thereby improving the accuracy of cross-domain path selection and the efficiency of resource allocation. By generating structured and correctly typed service level constraint parameters, the collaborative controller can more accurately understand user intent and transform it into network-executable scheduling instructions, thereby reducing conflicts caused by intent misunderstanding during scheduling and ensuring that cross-domain business flows can obtain stable and reliable service quality assurance.

[0203] In some of the solutions described above in this application, service level constraint parameters are generated based on a calibrated intent parsing benchmark to drive cross-domain path selection. However, in this process, when the service level constraint parameters are set too strictly or the network status changes dynamically, the candidate path set may become empty, making it impossible to find a feasible path that meets the constraints, thus causing scheduling failure. Existing mechanisms lack adaptive adjustment capabilities and cannot automatically optimize parameters when constraints are unrealistic, causing resource scheduling to be repeatedly interrupted in multiple rounds of execution and failing to adapt to changes in actual network conditions.

[0204] To address this issue, this application proposes a cross-domain candidate path filtering method. Using service level constraint parameters as scheduling constraints, it filters cross-domain candidate paths for cross-domain service flows, obtaining a set of candidate paths that satisfy the service level constraint parameters. This method obtains a cross-domain topology view of the cross-domain service flows within the jurisdiction of the coordinating controller and extracts all reachable cross-domain paths from this view. The coordinating controller abstracts and represents the entire network infrastructure, forming a cross-domain topology view that includes key information such as interconnection relationships, link capacity, and latency between network domains. For example, the coordinating controller can periodically collect topology information from domain controllers or network devices in each network domain, and perform aggregation, deduplication, and modeling to form a unified cross-domain topology view. For instance, it can use protocols such as BGP-LS or PCEP to obtain inter-domain link status information and construct a graph database or topology information repository. Furthermore, the coordinating controller can maintain a global network resource inventory and, combined with predefined inter-domain interconnection policies, dynamically calculate and generate all possible cross-domain paths that the current service flow may traverse. These paths can be physical paths or logical tunnels.

[0205] For each cross-domain path, obtain the end-to-end latency and end-to-end available bandwidth measurements. This step aims to obtain real-time or near-real-time performance metrics for each potential path to ensure that path evaluation is based on actual network conditions. For example, the coordinating controller can periodically send probe packets to each network domain, such as based on TWAMP or OWAMP protocols, to measure round-trip latency and jitter on a specific path, and combine this with link utilization information reported by each domain to estimate end-to-end available bandwidth. Alternatively, the coordinating controller can integrate a network performance monitoring system to collect traffic statistics and performance data from network devices via protocols such as SNMP, NetFlow / IPFIX, and then calculate the end-to-end latency and available bandwidth for each cross-domain path using a path aggregation algorithm.

[0206] The first compliance comparison is performed between the end-to-end latency measurement and the latency constraint parameter in the service level constraint parameters. The second compliance comparison is performed between the end-to-end available bandwidth measurement and the bandwidth constraint parameter in the service level constraint parameters. This step compares the actual measured performance of each path with the user-defined service level requirements. For example, for latency comparison, the end-to-end latency measurement of the path can be directly compared with the latency constraint parameter (usually the upper limit). If the measured value exceeds the constraint value, it is deemed non-compliant. Alternatively, a preset safety margin can be added to the measured value before comparison with the constraint parameter. For bandwidth comparison, the end-to-end available bandwidth measurement of the path can be compared with the bandwidth constraint parameter (usually the lower limit). If the measured value is lower than the constraint value, it is deemed non-compliant. Alternatively, a preset margin can be subtracted from the measured value before comparison with the constraint parameter.

[0207] Cross-domain paths that simultaneously meet both the first and second compliance checks are selected to form the candidate path set. This step aims to aggregate the results of various performance checks to identify all paths that simultaneously meet all specified service level requirements. For example, the coordination controller can maintain a Boolean flag for each path; if both the first and second compliance checks result in "pass," the path is added to the candidate path set. Alternatively, a filter-based mechanism can be used to filter out paths that do not meet latency constraints, and then further filter out paths that do not meet bandwidth constraints from the remaining paths, resulting in the candidate path set.

[0208] When the candidate path set is empty, the latency and bandwidth constraints in the service level constraint parameters are relaxed respectively. The first and second compliance comparisons are then re-executed with the relaxed constraint parameters until a non-empty candidate path set is obtained. This step is the core adaptive mechanism of this application, designed to find a feasible compromise by intelligently relaxing constraints when initial strict requirements cannot be met. For example, the relaxation process can use a fixed step increment or decrement; for instance, the latency constraint parameter can be increased by a preset percentage each time, and the bandwidth constraint parameter can be decreased by a preset percentage each time. Another approach is to dynamically adjust the relaxation step size and strategy based on historical scheduling failure experience or the current network congestion level. For example, if the overall network load is high, a larger relaxation step size can be used. If resources are scarce in a specific domain, more refined relaxation can be applied to paths related to that domain. The relaxation process can also set a maximum number of relaxations or a maximum relaxation magnitude to avoid excessive relaxation leading to a severe degradation in service quality. If no path can be found after reaching the maximum relaxation limit, it may be necessary to report the scheduling failure to the user or suggest adjustments to business requirements. Re-performing the first compliance comparison and the second compliance comparison means that the entire screening process will be repeated until at least one path is found.

[0209] The above technical solution addresses the problem that when service level constraint parameters are set too strictly or network conditions change dynamically, the candidate path set may become empty, making it impossible to find a feasible path that meets the constraints, thus causing scheduling failure. By obtaining actual cross-domain topology views and end-to-end measurements, this application can perform path evaluation based on accurate real-time data. More importantly, when the initial candidate path set is empty, the iterative relaxation mechanism introduced in this application can dynamically reduce the stringency of constraints, automatically adapting to changes in network conditions or overly strict initial constraints. This solves the problem of an empty set that may be caused by initial constraints, ensuring the robustness and adaptability of the scheduling process, avoiding scheduling interruptions due to the inability to find a path, and improving the success rate and flexibility of cross-domain resource scheduling. In this way, even under less than ideal network conditions or overly idealized user intent descriptions, the collaborative controller can find a feasible compromise to ensure service continuity. This makes the overall method of semantic parsing based on a calibrated intent parsing benchmark and driving cross-domain path selection and resource allocation more practical and reliable.

[0210] In some of the solutions mentioned above in this application, a compliance comparison is proposed between end-to-end latency measurements and bandwidth constraint parameters to screen candidate paths that meet service level constraint parameters. However, in this process, since the measurements may have historical biases, direct comparison may lead to inaccurate compliance judgments, thereby affecting the reliability of path screening and exacerbating conflicts in cross-domain resource scheduling.

[0211] To address this, this application further proposes a first compliance comparison between the end-to-end latency measurement and the latency constraint parameter in the service level constraint parameters, and a second compliance comparison between the end-to-end available bandwidth measurement and the bandwidth constraint parameter in the service level constraint parameters. Specifically, this includes: obtaining latency measurement deviation records reported by each network domain constituting the cross-domain path in historical scheduling rounds; determining a latency confidence interval for the end-to-end latency measurement based on these latency measurement deviation records; comparing the latency confidence interval with the latency constraint parameter; and determining that the first compliance comparison passes when the upper limit of the latency confidence interval is lower than the latency constraint parameter. Next, obtaining bandwidth measurement deviation records reported by each network domain constituting the cross-domain path in historical scheduling rounds; determining a bandwidth confidence interval for the end-to-end available bandwidth measurement based on these bandwidth measurement deviation records; and comparing the bandwidth confidence interval with the bandwidth constraint parameter; and determining that the second compliance comparison passes when the lower limit of the bandwidth confidence interval is higher than the bandwidth constraint parameter.

[0212] The process involves acquiring latency measurement deviation records reported by each network domain constituting the cross-domain path during historical scheduling rounds. This aims to collect historical data to quantify the unreliability or volatility of latency measurements. These records reflect the accuracy of latency measurements or the deviation of the network domain's own latency performance at different points in time. Specifically, after each scheduling cycle, each network domain can compare its reported actual latency with the expected latency by the coordinating controller and report the difference as a latency measurement deviation record. Alternatively, each network domain can periodically perform latency probing on its internal links or paths, compare the results with a baseline value, and summarize and report the deviation data to the coordinating controller.

[0213] Determining the confidence interval for the end-to-end delay measurement based on the delay measurement deviation record serves to quantify the uncertainty of the current end-to-end delay value using historical deviation data, obtaining a probability range that includes the true delay value. This reflects the actual situation more accurately than a single measurement value. For example, statistical methods can be used, such as calculating the mean and standard deviation of historical deviation records, and then constructing a delay confidence interval at a certain confidence level (e.g., 95%) based on a normal distribution or other suitable distribution. Alternatively, machine learning models, such as time series analysis or regression models, can be used to learn from historical delay measurement deviation records and predict the possible fluctuation range of the current delay measurement value, thereby determining the delay confidence interval.

[0214] The delay confidence interval is compared with the delay constraint parameter. If the upper limit of the delay confidence interval is lower than the delay constraint parameter, the first compliance comparison is considered passed. This aims to rigorously determine whether the path's delay performance meets the requirements. By comparing the upper limit of the confidence interval, it ensures that the path's delay meets the constraints even under the most unfavorable measurement deviation conditions, thereby improving the reliability of path selection. Specifically, the calculated upper limit of the delay confidence interval can be directly compared with the delay constraint parameter parsed from the user intent. Alternatively, a safety margin can be defined, and the upper limit of the delay confidence interval can be added to this margin before comparing it with the delay constraint parameter to provide additional fault tolerance.

[0215] This system acquires bandwidth measurement deviation records reported by each network domain constituting the cross-domain path during historical scheduling rounds. The aim is to collect historical data to quantify the unreliability or volatility of bandwidth measurements. These records reflect the accuracy of bandwidth measurements or the deviation of the network domain's own bandwidth performance at different points in time. Specifically, after each scheduling cycle, each network domain can compare its reported actual available bandwidth with the bandwidth expected by the coordinating controller, reporting the difference or ratio as a bandwidth measurement deviation record. Alternatively, each network domain can periodically perform bandwidth probes on its internal links or paths, compare the probe results with a baseline value, and summarize and report the deviation data to the coordinating controller.

[0216] Determining the bandwidth confidence interval for the end-to-end available bandwidth measurement based on the bandwidth measurement deviation record serves to quantify the uncertainty of the current measured end-to-end available bandwidth value using historical deviation data, obtaining a probability range that includes the true available bandwidth value. This reflects the actual situation more accurately than a single measurement value. For example, statistical methods can be used, such as calculating the mean and standard deviation of historical deviation records, and then constructing the bandwidth confidence interval at a certain confidence level (e.g., 95%) based on a normal distribution or other suitable distribution. Alternatively, machine learning models, such as time series analysis or regression models, can be used to learn from historical bandwidth measurement deviation records and predict the possible fluctuation range of the current bandwidth measurement value, thereby determining the bandwidth confidence interval.

[0217] The bandwidth confidence interval is compared with the bandwidth constraint parameter. If the lower limit of the bandwidth confidence interval is higher than the bandwidth constraint parameter, the second compliance comparison is considered passed. This aims to rigorously determine whether the path's bandwidth performance meets the requirements. By comparing the lower limit of the confidence interval, it ensures that even under the most unfavorable measurement deviation conditions, the path's available bandwidth meets the constraints, thereby improving the reliability of path selection. Specifically, the calculated lower limit of the bandwidth confidence interval can be directly compared numerically with the bandwidth constraint parameter parsed from the user intent. Alternatively, a safety margin can be defined, and the lower limit of the bandwidth confidence interval can be subtracted before comparing it with the bandwidth constraint parameter to provide additional fault tolerance.

[0218] The above technical solution improves the accuracy of compliance comparison by introducing a confidence interval mechanism based on historical deviations, thereby ensuring that path selection more reliably reflects actual resource supply capacity. For example, by obtaining delay measurement deviation records reported by each network domain constituting the cross-domain path in historical scheduling rounds, a deviation data foundation is provided for delay measurement, giving a practical basis for subsequent confidence interval calculations and avoiding reliance solely on current measurement values ​​while ignoring historical deviation patterns. Based on these delay measurement deviation records, the delay confidence interval for end-to-end delay measurements is determined, using historical deviation records to quantify measurement uncertainty and reduce the risk of misjudgment due to point estimation errors. When comparing the delay confidence interval with delay constraint parameters, comparing the upper limit of the confidence interval conservatively ensures that delay constraints are met even in the worst-case scenario, avoiding overestimation of delay performance due to measurement deviations. Similarly, obtaining bandwidth measurement deviation records reported by each network domain constituting the cross-domain path in historical scheduling rounds provides a bandwidth deviation data foundation, ensuring that bandwidth uncertainty assessment is based on evidence. Based on these bandwidth measurement deviation records, a bandwidth confidence interval is determined for the end-to-end available bandwidth measurement values, and the fluctuation range of bandwidth availability is quantified using historical deviation records. When comparing the bandwidth confidence interval with bandwidth constraint parameters, the lower limit of the confidence interval is compared to conservatively ensure that even the minimum available bandwidth meets the constraints, avoiding underestimation of bandwidth resources due to measurement deviations. This confidence interval comparison method based on historical deviations solves the problem of inaccurate judgments that may be caused by deviations in direct measurement comparisons, improves the robustness of path selection, and thus reduces resource scheduling conflicts caused by inaccurate path selection, improving the success rate and stability of cross-domain service flow scheduling.

[0219] In some of the embodiments described above in this application, cross-domain resource allocation is proposed based on the intra-domain resource availability status of each network domain in the next scheduling round to determine the bearer path and resource reservation. However, in its implementation, the deviation type corresponding to the deviation pattern of each network domain is not considered, which leads to the inability to prioritize resource allocation for network domains with insufficient resource supply, thereby failing to effectively correct the deviation pattern. This results in the scheduling result continuously deviating from the user's intention, with repeated conflicts that cannot be automatically resolved.

[0220] In response, this application further proposes a method for determining the bearer path of cross-domain service flows and the resource reservation amount of each network domain based on the intra-domain resource availability status of each network domain in the next scheduling round, within the candidate path set. This method includes: For each candidate path in the candidate path set, obtain the resource availability status within each network domain constituting the candidate path in the next scheduling round.

[0221] For each candidate path, obtain the deviation pattern type corresponding to each network domain constituting the candidate path in the understanding deviation pattern.

[0222] Based on the deviation pattern type, the resource allocation tendency weight of each network domain on each candidate path is determined. Among them, the resource allocation tendency weight of the network domain marked as consistently low is higher than that of the network domain marked as consistently high.

[0223] For each candidate path, the overall allocation fit is calculated using the resource availability status and resource allocation preference weights within the domain as inputs.

[0224] The candidate path with the highest overall allocation adaptability is selected as the bearer path for cross-domain business flows, and the resource reservation amount of each network domain is determined based on the availability status of intra-domain resources of each network domain on the bearer path.

[0225] For example, when obtaining the resource availability status of each network domain constituting the candidate path in the next scheduling round for each candidate path in the candidate path set, the resource availability status refers to the total amount and distribution of resources available within each network domain to carry service flows in the upcoming scheduling round. This includes, but is not limited to, link bandwidth, node processing capacity, and latency margin. Obtaining this status is the basis for reasonable resource allocation, ensuring that allocation decisions are based on the latest and actually available resource conditions. The coordination controller can periodically receive resource status reports from the domain controllers or network management systems of each network domain. These reports can contain detailed information such as real-time bandwidth utilization, remaining bandwidth, node queue depth, and latency measurements of links within each domain. Alternatively, the coordination controller can proactively initiate query requests to each network domain to obtain its predictive resource availability status in the next scheduling round. This can be achieved by using the resource prediction module within each network domain, combining historical data and current trends, to estimate and report future resource availability.

[0226] When obtaining the deviation pattern type corresponding to the understanding deviation pattern of each network domain constituting the candidate path for each candidate path, the understanding deviation pattern refers to the pattern in which each network domain has a persistent understanding deviation of the service level requirements described by the user's intent in multiple rounds of scheduling. These patterns can be "persistently low", "persistently high", "global coordination deviation", "local autonomy deviation", etc. Obtaining these deviation pattern types is to specifically correct historical deviations and optimize future scheduling effects during resource allocation. Before executing this step, the collaborative controller has already conducted continuous analysis of the inter-domain resource reservation behavior representation of each network domain through the aforementioned steps and determined the understanding deviation pattern of each network domain based on the correlation comparison results. Therefore, this step can directly extract the deviation pattern type corresponding to each network domain from the determined understanding deviation pattern records of each network domain stored internally by the collaborative controller. Alternatively, the collaborative controller can maintain a dynamically updated deviation pattern database, which records the historical deviation pattern types of each network domain under different service level indicators. When resource allocation is required, the coordination controller queries the database based on the user intent and service level requirements of the current business flow to obtain the latest deviation mode type corresponding to each network domain that constitutes the candidate path.

[0227] When determining the resource allocation tendency weight of each network domain on each candidate path based on the deviation pattern type, this resource allocation tendency weight is an indicator used to quantify the priority or importance of each network domain in the resource allocation decision. By mapping deviation pattern types to weights, the resource allocation process can proactively correct historical deviations. For example, for network domains with consistently low deviations, their resource allocation tendency weight should be higher to encourage the system to prioritize resource allocation for them, compensating for their historical resource shortages. Conversely, for network domains with consistently high deviations, their weight can be appropriately reduced to avoid unnecessary resource waste. The collaborative controller can pre-define a weight mapping table to map different deviation pattern types to specific numerical weights. For example, consistently low deviations correspond to weight value W1, and consistently high deviations correspond to weight value W2, where W1 > W2. For other deviation pattern types, corresponding weight values ​​can also be set according to their impact on resource allocation. Alternatively, the collaborative controller can employ an adaptive weight adjustment algorithm. For example, the initial weights can be set based on empirical values, and then the resource allocation tendency weights of each network domain can be dynamically adjusted according to the evolution of deviation patterns in subsequent scheduling rounds.

[0228] When calculating the comprehensive allocation fit of each candidate path, using the in-domain resource availability status and resource allocation tendency weights as inputs, this comprehensive allocation fit is a comprehensive indicator that measures whether a candidate path can effectively correct historical deviations in each network domain while meeting user intent and service level requirements. It combines the real-time resource availability of each network domain on the path with its priority in resource allocation. Calculating this fit aims to select the path that best balances the current resource status with the goal of correcting historical deviations from multiple candidate paths. This comprehensive allocation fit can be calculated using a weighted summation method. For example, for a candidate path, its comprehensive allocation fit can be expressed as the sum of the products of the in-domain resource availability status and the corresponding resource allocation tendency weights for each network domain on the path. Alternatively, the collaborative controller can use a multi-objective optimization algorithm to calculate the comprehensive allocation fit, using the in-domain resource availability status as one optimization objective and the resource allocation tendency weights as another optimization objective or constraint, and obtaining the comprehensive evaluation value of each candidate path through Pareto optimal solution sets or weighted summation methods.

[0229] When selecting the candidate path with the highest overall allocation adaptability as the bearer path for cross-domain service flows, and determining the resource reservation amount for each network domain based on the intra-domain resource availability status of each network domain on the bearer path, this bearer path is the actual network path selected to carry the cross-domain service flow, and the resource reservation amount is the amount of resources actually allocated by each network domain on this path for this service flow. This step is the implementation of resource allocation decisions, ensuring that service flows can receive reliable transmission guarantees in the network according to user intent and service level requirements. After calculating the overall allocation adaptability of all candidate paths, the coordinating controller directly compares these adaptability values ​​and selects the candidate path with the largest value as the bearer path. Once the bearer path is determined, the coordinating controller will calculate and determine the amount of resources that each network domain needs to reserve according to the intra-domain resource availability status of each network domain on the path, combined with the specific needs of the service flow, and according to the preset resource allocation strategy. Alternatively, after selecting the candidate path with the highest overall allocation adaptability, the coordinating controller can further execute a refined resource reservation negotiation process. For example, the coordination controller sends resource reservation requests to each network domain along the bearer path. Each network domain, based on its current resource availability and its own resource management policy, reports the actual amount of resources that can be reserved. The coordination controller integrates this feedback, along with the service level requirements of the business flow, to determine the resource reservation amount for each network domain and issues configuration instructions.

[0230] The above technical solution incorporates consideration of the understanding bias patterns of each network domain during cross-domain resource allocation, enabling dynamic adjustment of resource allocation strategies to address the issue of resource allocation failing to prioritize network domains with insufficient resource supply. For example, by acquiring the intra-domain resource availability status of each network domain in the next scheduling round, real-time foundational data is provided for resource allocation. Identifying the bias pattern type corresponding to each network domain's understanding bias patterns allows the collaborative controller to recognize the trend of each network domain's understanding bias towards user intent in historical scheduling. For instance, identifying a network domain with a consistently low bias indicates a long-term shortage of resources or a conservative understanding of demand. Identifying a network domain with a consistently high bias may indicate excessive resource reservation or an aggressive understanding of demand. Based on these bias pattern types, the collaborative controller can intelligently determine the resource allocation tendency weight for each network domain. For example, a higher resource allocation tendency weight can be assigned to network domains with consistently low bias to prioritize their resource needs and correct their resource supply shortage bias. Conversely, the weight of network domains with consistently high bias can be appropriately reduced to avoid resource waste. By using the availability status of resources within a domain and the weighted resource allocation tendency as joint inputs, the comprehensive allocation suitability of candidate paths is calculated. This ensures that the selected bearer path not only considers current resource availability but also incorporates a mechanism to correct historical deviations. The candidate path with the highest comprehensive allocation suitability is selected as the bearer path for cross-domain service flows, and the resource reservation amount is determined based on the availability status of resources within each network domain along this path. This achieves a cross-domain resource allocation method that can adaptively correct deviations and improve scheduling accuracy and efficiency, effectively avoiding the problems of scheduling results continuously deviating from user intent and repeated conflicts.

[0231] The following example will provide a more detailed explanation of the above technical solution: Suppose user A needs to deploy a cross-domain service flow that requires a strict Service Level Agreement (SLA), specifically an end-to-end latency of less than 30 milliseconds and a bandwidth requirement of at least 200 Mbps. This service flow needs to span network domains A, B, and C.

[0232] In the initial scheduling round, the software-defined network's coordinating controller receives a scheduling request from user A. The coordinating controller parses the user's intent, using the latency constraint (less than 30 milliseconds) and bandwidth requirement (not less than 200 Mbps) as scheduling targets. The coordinating controller then issues instructions to network domains A, B, and C, requesting them to reserve resources according to the parsed intent.

[0233] After the current scheduling round ends, the coordination controller collects the actual resource reservation information for each network domain. For example, the actual reserved resources in network domain A do not fully meet the 200Mbps bandwidth requirement, but are close to meeting the latency requirement. The actual reserved resources in network domain B exceed the user's intended bandwidth requirement in both latency and bandwidth, indicating a certain degree of resource redundancy. The actual reserved resources in network domain C meet the bandwidth requirement, but the latency is slightly higher than 30 milliseconds.

[0234] The coordinating controller compares the actual reserved resource amounts with the latency constraints and bandwidth requirements described by the user's intent to obtain a representation of the inter-domain resource reservation behavior of each network domain. For example, the coordinating controller calculates the forward resource mapping matching degree for each network domain. For instance, for network domain A, because its bandwidth guarantee resource amount is lower than its bandwidth requirement, even if its latency guarantee resource amount is higher, its forward resource mapping matching degree will be suppressed due to coupling processing. For network domain B, because both its latency guarantee resource amount and bandwidth guarantee resource amount are higher than the user's intent, its forward resource mapping matching degree is higher. The coordinating controller also compares the available intra-domain resources reported by each network domain with the actual reserved resource amount to obtain the reverse resource sufficiency of each network domain. For example, after comparing the available intra-domain bandwidth resources of network domain A with the actual occupied bandwidth resources, it may show that its reverse resource sufficiency is low, indicating that it is under resource constraints in terms of bandwidth. Network domain B may have a higher reverse resource sufficiency, indicating that it has abundant resources. The collaborative controller combines the positive resource mapping matching degree and the negative resource sufficiency degree, and integrates the degree of difference in the positive resource mapping matching degree between each network domain (e.g., calculating the standard deviation as a cross-domain matching difference component) to obtain the inter-domain resource reservation behavior representation of each network domain.

[0235] In multiple scheduling rounds, user A may continue to initiate similar service requests, or the service flow may continue to run. The coordination controller continuously collects and analyzes numerical sequences representing the inter-domain resource reservation behavior of each network domain. By analyzing these numerical sequences, the coordination controller extracts their trend characteristics over time, including persistent directional characteristics (e.g., network domain A's bandwidth reservation is consistently low), oscillatory characteristics (e.g., network domain C's latency reservation exhibits periodic fluctuations), and bursty characteristics. Based on these trend characteristics, the coordination controller identifies persistent characteristics of the inter-domain resource reservation behavior. For example, network domain A exhibits a persistent "consistently low" characteristic in terms of bandwidth, while network domain B exhibits a persistent "consistently high" characteristic in terms of both latency and bandwidth.

[0236] The collaborative controller correlates these persistent characteristics with the service level requirements (i.e., latency constraints and bandwidth requirements) described by the user's intent. For example, the "persistently low" bandwidth characteristic of network domain A has a direct negative correlation with the user's intent of "at least 200 Mbps" bandwidth requirement, indicating that network domain A is unlikely to meet this bandwidth requirement in terms of actual resource supply. The "persistently high" characteristic of network domain B indicates that its understanding of "less than 30 milliseconds" latency and "at least 200 Mbps" bandwidth may be overly conservative, leading to over-reservation. Based on this correlation comparison result, the collaborative controller determines the understanding bias pattern of each network domain regarding the service level requirements described by the user's intent. For example, for network domain A, its understanding bias pattern is determined to be "persistently low bandwidth." For network domain B, its understanding bias pattern is determined to be "persistently high latency / bandwidth." This mechanism differs from related technologies that only use deviation information to evaluate execution effectiveness; it can proactively identify and quantify the network domain's understanding bias regarding the user's intent.

[0237] After identifying the comprehension bias pattern, the collaborative controller uses this bias pattern and the user's intent as joint inputs to perform a reverse calibration operation on the intent parsing benchmark. Specifically, based on the "consistently low bandwidth" bias pattern, the collaborative controller determines that its associated specific service level indicator is bandwidth, with the bias direction being negative. For the "consistently high latency / bandwidth" bias pattern, its associated specific service level indicators are latency and bandwidth, with the bias direction being positive. The collaborative controller extracts the original semantic constraint values ​​from the user's intent (e.g., bandwidth 200 Mbps, latency 30 milliseconds).

[0238] Based on the deviation direction and the original semantic constraint values, the cooperative controller determines the adjustment direction and magnitude of the semantic mapping thresholds corresponding to these specific service level indicators in the intent resolution baseline. For example, for a bandwidth "consistently low" deviation in network domain A, the cooperative controller determines the adjustment direction of the bandwidth semantic mapping threshold to be amplified (e.g., adjusting the threshold from 200Mbps to 220Mbps) to encourage network domain A to reserve more bandwidth in subsequent scheduling. For a latency "consistently high" deviation in network domain B, the cooperative controller determines the adjustment direction of the latency semantic mapping threshold to be reduced (e.g., adjusting the threshold from 30ms to 28ms) to encourage network domain B to reserve latency resources more accurately in subsequent scheduling. The adjustment magnitude is determined based on the persistence intensity of the deviation and the original semantic constraint values; the greater the persistence intensity of the deviation, the greater the adjustment magnitude. To ensure the effectiveness of the adjustment, the cooperative controller generates candidate adjustment values ​​and performs backtracking simulations using historical resource mapping records. If the candidate adjustment values ​​improve the representation of inter-domain resource reservation behavior in historical scheduling rounds, the adjusted semantic mapping thresholds are updated in the intent resolution baseline to obtain the calibrated intent resolution baseline. This reverse calibration operation is the core innovation of this solution. It breaks the continuous disconnect between the intent parsing benchmark and the actual resource supply capacity in related technologies, and realizes adaptive optimization of intent parsing.

[0239] In the next scheduling round, when user A submits a service flow request again, the coordination controller performs semantic parsing on the user intent to be processed based on the calibrated intent parsing benchmark. For example, for the description of "high bandwidth," the coordination controller will parse it into a higher bandwidth constraint value (e.g., 220Mbps) instead of the original 200Mbps, based on the calibrated benchmark. For the description of "low latency," the coordination controller will parse it into a stricter latency constraint value (e.g., 28 milliseconds). These parsing results are used to generate structured service level constraint parameters.

[0240] The coordination controller uses these calibrated service level constraints as scheduling constraints to filter cross-domain candidate paths for cross-domain service flows. The coordination controller obtains all reachable paths in the cross-domain topology view and performs a compliance comparison on the end-to-end latency measurement and end-to-end available bandwidth measurement for each path. For example, it compares whether the upper limit of the path's latency confidence interval is lower than the calibrated latency constraint parameter, and whether the lower limit of the bandwidth confidence interval is higher than the calibrated bandwidth constraint parameter. A set of candidate paths that meet all constraints is then selected.

[0241] Within the candidate path set, the collaborative controller performs cross-domain resource allocation based on the intra-domain resource availability status of each network domain in the next scheduling round. During this process, the collaborative controller also considers the deviation mode type corresponding to each network domain in the understanding deviation mode, and determines the resource allocation tendency weight for each network domain accordingly. For example, the resource allocation tendency weight for a network domain labeled "consistently low" (such as the bandwidth of network domain A) will be higher than that for a network domain labeled "consistently high" (such as the latency / bandwidth of network domain B). This means that during allocation, more bandwidth will be prioritized for network domain A, while the latency / bandwidth allocation for network domain B will be more finely controlled. The collaborative controller calculates the comprehensive allocation suitability of each candidate path and selects the path with the highest suitability as the service flow carrying path, while simultaneously determining the resource reservation amount for each network domain. In this way, this solution effectively avoids repeated similar conflicts caused by the disconnect between the intent resolution benchmark and the actual resource supply capacity in related technologies, achieving more accurate and efficient dynamic scheduling of cross-domain resources.

[0242] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0243] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0244] The above are merely optional embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A resource dynamic scheduling method based on software-defined networking, characterized in that, The method, executed by the cooperative controller of the software-defined network, includes: In response to the scheduling request of cross-domain service flow, the latency constraints and bandwidth requirements described by the user intent corresponding to the cross-domain service flow, as well as the amount of resources actually reserved by each network domain in the current scheduling round to meet the user intent, are compared and processed to obtain the inter-domain resource reservation behavior representation of each network domain. The persistent characteristics of the inter-domain resource reservation behavior in multi-round scheduling are correlated with the user intent to determine the comprehension bias patterns of each network domain in relation to the service level requirements described by the user intent. Using the understanding bias pattern and the user intent as joint inputs, a reverse calibration operation is performed on the intent parsing benchmark to obtain a calibrated intent parsing benchmark, which adjusts the semantic mapping threshold in the intent parsing benchmark corresponding to the service level requirement towards the actual resource supply capacity of each network domain. The user intents to be processed in the next scheduling round are semantically parsed based on the calibrated intent parsing benchmark, and the parsing results are used to drive the cross-domain path selection and cross-domain resource allocation of the cross-domain business flow.

2. The method according to claim 1, characterized in that, The comparison of the latency constraints and bandwidth requirements described by the user intent corresponding to the cross-domain service flow, and the amount of resources actually reserved by each network domain in the current scheduling round to satisfy the user intent, yields a representation of the inter-domain resource reservation behavior of each network domain, including: The actual amount of resources reserved by each network domain to meet the user's intent is compared with the latency constraints and bandwidth requirements described by the user's intent to obtain the positive resource mapping matching degree of each network domain. The available resources reported by each network domain in the current scheduling round are compared with the actual reserved resources of each network domain to obtain the reverse resource sufficiency of each network domain. The forward resource mapping matching degree and reverse resource sufficiency of each network domain are combined and processed, and the difference in the forward resource mapping matching degree between each network domain is integrated to obtain the inter-domain resource reservation behavior representation of each network domain.

3. The method according to claim 2, characterized in that, The second comparison, which involves comparing the available resources reported by each network domain in the current scheduling round with the actual reserved resources of each network domain to obtain the reverse resource sufficiency of each network domain, includes: Extract the available latency resources and available bandwidth resources within the domain from the available resources reported by each network domain in the current scheduling round. Extract the actual amount of latency resources and bandwidth resources actually used from the actual amount of resources reserved in each network domain. The available latency resources within the domain are compared with the actual amount of latency resources occupied to obtain the latency dimension sufficiency sub-quantity. The available bandwidth resources within the domain are compared with the actual bandwidth resources occupied to obtain the bandwidth sufficiency sub-quantity. The latency dimension sufficiency and the bandwidth dimension sufficiency are comprehensively processed to obtain the reverse resource sufficiency of each network domain. The comprehensive processing adopts the method of determining the reverse resource sufficiency according to the shortest board principle.

4. The method according to claim 1, characterized in that, The correlation analysis between the persistent characteristics of the inter-domain resource reservation behavior representation in multi-round scheduling and the user intent determines the comprehension bias patterns of each network domain regarding the service level requirements described by the user intent, including: The numerical sequence of the inter-domain resource reservation behavior is analyzed in multiple consecutive scheduling rounds, and the trend characteristics of the numerical sequence over time are extracted. Based on the trend characteristics, the persistence characteristics of the inter-domain resource reservation behavior representation are identified from the numerical sequence; The persistent features are compared and correlated with the service level requirements described by the user intent to determine whether there is a corresponding change relationship between the persistent features and specific service level indicators in the service level requirements. Based on the results of the correlation comparison, the misunderstanding patterns of each network domain regarding the service level requirements described by the user's intent are determined.

5. The method according to claim 4, characterized in that, The step of identifying persistent characteristics of the inter-domain resource reservation behavior representation from the numerical sequence based on the trend characteristics includes: Based on the persistence direction feature in the trend features, the numerical sequence is initially oriented to obtain the candidate persistence type of the numerical sequence; Based on the oscillatory features in the trend characteristics, the confidence level of the candidate persistence type is verified. When the oscillatory features exceed a preset oscillation threshold, a decay correction is applied to the confidence level of the candidate persistence type. Based on the suddenness feature in the trend features, it is determined whether there are sudden jump points in the numerical sequence that deviate from the historical distribution range. When there are sudden jump points, the scheduling round in which the sudden jump point is located is marked as a deviation sample. The candidate persistence type, after confidence verification, is combined with the labeling results of the deviation samples to obtain the persistence feature representing the inter-domain resource reservation behavior. When the number of deviation samples exceeds a preset threshold, the persistence feature is determined to be a sudden deviation type; when the number of deviation samples does not exceed the preset threshold, the candidate persistence type after confidence verification is used as the persistence feature.

6. The method according to claim 1, characterized in that, The step of performing a reverse calibration operation on the intent parsing benchmark, using the comprehension bias pattern and the user intent as joint inputs, to obtain a calibrated intent parsing benchmark, includes: Based on the understanding bias pattern, determine the specific service level indicator associated with the understanding bias pattern, and the direction of the deviation of the understanding bias pattern from the specific service level indicator; Extract the original semantic constraint values ​​of the user intent in relation to the specific service level indicator from the user intent; Based on the deviation direction and the original semantic constraint value, determine the adjustment direction and adjustment magnitude of the semantic mapping threshold corresponding to the specific service level indicator in the intent parsing benchmark; The semantic mapping threshold corresponding to the specific service level indicator in the intent parsing benchmark is adjusted according to the adjustment direction and the adjustment magnitude. The adjusted semantic mapping threshold is updated in the intent parsing benchmark to obtain the calibrated intent parsing benchmark.

7. The method according to claim 6, characterized in that, The step of determining, based on the understanding bias pattern, the specific service level indicator associated with the understanding bias pattern, and the direction of deviation of the understanding bias pattern from the specific service level indicator, includes: The comprehension deviation pattern is deconstructed to extract deviation feature descriptions from the comprehension deviation pattern. The deviation feature descriptions include the pattern type identifier of the comprehension deviation pattern and the indicator pointing information corresponding to the comprehension deviation pattern in the service level requirements described by the user intent. Based on the indicator information, the specific service level indicator associated with the comprehension bias pattern is determined from among the multiple service level indicators included in the service level requirements. Based on the mode type identifier, the deviation direction of the understanding deviation mode on the specific service level indicator is determined, wherein the mode type identifier of the continuously high type corresponds to the positive deviation direction, and the mode type identifier of the continuously low type corresponds to the negative deviation direction.

8. The method according to claim 1, characterized in that, The step of semantically parsing the user intents to be processed in the next scheduling round based on the calibrated intent parsing benchmark, and using the parsing results to drive the cross-domain path selection and cross-domain resource allocation of the cross-domain service flow, includes: Semantic recognition is performed on the user intent to be processed in the next scheduling round, and the service level requirement description contained in the user intent is extracted. The service level requirement description is matched with the calibrated intent parsing benchmark to determine the semantic mapping threshold corresponding to the service level requirement description in the intent parsing benchmark; Based on the semantic mapping threshold, structured service level constraint parameters are generated, and the service level constraint parameters are used as the parsing result of the semantic parsing. Using the service level constraint parameters as scheduling constraints, cross-domain candidate paths are filtered for the cross-domain business flow to obtain a set of candidate paths that satisfy the service level constraint parameters; In the candidate path set, based on the intra-domain resource availability status of each network domain in the next scheduling round, cross-domain resource allocation is performed to determine the carrying path of the cross-domain service flow and the resource reservation amount of each network domain.

9. The method according to claim 8, characterized in that, The step of matching the service level requirement description with the calibrated intent parsing benchmark to determine the semantic mapping threshold corresponding to the service level requirement description in the intent parsing benchmark includes: The service level requirement description is segmented into words, and service level indicator words and constraint degree modifier words are extracted from the segmentation results. The service level indicator words are compared with each service level indicator contained in the calibrated intent parsing benchmark to determine the target service level indicator in the intent parsing benchmark that corresponds to the service level indicator words. Based on the constraint degree modifier, determine the value tendency of the semantic mapping threshold corresponding to the target service level indicator; In the intent parsing benchmark, the semantic mapping threshold corresponding to the target service level index under the value tendency is obtained.

10. The method according to claim 8, characterized in that, The process of using the service level constraint parameters as scheduling constraints to filter cross-domain candidate paths for the cross-domain service flow, thereby obtaining a set of candidate paths that satisfy the service level constraint parameters, includes: Obtain the cross-domain topology view of the cross-domain business flow within the jurisdiction of the collaborative controller, and extract all reachable cross-domain paths from the cross-domain topology view; For each cross-domain path, obtain the end-to-end latency measurement and the end-to-end available bandwidth measurement of the cross-domain path; The end-to-end latency measurement value is compared with the latency constraint parameter in the service level constraint parameters for a first compliance check, and the end-to-end available bandwidth measurement value is compared with the bandwidth constraint parameter in the service level constraint parameters for a second compliance check. Cross-domain paths that simultaneously meet both the first compliance comparison and the second compliance comparison are selected to form the candidate path set; When the candidate path set is empty, the latency constraint parameter and bandwidth constraint parameter in the service level constraint parameters are relaxed respectively. The first compliance comparison and the second compliance comparison are re-executed with the relaxed constraint parameters until a non-empty candidate path set is obtained.

Images