SD-WAN application traffic dynamic scheduling method and system based on user experience prediction

Abstract

The application relates to the technical field of data communication networks, in particular to an SD-WAN application flow dynamic scheduling method and system based on user experience prediction. The method comprises the following steps: acquiring application service characteristics of a current application session, real-time network indexes and historical experience data of a plurality of candidate links, and associatively generating an application link state set; generating application detection parameters based on the application service characteristics, constructing a simulation detection flow and applying the simulation detection flow to the plurality of candidate links, and generating application layer link detection results; combining the application link state set, the historical experience data and the application layer link detection results to construct application experience quality prediction input characteristics, generating candidate link experience prediction results; determining a target link based on the prediction results and link switching constraints, and delivering an application flow switching strategy; collecting actual application experience data after switching to generate a prediction deviation, and updating a user experience prediction model or a scheduling rule. The application makes link detection, experience prediction and flow switching form a continuous processing closed loop.

Description

Technical Field

[0001] This invention relates to the field of data communication network technology, and in particular to a method for dynamic scheduling of SD-WAN application traffic based on user experience prediction. Background Technology

[0002] In the field of data communication network technology, existing solutions for software-defined wide area network (SDA) application traffic scheduling typically involve the collaboration of a SDA controller, edge nodes, candidate link monitoring components, and forwarding nodes. These solutions primarily collect real-time network metrics such as latency, packet loss rate, jitter, available bandwidth, and link utilization of candidate links. Combined with application type, service priority, or preset policies, they perform path selection, bandwidth allocation, link switching, or priority control for different service traffic. While such solutions can perform link quality monitoring and path scheduling in typical multi-link forwarding scenarios, they are prone to limitations in scenarios where application sessions coexist, such as video, gaming, voice, and file transfer. These limitations include mismatches between application service characteristics and link detection methods, insufficient alignment between network metrics and application experience status, and scheduling lags behind changes in application session status.

[0003] Existing solutions often rely on general network metrics of candidate links, fixed probe packets, application type matching rules, or link quality scores for processing. When the packet length distribution, sending interval, real-time requirements, bandwidth requirements, or latency requirements of the current application session change, there is a lack of stable correspondence between the general link probe results and the actual communication pattern of the current application session. When the candidate link status fluctuates within the prediction window, there is also a tendency for the link quality score to become disconnected from the subsequent target link selection, making it difficult for application traffic switching strategies to reflect the changing experience trends of the current application session on different candidate links.

[0004] Existing technologies still suffer from common shortcomings in the joint processing of current application sessions, multiple candidate links, real-time network metrics, and historical experience data. These shortcomings include insufficient participation of application service characteristics in link detection, inadequate integration of historical experience data with the link prediction process, and insufficient correlation between candidate link experience prediction results and application traffic switching strategies. Therefore, it is necessary to address the issue of how to generate candidate link experience prediction results based on application service characteristics, real-time network metrics of candidate links, and historical experience data, specifically for software-defined wide area network (SDWAN) multi-link application traffic scheduling scenarios. Summary of the Invention

[0005] This invention provides a method for dynamic scheduling of SD-WAN application traffic based on user experience prediction, comprising:

[0006] S100: Obtain the application service characteristics of the current application session, real-time network indicators and historical experience data of multiple candidate links, and generate an application link status set according to the application session identifier, candidate link identifier and prediction window association.

[0007] S200. Based on the application service characteristics in the application link state set, generate application detection parameters, construct a simulated detection flow according to the application detection parameters and apply it to the multiple candidate links to generate application layer link detection results.

[0008] S300: Construct QoE prediction input features based on the application link status set, the historical experience data and the application layer link detection results, and input the QoE prediction input features into the user experience prediction model to generate candidate link experience prediction results;

[0009] S400. Based on the candidate link experience prediction results and link switching constraints, determine the target link from the multiple candidate links and generate an application traffic switching strategy;

[0010] S500: The application traffic switching policy is sent to the SD-WAN forwarding node to control the traffic of the current application session to switch to the target link; the actual application experience data after the switch is collected, and the prediction deviation is generated by comparing it with the experience prediction result of the candidate link; the user experience prediction model or scheduling rule is updated according to the prediction deviation.

[0011] Furthermore, the application service characteristics include application type, session identifier, service priority, message length distribution, transmission interval, real-time requirements, bandwidth requirements, and latency requirements; the real-time network indicators include latency, packet loss rate, jitter, available bandwidth, link utilization, throughput, retransmission rate, and link availability status.

[0012] Furthermore, the step of generating an application link state set by associating the application session identifier, candidate link identifier, and prediction window includes: matching the application session identifier with the application service characteristics and the historical experience data to generate an application session state record; matching the candidate link identifier with the real-time network indicators to generate a candidate link state record; and associating the application session state record with the candidate link state record according to the prediction window to generate the application link state set.

[0013] Furthermore, the step of generating application detection parameters based on application service characteristics in the application link state set includes: determining the detection message length, detection sending interval, detection duration, burst mode, and target bandwidth according to the application type, message length distribution, sending interval, and real-time requirements; and combining the detection message length, the detection sending interval, the detection duration, the burst mode, and the target bandwidth to generate the application detection parameters.

[0014] Furthermore, the step of constructing a simulated probe stream according to the application probe parameters and applying it to the multiple candidate links includes: constructing a continuous throughput probe stream when the application type is a video application; constructing a small message high-frequency interaction probe stream when the application type is a game application; constructing a fixed-interval low bitrate probe stream when the application type is a voice application; and constructing a continuous throughput probe stream when the application type is a file transfer application.

[0015] Furthermore, the step of constructing QoE prediction input features based on the application link state set, the historical experience data, and the application layer link detection results includes: aligning the application link state set, the historical experience data, and the application layer link detection results according to the application session identifier, the candidate link identifier, and the prediction window to generate prediction input records; and assembling features from the prediction input records to generate the QoE prediction input features.

[0016] Furthermore, the candidate link experience prediction results include experience score, probability of experience degradation, risk of lag, risk of interaction delay, risk of voice interruption, and risk of application layer response anomaly; the candidate link experience prediction results are associated with the candidate link identifier.

[0017] Furthermore, the step of determining the target link from the plurality of candidate links and generating an application traffic switching strategy based on the candidate link experience prediction results and link switching constraints includes: comparing the candidate link experience prediction results with an application experience threshold to generate candidate link filtering results; determining the target link based on the candidate link filtering results, link switching constraints, switching costs, current bearer link status, and link availability status; and generating the application traffic switching strategy including the target link identifier, switching trigger conditions, switching window, strategy validity period, fallback link, and session persistence parameters.

[0018] Furthermore, updating the user experience prediction model or scheduling rules based on the prediction deviation includes: when the prediction deviation exceeds a deviation threshold, adjusting the sample weights, application experience threshold, application detection parameters, or scheduling rules of the user experience prediction model; when the actual application experience data does not reach the application experience threshold, generating a fallback strategy, and associating the actual application experience data, the candidate link experience prediction results, and the fallback strategy as model update samples.

[0019] This invention also provides a software-defined wide area network application traffic dynamic scheduling system based on user experience prediction, comprising:

[0020] The data acquisition module is used to acquire the application service characteristics of the current application session, real-time network indicators and historical experience data of multiple candidate links, and associate them according to the application session identifier, candidate link identifier and prediction window to generate an application link status set.

[0021] An active detection module, connected to the data acquisition module, is used to generate application detection parameters based on application service characteristics in the application link status set, construct a simulated detection flow according to the application detection parameters and apply it to the multiple candidate links to generate application layer link detection results.

[0022] The experience prediction module, connected to the active detection module, is used to construct application experience quality prediction input features based on the application link status set, the historical experience data and the application layer link detection results, and input the application experience quality prediction input features into the user experience prediction model to generate candidate link experience prediction results.

[0023] The scheduling decision module, connected to the experience prediction module, is used to determine the target link from the multiple candidate links based on the experience prediction results of the candidate links and the link switching constraints, and generate an application traffic switching strategy.

[0024] The policy execution module, connected to the scheduling decision module, is used to distribute the application traffic switching policy to the software-defined wide area network forwarding node and control the traffic of the current application session to switch to the target link.

[0025] The feedback update module connects the strategy execution module and the experience prediction module. It is used to collect actual application experience data after switching, compare the actual application experience data with the candidate link experience prediction results, generate prediction deviation, and update the user experience prediction model or scheduling rules according to the prediction deviation.

[0026] The technical effects of this invention are as follows:

[0027] (1) Establish a parameter mapping relationship between the application service characteristics of the current application session and the candidate link active detection process. Generate application detection parameters according to the application type, message length distribution, sending interval, real-time requirements, bandwidth requirements and latency requirements. Based on this, construct a simulated detection flow to act on multiple candidate links to form application layer link detection results corresponding to the communication form of the current application session.

[0028] (2) Assemble the application link status set, historical experience data and application layer link detection results according to the application session identifier, candidate link identifier and prediction window to form the application experience quality prediction input features, and generate the candidate link experience prediction results associated with the candidate link identifier by the user experience prediction model.

[0029] (3) The candidate link experience prediction results and link switching constraints are used together as the basis for target link selection to generate application traffic switching strategy. After switching, the actual application experience data is compared with the candidate link experience prediction results to form prediction deviation, so that the prediction deviation participates in the update of user experience prediction model or scheduling rules.

[0030] (4) To address the mismatch between the general link detection results and the current application session communication pattern, application detection parameters are generated through application service characteristics and a simulated detection flow is constructed so that the detection process of the candidate link corresponds to the message length, sending interval, real-time requirements and bandwidth requirements of the current application session, and application layer link detection results that can participate in subsequent experience prediction are obtained.

[0031] (5) To address the problem of insufficient connection between real-time network indicators and application experience status in existing solutions, the application link status set, historical experience data and application layer link detection results are assembled into application experience quality prediction input features, so that the candidate link experience prediction results can simultaneously reflect the current link status, application communication characteristics and historical experience records, thereby reducing the experience status deviation caused when path selection is based solely on link quality scores.

[0032] (6) To address the problem of insufficient correlation between application traffic switching strategy and candidate link experience change trend, the target link is determined by the candidate link experience prediction results and link switching constraints, and the prediction deviation is generated by using the actual application experience data after switching, so that the user experience prediction model or scheduling rules can obtain feedback basis in the subsequent prediction window, and reduce the situation where the prediction and actual experience are inconsistent in similar application sessions under similar link conditions. Attached Figure Description

[0033] Figure 1 A flowchart illustrating the dynamic scheduling method for SD-WAN application traffic based on user experience prediction provided in this application embodiment;

[0034] Figure 2 This is a structural block diagram of an SD-WAN application traffic dynamic scheduling system based on user experience prediction, provided in an embodiment of this application. Detailed Implementation

[0035] Example 1: Refer to Figure 1 This is a flowchart illustrating the dynamic scheduling method for SD-WAN application traffic based on user experience prediction provided in an embodiment of the present invention. The process may include at least steps S100-S500:

[0036] S100: Obtain the application service characteristics of the current application session, real-time network metrics and historical experience data of multiple candidate links, and generate an application link status set according to the application session identifier, candidate link identifier and prediction window association.

[0037] In this implementation, the SD-WAN (Software Defined Wide Area Network) controller connects to multiple SD-WAN edge nodes, which are deployed at branch offices, headquarters, or cloud access points. After the first batch of packets from the current application session arrives at the SD-WAN edge node, the edge node generates an application session identifier based on the five-tuple, application identifier, protocol type, domain name, port, traffic direction, and session persistence status, and reports this application session identifier to the SD-WAN controller. Upon receiving the session report, the SD-WAN controller reads its locally stored candidate link table, including the currently carrying link, backup links, and other links that can participate in forwarding within the candidate link range. The candidate link table stores candidate link identifiers, access node identifiers, egress node identifiers, and link availability status. Links that cannot participate in the forwarding of the current application session are not included in the subsequent association steps.

[0038] The application service characteristics of the current application session are extracted by the SD-WAN edge node from session packets and session statistics. The application type can be determined by deep packet inspection results, application identifier, protocol type, domain name, or port matching results. The session identifier is used to distinguish different sessions generated by the same terminal or the same application. Service priority can be derived from application policies issued by the SD-WAN controller. Packet length distribution and transmission interval are statistically obtained by the edge node within the sampling window after session establishment. Real-time requirements, bandwidth requirements, and latency requirements can be provided by the link requirement table corresponding to the application type. If the number of packets for the same session within the sampling window is insufficient, the edge node retains the already collected session identifier, application type, and service priority, and marks the packet length distribution and transmission interval as low-confidence. Subsequent steps will run according to the default probe parameters corresponding to the application type when constructing probe parameters.

[0039] Real-time network metrics for multiple candidate links are provided by SD-WAN edge nodes, link probes, or network device statistics interfaces. These metrics include latency, packet loss rate, jitter, available bandwidth, link utilization, throughput, retransmission rate, and link availability status. When reading real-time network metrics, the SD-WAN controller first checks if the candidate link identifier matches the current topology table. If a candidate link has been removed from the topology table or its availability status is unavailable, that candidate link is only retained in its status record and does not participate in target link selection. For real-time network metrics collected earlier than the current prediction window, the SD-WAN controller does not discard them directly but appends them as historical link status to the candidate link status record, avoiding gaps in candidate link status due to short collection intervals.

[0040] Historical experience data originates from the experience data storage area maintained by the SD-WAN controller. This historical experience data is associated with application type, candidate link identifier, historical network metrics, and historical application experience results. For video applications, historical experience data may include the number of stutters, buffer duration, and bitrate change records; for game applications, historical experience data may include interaction response latency and jitter status; for voice applications, historical experience data may include the number of voice interruptions and continuous packet loss status; for file transfer applications, historical experience data may include application layer response time and transmission completion status. In one implementation, if no historical experience data for the same application session is found, the SD-WAN controller queries similar historical experience data according to application type and link category; if similar historical experience data also does not exist, a historical experience missing identifier is generated and transmitted to S300 along with the application link status set, enabling the user experience prediction model to adopt missing handling rules when constructing QoE prediction input features.

[0041] The SD-WAN controller associates the above data according to the application session identifier, candidate link identifier, and prediction window. Specifically, it first matches the application session identifier with application service characteristics and historical experience data to form an application session state record; then, it matches the candidate link identifier with real-time network metrics to form a candidate link state record; finally, it associates the application session state record with multiple candidate link state records according to the prediction window to obtain a set of application link states for the current application session. The prediction window represents the time range for participating in experience prediction after the current moment, and its length can be determined by the application type and service priority. If there is a time conflict between the application session state record and the candidate link state record, the SD-WAN controller prioritizes the real-time network metric that falls closest to the starting boundary of the prediction window and appends the conflicting state to the corresponding candidate link state record.

[0042] Once the application link status set is formed, it is distributed by the SD-WAN controller to the proactive probing module and the experience prediction module. The proactive probing module mainly reads the application service characteristics, candidate link identifiers, and link availability status. The experience prediction module subsequently reads real-time network metrics, historical experience data, and prediction windows. For candidate links marked as unavailable, with abnormal probing, or lacking historical experience, the application link status set does not directly delete the corresponding record. Instead, it retains the status identifier in the record for S200 to make probing decisions and for S300 to construct input features.

[0043] S200. Based on the application service characteristics in the application link state set, generate application detection parameters, construct a simulated detection flow according to the application detection parameters, and apply it to the multiple candidate links to generate application layer link detection results:

[0044] After receiving the application link status set generated by S100, the active probing module first reads the application service characteristics of the current application session, and then generates a probing task based on the link availability status of candidate links. The probing task does not send fixed probe messages uniformly to all network links, but instead determines the application probe parameters based on the application type, message length distribution, sending interval, and real-time requirements of the current application session. This process ensures that the probing process of candidate links is consistent with the communication pattern of the current application session, avoiding situations where fixed probe messages cannot reflect the application layer transmission status.

[0045] Application probing parameters include probe message length, probe sending interval, probe duration, burst mode, and target bandwidth. When determining the probe message length, the active probing module prioritizes the message length distribution of the current application session within the sampling window; if the message length distribution is marked as low-confidence, it reads the default message length range corresponding to the application type. The probe sending interval is jointly determined by the application session's sending interval and real-time requirements; for application sessions with high real-time requirements, the probe sending interval should not be too long. The probe duration is determined based on the prediction window, and the probing process should be completed before the target link is selected; if there are many candidate links, the active probing module selects candidate links to participate in the probing according to service priority and link availability status; candidate links with an unavailable availability status do not send simulated probe streams.

[0046] In one implementation, video applications correspond to a continuous throughput probing stream. The active probing module constructs continuous transmission packets according to the target bandwidth and probing duration, and records throughput fluctuations and transmission interruption states during the probing process. Game applications correspond to a short-message high-frequency interaction probing stream. The active probing module constructs round-trip interaction packets according to a shorter probing transmission interval, and records round-trip latency, jitter, and sudden packet loss states. Voice applications correspond to a fixed-interval low-bitrate probing stream. The active probing module sends low-bitrate probing packets at fixed intervals, and records continuous packet loss and interval jitter states. File transfer applications correspond to a continuous throughput probing stream. The active probing module constructs continuous transmission packets according to the target bandwidth, and records effective throughput and transmission completion status. The above probing streams are determined by application probing parameters and do not change the service packet content of the current application session.

[0047] Simulated probe flows can be generated by the SD-WAN controller and then executed by the SD-WAN edge nodes, or they can be constructed locally by the edge nodes based on application probe parameters issued by the controller. Before sending a simulated probe flow, the edge node verifies the candidate link identifier and forwarding table entries; if a candidate link has not yet established a forwarding path, the edge node returns a link path missing status to the SD-WAN controller, and the active probe module does not send a probe flow to that candidate link. For simulated probe flows that have already been sent, the edge node collects probe receipts at the egress side or the peer edge node and associates the probe receipts with the candidate link identifier, probe task identifier, and application session identifier.

[0048] The application layer link probing results are formed by the probing receipts and the probing task status. The probing results may include application layer round-trip time, application layer packet loss status, application layer jitter status, effective throughput, consecutive packet loss segments, probing completion status, and probing confidence level. If a candidate link does not return a receipt within the probing duration, the active probing module marks the candidate link as a probing timeout link. If short-term jitter occurs during the probing process but the receipt is complete, the active probing module retains the original probing values ​​and adds a low confidence level flag. The low confidence level flag does not directly exclude candidate links, but rather participates in feature weighting or missing feature handling when the S300 constructs the QoE prediction input features.

[0049] After generating application-layer link detection results, the active detection module submits them to the experience prediction module. These application-layer link detection results maintain a correspondence with the application session identifier, candidate link identifier, and prediction window. For candidate links that were not detected, the active detection module generates an undetected state and retains the candidate link identifier. In S300, the experience prediction module can combine real-time network metrics and historical experience data to perform degradation prediction. Thus, the output of S200 provides application-layer link performance that aligns with the current application communication pattern while also preserving the processing boundaries for abnormal links in subsequent predictions.

[0050] S300: Construct QoE prediction input features based on the application link status set, the historical experience data, and the application layer link detection results; input the QoE prediction input features into the user experience prediction model to generate candidate link experience prediction results.

[0051] After receiving the application layer link probing results generated in S200, the experience prediction module reads the application link state set generated in S100 and aligns the fields according to the application session identifier, candidate link identifier, and prediction window. In this embodiment, QoE (Quality of Experience) represents the application layer experience state of the current application session under specified link conditions, and this state is characterized by collectable application experience data. The experience prediction module does not directly use a single latency or packet loss rate as prediction input; instead, it places the current link state, application communication characteristics, historical experience performance, and application layer probing results into the same prediction input record.

[0052] During field alignment, the experience prediction module first matches the application business features in the application link status set with the candidate link status records, and then inserts the application layer link detection results of the corresponding candidate link into the same prediction input record. If historical experience data contains records of the same application type and the same candidate link, the experience prediction module prioritizes calling that historical experience data; if only historical experience data of the same application type but different candidate links exists, the link difference identifier is written into the prediction input record; if historical experience data is missing, the experience prediction module retains the historical experience missing identifier in the prediction input record and processes it using the corresponding missing branch in the user experience prediction model. The status identifier in the prediction input record only participates in the model input and does not independently determine whether a candidate link is selected as the target link.

[0053] When assembling features from the predicted input records, the experience prediction module organizes the input according to the application session dimension, candidate link dimension, and prediction window dimension. The application session dimension includes application type, service priority, packet length distribution, sending interval, bandwidth requirement, and latency requirement; the candidate link dimension includes real-time network metrics and application layer link detection results; and the prediction window dimension is used to limit the time range corresponding to the prediction results. For probe timeout links, the experience prediction module does not directly replace the timeout time with a fixed extreme value. Instead, it inputs the probe timeout status, real-time network metrics, and historical experience data into the user experience prediction model, and the model outputs the corresponding candidate link experience prediction results.

[0054] The user experience prediction model can be deployed in an SD-WAN controller or in a scheduling platform that communicates with the SD-WAN controller. After receiving QoE prediction input features, the user experience prediction model generates candidate link experience prediction results for each candidate link. The candidate link experience prediction results are associated with candidate link identifiers and may include experience scores, experience degradation probability, stuttering risk, interaction latency risk, voice interruption risk, and application layer response anomaly risk. For video applications, the model output can focus on retaining stuttering risk and experience degradation probability; for game applications, the model output can focus on retaining interaction latency risk; and for voice applications, the model output can focus on retaining voice interruption risk. The output items may differ for different application types, but the correspondence between candidate link identifiers and prediction windows remains consistent.

[0055] In one implementation, the experience prediction module performs format verification on the output of the user experience prediction model. If a candidate link does not receive a candidate link experience prediction result, the experience prediction module marks the candidate link as a prediction anomaly link and provides an anomaly identifier to the scheduling decision module. If there is a rule conflict between the experience score output by the model and the probability of experience degradation (e.g., a high experience score and a high probability of experience degradation), the experience prediction module retains the original output and adds a conflict status, which is then filtered by S400 based on link switching constraints and application experience thresholds. The experience prediction module does not directly perform link switching in this step to avoid confusion between the processing boundaries of the prediction phase and the scheduling decision phase.

[0056] After the candidate link experience prediction results are generated, the experience prediction module sends them to the scheduling decision module. The sent content includes the application session identifier, candidate link identifier, prediction window, candidate link experience prediction results, and prediction anomalies. S400 will determine the target link based on these results and link switching constraints. The QoE prediction input features formed in S300 can also be retained in the model update cache and used as part of the model update samples after prediction bias is generated in S500.

[0057] S400. Based on the candidate link experience prediction results and link switching constraints, determine the target link from the multiple candidate links and generate an application traffic switching strategy:

[0058] After receiving the candidate link experience prediction results generated by S300, the scheduling decision module first confirms that the corresponding application session is still active. If the current application session has ended or the edge node reports a session timeout, the scheduling decision module stops selecting the target link for that session and retains the candidate link experience prediction results as a historical prediction record. If the current application session is still active, the scheduling decision module reads the link switching constraints, which may include application experience threshold, switching cost, switching suppression conditions, current bearer link status, link availability status, and fallback conditions.

[0059] The scheduling decision module compares the predicted experience of each candidate link with the application experience threshold to generate a candidate link selection result. The application experience threshold can be configured according to the application type. For example, video applications focus on the risk of stuttering and the probability of experience degradation, game applications focus on the risk of interaction latency, and voice applications focus on the risk of voice interruption. If the predicted experience of a candidate link does not meet the corresponding application experience threshold, the candidate link is marked as not meeting the experience conditions. If the prediction of a candidate link is abnormal but the real-time network indicators and application layer link detection results do not show obvious abnormalities, the scheduling decision module can retain the candidate link as a backup link, but will not prioritize it as the target link.

[0060] After the candidate link selection results are formed, the scheduling decision module continues to read the status of the current bearer link. If the experience prediction result of the candidate link corresponding to the current bearer link still meets the application experience threshold, and the difference between the prediction results of other candidate links and the current bearer link does not reach the switching trigger condition, the scheduling decision module maintains the current bearer link, does not generate a link switching action, and only generates a maintenance strategy. If the probability of experience degradation of the current bearer link exceeds the corresponding threshold, or the corresponding risk among stuttering risk, interaction delay risk, and voice interruption risk reaches the switching trigger condition, the scheduling decision module determines the target link from the candidate links that meet the experience conditions, combining the switching cost and the link availability status.

[0061] Once the target link is determined, the scheduling decision module generates an application traffic switching policy. This policy includes a target link identifier, switching trigger conditions, a switching window, a policy validity period, a fallback link, and session persistence parameters. The target link identifier points to the forwarding table entry or tunnel identifier of the SD-WAN forwarding node; the switching window limits the time range for policy execution; the policy validity period prevents expired policies from continuing to be executed after link status changes; the fallback link is used to perform a fallback when switching fails in the S500 or when the post-switching experience does not meet the application experience threshold; and the session persistence parameters ensure that the edge node maintains the forwarding context of the current application session during link switching.

[0062] If none of the candidate links meet the application experience threshold, the scheduling decision module does not force the selection of the link with the highest experience prediction result as the target link, but instead generates a degradation scheduling policy. The degradation scheduling policy can specify maintaining the current carrying link, reducing the switching frequency, enabling a fallback link, or waiting for the next prediction window to re-predict. In cases of conflicting link availability states, such as a candidate link having a good prediction result but its availability state being unavailable, the scheduling decision module uses the link availability state as a constraint boundary and does not select that link as the target link. These abnormal branches are sent to the policy execution module along with the application traffic switching policy, giving the policy execution module a clear execution boundary within the S500.

[0063] After the application traffic switching policy is generated, the scheduling decision module associates the policy with the application session identifier, the current bearer link identifier, and the target link identifier, and sends it to the policy execution module. The policy execution module only receives policies that have already been processed by link switching constraints and does not recalculate the candidate link experience prediction results. In this way, S400 transforms the prediction results into an executable link switching control object and provides a target link benchmark for policy issuance, switching execution, and feedback comparison in S500.

[0064] S500: The application traffic switching policy is distributed to the SD-WAN forwarding node to control the traffic of the current application session to switch to the target link; the actual application experience data after the switch is collected, and compared with the experience prediction results of the candidate link to generate a prediction deviation; the user experience prediction model or scheduling rule is updated according to the prediction deviation.

[0065] After receiving the application traffic switching policy generated by S400, the policy execution module first verifies the policy validity period, target link identifier, and current application session status. If the policy has expired, the policy execution module returns an expired status to the scheduling decision module and does not execute the link switching. If the current application session is still active and the target link is available, the policy execution module distributes the application traffic switching policy to the corresponding SD-WAN forwarding node. The SD-WAN forwarding node can be a branch-side edge node, a headquarters-side edge node, or a cloud access-side edge node, specifically determined by the entry point location and target link location of the current application session.

[0066] After receiving the application traffic switching policy, the SD-WAN forwarding node reads the target link identifier, switching window, and session persistence parameters. Within the switching window, the forwarding node updates the forwarding table entries or tunnel selection status of the current application session, switching subsequent traffic of the current application session to the target link. For packets already en route to the current bearer link, the forwarding node can continue forwarding along the original path according to the session persistence parameters; for new packets after the switching window begins, the forwarding node forwards them according to the target link. If the forwarding table entry corresponding to the target link does not exist, the forwarding node returns a path missing status, and the policy execution module calls the fallback link in the application traffic switching policy or requests the scheduling decision module to regenerate the policy.

[0067] After the handover is completed, the SD-WAN forwarding node will return an execution receipt to the policy execution module. The execution receipt includes the application session identifier, target link identifier, execution time, handover status, and exception status. If the execution receipt indicates a handover failure, the feedback update module associates the policy execution result with the candidate link experience prediction result as an exception sample and generates a fallback execution request based on the fallback link in the application traffic handover policy. If the execution receipt indicates a successful handover, the feedback update module collects actual application experience data within the observation window after the handover. The observation window can be the same as the prediction window in the S300, or it can be configured to have a sampling time shorter than the prediction window, depending on the application type.

[0068] Real-world application experience data is provided by SD-WAN forwarding nodes, terminal probes, or application-side quality records. For video applications, this data may include the number of stutters, buffer duration, and bitrate variation; for gaming applications, it may include interaction response latency and jitter; for voice applications, it may include the number of voice interruptions and continuous packet loss; and for file transfer applications, it may include application layer response time and transmission completion status. When collecting real-world application experience data, the feedback update module first verifies the application session identifier and target link identifier to avoid writing experience data from other sessions or other links into the current model update sample. If the application session ends before the observation window begins after a switch, the feedback update module marks this data as an incomplete observation sample.

[0069] The feedback update module compares the actual application experience data with the candidate link experience prediction results for the corresponding target link in S300, generating a prediction bias. For experience scores, the prediction bias can be represented by the difference between the actual experience score and the predicted experience score; for experience degradation probability, stuttering risk, interaction delay risk, voice interruption risk, and application layer response anomaly risk, the prediction bias can be represented by the difference between the actual occurrence state and the predicted risk level. If the prediction bias does not exceed the bias threshold, the feedback update module saves the sample as a normal feedback sample. If the prediction bias exceeds the bias threshold, the feedback update module adjusts the sample weights, application experience thresholds, application detection parameters, or scheduling rules of the user experience prediction model.

[0070] When the actual application experience data fails to reach the application experience threshold, the feedback update module generates a fallback strategy. The fallback strategy can reuse the fallback links included in the application traffic switching strategy in S400, or it can request the scheduling decision module to re-determine the target link under the current candidate link status. After the fallback strategy is generated, the strategy execution module executes the fallback according to the current application session status; if the current application session has ended, the fallback strategy is no longer issued, and only the actual application experience data, candidate link experience prediction results, and fallback strategy are associated as model update samples. The model update samples retain the application session identifier, candidate link identifier, prediction window, QoE prediction input features, candidate link experience prediction results, actual application experience data, and prediction bias, for use in subsequent prediction model updates or scheduling rule corrections.

[0071] In subsequent scheduling cycles, the updated user experience prediction model or scheduling rules are continued to be called by S300 and S400. If a certain type of application continuously experiences prediction deviations exceeding the deviation threshold under a specific link state, the feedback update module can increase the weight of the corresponding model update sample and adjust the application experience threshold or application detection parameters corresponding to that application type. If a target link continuously triggers the fallback policy, the SD-WAN controller can add the fallback status to the candidate link status record, so that S400 reads this status when selecting the target link in the next prediction window. Thus, the feedback generated by S500 is not just an execution result record, but enters the next round of application link status association, QoE prediction, and target link selection process.

[0072] Example 2: Figure 2 A structural block diagram of an SD-WAN application traffic dynamic scheduling system based on user experience prediction according to an embodiment of the present invention is shown. Figure 2 As shown, the structure may include:

[0073] Data acquisition module 01 is used to acquire application service characteristics of the current application session, real-time network indicators of multiple candidate links, and historical experience data. It associates these with application session identifiers, candidate link identifiers, and prediction windows to generate an application link status set. During system operation, the data acquisition module connects to the software-defined wide area network (SDWAN) controller, the SWAN edge node, and the historical experience data storage area. After the current application session enters the SWAN edge node, the data acquisition module reads the session identifier, application type, packet length distribution, transmission interval, service priority, bandwidth requirement, and latency requirement reported by the edge node, and uses this information as the application service characteristics of the current application session. For multiple candidate links, the data acquisition module reads latency, packet loss rate, jitter, available bandwidth, link utilization, throughput, retransmission rate, and link availability status from link probes, edge node statistical interfaces, or the link status table maintained by the controller, and binds these real-time network indicators with the candidate link identifiers.

[0074] Historical experience data is provided by the historical experience data storage area in the software-defined wide area network controller. When reading historical experience data, the data acquisition module first searches for historical experience records of the same session based on the application session identifier. If no record of the same session is found, it searches for historical experience records under the same or similar application scenarios based on application type, service priority, and candidate link identifier. If historical experience data is missing, the data acquisition module does not stop the subsequent processing of the current application session, but adds the historical experience missing status to the corresponding record, so that the subsequent experience prediction module adopts the missing data handling rules when constructing the input features for application experience quality prediction.

[0075] The data acquisition module associates application service characteristics, real-time network metrics, and historical experience data according to the application session identifier, candidate link identifier, and prediction window. The application session identifier is used to bind the application service characteristics and historical experience data of the current application session; the candidate link identifier is used to bind the real-time network metrics of each candidate link; and the prediction window is used to limit the time range corresponding to the associated data. If the candidate link status changes within the prediction window, the data acquisition module prioritizes retaining the valid real-time network metric closest to the start time of the prediction window and writes the status change into the candidate link status. The final application link status set includes both the application session status and the candidate link status and is output to the active detection module and the experience prediction module. The active detection module reads the application service characteristics and candidate link status, while the experience prediction module reads the real-time network metrics, historical experience data, and prediction window from the application link status set.

[0076] The active detection module 02, connected to the data acquisition module, is used to generate application detection parameters based on application service characteristics in the application link status set, construct a simulated detection stream according to the application detection parameters, and apply it to the multiple candidate links to generate application layer link detection results. After receiving the application link status set output by the data acquisition module, the active detection module first reads the application type, message length distribution, sending interval, real-time requirements, bandwidth requirements, and latency requirements corresponding to the current application session, and then checks the link availability status of the candidate links. Candidate links with an unavailable link availability status do not enter the simulated detection stream sending branch, but their candidate link identifiers are retained in the application layer link detection results for subsequent experience prediction modules to identify the reasons for non-detection.

[0077] The active probing module generates application probing parameters based on application service characteristics. For application sessions with complete message length distributions, the probe message length is selected according to the message length distribution of the current application session; for application sessions with incomplete message length distributions, the probe message length is selected according to the default configuration corresponding to the application type. The probe sending interval is jointly determined by the sending interval and real-time requirements, the probe duration corresponds to the prediction window, and the burst mode and target bandwidth are jointly configured by the application type and bandwidth requirements. After generating the application probing parameters, the active probing module constructs a simulated probe flow and applies the simulated probe flow to multiple candidate links through software-defined wide area network edge nodes.

[0078] In one implementation, video applications correspond to a continuous throughput probing stream, where the active probing module constructs continuous transmission packets based on the target bandwidth and probing duration; game applications correspond to a short-message high-frequency interaction probing stream, where the active probing module constructs round-trip interaction packets based on a shorter sending interval; voice applications correspond to a fixed-interval low-bitrate probing stream, where the active probing module sends low-bitrate packets at fixed intervals; and file transfer applications correspond to a continuous throughput probing stream, where the active probing module constructs continuous transmission packets based on the target bandwidth. After the simulated probing stream is applied to candidate links, edge nodes return probing receipts. The active probing module associates the probing receipts with the application session identifier, candidate link identifier, and probing task status to form application-layer link probing results. If the probing receipt times out, the active probing module writes the corresponding candidate link into the probing timeout state; if the probing receipt is complete but the fluctuation state exceeds the probing stability boundary, the original probing value is retained and written into the low-confidence state. The application-layer link probing results are output to the experience prediction module to participate in the construction of subsequent application experience quality prediction input features.

[0079] The experience prediction module 03, connected to the active detection module, is used to construct application experience quality prediction input features based on the application link status set, the historical experience data, and the application layer link detection results. These input features are then input into the user experience prediction model to generate candidate link experience prediction results. The experience prediction module simultaneously receives the application link status set output by the data acquisition module and the application layer link detection results output by the active detection module. Application experience quality represents the application layer experience status of the current application session within a specified candidate link and prediction window. Its input is not composed of a single link quality indicator but rather of application service characteristics, real-time network indicators, historical experience data, and application layer link detection results.

[0080] The experience prediction module aligns the input data according to the application session identifier, candidate link identifier, and prediction window. Application service features in the application link state set represent the communication pattern of the current application session; real-time network metrics represent the network state of candidate links; historical experience data represents experience records of similar applications or links under similar states; and application layer link detection results represent the application layer performance of candidate links under simulated probe flows. For candidate links with missing historical experience data or low-confidence application layer link detection results, the experience prediction module retains the missing or low-confidence states and uses them as components of the application experience quality prediction input features, rather than replacing the original states with fixed values.

[0081] When constructing the application experience quality prediction input features, the experience prediction module first generates prediction input records corresponding to candidate link identifiers, then assembles features from the prediction input records, and inputs the assembled application experience quality prediction input features into the user experience prediction model. The user experience prediction model generates candidate link experience prediction results for each candidate link. These results are associated with the candidate link identifier and include experience score, probability of experience degradation, risk of stuttering, risk of interaction delay, risk of voice interruption, or risk of application layer response anomalies. If the user experience prediction model does not return a prediction result for a candidate link, the experience prediction module retains the candidate link identifier and writes a prediction anomaly status. Subsequently, it sends the generated candidate link experience prediction results and the prediction anomaly status together to the scheduling decision module, which then performs subsequent processing based on link switching constraints.

[0082] The scheduling decision module 04, connected to the experience prediction module, is used to determine the target link from the multiple candidate links based on the candidate link experience prediction results and link switching constraints, and generate an application traffic switching strategy. After receiving the candidate link experience prediction results output by the experience prediction module, the scheduling decision module first reads the activity status of the current application session and the status of the current carrying link. If the current application session has ended, the scheduling decision module will not generate an application traffic switching strategy and will retain the candidate link experience prediction results as historical prediction records. If the current application session is active, the scheduling decision module reads the link switching constraints and filters and selects from the multiple candidate links.

[0083] The link switching constraints include application experience threshold, switching cost, switching suppression condition, current bearer link status, link availability status, and fallback condition. The scheduling decision module compares the candidate link experience prediction results with the application experience threshold to obtain candidate link selection results. For candidate links with abnormal predictions but normal link availability status, the scheduling decision module retains them as alternative links. For candidate links with unavailable link availability status, even if the corresponding candidate link experience prediction result meets the application experience threshold, it is not determined as a target link. If the current bearer link still meets the application experience threshold and the switching cost is higher than the switching trigger condition, the scheduling decision module generates a strategy to maintain the current bearer link; if the current bearer link does not meet the application experience threshold, the target link is determined from the candidate link selection results.

[0084] When generating an application traffic switching policy, the scheduling decision module writes the target link identifier, switching trigger condition, switching window, policy validity period, fallback link, and session persistence parameters into the same policy object. If multiple candidate links meet the application experience threshold, the scheduling decision module determines the target link based on the switching cost, current bearer link status, and link availability. If no candidate link meets the application experience threshold, the scheduling decision module generates a policy object that includes either a fallback link or maintains the current bearer link. The application traffic switching policy is output to the policy execution module, which performs subsequent forwarding control according to the target link identifier and switching window in the policy object.

[0085] The policy execution module 05, connected to the scheduling decision module, is used to distribute the application traffic switching policy to the software-defined wide area network (SDWAN) forwarding node, controlling the traffic of the current application session to switch to the target link. After receiving the application traffic switching policy output by the scheduling decision module, the policy execution module first verifies the policy validity period, the current application session status, and the target link identifier. If the policy validity period has expired, the policy execution module returns a policy expired status and does not issue forwarding control. If the current application session is still active and the forwarding table entry corresponding to the target link exists, the policy execution module distributes the application traffic switching policy to the corresponding SWAN forwarding node.

[0086] After receiving the application traffic switching policy, the software-defined WAN forwarding node reads the target link identifier, switching window, and session persistence parameters, and adjusts the forwarding table entries or tunnel selection status of the current application session within the switching window. For packets already en route to the current bearer link, the software-defined WAN forwarding node completes the original path forwarding according to the session persistence parameters; for new packets after the switching window begins, the software-defined WAN forwarding node forwards them according to the target link. If the forwarding table entry corresponding to the target link does not exist, the policy execution module receives the path missing status and executes a fallback according to the fallback link in the application traffic switching policy, or returns the path missing status to the scheduling decision module to regenerate the policy.

[0087] After the traffic switching is completed, the policy execution module receives execution feedback from the software-defined WAN forwarding node. The execution feedback includes the application session identifier, target link identifier, execution time, switching status, and exception status. The policy execution module sends the execution feedback to the feedback update module, which determines whether to proceed with the actual application experience data collection process based on this feedback. If the switching status is a failure, the policy execution module does not continue to repeatedly issue the same application traffic switching policy, but instead executes subsequent control based on the new policy returned by the fallback link or scheduling decision module.

[0088] The feedback update module 06, connected to the strategy execution module and the experience prediction module, is used to collect actual application experience data after the switch, compare the actual application experience data with the candidate link experience prediction results, generate a prediction deviation, and update the user experience prediction model or scheduling rules based on the prediction deviation. After receiving the execution feedback from the strategy execution module, the feedback update module determines the feedback processing branch based on the switch status. When the switch status is successful, the feedback update module collects actual application experience data within the observation window; when the switch status is unsuccessful, the feedback update module associates the execution feedback, the target link identifier, and the candidate link experience prediction results as an abnormal sample and feeds back the abnormal status to the scheduling decision module or the strategy execution module.

[0089] Actual application experience data comes from software-defined wide area network (SDWAN) forwarding nodes, terminal probes, or application-side quality records. For video applications, this data includes the number of stutters, buffering time, or bitrate changes; for games, it includes interaction response latency or jitter; for voice applications, it includes the number of voice interruptions or continuous packet loss; and for file transfer applications, it includes application layer response time or transmission completion status. When collecting actual application experience data, the feedback update module verifies the data source based on the application session identifier and target link identifier. If the actual application experience data does not match the current application session, the data is excluded from the current prediction deviation calculation.

[0090] The feedback update module reads the candidate link experience prediction results corresponding to the target link identifier from the experience prediction module, and compares the actual application experience data with the candidate link experience prediction results to generate a prediction deviation. If the prediction deviation does not exceed the deviation threshold, the feedback update module saves the data as a normal feedback sample; if the prediction deviation exceeds the deviation threshold, the feedback update module adjusts the sample weights, application experience threshold, application detection parameters, or scheduling rules of the user experience prediction model according to the prediction deviation. If the actual application experience data does not reach the application experience threshold, the feedback update module generates a fallback strategy and hands it over to the strategy execution module for processing. The updated user experience prediction model or scheduling rules continue to be called by the experience prediction module and the scheduling decision module in subsequent prediction windows, forming a feedback flow consistent with the connection relationship of the aforementioned modules.

Claims

1. A method for dynamic scheduling of SD-WAN application traffic based on user experience prediction, characterized in that, include: S100: Obtain the application service characteristics of the current application session, real-time network indicators and historical experience data of multiple candidate links, and generate an application link status set according to the application session identifier, candidate link identifier and prediction window association. S200. Based on the application service characteristics in the application link state set, generate application detection parameters, construct a simulated detection flow according to the application detection parameters and apply it to the multiple candidate links to generate application layer link detection results. S300: Construct QoE prediction input features based on the application link status set, the historical experience data and the application layer link detection results, and input the QoE prediction input features into the user experience prediction model to generate candidate link experience prediction results; S400. Based on the candidate link experience prediction results and link switching constraints, determine the target link from the multiple candidate links and generate an application traffic switching strategy; S500: The application traffic switching policy is sent to the SD-WAN forwarding node to control the traffic of the current application session to switch to the target link; the actual application experience data after the switch is collected, and the prediction deviation is generated by comparing it with the experience prediction result of the candidate link; the user experience prediction model or scheduling rule is updated according to the prediction deviation.

2. The method for dynamic scheduling of SD-WAN application traffic based on user experience prediction according to claim 1, characterized in that, The application service characteristics include application type, session identifier, service priority, message length distribution, transmission interval, real-time requirements, bandwidth requirements, and latency requirements; the real-time network indicators include latency, packet loss rate, jitter, available bandwidth, link utilization, throughput, retransmission rate, and link availability status.

3. The method for dynamic scheduling of SD-WAN application traffic based on user experience prediction according to claim 1, characterized in that, The step of generating an application link state set by associating application session identifiers, candidate link identifiers, and prediction windows includes: matching the application session identifier with the application service characteristics and the historical experience data to generate an application session state record; matching the candidate link identifier with the real-time network indicators to generate a candidate link state record; and associating the application session state record with the candidate link state record according to the prediction window to generate the application link state set.

4. The SD-WAN application traffic dynamic scheduling method based on user experience prediction according to claim 1, characterized in that, The step of generating application detection parameters based on application service characteristics in the application link state set includes: determining the detection message length, detection sending interval, detection duration, burst mode, and target bandwidth according to the application type, message length distribution, sending interval, and real-time requirements; and combining the detection message length, the detection sending interval, the detection duration, the burst mode, and the target bandwidth to generate the application detection parameters.

5. The SD-WAN application traffic dynamic scheduling method based on user experience prediction according to claim 4, characterized in that, The step of constructing a simulated probe stream according to the application probe parameters and applying it to the multiple candidate links includes: constructing a continuous throughput probe stream when the application type is a video application; constructing a small message high-frequency interaction probe stream when the application type is a game application; constructing a fixed-interval low bitrate probe stream when the application type is a voice application; and constructing a continuous throughput probe stream when the application type is a file transfer application.

6. The method for dynamic scheduling of SD-WAN application traffic based on user experience prediction according to claim 1, characterized in that, The step of constructing QoE prediction input features based on the application link state set, the historical experience data, and the application layer link detection results includes: aligning the application link state set, the historical experience data, and the application layer link detection results according to the application session identifier, the candidate link identifier, and the prediction window to generate prediction input records; and assembling features from the prediction input records to generate the QoE prediction input features.

7. The method for dynamic scheduling of SD-WAN application traffic based on user experience prediction according to claim 1, characterized in that, The candidate link experience prediction results include experience score, probability of experience degradation, risk of lag, risk of interaction delay, risk of voice interruption, and risk of application layer response anomaly; the candidate link experience prediction results are associated with the candidate link identifier.

8. The method for dynamic scheduling of SD-WAN application traffic based on user experience prediction according to claim 1, characterized in that, The step of determining the target link from the multiple candidate links based on the candidate link experience prediction results and link switching constraints, and generating an application traffic switching strategy, includes: comparing the candidate link experience prediction results with an application experience threshold to generate candidate link filtering results; determining the target link based on the candidate link filtering results, link switching constraints, switching costs, current bearer link status, and link availability status; and generating the application traffic switching strategy that includes a target link identifier, switching trigger conditions, switching window, strategy validity period, fallback link, and session persistence parameters.

9. The method for dynamic scheduling of SD-WAN application traffic based on user experience prediction according to claim 1, characterized in that, The step of updating the user experience prediction model or scheduling rule based on the prediction deviation includes: when the prediction deviation exceeds the deviation threshold, adjusting the sample weights, application experience threshold, application detection parameters, or scheduling rules of the user experience prediction model; when the actual application experience data does not reach the application experience threshold, generating a fallback strategy, and associating the actual application experience data, the candidate link experience prediction results, and the fallback strategy as model update samples.

10. A dynamic traffic scheduling system for SD-WAN applications based on user experience prediction, applied to the method of any one of claims 1 to 9, characterized in that, include: The data acquisition module is used to acquire the application service characteristics of the current application session, real-time network indicators and historical experience data of multiple candidate links, and associate them according to the application session identifier, candidate link identifier and prediction window to generate an application link status set. An active detection module, connected to the data acquisition module, is used to generate application detection parameters based on application service characteristics in the application link status set, construct a simulated detection flow according to the application detection parameters and apply it to the multiple candidate links to generate application layer link detection results. The experience prediction module, connected to the active detection module, is used to construct application experience quality prediction input features based on the application link status set, the historical experience data and the application layer link detection results, and input the application experience quality prediction input features into the user experience prediction model to generate candidate link experience prediction results. The scheduling decision module, connected to the experience prediction module, is used to determine the target link from the multiple candidate links based on the experience prediction results of the candidate links and the link switching constraints, and generate an application traffic switching strategy. The policy execution module, connected to the scheduling decision module, is used to distribute the application traffic switching policy to the software-defined wide area network forwarding node and control the traffic of the current application session to switch to the target link. The feedback update module connects the strategy execution module and the experience prediction module. It is used to collect actual application experience data after switching, compare the actual application experience data with the candidate link experience prediction results, generate prediction deviation, and update the user experience prediction model or scheduling rules according to the prediction deviation.

Images