TSN gating scheduling table generation method for frame merging pre-processing

Abstract

The invention provides a TSN gating scheduling table generation method for frame merging pre-processing, and mainly solves the problems of low real-time performance of data transmission and low utilization efficiency of network resources caused by incapability of effectively managing and scheduling a large number of data streams in the prior art. According to the scheme adopted by the method, the streams are preprocessed, and the streams with the same characteristics are merged according to the preprocessing result, so that the real-time performance of transmission is improved, and the utilization efficiency of network resources is improved; according to the method adopted by the invention, the flow quantity in the network is reduced through merging processing, the scheduling complexity is reduced, the deterministic advantage of SMT solution is fused, the solution efficiency is improved on the basis, and the method is suitable for industrial automation and other real-time data processing applications needing high time sensitivity.

Description

Technical Field

[0001] The present invention belongs to the technical field of time-sensitive networks and specifically relates to a method for generating a TSN gating schedule table for frame merging pre-processing. Background Art

[0002] In modern industrial automation and critical infrastructure systems, the real-time and reliability of network communications are critical. IEEE802.1Qbv provides a standard framework for time-sensitive networking. Time-Sensitive Networking (TSN) is an extension of Ethernet technology that aims to provide deterministic network transmission services. This technology is mainly aimed at applications that require strict time control, such as real-time control systems, audio and video transmission, industrial automation, etc.

[0003] TSN provides network time determinism through a series of IEEE standards, ensuring that data packets arrive at their destination within the scheduled time. TSN technology includes multiple IEEE standards, including IEEE 802.1AS, IEEE 802.1Qbv, IEEE802.1Qbu, and IEEE 802.1Qci. Time-deterministic flow scheduling is one of the core applications of TSN, which involves how to efficiently and accurately plan and manage various data flows in the network. The main tasks of flow scheduling planning include flow identification and classification; each data flow in the network needs to be identified and classified according to its importance and real-time requirements. Common classification standards divide data flows into TS (time-sensitive flow), AVB (audio and video flow) and BE (best effort flow). These flows are divided into multiple priority levels and adopt different scheduling strategies. TSN time-sensitive network provides precise time synchronization and strict scheduling for data flows to ensure that data arrives at its destination at the scheduled time. This is very critical for applications that require strict timing, such as audio and video transmission, industrial control systems, etc. The implementation of TSN technology depends on the precise configuration and synchronization of each network component, including switches, routers and terminal devices. When the hardware can guarantee the transmission requirements normally, the network scheduling algorithm of TSN is the most important part in determining the time-deterministic data transmission process. However, with the increase in network scale and complexity, traditional TSN network scheduling algorithms often cannot effectively handle the real-time scheduling requirements of a large number of data streams, especially in an environment where the data stream changes dynamically. In the existing technology, static scheduling algorithms do not have the ability to dynamically adjust network flows, and it is difficult to cope with the rapid changes in network status. For the SMT solution methods commonly used in industrial environments, when faced with complex topologies and large-scale tasks, the scale of solution is often increased exponentially. The algorithms based on emerging technologies such as deep learning, neural networks, and large models are now popular. The huge overhead in the model training stage makes it impossible to quickly iterate the algorithm for changes in certain requirements in the industrial environment. In addition, the randomness brought by the exploratory solution method is not suitable for the requirements of solving determinism in the industrial production environment. Therefore, the existing technology cannot effectively manage and schedule a large number of data streams, resulting in reduced real-time data transmission and low utilization efficiency of network resources. Summary of the invention

[0004] In order to overcome the shortcomings of the prior art, improve the management and scheduling efficiency of data streams in the prior art, and improve the real-time performance of data transmission, the present invention provides a TSN gating scheduling table generation method for frame merging pre-processing.

[0005] A method for generating a TSN gating schedule table for frame merging pre-processing includes the following steps:

[0006] Step 1: Build a time-sensitive network model;

[0007] Step 2: Preprocess the stream before merging;

[0008] Preprocessing includes compression processing, encoding processing, flow identification and classification processing, normalization processing and residual jitter calculation; the residual jitter calculation must be performed after compression processing, encoding processing, flow identification and classification processing and normalization processing;

[0009] Step 3: Stream merging processing;

[0010] Step 4: Construct a gating schedule;

[0011] A gated schedule is constructed based on a set of merged flows; the gated schedule satisfies gated scheduling constraints; the gated scheduling constraints include window definition constraints, flow instance constraints, window sequence constraints, window size constraints, frame-window allocation constraints, flow isolation constraints, flow order constraints, and end-to-end delay constraints.

[0012] Furthermore, the time-sensitive network model is: G is the set of all objects in the network; N is the set of all nodes in the network; SW is the set of all switch nodes in the network; ES is the set of all end system nodes in the network; n i is the node in the network; L is the set of all links in the network; l i Links in the network;

[0013] The relationship of the time-sensitive network model G is:

[0014] G=<N,L> ; N =<SW,ND> ={n i} i=0,1,2...k;SW∈N;

[0015] n i ∈Ni=0,1,2…k;L= <l i > i=0,1,2…k;l i ∈Li=0,1,2...k;

[0016] The flow in the time-sensitive network model G is a series of data packets from the source node to the destination node;

[0017] The flow model in the time-sensitive network model G is:

[0018] S is the set of all flows in the network; s i is the i-th flow in the network; I is the set of all flow instances in the network; i i is any flow instance in the network;

[0019] S={s i} i=0,1,2…k;

[0020] si ∈S i=0,1,2…k;

[0021] I={i i} i=0,1,2…k;

[0022] i i ∈I i=0,1,2...k;

[0023] Each flow includes attributes, including flow ID, bandwidth, flow delay, flow jitter, flow size, flow period, source node, destination node, priority, flow length and priority;

[0024] A flow instance is: a source node periodically sends data packets, which propagate to the destination node along a predetermined path. The existence of each data packet on each link is a flow instance.

[0025] Furthermore, the compression process is to reduce the size of the stream by using a compression algorithm;

[0026] The encoding process is to process the stream using Huffman coding or AlphaMite coding, thereby reducing the length of the stream or changing the distribution characteristics of the stream;

[0027] The flow identification and classification process is as follows: traverse all flows and classify the flows into several categories according to the source address, destination address, cycle, priority and size of the flows;

[0028] The normalization process is to normalize the size of the stream to the same range, that is, to unify the size of all streams to the MTU maximum transmission unit according to the data transmission capability of the hardware;

[0029] The residual jitter is calculated as follows: the residual jitter of each flow is calculated, and the residual jitter is the maximum time variation range that the flow can tolerate while meeting the maximum delay requirement.

[0030] Furthermore, the specific steps of stream merging are:

[0031] Step 3.1: Generate a set of all flows and initialize a merged flow set, which is equal to the set of all flows;

[0032] Step 3.2: Traverse the merged stream collection;

[0033] In the merged stream set, randomly select two streams A and B and check whether they meet the merge condition:

[0034] If the merging condition is met, they are merged into a new stream C, and C is added to the merged stream set. Streams A and B are deleted from the merged stream set.

[0035] If the merge condition is not met, A and B are retained;

[0036] Repeat step 3.2 and traverse the merged stream set until no more merges occur in the merged stream set. The merge is completed and the merged stream set is output.

[0037] Furthermore, the conditions for merging any two streams are:

[0038] Judgment condition 1: Determine whether the two streams to be merged have the same source node and destination node;

[0039] Judgment condition 2: judging whether the bandwidth of the two streams to be merged is within the range allowed by the network capacity after the two streams are merged;

[0040] Judgment condition 3: Determine whether the two streams to be merged have the same priority;

[0041] Judgment condition 4: judging whether the merged stream can meet the delay requirement after the two streams to be merged are merged;

[0042] Judgment condition 5: judging whether the two streams to be merged have the same protocol type;

[0043] Judgment condition 6: determine whether the periods of the two streams to be merged are multiples;

[0044] Judgment condition 7: judge whether the remaining jitter of the two to-be-merged streams is not less than 10% of the jitter requirement, and the calculation result of the remaining tolerable jitter is True; the jitter requirement is a system preset value;

[0045] The two streams to be merged must meet the judgment conditions 1 to 7 at the same time to be merged; if any of the judgment conditions is false, the merge cannot be performed; the transmission delay of the merged stream is the sum of the delays of all streams before the merge;

[0046] The calculation steps of the remaining tolerable jitter are as follows:

[0047] a): Obtain the initial jitter budget of the two streams to be merged;

[0048] The initial jitter budget is the maximum jitter range that the system can tolerate;

[0049] b): Obtain the theoretical jitter value after the two streams to be merged are merged;

[0050] The theoretical jitter value of the two streams to be merged after merging is the transmission delay of the two streams to be merged;

[0051] c): Calculate the remaining tolerable jitter after merging the two streams to be merged;

[0052] If the two streams to be merged are stream A and stream B, the remaining tolerable jitter includes the remaining tolerable jitter of stream A and the remaining tolerable jitter of stream B; the remaining tolerable jitter of stream A is the difference between the initial jitter budget of stream A and the transmission delay of stream B; the remaining tolerable jitter of stream B is the difference between the initial jitter budget of stream B and the transmission delay of stream A; if the remaining tolerable jitter of stream A and the remaining tolerable jitter of stream B are both greater than zero, True is returned; if either the remaining tolerable jitter of stream A or the remaining tolerable jitter of stream B does not satisfy the value greater than zero, False is returned.

[0053] Furthermore, the window definition constraints are:

[0054]

[0055] (φ (a,b) [k]≥0)∨(τ (a,b) [k] <T s )

[0056] Among them, W (a,b) is the maximum scheduling window number of link (a, b); φ (a,b) [k] is (a,b) The opening time of the kth window on the link; ε is the intermediate set of links in the system; τ (a,b) for (a,b) The closing time of the kth window on the link;

[0057] The window definition constraints ensure that the opening and closing of time windows are performed within a predefined super period to ensure the periodicity and determinism of scheduling;

[0058] The flow instance constraints are:

[0059]

[0060] Where S is the set of flows in the system; S i is the i-th stream; j is the j-th instance; T s is the super period of the link; T i Indicates the period of the message; for (a,b) The window index of the frame instance of the jth frame of the i-th flow above; the flow instance constraint ensures that the flow instance is transmitted within the specified time window to avoid congestion and delay of data packets;

[0061] The window sequence constraints are:

[0062]

[0063] (τ (a,b) [i]≤φ (a,b) [j])∨(τ (a,b)[j]≤φ (a,b) [i])

[0064] Where i is the i-th flow; the window sequence constraint prevents different time windows on the same link from overlapping to ensure the sequential and conflict-free transmission of data flows;

[0065] The window size constraints are:

[0066]

[0067] The window size constraint ensures that the transmission time window size of each data frame is appropriate and the interval between different frames meets the periodicity requirements of the flow;

[0068] The frame-window allocation constraints are:

[0069]

[0070] in, is the jth instance of the i-th flow of link (a, b); For flow S i The set of frame instances on link (a, b); is the jth instance of the i-th flow on link (a, b);

[0071] Ensure that data frames are correctly allocated to appropriate time windows to achieve efficient transmission.

[0072] The flow isolation constraints are:

[0073]

[0074] is the window index of the lth frame of the jth stream on link (y, a); is the window index of the kth frame of the ith flow on the link (x, a); (y, a) and (x, a) represent two links with the same destination node;

[0075] Stream isolation constraints ensure isolation between different data streams and avoid interference by arranging time windows.

[0076] The flow order constraints are:

[0077]

[0078] Among them, R i is the flow path; (v k ,v k+1 ) are two adjacent links on the propagation path of the i-th flow;

[0079] Stream order constraints ensure that data streams are transmitted in the correct order on different links, avoiding out-of-order transmission of data packets;

[0080] The end-to-end delay constraint is:

[0081]

[0082] Where n represents the flow S i The number of links in the propagation path, (v n-1 ,v n ) represents the flow S i The link where the last hop of flow S is located, (v1, v2) represents i The link where the first hop is located, L i is the maximum allowed end-to-end delay;

[0083] End-to-end delay constraints ensure that the transmission delay of data flows throughout the network meets specific requirements to support real-time applications.

[0084] The beneficial effects of the present invention are as follows: the technical solution of the present invention can effectively manage and optimize the data flow of large-scale time-sensitive networks, improve the real-time data transmission and the utilization efficiency of network resources; two groups of software using the flow merging method and not using the flow merging method are set as a control group for comparison, and the comparison indicators are respectively the scale of solving the problem and the planning time. Under the cascade topology, a comparative test is carried out on the number of constraints, and the results show that the number of constraints of the planning method using the flow merging method is reduced by 17%; and the execution time is reduced by 50%. BRIEF DESCRIPTION OF THE DRAWINGS

[0085] Figure 1 Schematic diagram of TSN network structure;

[0086] Figure 2 K-Shortest Paths Yen algorithm diagram;

[0087] Figure 3 Schematic diagram of 8 priority queues of Qbv gating mechanism;

[0088] Figure 4 Schematic diagram of network modeling;

[0089] Figure 5 Schematic diagram of streams and stream instances;

[0090] Figure 6 Flow and flow instance attribute relationship diagram;

[0091] Figure 7 Plan business process diagram;

[0092] Figure 8 Schematic diagram of stream merging processing;

[0093] Fig. 9 Schematic diagram of the change of network topology complexity in the pairwise merging mode; (a) is a schematic diagram of pairwise merging in the case of unicast; (b) is a schematic diagram of pairwise merging in the case of one multicast; (c) is a schematic diagram of pairwise merging in the case of multiple multicasts;

[0094] Fig.10 Flow merging flowchart;

[0095] Fig.11 Calculate the residual tolerable jitter flow chart;

[0096] Fig.12 Performance test results under two different topologies; (a) is a simple topology network diagram; (b) is a simple topology performance test result; (c) is a cascade topology network diagram; (d) is a cascade topology performance test result;

[0097] Fig.13 Solve the scale optimization test results;

[0098] Fig.14 Solving time optimization test results. DETAILED DESCRIPTION

[0099] The scheme adopted by the present invention is:

[0100] A method for generating a TSN gating schedule table for frame merging pre-processing includes the following steps:

[0101] Step 1: Build a time-sensitive network model;

[0102] The time-sensitive network model is as follows: G is the set of all objects in the network; N is the set of all nodes in the network; SW is the set of all switch nodes in the network; ES is the set of all end system nodes in the network; n i is the node in the network; L is the set of all links in the network; l i Links in the network;

[0103] The relationship of the time-sensitive network model G is:

[0104] G=<N,L> ; N =<SW,ND> ={n i} i=0,1,2...k;SW∈N;

[0105] n i ∈N i=0,1,2…k;L= <l i > i=0,1,2…k;l i ∈L i=0,1,2...k;

[0106] The flow in the time-sensitive network model G is a series of data packets from the source node to the destination node;

[0107] The flow model in the time-sensitive network model G is:

[0108] S is the set of all flows in the network; s i is the i-th flow in the network; I is the set of all flow instances in the network; i i is any flow instance in the network;

[0109] S={s i} i=0,1,2…k;

[0110] s i ∈S i=0,1,2…k;

[0111] I={i i} i=0,1,2…k;

[0112] i i ∈I i=0,1,2...k;

[0113] Each flow includes attributes, including flow ID, bandwidth, flow delay, flow jitter, flow size, flow period, source node, destination node, priority, flow length and priority;

[0114] In the time-sensitive network model, a flow usually consists of a source node periodically sending data packets, which propagate to the destination node along a predetermined path. In this process, the existence of each data packet on each link is regarded as a flow instance;

[0115] Step 2: Preprocess the stream before merging;

[0116] Preprocessing includes compression processing, encoding processing, flow identification and classification processing, normalization processing and residual jitter calculation; the residual jitter calculation must be performed after compression processing, encoding processing, flow identification and classification processing and normalization processing;

[0117] The compression process is to reduce the size of the stream by using a compression algorithm, such as GZIP, BZIP2 or LZ77, so that even if the size of the merged stream increases, it will not cause too much pressure on the processing capacity of the network device;

[0118] The encoding process is to process the stream using Huffman coding or AlphaMite coding, thereby reducing the length of the stream or changing the distribution characteristics of the stream;

[0119] The flow identification and classification process is as follows: traverse all flows and classify the flows into several categories according to the source address, destination address, cycle, priority and size of the flows; thus, different processing and merging strategies are adopted according to the flows of different categories;

[0120] The normalization process is to normalize the size of the stream to the same range; this makes the characteristics of the stream more uniform, which is more conducive to subsequent processing and merging;

[0121] The residual jitter is calculated as follows: the residual jitter of each flow is calculated, and the residual jitter is the maximum time variation range that the flow can tolerate while meeting the maximum delay requirement;

[0122] Step 3: Stream merging processing;

[0123] The specific steps of stream merging are:

[0124] Step 3.1: Generate a set of all flows and initialize a merged flow set, which is equal to the set of all flows;

[0125] Step 3.2: Traverse the merged stream collection;

[0126] In the merged stream set, randomly select two streams A and B and check whether they meet the merge condition:

[0127] If the merging condition is met, they are merged into a new stream C, and C is added to the merged stream set. Streams A and B are deleted from the merged stream set.

[0128] If the merge condition is not met, A and B are retained;

[0129] Repeat step 3.2, traverse the merged stream set, until no more merges occur in the merged stream set, then the merge is complete, and output the merged stream set;

[0130] The conditions for merging any two streams are:

[0131] Judgment condition 1: Determine whether the two streams to be merged have the same source node and destination node;

[0132] Judgment condition 2: judging whether the bandwidth of the two streams to be merged is within the range allowed by the network capacity after the two streams are merged;

[0133] Judgment condition 3: Determine whether the two streams to be merged have the same priority;

[0134] Judgment condition 4: judging whether the merged stream can meet the delay requirement after the two streams to be merged are merged;

[0135] Judgment condition 5: judging whether the two streams to be merged have the same protocol type;

[0136] Judgment condition 6: determine whether the periods of the two streams to be merged are multiples;

[0137] Judgment condition 7: judge whether the remaining jitter of the two to-be-merged streams is not less than 10% of the jitter requirement, and the calculation result of the remaining tolerable jitter is True; the jitter requirement is a system preset value;

[0138] The two streams to be merged must meet the judgment conditions 1 to 7 at the same time to be merged; if any of the judgment conditions is false, the merge cannot be performed; the transmission delay of the merged stream is the sum of the delays of all streams before the merge;

[0139] The calculation steps of the remaining tolerable jitter are as follows:

[0140] a): Obtain the initial jitter budget of the two streams to be merged;

[0141] The initial jitter budget is the maximum jitter range that the system can tolerate;

[0142] b): Obtain the theoretical jitter value after the two streams to be merged are merged;

[0143] The theoretical jitter value of the two streams to be merged after merging is the transmission delay of the two streams to be merged;

[0144] c): Calculate the remaining tolerable jitter after merging the two streams to be merged;

[0145] If the two streams to be merged are stream A and stream B, the remaining tolerable jitter includes the remaining tolerable jitter of stream A and the remaining tolerable jitter of stream B; the remaining tolerable jitter of stream A is the difference between the initial jitter budget of stream A and the transmission delay of stream B; the remaining tolerable jitter of stream B is the difference between the initial jitter budget of stream B and the transmission delay of stream A; if the remaining tolerable jitter of stream A and the remaining tolerable jitter of stream B are both greater than zero, True is returned; if any of the remaining tolerable jitter of stream A and the remaining tolerable jitter of stream B does not satisfy the value greater than zero, False is returned;

[0146] Step 3: Construct a gating schedule;

[0147] According to the set of merged flows, a gating schedule is constructed; the gating schedule needs to satisfy the gating schedule constraint conditions;

[0148] Gated scheduling constraints include window definition constraints, flow instance constraints, window sequence constraints, window size constraints, frame-window allocation constraints, flow isolation constraints, flow order constraints, and end-to-end delay constraints;

[0149] Use SMT (Satisfiability Modulo Theories) technology to define the constraints of network traffic and ensure that all constraints are met when generating the schedule. The purpose of the constraints is to ensure that the data flow in the network can be transmitted within a strict time window to meet the requirements of high accuracy and low latency.

[0150] The window definition constraints are:

[0151]

[0152] (φ (a,b) [k]≥0)∨(τ (a,b) [k] <T s )

[0153] Among them, W (a,b) is the maximum scheduling window number of link (a, b); φ (a,b) [k] is (a,b) The opening time of the kth window on the link; ε is the intermediate set of links in the system; τ (a,b) for (a,b) The closing time of the kth window on the link;

[0154] The window definition constraints ensure that the opening and closing of time windows are performed within a predefined super period to ensure the periodicity and determinism of scheduling;

[0155] The flow instance constraints are:

[0156]

[0157] Where S is the set of flows in the system; S i is the i-th stream; j is the j-th instance; T s is the super period of the link; T i Indicates the period of the message; for (a,b) The window index of the frame instance of the jth frame of the i-th flow above; the flow instance constraint ensures that the flow instance is transmitted within the specified time window to avoid congestion and delay of data packets;

[0158] The window sequence constraints are:

[0159]

[0160] (τ (a,b) [i]≤φ (a,b) [j])∨(τ (a,b) [j]≤φ (a,b) [i])

[0161] Where i is the i-th flow; the window sequence constraint prevents different time windows on the same link from overlapping to ensure the sequential and conflict-free transmission of data flows;

[0162] The window size constraints are:

[0163]

[0164] The window size constraint ensures that the transmission time window size of each data frame is appropriate and the interval between different frames meets the periodicity requirements of the flow;

[0165] The frame-window allocation constraints are:

[0166]

[0167] in, is the jth instance of the i-th stream; For flow S i The set of frame instances on link (a, b); is the jth instance of the i-th flow on link (a, b);

[0168] Ensure that data frames are correctly allocated to appropriate time windows to achieve efficient transmission.

[0169] The flow isolation constraints are:

[0170]

[0171] is the window index of the lth frame of the jth stream on link (y, a); is the window index of the kth frame of the ith flow on the link (x, a); (y, a) and (x, a) represent two links with the same destination node;

[0172] Stream isolation constraints ensure isolation between different data streams and avoid interference by arranging time windows.

[0173] The flow order constraints are:

[0174]

[0175] Among them, R i is the flow path; (v k ,v k+1 ) are two adjacent links on the propagation path of the i-th flow; the flow order constraint ensures that the transmission order of data flows on different links is correct and avoids out-of-order transmission of data packets;

[0176] The end-to-end delay constraint is:

[0177]

[0178] Where n represents the flow S i The number of links in the propagation path, (v n-1 ,v n ) represents the flow S i The link where the last hop of flow S is located, (v1, v2) represents i The link where the first hop is located, L i is the maximum allowed end-to-end delay;

[0179] End-to-end delay constraints ensure that the transmission delay of data flows throughout the network meets specific requirements to support real-time applications.

[0180] The present invention is further described below in conjunction with the accompanying drawings and embodiments.

[0181] The network component related modeling is as follows: Figure 4 As shown;

[0182] symbol significance relation G The collection of all objects in the network G=<N,L> N The set of all nodes in the network <![CDATA[N=<SW,ND>={n i } i=0,1,2...k]]> SW The collection of all switch nodes in the network SW∈N ES The collection of all end system nodes in the network ES∈N <![CDATA[n i ]]> A node in the network <![CDATA[n i ∈N i=0,1,2...k]]> L The collection of all links in the network <![CDATA[L=<l i > i=0,1,2...k]]> <![CDATA[l i ]]> A link in the network <![CDATA[l i ∈L i=0,1,2...k]]>

[0183] In time-sensitive networking (TSN), a flow is a series of related data packets from a source node to a destination node. Each flow has its own specific quality of service requirements, such as bandwidth, latency, jitter, etc.

[0184] The relevant modeling of the flow is as follows:

[0185] symbol significance relation S The collection of all flows in the network <![CDATA[S={s i } i=0,1,2...k]]> <![CDATA[s i ]]> A flow in the network <![CDATA[s i ∈S i=0,1,2...k <!-- 9 -->]]> I The collection of all flow instances in the network <![CDATA[I={i i } i=0,1,2...k]]> <![CDATA[i i ]]> A flow instance in the network <![CDATA[i i ∈I i=0,1,2...k]]>

[0186] In time-sensitive networking (TSN), a flow is usually composed of a source node periodically sending data packets, which propagate to the destination node along a predetermined path. In this process, the presence of each data packet on each link can be regarded as a flow instance.

[0187] Although each flow instance belongs to the same flow, they may have some specific attributes due to various factors in the network, such as link bandwidth, delay, jitter, etc.

[0188] Flow size: This refers to the total size of all packets in the flow. This parameter determines the time it takes for the flow to be transmitted in the network.

[0189] The period of the flow: This refers to how often the flow is sent. For example, a flow with a period of 100ms means that a new packet is sent every 100ms.

[0190] Flow delay requirement: This refers to the maximum allowed delay of the flow from the source node to the destination node. This parameter determines the quality of service requirement of the flow.

[0191] Jitter requirement of a stream: This refers to the maximum allowed variation in the delay of a stream. The smaller the jitter, the higher the quality of service of the stream.

[0192] Each flow is treated as a periodic task, whose size, period, delay requirement, and jitter requirement are clearly defined.

[0193] This patent proposes a TSN gating schedule generation method based on frame merging pre-processing. The method mainly includes the following key technical steps: Figure 7 As shown;

[0194] Traffic merging pre-processing:

[0195] The main function of this module is to perform preliminary analysis and preprocessing of all data flows in the network, including:

[0196] Compression: Reduce the size of the stream through compression algorithms such as GZIP, BZIP2 or LZ77, so that even if the size of the combined stream increases, it will not put too much pressure on the processing capacity of the network device.

[0197] Coding: Optimize the characteristics of the stream through coding. You can use Huffman coding or Alphamite coding to reduce the length of the stream or change the distribution characteristics of the stream.

[0198] Flow identification and classification: Identify each data flow according to its flow ID, and classify the flow into different categories according to its source, destination, cycle, priority, size and other characteristics. In this way, we can adopt different processing and merging strategies for different categories of flows.

[0199] Normalization: In some cases, we may need to normalize the characteristics of the stream. For example, we can normalize the size or length of all streams to the same range. This can make the characteristics of the stream more uniform and more conducive to subsequent processing and merging.

[0200] Residual jitter calculation: Calculate the residual jitter of each flow, which is an important parameter for flow merging decisions. Residual jitter refers to the maximum time variation range that a flow can tolerate while meeting the maximum delay requirement.

[0201] Stream merging: After calculating the residual jitter, we can merge the streams of the same category. The transmission delay of the new stream is the sum of the lengths of all the streams before merging.

[0202] In this way, we can effectively reduce the number of flows in the network, thereby reducing the burden on network devices, such as Figure 8 As shown;

[0203] Flow 1 (red) and flow 3 (yellow) are two flows with the same sending period, source node, and destination node. As mentioned above, the two flows can be merged if the jitter meets the tolerance requirements. The merged flow is flow 4 (pink). It is not difficult to see from the figure that under the original conditions, the network planning task needs to process 10 flow instances from 3 flows. Through flow merging, the solution scale of the network planning task is reduced to 2 flows and 6 flow instances. This is the simplest case in network planning (two end nodes, one switch), and the topology and period relationship in actual application scenarios are often more complex. In theory, the more complex the network topology and the more diverse the flow period, the better the optimization effect of the flow merging method on the network planning task.

[0204] The merging of streams is not a simple two-by-two merging. A reliable, time-deterministic, and jitter-tolerant algorithm should be designed. First, read the stream configuration file to generate a stream set, initialize an empty merged stream set, and then traverse the stream set to select two streams A and B to check whether they meet the merging conditions. If they do, merge them into a new stream C and update the stream set. Otherwise, keep the original stream. Repeat this process until all streams are processed, and finally output the merged stream set, such as Fig.10 As shown;

[0205] During the flow merging process, it is necessary to consider the following conditions to ensure that the merged flow can work properly and meet the system performance requirements:

[0206] Same source node and destination node: Ensure that data is sent from the same source node to the same destination node to avoid confusion on the data path.

[0207] Similar bandwidth requirements: The bandwidth of the merged stream should be within the range allowed by the network capacity to avoid congestion and data loss caused by insufficient bandwidth.

[0208] Same priority: Maintain the consistency of flow priorities to ensure that high-priority flows are not unfairly scheduled due to being merged with low-priority flows.

[0209] Similar delay requirements: Ensure that the merged stream can meet the delay requirements to avoid service quality degradation due to large delay differences.

[0210] Same protocol type: Make sure the streams use the same communication protocol to avoid protocol incompatibility issues.

[0211] Similar cycles: Ensure the consistency of the flow sending cycle to avoid scheduling confusion caused by inconsistent cycles.

[0212] Similar jitter requirements: Jitter refers to the variation in the interval between data packet transmissions. Similar jitter requirements ensure that the combined stream will not be affected in terms of real-time and stability during transmission due to large jitter differences.

[0213] By strictly checking these conditions, it can be ensured that the merged stream can be transmitted normally in the network and that there will be no performance degradation or service quality issues due to the merge. These conditions are set to maximize the preservation of the original characteristics and service quality of each stream during the process of merging streams.

[0214] The most important part of the entire merge condition judgment is the jitter calculation. It is very important to ensure that the jitter meets the requirements in TSN for the following reasons:

[0215] Ensure Quality of Service (QoS): Jitter directly affects the quality of service, especially for applications with high real-time requirements. By calculating the residual tolerable jitter, it can be ensured that the merged flow can still meet the quality of service requirements.

[0216] Avoid network congestion and data loss: If the jitter exceeds the tolerable range, it may cause the buffer on the receiving end to overflow or underfill, which may lead to data loss or increased latency. Calculating the remaining tolerable jitter can prevent these problems in advance.

[0217] Optimize network resource usage: Controlling jitter can improve the utilization efficiency of network resources and reduce the triggering of retransmission and congestion control mechanisms caused by jitter. Calculating the remaining tolerable jitter can help make more optimized decisions during the merging process.

[0218] Ensuring system determinism: A key goal of TSN is to provide deterministic network behavior. By calculating and controlling jitter, it is possible to ensure that the system maintains this determinism after merging flows.

[0219] The process of calculating the remaining tolerable jitter is as follows: Fig.11 As shown;

[0220] Initial setup: Get the initial jitter budget: The initial jitter budget for each flow is the maximum jitter range that the system can tolerate.

[0221] Monitoring and recording: Record the current jitter value: Monitor and record the current jitter value of each stream to be merged in real time.

[0222] Theoretical jitter calculation: Theoretical jitter estimation of the merged stream: Estimate the theoretical jitter value after merging through simulation or mathematical model.

[0223] Calculate the remaining tolerable jitter: Calculate the remaining tolerable jitter: Subtract the combined theoretical jitter from the initial jitter budget to obtain the remaining tolerable jitter.

[0224] Check the remaining tolerable jitter: If the remaining tolerable jitter is greater than zero, continue merging. If the remaining tolerable jitter is less than or equal to zero, stop merging or take other optimization measures.

[0225] Feedback and adjustment: Continuously adjust and optimize the jitter control strategy based on actual operating conditions and monitoring data.

[0226] SMT constraint definition:

[0227] The SMT (Satisfiability Modulo Theories) technology is used to define the constraints of network traffic to ensure that all constraints are met when generating the schedule. The purpose of the constraints is to ensure that the data flow in the network can be transmitted within a strict time window to meet the requirements of high accuracy and low latency. Each constraint has its specific role. The following are the constraints involved in solving the schedule:

[0228] Gated scheduling constraints include window definition constraints, flow instance constraints, window sequence constraints, window size constraints, frame-window allocation constraints, flow isolation constraints, flow order constraints, and end-to-end delay constraints;

[0229] Use SMT (Satisfiability Modulo Theories) technology to define the constraints of network traffic and ensure that all constraints are met when generating the schedule. The purpose of the constraints is to ensure that the data flow in the network can be transmitted within a strict time window to meet the requirements of high accuracy and low latency.

[0230] The window definition constraints are:

[0231]

[0232] (φ (a,b) [k]≥0)∨(τ (a,b) [k] <T s )

[0233] Among them, W (a,b) is the maximum scheduling window number of link (a, b); φ (a,b) [k] is (a,b) The opening time of the kth window on the link; ε is the intermediate set of links in the system; τ (a,b) for (a,b) The closing time of the kth window on the link;

[0234] The window definition constraints ensure that the opening and closing of time windows are performed within a predefined super period to ensure the periodicity and determinism of scheduling;

[0235] The flow instance constraints are:

[0236]

[0237] Where S is the set of flows in the system; S i is the i-th stream; j is the j-th instance; T s is the super period of the link; T i Indicates the period of the message; is the window index of the frame instance of the jth frame of the i-th flow on (a, b); the flow instance constraint ensures that the flow instance is transmitted within the specified time window to avoid congestion and delay of data packets;

[0238] The window sequence constraints are:

[0239]

[0240] (τ (a,b) [i]≤φ (a,b) [j])∨(τ (a,b) [j]≤φ (a,b) [i])

[0241] Where i is the i-th flow; the window sequence constraint prevents different time windows on the same link from overlapping to ensure the sequential and conflict-free transmission of data flows;

[0242] The window size constraints are:

[0243]

[0244] The window size constraint ensures that the transmission time window size of each data frame is appropriate and the interval between different frames meets the periodicity requirements of the flow;

[0245] The frame-window allocation constraints are:

[0246]

[0247] Among them, f i,j is the jth instance of the i-th stream; For flow S i The set of frame instances on link (a, b); is the jth instance of the i-th flow on link (a, b);

[0248] Ensure that data frames are correctly allocated to appropriate time windows to achieve efficient transmission.

[0249] The flow isolation constraints are:

[0250]

[0251] For Link (y,a) The window index of the lth frame of the jth stream; For Link (x,a) The window index of the kth frame of the i-th stream; (y ,a), (x,a) Represents two links with the same destination node;

[0252] Stream isolation constraints ensure isolation between different data streams and avoid interference by arranging time windows.

[0253] The flow order constraints are:

[0254]

[0255] Among them, R i is the flow path; (v k ,v k+1 ) are two adjacent links on the propagation path of the i-th flow;

[0256] Stream order constraints ensure that data streams are transmitted in the correct order on different links, avoiding out-of-order transmission of data packets;

[0257] The end-to-end delay constraint is:

[0258]

[0259] Where n represents the flow S i The number of links in the propagation path, ( vn-1,vn ) represents the flow S i The link where the last hop of

[0260] ( v1,v2 ) represents the flow S i The link where the first hop is located, L i is the maximum allowed end-to-end delay;

[0261] End-to-end delay constraints ensure that the transmission delay of data flows throughout the network meets specific requirements to support real-time applications.

Claims

1. A method for generating a TSN gating schedule table for frame merging pre-processing, characterized in that: The steps include: Step 1: Build a time-sensitive network model; Step 2: Preprocess the stream before merging; Preprocessing includes compression, encoding, flow identification and classification, normalization and residual jitter calculation; The residual jitter calculation must be performed after compression, encoding, stream identification, classification and normalization. Step 3: Stream merging processing; Merge the preprocessed streams to generate a merged stream set; Step 4: Construct a gating schedule; A gating schedule is constructed based on the merged flow set; the gating schedule satisfies the gating schedule constraint condition; Gated scheduling constraints include window definition constraints, flow instance constraints, window sequence constraints, window size constraints, frame-window allocation constraints, flow isolation constraints, flow order constraints, and end-to-end delay constraints.

2. The method for generating a TSN gating schedule table for frame merging pre-processing according to claim 1, characterized in that: The time-sensitive network model is as follows: G is the set of all objects in the network; N is the set of all nodes in the network; SW is the set of all switch nodes in the network; ES is the set of all end system nodes in the network; i is the node in the network; L is the set of all links in the network; l i Links in the network; The relationship of the time-sensitive network model G is: G=<N,L>;N=<SW,ND>={n i }i=0,1,2...k;SW∈N; n i ∈Mi=0,1,2…k;L=<l i >i=0,1,2…k;l i ∈Li=0,1,2...k; The flow in the time-sensitive network model G is a series of data packets from the source node to the destination node; The flow model in the time-sensitive network model G is: S is the set of all flows in the network; s i is the i-th flow in the network; I is the set of all flow instances in the network; i i is any flow instance in the network; S={s i }i=0,1,2…k; s i ∈Si=0,1,2…k; I={i i }i=0,1,2…k; i i ∈Ii=0,1,2...k; Each flow includes attributes, including flow ID, bandwidth, flow delay, flow jitter, flow size, flow period, source node, destination node, priority, flow length and priority; A flow instance is: a source node periodically sends data packets, which propagate to the destination node along a predetermined path. The existence of each data packet on each link is a flow instance.

3. The method for generating a TSN gating schedule table for frame merging pre-processing according to claim 1, characterized in that: The compression process is to reduce the size of the stream by using a compression algorithm; The encoding process is to process the stream using Huffman encoding or AlphaMite encoding; The flow identification and classification process is as follows: traverse all flows and classify the flows into several categories according to the source address, destination address, cycle, priority and size of the flows; The normalization process is to normalize the size of the stream to the same range, that is, to unify the size of all streams to the MTU maximum transmission unit according to the data transmission capability of the hardware; The residual jitter is calculated as follows: the residual jitter of each flow is calculated, and the residual jitter is the maximum time variation range that the flow can tolerate while meeting the maximum delay requirement.

4. The method for generating a TSN gating schedule table for frame merging pre-processing according to claim 1, characterized in that: The specific steps of the stream merging are: Step 3.1: Generate a set of all flows and initialize a merged flow set, which is equal to the set of all flows; Step 3.2: Traverse the merged stream collection; In the merged stream set, randomly select two streams A and B and check whether they meet the merge condition: If the merging condition is met, they are merged into a new stream C, and C is added to the merged stream set. Streams A and B are deleted from the merged stream set. If the merge condition is not met, A and B are retained; Repeat step 3.2 and traverse the merged stream set until no more merges occur in the merged stream set. The merge is completed and the merged stream set is output.

5. The method for generating a TSN gating schedule table for frame merging pre-processing according to claim 4, characterized in that: The conditions for merging any two streams are: Judgment condition 1: Determine whether the two streams to be merged have the same source node and destination node; Judgment condition 2: judging whether the bandwidth of the two streams to be merged is within the range allowed by the network capacity after the two streams are merged; Judgment condition 3: Determine whether the two streams to be merged have the same priority; Judgment condition 4: judging whether the merged stream can meet the delay requirement after the two streams to be merged are merged; Judgment condition 5: judging whether the two streams to be merged have the same protocol type; Judgment condition 6: determine whether the periods of the two streams to be merged are multiples; Judgment condition 7: judge whether the remaining jitter of the two to-be-merged streams is not less than 10% of the jitter requirement, and the calculation result of the remaining tolerable jitter is True; the jitter requirement is a system preset value; The two streams to be merged must simultaneously meet all of the judgment conditions 1 to 7 to be merged; If any of the judgment conditions is negative, the merge cannot be performed; the transmission delay of the merged stream is the sum of the delays of all streams before the merge; The calculation steps of the remaining tolerable jitter are as follows: a): Obtain the initial jitter budget of the two streams to be merged; The initial jitter budget is the maximum jitter range that the system can tolerate; b): Obtain the theoretical jitter value after the two streams to be merged are merged; The theoretical jitter value of the two streams to be merged after merging is the transmission delay of the two streams to be merged; c): Calculate the remaining tolerable jitter after merging the two streams to be merged; If the two streams to be merged are stream A and stream B, the remaining tolerable jitter includes the remaining tolerable jitter of stream A and the remaining tolerable jitter of stream B; the remaining tolerable jitter of stream A is the difference between the initial jitter budget of stream A and the transmission delay of stream B; the remaining tolerable jitter of stream B is the difference between the initial jitter budget of stream B and the transmission delay of stream A; if the remaining tolerable jitter of stream A and the remaining tolerable jitter of stream B are both greater than zero, True is returned; if either the remaining tolerable jitter of stream A or the remaining tolerable jitter of stream B does not satisfy the value greater than zero, False is returned.

6. The method for generating a TSN gating schedule table for frame merging pre-processing according to claim 1, characterized in that: The window definition constraints are: (f (a,b) [k]≥0)∨(τ (a,b) [k] <T s ) Among them, W (a,b) is the maximum scheduling window number of link (a, b); φ (a,b) [k] is (a,b) The opening time of the kth window on the link; ε is the intermediate set of links in the system; τ (a,b) for (a,b) The closing time of the kth window on the link; The window definition constraints ensure that the opening and closing of time windows are performed within a predefined super period to ensure the periodicity and determinism of scheduling; The flow instance constraints are: Where S is the set of flows in the system; S i is the i-th stream; j is the j-th instance; T s is the super period of the link; T i Indicates the period of the message; is the window index of the frame instance of the jth frame of the i-th flow on the link (a, b); the flow instance constraint ensures that the flow instance is transmitted within the specified time window to avoid congestion and delay of data packets; The window sequence constraints are: (t (a,b) [i]≤φ (a,b) [j])∨(τ (a,b) [j]≤φ (a,b) [i]) Where i is the i-th flow; the window sequence constraint prevents different time windows on the same link from overlapping to ensure the sequential and conflict-free transmission of data flows; The window size constraints are: The window size constraint ensures that the transmission time window size of each data frame is appropriate and the interval between different frames meets the periodicity requirements of the flow; The frame-window allocation constraints are: in, is the jth instance of the i-th flow of link (a, b); For flow S i The set of frame instances on link (a, b); is the jth instance of the i-th flow on link (a, b); Ensure that data frames are correctly allocated to appropriate time windows to achieve efficient transmission; The flow isolation constraints are: is the window index of the lth frame of the jth stream on link (y, a); is the window index of the kth frame of the ith flow on the link (x, a); (y, a) and (x, a) represent two links with the same destination node; Stream isolation constraints ensure isolation between different data streams to avoid interference by arranging time windows; The flow order constraints are: Among them, R i is the flow path; (v k ,v k+1 ) are two adjacent links on the propagation path of the i-th flow; Stream order constraints ensure that data streams are transmitted in the correct order on different links, avoiding out-of-order transmission of data packets; The end-to-end delay constraint is: Where n represents the flow S i The number of links in the propagation path, (v n-1 ,v n ) represents the flow S i The link where the last hop of flow S is located, (v1, v2) represents i The link where the first hop is located, L i is the maximum allowed end-to-end delay; End-to-end delay constraints ensure that the transmission delay of data flows throughout the network meets specific requirements to support real-time applications.

Images