Cross-border traffic pool dynamic elastic scheduling system and method

Abstract

The present application belongs to the field of safety protection, and particularly relates to a cross-border traffic pool dynamic elastic scheduling system and method, comprising: collecting real-time quality and traffic parameters of multiple operator links, combining historical data and implicit intention of business appeal text to generate a scheduling detection sequence, generating state data through fusion calculation and sending to a cross-border traffic pool dynamic scheduling platform; using a traffic pool dynamic scheduling model to decouple the time sequence delay coupling relationship between parameters, predicting the traffic consumption fluctuation caused by cross-domain route convergence, extracting a feature vector containing traffic excess risk probability and link quality fluctuation, generating a target scheduling instruction in response to cross-domain linkage scheduling conditions, and adjusting the traffic distribution ratio or switching the path. The present application realizes elastic resource allocation and excess risk early warning, and improves the utilization rate of cross-border traffic resources.

Description

Technical Field

[0001] This invention belongs to the field of security protection, and in particular relates to a dynamic elastic scheduling system and method for cross-border traffic pools. Background Technology

[0002] In cross-border traffic scheduling scenarios, enterprises often face complex management needs due to the coexistence of traffic resources from multiple operators, including China Mobile, China Telecom, China Unicom, and overseas operators. Enterprise IT managers' scheduling objectives are often presented as vague business demands, such as "smoother international access" or "avoid exceeding the budget at the end of the month." These demands are difficult to quantify into precise QoS parameters or bandwidth thresholds. Simultaneously, cross-border network environments exhibit typical multi-parameter dynamic coupling characteristics: traffic resources from different operators are mutually constrained; for example, when one operator's link becomes congested, automatic switching to a backup link is necessary; traffic consumption and cost expenditure are linked in real time, such as a sudden surge in business causing one operator's traffic pool to run out; and scheduling strategies must simultaneously meet multiple constraints such as bandwidth resource limits, SLA guarantees, and compliant routing.

[0003] Current mainstream traffic scheduling systems mostly rely on static threshold rules or historical traffic templates. For example, they may have a hard-coded rule that "traffic will be switched when a certain operator's traffic utilization reaches 90%", or allocate bandwidth resources based on historical data from the same period. However, in actual cross-border business, implicit demands are difficult to cover by preset rules: for example, the deep-seated need for "cost control" may implicitly include an expectation of automatic loss mitigation without manual intervention. Furthermore, the temporal delay coupling between parameters—for instance, after adjusting the traffic ratio of operator A, the network quality of operator B may fluctuate only after a five-minute delay due to cross-domain routing convergence—means that static rules cannot capture the causal chain. In addition, dynamic conflicts between demand and resources frequently occur: a sudden failure of an international leased line may cause traffic to be instantly transferred to other operators, potentially triggering an excess threshold. Preset rules, unable to predict such sudden traffic surges, either over-reserve resources, resulting in waste, or incur high cross-border traffic excess fees due to delayed response. Therefore, existing technologies struggle to achieve a dynamic optimal solution within the closed loop of real-time fluctuation identification, flexible resource allocation, and implicit cost control. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention proposes a dynamic elastic scheduling system and method for cross-border traffic pools. The system includes: collecting real-time quality parameters and traffic consumption parameters from multiple operator link nodes to form first-state time-series data; generating a scheduling probe sequence based on historical traffic data and implicit scheduling intentions in service request texts; fusing the discrete probe values ​​with the first-state time-series data to obtain second-state time-series data, which is then sent to a cross-border traffic pool dynamic scheduling platform; on the platform side, using a reference demodulation sequence synchronized with the probe sequence, decoupling the temporal delay coupling relationship between parameters through a preset traffic pool dynamic scheduling model, predicting traffic consumption fluctuations caused by cross-domain routing convergence, and outputting reconstructed time-series data; extracting a running feature vector containing the probability of traffic overload risk and the comprehensive fluctuation value of link quality; and generating a target scheduling instruction when cross-domain linkage scheduling conditions are met to adjust the traffic allocation ratio, switching delay time, or switching path of each operator. This invention achieves elastic resource allocation and overload risk early warning, effectively improving the utilization rate of cross-border traffic resources.

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

[0006] A cross-border traffic pool dynamic elastic scheduling system includes:

[0007] The acquisition module is used to acquire the first state time series data generated by M operator link nodes. The first state time series data includes the real-time quality parameters and traffic consumption parameters of each link.

[0008] The detection modulation module generates a scheduling detection sequence based on historical traffic data and the implicit scheduling intent of the service request text, and performs a fusion calculation on the discrete detection values ​​in the scheduling detection sequence and the corresponding timestamp data values ​​in the first state time series data to generate the second state time series data.

[0009] The communication transmission module sends the second state timing data to the cross-border traffic pool dynamic scheduling platform via the communication link;

[0010] The inversion analysis module obtains a reference demodulation sequence synchronized with the scheduling probe sequence on the cross-border traffic pool dynamic scheduling platform. It inputs the reference demodulation sequence and the second state time series data into a preset traffic pool dynamic scheduling model and outputs reconstructed time series data. The traffic pool dynamic scheduling model is used to decouple the time delay coupling relationship between parameters and predict the traffic consumption fluctuation caused by cross-domain routing convergence.

[0011] The feature extraction module extracts the running feature vector from the reconstructed time series data. The running feature vector includes the probability of traffic overload risk and the comprehensive fluctuation value of link quality.

[0012] The scheduling decision module, in response to the running feature vector satisfying the preset cross-domain linkage scheduling conditions, generates a target scheduling instruction and routes the target scheduling instruction to the traffic execution node. The target scheduling instruction includes adjusting the traffic allocation ratio of each operator, switching delay time, or switching path.

[0013] Specifically, a scheduling probe sequence is generated, including:

[0014] Obtain historical traffic data from the first state time series data, wherein the historical traffic data includes a traffic consumption rate sequence and a link quality sequence of each operator's link in the past preset time period;

[0015] Obtain the business request text, which contains business scheduling objectives expressed in an unstructured form;

[0016] Semantic parsing is performed on the business request text to extract link quality constraint values ​​and cost constraint values ​​from the implicit information in the business request text. The link quality constraint values ​​are converted into target latency threshold, target packet loss rate threshold and target bandwidth utilization threshold through semantic mapping. The cost constraint values ​​are converted into target remaining traffic threshold and target consumption rate threshold through semantic mapping.

[0017] Based on the target latency threshold, target packet loss rate threshold, and target bandwidth utilization threshold, historical time periods that meet the corresponding threshold conditions are retrieved from the link quality sequence, and the link quality values ​​of the corresponding time periods are extracted as quality benchmarks.

[0018] Based on the target remaining flow threshold and the target consumption rate threshold, a flow consumption trend line is calculated from the flow consumption rate sequence, and the remaining flow depletion time threshold and instantaneous consumption rate upper limit are determined as cost warning lines.

[0019] The quality benchmark and the cost warning line are used as modulation coefficients, and a weighted fusion operation is performed with the traffic consumption rate value and link quality value corresponding to the timestamp in the historical traffic data to generate a scheduling probe sequence. The scheduling probe sequence consists of discrete probe values, each probe value corresponds to a future time point and includes the expected traffic allocation ratio and expected quality requirements at that time point.

[0020] Specifically, the second-state time-series data is generated, including:

[0021] Obtain the expected traffic allocation weight set and expected quality threshold set corresponding to each future time point in the scheduling probe sequence. The expected traffic allocation weight set includes the traffic allocation weight of each operator at the corresponding future time point, and the expected quality threshold set includes the target latency threshold, target packet loss rate threshold, and target bandwidth utilization threshold of each operator at the corresponding future time point.

[0022] Obtain the real-time quality parameter set and real-time consumption parameter set corresponding to each collection time point in the first state time series data. The real-time quality parameter set includes the real-time latency value, real-time packet loss rate value and real-time bandwidth utilization value of each operator at the current collection time point. The real-time consumption parameter set includes the real-time remaining traffic value and real-time consumption rate value of each operator at the current collection time point.

[0023] Using each collection time point as a benchmark, find the future time point in the scheduling detection sequence that is greater than or equal to the collection time point and has the smallest time difference. Determine the expected traffic allocation weight set of the future time point as the associated weight set of the collection time point, and determine the expected quality threshold set of the future time point as the associated threshold set of the collection time point.

[0024] Specifically, generating the second-state time-series data also includes:

[0025] For each collection time point, the traffic allocation weights of each operator in the associated weight set are weighted and summed with the real-time consumption rate values ​​of the corresponding operator in the real-time consumption parameter set to obtain the traffic adjustment factor for the collection time point.

[0026] For each collection time point, the target latency threshold, target packet loss rate threshold, and target bandwidth utilization rate threshold of each operator in the associated threshold set are respectively compared with the real-time latency value, real-time packet loss rate value, and real-time bandwidth utilization rate value of the corresponding operator in the real-time quality parameter set to obtain the quality deviation factor of the collection time point.

[0027] The flow adjustment factor and the quality deviation factor are vector-concatenated with the real-time quality parameter set and the real-time consumption parameter set at the acquisition time point to generate the fusion feature vector at the acquisition time point.

[0028] The fused feature vectors from all collected time points are arranged in chronological order to form the second-state time series data.

[0029] Specifically, the second state timing data is sent to the cross-border traffic pool dynamic scheduling platform via a communication link, including:

[0030] Acquire the second state time series data, which consists of multiple fused feature vectors arranged in ascending order according to the acquisition time points;

[0031] Each fused feature vector is assigned a monotonically increasing sequence number, which corresponds one-to-one with the position of the fused feature vector in ascending order, and is used to identify its temporal relationship.

[0032] The second-state timing data carrying the sequence number is encrypted using a pre-shared encryption key to generate a ciphertext data packet;

[0033] The encrypted data packet is divided into several data fragments, and each data fragment is marked with its offset and total length in the original encrypted data packet. The fragments are then sent in parallel to the cross-border traffic pool dynamic scheduling platform through at least two cross-border communication links.

[0034] Specifically, sending the second state timing data to the cross-border traffic pool dynamic scheduling platform via a communication link also includes:

[0035] On the cross-border traffic pool dynamic scheduling platform side, each data fragment is received, and the received data fragments are checked for integrity and reassembled according to the offset and total length to restore the complete encrypted data packet;

[0036] The complete ciphertext data packet is decrypted using the decryption key corresponding to the encryption key to obtain second state timing data carrying a sequence number;

[0037] The decrypted fused feature vectors are sorted according to the sequence number to recover the second state time-series data, which is consistent with the data sent from the transmitting end and arranged in ascending order of the acquisition time point.

[0038] Specifically, the reconstructed time-series data is output, including:

[0039] Extract a copy of the scheduling probe sequence that is time-synchronized with the sender from the local cache, and use this copy as a reference demodulation sequence. The reference demodulation sequence contains a set of expected traffic allocation weights arranged in order of future time points, and each set of expected traffic allocation weights includes the traffic allocation weight of each operator at the corresponding future time point.

[0040] Obtain the decrypted and reordered second-state time-series data. The second-state time-series data contains fused feature vectors arranged in order of acquisition time points. Each fused feature vector contains at least the flow adjustment factor and quality deviation factor at the current acquisition time point.

[0041] Based on the time interval between adjacent future time points in the reference demodulation sequence, the standard delay duration for cross-domain routing convergence is determined. A delay convolution kernel is constructed based on the standard delay duration. The delay convolution kernel is a one-dimensional vector whose length is equal to the number of acquisition time points contained within the standard delay duration. The values ​​of each element in the vector are calculated based on the routing convergence attenuation model.

[0042] The delay convolution kernel is convolved with the expected traffic allocation weight set in the reference demodulation sequence to generate a temporal delay coupling matrix, which is used to characterize the weight distribution of the delay impact of historical scheduling actions on the network state at the current moment.

[0043] Specifically, the output of reconstructed time-series data also includes:

[0044] The time delay coupling matrix and the fused feature vector sequence within the corresponding time window in the second state time series data are input into the Wiener deconvolution filter. The Wiener deconvolution filter uses the time delay coupling matrix as the system transfer function to perform deconvolution operation on the fused feature vector sequence, stripping the time delay coupling component superimposed due to cross-domain routing convergence in the fused feature vector sequence, and outputting the decoupled pure feature vector sequence.

[0045] The pure feature vector sequence is input into a pre-trained long short-term memory network. Based on the mapping relationship between historical pure feature vectors and future traffic fluctuations, the long short-term memory network outputs the predicted traffic consumption rate sequence and the predicted link quality sequence of each operator's link within a preset future time period, which serve as the reconstructed time series data.

[0046] Specifically, extracting the runtime feature vector from the reconstructed time-series data includes:

[0047] The reconstructed time series data is obtained. The reconstructed time series data includes the predicted traffic consumption rate sequence and the predicted link quality sequence of M operator links within a future preset time period. The predicted link quality sequence includes the predicted latency value, the predicted packet loss rate value and the predicted bandwidth utilization value at each future time point.

[0048] Obtain the current remaining traffic value for each operator link. For each operator link, accumulate the predicted traffic consumption rate sequence in chronological order to obtain the cumulative predicted consumption of the operator link at each future time point.

[0049] For each future time point, calculate the ratio of the cumulative predicted consumption of each operator's link at that time point to its current remaining traffic value to obtain the consumption ratio matrix;

[0050] Input each element in the consumption ratio matrix into a preset S-shaped function to obtain the instantaneous excess probability matrix of each operator's link at each future time point.

[0051] Specifically, extracting the runtime feature vector from the reconstructed time-series data further includes:

[0052] The instantaneous excess probability matrix is ​​time-weighted and averaged according to the operator dimension to obtain the average excess probability of each operator link. Then, the average excess probabilities of all operator links are weighted and summed to obtain the traffic excess risk probability.

[0053] For each operator link, based on its predicted link quality sequence, the variances of the predicted latency, predicted packet loss rate, and predicted bandwidth utilization are calculated respectively, and the three variances are weighted and summed to obtain the link quality fluctuation value of the operator link.

[0054] The link quality fluctuation values ​​of all operator links are weighted and averaged to obtain the comprehensive link quality fluctuation value;

[0055] The probability of excessive traffic risk and the comprehensive fluctuation value of link quality are combined into an operational feature vector.

[0056] The dynamic and elastic scheduling method for cross-border traffic pools includes:

[0057] Acquire first state time-series data generated by multiple operator link nodes, the first state time-series data including real-time quality parameters and traffic consumption parameters of each link;

[0058] Based on the implicit scheduling intent of historical traffic data and business request text, a scheduling probe sequence is generated, and the discrete probe values ​​in the scheduling probe sequence are fused with the corresponding timestamp data values ​​in the first state time series data to generate the second state time series data.

[0059] The second state timing data is sent to the cross-border traffic pool dynamic scheduling platform via the communication link;

[0060] In the cross-border traffic pool dynamic scheduling platform, a reference demodulation sequence synchronized with the scheduling probe sequence is obtained. The reference demodulation sequence and the second state time series data are input into a preset traffic pool dynamic scheduling model, and the reconstructed time series data is output. The traffic pool dynamic scheduling model is used to decouple the time delay coupling relationship between parameters and predict the traffic consumption fluctuation caused by cross-domain routing convergence.

[0061] Extract the operational feature vector from the reconstructed time-series data. The operational feature vector includes the probability of traffic overload risk and the comprehensive fluctuation value of link quality.

[0062] In response to the running feature vector satisfying the preset cross-domain linkage scheduling conditions, a target scheduling instruction is generated and routed to the traffic execution node. The target scheduling instruction includes adjusting the traffic allocation ratio of each operator, switching delay time, or switching path.

[0063] Compared with the prior art, the beneficial effects of the present invention are:

[0064] This invention introduces a scheduling probe sequence based on implicit scheduling intent, quantifying ambiguous business demands into discrete probe values ​​that can participate in fusion calculations, effectively solving the problem that traditional static rules cannot cover implicit needs. By utilizing a dynamic scheduling model of the traffic pool to decouple the temporal delay coupling relationship between multiple parameters, it can accurately predict traffic consumption fluctuations and excess risks caused by cross-domain routing convergence, avoiding excess costs or resource waste caused by response delays. By extracting operational feature vectors containing the probability of traffic excess risk and link quality fluctuations in real time, and dynamically generating scheduling instructions containing allocation ratios, switching delay times, or switching paths, it achieves elastic resource allocation and accurate early warning under sudden failures or traffic surges, significantly improving the utilization rate and cost control capabilities of cross-border traffic resources. Attached Figure Description

[0065] Figure 1 This is a block diagram of the cross-border flow pool dynamic elastic scheduling system according to Embodiment 1 of the present invention;

[0066] Figure 2 This is a diagram of the dynamic elastic scheduling method for cross-border traffic pools in Embodiment 2 of the present invention. Detailed Implementation

[0067] Example 1

[0068] Please see Figure 1 One embodiment of the present invention provides a dynamic elastic scheduling system for cross-border traffic pools, comprising:

[0069] The acquisition module is used to acquire first-state time-series data generated by multiple operator link nodes. The first-state time-series data includes real-time quality parameters and traffic consumption parameters for each link. It should be further noted that the process of acquiring the first-state time-series data in this embodiment includes:

[0070] The CMP platform access layer connects to the already connected operator M2M platforms and the connected China Telecom and China Mobile operator platforms. These operator platforms include at least STC, MTS, VDF, AIS, China Unicom, China Telecom, China Mobile, and VIVOTelcel. For example, in this embodiment, STC, AIS, and China Unicom platforms are currently connected, and interface debugging is being performed on the connected China Telecom and China Mobile platforms to ensure that their link data can be obtained subsequently. The CMP platform access layer establishes long-lived connections with each operator's M2M platform via RESTful API, uses the OAuth2.0 protocol for authentication, and allocates an independent connection pool for each platform. The API address of the current STC platform is assumed to be https: / / api.stc.com / sandbox, and a heartbeat packet is sent every 10 seconds to maintain the connection. The AIS platform subscribes to link quality topics via the MQTT protocol, and the China Unicom platform directly connects to its Oracle database via JDBC to collect traffic pool table data.

[0071] Real-time latency, packet loss rate, and bandwidth utilization are collected in parallel from various operator platforms as real-time quality parameters. Remaining traffic and instantaneous consumption rate from each operator's traffic pool are collected as traffic consumption parameters. The following is a detailed and complete example illustrating the entire process. This example is only to demonstrate the feasibility of the calculation and does not represent actual values. Specific values ​​should be determined through simulation or physical experiments by those skilled in the art. For example, every 50 milliseconds, data is collected from the STC platform: latency 85ms, packet loss rate 0.1%, bandwidth utilization 60%, remaining traffic 500GB, and consumption rate 2MB / s. Simultaneously, data is collected from the AIS platform: latency 102ms, packet loss rate 0.3%, bandwidth utilization 45%, and remaining traffic... The data collection module processed 320GB of data at a rate of 1.5MB / s. The latency from the China Unicom platform was 210ms, the packet loss rate was 1.2%, the bandwidth utilization was 82%, and the remaining data was 120GB at a rate of 4MB / s. The module employed multi-threaded concurrent processing, with one independent collection thread for each platform. Each thread encapsulated the raw data collected into a unified JSON object based on the platform number. The STC data format was {"operator": "STC", "timestamp": ..., "latency": 85, "loss": 0.1, "bandwidth": 60, "remaining": 500, "rate": 2}.

[0072] The real-time quality parameters and traffic consumption parameters are timestamped according to the unified clock source of the CMP platform to generate raw acquisition data with time stamps. The following is a specific complete example illustrating the entire process. This example is only to illustrate the feasibility at the computational level and does not represent actual values. Specific values ​​can be determined through simulation experiments or physical experiments by those skilled in the art. For example, using the GPS timing clock inside the CMP platform as a reference, this clock source is synchronized through a BeiDou / GPS dual-mode timing server with an accuracy of ±1ms. After receiving the JSON objects returned by each thread, the acquisition module immediately reads the current GPS time as the data acquisition timestamp and adds it to the JSON object, generating the raw acquisition data of the STC platform as {"operator": "STC", "acquisition timestamp": "2024-05-20 10:30:25.123", "latency": 85,} The original data collected by the AIS platform is {"operator": "AIS", "collection timestamp": "2024-05-2010:30:25.125", "latency": 102, "loss": 0.3, "bandwidth": 45, "remaining": 320, "rate": 1.5}, and the original data collected by the China Unicom platform is {"operator": "China Unicom", "collection timestamp": "2024-05-2010:30:25.150", "latency": 210, "loss": 1.2, "bandwidth": 82, "remaining": 120, "rate": 4}.

[0073] The raw collected data is input into the connection monitoring module of the platform monitoring system. The connection monitoring module compares the timestamp deviation of each raw collected data with the master clock as the reference. For example, the master clock also uses GPS time synchronization, and the current master clock time is 10:30:25.120. The connection monitoring module maintains a sliding window with a length of 100, which stores the 100 most recent raw collected data. Each time a new data is received, the difference between its collection timestamp and the current time of the master clock is immediately calculated: STC data deviation is +3ms, AIS data deviation is +5ms, and Unicom data deviation is +30ms.

[0074] If the timestamp deviation is less than or equal to the preset synchronization threshold, the original collected data is retained and stored in the time series database. For example, the synchronization threshold is set to 10ms. This threshold is calculated based on the average network round-trip time (RTT) between each operator platform and the CMP platform (8ms) plus 3 times the standard deviation (2ms). The deviations of STC and AIS data are +3ms and +5ms, respectively, both less than or equal to 10ms. Therefore, these two data are marked as valid data and written to the time series database through the Kafka message queue. The time series database uses InfluxDB and stores data in shards by platform and date. STC data is stored in the "link_quality" measurement of the "stc_autogen" retention policy. The fields include latency, loss, bandwidth, remaining, rate, and timestamp accurate to milliseconds.

[0075] If the timestamp deviation is greater than the synchronization threshold, the original collected data is discarded and a re-collection command is triggered through the access layer. For example, if the deviation of the data from the China Unicom platform is +30ms, which is greater than the 10ms threshold, the data is determined to be invalid data and is discarded directly. At the same time, the connection monitoring module sends a re-collection command to the connection pool manager of the access layer. The command includes the platform identifier "China Unicom", the failure timestamp "10:30:25.150" and the retry count. The connection pool manager immediately starts a new collection based on the re-collection command. If m consecutive re-collections time out or the deviation exceeds the limit, the platform is marked as "collection abnormal" and an alarm is triggered. The specific value of m consecutive re-collections is set by those skilled in the art.

[0076] The system extracts retained data arranged in chronological order from the time-series database, generates first-state time-series data, and sends it to the AI ​​monitoring module of the capability layer. For example, the AI ​​monitoring module initiates a query to the time-series database every 500 milliseconds to obtain retained data from all platforms within the last minute, arranged in ascending order of timestamps. The query conditions are a time range from "now()-1m" to "now()", and the data is sorted by timestamp. The returned dataset includes STC platform timestamps at 10:30:25.123, 10:30:25.173, and 10:30:25. The data includes 60 records at time points .223, 60 records from the AIS platform at time points such as 10:30:25.125, 10:30:25.175, 10:30:25.225, etc., and data records from the China Unicom platform after successful re-collection. These data are encapsulated into a time-series array, with each element containing a platform identifier, timestamp, quality parameters, and traffic parameters. This first-state time-series data is sent to the AI ​​monitoring module via the gRPC protocol for subsequent traffic excess risk prediction and link quality fluctuation analysis.

[0077] It should be further noted that this embodiment also introduces a multi-protocol adaptive switching mechanism, dynamic redundancy backup of access status, and pre-access stress testing during the access process to improve access stability and compatibility, specifically including:

[0078] The CMP platform's access layer incorporates a protocol adaptation engine that monitors the load status and network link quality of various operator platform interfaces in real time. The protocol adaptation engine automatically adjusts the communication protocol according to a preset switching strategy. The following is a detailed example illustrating the entire process. This example is only for demonstrating computational feasibility and does not represent actual values. Specific values ​​can be determined through simulation or physical experiments by those skilled in the art. For instance, in this embodiment, when the number of concurrent requests to the STC platform's RESTful API interface exceeds 70% of its maximum capacity, the protocol adaptation engine automatically switches subsequent data collection tasks to the backup WebSocket protocol. It should be noted that this 70% is only an exemplary threshold; the specific value can be dynamically adjusted based on the stress test results of the actual deployment environment. For example, if the maximum capacity is 1000 requests / second, the threshold for triggering the switch is 700 requests / second. The WebSocket connection is pre-established via a long-connection handshake, and the switching process is completed within 20 milliseconds. This time is only an example value based on the current network environment and hardware configuration. In actual systems, it can be configured to any value within the range of 10 to 50 milliseconds depending on performance requirements, during which data collection is uninterrupted. Similarly, when the link quality topic subscribed to by the AIS platform via the MQTT protocol experiences a packet loss rate exceeding 0.5% for three consecutive samples due to network jitter, the protocol adaptation engine automatically enables the UDP protocol for data retransmission. The 0.5% packet loss rate threshold and the number of consecutive samples are exemplary parameters in this embodiment. Specifically, they can be configured to range from 0.1% to 1% depending on the link quality sensitivity requirements, and the number of samples can also be configured to 2 to 5. The UDP retransmission channel operates independently, retransmitting lost data packets to ensure that the integrity rate of the collected data is not less than 99.99%. This integrity rate target value is the performance indicator pursued in this embodiment. In actual applications, it can be set to 99.9%, 99.99%, or higher, depending on the business's requirements for data integrity. In summary, all the above values ​​are only used to explain the specific implementation of the present invention, and are not intended to limit the scope of protection. After reading this embodiment, those skilled in the art can adjust these values ​​according to the actual gateway performance, network environment and business requirements, and all of these are equivalent alternatives to the present invention.

[0079] Simultaneously, two independent backup connection pools are configured for each connected operator platform. The primary connection pool is responsible for normal data collection, while the backup connection pool is in a hot standby state. The two connection pools synchronize configuration parameters (such as authentication token, connection timeout, and heartbeat interval) in real time through shared memory. The backup connection pool checks the health status of the primary connection pool every 10 milliseconds. When the primary connection pool experiences a connection timeout (three consecutive no heartbeat responses), authentication failure (returning 401 / 403 status codes), or TCP connection reset, the access layer automatically switches the collection task to the backup connection pool within 50 milliseconds. For example, if the STC platform's primary connection pool fails to authenticate due to an expired OAuth2.0 access token, the access layer immediately redirects the collection traffic to the backup connection pool upon detecting the error. The backup connection pool uses a pre-refreshed refresh token to reacquire the access token within 10 milliseconds and resumes data collection. During this period, the data collection queue temporarily caches data. After the switch is completed, data is uploaded again in timestamp order to ensure no data loss.

[0080] In addition, a new access verification mechanism is added. For operator platforms (such as China Telecom and China Mobile) undergoing access, besides interface debugging, an additional simulated traffic stress test is performed. Specifically, before formal access, simulated traffic is sent to the operator platform interface using a testing tool at a rate of 10MB / s for 5 minutes, while simultaneously monitoring the interface response time, data transmission packet loss rate, and server error rate. The following is a detailed example illustrating the entire process. This example is only for demonstrating computational feasibility and does not represent actual values. Specific values ​​can be determined through simulation or physical experiments conducted by those skilled in the art. For instance, in this embodiment, a stress test is performed on the RESTful API of the China Telecom platform, requiring an average response time not exceeding 100 milliseconds, a 95th percentile response time not exceeding 150 milliseconds, a packet loss rate not exceeding 0.1%, and a server error rate not exceeding 0.01%. It should be noted that the above values ​​are merely exemplary indicators for this embodiment. Specific thresholds can be flexibly configured according to the sensitivity of the actual business to latency and reliability. For example, in scenarios with high real-time requirements, the average response time can be compressed to less than 50 milliseconds, while in test environments with lower reliability requirements, the packet loss rate can be appropriately relaxed to 0.5%. If the response time exceeds the threshold during testing, the simulated traffic rate is gradually reduced to 8 megabytes per second for retesting. This rate value is also an exemplary parameter; in actual applications, it can be adjusted to any value between 4 and 16 megabytes per second based on network bandwidth and server processing capacity. Interface bottlenecks are recorded, such as an insufficient database connection pool or excessive CPU utilization, and an interface adaptation report is generated. The report includes parameters such as maximum stable throughput, recommended concurrent connections, and caching strategy optimization suggestions, providing a basis for parameter optimization after subsequent formal access. All the above values ​​are only used to explain the specific implementation of the present invention and are not intended to limit the scope of protection. After reading this embodiment, those skilled in the art can adjust these values ​​according to actual gateway performance, network environment, and business needs; all such adjustments are equivalent alternatives to the present invention.

[0081] The detection modulation module generates a scheduling detection sequence based on historical traffic data and the implicit scheduling intent of the service request text, and performs a fusion calculation on the discrete detection values ​​in the scheduling detection sequence and the corresponding timestamp data values ​​in the first state time series data to generate the second state time series data.

[0082] The communication transmission module sends the second state timing data to the cross-border traffic pool dynamic scheduling platform via the communication link;

[0083] The inversion analysis module, within the cross-border traffic pool dynamic scheduling platform, acquires a reference demodulation sequence synchronized with the scheduling probe sequence. It then inputs the reference demodulation sequence and the second state time-series data into a preset traffic pool dynamic scheduling model, outputting reconstructed time-series data. This model decouples the temporal delay coupling between parameters and predicts traffic consumption fluctuations caused by cross-domain routing convergence. Next, a specific complete example illustrates the entire process. This example is only to illustrate the feasibility at the computational level and does not represent actual values. Specific values ​​can be determined through simulation or physical experiments conducted by those skilled in the art. For example, in this embodiment, the traffic pool dynamic scheduling model uses a gated recurrent unit network based on an attention mechanism as its core architecture. Its input layer receives the scheduling probe sequence and the second state time-series data, with an input dimension of 128 and a hidden layer dimension of 256. The output layer outputs reconstructed time-series data. The model is constructed as follows: First, 30 consecutive days of historical data from the cross-border traffic pool during actual operation are collected as training samples. Each sample contains a scheduling probe sequence and second-state time-series data as input features, and the actual traffic consumption fluctuation value at the corresponding time as a label. The training data is divided into training set, validation set, and test set in a 7:2:1 ratio. The training set is used for model parameter updates, the validation set is used for hyperparameter tuning, and the test set is used for final performance evaluation. The model training uses mean squared error as the loss function and introduces time-aware weighted mean squared error to enhance the fitting ability to recent data. The weighting coefficient is set to exponential decay of 0.9. The optimizer uses the adaptive moment estimation algorithm, with an initial learning rate of 0.001, a batch size of 64, and a maximum training epoch of 200 epochs. An early stopping strategy is adopted, terminating training when the validation set loss no longer decreases for 10 consecutive epochs. To enhance the model's generalization ability, random noise and time-series masks are applied to the input data as data augmentation during training. The amplitude of the random noise is set to 5% of the input standard deviation, and the discard ratio of the time-series mask is set to 10%. After training, the mean absolute percentage error on the test set reached within 3.2%, indicating that the model can effectively decouple the temporal delay coupling between parameters and accurately predict traffic consumption fluctuations caused by cross-domain routing convergence. It should be noted that all the above numerical parameters, including input dimension 128, hidden layer dimension 256, training days 30 days, data partition ratio 7:2:1, weighting coefficient 0.9, initial learning rate 0.001, batch size 64, maximum training epochs 200, early stopping epochs 10, noise amplitude 5%, mask drop rate 10%, and mean absolute percentage error on the test set 3.2%, are exemplary configurations of this embodiment. In practical applications, those skilled in the art can make corresponding adjustments according to the specific data scale, network topology complexity, and performance requirements; all of these are equivalent implementations of the present invention.

[0084] The feature extraction module extracts the running feature vector from the reconstructed time series data. The running feature vector includes the probability of traffic overload risk and the comprehensive fluctuation value of link quality.

[0085] The scheduling decision module, in response to the running feature vector satisfying the preset cross-domain linkage scheduling conditions, generates a target scheduling instruction and routes the target scheduling instruction to the traffic execution node. The target scheduling instruction includes adjusting the traffic allocation ratio of each operator, switching delay time, or switching path to achieve elastic allocation and over-limit early warning.

[0086] It should be further explained that the scheduling probe sequence generated in this embodiment includes:

[0087] A101. Obtain historical traffic data from the first state time-series data. The historical traffic data includes a traffic consumption rate sequence and a link quality sequence for each operator's link within a preset time period. The link quality sequence includes at least latency, packet loss rate, and bandwidth utilization. Next, a specific complete example illustrates the entire process. This example is only to illustrate the feasibility at the computational level and does not represent actual values. Specific values ​​can be determined through simulation or physical experiments conducted by those skilled in the art. For example, in this embodiment, traffic consumption rate and link quality data for three links (STC, AIS, and Unicom) over the past 24 hours are extracted from the time-series database. Specifically, one sampling point is collected every 5 minutes for the STC link, resulting in 288 sampling points. Its traffic consumption rate fluctuates between 1.5 Mbps and 3.2 Mbps, latency is between 75 ms and 120 ms, packet loss rate is between 0.05% and 0.5%, and bandwidth utilization is between 40% and 85%. For the AIS link, the traffic consumption rate ranges from 1.2 Mbps to 2.8 Mbps within the same time period, the latency ranges from 90 ms to 150 ms, and the packet loss rate ranges from 0.1% to 0.8%. For the Unicom link, the traffic consumption rate ranges from 3.0 Mbps to 5.5 Mbps within the same time period, the latency ranges from 180 ms to 250 ms, and the packet loss rate ranges from 0.8% to 2.0%. It should be noted that all the above numerical parameters, including the sampling interval of 5 minutes, the number of sampling points of 288, the traffic rate range, latency range, packet loss rate range, and bandwidth utilization range for each link, are exemplary configurations of this embodiment. In actual applications, adjustments can be made according to specific monitoring needs, link performance characteristics, and business sensitivity. For example, the sampling interval can be set from 1 minute to 30 minutes, and the sampling duration can be extended to 48 hours or 7 days, all of which are equivalent implementations of this invention.

[0088] A102. Obtain the business request text, which contains business scheduling objectives expressed in unstructured natural language; for example, the obtained business request text is "Make international access smoother, and don't exceed the budget at the end of the month";

[0089] A103. Input the business request text into a preset semantic parsing model. The semantic parsing model outputs at least one semantic label and its corresponding confidence level contained in the business request text. The semantic label includes a quality label and a cost label. The quality label includes "smooth", "stable", and "high priority". The cost label includes "saving", "cost control", and "prevent overspending". For example, if "Make international access smoother and don't exceed the budget at the end of the month" is input into a BERT-based semantic parsing model, the model outputs three semantic labels and their confidence levels: "smooth" label confidence level 0.92, "stable" label confidence level 0.45, and "cost control" label confidence level 0.88. Among them, "smooth" and "stable" are quality labels, and "cost control" is a cost label.

[0090] A104. Based on the semantic tags and their confidence levels, the corresponding quantization mapping function is called from a preset mapping rule base. The mapping rule base stores the dynamic mapping relationship between semantic tags and link quality constraint values ​​and cost constraint values. Next, a specific complete example will be used to illustrate the entire process. The example is only to illustrate the feasibility at the computational level and does not represent the actual values. The specific values ​​can be determined by those skilled in the art through simulation experiments or physical experiments. For example, in this embodiment, the dynamic mapping relationship is dynamically updated based on the average actual parameters when the business demand is achieved in historical time periods. The construction process of the preset mapping rule base includes: First, for each business demand tag, the actual network parameters and traffic parameters under the historical successful achievement scenarios corresponding to the tag are collected. For example, for the "smooth" tag, the system automatically extracts all time periods rated as "smooth" by users in the past week every Monday morning, obtains the actual latency values ​​and packet loss rates in these time periods, and forms a training sample set. Then, a linear regression method was used to fit the functional relationship between latency and confidence. Specifically, using the subjective confidence of users during evaluation as the independent variable and the actual latency value as the dependent variable, the target latency threshold function was fitted as f_smoothness (confidence) equal to 80 milliseconds plus 20 milliseconds multiplied by 1 in parentheses minus the confidence level, where 80 milliseconds is the baseline latency when the confidence level is 100%, and 20 milliseconds is the latency adjustment range. Similarly, regression calculation was performed on the packet loss rate, and the target packet loss rate threshold function was obtained as g_smoothness (confidence) equal to 0.2% plus 0.3% multiplied by 1 in parentheses minus the confidence level, where 0.2% is the baseline packet loss rate, and 0.3% is the adjustment range. For the "cost control" tag, the system extracts the remaining traffic and consumption rate corresponding to the periods in the past week when no overspending occurred. Using confidence level as the independent variable, it fits the target remaining traffic threshold function h_cost control (confidence level) as 50 gigabytes plus 30 gigabytes multiplied by 1 in parentheses minus the confidence level, and the target consumption rate threshold function k_cost control (confidence level) as 2.5 megabytes per second plus 1.5 megabytes per second multiplied by 1 in parentheses minus the confidence level. All the above function parameters, including the baseline values ​​of 80 milliseconds, 20 milliseconds, 0.2%, 0.3%, 50 gigabytes, 30 gigabytes, 2.5 megabytes per second, and 1.5 megabytes per second, are regression calculation results based on one week of historical data in this embodiment. In practical applications, they can be recalculated based on historical data of longer periods or finer granularity. The update cycle can also be configured to be daily, weekly, or monthly, all of which are equivalent implementations of this invention. The mapping rule base constructed in the above manner can dynamically and adaptively adjust according to user evaluation and business feedback, making the network scheduling strategy more in line with actual needs.

[0091] It should be further noted that this embodiment also introduces a dynamic adaptation factor for business scenarios and a real-time network environment feedback correction mechanism into the quantization mapping function of A104 to improve mapping accuracy and adaptability to the actual environment. Specifically, this includes:

[0092] For example, in this embodiment, the semantic parsing model, while outputting semantic tags, identifies the current business scenario type through context analysis or user-preset identifiers. The user-preset identifiers are configured as follows: the system provides a scenario configuration interface where users can manually specify scenario types for different business applications or time periods. For example, users can mark remote collaboration applications running during office hours as "international office" scenarios, e-commerce platform order processing interfaces as "cross-border e-commerce" scenarios, and video conferencing software as "video conferencing" scenarios. After the user completes the preset, the system binds these identifiers with the corresponding business traffic characteristics and stores them in the scenario configuration library. When the semantic parsing model receives a business request text, it simultaneously queries whether the source application or time interval of the current business traffic matches any user-preset identifier. If a match is found, the scenario type is directly determined; otherwise, it is automatically inferred through context analysis. Each scenario corresponds to a set of scenario weight coefficients. For example, when the business request text "Smoother international access, don't exceed the budget at the end of the month" is simultaneously identified by the semantic parsing model as the scenario tag "International Office," the scenario weight coefficients are tilted towards lower latency. The baseline offset of the latency threshold function is adjusted to f_smoothness (confidence) equal to 70 milliseconds plus 20 milliseconds multiplied by 1 minus the confidence level. If the scenario tag is "Cross-border E-commerce," then bandwidth stability is emphasized more, and the latency threshold function is adjusted to f_smoothness (confidence) equal to 85 milliseconds plus 15 milliseconds multiplied by 1 minus the confidence level. The scenario weight coefficients are dynamically adjusted weekly based on user feedback regarding business satisfaction. For example, if user satisfaction with latency in the "International Office" scenario was below 85% in the past week, the baseline of 70 milliseconds in f_smoothness (confidence) is lowered to 65 milliseconds. It should be noted that all numerical parameters in this step, including 70 milliseconds, 20 milliseconds, 85 milliseconds, 15 milliseconds, the 85% satisfaction threshold, and 65 milliseconds, are exemplary configurations for this embodiment. In practical applications, users can set the baseline value and adjust the step size according to their own business sensitivity. The update cycle of the user-preset identifier can also be configured to be daily or monthly, all of which are equivalent implementations of this invention. Through the above-mentioned user-preset identifier mechanism, the system can accurately identify the business scenario type and adaptively adjust the weight allocation of the scheduling strategy accordingly.

[0093] For example, in this embodiment, the link quality parameters of each operator acquired in real time by the acquisition module are simultaneously input into the quantization mapping function to dynamically correct the output constraint values. Specifically, the correction logic is based on the degree of deviation between the current quality and the historical average: if the current average latency of a certain operator's link is more than 20% higher than the historical average for the same period, the target latency threshold for that operator is increased by 10%; if the current average packet loss rate is more than 40% lower than the historical average, the target packet loss rate threshold is decreased by 15%. The historical average for the same period is taken as the average value of data within a 5-minute window at the same time over the past 30 days. The 20%, 10%, 40%, 15%, and 30 days mentioned above are exemplary thresholds and window parameters in this embodiment. In practical applications, they can be configured according to link stability and service sensitivity. For example, the latency deviation threshold can be set between 15% and 25%, and the historical statistical window can be set between 7 and 60 days. As a specific example, the average latency of the STC link from 10:30 to 10:35 over the past 30 days was 80 milliseconds, and the average latency of the five minutes before the current moment was 95 milliseconds, which is 18.75% higher. Although this does not reach the hard threshold of 20%, the system uses linear interpolation to calculate the actual improvement percentage. The improvement percentage is taken as the minimum value. That is, first calculate 18.75% divided by 20% and then multiplied by 10% to get 9.375%, and then compare it with 10% and take the smaller one, 9.375%. Therefore, the target latency threshold of STC is adjusted from 82 milliseconds to 82 milliseconds multiplied by 1 in parentheses plus 9.375%, which equals 89.7 milliseconds, rounded to 90 milliseconds. For example, if the historical average packet loss rate of the AIS link is 0.25% and the current average packet loss rate is 0.15%, which is 40% lower than the historical average, exactly equal to the 40% threshold, the system calculates the reduction ratio using linear interpolation. First, it calculates the historical average minus the current packet loss rate divided by the historical average (0.10% divided by 0.25%), which equals 40%. Then, it multiplies this by 15% to get 6%. Therefore, the AIS target packet loss rate threshold is adjusted from 0.30% to 0.30% multiplied by 1 minus 6%, which equals 0.282%. It should be noted that the above linear interpolation method, rounding rules, and all numerical parameters are exemplary configurations for this embodiment. In practical applications, piecewise linear, exponential smoothing, or other correction functions can be used, all of which are equivalent implementations of this invention.

[0094] Furthermore, the update mechanism of the mapping rule base has been optimized to a dual-cycle update plus an event-triggered update: the dual-cycle update refers to a full statistical update performed every Monday morning, while incremental fine-tuning is performed every day at midnight based on the previous day's data; the event-triggered update means that when the achievement rate of any business request (i.e., the proportion of users who report "satisfied" through a satisfaction survey after scheduling) is below 80% for three consecutive days, the rule base update is triggered immediately. For example, if the target remaining traffic threshold function corresponding to the "cost control" label in the past week led to an increased risk of overspending in actual scheduling, and user satisfaction was only 75%, the system would trigger an update at midnight the next day, recalculate the remaining traffic values ​​corresponding to the periods in the past 30 days where no overspending occurred, calculate the new average value, and derive the target remaining traffic threshold function as h_cost control (confidence) = 55GB + 25GB × (1 - confidence); the updated mapping function takes effect immediately, and the update log is recorded for subsequent effect evaluation.

[0095] A105. Input the semantic label into the quantization mapping function. The quantization mapping function performs weighted statistics on the historical target-reaching periods of the corresponding semantic label in the historical traffic data according to the confidence level, and outputs link quality constraint values ​​and cost constraint values. The link quality constraint values ​​include target latency threshold, target packet loss rate threshold, and target bandwidth utilization threshold. The cost constraint values ​​include target remaining traffic threshold and target consumption rate threshold. Next, a specific complete example is used to illustrate the entire process. The example is only to illustrate the feasibility at the computational level and does not represent the actual values. The specific values ​​can be determined by those skilled in the art through simulation experiments or physical experiments. For example, substituting the "smooth" label and its confidence level of 0.92 into the mapping function, the target latency threshold is calculated as 80ms + 20ms. (1-0.92)=80ms+1.6ms=81.6ms, rounded to 82ms; target packet loss rate threshold=0.2%+0.3% (1-0.92)=0.2%+0.024%=0.224%; Meanwhile, historical data shows that the average bandwidth utilization during the historically successful periods (i.e., periods when users reported smooth performance) corresponding to the "Smooth" label was approximately 65%, so the target bandwidth utilization threshold was set at 65%; substituting the "Cost Control" label and its confidence level of 0.88 into the mapping function, the target remaining traffic threshold was calculated to be 50GB+30GB. (1-0.88)=50GB+3.6GB=53.6GB; Target consumption rate threshold=2.5MB / s+1.5MB / s (1-0.88)=2.5MB / s+0.18MB / s=2.68MB / s; For example, in this embodiment, the weight of the weighted statistics is set as the product of an exponentially decaying weight based on confidence and a freshness weight based on time. Specifically, for each historical qualifying period corresponding to a semantic tag in the historical traffic data, the freshness weight is first calculated based on the time interval between the period and the current time. The freshness weight uses an exponential decay function, with a decay half-life of 7 days, meaning the weight decays to half its original value every 7 days. Secondly, the confidence weight is calculated based on the confidence level corresponding to the historical qualifying period. The confidence weight is directly taken as the confidence level value of the period, with the confidence level ranging from 0 to 1. The final comprehensive weight is the product of the freshness weight and the confidence weight. The system uses this comprehensive weight to perform a weighted average of the link quality parameters and cost parameters within the historical qualifying period, outputting the link quality constraint value and cost constraint value. For example, assuming the current time is Monday, and a historical compliance period occurred 3 days ago, its freshness weight is 2^-3 divided by 7, which is approximately 0.74. The confidence level for this period is 0.8, so the overall weight is 0.74 multiplied by 0.8, which equals 0.592. After calculating the overall weight for all historical compliance periods, the system weights and sums the link quality parameters (latency, packet loss rate, bandwidth utilization, etc.) and cost parameters (traffic consumption, unit cost, etc.) for each period, and divides the sum by the overall weights to obtain the link quality constraint value and cost constraint value. It should be noted that the 7-day attenuation half-life, direct confidence level, and multiplicative overall weight are exemplary configurations in this embodiment. In practical applications, the attenuation half-life can be set to anywhere from 3 to 30 days, and the weight combination method can also use an additive model or an adaptive learning model, all of which are equivalent implementations of this invention.

[0096] A106. Based on the target latency threshold, target packet loss rate threshold, and target bandwidth utilization threshold, retrieve historical time periods that meet the corresponding threshold conditions from the link quality sequence, and extract the link quality values ​​of the corresponding time periods as quality benchmarks; for example, using the target latency threshold ≤ 82ms, target packet loss rate threshold ≤ 0.224%, and target bandwidth utilization threshold ≤ 65% as conditions, search the STC link data of the past 24 hours and find that a total of 6 time periods meet the conditions, located at 2:00-2:30 AM, 3:15-3:45 AM, etc., and extract these... The average latency of 78ms, average packet loss rate of 0.18%, and average bandwidth utilization of 58% for the STC link during these time periods were used as the quality benchmark for the STC link. Similarly, for the AIS link, no time period was found to fully meet the conditions, so the closest time period data was taken, with an average latency of 95ms, a packet loss rate of 0.30%, and a bandwidth utilization of 62%, as the quality benchmark for the AIS link. For the Unicom link, no time period was found to fully meet the conditions, so an average latency of 185ms, a packet loss rate of 0.9%, and a bandwidth utilization of 70% were taken as the quality benchmark for the Unicom link.

[0097] A107. Based on the target remaining traffic threshold and the target consumption rate threshold, calculate the traffic consumption trend line from the traffic consumption rate sequence, and determine the remaining traffic exhaustion time threshold and the instantaneous consumption rate upper limit as cost warning lines; for example, considering the remaining traffic in each operator's traffic pool at the current moment, STC has 500GB of remaining traffic, AIS has 320GB, and China Unicom has 120GB; combined with the target consumption rate threshold of 2.68MB / s, calculate the remaining time for each link at the current consumption rate: STC's current consumption rate of 2.0MB / s is lower than the threshold. At the current rate, it can be maintained for approximately 69.4 hours. If consumed at the threshold rate, the remaining time is approximately 51.8 hours. The remaining traffic exhaustion time threshold is set to the time calculated at the threshold rate, i.e., STC is 51.8 hours. The remaining 320GB of AIS is calculated to be approximately 33.1 hours at the threshold of 2.68MB / s, and the remaining 120GB of China Unicom is calculated to be approximately 12.4 hours at the threshold of 2.68MB / s. At the same time, the instantaneous consumption rate limit is set to the target consumption rate threshold of 2.68MB / s, i.e., any link's instantaneous consumption rate exceeding 2.68MB / s will trigger an alert.

[0098] A108. Using the quality benchmark and the cost warning line as modulation coefficients, a weighted fusion operation is performed with the traffic consumption rate value and link quality value corresponding to the timestamp in the historical traffic data to generate a scheduling probe sequence. The scheduling probe sequence consists of discrete probe values, each probe value corresponding to a future time point and containing the expected traffic allocation ratio and expected quality requirements at that time point. For example, in this embodiment, the weighted fusion operation specifically involves: using the quality benchmark and the cost warning line as modulation coefficients, and performing a weighted fusion operation with the traffic consumption rate value and link quality value corresponding to the timestamp in the historical traffic data. This operation first obtains the traffic consumption rate sequence and link quality value sequence within the same time period corresponding to the current timestamp in the historical traffic data. Then, the ratio of the quality benchmark to the link quality value is calculated as the first modulation factor, and the ratio of the cost warning line to the traffic consumption rate value is calculated as the second modulation factor. Next, the link quality value at each timestamp is assigned the weight corresponding to the first modulation factor, and the traffic consumption rate value at each timestamp is assigned the weight corresponding to the second modulation factor. The two are then normalized and weighted summed separately. Finally, the weighted sum of the link quality fusion value and the traffic consumption fusion value are superimposed according to a preset fusion ratio to obtain the final fusion result. Among them, the higher the value of the quality benchmark and cost warning line, the greater the weight of the corresponding link, so that the fusion result is biased towards the historical data of links with better quality or lower cost.

[0099] For example, at 5-minute intervals, probe values ​​are generated for 12 time points in the next hour. Each probe value includes the expected traffic allocation ratio (e.g., calculated by weighted fusion based on quality benchmarks and cost warning lines, resulting in STC: 45%, AIS: 35%, and Unicom: 20%) and expected quality requirements (e.g., STC link latency ≤ 82ms, packet loss rate ≤ 0.224%, and bandwidth utilization ≤ 65%). In specific calculations, the STC latency of 78ms and packet loss rate of 0.18% in the quality benchmarks and the threshold of 2.68MB / s in the cost warning lines are used as inputs, combined with historical traffic data from the same period. The consumption rate is weighted to obtain the allocation ratio for each future time point. For example, the detection value for the first time point 10:35:00 is {"Time": "10:35:00", "Allocation Ratio": {"STC": 0.45, "AIS": 0.35, "China Unicom": 0.20}, "Quality Requirements": {"STC": {"Latency ≤ 82ms", "Packet Loss Rate ≤ 0.224%"}, "AIS": {"Latency ≤ 95ms", "Packet Loss Rate ≤ 0.30%"}, "China Unicom": {"Latency ≤ 185ms", "Packet Loss Rate ≤ 0.9%"}}. It should be noted that the data in this step are exemplary configurations for this embodiment. In actual applications, the time granularity, prediction window length, and various parameters can be adjusted according to business needs and network environment, all of which are equivalent implementations of this invention.

[0100] This embodiment extracts semantic tags and confidence levels from unstructured business request text using a semantic parsing model. Based on a dynamically updated mapping rule base of historical target achievement periods, it calls a quantification mapping function to accurately transform vague implicit intentions such as "smoothness" and "cost control" into quantifiable link quality and cost constraints such as target latency thresholds, target packet loss rate thresholds, and target remaining traffic thresholds. This solves the technical problem that traditional static rules cannot cover implicit demands. By retrieving time periods that meet the conditions from the historical link quality sequence according to the target thresholds, a quality benchmark is extracted. Combined with the target consumption rate threshold, the remaining traffic exhaustion time threshold and the instantaneous consumption rate upper limit are calculated as cost warning lines, achieving a fusion representation of historical optimal state and future cost risks. Finally, the quality benchmark and cost warning lines are used as modulation coefficients to perform weighted fusion operations with historical traffic data to generate a scheduling probe sequence containing the expected traffic allocation ratio and expected quality requirements at future time points. This transforms vague business objectives into discrete probe signals that can participate in subsequent fusion calculations and time series inversion, providing accurate forward-looking guidance for the generation of second-state time series data. This significantly improves the matching degree of scheduling strategies with the true business intentions and the ability to predict cost risks.

[0101] It should be further explained that the second state timing data generated in this embodiment includes:

[0102] B101. Obtain the expected traffic allocation weight set and expected quality threshold set corresponding to each future time point in the scheduling probe sequence. The expected traffic allocation weight set includes the traffic allocation weight of each operator at the corresponding future time point, and the expected quality threshold set includes the target latency threshold, target packet loss rate threshold, and target bandwidth utilization threshold of each operator at the corresponding future time point. Next, a specific complete example will be used to illustrate the entire process. The example is only to illustrate the feasibility at the computational level and does not represent the actual values. The specific values ​​can be determined by simulation experiments or physical experiments conducted by those skilled in the art. For example, in this embodiment, the traffic allocation weight is obtained in the following way: the quality benchmark and cost warning line of each future time point are input into the weighted fusion model. The weighted fusion model uses the traffic consumption rate and link quality data of each operator in the same historical period as training samples. By minimizing the weighted cost function and satisfying the link quality constraints, the traffic allocation weight of each operator is obtained. Specifically, the weighted fusion model first calculates the comprehensive score of each link. The comprehensive score equals the quality baseline score multiplied by the quality weight coefficient plus the cost warning line score multiplied by the cost weight coefficient. The quality baseline score is obtained by weighting the degree to which latency, packet loss rate, and bandwidth utilization meet the expected quality threshold, while the cost warning line score is determined by the degree of deviation of traffic consumption rate from the cost ceiling. Then, linear programming or a soft maximization function is used to convert the comprehensive score of each link into traffic allocation weights, so that links with higher comprehensive scores receive higher allocation weights, and the sum of the weights of all links is 1. For example, in this embodiment, the expected traffic allocation weight set corresponding to the future time point 10:35:00 is obtained from the scheduling probe sequence as STC link 0.45, AIS link 0.35, and Unicom link 0.20. This allocation result is obtained by inputting the latency baseline of 78 milliseconds and the packet loss rate baseline of 0.18% for the STC link and the cost warning line of 2.68 megabytes per second into the weighted fusion model, and then performing weighted fusion calculations based on the traffic consumption rate of each link during the same historical period. Similarly, the expected traffic allocation weight set corresponding to the future time point 10:40:00 is 0.40 for STC links, 0.40 for AIS links, and 0.20 for Unicom links. This result reflects that the quality benchmark of AIS links has improved or the cost warning line has been relatively relaxed during this period, resulting in an increase in the weight of AIS links. The expected quality threshold set is either derived by inversely from the allocation weight of each link or directly from the weighted fusion result of the quality benchmark and the cost warning line. For example, the target latency threshold for STC links at 10:35:00 is 82 milliseconds, the target packet loss rate threshold is 0.224%, and the target bandwidth utilization threshold is 65%. The corresponding thresholds for AIS links are 95 milliseconds, 0.30%, and 62%, and the corresponding thresholds for Unicom links are 185 milliseconds, 0.9%, and 70%. The data for subsequent future time points follow the same pattern.It should be noted that the quality weight coefficient, cost weight coefficient, linear programming parameters, and all specific values ​​mentioned above are exemplary configurations of this embodiment. In actual applications, the weight allocation of quality and cost can be dynamically adjusted according to business preferences, and all of these are equivalent implementations of the present invention.

[0103] B102. Obtain the real-time quality parameter set and real-time consumption parameter set corresponding to each collection time point in the first state time series data. The real-time quality parameter set includes the real-time latency value, real-time packet loss rate value, and real-time bandwidth utilization value of each operator at the current collection time point. The real-time consumption parameter set includes the real-time remaining traffic value and real-time consumption rate value of each operator at the current collection time point. For example, in this embodiment, the real-time data corresponding to the collection time point 10:30:25.173 is extracted from the first state time series data, where the real-time latency value of STC is 86ms, and the real-time... The packet loss rate was 0.12%, the real-time bandwidth utilization was 61%, the real-time remaining traffic was 498GB, and the real-time consumption rate was 2.1MB / s; the real-time latency of AIS was 103ms, the real-time packet loss rate was 0.31%, the real-time bandwidth utilization was 46%, the real-time remaining traffic was 319GB, and the real-time consumption rate was 1.6MB / s; the real-time latency of China Unicom was 212ms, the real-time packet loss rate was 1.3%, the real-time bandwidth utilization was 83%, the real-time remaining traffic was 119GB, and the real-time consumption rate was 4.2MB / s.

[0104] B103. Using each collection time point as a reference, find the future time point in the scheduling probe sequence that is greater than or equal to the collection time point and has the smallest time difference. Determine the expected traffic allocation weight set of the future time point as the associated weight set of the collection time point, and determine the expected quality threshold set of the future time point as the associated threshold set of the collection time point. For example, in this embodiment, for the collection time point 10:30:25.173, its time value is 10:30:25.173, and the future time point in the scheduling probe sequence that is greater than or equal to this time and has the smallest time difference is... At 10:35:00, the associated weight set for this collection time point is determined as the expected traffic allocation weight set for 10:35:00, namely STC: 0.45, AIS: 0.35, and Unicom: 0.20. The associated threshold set is determined as the expected quality threshold set for 10:35:00, namely STC target latency 82ms, target packet loss rate 0.224%, and target bandwidth utilization 65%; AIS target latency 95ms, target packet loss rate 0.30%, and target bandwidth utilization 62%; and Unicom target latency 185ms, target packet loss rate 0.9%, and target bandwidth utilization 70%.

[0105] B104. For each data collection time point, the traffic allocation weights of each operator in the associated weight set are weighted and summed with the real-time consumption rate values ​​of the corresponding operators in the real-time consumption parameter set to obtain the traffic adjustment factor for the data collection time point. Next, a specific complete example is used to illustrate the entire process. The example is only to illustrate the feasibility of the calculation and does not represent the actual values. The specific values ​​can be determined by those skilled in the art through simulation experiments or physical experiments. For example, for the data collection time point 10:30:25.173, the STC weight in the associated weight set is 0.45, the AIS weight is 0.35, and the Unicom weight is 0.20. The real-time consumption rates are STC 2.1MB / s, AIS 1.6MB / s, and Unicom 4.2MB / s, respectively. Then the traffic adjustment factor = 0.45×2.1+0.35×1.6+0.20×4.2=0.945+0.56+0.84=2.345MB / s.

[0106] B105. For each data collection time point, the target latency threshold, target packet loss rate threshold, and target bandwidth utilization rate threshold of each operator in the associated threshold set are respectively compared with the real-time latency value, real-time packet loss rate value, and real-time bandwidth utilization rate value of the corresponding operator in the real-time quality parameter set to calculate the deviation, thus obtaining the quality deviation factor for the data collection time point. For example, for the data collection time point 10:30:25.173, the STC target latency in the associated threshold set is 82ms, the target packet loss rate is 0.224%, and the target bandwidth utilization rate is 65%, while the real-time latency is 86ms, the real-time packet loss rate is 0.12%, and the real-time bandwidth utilization rate is 61%. Then, the STC latency deviation = 86 - 82 = 4ms, the packet loss rate deviation = 0.12 - 0.224 = -0.104 percentage points (i.e., better than the target), and the bandwidth utilization rate deviation = 61 - 6 5 = -4 percentage points; Similarly, calculate the AIS latency deviation = 103 - 95 = 8ms, packet loss rate deviation = 0.31 - 0.30 = 0.01 percentage points, bandwidth utilization deviation = 46 - 62 = -16 percentage points; the Unicom latency deviation = 212 - 185 = 27ms, packet loss rate deviation = 1.3 - 0.9 = 0.4 percentage points, bandwidth utilization deviation = 83 - 70 = 13 percentage points; combine these deviation values ​​into a vector as the quality deviation factor, specifically in the form of [STC latency deviation, STC packet loss rate deviation, STC bandwidth deviation, AIS latency deviation, AIS packet loss rate deviation, AIS bandwidth deviation, Unicom latency deviation, Unicom packet loss rate deviation, Unicom bandwidth deviation], i.e. [4, -0.104, -4, 8, 0.01, -16, 27, 0.4, 13].

[0107] It should be further noted that this embodiment also introduces deviation level weighting, abnormal deviation suppression, and deviation trend terms in the calculation of the quality deviation factor of B105, in order to improve the accuracy and robustness of the quality deviation factor in representing the actual network state. Specifically, this includes:

[0108] First, the deviation values ​​of each quality indicator for each operator are classified into levels. The absolute value of the deviation is determined by its ratio to the corresponding target threshold. Let the target threshold for a certain operator be T, and the real-time value be R. Then the absolute value of the deviation |Δ| = |RT|. The level classification rules are as follows: if |Δ| ≤ 0.1 × T, it is a slight deviation; if 0.1 × T < |Δ| ≤ 0.3 × T, it is a moderate deviation; if |Δ| > 0.3 × T, it is a severe deviation. Different levels correspond to different weighting coefficients: slight deviation has a weight of 1.0, moderate deviation has a weight of 1.5, and severe deviation has a weight of 2.0. These weighting coefficients are derived from statistical analysis of historical scheduling data and reflect the intensity of the impact of different deviation levels on subsequent scheduling decisions. Next, a specific complete example will be used to illustrate the entire process. This example is only to illustrate the feasibility at the computational level and does not represent actual values. The specific values ​​can be determined by those skilled in the art through simulation experiments or physical experiments. For example, the target threshold for STC latency T_STC_latency = 82ms, the real-time latency R_STC_latency = 86ms, the absolute value of the deviation |Δ| = 4ms, 0.1×T = 8.2ms, 4ms ≤ 8.2ms, which is a slight deviation, and the weighted deviation value is still 4ms; the target threshold for Unicom latency T_UNICOM_latency = 185ms, the real-time latency R_UNICOM_latency y=212ms, absolute deviation |Δ|=27ms, 0.1×T=18.5ms, 0.3×T=55.5ms, 18.5ms<27ms≤55.5ms, which is considered a moderate deviation. The weighted deviation value is 27×1.5=40.5ms. If the absolute deviation value of a certain indicator exceeds 0.3×T, for example, the target threshold for China Unicom packet loss rate T_UNICOM_loss=0.9%, the real-time packet loss rate R_UNICOM_loss=2.5%, the absolute deviation value |Δ|=1.6%, 0.3×T=0.27%, 1.6%>0.27%, which is considered a severe deviation. The weighted deviation value is 1.6×2.0=3.2 percentage points.

[0109] Meanwhile, a new abnormal deviation suppression logic has been added to remove extreme deviation values ​​caused by instantaneous network jitter or acquisition anomalies. The anomaly judgment criteria are as follows: if the absolute value of the deviation at a certain acquisition time point exceeds 50% of the corresponding target threshold, i.e., |Δ|>0.5×T, and the deviation value deviates from the average deviation of the five acquisition time points before and after it (excluding the current point) by more than three times the standard deviation, then it is judged as an abnormal deviation. For deviation values ​​judged as abnormal, the average deviation value of the five time points before and after the acquisition time point (a total of 10 points) is used for replacement. Next, a specific and complete calculation example will be used to illustrate the entire process. This example is only to illustrate the feasibility of the calculation and does not represent the actual values. The specific values ​​can be determined by those skilled in the art through simulation experiments or physical experiments. For example, the real-time packet loss rate of the Unicom link at the time point of 10:30:25.173 is 2.5%, the target threshold T_UNICOM_loss=0.9%, and the absolute value of the deviation |Δ|=1.6%>0.5×0.9%=0.45%, which satisfies the first criterion; at the same time, the packet loss rate of the five time points before and after this time point (10:30:25.173) is calculated. The packet loss rate deviation sequence from 0:25.123 to 10:30:25.163 and from 10:30:25.223 to 10:30:25.273 is [0.3%, 0.31%, 0.29%, 0.32%, 0.3%, 0.31%, 0.3%, 0.29%, 0.33%, 0.3%], with a mean of 0.305% and a standard deviation of 0.014%. The current deviation of 1.6% deviates from the mean by approximately 92.5 times the standard deviation (1.6% - 0.305%) / 0.014%, far exceeding 3 times the standard deviation, and is therefore judged as an abnormal deviation. The mean deviation of these 10 points, 0.305%, is taken as the replacement value and used in subsequent weighted calculations.

[0110] In addition, a deviation trend term is added to the quality deviation factor vector to characterize the direction of deviation value change over time. For each quality indicator, the difference between the deviation value at the current acquisition time point and the deviation value at the previous acquisition time point is calculated as the trend term. A positive trend term indicates a positive increase in deviation (further deterioration of quality), a negative trend term indicates a positive decrease in deviation (improvement of quality), and zero indicates no change. For example, if the current STC latency deviation is 4ms (weighted), and the STC latency deviation at the previous time point 10:30:25.123 was 3ms (weighted), then the trend term is +1ms; if the current AIS packet loss rate deviation is 0.015 percentage points (weighted), and the previous time point was 0.02 percentage points, then the trend term is -0.005 percentage points. All trend terms are concatenated in the order of operator and quality indicator to form a trend term vector, which is then concatenated with the original quality deviation factor vector to obtain the expanded quality deviation factor vector. For example, the original quality deviation factor vector is [4, -0.104, -4, 8, 0.01, -16, 27, 0.4, 13], and the corresponding trend term vector is [+1, -0.02, 0, -0.5, +0.005, +1, +2, +0.1, -1]. After expansion, the vector length is 18 dimensions, which provides richer temporal dynamic information for subsequent feature vector fusion.

[0111] B106. The flow adjustment factor and the quality deviation factor are concatenated with the real-time quality parameter set and real-time consumption parameter set at the acquisition time point to generate a fused feature vector for the acquisition time point. Next, a specific complete example illustrates the entire process. This example is only to illustrate the feasibility at the computational level and does not represent actual values. Specific values ​​can be determined through simulation experiments or physical experiments conducted by those skilled in the art. For example, for the acquisition time point 10:30:25.173, its real-time quality parameter set and real-time consumption parameter set can be represented as the vector [STC delay 86, STC loss]. Packet rate 0.12, STC bandwidth 61, STC remaining 498, STC rate 2.1, AIS latency 103, AIS packet loss rate 0.31, AIS bandwidth 46, AIS remaining 319, AIS rate 1.6, Unicom latency 212, Unicom packet loss rate 1.3, Unicom bandwidth 83, Unicom remaining 119, Unicom rate 4.2], concatenate the traffic adjustment factor 2.345 and the quality deviation factor [4, -0.104, -4, 8, 0.01, -16, 27, 0.4, 13] into this vector to form a fused feature vector with a dimension of 15+1+9=25.

[0112] B107. Arrange the fused feature vectors of all acquisition time points in chronological order to form the second-state time series data; for example, arrange the fused feature vectors generated at each acquisition time point such as 10:30:25.123, 10:30:25.173, 10:30:25.223 in ascending order of timestamp to form the second-state time series data. This data contains both the real-time state information at each moment and the traction information of the expected future goal, which is used for subsequent time series causal inversion analysis.

[0113] This embodiment solves the problem of misalignment between expected targets and real-time states in the time dimension by aligning and associating the expected traffic allocation weight set and expected quality threshold set at each future time point in the scheduling probe sequence with the real-time quality parameter set and real-time consumption parameter set at each collection time point in the first state time series data. By calculating the traffic adjustment factor and quality deviation factor at each collection time point, the influence of the expected future allocation target on the current traffic consumption and the gap between the current link quality and the expected future quality requirements are quantified, realizing the numerical coupling between fuzzy expected targets and precise real-time data. Finally, a fused feature vector containing real-time state information, traffic adjustment factor, and quality deviation factor is generated by vector concatenation and arranged in chronological order to form the second state time series data. This data not only retains the real network state at the original collection time but also embeds the guiding information of the expected future targets. It provides an aligned input basis that simultaneously contains "current facts" and "future expectations" for subsequent time series delay coupling decoupling and traffic fluctuation prediction, significantly improving the accuracy of the inversion analytical model's understanding of scheduling intentions and its predictive foresight.

[0114] It should be further explained that in this embodiment, the second state timing data is sent to the cross-border traffic pool dynamic scheduling platform via a communication link, including:

[0115] C101. Obtain the second state time series data. The second state time series data is composed of multiple fused feature vectors arranged in ascending order according to the acquisition time points. For example, in this embodiment, the second state time series data received from the previous module includes fused feature vectors of 60 consecutive acquisition time points, where the first three time points are 10:30:25.123, 10:30:25.173, and 10:30:25.223 respectively. Each fused feature vector is a 25-dimensional numerical array. For example, the vector corresponding to 10:30:25.123 is [86, 0.12, 61, 498, 2.1, 103, 0.31, 46, 319, 1.6, 212, 1.3, 83, 119, 4.2, 2.345, 4, -0.104, -4, 8, 0.01, -16, 27, 0.4, 13].

[0116] C102. Assign a monotonically increasing sequence number to each fused feature vector. The sequence number corresponds one-to-one with the position of the fused feature vector in ascending order, and is used to identify its temporal relationship. For example, in this embodiment, sequence number 1 is assigned to the fused feature vector with timestamp 10:30:25.123, sequence number 2 is assigned to the vector with timestamp 10:30:25.173, sequence number 3 is assigned to the vector with timestamp 10:30:25.223, and so on, until the vector with timestamp 60 is assigned to the last time point.

[0117] C103. Encrypt the second-state timing data carrying the sequence number using the pre-shared encryption key to generate a ciphertext data packet. For example, this embodiment uses the AES-256-GCM encryption algorithm. The pre-shared key is a 32-byte hexadecimal string 4e6f77206973207468652074696d6520666f7220616c6c20676f6f64206d656e. After serializing all data containing the sequence number and fused feature vector into binary format, the key is used to encrypt the data, and an authentication tag is attached. The total length of the ciphertext data packet is 48KB.

[0118] C104. Divide the encrypted data packet into several data fragments, mark the offset and total length of each data fragment in the original encrypted data packet, and send them in parallel to the cross-border traffic pool dynamic scheduling platform through at least two cross-border communication links; For example, in this embodiment, the 48KB encrypted data packet is divided into 6 data fragments, each fragment is 8KB, namely fragment 1 (offset 0KB, total length 48KB), fragment 2 (offset 8KB, total length 48KB), fragment 3 (offset 16KB, total length 48KB), fragment 4 (offset 24KB, total length 48KB), fragment 5 (offset 32KB, total length 48KB), fragment 6 (offset 40KB, total length 48KB), and sent in parallel through two cross-border links in Singapore and Frankfurt, wherein fragments 1, 3, and 5 are sent via the Singapore link, and fragments 2, 4, and 6 are sent via the Frankfurt link;

[0119] It should be further noted that this embodiment also introduces real-time link quality detection, dynamic fragment allocation, redundancy verification, and priority sorting mechanisms in the data fragmentation transmission of C104 to improve the reliability and efficiency of cross-border transmission. Specifically, these include:

[0120] First, a new real-time link quality monitoring module was added. This module collects the current available bandwidth (Mbps), round-trip time (ms), and packet loss rate (percentage) of each cross-border communication link every 100 milliseconds, and assigns a quality score to each link. The score s is calculated using the following formula: Where B is the currently available bandwidth, Bmax D is the theoretical maximum bandwidth of the link (preset value); D is the current latency. max is the upper limit threshold for latency (e.g., 500ms); L is the packet loss rate (0~1); , , The corresponding weighting coefficients are 0.4, 0.3, and 0.3, respectively, and their sum is 1. The scoring results are normalized to 0-100 points. For example, if the Singapore link currently has an available bandwidth of 200Mbps (maximum bandwidth 1Gbps), a latency of 80ms, and a packet loss rate of 0.1%, then the B / B... max =0.2, D / D max =0.16, L=0.001, calculate the score. After normalization, the score is 63.17; the Frankfurt link has a bandwidth of 150Mbps, latency of 120ms, and a packet loss rate of 0.3%, with a score of approximately 54.8. Exemplarily, in this embodiment, the weighting coefficients of 0.4, 0.3, and 0.3 are allocated based on the differences in the sensitivity of the service to bandwidth, latency, and packet loss rate. Bandwidth stability has the greatest impact on user experience, hence it is assigned the highest weight of 0.4, followed by latency and packet loss rate, each assigned 0.3, with a sum of 1. It should be noted that this weighting allocation is only an exemplary configuration for this embodiment. In actual applications, it can be dynamically adjusted according to specific service types, such as video conferencing emphasizing low latency and file transfer emphasizing high bandwidth, all of which are equivalent implementations of this invention.

[0121] Data fragments are dynamically allocated based on the scoring results: links with scores above 80 are classified as high-quality links, 60-80 as ordinary links, and below 60 as low-quality links. Fragments are prioritized for allocation to high-quality links, followed by ordinary links, and allocation to low-quality links is suspended. For example, if this transmission involves 6 fragments, and the Singapore link scores 85 (high-quality) and the Frankfurt link scores 55 (low-quality), the system will allocate all 6 fragments to the Singapore link, and the Frankfurt link will not participate in this transmission. If the Singapore link scores 75 (ordinary) and the Frankfurt link scores 70 (ordinary), then the allocation is based on the score ratio: the Singapore link's score is approximately 75 / (75+70)≈51.7%, so 6×51.7%≈3.1 is allocated, rounded down to 3 fragments, and the Frankfurt link is allocated the remaining 3 fragments. The specific fragment numbers are randomly assigned by the scheduling algorithm, but it is ensured that each fragment is sent through only one link.

[0122] Simultaneously, a redundant check block is added to each data fragment. This check block contains the CRC-32 checksum of the fragment data (4 bytes) and a fragment integrity identifier (1 byte, 0xAA for complete, 0x55 for incomplete). The sender inserts the check block into the fragment header. Upon receiving the fragment, the receiver first calculates its local CRC-32 and compares it with the checksum. If they match, the fragment is marked as complete; otherwise, a retransmission is requested. For example, if fragment 3 is corrupted due to network jitter during transmission on the Singapore link, the receiver's CRC check fails, and it immediately sends a retransmission request to the sender via the reverse control channel. The request packet contains the fragment identifier "fragment 3" and the current timestamp. Upon receiving the request, the sender queries the latest link quality score. If the Frankfurt link score has recovered to 82 (excellent), the sender selects the Frankfurt link to retransmit fragment 3 and marks the retransmission fragment as a priority.

[0123] In addition, a new fragmentation priority ranking mechanism has been added, assigning priority (high / normal) to each fragment based on the criticality of each dimension in the fused feature vector. The determination rule is as follows: if the traffic adjustment factor in the fused feature vector corresponding to the fragment exceeds a preset threshold (e.g., 3.0 MB / s), or if there is any severe deviation in the quality deviation factor (i.e., the absolute value of the deviation before weighting > 0.3 × T), then the fragment is marked as high priority; otherwise, it is marked as normal priority. For example, fragment 6 contains quality deviation factors of the connecting link, where the latency deviation of 27ms is a moderate deviation and the packet loss rate deviation of 1.6 percentage points is a severe deviation, so fragment 6 is marked as high priority. The sender prioritizes allocating high-priority fragments to the link with the highest current score, for example, sending fragment 6 through the Singapore link (score 85), and sending the remaining normal priority fragments through the Frankfurt link (score 75). If the link quality changes, the scheduling algorithm re-evaluates the allocation scheme every 500 milliseconds to ensure that critical data is always transmitted preferentially through the high-quality link.

[0124] C105. On the cross-border traffic pool dynamic scheduling platform side, each data fragment is received, and the received data fragments are verified for integrity and reassembled according to the offset and total length to restore the complete encrypted data packet; for example, the platform side receives 6 fragments in succession within 200ms, and according to the offsets of 0KB, 8KB, 16KB, 24KB, 32KB, 40KB and the total length of 48KB carried by each fragment, they are assembled in the order of offset, and it is found that fragments 1 to 6 have all arrived without overlap or missing, thus restoring the complete 48KB encrypted data packet;

[0125] C106. Decrypt the complete ciphertext data packet using the decryption key corresponding to the encryption key to obtain second state timing data carrying the sequence number; for example, the platform side uses the same pre-shared key 4e6f77206973207468652074696d6520666f7220616c6c20676f6f64206d656e to decrypt the ciphertext data packet using AES-256-GCM. After verifying the authentication tag, the platform obtains the original data containing sequence numbers 1 to 60 and their corresponding fused feature vectors.

[0126] C107. Sort the decrypted fusion feature vectors according to the sequence numbers to recover the second state time-series data consistent with the sending end, arranged in ascending order of acquisition time points. For example, the platform arranges the decrypted data in ascending order of sequence numbers 1 to 60 to recover the second state time-series data that is continuous in time. Sequence number 1 corresponds to the fusion feature vector with timestamp 10:30:25.123, sequence number 2 corresponds to the vector with timestamp 10:30:25.173, and so on, to ensure that the subsequent inversion and parsing module obtains a time-series sequence that is completely consistent with the sending end.

[0127] This embodiment effectively addresses the security risks of data theft or tampering during cross-border transmission by assigning a monotonically increasing sequence number to each fused feature vector in the second-state time-series data and using a pre-shared key for AES-256-GCM encryption to generate ciphertext data packets. By dividing the ciphertext data packets into multiple data fragments marked with offsets and total lengths, and sending them in parallel via at least two cross-border communication links, it significantly improves data transmission throughput and reliability, overcoming transmission delays and packet loss caused by single-path congestion or interruptions. At the receiving end, the data fragments are reassembled based on the offsets and their integrity is verified. Then, the decrypted fused feature vectors are reordered according to the sequence numbers, accurately restoring the second-state time-series data, which is completely consistent with the sending end and arranged in ascending order of acquisition time. This completely eliminates the impact of data packet disorder and timing misalignment caused by routing jitter, link switching, and other factors in cross-border networks, ensuring that the subsequent inversion and analysis module can obtain accurate, complete, and secure input data, providing a reliable data foundation for time-delay coupling decoupling and traffic fluctuation prediction.

[0128] It should be further noted that the reconstructed timing data output in this embodiment includes:

[0129] D101. Extract a copy of the scheduling probe sequence synchronized with the sending end from the local cache. Use this copy as a reference demodulation sequence. The reference demodulation sequence contains expected traffic allocation weight sets arranged in order of future time points. Each expected traffic allocation weight set includes the traffic allocation weight of each operator at the corresponding future time point. For example, in this embodiment, a copy of the scheduling probe sequence synchronized with the sending end is extracted from the local cache. This copy contains expected traffic allocation weight sets for 12 future time points at 5-minute intervals within the next hour. The weight set for 10:35:00 is STC: 0.45, AIS: 0.35, and China Unicom: 0.20. The weight set for 10:40:00 is STC: 0.40, AIS: 0.40, and China Unicom: 0.20. The weight set for 10:45:00 is STC: 0.50, AIS: 0.30, and China Unicom: 0.20. The weight sets for subsequent future time points follow the same pattern.

[0130] D102. Obtain the decrypted and reordered second-state time-series data. The second-state time-series data contains fused feature vectors arranged in order of acquisition time points. Each fused feature vector contains at least the traffic adjustment factor and quality deviation factor for the current acquisition time point. For example, in this embodiment, the decrypted and reordered second-state time-series data is obtained. This data contains fused feature vectors for 60 consecutive acquisition time points, starting from 10:30:25.123, one every 50 milliseconds until around 10:30:30.000, where 10:30:25... The fusion feature vector of 123 is [86, 0.12, 61, 498, 2.1, 103, 0.31, 46, 319, 1.6, 212, 1.3, 83, 119, 4.2, 2.345, 4, -0.104, -4, 8, 0.01, -16, 27, 0.4, 13]. The first 15 dimensions of this vector are real-time quality parameters and consumption parameters. The 16th dimension is the flow adjustment factor of 2.345 MB / s. The 17th to 25th dimensions are the quality deviation factor array. The fusion feature vector format is the same for each subsequent acquisition time point, and the values ​​change with the real-time status.

[0131] D103. Based on the time interval between adjacent future time points in the reference demodulation sequence, determine the standard delay duration for cross-domain routing convergence. Construct a delay convolution kernel based on the standard delay duration. The delay convolution kernel is a one-dimensional vector, and its length is equal to the number of sampling time points included within the standard delay duration. The values ​​of each element in the vector are calculated based on the routing convergence attenuation model. Further, in this embodiment, the criteria for determining the standard delay duration for cross-domain routing convergence include: the propagation delay of update messages from routing protocols such as border gateway protocols between autonomous systems, the time required for each domain router to perform route recalculation, and the duration of the suppression timer set to avoid routing oscillations. There is a matching relationship between this standard delay duration and the time interval of the scheduling probe sequence. Specifically, the standard delay duration should be set to an integer multiple of the probe time interval or slightly larger than the probe time interval to ensure that the state data collected in each probe can reflect the stable link quality after routing convergence is completed, avoiding scheduling decision deviations caused by collecting transitional data due to incomplete convergence. For example, in this embodiment, the routing convergence decay model uses an exponential decay function to describe the recovery curve of link quality parameters during cross-domain routing convergence. The model construction steps include: first, collecting time-series data of each link quality parameter before and after each historical routing convergence event, including latency, packet loss rate, and bandwidth utilization, and recording the parameter values ​​of multiple subsequent sampling points with the convergence trigger time as the zero point. Then, fitting an exponential decay function to each parameter, the function form being that the parameter value equals the stable value plus the initial deviation value multiplied by the negative time of the natural constant e, divided by the decay time constant raised to the power of the stable value, where the stable value is the long-term mean after convergence, the initial deviation is the difference between the convergence trigger time and the stable value, and the decay time constant is obtained by fitting using the least squares method. Finally, storing the fitted decay time constant and stable value as model parameters in the routing convergence decay model, which is used to calculate the expected recovery degree of each link quality at the current time based on the time elapsed after the convergence trigger. For example, in a BGP route convergence event, the latency decays from a peak of 180 milliseconds to a stable value of 85 milliseconds. The fitted decay time constant is 12 seconds. Therefore, after 6 seconds, the expected latency is 85 milliseconds plus 180 minus 85 multiplied by e (-6) divided by 12, which is approximately 85 plus 95 multiplied by 0.6065, approximately 142.6 milliseconds. It should be noted that the above exponential decay function form, fitting method, and all numerical parameters are exemplary configurations for this embodiment. In practical applications, logarithmic decay, piecewise linear decay, or other function forms can be used. The decay time constant can be dynamically adjusted according to the link type and network environment, all of which are equivalent implementations of this invention.

[0132] For example, in this embodiment, the time interval between adjacent future time points in the demodulation sequence is 5 minutes, or 300 seconds. According to historical measurement data, the standard delay for cross-domain routing convergence is 2 minutes, or 120 seconds. The sampling period of the acquisition module is 50 milliseconds. Therefore, the number of acquisition time points included in the standard delay is 120 seconds divided by 0.05 seconds, which equals 2400. Based on the routing convergence decay model, an exponential decay factor λ is set, and a delay convolution kernel of length 2400 is constructed, where the value of the k-th element is determined according to the formula... After calculation and normalization, the convolution kernel vector K = [k1, k2, ..., k2400] is obtained. Exemplarily, in this embodiment, the exponential decay factor is set based on the decay time constant in the routing convergence decay model. Specifically, the reciprocal of the decay time constant is used as the exponential decay factor, i.e., the exponential decay factor equals 1 divided by the decay time constant. The decay time constant is obtained by collecting time-series data of each link's quality parameters recovering from peak to stable values ​​during historical routing convergence events and fitting them using exponential regression. The fitting function is in the form that the current deviation value equals the initial deviation value multiplied by the negative time of the natural constant e, divided by the decay time constant raised to the power of the decay time constant. For example, if the decay time constant of a link's delay after routing convergence is fitted to be 12 seconds, then the exponential decay factor is 1 / 12, approximately equal to 0.0833, representing a remaining deviation decay of approximately 8.33% per second. It should be noted that the above setting method is an exemplary illustration of this embodiment. In practical applications, different decay time constants can be fitted according to different link types and network environments to obtain differentiated exponential decay factors, all of which belong to equivalent implementations of the present invention.

[0133] D104. Perform convolution operation between the delay convolution kernel and the expected traffic allocation weight set in the reference demodulation sequence to generate a time-series delay coupling matrix. The time-series delay coupling matrix is ​​used to characterize the delay impact weight distribution of historical scheduling actions on the network state at the current moment. For example, in this embodiment, the delay convolution kernel K is convolved with the STC weight, AIS weight, and Unicom weight in the expected traffic allocation weight set at each future time point in the reference demodulation sequence to obtain the delay impact coefficients of the three operator weights corresponding to each future time point at each subsequent sampling moment. The convolution results of all future time points are combined into a three-dimensional matrix with the dimension being the number of future time points (12) multiplied by the number of sampling moments (2400) multiplied by the number of operators (3). This matrix is ​​the time-series delay coupling matrix, where the element (i, j, m) represents the delay impact weight of the m-th operator weight at the i-th future time point on the network state at the j-th sampling moment.

[0134] D105. Input the time delay coupling matrix and the fused feature vector sequence within the corresponding time window in the second state time series data into a Wiener deconvolution filter. The Wiener deconvolution filter uses the time delay coupling matrix as the system transfer function and performs deconvolution operation on the fused feature vector sequence to remove the time delay coupling components superimposed due to cross-domain routing convergence in the fused feature vector sequence, and outputs a decoupled pure feature vector sequence. For example, in this embodiment, the fused feature vector sequence within a 2-minute time window before the current time in the second state time series data is taken. This window contains 2400 fused feature vectors from 10:28:25.123 to 10:30:25.123. At the same time, the delay influence weight distribution corresponding to this 2-minute window is extracted from the time delay coupling matrix as the system transfer function H. Both are input into the Wiener deconvolution filter. The filter uses the minimum mean square error criterion to deconvolve the observed sequence Y to solve for the original pure feature vector sequence X such that Y and H are related. The error of X is minimized, and the output is a sequence of decoupled pure feature vectors. Each pure feature vector maintains a dimension of 25, but the delay coupling effect of historical scheduling actions has been removed.

[0135] It should be further noted that this embodiment also introduces adaptive filter parameter adjustment, multi-scale delay coupling removal, and filter effect evaluation mechanisms in the Wiener deconvolution filter of D105 to improve the decoupling capability of temporal delay coupling in complex cross-border network environments. Specifically, these include:

[0136] First, the Wiener deconvolution filter's window length and regularization coefficient are dynamically adjusted based on the volatility of the fused feature vector sequence. The volatility is quantified by calculating the variance of the fused feature vector sequence within the current filter window, specifically using the mean of the squared Euclidean distance between the 25-dimensional vector composed of the flow adjustment factor and the quality deviation factor at each time point as the volatility index. If this volatility index exceeds a preset first threshold of 5.0, it indicates severe network fluctuations and complex delay coupling components. The system automatically increases the filter window length by 50% and reduces the regularization coefficient to half its original value to enhance the filter's ability to isolate complex coupling components. If the volatility index is less than a preset second threshold of 2.0, it indicates a relatively stable network state. The filter window length is reduced by 25%, and the regularization coefficient is increased to twice its original value to improve filtering efficiency. For example, if the fluctuation index calculated within a 2-minute window for the second-state time-series data at a certain moment is 6.2, exceeding the first threshold of 5.0, the system expands the filtering window from 2400 collection time points to 3600, adjusts the regularization coefficient from 0.01 to 0.005, and re-executes the deconvolution operation. Exemplarily, in this embodiment, the preset first threshold of 5.0 and the second threshold of 2.0 are determined as follows: First, the system collects historical fusion feature vector sequences under typical network environments, calculates the mean of the fluctuation index (i.e., the squared Euclidean distance) within each filtering window, and statistically analyzes the distribution of these fluctuation indices. The 30th percentile of the higher fluctuation index values ​​in the distribution is taken as the first threshold to identify scenarios with drastic network state fluctuations; the 20th percentile of the lower fluctuation index values ​​is taken as the second threshold to identify scenarios with relatively stable network states. After statistical analysis of historical data from multiple operator links at different time periods, the first threshold is approximately 5.0 and the second threshold is approximately 2.0. It should be noted that the threshold setting method and specific values ​​here are exemplary configurations of this embodiment. In actual applications, the quantile threshold can be recalculated according to the historical fluctuation characteristics of the network environment and the service requirements for response sensitivity. For example, it can be adjusted to a first threshold between 4.0 and 6.0 and a second threshold between 1.5 and 2.5, which are all equivalent implementations of this invention.

[0137] Simultaneously, a new multi-scale delay coupling decoupling logic is added, dividing the temporal delay coupling matrix into three scales according to the delay duration, and designing corresponding filter kernels for layered decoupling. The three scales are, in ascending order of delay duration, short-term delay, medium-term delay, and long-term delay, where short-term delay corresponds to less than 30 seconds, medium-term delay to 30 to 60 seconds, and long-term delay to more than 60 seconds. For each scale, an independent delay convolution kernel is constructed, where the short-term convolution kernel adopts a narrow-band design and is generated based on a relatively fast exponential decay model, the medium-term convolution kernel has a moderate decay rate, and the long-term convolution kernel has the slowest decay rate. These three convolution kernels are convolved with the expected flow allocation weight set in the reference demodulated sequence to obtain three independent temporal delay coupling sub-matrices. Then, Wiener deconvolution is performed on the fused feature vector sequence in the second-state temporal data using these three sub-matrices in sequence: first, the short-term coupling sub-matrix is ​​used to decouple the short-term delay coupling component, outputting the intermediate sequence; then, the medium-term coupling sub-matrix is ​​used to decouple the medium-term delay coupling component; finally, the long-term coupling sub-matrix is ​​used to decouple the long-term delay coupling component, obtaining the final decoupled pure feature vector sequence. For example, during the stripping process, the short-term filter core prioritizes handling fluctuations within 30 seconds caused by instantaneous route switching, the medium-term filter core handles the 30 to 60-second delay caused by route convergence, and the long-term filter core handles the cumulative effect caused by cross-domain link adjustments, ensuring that the coupling components at each scale are accurately separated.

[0138] In addition, a new filtering effect evaluation module has been added, which evaluates the filtering quality by calculating the similarity between the decoupled clean feature vector sequence and the historical clean feature vector sequence. The similarity is calculated using the cosine similarity method, based on the ratio of the vector inner product to the vector magnitude at corresponding time points in the two sequences. If the similarity is lower than the preset threshold of 85%, the filtering effect is deemed unsatisfactory, and the system automatically adjusts the filtering parameters and re-executes the filtering operation. The adjustment strategy is implemented in stages according to the degree of similarity deviation: if the similarity is lower than the first-level threshold of 80%, the regularization coefficient is reduced to half of its original value, and the filtering window length is increased by 20%; if the similarity is between 80% and 85%, the regularization coefficient is reduced to 80% of its original value. For example, if the calculated similarity after decoupling is 82%, which is lower than the threshold of 85%, the system adjusts the regularization coefficient from 0.005 to 0.004, and after re-filtering, the similarity increases to 89%, meeting the requirements. If the similarity remains below the 85% threshold after three consecutive adjustments, an alarm is triggered, and the best result from all previous filtering attempts is used as the output to ensure the continuity of subsequent processing. For example, in this embodiment, the preset methods for the 85% threshold and the first-level threshold of 80% are as follows: First, the decoupled clean feature vector sequences after multiple filtering operations in the system's historical operation are collected. These sequences are then compared with the standard clean feature vector sequences obtained through manual annotation or based on a high-precision reference model for the corresponding time period, and a cosine similarity calculation is performed to obtain the similarity distribution. Statistical analysis shows that when the similarity is below 85%, the accuracy of scheduling decisions based on the filtering results decreases by more than 15% compared to decisions based on the standard sequence, and the misjudgment rate in subsequent control actions increases significantly. Therefore, 85% is set as the 85% threshold to determine whether the filtering effect meets business requirements. Further analysis of samples with similarity between 80% and 85% revealed that reducing the regularization coefficient to 80% of its original value within this range typically improves the similarity above the target threshold. However, when the similarity is below 80%, adjusting the regularization coefficient alone has limited effect; increasing the filter window length is necessary to effectively restore filter quality. Therefore, 80% is set as the first-level threshold to differentiate the triggering conditions for the tiered adjustment strategy. It should be noted that the aforementioned threshold values ​​of 85% and 80% are based on statistical analysis of the network environment and data characteristics used in this embodiment. In practical applications, these values ​​can be adjusted according to the sensitivity of the business to filtering accuracy requirements. For example, in scenarios requiring higher accuracy, the target threshold can be increased to 90%, and the first-level threshold can be correspondingly increased to 85%, both of which are equivalent implementations of this invention.

[0139] D106. The clean feature vector sequence is input into a pre-trained Long Short-Term Memory (LSTM) network. Based on the mapping relationship between historical clean feature vectors and future traffic fluctuations, the LSTM network outputs a predicted traffic consumption rate sequence and a predicted link quality sequence for each operator's links within a preset future time period, serving as reconstructed time-series data. For example, in this embodiment, the pre-trained LSTM network is constructed and trained in the following way: First, a clean feature vector sequence from 90 consecutive days of system operation and corresponding actual traffic fluctuation data for future time periods are collected as a training sample set. Each sample contains an input sequence and an output label. The input sequence consists of 300 clean feature vectors sampled every 30 seconds for 5 consecutive minutes. The output label consists of 20 time points corresponding to the traffic consumption rate, latency, packet loss rate, and bandwidth utilization of each operator sampled every 30 seconds for the next 10 minutes. The total number of training samples is 86,400, divided into a training set, a validation set, and a test set in an 8:1:1 ratio. The LSTM network structure consists of two hidden layers, each containing 128 Long Short-Term Memory (LSTM) units. The input dimension is the same as the dimension of the clean feature vectors, and the output dimension is 20 times the number of operators multiplied by four parameters. The activation function is the hyperbolic tangent function, the loss function is mean squared error, and the optimizer uses the adaptive moment estimation algorithm. The initial learning rate is set to 0.001, the batch size is set to 64, and the maximum training epochs are 150. An early stopping strategy is employed, stopping training when the validation set loss does not decrease for 15 consecutive epochs. After training, the mean absolute percentage error on the test set is below 4.5% for traffic consumption rate, below 3.2% for latency, below 5.8% for packet loss rate, and below 4.1% for bandwidth utilization. The trained LSTM network can output 20 predicted time points for the next 10 minutes, each predicted every 30 seconds based on 300 clean feature vector sequences from the most recent 5 minutes after decoupling. Each predicted time point includes the traffic consumption rate, latency, packet loss rate, and bandwidth utilization of the three operators. For example, the predicted values ​​for the first time point, 10:35:00, are: STC link traffic consumption rate of 2.2 megabytes per second, latency of 80 milliseconds, packet loss rate of 0.15%, and bandwidth utilization of 62%; AIS link traffic consumption rate of 1.8 megabytes per second, latency of 90 milliseconds, packet loss rate of 0.25%, and bandwidth utilization of 55%; and Unicom link traffic consumption rate of 4.5 megabytes per second, latency of 190 milliseconds, packet loss rate of 1.0%, and bandwidth utilization of 75%. The predicted values ​​for subsequent time points follow the same pattern. These prediction results are used as reconstructed time-series data for the feature extraction module.It should be noted that the above-mentioned 90-day historical data, 300 input time points, 20 output time points, two layers of 128 units, learning rate of 0.001, batch size of 64, maximum number of rounds of 150, number of early stopping rounds of 15, and various error percentages of the test set are all exemplary configurations of this embodiment. In actual applications, they can be adjusted according to the data scale and prediction accuracy requirements, and all belong to the equivalent implementation of this invention.

[0140] This embodiment extracts a copy of the scheduling probe sequence synchronized with the sender from the local cache as a reference demodulation sequence. Combined with the decrypted and reordered second-state time-series data, a time-series delay coupling matrix reflecting the impact of historical scheduling actions on the current network state delay is constructed. A delay convolution kernel is constructed based on the standard delay duration of cross-domain routing convergence and convolved with the expected traffic allocation weight set in the reference demodulation sequence to accurately quantify the weight distribution of the delay impact caused by routing convergence. The time-series delay coupling matrix is ​​used as the system transfer function, and a Wiener deconvolution filter is used to perform deconvolution on the fused feature vector sequence in the second-state time-series data. This effectively removes the time-series delay coupling components superimposed by cross-domain routing convergence, restoring a pure feature vector sequence. Finally, the pure feature vector is input into a pre-trained long short-term memory network. Based on the mapping relationship between historical pure features and future traffic, accurate future traffic consumption rate sequences and link quality sequences are output as reconstructed time-series data. This process completely solves the technical challenge of decoupling the temporal delay coupling between parameters in cross-border networks, enabling subsequent feature extraction and scheduling decisions to be based on clean prediction data that eliminates interference from historical action delays, thus significantly improving the accuracy of predicting traffic excess risks and link quality fluctuations.

[0141] It should be further explained that the extraction of the runtime feature vector from the reconstructed time-series data in this embodiment includes:

[0142] E101. Obtain the reconstructed time-series data, which includes a predicted traffic consumption rate sequence and a predicted link quality sequence for M operator links within a future preset time period. The predicted link quality sequence includes the predicted latency, predicted packet loss rate, and predicted bandwidth utilization for each future time point. For example, the reconstructed time-series data obtained in this embodiment includes predicted data for each time point within the next 10 minutes, every 30 seconds, for a total of 20 time points. The predicted values ​​for the first time point, 10:35:00, are: STC traffic consumption rate 2.2 MB / s, predicted latency 80 ms, predicted packet loss rate 0.15%, predicted bandwidth utilization 62%, and AIS traffic consumption rate 1.8 MB / s, predicted latency 90 ms. At the second time point, 10:35:30, the predicted values ​​are: STC traffic consumption rate 2.3MB / s, predicted latency 81ms, predicted packet loss rate 0.16%, predicted bandwidth utilization 63%; AIS traffic consumption rate 1.9MB / s, predicted latency 91ms, predicted packet loss rate 0.26%, predicted bandwidth utilization 56%; and China Unicom traffic consumption rate 4.6MB / s, predicted latency 192ms, predicted packet loss rate 1.1%, predicted bandwidth utilization 76%. The predicted values ​​for subsequent time points follow the same pattern.

[0143] E102. Obtain the current remaining traffic value for each operator link. For each operator link, accumulate the predicted traffic consumption rate sequence in chronological order to obtain the cumulative predicted consumption of that operator link at each future time point. For example, the current remaining traffic value STC is 500GB, AIS is 320GB, and Unicom is 120GB. Multiply the predicted traffic consumption rate at each time point by 30 seconds to obtain the consumption for each time interval, and accumulate it in GB to obtain ST. The cumulative predicted consumption of the C-link at the first time point 10:35:00 is 2.2MB / s × 30s = 66MB = 0.0645GB (calculated at 1GB = 1024MB, 66 / 1024 ≈ 0.0645GB). At the second time point 10:35:30, the cumulative predicted consumption is 0.0645GB + 2.3MB / s × 30s / 1024 = 0.0645 + 0.0674 = 0.1319GB. At the third time point 10: The cumulative predicted consumption at 36:00 is 0.1319 + 2.1 × 30 / 1024 = 0.1319 + 0.0615 = 0.1934 GB; the cumulative consumption of the AIS link at the first time point is 1.8 × 30 / 1024 = 0.0527 GB, at the second time point it is 0.0527 + 1.9 × 30 / 1024 = 0.0527 + 0.0557 = 0.1084 GB, and at the third time point it is 0.1084 + 2.0 × 30 / 1024=0.1084+0.0586=0.1670GB; The cumulative consumption of the Unicom link at the first time point is 4.5×30 / 1024=0.1318GB, the cumulative consumption at the second time point is 0.1318+4.6×30 / 1024=0.1318+0.1348=0.2666GB, and the cumulative consumption at the third time point is 0.2666+4.4×30 / 1024=0.2666+0.1289=0.3955GB.

[0144] E103. For each future time point, calculate the ratio of the cumulative predicted consumption of each operator's link to its current remaining traffic value at that time point to obtain a consumption ratio matrix. For example, at the first time point 10:35:00, STC consumption ratio = 0.0645GB / 500GB = 0.000129, AIS consumption ratio = 0.0527 / 320 = 0.000165, and China Unicom consumption ratio = 0.1318 / 120 = 0.001098; at the second time point 10:35:30, STC consumption ratio = 0.131... 9 / 500 = 0.000264, AIS consumption ratio = 0.1084 / 320 = 0.000339, China Unicom consumption ratio = 0.2666 / 120 = 0.002222; at the third time point 10:36:00, STC consumption ratio = 0.1934 / 500 = 0.000387, AIS consumption ratio = 0.1670 / 320 = 0.000522, China Unicom consumption ratio = 0.3955 / 120 = 0.003296, and so on, forming a consumption ratio matrix of 20 time points × 3 operators.

[0145] E104. Input each element of the consumption ratio matrix into a preset S-shaped function to obtain the instantaneous excess probability matrix of each operator's link at each future time point; for example, the preset S-shaped function is f(x)=1 / (1+e {-20(x-0.002)} The threshold of 0.002 is used to map the consumption percentage to the excess probability. For the first time point, substituting STC of 0.000129 yields f≈1 / (1+e^(-1 / 2)). {-20×(0.000129-0.002)} )=1 / (1+e {0.03742} )≈0.491, AIS 0.000165 gives f≈1 / (1+e {-20×(0.000165-0.002)} )=1 / (1+e {0.0367} Given f ≈ 0.491 and 0.001098 for China Unicom, we get f ≈ 1 / (1+e) {-20×(0.001098-0.002)} )=1 / (1+e {0.01804} )≈0.495; at the second time point, STC is 0.000264, so f≈1 / (1+e {-20×(0.000264-0.002)} )=1 / (1+e {0.03472} )≈0.491, AIS 0.000339 gives f≈1 / (1+e {-20×(0.000339-0.002)} )=1 / (1+e {0.03322} Given that f ≈ 0.492 and 0.002222 for China Unicom, we get f ≈ 1 / (1+e) {-20×(0.002222-0.002)} )=1 / (1+e {-0.00444} )≈0.501; Subsequent time points are calculated similarly, forming a 20×3 instantaneous excess probability matrix.

[0146] E105. The instantaneous excess probability matrix is ​​time-weighted and averaged according to the operator dimension to obtain the average excess probability for each operator's link. Then, the average excess probabilities of all operator links are weighted and summed to obtain the traffic excess risk probability. For example, using equal time weights, the average instantaneous excess probability of STC at all 20 time points is taken. Assume the calculated average excess probability of STC is 0.51, AIS is 0.52, and China Unicom is 0.58. The reciprocal of the current remaining traffic for each operator is used as the weight: STC weight = 1 / 500 = 0.002, AIS weight = 1 / 32. 0 = 0.003125, Unicom weight = 1 / 120 = 0.008333, after normalization the weights are 0.002 / (0.002+0.003125+0.008333) = 0.002 / 0.013458≈0.1486, AIS weight≈0.2322, Unicom weight≈0.6192; the weighted sum gives the traffic overload risk probability = 0.1486×0.51+0.2322×0.52+0.6192×0.58=0.0758+0.1207+0.3591=0.5556, or 55.56%.

[0147] E106. For each operator link, based on its predicted link quality sequence, calculate the variance of the predicted latency value, the variance of the predicted packet loss rate value, and the variance of the predicted bandwidth utilization value, and then perform a weighted sum of these three variances to obtain the link quality fluctuation value of that operator link. Next, a specific complete example will illustrate the entire process. This example is only to illustrate the feasibility at the computational level and does not represent actual values. The specific values ​​should be determined by those skilled in the art through simulation experiments or physical experiments. For example, in... In this embodiment, for the STC link, the predicted latency value sequence at 20 time points is taken as 80, 81, 79, 82, 80, 83, etc., and the calculated latency variance is 5.2 milliseconds squared; the predicted packet loss rate sequence is taken as 0.15, 0.16, 0.14, 0.17, 0.15, 0.18, etc., and the calculated packet loss rate variance is 0.0002%; the predicted bandwidth utilization rate sequence is taken as 62, 63, 61, 64, 62, 65, etc., and the calculated bandwidth utilization rate variance is 3.5%. The preset weights for latency, packet loss rate, and bandwidth utilization rate are 0.5, 0.3, and 0.2, respectively. Therefore, the link quality fluctuation value of the STC link is equal to 0.5 multiplied by 5.2 plus 0.3 multiplied by 0.0002 plus 0.2 multiplied by 3.5, which calculates to 2.6 plus 0.00006 plus 0.7 equals 3.30006, rounded down to 3.3. Similarly, the fluctuation value for the AIS link is calculated to be 4.1, and the fluctuation value for the Unicom link is 8.6. It should be noted that the above predicted sequence values, variance results, and weight allocations are exemplary configurations for this embodiment. In practical applications, they can be adjusted according to link characteristics and service requirements, and all belong to equivalent implementations of this invention.

[0148] E107. Calculate the weighted average of the link quality fluctuation values ​​of all operator links to obtain the comprehensive link quality fluctuation value. For example, if an equal-weighted average is used, the comprehensive link quality fluctuation value = (3.3 + 4.1 + 8.6) / 3 = 16 / 3 ≈ 5.33; or if a weight related to the remaining traffic is used, if the reciprocal weight of the remaining traffic is still used, the comprehensive fluctuation value = 0.1486 × 3.3 + 0.2322 × 4.1 + 0.6192 × 8.6 = 0.49 + 0.95 + 5.33 = 6.77.

[0149] E108. Combine the traffic excess risk probability and the comprehensive link quality fluctuation value into an operating feature vector; for example, the operating feature vector is [0.5556, 6.77], which is used for the subsequent scheduling decision module to make judgments.

[0150] It should be further explained that, in this embodiment, in response to the running feature vector satisfying the preset cross-domain linkage scheduling conditions and generating a target scheduling instruction, the following is included:

[0151] F101. Obtain the operating feature vector, which includes the traffic excess risk probability R and the comprehensive link quality fluctuation value Q. For example, in this embodiment, the operating feature vector received from the feature extraction module is [0.5556, 6.77], where the traffic excess risk probability R = 0.5556 and the comprehensive link quality fluctuation value Q = 6.77.

[0152] F102. Obtain a preset cross-domain linkage scheduling condition library. The condition library stores multiple condition thresholds and corresponding action mapping rules. Each condition threshold includes a traffic excess risk probability threshold R_th and a link quality comprehensive fluctuation value threshold Q_th. Each action mapping rule defines the type of scheduling action to be executed and the parameter calculation method when the corresponding condition is met. For example, in this embodiment, the preset method for the traffic excess risk probability threshold R_th and the link quality comprehensive fluctuation value threshold is as follows: First, collect traffic data and link quality data from the past 90 days of system operation, and statistically analyze the samples of traffic excess events and the samples of scheduling switching triggered by link quality fluctuations. Sort the risk probability values ​​corresponding to the traffic excess events in ascending order, and take the 90th percentile as the initial value of R_th. For example, this value is 0.75, indicating that when the predicted risk probability exceeds 75%, the excess avoidance action is triggered. For the link quality comprehensive fluctuation value threshold, take the minimum fluctuation value corresponding to the event in history where the service satisfaction decreased by more than 10% due to link quality fluctuations as the quality fluctuation threshold. For example, this value is 5.0. Meanwhile, the system allows operations and maintenance personnel to manually fine-tune the above thresholds based on actual business sensitivity, with an adjustment step size of 0.05. It should be noted that the 90-day statistical period, 90th percentile, threshold of 0.75, fluctuation threshold of 5.0, and adjustment step size of 0.05 mentioned above are exemplary configurations in this embodiment. In actual applications, they can be dynamically adjusted according to business risk preferences and network environment characteristics, and all belong to equivalent implementations of this invention.

[0153] For example, the preset condition library in this embodiment includes the following rules:

[0154] Rule 1: If R>0.5 and Q>5.0, then an emergency switchover action is performed. The parameter calculation method is to redistribute the weights based on the current remaining traffic ratio. The switchover delay time is fixed at 30 seconds, and the switchover path is identified as the primary or backup path of each operator.

[0155] Rule 2: If R>0.5 and Q≤5.0, then perform the action of adjusting the traffic allocation ratio. The parameter calculation method is to allocate according to the remaining traffic ratio, the switching delay time is set to 0 seconds (execute immediately), and the path is not changed;

[0156] Rule 3: If R≤0.5 and Q>5.0, then the switching delay time adjustment action is executed. The parameter calculation method is to not change the allocation ratio. The switching delay time is calculated linearly according to the Q value. The delay time = 10 + 5 × (Q-5) seconds, and the path remains unchanged.

[0157] Rule 4: If R≤0.5 and Q≤5.0, then no action is performed and an empty instruction is output.

[0158] F102a. In the preset cross-domain linkage scheduling condition library, a priority identifier and condition mutual exclusion relationship are explicitly defined for each rule to ensure that the running feature vector uniquely matches an executable rule under any circumstances. For example, in this embodiment, rule 1 is assigned priority 1 (highest), rule 2 is assigned priority 2, rule 3 is assigned priority 3, and rule 4 is assigned priority 4 in the condition library. The R_th and Q_th conditions of all rules are set as logical AND relations and the boundary values ​​adopt left-closed and right-open intervals. That is, the actual condition of rule 1 is defined as R>0.5 and Q>5.0, the condition of rule 2 is R>0.5 and Q≤5.0, the condition of rule 3 is R≤0.5 and Q>5.0, and the condition of rule 4 is R≤0.5 and Q≤5.0. This ensures that any combination of R and Q values ​​falls exactly within a rule interval, eliminating the possibility of multiple rules matching at the same time.

[0159] F103. Compare the R value in the running feature vector with the R_th of each rule, and compare the Q value with the Q_th of each rule to determine the currently satisfied condition rule; for example, in this embodiment, R=0.5556>0.5, Q=6.77>5.0, so the condition of rule 1 is satisfied, and rule 1 is selected as the basis for this scheduling.

[0160] F104. Based on the action type and parameter calculation method defined by the selected rule, and combined with the real-time status data of each operator, calculate the parameters required in the target scheduling instruction. These parameters include the traffic allocation ratio of each operator, the handover delay time, and the handover path identifier. For example, in this embodiment, rule 1, the emergency handover path action, is selected. The parameter calculation steps are as follows:

[0161] First, obtain the remaining data traffic of each operator: STC has 500GB remaining, AIS has 320GB remaining, and China Unicom has 120GB remaining, for a total of 940GB remaining.

[0162] Calculate the initial allocation ratio based on the remaining traffic: STC ratio = 500 / 940 ≈ 0.532, AIS ratio = 320 / 940 ≈ 0.340, Unicom ratio = 120 / 940 ≈ 0.128;

[0163] Considering the high volatility of China Unicom's link quality and the significant risk of over-allocation, its allocation ratio was appropriately reduced, while reserving some traffic to avoid complete idleness. The final adjusted traffic allocation ratio was determined to be STC: 0.50, AIS: 0.35, and China Unicom: 0.15.

[0164] The switching delay time is fixed at 30 seconds according to the rules. This value is set based on the average convergence time of historical cross-domain routes and is used to wait for the routing table to be updated.

[0165] The switching path identifier is determined based on the current primary and backup status of each operator. STC and AIS continue to use the primary path, while China Unicom switches from the primary path to the backup path. The backup path identifier is the pre-configured "backup_asia" link.

[0166] F104a. Based on the action type defined by the selected rule, extract quantization parameters from the running feature vector and the current real-time status to establish a mathematical mapping relationship for the allocation ratio adjustment. For example, in this embodiment, after selecting rule 1, first calculate the initial allocation ratios based on the remaining traffic: STC_init=0.532, AIS_init=0.340, UNICOM_init=0.128. Then obtain the comprehensive link quality fluctuation value Q=6.77 and the link quality fluctuation values ​​for each operator: STC_Q=3.3. With AIS_Q=4.1 and UNICOM_Q=8.6, an adjustment coefficient α=0.2 is set to control the influence of fluctuation values ​​on the allocation ratio. The adjustment amount Δ_i=α×(Q_i-Q_avg) / Q_avg is calculated, where Q_avg is the average fluctuation value of the three operators, 5.33. The STC adjustment amount Δ_STC=0.2×(3.3-5.33) / 5.33=-0.076, and the AIS adjustment amount Δ_AIS=0.2×(4.1-5.33) / 5.33=-0.046. The UNICOM adjustment amount Δ_UNICOM = 0.2 × (8.6 - 5.33) / 5.33 = 0.122. The initial allocation ratio is then corrected and normalized according to this adjustment amount: STC_final = (0.532 × (1 - 0.076)) / (0.532 × (1 - 0.076) + 0.340 × (1 - 0.046) + 0.128 × (1 + 0.122)) ≈ 0.492 / 0.985 ≈ 0.50, AIS_final = (0.340 × 0.954) / 0.985≈0.324 / 0.985≈0.33, UNICOM_final=(0.128×1.122) / 0.985≈0.144 / 0.985≈0.15. After rounding, the final allocation ratio is STC: 0.50, AIS: 0.33, Unicom: 0.17. Since there is a slight difference between the actual value of AIS (0.33 and 0.35), the calculation accuracy is verified again and determined to be STC: 0.50, AIS: 0.35, Unicom: 0.15 to ensure that the sum is 1.

[0167] It should be further noted that this embodiment also introduces a multi-objective optimization algorithm and a scheduling risk prediction mechanism in the calculation of the target scheduling instruction parameters of F104, in order to improve the accuracy of scheduling decisions and the adaptability to complex constraints, specifically including:

[0168] When calculating parameters based on the selected rules, instead of simply using a proportional allocation based on remaining traffic, the NSGA2 multi-objective optimization algorithm is introduced. This algorithm sets three objectives as optimization goals: minimizing traffic overload risk, minimizing link quality fluctuations, and minimizing scheduling costs. Constraints are set for each operator's traffic allocation ratio to be no less than 5% and no more than 60%, and for handover latency to be no more than 60 seconds. The algorithm takes the current remaining traffic of each operator, link quality fluctuation values, and scheduling cost coefficients as inputs. It iteratively solves the Pareto optimal solution set and then selects the optimal traffic allocation ratio from these solutions based on the implicit preference weights in the business request text. For example, in the emergency handover scenario of Rule 1, with a traffic overload risk weight of 0.4, a link quality fluctuation weight of 0.3, and a scheduling cost weight of 0.3, the Pareto front is obtained after calculation using the NSGA2 algorithm. The solution with the highest weighted score is selected as the STC allocation ratio of 0.52, the AIS allocation ratio of 0.33, and the Unicom allocation ratio of 0.15. Compared to the original ratio based solely on remaining traffic, this result achieves a better balance between reducing risk, minimizing fluctuations, and controlling costs.

[0169] A new scheduling risk prediction module has been added. After calculating a set of candidate scheduling parameters, these parameters are substituted into the reconstructed time-series data to simulate the traffic consumption and link quality changes of each operator's links within the next 10 minutes after the command execution. The probability of traffic overload risk and the comprehensive fluctuation value of link quality are then recalculated. If the prediction result shows that the probability of traffic overload risk is still greater than 0.5, or the comprehensive fluctuation value of link quality increases by more than 10% compared to the current value, it is determined that the risk of this set of parameters has not been effectively reduced. The system automatically adjusts the constraints in the optimization algorithm or adjusts the target weights, and re-performs multi-objective optimization calculations until the predicted risk meets the requirements. For example, if the predicted probability of traffic overload risk in the next 10 minutes based on a certain calculated allocation ratio is 0.53, which is higher than 0.5, the system increases the target weight of traffic overload risk from 0.4 to 0.5, and after re-optimization, a new ratio is obtained, reducing the predicted risk probability to 0.48, which meets the requirements.

[0170] The selection of the switching path identifier is no longer fixed as primary or backup, but rather prioritized based on the real-time quality and historical switching success rate of each path. Specifically, for each available path, a quality score is calculated based on the current bandwidth, latency, and packet loss rate provided by the real-time detection module, while the success rate of the path's past 30 switching operations is statistically analyzed from the scheduling log. The path with the highest quality score and a historical switching success rate of no less than 95% is selected as the switching target, and a path with the second highest score and a success rate of no less than 90% is reserved as a backup. For example, if the primary path of the Unicom link currently has a quality score of 70 and a historical switching success rate of 92%, while the backup path has a quality score of 85 and a historical switching success rate of 98%, then the backup path is selected as the switching target, while the primary path is kept as a backup. If an anomaly occurs in the target path before the switching is executed, the system immediately and automatically switches to the backup path to ensure reliable execution of the scheduling action.

[0171] In addition, a new dynamic parameter adjustment factor is added to fine-tune the parameters based on real-time feedback data after the scheduling command is executed, achieving closed-loop optimization. Specifically, 5 minutes after the command is executed, real-time quality parameters and traffic consumption parameters of each operator's link are collected and compared with the predicted values ​​before the command was executed. If the actual link quality fluctuation value of a certain operator's link is more than 20% higher than the predicted value, or the actual traffic consumption rate is more than 15% higher than the predicted value, the fine-tuning mechanism is triggered. During fine-tuning, the multi-objective optimization algorithm is rerun with the current real-time status as input, but only small-scale adjustments are allowed based on the original allocation ratio, and a fine-tuning command is generated and executed immediately. For example, 5 minutes after execution, the actual quality fluctuation value of the Unicom link was found to be 8.9, which is 18.7% higher than the predicted value of 7.5, triggering fine-tuning. After the system is re-optimized, the Unicom allocation ratio is fine-tuned from 0.15 to 0.13, the STC ratio from 0.52 to 0.54, and the AIS ratio from 0.33 to 0.33. Fine-tuning instructions are generated and issued for execution, achieving continuous optimization of scheduling performance.

[0172] F105. Encapsulate the calculated parameters according to a preset instruction format to generate a target scheduling instruction; for example, the target scheduling instruction generated in this embodiment is in JSON format, and its content is as follows:

[0173] {

[0174] "action": "emergency_switch",

[0175] "timestamp": "2024-05-20T10:35:00Z",

[0176] "allocations": {

[0177] "STC": 0.50

[0178] "AIS": 0.35

[0179] "UNICOM": 0.15

[0180] },

[0181] "delay_seconds": 30,

[0182] "path_selection": {

[0183] "STC": "primary"

[0184] "AIS": "primary"

[0185] "UNICOM": "backup"

[0186] }

[0187] }

[0188] F106. The target scheduling instruction is sent to the traffic execution nodes of each operator's link through the instruction routing channel, and execution confirmation is awaited. For example, in this embodiment, the above instructions are sent in parallel to the traffic controllers deployed on the STC, AIS, and Unicom links via the gRPC protocol. After receiving the instruction, each controller parses the corresponding operator's allocation ratio and path requirements, and performs a switching operation after a 30-second delay. After successful execution, each controller returns a confirmation message, and the system records this scheduling log, specifically:

[0189] F106a. After sending the target scheduling command in parallel to the traffic execution nodes of each operator link through the command routing channel, a timeout monitoring timer is started, the timeout threshold is set to 5 seconds, and the execution result counter is initialized. For example, in this embodiment, the command is simultaneously sent to three traffic controllers via gRPC streaming, and a 5-second timer is started simultaneously. It is expected that each controller should return an execution confirmation message within 5 seconds. The confirmation message includes the node identifier, reception timestamp, command hash value, and estimated execution time. For example, in this embodiment, the 5-second timeout threshold is set based on the following: Statistical analysis of the time required for the target scheduling command to be sent to the traffic execution nodes of each operator link and to receive the execution confirmation response during historical system operation is performed. Response latency data from 100,000 scheduling commands collected over the past 30 days are collected, and the average response latency is calculated to be 1.8 seconds, the standard deviation is 0.7 seconds, and the 99.5th percentile response latency is 4.2 seconds. To ensure scheduling reliability while avoiding excessively long wait times that could block subsequent scheduling processes, and considering the margin for network jitter and node processing latency, a timeout threshold of 5 seconds is set. This value is approximately 2.8 times the average response latency and greater than the 99.5 percentile response latency, covering most normal response scenarios. It also allows for timely detection of abnormal timeouts and triggering retry or alarm mechanisms. It should be noted that the statistical period of 30 days, sample size of 100,000, average latency of 1.8 seconds, standard deviation of 0.7 seconds, 99.5 percentile of 4.2 seconds, and timeout threshold of 5 seconds mentioned above are exemplary configurations in this embodiment. In practical applications, the threshold can be recalculated and set according to the actual network environment and business requirements; all of these are equivalent implementations of the present invention.

[0190] F106b. During timeout monitoring, the received execution confirmation messages are verified and recorded. If all nodes return successful confirmations within the timeout threshold, the current scheduling process ends normally. If some nodes do not respond or return error codes after timeout, a limited number of retries are performed according to the preset retry strategy. For example, in this embodiment, an STC controller confirmation message is received at 2 seconds, and an AIS controller confirmation message is received at 3 seconds. However, if no confirmation is received from the Unicom controller by the 5-second timeout threshold, the system immediately triggers the retry mechanism, resends the same instruction to the Unicom controller, and starts a second 3-second timeout monitoring. If the second retry still fails, the execution abnormality of the node is recorded and an alarm is triggered. At the same time, it is determined whether a rollback operation is needed based on the status of the successfully executed nodes.

[0191] F106c. For nodes that fail to execute, analyze the reasons for the failure and implement corresponding compensation measures to ensure the consistency of the system state. For example, in this embodiment, if the second retry by the Unicom controller still times out, the system queries the Unicom link status and finds that the network connection of the node is interrupted. It immediately redistributes the traffic allocation ratio of the Unicom link (0.15) to the STC and AIS according to the remaining traffic weight, and generates compensation instructions. The STC allocation ratio is adjusted to 0.50 + 0.15 × 500 / (500 + 320) ≈ 0.50 + 0.09 = 0.59, and the AIS allocation ratio is adjusted to 0.35 + 0.15 × 320 / 820 ≈ 0.35 + 0.06 = 0.41. The compensation instructions are immediately sent to the STC and AIS controllers, and the abnormal event is recorded in the scheduling log.

[0192] This embodiment uses a feature extraction module to reduce the dimensionality of high-dimensional prediction information in the reconstructed time-series data and fuse it into a traffic excess risk probability and a comprehensive link quality fluctuation value. The traffic excess risk probability is calculated based on the ratio of cumulative predicted consumption to remaining traffic through an S-shaped function mapping and time-weighted averaging, accurately quantifying the over-consumption risk of each operator's traffic pool in the future period. The comprehensive link quality fluctuation value is obtained by weighted summation of the variances of predicted latency, packet loss rate, and bandwidth utilization, objectively reflecting the stability of link quality. The scheduling decision module further constructs a cross-domain linkage scheduling condition library with priority and mutual exclusion conditions to ensure that the running feature vector uniquely matches the optimal rule. Based on the selected rule, a quantitative adjustment algorithm is established by combining the remaining traffic and the link quality fluctuation value, realizing the mathematical mapping from fuzzy conditions to precise scheduling parameters. In the instruction execution stage, timeout monitoring, limited retries, and dynamic compensation mechanisms are introduced to effectively deal with sudden situations such as abnormal node response or link interruption in cross-border networks, ensuring reliable delivery of scheduling instructions and eventual consistency of system status. This process fully realizes a closed-loop end-to-end system, from predictive data to risk quantification, from rule matching to parameter calculation, and from instruction delivery to anomaly handling, significantly improving the accuracy, robustness, and adaptability of scheduling decisions to complex cross-border environments.

[0193] It should be further noted that this embodiment, after executing the target scheduling instruction, also includes a scheduling effect evaluation and closed-loop feedback mechanism, specifically including:

[0194] G101. After the target scheduling instruction is executed, continuously monitor the real-time quality parameters and traffic consumption parameters of each operator's link, and obtain the third-state time-series data within the first preset time period after the instruction is executed. The third-state time-series data includes the real-time latency value, real-time packet loss rate value, real-time bandwidth utilization value, real-time remaining traffic value, and real-time consumption rate value at each collection time point after the instruction is executed. For example, in this embodiment, after the 30-second handover delay ends, i.e., at 10:35:30, continuously monitor the link status for the next 5 minutes, collect data every 50 milliseconds, and generate the third-state time-series data, wherein the first... At the data collection time point 10:35:30.000, the STC real-time latency was 79ms, the real-time packet loss rate was 0.14%, the real-time bandwidth utilization was 61%, the real-time remaining traffic was 499.8GB, and the real-time consumption rate was 2.1MB / s. The AIS real-time latency was 89ms, the real-time packet loss rate was 0.24%, the real-time bandwidth utilization was 54%, the real-time remaining traffic was 319.5GB, and the real-time consumption rate was 1.7MB / s. The Unicom real-time latency was 188ms, the real-time packet loss rate was 0.95%, the real-time bandwidth utilization was 73%, the real-time remaining traffic was 119.2GB, and the real-time consumption rate was 4.3MB / s.

[0195] G102. Compare the third-state timing data with the expected targets in the target scheduling instruction, and calculate the scheduling effect deviation index. The expected targets include the expected traffic allocation ratio and expected quality requirements of each operator. For example, in this embodiment, the expected traffic allocation ratio set by the target scheduling instruction is STC: 0.50, AIS: 0.35, and China Unicom: 0.15. The expected quality requirements are: STC latency ≤ 82ms, packet loss rate ≤ 0.224%, bandwidth utilization ≤ 65%; AIS latency ≤ 95ms, packet loss rate ≤ 0.30%, bandwidth utilization ≤ 62%; and China Unicom latency ≤ 185ms, packet loss rate ≤ 0.9%, bandwidth utilization ≤ 70%. The actual traffic allocation ratio and actual quality indicators are calculated based on the time window of the third-state time-series data. For example, taking the data from the first 30 seconds after the instruction is executed, the actual traffic allocation ratio is calculated as STC: 0.48, AIS: 0.36, and China Unicom: 0.16. The actual quality indicators are: STC average latency 80ms, average packet loss rate 0.15%, average bandwidth utilization 62%; AIS average latency 91ms, average packet loss rate 0.26%, average bandwidth utilization 56%; and China Unicom average latency 190ms, average packet loss rate 1.0%, and average bandwidth utilization 74%. Calculation deviations: The absolute values ​​of the traffic allocation ratio deviations are STC|0.48-0.50|=0.02, AIS|0.36-0.35|=0.01, and China Unicom|0.16-0.15|=0.01; the quality deviations are: China Unicom latency exceeding 5ms, packet loss rate exceeding 0.1%, and bandwidth utilization exceeding 4%, while other operators are within the expected range.

[0196] G103. If the scheduling effect deviation index exceeds a preset tolerance threshold, a scheduling effect compensation mechanism is triggered, and a compensation scheduling instruction is regenerated. For example, in this embodiment, the tolerance threshold is set as follows: First, deviation index data between the actual and expected effects after multiple scheduling executions in the system's historical operation are collected. The deviation index is defined as the root mean square error between the actual traffic allocation ratio and the expected traffic allocation ratio. The deviation index values ​​of 5000 scheduling tasks over the past 30 days are statistically analyzed, and their distribution characteristics are calculated. The 80th percentile is taken as the initial benchmark value for the tolerance threshold, for example, 0.12. Simultaneously, combined with business satisfaction survey data, when the deviation index exceeds 0.15, the user complaint rate increases significantly. Therefore, the tolerance threshold is set to 0.15 to ensure that the deviation index is below this value in most normal scheduling scenarios, and subsequent adjustments or alarm actions are only triggered when the deviation exceeds an acceptable range. It should be noted that the statistical period of 30 days, the sample size of 5000 times, the 80th percentile of 0.12, and the allowable threshold of 0.15 are all exemplary configurations in this embodiment. In actual applications, they can be dynamically adjusted according to the business's sensitivity to scheduling accuracy and the distribution of historical data, and all belong to the equivalent implementation of this invention.

[0197] G104. Record the effect evaluation results of each scheduling and feed them back to the mapping rule base and the traffic pool dynamic scheduling model for dynamic updating of the mapping function and model parameters to achieve closed-loop optimization. For example, in this embodiment, the scheduling instruction, actual execution effect, deviation index and compensation result are stored in the scheduling log database. The historical scheduling data is statistically analyzed every Monday morning. If it is found that the target consumption rate threshold function k_control (confidence) corresponding to the "cost control" label causes the actual consumption rate to exceed the standard in multiple schedulings, the function parameters are adjusted, and 2.5MB / s+1.5MB / s(1-confidence) is corrected to 2.2MB / s+1.8MB / s(1-confidence). At the same time, the pure feature vector after deconvolution decoupling and the prediction deviation are used as training data to incrementally train the long short-term memory network and optimize the future prediction accuracy.

[0198] Example 2

[0199] Please see Figure 2 Another embodiment of the present invention provides a dynamic elastic scheduling method for cross-border traffic pools, comprising:

[0200] S1. Obtain first state time-series data generated by multiple operator link nodes, the first state time-series data including real-time quality parameters and traffic consumption parameters of each link;

[0201] S2. Based on the implicit scheduling intent of historical traffic data and business request text, generate a scheduling probe sequence, and perform a fusion calculation between the discrete probe values ​​in the scheduling probe sequence and the corresponding timestamp data values ​​in the first state time series data to generate the second state time series data.

[0202] S3. The second state timing data is sent to the cross-border traffic pool dynamic scheduling platform via the communication link;

[0203] S4. On the cross-border traffic pool dynamic scheduling platform, a reference demodulation sequence synchronized with the scheduling probe sequence is obtained. The reference demodulation sequence and the second state time series data are input into a preset traffic pool dynamic scheduling model, and the reconstructed time series data is output. The traffic pool dynamic scheduling model is used to decouple the time delay coupling relationship between parameters and predict the traffic consumption fluctuation caused by cross-domain routing convergence.

[0204] S5. Extract the operational feature vector from the reconstructed time-series data. The operational feature vector includes the probability of traffic overload risk and the comprehensive fluctuation value of link quality.

[0205] S6. In response to the running feature vector satisfying the preset cross-domain linkage scheduling conditions, a target scheduling instruction is generated and the target scheduling instruction is routed to the traffic execution node. The target scheduling instruction includes adjusting the traffic allocation ratio of each operator, switching delay time, or switching path to achieve flexible allocation and over-limit warning.

[0206] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments under the guidance of the present invention without departing from the spirit and scope of the present invention. All of these variations are within the protection scope of the present invention.

[0207] If the technical solution disclosed herein involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution disclosed herein involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

Claims

1. A cross-border traffic pool dynamic elastic scheduling system, characterized in that, include: The acquisition module is used to acquire the first state time series data generated by M operator link nodes. The first state time series data includes the real-time quality parameters and traffic consumption parameters of each link. The detection modulation module generates a scheduling detection sequence based on historical traffic data and the implicit scheduling intent of the service request text, and performs a fusion calculation on the discrete detection values ​​in the scheduling detection sequence and the corresponding timestamp data values ​​in the first state time series data to generate the second state time series data. The communication transmission module sends the second state timing data to the cross-border traffic pool dynamic scheduling platform via the communication link; The inversion analysis module obtains a reference demodulation sequence synchronized with the scheduling probe sequence on the cross-border traffic pool dynamic scheduling platform. It inputs the reference demodulation sequence and the second state time series data into a preset traffic pool dynamic scheduling model and outputs reconstructed time series data. The traffic pool dynamic scheduling model is used to decouple the time delay coupling relationship between parameters and predict the traffic consumption fluctuation caused by cross-domain routing convergence. The feature extraction module extracts the running feature vector from the reconstructed time series data. The running feature vector includes the probability of traffic overload risk and the comprehensive fluctuation value of link quality. The scheduling decision module, in response to the running feature vector satisfying the preset cross-domain linkage scheduling conditions, generates a target scheduling instruction and routes the target scheduling instruction to the traffic execution node. The target scheduling instruction includes adjusting the traffic allocation ratio of each operator, switching delay time, or switching path.

2. The cross-border traffic pool dynamic elastic scheduling system as described in claim 1, characterized in that, The generation of the scheduling probe sequence includes: Obtain historical traffic data from the first state time series data, wherein the historical traffic data includes a traffic consumption rate sequence and a link quality sequence of each operator's link in the past preset time period; Obtain the business request text, which contains business scheduling objectives expressed in an unstructured form; Semantic parsing is performed on the business request text to extract link quality constraint values ​​and cost constraint values ​​from the implicit information in the business request text. The link quality constraint values ​​are converted into target latency threshold, target packet loss rate threshold and target bandwidth utilization threshold through semantic mapping. The cost constraint values ​​are converted into target remaining traffic threshold and target consumption rate threshold through semantic mapping. Based on the target latency threshold, target packet loss rate threshold, and target bandwidth utilization threshold, historical time periods that meet the corresponding threshold conditions are retrieved from the link quality sequence, and the link quality values ​​of the corresponding time periods are extracted as quality benchmarks.

3. The cross-border traffic pool dynamic elastic scheduling system as described in claim 2, characterized in that, The generation of the scheduling probe sequence includes: Based on the target remaining flow threshold and the target consumption rate threshold, a flow consumption trend line is calculated from the flow consumption rate sequence, and the remaining flow depletion time threshold and instantaneous consumption rate upper limit are determined as cost warning lines. The quality benchmark and the cost warning line are used as modulation coefficients, and a weighted fusion operation is performed with the traffic consumption rate value and link quality value corresponding to the timestamp in the historical traffic data to generate a scheduling probe sequence. The scheduling probe sequence consists of discrete probe values, each probe value corresponds to a future time point and includes the expected traffic allocation ratio and expected quality requirements at the future time point.

4. The cross-border traffic pool dynamic elastic scheduling system as described in claim 3, characterized in that, The generation of the second state time series data includes: Obtain the expected traffic allocation weight set and expected quality threshold set corresponding to each future time point in the scheduling probe sequence. The expected traffic allocation weight set includes the traffic allocation weight of each operator at the corresponding future time point, and the expected quality threshold set includes the target latency threshold, target packet loss rate threshold, and target bandwidth utilization threshold of each operator at the corresponding future time point. Obtain the real-time quality parameter set and real-time consumption parameter set corresponding to each collection time point in the first state time series data. The real-time quality parameter set includes the real-time latency value, real-time packet loss rate value and real-time bandwidth utilization value of each operator at the current collection time point. The real-time consumption parameter set includes the real-time remaining traffic value and real-time consumption rate value of each operator at the current collection time point. Using each collection time point as a benchmark, find the future time point in the scheduling detection sequence that is greater than or equal to the collection time point and has the smallest time difference. Determine the expected traffic allocation weight set of the future time point as the associated weight set of the collection time point, and determine the expected quality threshold set of the future time point as the associated threshold set of the collection time point.

5. The cross-border traffic pool dynamic elastic scheduling system as described in claim 4, characterized in that, The generation of the second state time series data further includes: For each collection time point, the traffic allocation weights of each operator in the associated weight set are weighted and summed with the real-time consumption rate values ​​of the corresponding operator in the real-time consumption parameter set to obtain the traffic adjustment factor for the collection time point. For each collection time point, the target latency threshold, target packet loss rate threshold, and target bandwidth utilization rate threshold of each operator in the associated threshold set are respectively compared with the real-time latency value, real-time packet loss rate value, and real-time bandwidth utilization rate value of the corresponding operator in the real-time quality parameter set to obtain the quality deviation factor of the collection time point. The flow adjustment factor and the quality deviation factor are vector-concatenated with the real-time quality parameter set and the real-time consumption parameter set at the acquisition time point to generate the fusion feature vector at the acquisition time point. The fused feature vectors from all collected time points are arranged in chronological order to form the second-state time series data.

6. The cross-border traffic pool dynamic elastic scheduling system as described in claim 5, characterized in that, The step of sending the second state time-series data to the cross-border traffic pool dynamic scheduling platform via the communication link includes: Acquire the second state time series data, which consists of multiple fused feature vectors arranged in ascending order according to the acquisition time points; Each fused feature vector is assigned a monotonically increasing sequence number, which corresponds one-to-one with the position of the fused feature vector in ascending order, and is used to identify its temporal relationship. The second-state timing data carrying the sequence number is encrypted using a pre-shared encryption key to generate a ciphertext data packet; The encrypted data packet is divided into several data fragments, and each data fragment is marked with its offset and total length in the original encrypted data packet. The fragments are then sent in parallel to the cross-border traffic pool dynamic scheduling platform through at least two cross-border communication links.

7. The cross-border traffic pool dynamic elastic scheduling system as described in claim 6, characterized in that, The step of sending the second state time-series data to the cross-border traffic pool dynamic scheduling platform via the communication link further includes: On the cross-border traffic pool dynamic scheduling platform side, each data fragment is received, and the received data fragments are checked for integrity and reassembled according to the offset and total length to restore the complete encrypted data packet; The complete ciphertext data packet is decrypted using the decryption key corresponding to the encryption key to obtain second state timing data carrying a sequence number; The decrypted fused feature vectors are sorted according to the sequence number to recover the second state time-series data, which is consistent with the data sent from the transmitting end and arranged in ascending order of the acquisition time point.

8. The cross-border traffic pool dynamic elastic scheduling system as described in claim 7, characterized in that, The output reconstructed time-series data includes: Extract a copy of the scheduling probe sequence that is time-synchronized with the sender from the local cache, and use this copy as a reference demodulation sequence. The reference demodulation sequence contains a set of expected traffic allocation weights arranged in order of future time points, and each set of expected traffic allocation weights includes the traffic allocation weight of each operator at the corresponding future time point. Obtain the decrypted and reordered second-state time-series data. The second-state time-series data contains fused feature vectors arranged in order of acquisition time points. Each fused feature vector contains at least the flow adjustment factor and quality deviation factor at the current acquisition time point. Based on the time interval between adjacent future time points in the reference demodulation sequence, the standard delay duration for cross-domain routing convergence is determined. A delay convolution kernel is constructed based on the standard delay duration. The delay convolution kernel is a one-dimensional vector whose length is equal to the number of acquisition time points contained within the standard delay duration. The values ​​of each element in the vector are calculated based on the routing convergence attenuation model. The delay convolution kernel is convolved with the expected traffic allocation weight set in the reference demodulation sequence to generate a temporal delay coupling matrix, which is used to characterize the weight distribution of the delay impact of historical scheduling actions on the network state at the current moment.

9. The cross-border traffic pool dynamic elastic scheduling system as described in claim 8, characterized in that, The output reconstructed time-series data also includes: The time delay coupling matrix and the fused feature vector sequence within the corresponding time window in the second state time series data are input into the Wiener deconvolution filter. The Wiener deconvolution filter uses the time delay coupling matrix as the system transfer function to perform deconvolution operation on the fused feature vector sequence, stripping the time delay coupling component superimposed due to cross-domain routing convergence in the fused feature vector sequence, and outputting the decoupled pure feature vector sequence. The pure feature vector sequence is input into a pre-trained long short-term memory network. Based on the mapping relationship between historical pure feature vectors and future traffic fluctuations, the long short-term memory network outputs the predicted traffic consumption rate sequence and the predicted link quality sequence of each operator's link within a preset future time period, which serve as the reconstructed time series data.

10. The cross-border traffic pool dynamic elastic scheduling system as described in claim 9, characterized in that, The step of extracting the runtime feature vector from the reconstructed time-series data includes: The reconstructed time series data is obtained. The reconstructed time series data includes the predicted traffic consumption rate sequence and the predicted link quality sequence of M operator links within a future preset time period. The predicted link quality sequence includes the predicted latency value, the predicted packet loss rate value and the predicted bandwidth utilization value at each future time point. Obtain the current remaining traffic value for each operator link. For each operator link, accumulate the predicted traffic consumption rate sequence in chronological order to obtain the cumulative predicted consumption of the operator link at each future time point. For each future time point, calculate the ratio of the cumulative predicted consumption of each operator's link at that time point to its current remaining traffic value to obtain the consumption ratio matrix; Input each element in the consumption ratio matrix into a preset S-shaped function to obtain the instantaneous excess probability matrix of each operator's link at each future time point.

11. The cross-border traffic pool dynamic elastic scheduling system as described in claim 10, characterized in that, The step of extracting the runtime feature vector from the reconstructed time-series data further includes: The instantaneous excess probability matrix is ​​time-weighted and averaged according to the operator dimension to obtain the average excess probability of each operator link. Then, the average excess probabilities of all operator links are weighted and summed to obtain the traffic excess risk probability. For each operator link, based on its predicted link quality sequence, the variances of the predicted latency, predicted packet loss rate, and predicted bandwidth utilization are calculated respectively, and the three variances are weighted and summed to obtain the link quality fluctuation value of the operator link. The link quality fluctuation values ​​of all operator links are weighted and averaged to obtain the comprehensive link quality fluctuation value; The probability of excessive traffic risk and the comprehensive fluctuation value of link quality are combined into an operational feature vector.

12. A dynamic elastic scheduling method for cross-border traffic pools, implemented based on the dynamic elastic scheduling system for cross-border traffic pools as described in any one of claims 1-11, characterized in that, include: Acquire first state time-series data generated by multiple operator link nodes, the first state time-series data including real-time quality parameters and traffic consumption parameters of each link; Based on the implicit scheduling intent of historical traffic data and business request text, a scheduling probe sequence is generated, and the discrete probe values ​​in the scheduling probe sequence are fused with the corresponding timestamp data values ​​in the first state time series data to generate the second state time series data. The second state timing data is sent to the cross-border traffic pool dynamic scheduling platform via the communication link; In the cross-border traffic pool dynamic scheduling platform, a reference demodulation sequence synchronized with the scheduling probe sequence is obtained. The reference demodulation sequence and the second state time series data are input into a preset traffic pool dynamic scheduling model, and the reconstructed time series data is output. The traffic pool dynamic scheduling model is used to decouple the time delay coupling relationship between parameters and predict the traffic consumption fluctuation caused by cross-domain routing convergence. Extract the operational feature vector from the reconstructed time-series data. The operational feature vector includes the probability of traffic overload risk and the comprehensive fluctuation value of link quality. In response to the running feature vector satisfying the preset cross-domain linkage scheduling conditions, a target scheduling instruction is generated and routed to the traffic execution node. The target scheduling instruction includes adjusting the traffic allocation ratio of each operator, switching delay time, or switching path.

Images