Satellite communication high-speed data transmission method and system

Abstract

The present invention discloses a satellite communication high-speed data transmission method and system. The method includes: separating cached data content and length information to provide a basis for refined operations; introducing a predictive decision arbitration module based on opportunity cost when making transmission decisions; when length and time thresholds are triggered simultaneously, resulting in a decision conflict, calculating the weighted cost and selecting the optimal transmission based on the service quality level and system configuration weight; activating a stateful predictive byte splicing module when constructing data batches; intelligently performing elastic piggybacking or byte splicing operations based on the size of the overflow, and updating the status of the remaining length of the data packet after splicing. Through intelligent arbitration and adaptive batch generation, the present invention improves bus utilization and system throughput, while also taking into account the real-time and reliability of data transmission.

Description

Technical Field

[0001] The present invention belongs to the field of data transmission, and in particular to a satellite communication high-speed data transmission method and system. Background Art

[0002] With the rapid evolution of information technology, society's demand for data communications continues to grow. High-throughput satellites (HTS), at the forefront of modern satellite communication technology, have become critical infrastructure for building a seamless global network and bridging the digital divide, leveraging their core advantages of wide coverage, high bandwidth, high speed, and low latency. From providing high-speed internet access to remote areas, to supporting real-time cross-border video conferencing and remote high-definition medical diagnosis, to facilitating data backhaul for massive numbers of Internet of Things (IoT) devices, HTS are profoundly transforming every aspect of social production and daily life. Driven by these application scenarios, the load on satellite communication systems is increasing, posing severe challenges to data processing capabilities. Throughout the entire link, the baseband processing system within the ground station or user terminal is the core bottleneck for ensuring efficient and reliable data transmission. In such systems, the efficiency of data exchange within the system-on-chip (SoC) directly determines overall system performance. The Advanced eXtensible Interface (AXI) bus protocol, particularly its stream-oriented AXI4-STREAM protocol, has become the de facto standard for data exchange in such systems due to its high performance, high bandwidth, and low latency. Incorporating AXI Multi-channel Direct Memory Access (AXI MCDMA) technology, the system can establish a high-speed data channel between the baseband processing unit and the protocol processor. Therefore, designing and implementing a data transmission control method within this technical framework that can adapt to high-throughput, highly dynamic traffic flows, maximize hardware performance, and ensure the ultimate efficiency and reliability of data transmission, is of vital theoretical research significance and has enormous practical application value.

[0003] Currently, in the design of SoC data transmission based on AXI4-STREAM and AXI MCDMA, the industry has formed a relatively mature implementation solution. At the hardware level, a first-in-first-out queue (FIFO) is usually used as a data cache mechanism to build a data content cache area and a data length cache area respectively to temporarily store baseband data frames and their metadata of different lengths sent from the upstream demodulation module. At the flow control logic level, in order to balance the DMA transmission efficiency and data real-time performance, a batch transmission strategy based on dual-threshold triggering is generally adopted. This strategy mainly includes two trigger mechanisms: the first is length accumulation triggering. The system will continue to accumulate the total length of the data packets in the cache. When the nth data packet is received, the cumulative total length exceeds the preset maximum number of transmission bytes (Max length) triggers a DMA transfer. To ensure that the downstream DMA driver cache does not overflow, this transfer usually only contains the 1st to n-1th complete data packets. The second is a timeout wait trigger. If the data stream is relatively sparse, within the preset maximum wait time (Max waittime ), the cumulative length has not reached Max length When the threshold is reached, the system triggers a DMA transfer, sending all currently cached data packets at once to ensure real-time data delivery and prevent individual data packets from being delayed indefinitely. After being read out, the data is encapsulated by the standard AXI4-STREAM protocol module, generating a protocol data stream containing timing signals such as TVALID and TLAST, which is ultimately sent to the AXI MCDMA for processing.

[0004] However, while these conventional technical solutions work effectively in most scenarios, their inherent and deep-seated design flaws are exposed in the complex environment of high-throughput satellite communications, characterized by high dynamics, high load, and widely varying quality of service (QoS). This leads to a series of difficult-to-solve technical problems. These include: In complex scenarios where length and time thresholds are triggered simultaneously, the existing methods' rigid decision-making mechanisms lead to conflicting decisions that fail to balance throughput and latency, resulting in suboptimal overall system performance. Furthermore, when handling transmissions triggered by length exceeding the limit, the existing methods are unable to fine-tune the final packet that caused the overflow, resulting in inefficient batch building. Summary of the Invention

[0005] The purpose of the invention is to provide a satellite communication high-speed data transmission method and system, in order to solve at least one technical problem existing in the prior art.

[0006] A technical solution, a method for high-speed data transmission in satellite communication, wherein data from a baseband frame is stored in a first buffer and length information of the data is stored in a second buffer, comprising:

[0007] Calculate in real time the cumulative length of the data in the first buffer and the waiting time since the last transmission;

[0008] When the accumulated length exceeds the length threshold or the waiting time reaches the time threshold, a transmission instruction is generated;

[0009] extracting data and length information from the first buffer and the second buffer according to the transmission instruction, and constructing a data block to be sent;

[0010] Encapsulate the data block to be sent into an AXI4-STREAM protocol data stream and send it.

[0011] A satellite communication high-speed data transmission system, comprising:

[0012] a data buffer module configured to obtain an input baseband frame, store data from the baseband frame into a first buffer, and store length information of the data into a second buffer;

[0013] a state parameter calculation module, connected to the data cache module, and configured to calculate in real time the cumulative length of the data in the first cache and the waiting time since the last transmission;

[0014] a transmission decision module, connected to the state parameter calculation module, and configured to generate a transmission instruction when the accumulated length exceeds a length threshold or the waiting time reaches a time threshold;

[0015] a data batch generation module, connected to the data buffer module and the transmission decision module, and configured to extract data and length information from the first buffer and the second buffer according to the transmission instruction to construct a data block to be sent;

[0016] The protocol encapsulation and sending module is connected to the data batch generation module and is configured to encapsulate the data blocks to be sent into AXI4-STREAM protocol data streams and send them.

[0017] Beneficial effect: The present invention makes system resource allocation more reasonable through intelligent arbitration and adaptive batch generation, effectively reduces the load of the protocol processor at high data rates, improves bus utilization and system throughput, and takes into account the real-time and reliability of data transmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 A flowchart of the steps of a satellite communication high-speed data transmission method provided in an embodiment of the present application.

[0019] Figure 2 A flowchart of the steps for generating a transmission instruction provided in an embodiment of the present application.

[0020] Figure 3 A flowchart of the steps for calculating time-first cost and length-first cost provided in an embodiment of the present application.

[0021] Figure 4 A flowchart of the steps for constructing a data block to be sent provided in an embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0023] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0024] Research has found that existing methods use overly rigid decision-making mechanisms and lack the ability to intelligently arbitrate under complex constraints. When the rate and bursty nature of data flows cause both length and time thresholds to be triggered simultaneously, the system faces a decision-making dilemma. Unable to dynamically select the optimal transmission strategy based on the service's Quality of Service (QoS) and current system state, conventional designs typically make decisions based on fixed priorities (e.g., time priority). This one-size-fits-all approach is blind and ignores the opportunity costs of making different decisions. Forcing delivery based on time can significantly reduce bus utilization and throughput due to small data volumes. Forcing delivery based on length can unnecessarily delay a newly arrived high-priority, low-latency packet (such as a VoIP packet) in the next send window, thereby compromising its quality of service. This decision-making mechanism, which lacks the ability to dynamically balance throughput and latency and is unaware of data QoS, is inadequate for mixed traffic flows and fails to optimize overall system performance.

[0025] In addition, when dealing with length-triggered scenarios, existing methods have problems with inefficient batch construction and implicit head-of-line blocking. It does not have the ability to splice bytes and cannot maximize the use of the current transmission bandwidth. The resulting head-of-line blocking and bandwidth waste will seriously affect the efficiency and real-time performance of data transmission under high load. When the nth data packet causes a length overflow, simply discarding the packet and sending the first n-1 packets is a rough and inefficient strategy. On the one hand, if the overflow is extremely small (for example, only a few bytes), this processing method will give up sending an almost complete large data packet in order to adhere to the rigid length limit, resulting in a significant loss of throughput and fragmentation of subsequent processing. On the other hand, this method does not have the ability to perform refined operations on partial processing. It cannot accurately borrow a portion of bytes from the nth data packet to perfectly fill the current batch to achieve Max length This inability to splice data packets and memorize and process partially sent packets not only wastes bus bandwidth but also causes the delayed nth packet to effectively cause head-of-line blocking, increasing data processing jitter and uncertainty, and severely restricting the system's ultimate performance under high-speed, heavy-load conditions.

[0026] like Figure 1 As shown, a satellite communication high-speed data transmission method is proposed, comprising the following steps:

[0027] Data from the baseband frame is stored in a first buffer, and length information of the data is stored in a second buffer;

[0028] In this embodiment, the raw baseband frame data stream and its corresponding enable signal from the upstream module are obtained. While the enable signal is active, a counter is used to calculate the actual length (in bytes) of the raw baseband frame. The raw baseband frame data is written as a byte stream to a data content buffer (a first-in, first-out queue for data content), which serves as the primary buffer. As each data frame is written, the frame's data length is written as a separate integer value to a data length buffer (a data length FIFO, which may be a dual-port RAM with support for updates in hardware), which serves as the secondary buffer. This cache architecture, which separates data and metadata, is the foundation for subsequent complex decision-making and batch generation.

[0029] Calculate in real time the cumulative length of the data in the first buffer and the waiting time since the last transmission;

[0030] In this embodiment, each time new length information is written to the data length buffer, the state parameter calculation module is immediately triggered to use the data length information and metadata from the baseband frame to update or calculate the aggregate state parameter set used for decision-making in real time. The parameter set is stored in a set of hardware registers and includes at least the total number of data packets currently cached in the data length buffer, n, the cumulative total data length (cumulative total number of bytes) S of the n data packets currently cached. n , the waiting time since the last transmission (the number of clock cycles) and the service quality level of the latest incoming n-th data packet (obtained from the baseband frame metadata). The calculation process is as follows: read the current total number of packets n register value, add 1 to it through the adder to get the updated total number of packets n; read the current cumulative total length S n The register value is added to the aligned data length through the adder to obtain the updated cumulative total length S n ; Check the transmission completion flag. If the flag is high (indicating that a transmission has just been completed in the previous cycle), wait for time cnt The register is cleared; otherwise, its count value is increased by 1 to obtain the updated waiting time time cnt ; Parse the service quality level from the metadata field of the original baseband frame and store it in the current latest packet service level QoS n register.

[0031] When the accumulated length exceeds the length threshold or the waiting time reaches the time threshold, a transmission instruction is generated;

[0032] In this embodiment, the transmission decision module continuously monitors the aggregation state parameter set in each clock cycle, and when any of the preset trigger conditions (the cumulative total length S n >Maximum number of bytes transmitted Max length or waiting time cnt ≥Maximum waiting time Max waittime ), it enters the decision arbitration phase. If only a single condition is triggered, a clear single-trigger instruction is generated; if two conditions are triggered at the same time (decision conflict), the predictive decision arbitration module based on opportunity cost is called to aggregate the state parameter set and the system configuration weight (such as the delay weight W lat , throughput weight W thr ) to calculate, obtain the optimal post-arbitration transmission instruction, and output a unique, unambiguous final transmission decision instruction. This embodiment resolves decision conflicts and optimizes selection.

[0033] extracting data and length information from the first buffer and the second buffer according to the transmission instruction, and constructing a data block to be sent;

[0034] In this embodiment, according to the final transmission decision instruction, the data batch to be sent is extracted from the data content buffer and the data length buffer. waittime Send, then generate a data block containing all the current n data packets to be sent. If the instruction requires based on Max length When sending, the stateful predictive byte splicing module is activated, and elastic piggybacking or hardware byte splicing operations are performed according to the overflow amount to generate an optimized data block to be sent, and an entry in the data length buffer is updated when necessary. The processed data block to be sent and its final transmission length are output. This embodiment solves the problem of Max length The head-of-line blocking problem that may be caused by triggering

[0035] Encapsulate the data block to be sent into an AXI4-STREAM protocol data stream and send it.

[0036] In this embodiment, the data block to be sent and the final transmission length are read, the transmit logic is activated, and the data block to be sent is placed into the transmit buffer. The data in the data block to be sent (4 bytes at a time) is assigned to the transmit data (TDATA) signal on a clock cycle-by-clock basis, preparing for serialized output to the TDATA bus. The transmit valid (TVALID) signal is set high during the data valid period or as long as there is data in the transmit buffer. A counter counts from 0 to the final transmission length / 4-1. When and only when the counter reaches its maximum value, the transmit last (TLAST) signal is set high to mark the end of the data block. Specifically, the value (final transmission length / 4)-1 is loaded into the TLAST target count register. A successful transmission tick counter is incremented by one for each clock cycle in which TVALID and TREADY (transmit ready, from downstream) are simultaneously high. A hardware comparator continuously compares the successful transmission tick counter with the value in the TLAST target count register. When the two values ​​are equal, the TLAST signal is set high for one clock cycle. Combine all generated TDATA, TVALID, TLAST and other signals to generate AXI4-STREAM protocol data stream according to the AXI4-STREAM protocol specification, and send it to the downstream AXI MCDMA module through the physical interface.

[0037] like Figure 2 As shown, according to one aspect of the present application, generating a transmission instruction includes:

[0038] When the cumulative length and waiting time exceed their respective thresholds at the same time, it is determined to be a decision conflict;

[0039] In this embodiment, at each clock cycle, the aggregation state parameter set is read and compared with the preset system configuration parameters (including Max length Maxwaittime ) to compare and generate two Boolean signals of length trigger condition and time trigger condition in real time. The specific judgment conditions are: Length trigger condition (Trigger_L): When S n > Max length True when time trigger condition (Trigger_T): when time cnt ≥Max waittime True when !Trigger_L is true. Combinatorial logic is used to determine the trigger status. If only one of the two trigger conditions is true, a single-shot instruction containing the corresponding action (length-first (LENGTH_FIRST) or time-first (TIME_FIRST)) is generated. If both conditions are true, a decision conflict is determined. Specifically: if !Trigger_L and !Trigger_T are true, no instruction is generated and the waiting process continues. If Trigger_L and !Trigger_T are true, a single-shot instruction is generated with the instruction content {Action: LENGTH_FIRST, Count: n-1}. If !Trigger_L and Trigger_T are true, a single-shot instruction is generated with the instruction content {Action: TIME_FIRST, Count: n}. If Trigger_L and Trigger_T are true, a decision conflict is determined. ! is the logical NOT operator, !Trigger_L indicates that Trigger_L is false, Action represents the action taken in the trigger instruction, and Count is the count parameter value associated with the instruction.

[0040] To resolve decision conflicts, the arbitration module of predictive decision-making is activated;

[0041] The arbitration module generates a transmission instruction that maximizes the transmission efficiency by calculating and comparing the time priority cost and the length priority cost.

[0042] like Figure 3 As shown, in an optional embodiment, calculating the time-first cost and the length-first cost includes:

[0043] Calculate the time priority cost based on the quality of service level of the latest data packet in the current cache, the preset delay weight and throughput weight, and the cumulative length of all data packets in the current cache;

[0044] Optionally, the calculation of the time-first cost includes:

[0045] Determine the delay penalty value based on the service quality level of the latest data packet through the delay evaluation function;

[0046] Determine the throughput score based on the cumulative length of all packets;

[0047] Using the delay weight and throughput weight, the delay penalty value and the throughput score are weighted and summed to obtain the time priority cost.

[0048] The length-first cost is calculated based on the QoS level, delay weight, and throughput weight of the latest packet, as well as the cumulative length of packets other than the latest packet.

[0049] In this embodiment, a predictive decision arbitration module based on opportunity cost is started to resolve decision conflicts. n ,n,QoS n ) and system configuration weight (W lat , W thr ). Parallel calculation of the cost of the two decision branches: Computation time priority cost (Cost TimeFirst ) : Use QoS n As the address, query the delay penalty lookup table (LUT) to get the penalty value P lat ; Using the hardware reciprocal unit, S n Calculate the throughput score S thr_n = 1 / S n ; Calculate W in parallel through two hardware multipliers lat * P lat and W thr * S thr_n ; Add the above two products through the adder to get the final Cost TimeFirst :Cost TimeFirst =W lat ×f lat (QoS n )+W thr ×1 / S n ; where f lat (QoS n ) is based on the service level QoS n Function to evaluate delay penalty, high priority QoS n This will result in a very high delay penalty. Calculate the length-first cost (Cost LengthFirst ) : Use QoS n Query the delay benefit lookup table (LUT) and get a small delay cost P lat_next ; Similarly, by S n The total number of bytes S of the first n-1 data packets excluding the latest data packet is calculated by combining the length of the nth packet. n-1 , and calculate the throughput score S thr_n-1 = 1 / S n-1 ; Similarly, the final Cost is obtained through the multiplier and adder LengthFirst :Cost LengthFirst =Wlat ×f lat_next (QoS n )+W thr ×1 / S n-1 ; Wherein the delay opportunity cost evaluation function f lat_next (QoS n ) evaluates the benefit of leaving the high-priority packet until the next near-zero-delay transmission (a very small value). TimeFirst and Cost LengthFirst Input hardware comparator, if Cost TimeFirst <= Cost LengthFirst , time priority is selected; otherwise, length priority is selected. Based on the comparison result, a post-arbitration transmission instruction containing the optimal action (TIME_FIRST or LENGTH_FIRST) is generated. Its format is consistent with the one-shot instruction. A selector selects either the one-shot instruction or the post-arbitration transmission instruction as the final and only final transmission decision instruction.

[0050] In another embodiment of the present application, the transmission decision module continuously monitors the aggregated state parameter set provided by the state parameter calculation module. n Greater than the preset Max length , and the waiting time since the last transmission time cnt Also reached Max waittime When the decision conflict is determined, the system enters the decision conflict state and immediately starts the predictive decision arbitration process. After the decision conflict is determined, the arbitration module will start two independent hardware cost calculation units in parallel to calculate the opportunity cost of choosing different decision paths. Specifically: Calculate the time priority cost Cost TimeFirst :This cost aims to quantify the comprehensive benefits of sending all the current n packets immediately. Its calculation input includes: the service level QoS of the current latest packet n , the cumulative length of all packets S n , and the system configuration delay weight W lat and throughput weight W thr In this embodiment, QoS n It is mapped to the delay penalty value f through the preset delay penalty lookup table (LUT) lat (QoS n ), high priority QoS will correspond to a large penalty value. The final cost is calculated by the formula Cost TimeFirst =W lat ×f lat (QoS n )+W thr ×1 / S n Calculate the length priority cost. LengthFirst:This cost aims to quantify the comprehensive benefits of sending only the first n-1 packets to prioritize meeting the length limit. Its calculation input is similar, but the data length is S n-1 In addition, its delay cost term f lat_next (QoS n ) evaluates the opportunity cost of postponing the high-priority packet to the next time it is sent. If the packet is a high-priority packet, this cost value will be very high. The final cost is calculated by the formula Cost LengthFirst =W lat ×f lat_next (QoS n )+W thr ×1 / S n-1 Calculate the two cost values ​​Cost TimeFirst and Cost LengthFirst Input hardware comparator, if Cost TimeFirst <= Cost LengthFirst If the system finds that sending immediately is more profitable (or has a lower opportunity cost), the system will generate a post-arbitration transmission instruction with the content {Action: TIME_FIRST, Count: n}. Otherwise, the system will generate an instruction with the content {Action: LENGTH_FIRST, Count: n-1}. This instruction serves as the final transmission decision and is sent to the downstream data batch generation module.

[0051] For example, in a specific application, Max length =32000 bytes, Max waittime =50000 clock cycles, weight W lat =0.7, W thr =0.3. When S n =33000 bytes (composed of 22 packets of 1500 bytes), time cnt =50000, and the latest packet QoS n When it is the highest priority, f lat (QoS n ) to get a minimum value (such as 0.1, representing high returns), and f lat_next (QoS n ) is a maximum value (such as 100, representing high cost). Calculate Cost TimeFirst Much less than Cost LengthFirst Therefore, the system decides to send all 22 packets immediately, ensuring low latency for high-priority services. Through the above steps, this embodiment transforms the fuzzy decision conflict point into a quantifiable optimization problem, achieving an intelligent and dynamic trade-off between throughput and latency under complex constraints.

[0052] This embodiment introduces a predictive decision-making arbitration module based on opportunity costs, addressing the suboptimal performance issues inherent in existing technologies caused by rigid decision-making logic when dual thresholds of length and time are triggered. In mixed satellite communication scenarios, for example, when interactive video streaming (requiring low latency) and large file downloads (requiring high throughput) coexist and conflicting decision-making, this embodiment intelligently balances these issues. By assigning a high opportunity cost for delay to high-QoS packets, the system prioritizes immediate delivery, ensuring a consistent user experience during video conferencing. Conversely, for bulk data without specific latency requirements, the system prioritizes data that meets the length threshold to maximize the efficiency of single DMA transfers. This results in more rational system resource allocation and achieves Pareto optimality in overall performance under complex traffic loads.

[0053] like Figure 4 As shown, according to one aspect of the present application, constructing a data block to be sent includes:

[0054] determining whether the transmission instruction is generated because the accumulated length exceeds a length threshold or because the waiting time reaches a time threshold;

[0055] When it is determined that the transmission instruction is generated because the accumulated length exceeds the length threshold, the stateful predictive byte splicing module is activated and is responsible for generating the data block to be sent.

[0056] In this embodiment, a final transmission decision instruction is obtained, and data is prepared to be read from the data content buffer and the data length buffer. If the instruction is {Action: TIME_FIRST, Count: n}, the standard process is executed: all n length values ​​are read from the data length buffer, and each read length value is sent to an accumulator. After n cycles, the value in the accumulator is the final transmission length; the final transmission length is divided by 4 and loaded into a countdown counter. This counter accurately controls the read enable signal of the data content buffer to form a complete data block to be sent. If the instruction is {Action: LENGTH_FIRST, Count: n-1}, the stateful predictive byte splicing module is activated, and the final data block to be sent is output.

[0057] According to one aspect of the present application, a stateful predictive byte splicing module generates a data block to be sent, including:

[0058] Calculating an overflow amount exceeding a length threshold due to the addition of a latest data packet into the first buffer;

[0059] Determine whether the overflow amount is greater than zero and does not exceed a preset elastic margin; if so, construct all currently cached data packets, including the latest data packet, into a data block to be sent;

[0060] If the overflow amount is greater than the preset elastic margin, then: calculate the number of splicing bytes, where the number of splicing bytes is the difference between the length threshold and the cumulative length of other cached data packets except the latest data packet; based on the number of splicing bytes, merge all cached data packets except the latest data packet and part of the data content intercepted from the latest data packet to construct a data block to be sent.

[0061] The calculation here is the number of concatenated bytes that need to be read from the latest data packet to bring the total length of the data block to the length threshold. In other words, the concatenated bytes are the number of bytes that need to be read from the latest data packet to bring the total length of the data block to the length threshold. Alternatively, the difference between the length threshold and the cumulative length of all cached data packets excluding the latest data packet is calculated, and this difference is determined as the concatenated bytes; all cached data packets excluding the latest data packet are combined with the data content corresponding to the concatenated bytes read from the latest data packet to construct the data block to be sent.

[0062] In this embodiment, the length Size of the nth data packet is read. n , calculate the overflow amount Overflow = (S n-1 +Size n ) - Max length Get the system configuration elastic margin Margin_E. If 0 < Overflow ≤ Margin_E, then perform piggybacking: read the length and content of all n packets from the cache to generate a total length of S n The data block to be sent and the final transmission length S n ; If Overflow > Margin_E, perform byte splicing: read the length of the first n-1 packets from the data length buffer and calculate S n-1 ; Calculate the number of bytes that need to be spliced ​​from the nth packet Bytes To_Splice = Max length -S n-1 Start the special read control state machine and read the first n-1 complete data packets and their lengths from the data content buffer. Then the state machine enters the partial read state and reads the first bytes of the nth data packet. To_Splice bytes, merge the first n-1 complete packets and the header data of the nth packet to form a total length of Max length The final transmission length of the data block to be sent is Max length .

[0063] According to one aspect of the present application, after merging and constructing the data blocks to be sent, the method further includes:

[0064] Calculate the remaining length of the latest data packet after the partial data content is intercepted;

[0065] An update operation is performed on the second cache, and the length information corresponding to the latest data packet is modified to the remaining length.

[0066] In this embodiment, a read-modify-write operation is performed on the data length buffer: the length entry of the nth packet is changed from Size n Modify to the remaining length New Size_n = Size n - Bytes To_Splice The state machine issues an update instruction to the data length buffer (a dual-port RAM in hardware), containing the address to be updated (the location of the nth packet) and the new length value, completing the modification of the length of the entry. The output of this operation is the updated data length buffer, ensuring the correctness of the next decision.

[0067] In another embodiment of the present application, after receiving the length priority instruction, the number of packets (n-1) contained in the instruction is read, and the length Size of the nth packet is obtained from the second cache. n Calculate the overflow amount Overflow=(S n-1 +Size n )-Max length Overflow is compared with the system preset elastic margin Margin_E to decide whether to enter elastic piggybacking mode or byte splicing mode. If the judgment result is 0 < Overflow ≤ Margin_E, the first path is activated: in this embodiment, Margin_E can be set to 256 bytes, for example. The operation of the first path is very direct: the module will generate an instruction to read n data packets, read the data content and length information of all n packets from the first cache and the second cache, and together form a total length S n The data block to be sent. At the cost of an acceptable, small overlength, higher single transmission efficiency is achieved, avoiding unnecessary unpacking operations. If Overflow > Margin_E, the second path is activated: The second path aims to construct a length strictly equal to Max length Specifically, calculate the number of bytes to be intercepted from the nth packet, that is, the number of splicing bytes. The calculation method is: Bytes To_Splice =Max length -S n-1 The module controls the reading of the first n-1 complete data packets from the first buffer, and then reads the bytes from the starting position of the nth data packet. To_SpliceThe two parts of data are combined to form the final data block to be sent. After the data block is constructed, the module will immediately perform an update operation on the second cache (whose hardware is a dual-port RAM that supports read, modify and write). Specifically, the remaining length of the nth packet New Size_n =Size n -Bytes To_Splice ; Store the corresponding entry of the nth packet length in the second cache, and its value is from Size n Modify to New Size_n .

[0068] For example, in another specific application, Max length =32000 bytes, S n-1 =31500 bytes, Size n = 2000 bytes. Overflow is 1500 bytes, much larger than Margin_E. The module will calculate Bytes To_Splice = 32000 - 31500 = 500 bytes. Generate a data block of 32000 bytes, which contains the first n-1 complete packets plus the first 500 bytes of the nth packet. Calculate New Size_n = 2000 - 500 = 1500 bytes, and the length entry of the nth packet in the second cache is updated to 1500. Through the above steps, the head-of-line blocking problem caused by length triggering is solved, the bus utilization is maximized, and the state consistency and data integrity of the data stream between multiple transmissions are guaranteed.

[0069] This embodiment improves the transmission efficiency loss and unnecessary processing overhead caused by the existing technology that strictly adheres to the length threshold. This is achieved by introducing a configurable parameter called elastic margin and executing a larger batch of DMA transmission containing the overrun data packets when it is determined that the overflow amount does not exceed the margin. In actual satellite communication scenarios, the data packet length of the upper layer protocol (such as TCP / IP) is often large, for example, 1500 bytes. If Max lengthThe total length of the packet is 32,000 bytes. When the 22nd packet (total length 33,000 bytes) arrives, the conventional method will only send the first 21 packets (31,500 bytes), resulting in 500 bytes of idle bandwidth. However, under the condition that Overflow (1,000 bytes) is less than Margin_E (such as 2,048 bytes), this embodiment will choose to send all 33,000 bytes at one time. The transmission tasks that originally required two DMA interrupts and two protocol processor interactions to complete are merged into one, which reduces the CPU processing overhead per unit data volume, effectively reduces the load of the protocol processor at high data rates, and improves the overall stability and throughput of the system. It also solves the problems of head-of-line blocking and bus bandwidth waste caused by the inability of the existing technology to finely process overflow data packets. By accurately calculating Bytes To_Splice , and intercept part of the content from the latest data packet that caused the overflow to construct a data packet with a length strictly equal to Max length This technology improves bus utilization for each length-triggered DMA transfer and avoids wasted bytes in satellite communication links, where bandwidth is at a premium. By modifying the packet length information in the secondary cache, the system retains a memory of the remaining data fragments, ensuring the absolute integrity of the data stream. This allows the next transmission decision to be made based on the correctly updated system state, enabling seamless and lossless data continuation between multiple transmission batches. This ensures that data transmission maintains the highest efficiency and reliability even under the most extreme load conditions.

[0070] According to one aspect of the present application, the first cache is a first-in-first-out queue; the second cache is an updateable cache area that supports modifying the stored length information in the middle of the queue.

[0071] According to one aspect of the present application, before storing the data into the first cache and storing the length information into the second cache, data alignment preprocessing is also included:

[0072] Calculate the original length of the baseband frame;

[0073] According to the numerical characteristics of the original length, the preset padding data comparison table is queried to determine the number of bytes required for padding;

[0074] The filling data corresponding to the number of bytes required to be filled is appended to the baseband frame to form a byte-aligned data frame, wherein the byte-aligned data frame is the data to be stored in the first cache.

[0075] Optionally, before the padding data is appended to the baseband frame, synchronization delay processing is performed on the baseband frame and its corresponding frame valid signal; and the baseband frame after the synchronization delay processing is used to be spliced ​​with the padding data.

[0076] In this embodiment, according to the AXI4-STREAM bus width requirement (e.g., 4 bytes), the original baseband frame is padded with data to obtain a byte-aligned data frame and its corresponding aligned data length. Specifically, the byte counter i is started. data_en_cnt , the enable signal i data_en The counter increases by one for each clock cycle when the enable signal i is high. data_en When the falling edge of the counter i data_en_cnt The final count value is latched into the register to obtain the stable original baseband frame length Count_A. The lowest two digits of the actual length of the original baseband frame Count_A are used as the address to query the preset padding data number comparison table (LUT) or read-only memory (ROM) to obtain the number of 0 bytes Count_B required to achieve 4-byte alignment within a single clock cycle. For example, if the lowest two binary digits of Count_A are 01, the table shows that 3 0 bytes need to be padded. In order to solve the problem of subsequent signal timing misalignment caused by the single clock cycle delay introduced by calculating Count_B, the input synchronization delay method is used for processing. The input original baseband frame (i data ) and its enable signal i data_en Synchronize and delay one clock cycle to get the i after timing synchronization data_delay and i data_en_delay Specifically: the original baseband frame data stream i data Connect to the input of a set of D-type flip-flops; the frame valid signal i data_en Connect to the input of another D-type flip-flop; use a unified system clock to drive all the above flip-flops, and on the rising edge of the next clock edge, obtain the data i that is delayed by one cycle and synchronized with the timing. data_delay and enable signal i data_en_delay . Use data selector (MUX) to merge data streams, in i data_en_delay Validity period, select i data_delay To output data, during the active period of the extended enable signal determined by Count_B (for example, a countdown counter loaded with the Count_B value), a constant zero level is selected as the output. The outputs of these two stages are concatenated to form a complete aligned data frame. Simultaneously, an adder calculates the aligned data frame with a total length of Count_A + Count_B, and its corresponding aligned data length. These steps not only achieve 4-byte alignment for baseband frames of arbitrary length, but also eliminate potential timing contention risks at the hardware level through synchronous delay design, ensuring the stability and reliability of data preprocessing.

[0077] This embodiment resolves the internal timing contention issue that may arise from inconsistent hardware pipeline processing delays, ensuring the stability and reliability of the data preprocessing stage. In high-speed digital circuit design using FPGAs or ASICs, calculating the number of padding bytes requires one or more clock cycles of search and calculation, and the resulting output timing lags behind the end timing of the original data stream. If left unaddressed, timing misalignment can lead to metastability or data sampling errors at the moment of data splicing, resulting in occasional data corruption that is difficult to debug. By synchronously inserting a delay equal to the calculation delay into the two faster paths—the original data stream and its enable signal—all signals involved in the final data splicing are precisely aligned on the same clock edge. This ensures that every data bit delivered to the core processing module is correct, avoiding error detection and retransmission in upper layers (such as TCP) caused by underlying data corruption, thereby ensuring the overall performance of the entire satellite communication link and the stability of the user experience.

[0078] According to one aspect of the present application, a satellite communication high-speed data transmission method includes: obtaining multiple input baseband frames, separating the data content and corresponding length information contained in the multiple baseband frames, and writing them into a data content buffer and a data length buffer respectively.

[0079] Specifically, a data content buffer (preferably a hardware FIFO) is used to temporarily store the data content of the byte-aligned data frames in byte order. Simultaneously, an independent data length buffer (preferably another FIFO) is used to store the total length of each data frame as an independent entry.

[0080] Based on the current status of the data content cache area and the data length cache area, the aggregation status parameter set is updated in real time, wherein the aggregation status parameter set includes at least the total number of data packets currently cached, the cumulative total data length of all cached data packets, and the waiting time since the last transmission.

[0081] Specifically, whenever a new length information is written into the data length buffer, the state parameter calculation module is immediately triggered to update a set of aggregated state parameters used for global decision-making in real time. This parameter set is stored in the hardware register and includes at least: the total number of packets currently buffered, n; the cumulative total number of bytes of all buffered packets, S; n ; and the number of clock cycles since the last successful DMA batch was sent, time cnt .

[0082] Continuously monitor the aggregation status parameter set. When the accumulated total data length exceeds the preset length threshold or the waiting time reaches the preset time threshold, the trigger condition is determined to be met and the final transmission decision instruction is generated.

[0083] Specifically, the transmission decision module continuously monitors the aggregation state parameter set in each clock cycle. The module makes judgments based on two preset thresholds: length threshold Max length and time threshold Max waittime When S n > Max length or time cnt ≥ Max waittime When any of the conditions are met, the module generates the final transmission decision instruction. Optionally, in the case of a decision conflict scenario where both conditions are met at the same time, a more advanced arbitration module can be activated to generate the optimal instruction.

[0084] In response to the final transmission decision instruction, corresponding data is extracted from the data content buffer and the data length buffer to construct a data block to be sent and its corresponding final transmission length.

[0085] Specifically, the data batch generation module extracts data from the first and second buffers in response to the decision instruction. If the instruction is triggered by time, the module reads all n packets in the current buffer to form the data block to be sent. If the instruction is triggered by length, the module reads the first n-1 packets. Preferably, a more advanced byte splicing module can be activated when the length is triggered to maximize efficiency. The module then outputs the finalized data block to be sent and the final transmission length.

[0086] The data block to be sent and the final transmission length are encapsulated into an AXI4-STREAM protocol data stream and sent to the downstream module.

[0087] Specifically, the protocol encapsulation and transmission module obtains the data block to be sent and the final transmission length. The data block contents are assigned to the TDATA signal on a clock-by-clock basis. The TVALID signal is pulled high during the data validity period, and the TLAST signal is set high when the last data beat is transmitted. All these signals together constitute the standard AXI4-STREAM protocol data stream, which is sent to the downstream AXI MCDMA controller. Through these steps, a complete closed-loop data processing process of caching, monitoring, deciding, building, and transmitting is established. This process converts unordered, arbitrary-length data streams into regular, efficient DMA transmission batches, providing a foundation for high-speed, reliable satellite communications.

[0088] According to one aspect of the present application, a satellite communication high-speed data transmission system is characterized by comprising:

[0089] a data buffer module configured to obtain an input baseband frame, store data from the baseband frame into a first buffer, and store length information of the data into a second buffer;

[0090] a state parameter calculation module, connected to the data cache module, and configured to calculate in real time the cumulative length of the data in the first cache and the waiting time since the last transmission;

[0091] a transmission decision module, connected to the state parameter calculation module, and configured to generate a transmission instruction when the accumulated length exceeds a length threshold or the waiting time reaches a time threshold;

[0092] a data batch generation module, connected to the data buffer module and the transmission decision module, and configured to extract data and length information from the first buffer and the second buffer according to the transmission instruction to construct a data block to be sent;

[0093] The protocol encapsulation and sending module is connected to the data batch generation module and is configured to encapsulate the data blocks to be sent into AXI4-STREAM protocol data streams and send them.

[0094] In a specific embodiment of the present application, a high-speed data transmission method for satellite communications based on the AXI4-STREAM protocol is provided to address the problem of DMA controller packet loss caused by untimely protocol processor interrupt processing. This method primarily meets the protocol processor interrupt processing time requirements by reducing the data transmission interval and increasing the data volume of each DMA transmission without reducing the data rate. On the one hand, a maximum data volume for each DMA data transmission is set to ensure that the data buffer within the DMA driver does not overflow during high-speed communication, thereby improving data transmission reliability. On the other hand, a maximum data transmission interval is set to ensure that data delay and jitter do not increase during low-speed communication, thereby improving the real-time performance of data transmission. This embodiment is developed based on an FPGA platform. The entire data processing process is as follows: the demodulated baseband frame data is sent to the data alignment module, which pads the baseband frame length with data zeros of different lengths, so that the total length of the baseband frame length plus the length of the padded data zeros is a multiple of 4. The 4-byte aligned data is sent to the data cache module, which stores the aligned data in the data content cache and the aligned data length in the data length cache. When data exists in the data content cache, the flow control module starts to determine whether the total data length written to the data length cache is greater than the maximum data length. length (Set the maximum number of bytes sent to AXI MCDMA each time), if the total data length of the data length buffer exceeds Max after the nth packet data is written length , then read the first package data to the n-1th package data from the data content buffer at one time; if the total data length of the data length buffer is less than Max length , but the time consumed has reached Max waittime(Set the maximum waiting time for each transmission to AXI MCDMA), then read the complete data of the first to nth packets from the data buffer at one time; the data read from the data content buffer is flow controlled and finally passes through the AXI4-STREAM protocol module to generate the corresponding data signal according to the AXI4-STREAM protocol.

[0095] The data alignment module is primarily used to align baseband frame data to 4 bytes, preparing for the AXI-STREAM protocol module to transmit 4 bytes of data in a single clock cycle. The AXI4-STREAM protocol sets the 4-byte data transmission per clock cycle for the following reasons: modern applications have high data transmission bandwidth requirements, and transmitting 4 bytes per clock cycle significantly improves bus efficiency and meets high-bandwidth demands. 4 bytes (32 bits) are a common unit of data alignment, and many processors and memories use 32 bits as the basic unit of operation, simplifying data alignment and transmission. Increasing the clock frequency increases power consumption and design complexity, while transmitting 4 bytes per clock cycle achieves high bandwidth at a lower frequency, reducing the problems associated with high-frequency clocks. The AXI-STREAM bus supports multiple data widths, with 4 bytes being a common configuration. This design incorporates flexibility to accommodate diverse usage scenarios.

[0096] The implementation process of the data alignment module is as follows: In the baseband frame enable i data_en During the high level period, a 16-bit counter i data_en_cnt Counting is performed, and the value of the counter is latched at the falling edge of the baseband frame enable. The latched counter value is recorded as Count_A and the counter value is cleared to 0. The number of data 0s that need to be filled is determined based on the lower two bits of the counter value Count_A. The number of data 0s that need to be filled is recorded as Count_B, as shown below: when Count_A [1:0] is 0, Count_B is 0; when Count_A [1:0] is 1, Count_B is 3; when Count_A [1:0] is 2, Count_B is 2; when Count_A [1:0] is 3, Count_B is 1. The number of clock cycles of the extended signal Delay_A of the baseband frame enable is determined based on the number of filled data 0s Count_B. In terms of value, Delay_A=Count_B. Since the number of filled data 0s Count_B lags behind the output of the counter latch value Count_A by one clock cycle, the output of the Delay_A signal lags behind by one clock cycle, resulting in the baseband frame enable signal i data_en The end and start time of the extended signal Delay_A are not aligned and the baseband frame data i data The end and the start time of the padded data 0 are not aligned, so the baseband frame enable signal i data_en and baseband frame data signal idata At the same time, delay one clock cycle, i data_en The signal after one clock cycle is recorded as i data_en_delay ,i data The signal after one clock cycle is recorded as i data_delay , to solve the problem of data alignment module generating output enable o data_en and data o data Timing alignment problem. Output data enable o data_en It consists of two parts: one is the baseband frame enable signal i data_delay , the second is to extend the signal Delay_A, o data_en The clock cycle of continuous high level is Count_A+Count_B. Output data signal o data It also consists of two parts. When the baseband frame enable signal is high, the baseband frame data i is output. data_delay , when the Delay_A signal is high, the output data is 0.

[0097] The data cache module mainly stores the data length and data output by the data alignment module. The implementation process is as follows: two FIFO (First In First Out) IP cores are used to cache the data length and data respectively. For the data length FIFO cache, its FIFO write enable is the data enable output by the data alignment module. data_en The falling edge o data_neg The data length of the FIFO buffer data input is Count_A+Count_B. The read enable is generated by the flow control module, and the bit width of the read data is consistent with the input data bit width. For the data FIFO buffer, its FIFO write enable is the data enable of the data filling module data. data_en , data FIFO buffer data input is o data The read enable is generated by the flow control module. Since the FIFO data is 1 byte input and 4 bytes output, the read data width is 1 / 4 of the input data width.

[0098] The implementation process of the flow control module is as follows: when data is written into the data cache module, the number of input data packets is counted and recorded as Cnt n And the data packet length is accumulated, the result of the accumulation is S n , when the packet count Cnt n is n and the packet length is S n Greater than Max length When the data length FIFO read enable signal is generated, the signal duration is n-1 clock cycles, that is, the length of each of the first n-1 packets of data is read out, and each length information is accumulated to calculate the total length of n-1 packets of data, which is recorded as S n-1After the calculation is completed, a data content cache read enable signal is generated, and the signal duration is S n-1 / 4 clock cycles, that is, read the data content of the first n-1 packets, read 4 bytes of data in a single clock cycle, and send the read data content to the AXISTREAM protocol module. The next data transmission will start with the nth packet data. The following example illustrates the total amount of data transmission control logic:

[0099] Case 1: Assume that the length of each data packet is 1500Byte, Max length The value is 32000Byte. When n=21, S21=31500Byte, which is less than Max length When n=22, S22=33000Byte, which is greater than Max length , trigger the read data cache module mechanism. Read the 21-packet data length from the data length cache module and calculate the total length of the 21-packet data S21 as 31500Byte, read the data content cache, and read the enable signal data rd_en The duration is 31500 / 4=7875 clock cycles, and 4 bytes of data are output in a single clock cycle. When data is written into the data cache module, the number of input data packets is counted and recorded as Cnt n And the data packet length is accumulated, the result of the accumulation is S n , when the packet count Cnt n is n and the packet length is S n Less than Max length But the time since the last data was sent is time cnt =Max waittime When the data length FIFO read enable signal is generated, the signal duration is n clock cycles, each time a length information is read, it is accumulated to calculate the total length of n packets of data. After the calculation is completed, the data cache read enable signal is generated, and the signal duration is S n / 4 clock cycles, that is, reading the data content of the first n packets, and reading 4 bytes of data in a single clock cycle. The read data content is sent to the AXI STREAM protocol module.

[0100] Case 2: Assume that the length of each data packet is 1500Byte, Max length The value is 32000Byte, the interval between two data packets (the interval between the rising edges of each two data packets) is 5000 clock cycles, Max waittime The value is 52000. When starting from the rising edge of the first packet of data, after Max waittime After clock cycles (time cnt =Max waittime), a total of 10 complete data packets are stored in the data cache module. Read the 10 data packet lengths from the data length cache module and calculate the total length S10 of the 10 data packets to be 15000Byte, read the data content cache, and read the enable signal data rd_en The duration is 3750 clock cycles, and 4 bytes of data are output in a single clock cycle.

[0101] The implementation process of the AXI4-STREAM protocol module is as follows: the AXI4-STREAM interface is divided into master devices (Source) and slave devices (Sink), and the main signals are as follows: when the main signal is TVALID, the direction is from master to slave, and the master device sends it to indicate that the current data (TDATA, etc.) is valid; when the main signal is TREADY, the direction is from slave to master, and the slave device sends it to indicate that data can be received. Data transmission requires TVALID and TREADY to be high at the same time; when the main signal is TDATA[n:0], the direction is from master to slave, and the actual transmitted data has a configurable bit width; when the main signal is TLAST, the direction is from master to slave, marking the last data of the data packet; when the main signal is TKEEP[n:0], the direction is from master to slave, indicating the bytes to be retained in TDATA (used to prevent padding during data reduction); when the main signal is TDEST[p:0], the direction is from master to slave, and the destination identifier is used for multi-destination routing. The data transmission mechanism is as follows: Handshake condition: When TVALID and TREADY are both high at the rising edge of the clock, the data (TDATA, etc.) is successfully transmitted; Timing example: The master device sets TVALID = 1, and if the slave device is ready, it sets TREADY = 1. If the slave device is not ready (TREADY = 0), the master device must keep TVALID and TDATA unchanged until the transmission is completed; Flow control: Back pressure is achieved through TREADY, and the slave device can pause the data flow to prevent overflow. AXI4-STREAM protocol conversion: TVALID signal generation: Data read enable signal data generated in the flow control module rd_en When TREADY is high, it can be used as TVALID signal; since the data content data cache FIFO output is delayed by two clock cycles, the data read enable data rd_en It is necessary to delay two clock cycles to align with the data output; the data after the delay of two clock cycles rd_en_delay2 can be used as a TVALID signal. TDATA signal generation: The 4-byte data output by the data content cache FIFO can be used as a TDATA signal. It is necessary to pay attention to the definition of the big and small ends of the master and slave devices, which may involve byte order conversion. TKEEP signal generation: Since a single clock cycle is set to transmit 4 bytes of data, the TKEEP signal bit width is 4; in addition, the data alignment module aligns the 4-byte data, that is, the padded data 0 is also sent to the AXI MCDMA as valid data, and the TKEEP value is fixed to 15. TDEST signal generation: The TDEST signal can specify the channel for data transmission. AXI MCDMA supports a maximum of 16 channels, so the TDEST bit width is 4; the channel for data transmission needs to be agreed upon with the slave device. TLAST signal generation: The data read enable signal data generated in the flow control module rd_en The duration is S n / 4 clock cycles, when the read enable signal counts data rd_encnt The value is S n / 4-1, TLAST signal becomes high level; when read enable signal count data rd_encnt The value is S n When the AXI4-STREAM protocol signal is generated, the data will be sent to the AXI MCDMA.

[0102] This invention addresses the issue of conflicting decisions by introducing a predictive decision arbitration module based on opportunity costs. In the prior art, when both length and time thresholds are triggered simultaneously, the system can only make blind decisions based on a preset fixed priority. This invention intelligentizes and quantifies this decision-making process. Once a conflict is detected, the arbitration module calculates the costs of both options in parallel. By comparing these two precisely quantified opportunity costs, it makes the decision that truly best reflects the current interests. This transforms a passive, rigid decision point into an active, dynamic, data-driven optimization process, resolving the conflicting decision issue and optimizing overall system performance. A stateful, predictive byte splicing module provides a combined, refined solution. The introduction of an elastic piggybacking mechanism avoids the throughput loss caused by discarding a large data packet for minor overflows, improving the flexibility and efficiency of batch construction. Byte splicing eliminates the need to directly discard the last data packet, as in the prior art. Instead, the present invention precisely calculates the number of bytes required to fill the current batch to the length threshold, extracts this portion of data from the header of the last data packet, and merges it with the previous complete data packet to construct the most efficient data block with maximized length utilization. After the splicing is complete, an update operation is performed on the second buffer storing the length information, modifying the length of the partially sent packet to its remaining length. This ensures that the system does not lose track of data fragments, completely solves the problem of head-of-line blocking, and ensures that the entire data stream is processed with extreme efficiency and 100% integrity.

[0103] The preferred embodiments of the present invention are described in detail above. However, the present invention is not limited to the specific details in the above embodiments. Within the technical concept of the present invention, various equivalent transformations can be made to the technical solutions of the present invention, and these equivalent transformations all fall within the scope of protection of the present invention.

Claims

1. A method for high-speed data transmission in satellite communication, wherein: Data from a baseband frame is stored in a first buffer, and length information of the data is stored in a second buffer, which is characterized by including: Calculate in real time the cumulative length of the data in the first buffer and the waiting time since the last transmission; When the accumulated length exceeds the length threshold or the waiting time reaches the time threshold, a transmission instruction is generated; extracting data and length information from the first buffer and the second buffer according to the transmission instruction, and constructing a data block to be sent; Encapsulate the data block to be sent into an AXI4-STREAM protocol data stream and send it; Generate transfer instructions, including: When the cumulative length and waiting time exceed their respective thresholds at the same time, it is determined to be a decision conflict; To resolve decision conflicts, the arbitration module of predictive decision-making is activated; The arbitration module generates a transmission instruction that maximizes the transmission efficiency by calculating and comparing the time priority cost and the length priority cost.

2. The method according to claim 1, characterized in that Calculate time-first cost and length-first cost, including: Calculate the time priority cost based on the quality of service level of the latest data packet in the current cache, the preset delay weight and throughput weight, and the cumulative length of all data packets in the current cache; The length-first cost is calculated based on the QoS level, delay weight, and throughput weight of the latest packet, as well as the cumulative length of packets other than the latest packet.

3. The method according to claim 2, characterized in that The calculation of time priority cost includes: Determine the delay penalty value based on the service quality level of the latest data packet through the delay evaluation function; Determine the throughput score based on the cumulative length of all packets; Using the delay weight and throughput weight, the delay penalty value and the throughput score are weighted and summed to obtain the time priority cost.

4. The method according to claim 1, wherein Construct the data block to be sent, including: determining whether the transmission instruction is generated because the accumulated length exceeds a length threshold or because the waiting time reaches a time threshold; When it is determined that the transmission instruction is generated because the accumulated length exceeds the length threshold, the stateful predictive byte splicing module is activated and is responsible for generating the data block to be sent.

5. The method according to claim 4, characterized in that The stateful predictive byte splicing module generates the data blocks to be sent, including: Calculating an overflow amount exceeding a length threshold due to the addition of a latest data packet into the first buffer; Determine whether the overflow amount is greater than zero and does not exceed a preset elastic margin; if so, construct all currently cached data packets including the latest data packet into a data block to be sent.

6. The method according to claim 4, characterized in that The stateful predictive byte splicing module generates data blocks to be sent, and also includes: Calculating an overflow amount exceeding a length threshold due to the addition of a latest data packet into the first buffer; If the overflow is greater than the preset elastic margin, then: Calculate the number of spliced ​​bytes, where the number of spliced ​​bytes is the difference between the length threshold and the cumulative length of other cached data packets except the latest data packet; Based on the number of concatenated bytes, all cached data packets except the latest data packet and part of the data content intercepted from the latest data packet are combined to form a data block to be sent.

7. The method according to claim 6, characterized in that After merging and building the data blocks to be sent, it also includes: Calculate the remaining length of the latest data packet after the partial data content is intercepted; An update operation is performed on the second cache, and the length information corresponding to the latest data packet is modified to the remaining length.

8. The method according to claim 1, wherein: The first cache is a first-in-first-out queue; The second buffer is an updateable buffer area that supports modifying the stored length information in the middle of the queue.

9. A satellite communication high-speed data transmission system, characterized in that: include: a data buffer module configured to obtain an input baseband frame, store data from the baseband frame into a first buffer, and store length information of the data into a second buffer; a state parameter calculation module, connected to the data cache module, and configured to calculate in real time the cumulative length of the data in the first cache and the waiting time since the last transmission; The transmission decision module is connected to the state parameter calculation module and is configured to generate a transmission instruction when the cumulative length exceeds a length threshold or the waiting time reaches a time threshold. Specifically, when both the cumulative length and the waiting time exceed their respective thresholds, a decision conflict is determined. To resolve the decision conflict, the predictive decision arbitration module is activated. The arbitration module calculates and compares the time-priority cost and the length-priority cost to generate a transmission instruction that maximizes the transmission efficiency. a data batch generation module, connected to the data buffer module and the transmission decision module, and configured to extract data and length information from the first buffer and the second buffer according to the transmission instruction to construct a data block to be sent; The protocol encapsulation and sending module is connected to the data batch generation module and is configured to encapsulate the data blocks to be sent into AXI4-STREAM protocol data streams and send them.

Images