Dynamic splitting method for data frames in guard band of time sensitive network

By dynamically splitting non-real-time control data frames in time-sensitive networks, the bandwidth waste of the guard band mechanism and the fragmentation overhead introduced by frame preemption are solved, achieving more efficient network transmission and real-time performance.

CN121691202APending Publication Date: 2026-03-17SHENYANG UNIVERSITY OF TECHNOLOGY
View PDF 4 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-12-22
Publication Date
2026-03-17

AI Technical Summary

Technical Problem

In existing time-sensitive networks, the guard band mechanism suffers from wasted bandwidth resources, and the fragmentation overhead introduced by the frame preemption mechanism leads to delayed transmission of real-time control data frames.

Method used

By calculating the transmittable data length and latest split threshold of non-real-time control data frames within the guard band, the splitting strategy is dynamically determined, optimizing the splitting position and preemption time of data frames within the guard band to reduce preemption overhead and improve network transmission efficiency.

Benefits of technology

Effectively utilize protection band bandwidth resources, reduce the negative impact of preemption overhead on real-time traffic, and improve network transmission efficiency and real-time performance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121691202A_ABST
    Figure CN121691202A_ABST
Patent Text Reader

Abstract

The invention discloses a dynamic splitting method for data frames in a guard band of a time-sensitive network, and relates to the field of Internet of Things. Comprising the following steps: calculating a transmittable data byte length of a non-real-time control data frame in a guard band; when a non-real-time control data frame enters a guard band, calculating the data byte length of an untransmitted part of the non-real-time control data frame; calculating a latest splitting threshold value of the non-real-time control data frame; and dynamically determining a splitting strategy of the non-real-time control data frame in the guard band according to the size relationship. On the basis of a frame preemption mechanism, splitting is carried out in a protection band in advance based on the length of a data frame, and the optimal splitting position of the data frame in the protection band is determined, and the optimal preemption moment is dynamically determined according to the size of the data frame, so that the preemption overhead is reduced, and the negative influence of the preemption overhead on real-time flow is eliminated; and the bandwidth resource utilization efficiency of the protection band is maximized.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of the Internet of Things (IoT), and more specifically to a method for dynamically splitting data frames within the guard band of a time-sensitive network. Background Technology

[0002] Time-Sensitive Networking (TSN) evolved from the audio and video bridging standard by the IEEE 802.1 working group. It aims to provide deterministic low-latency and low-jitter transmission for scenarios such as industrial automation, automotive electronics, and 5G slicing.

[0003] In TSN, there are three types of data frames: Time-Triggered (TT) control frames, Audio-Video Bridging (AVB) frames, and Best-Effort (BE) frames. TT control frames are used for safety-critical tasks and have strict time constraints on transmission latency. AVB frames are used for multimedia applications with relatively lower real-time requirements. Best-Effort frames are mainly used for non-real-time tasks and have the lowest real-time requirements. AVB and Best-Effort frames belong to the non-real-time control frame category. The Time-Aware Shaper, as one of the core technologies of TSN deterministic scheduling, proposes a guard band mechanism, such as... Figure 1 As shown, a complete transmission cycle is divided into a real-time control data frame area (T0), a non-real-time control data frame area (T1), and a guard band area (T2). The IEEE 802.3 standard specifies a maximum data frame length of 1518 bytes. Therefore, the guard band mechanism uses the 1518-byte T2 area to isolate the T0 and T1 areas. Non-real-time data frames that have not yet completed transmission can continue to be transmitted in the T2 area, but the T2 area does not allow the start of transmission of new non-real-time control data frames. This effectively avoids interference from non-real-time control data frames to the transmission of real-time control data frames.

[0004] However, the guard band mechanism suffers from significant waste of guard band bandwidth resources. Therefore, the IEEE 802.1Qbu protocol proposes a frame preemption mechanism, such as... Figure 1As shown, real-time control data frames preempt non-real-time control data frames for priority transmission. However, this preemption mechanism requires certain conditions to be met. When a preemption occurs, the non-real-time control data frame is fragmented into two segments. According to the IEEE 802.3 standard, each segment must meet the minimum data frame length to ensure that non-real-time control data frames can continue to be transmitted after the preemption occurs. Therefore, the T2 area only needs to be able to transmit non-real-time control data frames that do not meet the preemption mechanism's length requirement. This allows the T2 area, which is 1518 bytes long, to be shortened to 123 bytes, thereby reducing the waste of guard band bandwidth resources. However, the frame preemption mechanism introduces fragmentation overhead, causing a delay in the transmission of real-time control data frames. Summary of the Invention

[0005] In view of the shortcomings of the prior art, the present invention provides a dynamic splitting method for data frames in the guard band of a time-sensitive network, which can solve the problem of delayed transmission of real-time control data frames on the data frame transmission link due to fragmentation overhead, while maximizing the utilization of guard band bandwidth resources.

[0006] The technical solution of this invention is:

[0007] A method for dynamically splitting in-band data frames in a time-sensitive network, the method comprising the following steps:

[0008] Step 1: Calculate the length of data bytes that can be transmitted within the guard band for non-real-time control data frames. ;

[0009] Step 2: When a non-real-time control data frame enters the guard band, calculate the length of the untransmitted data bytes in the non-real-time control data frame. ;

[0010] Step 3: Calculate the latest splitting threshold for non-real-time control data frames. ;

[0011] Step 4: According to , as well as Based on the size relationship, the splitting strategy of non-real-time control data frames within the guard band is dynamically determined and split according to the splitting strategy.

[0012] Furthermore, according to the method described, the length of data bytes that a non-real-time control data frame can transmit within the guard band is... Equal to the length of the protection band in bytes, i.e. It equals 123 bytes.

[0013] Furthermore, according to the method, in step 3, the latest splitting threshold of the non-real-time control data frame is calculated. The method is as follows: First, define the structure of the non-real-time control data frame being preempted by the real-time control data frame and split into the first segment, the middle segment, and the tail segment; then, calculate the length of the remaining untransmitted data bytes after the non-real-time control data frame is split within the guard band according to equation (9); then, take the greater than or equal to sign in equation (9) when the equality sign is taken. The value is defined as the latest split threshold. Thus, the latest splitting threshold is derived. It is 157 bytes;

[0014]

[0015] Among them, the minimum byte length of the data frame 64 bytes; the number of data bytes transmitted within the guard band for non-real-time control data frames. Equal to 107 bytes; header byte length of non-real-time control data frames. It is 14 bytes.

[0016] Furthermore, according to the method, the first segment, the middle segment, and the last segment each include a frame header, a payload, a data check field, and an 8-byte physical field; wherein the frame header has a byte length... The payload is 14 bytes long. The data validation field is 46 bytes long. The minimum byte length is 4 bytes, so the minimum byte length of the first segment, the middle segment, and the tail segment is 64 bytes.

[0017] Furthermore, according to the method, the strategy for dynamically determining the splitting of non-real-time control data frames within the guard band in step 4 includes:

[0018] (1) If At this time, the non-real control data frames within the guard band will not be split, but the remaining untransmitted data will be transmitted directly within the guard band;

[0019] (2) If Then, the non-real-time control data frame is split at the latest time point. Perform the splitting; the latest splitting time point The length of data bytes transmitted within the guard band for non-real-time control data frames is [length missing]. The split must be triggered at the specified time, where Calculate according to formula (8);

[0020]

[0021] Among them, the size of bytes This refers to the splitting overhead that is introduced when non-real-time control data frames are split.

[0022] (3) If Then, according to equation (11), the optimal splitting time point of the non-real-time control data frame within the guard band is determined. :

[0023]

[0024] in, This refers to the start time of non-real-time control data frames within the guard band. This is to control the transmission rate of data frames on the data frame transmission link in a non-real-time manner.

[0025] Furthermore, according to the method described, at the optimal splitting time point The length of the remaining untransmitted portion of the split non-real-time control data frame in bytes must satisfy equation (12):

[0026]

[0027] in, This is the minimum byte length of a data frame as specified in IEEE 802.3.

[0028] Compared with the prior art, the present invention has the following beneficial effects:

[0029] Based on the frame preemption mechanism, the present invention splits the data frame in advance within the guard band according to the data frame length. By determining the optimal splitting position of the data frame within the guard band and dynamically determining the optimal preemption time according to the data frame size, the preemption overhead is reduced, the negative impact of preemption overhead on real-time traffic is eliminated, the utilization efficiency of guard band bandwidth resources is maximized, and network transmission efficiency and real-time performance are improved. Attached Figure Description

[0030] Figure 1 This is a diagram illustrating the core concept of the dynamic splitting method for in-band data frames in time-sensitive networks according to this embodiment.

[0031] Figure 2 This is a flowchart of the dynamic splitting method for data frames within the guard band of the time-sensitive network in this embodiment.

[0032] Figure 3 This is a schematic diagram of non-real-time control data frame fragmentation in this embodiment;

[0033] Figure 4 This is a schematic diagram of the non-real-time control data frame splitting in this embodiment. Detailed Implementation

[0034] To facilitate understanding of this application, a more comprehensive description of this application will be provided below with reference to the accompanying drawings.

[0035] Figure 1 This diagram illustrates the core concept of the dynamic splitting method for in-band data frames in time-sensitive networks according to this embodiment. Figure 2 This is a flowchart of the dynamic splitting method for in-band data frames in the time-sensitive network of this embodiment. For example... Figure 1 and Figure 2 As shown, the dynamic splitting method for in-band data frames in the time-sensitive network includes the following steps:

[0036] Step 1: Calculate the length of data bytes that can be transmitted within the guard band for non-real-time control data frames. .

[0037] According to the start time of the protective belt and the end time of the protective belt And based on the non-real-time control data frame transmission rate on the data frame transmission link Calculate the length of data bytes that can be transmitted within the guard band for non-real-time control data frames. :

[0038]

[0039] According to IEEE 802.1Qbu, the guard band length under the frame preemption mechanism is 123 bytes. Therefore, after calculation, the length of data bytes that a non-real-time control data frame can transmit within the guard band is... It will definitely be equal to the length of the protection band bytes, that is It equals 123 bytes.

[0040] Step 2: When a non-real-time control data frame enters the guard band, calculate the length of the untransmitted data bytes in the non-real-time control data frame. .

[0041] Step 3: Calculate the latest splitting threshold for non-real-time control data frames. .

[0042] According to IEEE 802.3, the byte length of all types of data frames must be greater than or equal to the minimum byte length of the data frame. (64 bytes). A non-real-time control data frame will be fragmented into two segments after being preempted once by a real-time control data frame. If the preemption mechanism occurs N times, the fragmented non-real-time control data frame segments will meet the minimum byte length requirement. Under the premise that it will be fragmented into N+1 segments, the structure of the fragmented non-real-time control data frame is as follows: Figure 3 As shown, in a fragmented non-real-time control data frame, the first segment is called the first segment, the last segment is called the last segment, and the other segments are called intermediate segments. The intermediate and last segments of the fragmented non-real-time control data frame do not need to be re-added with bytes of length. The 14-byte header of the non-real-time control data frame requires a 4-byte fixed-length temporary checksum (mCRC) to be added at the end of the first and middle segments. After the real-time control data frame is transmitted, the fragmented non-real-time control data frame is reassembled based on the mCRC to ensure the integrity of the entire non-real-time control data frame. The tail segment retains the original non-real-time control data frame's Data Checksum (FCS) field, which is used to verify the integrity of the entire non-real-time control data frame. The FCS field has a fixed length of 4 bytes, and its specific structure is as follows:

[0043] (1) First segment: Includes the non-real-time control data frame header, payload, temporary checksum, and 8-byte physical field. The 8-byte physical field is an additional field added by the physical layer in IEEE 802.3 to ensure frame transmission synchronization and boundary identification. This field is not included in the minimum byte length of the data frame specified by IEEE 802.3. A temporary checksum mCRC needs to be set at the end of the first segment of the fragmented non-real-time control data frame. The minimum byte length requirement for the first segment of the fragmented non-real-time control data frame is as follows (2):

[0044]

[0045] Among them, the byte length of the non-real-time control data frame header 14 bytes; length of the first segment payload bytes The length of the mCRC (temporary checksum) for the first segment is 46 bytes. It is 4 bytes.

[0046] (2) Intermediate Segmentation: A temporary checksum mCRC needs to be set at the end of the intermediate segment of the fragmented non-real-time control data frame. Therefore, the intermediate segment contains the payload, the temporary checksum, and an 8-byte physical field. The minimum byte length requirement for the intermediate segment of the fragmented non-real-time control data frame is given by formula (3):

[0047] Among them, the length of the intermediate segment payload bytes It is 60 bytes long, with the intermediate segment temporary check code mCRC byte length. It is 4 bytes.

[0048] (3) Tail Segment: The tail segment of the fragmented non-real-time control data frame retains the original non-real-time control data frame's data check field (FCS). Therefore, the tail segment includes the payload, the data check field, and an 8-byte physical field. The minimum byte length requirement for the tail segment of the fragmented non-real-time control data frame is given by formula (4):

[0049] Among them, the length of the tail segment payload bytes The length of the tail segment data verification field (FCS) is 60 bytes. It is 4 bytes.

[0050] IEEE 802.3 specifies the minimum idle transmission interval (in bytes) between data frames. The interval is 12 bytes. Therefore, when a non-real-time control data frame is fragmented, there will be a minimum idle transmission interval of 12 bytes between the first segment and the real-time control data frame. Therefore, when a real-time control data frame preempts a non-real-time control data frame, the non-real-time control data frame is fragmented into two segments: a first segment and a last segment. A 4-byte temporary checksum mCRC needs to be added to the end of the first segment. Simultaneously, a minimum idle transmission interval of 12 bytes exists between the first segment and the real-time control data frame. Therefore, the minimum idle transmission interval is 12 bytes. The 4-byte temporary checksum mCRC introduces a 16-byte fragmentation overhead. When a real-time control data frame preempts a non-real-time control data frame, the real-time control data frame cannot be transmitted immediately on the data frame transmission link. Instead, it must wait for the minimum idle transmission interval and the temporary checksum processing to complete before it can be transmitted.

[0051] To address the issue of delayed transmission of real-time control data frames on the data frame transmission link due to fragmentation overhead, this implementation method splits non-real-time control data frames within the guard band. Unlike the fragmentation described above, when a non-real-time control data frame is preempted by a real-time control data frame and fragmented, the entire non-real-time control data frame is lost if any segment is lost. However, when splitting the non-real-time control data frame, a separate data checksum field (FCS) is set at the end of the first and middle segments, dividing the non-real-time control data into several independent segments for transmission. Even if a segment is lost in subsequent transmissions, the previously transmitted segments are still retained. Furthermore, to verify the integrity of the split independent segments, a 14-byte non-real-time control data frame header is added to the beginning of the middle and end segments of the split non-real-time control data frame. The structure of the split non-real-time control data frame is as follows: Figure 4 As shown, the specific structure of each part is as follows:

[0052] (1) First segment: Includes the non-real-time control data frame header, payload, data check field, and 8-byte physical field. The 8-byte physical field is an additional field added by the physical layer in IEEE 802.3 to ensure frame transmission synchronization and boundary identification. This field is not included in the minimum byte length of the data frame specified by IEEE 802.3. The minimum byte length requirement for the first segment of the split non-real-time control data frame is as follows (5):

[0053]

[0054] Among them, the length of the frame header bytes of the non-real-time control data frame The payload length of the first segment is 14 bytes. The length of the first segment's data verification field is 46 bytes. It is 4 bytes.

[0055] (2) Intermediate Segment: A non-real-time control data frame header and a data verification field are set at the beginning and end of the intermediate segment of the split non-real-time control data frame, respectively. Therefore, the intermediate segment contains a non-real-time control data frame header, payload, data verification field, and an 8-byte physical field. The minimum byte length requirement for the intermediate segment of the split non-real-time control data frame is as follows: Formula (6):

[0056] Among them, the byte length of the non-real-time control data frame header It is 14 bytes, and the length of the intermediate segmented payload bytes is [not specified]. The length of the validation field in the middle segment is 46 bytes. It is 4 bytes.

[0057] (3) Tail Segment: A non-real-time control data frame header and a data check field are set at the beginning and end of the split non-real-time control data frame tail segment, respectively. Therefore, the tail segment includes a non-real-time control data frame header, payload, data check field, and 8-byte physical field. The minimum byte length requirement for the split non-real-time control data frame tail segment is as follows (7):

[0058] Among them, the byte length of the non-real-time control data frame header The length of the tail segment payload bytes is 14 bytes. The length of the tail segment data verification field is 46 bytes. It is 4 bytes.

[0059] IEEE 802.3 specifies the minimum idle transmission interval (in bytes) between data frames. Therefore, when a non-real-time control data frame is split, there will also be a minimum idle transmission interval of 12 bytes between the first segment and the real-time control data frame. When splitting non-real-time control data frames, a separate 4-byte data check field is set at the end of the first segment of the split non-real-time control data frame, so the minimum idle transmission interval is 12 bytes. Similar to the 4-byte data checksum field, this introduces a 16-byte splitting overhead. Therefore, non-real-time control data frames need to reserve 16 bytes of bandwidth before ending transmission within the guard band to eliminate the 16-byte splitting overhead. Thus, when the non-real-time control data frame is transmitted within the guard band with a length of [number of bytes], [the following is a separate, unrelated sentence:] The data must be split before a split can be triggered, and this moment is defined as the latest split time. ,in Calculate according to formula (8).

[0060]

[0061] in, This refers to the number of data bytes that can be transmitted within the guard band for non-real-time control data frames.

[0062] After a non-real-time control data frame is split within the guard band, the length of the remaining untransmitted bytes is equal to the number of untransmitted data bytes when the frame entered the guard band. Subtract the number of data bytes already transmitted within the guard band. Because splitting adds a 14-byte non-real-time control data frame header to the beginning of the middle and end segments of the split non-real-time control data frame, the remaining untransmitted portion of the frame after splitting within the guard band needs to have a new 14-byte non-real-time control data frame header added. Simultaneously, in accordance with IEEE 802.3's minimum byte length requirement for data frames... According to the regulations, the length of the remaining untransmitted data bytes after a non-real-time control data frame is split within the guard band must satisfy formula (9):

[0063]

[0064] When the greater than or equal to sign in equation (9) is taken as equal sign The value is defined as the latest split threshold. The latest split threshold can be derived. The size in bytes is as follows:

[0065]

[0066] The minimum byte length of the data frame It is 64 bytes. Equal to 107 bytes, the byte length of the header of a non-real-time control data frame. It is 14 bytes.

[0067] When a non-real-time control data frame enters the guard band, calculate the length of the data bytes in the untransmitted portion of the non-real-time control data frame. ,when When the frame size is 157 bytes, the non-real-time control data frame is split when 107 bytes are transmitted within the guard band. This reserves 16 bytes of bandwidth before the non-real-time control data frame completes its transmission within the guard band. This not only offsets the 16-byte splitting overhead but also ensures that the remaining untransmitted data portion of the non-real-time control data frame after splitting within the guard band has a length that exactly meets the minimum byte length requirement for data frames in the IEEE 802.3 standard. According to the regulations.

[0068] for A non-real-time control data frame can be split when 107 bytes are transmitted within the guard band; this moment is marked as the latest split time. And for If non-real-time control data frames are also split at the latest splitting time, the length of the remaining untransmitted data bytes after splitting will definitely not meet the IEEE 802.3 minimum byte length requirement for data frames. Therefore, the split point needs to be re-discussed, which will be discussed in detail in step 4.

[0069] Step 4: Based on the length of the remaining untransmitted data bytes when the non-real-time control data frame enters the guard band. Number of data bytes that can be transmitted within the guard band compared to non-real-time control data frames and the latest split threshold The size relationship is used to dynamically determine the method for splitting non-real-time control data frames within the guard band, such as... Figure 1 As shown:

[0070] like That is, when a non-real-time control data frame enters the guard band, if the length of the remaining untransmitted data bytes is less than or equal to the number of data bytes that the non-real-time control data frame can transmit within the guard band, the non-real-time control data frame will not be split within the guard band, but will directly transmit the remaining untransmitted data within the guard band.

[0071] like Then, the non-real-time control data frame is split at the latest time point. The data frame is split. This allows for a 16-byte bandwidth reserve before the non-real-time control data frame is fully transmitted within the guard band. This not only offsets the 16-byte splitting overhead but also ensures that the remaining untransmitted portion of the non-real-time control data frame, after being split within the guard band, has a byte length that exactly meets the minimum byte length M specified in the IEEE 802.3 standard for data frames.

[0072] like Then, according to formula (11), the optimal splitting time point of the non-real-time control data frame within the guard band is determined. :

[0073]

[0074] for Non-real-time control data frames not only need to be split within the guard band, but the optimal splitting time within the guard band also needs to be determined. If the splitting time is unreasonable, the following two problems may occur:

[0075] 1) Non-real-time control data frames are split too late within the guard band:

[0076] The length of the remaining untransmitted data bytes after a non-real-time control data frame is split within the guard band does not meet the minimum byte length requirement for data frames specified in EEE 802.3. Within the guard band, the middle and tail segments of the split non-real-time control data frame will each have a 4-byte non-real-time control data frame header added. And set a 4-byte data validation field Therefore, it is necessary to ensure that the length of the remaining untransmitted data bytes after the non-real-time control data frame is split meets the following requirements. + + ≥ .

[0077] For example, when a non-real-time control data frame enters the guard band, the length of the remaining untransmitted data bytes is... It is 140 bytes. If it's at the latest splitting time... If the data frame is split (i.e., the split is triggered when 107 bytes are transmitted within the guard band), then the remaining untransmitted data bytes after subtracting 107 bytes from 140 bytes is 33 bytes, which includes the payload. ) and data validation fields ( The length of bytes.

[0078] Meanwhile, this non-real-time control data frame was split at the latest time point. After the split, the remaining untransmitted data needs to have a 14-byte non-real-time control data frame header added. Therefore, the total length of the remaining untransmitted data after the split is the sum of 33 bytes and 14 bytes, or 47 bytes. This value does not meet the minimum byte length of a data frame specified by the IEEE 802.3 standard. (64 bytes).

[0079] 2) Non-real-time control data frames are prematurely split within the guard band:

[0080] If non-real-time control data frames are split after transmitting only a small amount of data within the guard band, it will result in a waste of guard band bandwidth resources.

[0081] For example, when a non-real-time control data frame enters the guard band, the length of the remaining untransmitted data in bytes... The data frame is 140 bytes. If the non-real-time control data frame is split after transmitting only 60 bytes within the guard band, the total length of the remaining untransmitted data is 94 bytes (i.e., ...). + + (bytes). If the non-real-time control data frame is split after transmitting 80 bytes within the guard band, the total length of the remaining untransmitted data is 74 bytes (i.e., ...). + + (74 bytes). Obviously, compared to transmitting only 60 bytes and then splitting, transmitting 80 bytes and then splitting makes fuller use of the guard band's bandwidth resources.

[0082] To accommodate both of these situations, for For non-real-time control data frames, an optimal splitting point should be found. As long as the length of the remaining untransmitted data bytes after the non-real-time control data frame is split is exactly equal to the minimum byte length of the data frame specified in IEEE 802.3. This ensures that the non-real-time control data frame utilizes the guard band bandwidth to the maximum extent. Therefore, the length of the remaining untransmitted data in the non-real-time control data frame split at the optimal splitting time point must satisfy equation (12):

[0083]

[0084] The length of the header bytes of the non-real-time control data frame The minimum byte length of a data frame is 14 bytes, as specified in IEEE 802.3. It is 64 bytes, so we can get Bytes, that is, the length of the payload bytes in the remaining untransmitted portion of data after a non-real-time control data frame is split within the guard band. Add data validation field The frame length is at least 50 bytes. Additionally, after a non-real-time control data frame is split within the guard band, the remaining untransmitted data is appended with a 14-byte non-real-time control data frame header. This ensures that the remaining untransmitted data after the non-real-time control data frame is split within the guard band is exactly equal to the minimum frame length specified in IEEE 802.3. Therefore, the optimal splitting time point of the non-real-time control data frame within the guard band is determined according to formula (11). :

[0085]

[0086] in, This refers to the start time of non-real-time control data frames within the guard band. This refers to the transmission rate of non-real-time control data frames on the data frame transmission link. When a non-real-time control data frame enters the guard band, the length of the untransmitted data bytes in that non-real-time control data frame is calculated. .

[0087] From the time when the non-real-time control data frame enters the guard band and begins transmission, after transmission ( After the time required for -50) bytes, the non-real-time control data frame is split, and the length of the remaining untransmitted data is 100 bytes. ,in The non-real-time control data frame header is 14 bytes, and the length of the remaining untransmitted data bytes just meets the minimum frame length requirement, which maximizes the use of guard band bandwidth resources and complies with the IEEE 802.3 standard.

[0088] It should be understood that, inspired by the technical concept of this invention, those skilled in the art can make various improvements or modifications based on the above content without departing from the scope of this invention, and these modifications still fall within the protection scope of this invention.

Claims

1. A method for dynamic splitting of a protection in-band data frame of a time sensitive network, characterized in that, The method comprises the following steps: Step 1: Calculate the length of data bytes that can be transmitted in the guard band for the non-real-time control data frame ; Step 2: Calculate the length of the data bytes of the non-real-time control data frame that are not transmitted when the non-real-time control data frame enters the guard band ; Step 3: Calculate the latest split threshold for non-real-time control data frames ; Step 4: According to the size relationship of , and , dynamically determine the splitting strategy of the non-real-time control data frame in the guard band.

2. The method of claim 1, wherein, Length of data bytes transmittable in the guard band for non-real-time control data frames is equal to the length of the guard band bytes, i.e. is equal to 123 bytes.

3. The method of claim 1, wherein, The step 3 calculates the latest split threshold of the non-real-time control data frame The method is: first, define the structure of the non-real-time control data frame split into the first segment, the middle segment and the tail segment by the real-time control data frame; then, calculate the data byte length of the remaining part of the non-real-time control data frame after the split in the guard band according to formula (9); Then the value of the equal-to-or-greater-than sign in formula (9) is defined as the latest split threshold value is defined as the latest split threshold value is defined as the latest split threshold is 157 bytes; ; Wherein, the minimum byte length of the data frame is 64 bytes; the number of data bytes transmitted in the guard band of the non-real-time control data frame is equal to 107 bytes; the byte length of the frame header of the non-real-time control data frame is 14 bytes.

4. The method of claim 3, wherein, The first segment, middle segment, and tail segment all include a frame header, payload, data checksum field, and an 8-byte physical field; the frame header's byte length... The payload is 14 bytes long. The data validation field is 46 bytes long. The minimum byte length is 4 bytes, so the minimum byte length of the first segment, the middle segment, and the tail segment is 64 bytes.

5. The method of claim 4, wherein, The dynamic determination of the splitting strategy of the non-real-time control data frame in the guard band in step 4 comprises: (1) If At this time, the non-real control data frames in the protection band are not split, but directly transmitted in the protection band to complete the remaining data transmission. (2) If , the non-real-time control data frame is split at the latest split time point ; the latest split time point is the time point at which the non-real-time control data frame must trigger the split when the length of the data bytes transmitted in the guard band is , wherein is calculated according to formula (8); ; wherein the byte size splitting overhead introduced when the non-real-time control data frame is split; (3) If then the optimal split point in time for the non-real-time control data frames within the guard band is determined according to equation (11) : ; wherein, is the start transmission time of the non-real-time control data frames in the guard band, is the transmission rate of the non-real-time control data frames over the data frame transmission link.

6. The method of claim 5, wherein, At the optimal split time point The byte length of the remaining untransmitted part of the split non-real-time control data frame needs to satisfy equation (12): ; wherein is the minimum byte length of a data frame as specified by IEEE 802.3.

Citation Information

Patent Citations

  • Time-sensitive network frame preemption optimization method combined with time-aware shaper

    CN115865824A

  • Flow scheduling method, device, equipment, medium and product

    CN120342970A

  • Frame preemption method, transmitting device and receiving device for transmitting node and receiving node in time-sensitive network

    CN120389835A

  • Time-sensitive networking time slot scheduling method, terminal and storage medium

    WO2022199007A1