A large model-based deterministic network traffic quality of service identification method

Abstract

The application discloses a kind of certainty network traffic service quality identification methods based on large model, belong to network traffic processing technical field, by introducing large model inference ability, in combination with traffic feature, business semantics and network context information, realize the automatic, semantic and structured identification of traffic QoS demand, support incremental update under dynamic network environment, improve the accuracy of QoS configuration and system overall operation efficiency.The method of the application comprises the following steps: step 1, collect information, generate a unified structured traffic representation;Step 2, according to the structured traffic representation, extract the semantic attributes of the target service flow, and construct a unified semantic description;Step 3, construct a reference flow library, and select a matching reference flow set related to the target service flow from the reference flow library according to the semantic description of the target service flow;Step 4, infer the service quality requirements of the target service flow based on the large model, and generate the QoS parameters corresponding to the target flow.

Description

Technical Field

[0001] This invention belongs to the field of network traffic processing technology, specifically relating to a deterministic network traffic quality of service identification method based on a large model. Background Technology

[0002] With the development of Time-Sensitive Networking (TSN) and Deterministic Networking, network services are increasingly demanding higher levels of end-to-end latency, jitter, and reliability. In existing technologies, the Quality of Service (QoS) requirements for network traffic typically rely on manual analysis and configuration, which is ill-suited to large-scale, dynamically changing network environments. This presents the following main technical problems: First, there is a lack of automated mechanisms for identifying traffic quality of service (QoS) requirements. Existing methods are mainly based on static rules or manual configuration, pre-setting QoS parameters according to service type. They cannot automatically infer the true service requirements from the multi-dimensional characteristics of traffic (such as periodicity, packet length, and communication mode). In complex industrial networks or cross-domain network environments, the semantic differences between different service flows are significant, and a single rule is insufficient to accurately characterize their QoS requirements, leading to unreasonable QoS configuration.

[0003] Secondly, there is a lack of effective mapping between traffic semantics and QoS requirements. Existing technologies often separate traffic identification from scheduling configuration, that is, first identifying traffic types through simple classification methods, and then specifying QoS parameters manually or through predefined policies. This approach cannot establish a correlation model between traffic characteristics, service semantics, and QoS indicators, resulting in a lack of basis for QoS settings and making it difficult to support fine-grained scheduling and optimization.

[0004] Secondly, there is a lack of QoS inference capabilities that incorporate network context information. In actual network operation, factors such as link load, topology, and device status significantly impact traffic service demands. However, existing methods typically ignore network context and process traffic solely based on its inherent characteristics, failing to dynamically reflect the impact of network environment changes on QoS requirements, thus affecting overall scheduling efficiency and resource utilization.

[0005] Furthermore, existing methods struggle to adapt to the continuous optimization needs of dynamic network environments. When network conditions change or some traffic fails to meet QoS requirements, traditional methods often require reanalysis and reconfiguration of all traffic, resulting in high computational overhead and low response efficiency, making it difficult to meet real-time or near-real-time optimization needs. Summary of the Invention

[0006] To overcome the shortcomings of existing technologies, this invention aims to provide a deterministic network traffic QoS identification method based on a large model. By introducing the reasoning capability of a large model and combining traffic characteristics, business semantics, and network context information, it achieves automated, semantic, and structured identification of traffic QoS requirements and supports incremental updates in dynamic network environments, thereby improving the accuracy of QoS configuration and the overall system operating efficiency.

[0007] To achieve the above objectives, the present invention may adopt the following specific technical solutions: The aforementioned deterministic network traffic quality of service identification method based on a large model includes the following steps: Step 1: Collect basic information, topology information, and network service background information of the service flow to be identified from the deterministic network, and preprocess the collected raw data to generate a unified structured traffic representation; Step 2: Based on the structured traffic representation obtained in Step 1, extract the semantic attributes of the target business flow, construct a unified semantic description, and map from "traffic numerical features" to "business semantic features". Step 3: Construct a reference flow library and select a set of matching reference flows related to the target service flow from the reference flow library based on the semantic description of the target service flow, so as to provide empirical samples, boundary parameters and semantic mapping basis for subsequent QoS inference; Step 4: Based on the large model, reason about the service quality requirements of the target business flow and generate the QoS parameters corresponding to the target flow; the reasoning modes include three types: direct matching processing, chain of thought (CoT) and multi-path reasoning (Forest of Thought (FoT).

[0008] Furthermore, in step 1, the service flow data is acquired through the network monitoring module, the mirror port of the switching device interface, the controller log interface, or the packet collection device; data collection is performed according to a preset monitoring cycle and configured according to the network scale, service type, and scheduling accuracy requirements; wherein, the collected data includes at least basic traffic attributes, topology information, and network service background information, and the monitoring cycle is 1 ms to 1000 ms (milliseconds), which represents the time interval for collecting and updating the status of network service flows, and is not equivalent to the sending cycle of the service flow itself.

[0009] Furthermore, in step 2, the structured traffic representation includes at least fields such as period, transmission interval sequence, source node, destination node, protocol type, topology information, network service type, application scenario information, and device role information; the semantic description includes at least service type, behavior pattern, communication pattern, and service importance.

[0010] Furthermore, the specific content of step 2 includes: Step 2.1, Behavioral Pattern Recognition: Used to describe the transmission characteristics of the target service flow in the time dimension; the target service flow is divided into periodic flow, burst flow, or continuous flow; Step 2.2, Communication Pattern Recognition: This describes the source-destination relationship of the target service flow in the network; based on the mapping relationship between the source node and the destination node, the communication pattern is classified into unicast, multicast, or broadcast. Step 2.3, Business Type Determination: This step is used to characterize the business semantic category of the target business flow. Business type determination is based on a combination of rule base, protocol features, node type, behavior pattern, and network service background information. Business types include at least control type, monitoring type, and ordinary data type. Step 2.4, Business Importance Determination: Business importance is divided into high-importance business flows, medium-importance business flows, and low-importance business flows; Step 2.5: Output Semantic Structure: Generate a unified semantic description structure; the semantic description structure includes at least service type, behavior pattern, communication pattern, and service importance. Among them, service type represents the service category to which the target service flow belongs, behavior pattern represents the sending characteristics of the target service flow, communication pattern represents the source-destination relationship of the target service flow, and service importance represents the priority of the target service flow in the system.

[0011] Furthermore, step 3 includes: Step 3.1: Construct a global reference flow library. The global reference flow library consists of multiple reference flows. Each reference flow includes at least traffic feature representation, semantic description, and QoS parameters. Step 3.2: Perform unified processing on the original reference data from different sources to form a standard reference stream; the processing includes at least feature extraction, semantic modeling, QoS labeling or determination, and consistency verification; Step 3.3: After the global reference flow library is built, for the target business flow to be identified and its semantic description, select the set of matching reference flows related to it from the global reference flow library; Step 3.4: Define the semantic similarity between the semantic description of the target service flow and the semantic description of the reference flow. The semantic similarity is calculated using a weighted summation method, i.e.: sim = w1 × simtype + w2 × simpattern + w3 × simmode + w4 × simimportance + w5 × simcontext, where sim represents semantic similarity, simtype represents service type similarity, simpattern represents behavioral pattern similarity, simmode represents communication pattern similarity, simimportance represents service importance similarity, and simcontext represents context similarity; w1, w2, w3, w4, and w5 are weight coefficients; the sum of each weight satisfies w1 + w2 + w3 + w4 + w5 = 1; Step 3.5: Match based on the semantic similarity between the target business flow and the reference flow; Step 3.6: After the matching process, output the set of matching reference flows corresponding to the target business flow and the matching type; the matching result includes the set of matching reference flows, the semantic similarity of each reference flow, and the matching type of the current target business flow.

[0012] Furthermore, in step 4, direct matching is suitable for scenarios where high-confidence reference samples already exist; CoT chain inference is suitable for scenarios where there is partial reference information and QoS parameters need to be gradually supplemented; FoT multi-path inference is suitable for scenarios where high-confidence reference samples are lacking and QoS candidate results need to be generated from multiple perspectives and compared and filtered.

[0013] Further, in step 4, the QoS candidate results are evaluated through a unified scoring mechanism, and the optimal candidate result is selected as the inference output of the target service flow. For multiple QoS candidate results generated by CoT or FoT, the scoring criteria include at least semantic consistency score, reference flow proximity score, network executability score, and constraint conflict penalty. The final score can be expressed as: scorem = λ1 × s1 + λ2 × s2 + λ3 × s3 + λ4 × s4, where scorem represents the comprehensive score of the m-th candidate QoS result; s1 represents the semantic consistency score; s2 represents the reference flow proximity score; s3 represents the network executability score; s4 represents the constraint conflict penalty value; λ1, λ2, λ3, and λ4 are weight coefficients, and satisfy λ1 + λ2 + λ3 + λ4 = 1.

[0014] Furthermore, the QoS results include at least end-to-end latency constraints, latency jitter constraints, tolerable packet loss rate cap, transmission reliability requirements, and service priority levels; wherein, the end-to-end latency constraints characterize the maximum allowable latency of the target service flow during end-to-end transmission; the latency jitter constraints characterize the fluctuation range of the service flow transmission latency; the tolerable packet loss rate cap characterizes the maximum allowable packet loss level of the service flow; the transmission reliability requirements characterize the reliability level that the service flow needs to meet; and the service priority level characterizes the degree of priority guarantee for the target service flow in resource allocation and scheduling execution.

[0015] Compared with the prior art, the present invention has the following advantages: (1) Automatic identification of traffic QoS requirements: This invention introduces a large model inference mechanism to directly map traffic characteristics to QoS parameters, reducing reliance on manual configuration and improving configuration accuracy and consistency.

[0016] (2) A correlation mechanism between traffic semantics and QoS requirements has been established: By integrating traffic characteristics and service semantic information, this invention enables the QoS identification process to no longer rely on simple classification, but to reflect the essential needs of the service, thereby improving the rationality of QoS settings.

[0017] (3) Possesses multi-source information fusion capability: In the QoS inference process, this invention comprehensively considers traffic characteristics, service semantics and network context information, so that the identification results can dynamically adapt to the network operation status and improve the effectiveness of scheduling decisions.

[0018] (4) This invention achieves intelligent transfer capability based on empirical knowledge by introducing a reference flow mechanism and semantic similarity reasoning, enabling effective QoS inference even in the absence of explicit rules. The incremental update mechanism proposed in this invention allows for the re-analysis of traffic that does not meet QoS requirements, significantly reducing computational overhead compared to existing full-processing methods. In typical network scenarios, only a small amount of traffic needs to be updated, reducing the computational scale to a smaller proportion of the original method, thereby improving the overall efficiency of the system.

[0019] In summary, the present invention outperforms existing technologies in terms of automation, identification accuracy, and system operating efficiency, and is suitable for large-scale, dynamically changing deterministic network environments. Attached Figure Description

[0020] Figure 1 This is the traffic identification process of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0022] This invention provides a deterministic network traffic quality of service identification method based on a large model, comprising the following steps: (a) Step 1: Traffic data collection and preprocessing.

[0023] This step is used to collect basic information, topology information, and network service background information of the service flow to be identified from the deterministic network, and to preprocess the collected raw data to generate a unified structured traffic representation, providing standard input for subsequent traffic semantic modeling, reference flow matching, and QoS inference.

[0024] Service flow data is acquired through network monitoring modules, mirrored ports of switching equipment interfaces, controller log interfaces, or packet collection devices. Data collection can be performed according to a preset monitoring period, preferably 1 ms to 1000 ms, and can be configured according to network scale, service type, and scheduling accuracy requirements. It should be noted that the monitoring period represents the time interval for collecting and updating the status of network service flows, and is not the same as the transmission period of the service flow itself.

[0025] The collected data includes at least the following three types of information: (1) Basic attributes of traffic Basic traffic attributes are used to describe the transmission characteristics of the target service flow itself, and include at least: ① Period t: preferably 1ms to 100ms, used to characterize the transmission period of periodic service flows; for non-periodic service flows, this field can be marked as non-periodic or approximated by the average transmission interval.

[0026] ② Message length l: Used to characterize the data length of a single message or frame.

[0027] ③ Transmission interval sequence: used to describe the time difference between the transmission times of adjacent messages. When the service flow is a strictly periodic flow, the transmission interval sequence can be approximately equal to a fixed period; when the service flow is an aperiodic flow or a burst flow, the transmission interval sequence is a changing sequence.

[0028] ④ Protocol Type: This characterizes the communication protocol category to which the target service flow belongs, including industrial control protocols, monitoring protocols, general Ethernet protocols, or other deterministic communication protocols. Protocol types can be obtained through methods such as header field parsing, port number identification, protocol identifier field extraction, protocol template matching, or optional deep packet inspection. Protocol types that cannot be clearly identified can be marked as unknown protocol types or retained as a set of candidate protocols.

[0029] Optionally, it may also include message number, timestamp, priority marker, and flow identifier. Among them, period is mainly used to describe the theoretical time attribute of the service flow, and the sending interval sequence is mainly used to describe the actual sending behavior of the service flow during operation. Both are used together to support subsequent periodicity determination and real-time analysis. Protocol type is mainly used to reflect the communication semantics and application background of the service flow, and together with message length, period, and sending interval sequence, it constitutes the basic input for subsequent semantic modeling.

[0030] (2) Topological information Topology information is used to describe the transmission relationships of target service flows in the network, and includes at least: ① Network topology: Used to describe the overall connectivity of the network in which the target service flow resides, preferably represented as a graph structure consisting of sets of nodes and links. The network topology reflects the switching equipment, terminal equipment, and their interconnections.

[0031] ②Source node s: The sending device or sending port used to represent the target service flow.

[0032] ③ Destination node d: Used to characterize the receiving device, receiving port, or set of destination nodes of the target service flow.

[0033] Optionally, it may also include link identifiers, switching node sequences, port identifiers, and link cost information. The network topology describes the global structure of the network in which the service flow resides. The source and destination nodes are primarily used to determine the sending and receiving relationships of the service flow and can assist in determining the service type, communication mode, and network role of the service flow. The link identifiers, switching node sequences, port identifiers, and link cost information can further refine the topological context representation of the service flow and serve as auxiliary inputs for subsequent QoS inference and scheduling constraint generation.

[0034] (3) Background information of network services Network service background information describes the application environment, service scenario, and business background of the network in which the target service flow resides, providing scenario priors for subsequent service semantic modeling, reference flow matching, and QoS inference. The network service background information includes at least: ① Network Service Type: This characterizes the application category or service scenario of the network in which the target service flow resides, including industrial control networks, condition monitoring networks, power communication networks, vehicle-to-everything (V2X) communication networks, smart manufacturing networks, or other deterministic communication scenarios. The network service type can be determined through network deployment configuration, system identifier, device role, protocol category, or manually defined scenario labels.

[0035] ② Application Scenario Information: This describes the specific application task or business process to which the target service flow belongs, such as control command transmission, status sampling and reporting, event alarm transmission, configuration data interaction, or general information exchange. Application scenario information can further characterize the functional role and service focus of the service flow in the network.

[0036] ③ Device Role Information: This describes the functional location of devices related to the target service flow in the network, such as controllers, actuators, sensors, monitoring terminals, switching equipment, or configuration terminals. Device role information can help determine the service type, importance, and QoS requirement level of the service flow.

[0037] Optionally, it may also include industry-specific information, protocol application background, deployment area information, and service priority assurance strategy information. Among these, network service type primarily characterizes the overall application background of the network where the target service flow resides; application scenario information primarily describes the specific service tasks undertaken by the service flow; and device role information primarily characterizes the functional positioning of the service flow within the system. These pieces of information collectively constitute the scenario context input for the target service flow, used for subsequent semantic modeling, reference flow matching, and QoS inference.

[0038] (4) Data preprocessing After the raw business flow data is collected, preprocessing is performed on the raw data to eliminate noise, standardize units, and construct a standard input format. The preprocessing includes at least the following operations: ① Time Alignment: Data records from different acquisition locations, devices, or ports are aligned to a unified time reference. Preferably, the time alignment error is controlled within 1 μs (microseconds); in actual deployment, this alignment error threshold can also be adjusted according to network synchronization capabilities and service accuracy requirements. The time-aligned data is used to ensure the comparability of different message records on a unified timeline.

[0039] ② Outlier Removal: Anomaly detection and cleaning are performed on the collected raw traffic data. The 3σ principle is preferred for outlier removal, but preset threshold filtering, sliding window detection, or quantile filtering can also be used. For sampled values ​​that clearly exceed reasonable ranges, missing values, or erroneous records, deletion, correction, or interpolation are performed to avoid abnormal input interfering with subsequent semantic modeling and QoS inference.

[0040] ③ Data Normalization Processing: Perform unified normalization or standardization processing on data with different dimensions to improve the consistency of subsequent semantic mapping and large model input. Normalization objects may include message length, transmission interval sequence, hop count information, protocol type encoding, network service type label, and device role label, etc. The normalization method can employ max-min normalization, z-score standardization, or other processing methods suitable for the current data distribution. For discrete type fields, label mapping, one-hot encoding, or embedding representation can also be used for unified conversion.

[0041] After the above preprocessing, a unified structured traffic representation is constructed. The structured traffic representation of the target service flow includes at least the service flow period, packet length, source node identifier, destination node identifier, transmission interval sequence, protocol type, network topology information, network service type, application scenario information, and device role information. Specifically, the service flow period describes the theoretical time attribute of the target service flow; the packet length describes the data size of a single packet or frame; the source node identifier and destination node identifier describe the transmission relationship of the service flow; the transmission interval sequence describes the actual transmission behavior of the service flow during operation; the protocol type characterizes the communication protocol category to which the target service flow belongs; the network topology information characterizes the overall connectivity of the network where the service flow resides; and the network service type, application scenario information, and device role information constitute the scenario context of the target service flow. In some embodiments, the structured traffic representation can be further extended to include fields such as link identifier, switching node sequence, port identifier, hop count information, flow identifier, timestamp, and priority marker.

[0042] (ii) Step 2: Based on the structured traffic representation obtained in Step 1, extract the semantic attributes of the target business flow, construct a unified semantic description, and map from "traffic numerical features" to "business semantic features".

[0043] Structured traffic representation includes at least the following fields: period, transmission interval sequence, source node, destination node, protocol type, topology information, network service type, application scenario information, and device role information; semantic description includes at least the following semantic information: service type, behavior pattern, communication mode, and service importance.

[0044] In this invention, semantic modeling is preferably carried out from the following dimensions: (1) Behavioral pattern recognition Behavioral patterns are used to describe the transmission characteristics of service flows over time. Preferably, the target service flow can be divided into periodic flow, burst flow, or continuous flow.

[0045] ① Periodic Flow: A periodic flow is defined as a flow where the deviation between the actual transmission interval sequence of the target service flow and its theoretical period is less than a preset period error threshold. Preferably, the period error threshold is less than 5%, i.e.: |Δt k - t i | / t i < 5%, Where, Δt k t represents the transmission interval of the k-th adjacent message. i This indicates the period of the target business flow. Periodic flows typically correspond to control or monitoring types of business and have high temporal stability.

[0046] ② Burst Flow: A burst flow is defined as a traffic flow whose packet arrival density within a short time window is significantly higher than its long-term average level. Preferably, this is achieved by defining a burst coefficient b. i Make a judgment: b i = r peak / r avg , Where, r peak Peak rate, representing the peak message arrival rate; r avg is the average rate, representing the average message arrival rate. When b i When the value exceeds the preset threshold, it is determined to be a burst flow; the threshold is preferably set between 2 and 5, as burst flows usually have a significant impact on cache usage and instantaneous link load.

[0047] ③ Continuous Flow: When the target service flow does not meet the criteria for either periodic flow or burst flow, but maintains continuous transmission over a relatively long time window, it is determined to be a continuous flow. Continuous flows are generally characterized by small variations in transmission intervals without a fixed period, or by continuous traffic and relatively stable throughput.

[0048] (2) Communication pattern recognition Communication modes are used to describe the source-destination relationship of a target service flow in the network. Preferably, based on the mapping relationship between the source node and the destination node, the communication mode is divided into unicast, multicast, or broadcast.

[0049] Unicast: When a source node corresponds to only one destination node, it is determined to be in unicast mode, i.e., 1→1. Unicast mode is usually used for point-to-point control command transmission or status feedback services.

[0050] Multicast: When one source node corresponds to multiple destination nodes, it is determined to be multicast mode, i.e., 1→n, where n is greater than 1. Multicast mode is usually used for synchronization control, state distribution, or multi-terminal collaboration scenarios. Its QoS configuration needs to consider both multicast consistency and reception synchronization.

[0051] Broadcast: When a source node sends messages indiscriminately to multiple nodes in the network, or when the set of destination nodes is not limited to a fixed subset, it is considered broadcast mode. Broadcast mode is typically used for discovery, announcement, or basic state synchronization services, and it consumes a wide range of resources.

[0052] It should be noted that the communication mode can be determined directly based on the number of source and destination nodes, or it can be determined comprehensively by combining network topology, forwarding table information, or service configuration rules.

[0053] (3) Business type determination The service type is used to characterize the semantic category of the target service flow. Preferably, the service type determination is based on a combination of rule base, protocol features, node type, behavior pattern, and network service background information. The service types include at least control type, monitoring type, and general data type.

[0054] ① Control-type business flows A target service flow can be classified as a control-type service flow when it meets one of the following conditions: the source or destination node belongs to a PLC, controller, actuator, or other control device; the service flow has obvious periodicity and a short cycle; the service flow requires low latency and high reliability; and the application scenario of the service flow is control command transmission, linkage control, or closed-loop regulation. Control-type service flows typically have the characteristics of low latency, high reliability, and high priority.

[0055] ② Monitoring-related business processes A target service flow can be classified as a monitoring service flow if it meets one of the following conditions: the service flow originates from sensors, sampling units, or monitoring equipment; the service flow has periodic sampling characteristics; it has certain latency requirements, but generally lower than those for control services; and the application scenario of the service flow is status sampling reporting, monitoring data transmission, or event alarm reporting. Monitoring service flows typically exhibit periodicity, moderate latency requirements, and high stability requirements.

[0056] ③ Ordinary data-related business flows When a target service flow does not meet the criteria for control or monitoring, and primarily undertakes general data transmission, log transmission, configuration interaction, or non-critical business information exchange, it can be classified as a regular data service flow. Regular data service flows typically have less stringent requirements for latency and jitter, focusing more on basic connectivity and throughput needs.

[0057] (4) Determination of business importance To further support subsequent QoS inference, this invention preferably classifies the importance of target service flows. Service importance can be divided into three levels: high, medium, and low.

[0058] ① Highly important business flows A business flow with any of the following characteristics can be identified as high importance: control-related business; business with strict requirements for end-to-end latency or reliability; business flow marked as a priority protection object in the business priority protection strategy.

[0059] ②Medium-Important Business Flows A business flow with any of the following characteristics can be classified as medium importance: periodic monitoring business; requiring stability but not requiring extremely low latency; having moderate sensitivity to resource consumption.

[0060] ③Low-importance business flows Ordinary data interaction, log transmission, or background services can be considered low importance, and their QoS requirements are usually relatively lenient.

[0061] Business importance can be directly mapped based on business type, or it can be modified by comprehensively considering device roles, application scenario information, and business priority assurance strategy information. For example, in a high-priority assurance scenario, some business flows that were originally of medium importance can be upgraded to high importance to ensure their transmission is prioritized.

[0062] After the semantic modeling described above, a unified semantic description structure is generated. This semantic description structure includes at least service type, behavioral pattern, communication pattern, and service importance. Specifically, service type represents the service category to which the target service flow belongs, behavioral pattern represents the transmission characteristics of the target service flow, communication pattern represents the source-destination relationship of the target service flow, and service importance represents the priority of the target service flow within the system.

[0063] Preferably, the service types include control, monitoring, and general data types; the behavior patterns include periodic, bursty, and continuous types; the communication patterns include unicast, multicast, and broadcast; and the service importance is categorized into high, medium, and low levels.

[0064] In some implementations, to support more complex QoS reasoning, the semantic description structure may further include contextual information. The contextual information preferably includes network service type, application scenario information, device role information, and network scale information, so as to provide supplementary basis for subsequent QoS reasoning from multiple aspects such as business background, scenario characteristics, device functional positioning, and network scale.

[0065] (III) Step 3: Construct a reference flow library and select a set of matching reference flows related to the target service flow from the reference flow library according to the semantic description of the target service flow, so as to provide empirical samples, boundary parameters and semantic mapping basis for subsequent QoS inference.

[0066] The reference stream can be derived from historical operational data, manually labeled data, or standard protocol templates, thus forming a set of reference samples that combines actual business characteristics with prior domain knowledge.

[0067] First, a global reference flow library is constructed. This library consists of multiple reference flows. The number of reference flows can be configured based on network size, the richness of service types, and historical data accumulation, preferably 10 to 1500. 4 strip.

[0068] Each reference flow includes at least a traffic feature representation, a semantic description, and QoS parameters. The traffic feature representation describes the structured traffic characteristics of the reference flow, the semantic description describes the service semantic characteristics of the reference flow, and the QoS parameters describe the service quality requirements corresponding to the reference flow. The QoS parameters include at least end-to-end latency constraints, jitter constraints, tolerable packet loss rate, reliability requirements, and service priority. Preferably, the end-to-end latency constraint ranges from 10 microseconds to 10 milliseconds, the jitter constraint ranges from 1 microsecond to 100 microseconds, and the tolerable packet loss rate ranges from 10... -6 Up to 10 -2 The reliability requirement ranges from 90% to 99.999%, and the business priority ranges from 0 to 7.

[0069] It should be noted that the reference flow does not simply store the original record of a single service flow, but rather a standard sample formed by organizing, annotating, verifying, and structuring historical service flows. In other words, each reference flow corresponds to a standard mapping sample that has undergone semantic and QoS annotation.

[0070] (1) Reference source The reference stream can originate from one or more of the following data sources: Historical operational data: Known service flow data is collected from the long-term operation of the network, and reference flows are formed by combining their actual operational performance, scheduling strategies, and performance results. This type of reference flow has strong authenticity, can reflect the service behavior patterns and QoS requirements in the actual network, and is preferred as a high-confidence reference sample for direct or partial matching scenarios.

[0071] Manually labeled data: Network operations personnel, domain experts, or system designers label typical service flows with QoS parameters based on service type, device role, protocol characteristics, and empirical rules, and then convert them into standard reference flows. This type of reference flow is particularly suitable for critical control services and service scenarios with a small number of samples but strict requirements.

[0072] Standard Protocol Templates: Based on publicly available specifications, standard documents, or vendor technical manuals of industrial protocols, power protocols, vehicle-to-everything (V2X) protocols, or other domain protocols, typical parameter characteristics and QoS requirements of their corresponding service flows are extracted to construct protocol template reference flows. For example, protocol-level reference flow templates can be formed based on industrial Ethernet protocols, fieldbus protocols, or other deterministic service protocols. These protocol template reference flows can serve as prior knowledge input in scenarios lacking historical samples and provide basic protocol semantic support for FoT multipath inference without matching traffic.

[0073] In some implementations, the reference flow may also be derived from simulation-generated data, testbed-acquired data, or validated configuration template data. Any flow that can form a stable mapping between traffic characteristics, semantic descriptions, and QoS parameters can be included in the reference flow library.

[0074] (2) Reference Stream Generation To ensure that all reference streams in the reference stream library have a consistent format and comparability, preferably, uniform processing is performed on the original reference data from different sources to form a standard reference stream. This processing includes at least the following: ①Feature extraction: Following the method in step 1, extract structured traffic feature information from the original business flow data.

[0075] ② Semantic modeling: Following the method in step 2, perform semantic mapping on the structured traffic feature information to generate corresponding semantic descriptions.

[0076] ③ QoS Labeling or Determination: For each reference flow, a set of QoS parameters is given. QoS parameters can be obtained from historical operational results, determined by manual rules, or directly provided by standard protocol templates.

[0077] ④ Consistency check: Check the consistency between traffic feature information, semantic description information and QoS parameters in the reference flow, and remove conflicting samples, abnormal samples or incomplete samples to improve the stability of subsequent matching and inference.

[0078] After the above processing, each reference flow in the global reference flow library can serve as an empirical support unit for subsequent target service flow QoS inference.

[0079] (3) Generation of matching reference stream set After the global reference flow library is built, a set of matching reference flows related to the target business flow to be identified and its semantic description is selected from the global reference flow library.

[0080] The number of reference flows included in the matching reference flow set is preferably 1 to 5, more preferably 2 to 3. The difference between the matching reference flow set and the aforementioned global reference flow library is that the global reference flow library is a complete set of system-level reference samples, while the matching reference flow set is a local candidate reference flow set selected for the current target service flow. The selection process is preferably based on the semantic description of the target service flow, combined with protocol type, network service type, application scenario information, and device role information to filter candidate reference flows.

[0081] (4) Matching mechanism To select reference flows suitable for the target service flow from the global reference flow library, a semantic similarity is defined between the semantic description of the target service flow and the semantic description of the reference flow. The semantic similarity value ranges from 0 to 1, with a higher value indicating that the target service flow and the reference flow are closer in terms of service type, behavior pattern, communication pattern, service importance, and contextual conditions.

[0082] Preferably, the semantic similarity is determined by the following dimensions: business type similarity, behavior pattern similarity, communication pattern similarity, and business importance similarity.

[0083] Optionally, it may also include contextual similarity, such as network service type, application scenario information, device role information, and network scale information.

[0084] In a preferred embodiment, semantic similarity can be calculated using a weighted summation method, i.e.: sim = w1 × simtype + w2 × simpattern + w3 × simmode + w4 × simimportance + w5 × simcontext, where sim represents semantic similarity; simtype represents business type similarity; simpattern represents behavioral pattern similarity; simmode represents communication pattern similarity; simimportance represents business importance similarity; simcontext represents contextual similarity; and w1, w2, w3, w4, and w5 are weight coefficients. The sum of each weight preferably satisfies w1 + w2 + w3 + w4 + w5 = 1. When contextual similarity is not used, w5 can be 0.

[0085] In another implementation, semantic similarity can also be achieved through rule matching, distance measurement, embedding vector similarity, or confidence scores output by classification models.

[0086] (5) Matching strategy Based on the semantic similarity between the target business flow and the reference flow, the following matching strategy is preferred: ① When the semantic similarity is greater than or equal to 0.9, the reference flow is determined to be a direct match with the target service flow. In this case, the corresponding reference flow can be directly included in the matching reference flow set, and its QoS parameters can be used as a high-confidence reference in subsequent inference processes.

[0087] ② When the semantic similarity is between 0.6 and 0.9, the reference flow is determined to be a partial match with the target service flow. At this time, the reference flow can be included in the matching reference flow set as a candidate reference sample for subsequent CoT chain inference. The final QoS parameters are generated through further constraint analysis and multi-candidate comparison.

[0088] ③ When the semantic similarity is less than 0.6, the reference flow is determined to be unmatched with the target business flow. In this case, it is not included in the high-confidence matching set, or it is only retained as a low-weight supplementary sample. If there are no reference flows with a semantic similarity of not less than 0.6 in the global reference flow library, the current target business flow is determined to be an unmatched flow, and FoT multi-path inference is triggered in subsequent steps.

[0089] It should be noted that the above 0.9 and 0.6 are preferred thresholds, and can be adjusted in actual implementation according to different business scenarios, different protocol categories and different sample sizes.

[0090] (6) Output of matching results After the above matching process, a set of matching reference flows corresponding to the target service flow and their matching types are output. The matching results include at least the following: ① the set of matching reference flows; ② the semantic similarity of each reference flow; ③ the matching type of the current target service flow, which includes direct matching, partial matching, and no matching.

[0091] The matching result will serve as the direct input for the inference mode call in step 4.

[0092] (iv) Step 4: Based on the large model, infer the service quality requirements of the target service flow and generate the QoS parameters corresponding to the target flow; the inference modes include three types: direct matching processing, CoT chain inference, and FoT multi-path inference, such as... Figure 1 As shown.

[0093] Unlike the previous steps, this step does not repeat the reference flow matching process itself. Instead, based on the obtained semantic description of the target service flow and the set of matching reference flows, it calls the corresponding inference mode according to the predetermined matching result. After the three modes are executed, they uniformly output structured QoS parameters for subsequent QoS structured representation and scheduling constraint generation steps.

[0094] (1) The data input to the inference module of this step includes at least the following two categories: Target Flow Semantic Description: After processing in step 2, the target service flow forms a semantic representation. This semantic representation includes at least service type, behavior pattern, communication pattern, service importance, and network context information. Preferably, the network context information includes network service type, application scenario information, device role information, and network scale information. Specifically, the service type describes service attributes; the behavior pattern describes traffic behavior characteristics; the communication pattern describes communication relationships; service importance reflects service priority; and the network context information characterizes the service background, application scenario, and topology context of the network where the target service flow resides.

[0095] Matching Reference Flow Set: The matching reference flow set is obtained from step 3 and may contain one or more reference flows. Each reference flow includes at least a protocol type, service semantics, and QoS parameters. The protocol type characterizes the communication protocol category to which the reference flow belongs; the service semantics characterizes the semantic features of the reference flow; and the QoS parameters characterize the service quality requirements corresponding to the reference flow. The QoS parameters preferably include end-to-end latency constraints, latency jitter constraints, packet loss rate caps, reliability requirements, and priority levels.

[0096] The number of matching reference flows is preferably 1 to 5, more preferably 2 to 3. In this step, the set of matching reference flows is no longer used to re-execute the matching decision, but mainly serves as a reference for QoS inference and a source of boundary constraints.

[0097] (2) Inference mode invocation Based on the matching results output in step 3, the corresponding inference mode is invoked. Specifically, this includes: ① When the matching type of the target business flow is direct matching, perform direct matching processing; ② When the matching type of the target business flow is partial matching, perform CoT chained reasoning; ③ When the matching type of the target business flow is no match, perform FoT multi-path inference.

[0098] The three inference modes described above are applicable to scenarios with varying degrees of complete reference information. Specifically, direct matching is suitable for scenarios where high-confidence reference samples already exist; CoT chain inference is suitable for scenarios with partial reference information that require gradual completion of QoS parameters; and FoT multi-path inference is suitable for scenarios lacking high-confidence reference samples that require generating QoS candidate results from multiple perspectives and comparing and filtering them.

[0099] (3) Direct matching processing When the matching type output in step 3 is direct matching, this step preferably does not perform complex reasoning, but directly inherits the QoS parameters of the corresponding reference flow, and makes minor adjustments to some parameters in combination with the service background information of the network where the target service flow is located.

[0100] Let qd be the quality of service (QoS) parameter corresponding to the directly matched reference flow. Then, the initial QoS parameter of the target service flow can be expressed as: qi0 = qd, where qi0 represents the initial QoS parameter of the target service flow. In the direct matching scenario, QoS inheritance optimization includes: inheriting the priority of the reference flow, the latency constraint of the reference flow, the jitter constraint of the reference flow, the packet loss rate constraint of the reference flow, and the reliability requirements of the reference flow.

[0101] In some implementations, the inherited QoS parameters can be slightly modified based on the network service type, application scenario information, device role information, and network scale of the target service flow, so that the reference flow QoS parameters are more suitable for the scenario to which the current target service flow belongs.

[0102] (4) CoT chain reasoning When the matching type output in step 3 is partial matching, this invention invokes CoT chained inference. CoT chained inference does not directly output the QoS result all at once, but rather analyzes the key constraints of the target service flow step by step according to a preset inference chain, and generates candidate QoS parameters step by step by combining the QoS boundaries in the matching reference flow set, thereby improving the stability and interpretability of the inference. CoT chained inference includes at least the following sub-steps: 1) Sub-step A: Extract key semantic constraints First, key constraint factors affecting QoS configuration are extracted from the semantic description of the target service flow. These key constraint factors include at least service type constraints, periodicity constraints, real-time constraints, reliability constraints, and scenario context constraints. Specifically:

[0103] ① Business type constraint extraction If the service type is control-related, the service flow is determined to be a high real-time, high-reliability service, and is given higher priority with constraints on lower latency and jitter. If the service type is monitoring-related, the service flow is determined to be a periodic sampling or status monitoring service, with moderate latency constraints and high requirements for periodic consistency. If the service type is ordinary data-related, it is determined that it mainly focuses on throughput and basic reliability, and can adopt more lenient latency constraints.

[0104] ② Periodic constraint extraction If the behavior pattern is periodic, its periodic parameter ti is recorded, where ti represents the periodic parameter of the target service flow, and further constraints are imposed: the upper limit of latency is less than or equal to a certain proportion of the period; jitter is not greater than the periodic jitter tolerance range. Preferably, for periodic flows: end-to-end latency is less than or equal to αti, and latency jitter is less than or equal to βti, where α represents the latency proportionality coefficient, β represents the jitter proportionality coefficient, α is preferably taken as 0.1 to 0.5, and β is preferably taken as 0.01 to 0.1.

[0105] ③ Communication mode constraint extraction If the communication mode is multicast, then consider its multicast consistency and multi-receiver synchronization requirements, and appropriately increase the reliability requirements; if the communication mode is broadcast, then consider its coverage and resource consumption characteristics, and the priority is generally not higher than the critical control flow; if the communication mode is unicast, then focus on setting the latency and reliability parameters according to the point-to-point service requirements.

[0106] ④ Scene context constraint extraction QoS is dynamically adjusted based on network service type, application scenario information, device role information, and network scale within the network context. For example: when the target service flow belongs to an industrial control network, latency and reliability constraints are prioritized; when the target service flow belongs to an application scenario of control command transmission or event alarm transmission, the priority of the target service flow is increased or latency requirements are tightened; when the relevant device roles include controllers, actuators, or critical monitoring terminals, reliability and redundancy requirements are increased; and when the network scale is large, the end-to-end latency estimate is appropriately increased.

[0107] 2) Sub-step B: Reference flow constraint mapping After extracting the key semantic constraints of the target service flow, a mapping analysis is performed on the matching reference flow set to extract the QoS boundaries and value ranges in the reference flow, forming candidate QoS intervals.

[0108] For each reference flow, its end-to-end latency constraint, jitter constraint, packet loss rate cap, reliability requirement, and priority level are read. If the number of matching reference flows is greater than one, corresponding sets of latency parameters, jitter parameters, packet loss rate parameters, reliability parameters, and priority parameters are formed. Then, the inference reference range for each parameter is calculated, preferably using the minimum, maximum, median, or weighted average value. For example, the latency reference range can be determined by the minimum and maximum values ​​in the latency parameter set; the priority reference value can be the most frequently occurring value in the priority parameter set, or the integer value obtained by weighted averaging.

[0109] The weights can be assigned based on the similarity between the reference flow and the target business flow, denoted as wj, satisfying: Σwj = 1, the higher the similarity, the greater the weight.

[0110] 3) Sub-step C: Chained reasoning generates QoS candidate results Based on the key semantic constraints of the target service flow extracted in sub-step A and the reference QoS interval formed in sub-step B, the large model generates QoS candidate results item by item in a preset order. Preferably, the inference order is: priority inference, latency inference, jitter inference, packet loss rate inference, and reliability inference.

[0111] ① Priority reasoning Priority is determined based on a combination of business importance, real-time requirements, and reference stream priority. The selection rules are as follows: High-importance control flow: priority 5-7; Periodic monitoring stream: Priority 3-6; Normal data stream: priority 0-4.

[0112] If the reference stream priority is concentrated on a certain value, then that value will be given priority as the output result.

[0113] ②Time Delay Reasoning Latency is determined jointly based on periodic characteristics, service type, and reference flow latency. The optimal selection rules are as follows: Control flow: 10 μs to 1 ms; Monitoring flow: 100 μs~5 ms; Normal data stream: 1 ms to 10 ms.

[0114] If a periodic parameter exists, it is preferable to satisfy: end-to-end latency ≤ min (refer to the upper bound of the stream latency, αti).

[0115] ③ Jittery reasoning Jitter is mainly related to periodic consistency and scheduling accuracy. The optimal selection rules are as follows: High real-time cycle flow: 1 μs to 20 μs; Typical monitoring flow: 10 μs to 100 μs; Normal data stream: can be longer than 100 μs, or not as a strong constraint.

[0116] ④ Packet loss rate and reliability reasoning Packet loss rate and reliability are interrelated. The optimal selection criteria are as follows: Control flow: Packet loss rate no greater than 10 -4 The reliability is no less than 99.99%; Monitoring stream: Packet loss rate not greater than 10 -3 The reliability is no less than 99.9%; Normal data stream: packet loss rate no greater than 10 -2 The reliability is no less than 99%.

[0117] 4) Sub-step D: Generation of multiple candidate results To avoid instability in single inference output, this invention preferably generates multiple QoS candidate results. The number of candidates is denoted as k, where k = 3 to 5; preferably k = 3. The generated candidate results can be sequentially denoted as the first candidate QoS result, the second candidate QoS result, and so on, up to the kth candidate QoS result. Each candidate result includes a complete set of QoS parameters.

[0118] It should be noted that the candidate QoS results generated in this step are intermediate inference results. The optimal candidate will be selected through a scoring mechanism and further converted into a unified structured QoS representation.

[0119] (5) FoT multi-path reasoning When the matching type output in step 3 is no match, this invention invokes FoT multi-path inference. Unlike CoT chain inference, FoT multi-path inference does not rely on highly similar reference flows to derive QoS step by step in a single chain. Instead, it constructs multiple independent inference chains, generates multiple QoS candidate results in parallel, and then selects the optimal result through a unified scoring mechanism to improve the inference capability for new types of traffic, unknown protocol traffic, or cross-scenario traffic.

[0120] When generating the results of each inference chain, FoT multi-path inference takes into account at least the following factors: ① Protocol semantic factors: Based on the protocol type, message behavior characteristics and protocol template knowledge of the target business flow, protocol semantic factors are used to analyze the latency, jitter, reliability and priority requirements that such business flows usually correspond to in the same protocol scenario.

[0121] ②Scenario requirement factors: Scenario requirement factors are based on the application scenario, business task and service goal of the target business flow. They are used to analyze the service assurance priorities of the business in the corresponding scenario, such as prioritizing low latency, stability or high reliability.

[0122] ③ Network service background factors: Based on the service type, device role information and network scale of the network to which the target service flow belongs, the network service background factors are used to analyze the reasonable QoS setting range and executability level of the service flow in the current network scenario.

[0123] In some implementations, the following factors may be further considered: historical similarity flow backtracking factor, scheduling feasibility factor, and fault tolerance factor.

[0124] It should be noted that each inference chain in FoT preferably analyzes the QoS requirements of the target service flow by comprehensively considering the above-mentioned multiple factors. The differences between different inference chains lie in the inference path, inference order, factor weight allocation, or candidate result generation method. Preferably, the FoT multi-path inference includes at least three independent inference chains, each generating corresponding QoS candidate results from the large model. The generated candidate results can correspond to the multiple candidate QoS results in the above steps. The candidate results generated by multiple inference chains are then merged to form the FoT candidate set, and the optimal candidate result is selected in subsequent steps through a unified scoring mechanism.

[0125] (6) Candidate result scoring and unified output Regardless of whether direct matching, CoT chained inference, or FoT multi-path inference is used, this invention preferably evaluates QoS candidate results through a unified scoring mechanism and selects the optimal candidate result as the inference output for the target service flow. For multiple QoS candidate results generated by CoT or FoT, the scoring criteria include at least the following dimensions:

[0126] ① Semantic consistency score: Evaluates whether the candidate QoS is consistent with the semantic characteristics of the target service flow.

[0127] ② Reference Flow Proximity Score: Evaluates the proximity of the candidate QoS to the reference flow's QoS range. For flows without a match, this item can be downgraded or replaced with a protocol template proximity score.

[0128] ③ Network Feasibility Score: Evaluates whether candidate QoS is feasible under the current network service context and network scale. For example: whether latency constraints are consistent with network scale and service cycle; whether priority level matches service importance and service type; and whether reliability requirements match available redundancy mechanisms and scheduling resources.

[0129] ④ Constraint Conflict Penalty: If a candidate result has a significant conflict, its score will be reduced. For example: the latency constraint is too small, making it difficult to achieve under the current network scale; low priority but requiring ultra-high reliability; jitter constraint is stricter than the system's minimum time slot capability.

[0130] The final score can be expressed as: scorem = λ1 × s1 + λ2 × s2 + λ3 × s3 + λ4 × s4, where scorem represents the comprehensive score of the m-th candidate QoS result; s1 represents the semantic consistency score; s2 represents the reference flow proximity score; s3 represents the network executability score; s4 represents the constraint conflict penalty value; λ1, λ2, λ3, and λ4 are weight coefficients, and satisfy λ1 + λ2 + λ3 + λ4 = 1. The preferred values ​​are: λ1 = 0.30~0.40; λ2 = 0.20~0.30; λ3 = 0.20~0.30; λ4 = 0.10~0.20.

[0131] The candidate QoS with the highest score is taken as the optimal inference result for the target service flow. This optimal inference result will be further converted into a unified structured QoS representation in subsequent steps and used as the input for generating scheduling constraints.

[0132] (7) QoS structured output After completing direct matching, CoT chain inference, or FoT multi-path inference, the optimal inference result of the target business flow is represented in a unified structure to eliminate the differences in output format between different inference modes and form a standard parameter set that can be directly called by subsequent routing, scheduling, and configuration modules.

[0133] Structured QoS results include at least: end-to-end latency constraints, latency jitter constraints, tolerable packet loss rate cap, transmission reliability requirements, and service priority levels. Specifically, end-to-end latency constraints characterize the maximum allowable latency of the target service flow during end-to-end transmission; latency jitter constraints characterize the fluctuation range of the service flow's transmission latency; tolerable packet loss rate cap characterizes the maximum allowable packet loss level of the service flow; transmission reliability requirements characterize the reliability level that the service flow must meet; and service priority levels characterize the degree of priority guarantee for the target service flow in resource allocation and scheduling execution.

[0134] In some implementations, fields such as service type, communication mode, constraint type, and redundancy flag can be further expanded to enhance the executability of subsequent scheduling.

[0135] To ensure the results are usable for deployment, it is preferable to perform range constraints and consistency checks on the structured QoS parameters, including: ① Latency, jitter, packet loss rate, reliability, and priority should all be within the preset range; ② For periodic streams, it is preferable to satisfy the delay constraint and jitter constraint, which are respectively no higher than a certain proportion of the business cycle; ③ When reliability requirements are high, it is preferable to simultaneously reduce the upper limit of packet loss rate and enable redundancy flags in subsequent constraint generation.

[0136] The structured QoS results serve as a unified input for subsequent steps, generating routing constraints, time slot allocation constraints, and redundant transmission constraints, thereby transforming QoS inference results into executable scheduling conditions. This invention employs three inference modes—direct matching, CoT chained inference, and FoT multi-path inference—to enable the system to select different inference paths based on varying levels of reference information completeness. For scenarios with high-confidence reference flows, QoS parameters can be quickly inherited and corrected; for partially matched scenarios, QoS results can be gradually generated through chained inference; and for unmatched scenarios, multi-path inference enhances adaptability to new service flows, thus strengthening the invention's generalization ability to complex service flows and unknown traffic scenarios.

[0137] This invention achieves a closed-loop mapping from "traffic characteristics—semantic reasoning—QoS parameters—scheduling constraints" by converting the QoS results obtained through reasoning into a unified set of structured parameters and automatically generating corresponding scheduling constraints. This technical solution can directly transform QoS requirements into path length constraints, time slot allocation constraints, and redundant transmission constraints, reducing the manual conversion steps between QoS analysis and scheduling execution and improving the overall automation level of the system.

[0138] Example 1

[0139] QoS identification methods in direct matching scenarios: In a deterministic industrial control network, a target service flow is sent from PLC1 to Actuator1. The service flow has a transmission period of 10 milliseconds, a message length of 128 bytes, an average link load of 45%, and a transmission path passing through switching nodes S1, S2, and S3.

[0140] After completing data acquisition and preprocessing in step 1, the basic characteristics of the target business flow are as follows: the business flow cycle is 10 milliseconds, the message length is 128 bytes, the source node is PLC1, the destination node is Actuator1, the path node sequence is S1, S2, S3, the link load is 45%, and the device status is normal.

[0141] After semantic modeling based on step 2, the semantic attributes of the target business flow are identified as follows: the business type is control type, the behavior pattern is periodic, the communication pattern is unicast, and the business importance is high.

[0142] In the reference flow library, there exists a reference flow that is highly consistent with the target service flow in terms of protocol type, service type, and periodic characteristics. This reference flow is denoted as the direct matching reference flow RefFlow. dThe QoS parameters corresponding to this reference flow are as follows: end-to-end latency constraint of 800 microseconds, latency jitter constraint of 20 microseconds, and tolerable packet loss rate of 10%. -4 The reliability requirement is 99.99%, and the priority level is 6.

[0143] Since the reference flow and the target service flow are directly matched, the QoS parameters of the reference flow are directly inherited in step 4, and minor adjustments are made based on the current link load. In this embodiment, since the average link load is 45%, the conditions for further increasing priority or tightening latency have not been met, so the original QoS parameters of the reference flow remain unchanged.

[0144] Therefore, the final QoS result for the target service flow is: end-to-end latency constraint of 800 microseconds, latency jitter constraint of 20 microseconds, and tolerable packet loss rate of 10%. -4 The reliability requirement is 99.99%, and the priority level is 6. Subsequently, the above QoS results are converted into structured output, which includes at least the end-to-end latency constraint field, latency jitter constraint field, tolerable packet loss rate field, transmission reliability field, and service priority field.

[0145] Example 2 CoT chained inference method in partial matching scenarios: In an industrial monitoring network, the target service flow is controlled by a sensor. A Send to Controller B The service stream has a transmission period of 20 milliseconds, a message length of 96 bytes, and a link load of 55%. Its service type is preliminarily determined to be monitoring, and its communication mode is periodic unicast.

[0146] After completing data acquisition and preprocessing in step 1, the basic characteristics of the target business flow are as follows: the business flow period is 20 milliseconds, the message length is 96 bytes, and the source node is Sensor. A The target node is the Controller. B The link load is 55%.

[0147] After semantic modeling in step 2, the semantic attributes of the target business flow are identified as follows: business type is monitoring, behavior pattern is periodic, communication mode is unicast, and business importance is medium.

[0148] In the reference flow library, there is no reference flow that is completely identical to the target service flow, but there are two partially matching reference flows.

[0149] The protocol type of the first reference flow is EtherCAT, and its semantic characteristics are control, periodic, unicast, and high importance. The corresponding QoS parameters are: end-to-end latency constraint of 1000 microseconds, latency jitter constraint of 30 microseconds, and tolerable packet loss rate of 10%. -4 Reliability requirement: 99.99%; priority level: 6.

[0150] The second reference flow uses the Profinet protocol, with semantic characteristics of monitoring, periodic, unicast, and medium importance. Its corresponding QoS parameters are: end-to-end latency constraint of 500 microseconds, latency jitter constraint of 20 microseconds, and tolerable packet loss rate of 10%. -3 Reliability requirement: 99.9%, priority level: 5.

[0151] Since the target service flow partially matches the two reference flows mentioned above, CoT chained inference is invoked in step 4. First, the key semantic constraints of the target service flow are extracted, including: service type is monitoring, period parameter is 20 milliseconds, communication mode is unicast, and service importance is medium. Second, the QoS boundaries of the two reference flows are mapped to form candidate intervals for latency, jitter, packet loss rate, reliability, and priority. Then, chained inference is performed item by item in the order of priority, latency, jitter, packet loss rate, and reliability, generating three sets of candidate QoS results.

[0152] In step 4, the candidate results are compared using a unified scoring function. Taking into account factors such as semantic consistency, reference flow proximity, network executability, and constraint conflicts, the candidate result with the highest score is finally selected as the output.

[0153] The final QoS results are: end-to-end latency constraint of 600 microseconds, latency jitter constraint of 25 microseconds, and tolerable packet loss rate of 10%. -3 Reliability requirement: 99.9%, priority level: 5.

[0154] Subsequently, corresponding scheduling constraints are generated based on the QoS result. The generated scheduling constraints include: the number of candidate paths is 2, the time slot period is 20 milliseconds, the transmission window is allocated according to the queue corresponding to priority level 5, and redundant replicas are not enabled.

[0155] Example 3 FoT multi-path inference methods in scenarios without matching: In a hybrid deterministic network, the target service flow is controlled by Unknown Device Sent to Compute NodeThe traffic flow exhibits non-fixed periodicity and short bursts, with a link load of 72% and normal device status. However, there is no reference flow with a semantic similarity of at least 0.6 in the reference flow library. Therefore, the target traffic flow is determined to be an unmatched flow.

[0156] After completing data collection and preprocessing in step 1, the basic characteristics of the target business flow can be obtained as follows: the source node is Unknown. Device The destination node is Compute Node The behavior is characterized by non-fixed periods and short bursts, with a link load of 72% and the device status being normal.

[0157] After semantic modeling based on step 2, its semantic attributes are as follows: the behavior pattern is bursty, the communication mode is determined to be unicast based on the source-sink relationship, and the service type is difficult to be directly classified into the control or monitoring category, and needs to rely on subsequent reasoning to determine a more suitable QoS requirement.

[0158] Since there are no reference flows in the reference flow library with a semantic similarity of not less than 0.6, FoT multi-path inference is invoked in step 4. Preferably, FoT multi-path inference comprehensively considers the following factors: First, protocol semantic factors, that is, estimating the basic QoS range of the target service flow based on the protocol fields and message behavior characteristics of the target service flow; Second, scenario requirement factors, that is, estimating its sensitivity to latency and reliability based on the service objectives of the scenario in which the target service flow is located; Third, network service background factors, that is, estimating its executable QoS boundaries based on the current network scale, service background, and resource conditions.

[0159] Based on this, FoT constructs three independent inference chains. Each inference chain comprehensively considers the above-mentioned factors, but differs in inference path, inference order, factor weight allocation, or candidate result generation method. The three inference chains generate corresponding QoS candidate results, which are then merged to form the FoT candidate set.

[0160] In step 4, multiple candidate results in the FoT candidate set are evaluated through a unified scoring mechanism. Taking into account semantic consistency, protocol template proximity, network executability, and constraint conflict, the optimal candidate result is finally selected as the QoS output of the target service flow.

[0161] The final QoS results are: end-to-end latency constraint of 2 milliseconds, latency jitter constraint of 80 microseconds, and tolerable packet loss rate of 10%. -2 Reliability requirement: 99%; priority level: 3.

[0162] The QoS results are then converted into structured QoS parameters, and scheduling constraints are further generated. These constraints include: allowing a wider transmission window, a path hop count not exceeding 5 hops, disabling redundant replicas, and a priority queue level of 3.

[0163] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A deterministic network traffic quality of service identification method based on a large model, characterized in that, Includes the following steps: Step 1: Collect basic information, topology information, and network service background information of the service flow to be identified from the deterministic network, and preprocess the collected raw data to generate a unified structured traffic representation; Step 2: Based on the structured traffic representation obtained in Step 1, extract the semantic attributes of the target business flow, construct a unified semantic description, and map from "traffic numerical features" to "business semantic features"; The specific content includes: Step 2.1, Behavioral Pattern Recognition: Used to describe the transmission characteristics of the target service flow in the time dimension; the target service flow is divided into periodic flow, burst flow, or continuous flow; Step 2.2, Communication Pattern Recognition: This describes the source-destination relationship of the target service flow in the network; based on the mapping relationship between the source node and the destination node, the communication pattern is classified into unicast, multicast, or broadcast. Step 2.3, Business Type Determination: This step is used to characterize the business semantic category of the target business flow. Business type determination is based on a combination of rule base, protocol features, node type, behavior pattern, and network service background information. Business types include at least control type, monitoring type, and ordinary data type. Step 2.4, Business Importance Determination: Business importance is divided into high-importance business flows, medium-importance business flows, and low-importance business flows; Step 2.5, Output Semantic Structure: Generate a unified semantic description structure; the semantic description structure includes at least service type, behavior pattern, communication pattern and service importance, where service type represents the service category to which the target service flow belongs, behavior pattern represents the sending characteristics of the target service flow, communication pattern represents the source-destination relationship of the target service flow, and service importance represents the priority of the target service flow in the system. Step 3: Construct a reference flow library, and based on the semantic description of the target service flow, select a set of matching reference flows related to the target service flow from the reference flow library to provide empirical samples, boundary parameters, and semantic mapping basis for subsequent QoS inference; Specific content includes: Step 3.1: Construct a global reference flow library. The global reference flow library consists of multiple reference flows. Each reference flow includes at least traffic feature representation, semantic description, and QoS parameters. Step 3.2: Perform unified processing on the original reference data from different sources to form a standard reference stream; the processing includes at least feature extraction, semantic modeling, QoS labeling or determination, and consistency verification; Step 3.3: After the global reference flow library is built, for the target business flow to be identified and its semantic description, select the set of matching reference flows related to it from the global reference flow library; Step 3.4: Define the semantic similarity between the semantic description of the target service flow and the semantic description of the reference flow. The semantic similarity is calculated using a weighted summation method, i.e.: sim = w1 × simtype + w2 × simpattern + w3 × simmode + w4 × simimportance + w5 × simcontext, where sim represents semantic similarity, simtype represents service type similarity, simpattern represents behavioral pattern similarity, simmode represents communication pattern similarity, simimportance represents service importance similarity, and simcontext represents context similarity; w1, w2, w3, w4, and w5 are weight coefficients; the sum of each weight satisfies w1 + w2 + w3 + w4 + w5 = 1; Step 3.5: Match based on the semantic similarity between the target business flow and the reference flow; Step 3.6: After the matching process, output the set of matching reference flows corresponding to the target business flow and the matching type; the matching result includes the set of matching reference flows, the semantic similarity of each reference flow, and the matching type of the current target business flow; Step 4: Based on the large model, infer the service quality requirements of the target service flow and generate the QoS parameters corresponding to the target flow; the inference modes include three types: direct matching processing, CoT chain inference and FoT multi-path inference.

2. The deterministic network traffic quality of service identification method based on a large model according to claim 1, characterized in that, In step 1, service flow data is acquired through a network monitoring module, a mirror port of the switching device interface, a controller log interface, or a packet collection device. Data collection is performed according to a preset monitoring cycle and configured according to network scale, service type, and scheduling accuracy requirements. The collected data includes at least basic traffic attributes, topology information, and network service background information. The monitoring cycle is 1ms to 1000ms, which represents the time interval for collecting and updating the status of network service flows and is not equivalent to the sending cycle of the service flow itself.

3. The deterministic network traffic quality of service identification method based on a large model according to claim 1, characterized in that, In step 2, the structured traffic representation includes at least the following fields: period, transmission interval sequence, source node, destination node, protocol type, topology information, network service type, application scenario information, and device role information; the semantic description includes at least the service type, behavior pattern, communication mode, and service importance.

4. The deterministic network traffic quality of service identification method based on a large model according to claim 1, characterized in that, In step 4, direct matching is suitable for scenarios where high-confidence reference samples already exist; CoT chain inference is suitable for scenarios where there is partial reference information and QoS parameters need to be gradually supplemented. FoT multi-path inference is suitable for scenarios where high-confidence reference samples are lacking and QoS candidate results need to be generated from multiple perspectives and compared and filtered.

5. The deterministic network traffic quality of service identification method based on a large model according to claim 4, characterized in that, In step 4, the QoS candidate results are evaluated using a unified scoring mechanism, and the optimal candidate result is selected as the inference output of the target service flow. For multiple QoS candidate results generated by CoT or FoT, the scoring criteria include at least semantic consistency score, reference flow proximity score, network executability score, and constraint conflict penalty. The final score can be expressed as: scorem = λ1 × s1 + λ2 × s2 + λ3 × s3 + λ4 × s4, where scorem represents the comprehensive score of the m-th candidate QoS result; s1 represents the semantic consistency score; s2 represents the reference flow proximity score; s3 represents the network executability score; s4 represents the constraint conflict penalty value; λ1, λ2, λ3, and λ4 are weight coefficients, and satisfy λ1 + λ2 + λ3 + λ4 = 1.

6. The deterministic network traffic quality of service identification method based on a large model according to claim 5, characterized in that, The QoS results include at least end-to-end latency constraints, latency jitter constraints, tolerable packet loss rate cap, transmission reliability requirements, and service priority levels. The end-to-end latency constraints characterize the maximum allowable latency of the target service flow during end-to-end transmission; the latency jitter constraints characterize the fluctuation range of the service flow's transmission latency; the tolerable packet loss rate cap characterizes the maximum allowable packet loss level of the service flow; the transmission reliability requirements characterize the reliability level that the service flow needs to meet; and the service priority level characterizes the degree of priority guarantee for the target service flow in resource allocation and scheduling.

Images