A two-way protocol conversion gateway system of MESH ad hoc network and satellite communication

Abstract

The application discloses a bidirectional protocol conversion gateway system of MESH ad hoc network and satellite communication, which firstly carries out integrity check and protocol analysis on heterogeneous network data through a hardware protocol conversion engine, carries out link quality evaluation by fusing cross-domain feedback, further carries out forward prediction on link state time sequence trend, generates a routing decision to actively guide path selection, and on the basis, dynamically weights the load fragmentation and mark sequence number according to the decision according to the service type, and encapsulates the target frame through hardware level field mapping. Finally, the cross-domain transmission is realized through the radio frequency channel, the retransmission coordination unit is monitored and fed back to form an adaptive closed loop of "evaluation-decision-fragmentation-encapsulation-feedback". In this way, the protocol conversion delay is significantly reduced, the link switching and bandwidth efficient utilization are realized, and the real-time and reliable communication of "broken link continuous connection" in extreme environment is ensured.

Description

Technical Field

[0001] This application relates to the field of wireless communication technology, and more specifically, to a bidirectional protocol conversion gateway system for MESH self-organizing networks and satellite communication. Background Technology

[0002] With the large-scale deployment of low-Earth orbit satellite constellations (such as Qianfan, Starlink, and Tiantong-1) and the widespread application of terrestrial mesh self-organizing network technology, wireless communication is gradually evolving towards a space-ground integrated approach. In extreme scenarios such as military operations, emergency rescue, and field exploration where there are "road, network, and power outages," a single communication method is insufficient to guarantee the continuous smooth operation of the command link: terrestrial mesh self-organizing networks have the advantages of flexible networking and low latency, but their coverage is limited and nodes are easily damaged; satellite communication has global coverage capabilities, but it is susceptible to electromagnetic interference and obstruction. Therefore, constructing a protocol conversion gateway solution that enables bidirectional interoperability between terrestrial mesh self-organizing networks and satellite communication has become a key technical requirement for ensuring "uninterrupted communication even when the link is broken," and is of great significance for improving the continuity and reliability of command and dispatch in complex environments.

[0003] Existing MESH self-organizing network and satellite communication protocol conversion gateway solutions typically use a software protocol stack as the core, employing a general-purpose processor to perform a serial processing flow of "unpacking-parsing-repackaging" on heterogeneous network data frames, and switching between ground links and satellite links according to preset static rules. However, such solutions have revealed several technical problems in engineering practice: On the one hand, the conversion process based on the software protocol stack relies on CPU layer-by-layer processing, and the single-frame conversion latency is generally higher than 100 milliseconds, making it difficult to meet the latency constraints of real-time command and dispatch. On the other hand, link switching decisions mostly adopt a passive mechanism triggered by thresholds, lacking the ability to predict the trend of channel quality changes. In the transient process of satellite signal interference or ground node damage, service interruptions are likely to occur, and dynamic aggregation and fragmentation by service type cannot be achieved when dual links coexist, resulting in low bandwidth utilization and insufficient reliability of critical command transmission. In addition, existing protocol conversion equipment is large in size and consumes a lot of power, making it difficult to integrate into miniaturized platforms such as soldier-carried terminals or UAV-mounted modules.

[0004] Therefore, an optimized bidirectional protocol conversion gateway system for MESH self-organizing networks and satellite communication is needed. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a bidirectional protocol conversion gateway system for MESH self-organizing networks and satellite communication.

[0006] According to one aspect of this application, a bidirectional protocol conversion gateway system for MESH self-organizing networks and satellite communication is provided, comprising: The data verification and parsing and link status assessment module is used to perform integrity verification and protocol parsing on the acquired heterogeneous network raw data stream through the hardware protocol conversion engine to obtain unified standard payload data, and to perform comprehensive link quality assessment by combining cross-domain transmission feedback messages to obtain link status characteristic parameters. The dynamic link routing prediction and decision module is used to predict and make decisions on the channel quality change trends of terrestrial ad hoc network links and satellite communication links based on link state characteristic parameters in order to obtain link routing decision instructions. The payload data aggregation, fragmentation and marking module is used to aggregate, fragment and mark sequence numbers of unified standard payload data according to dynamic weights of data types based on link routing decision instructions to obtain serialized payload data blocks to be encapsulated. The hardware-level cross-network protocol encapsulation module is used to perform hardware-level protocol field mapping encapsulation on the serialized payload data block to be encapsulated to obtain the target network encapsulated data frame according to the target network standard determined by the link routing decision instruction. The cross-domain transmission and transmission status closed-loop module is used to transmit the target network-encapsulated data frame across domains through the corresponding physical layer radio frequency channel, and to monitor the transmission status and packet loss retransmission behavior through the retransmission coordination unit to obtain cross-domain transmission feedback messages.

[0007] Compared with existing technologies, this application provides a bidirectional protocol conversion gateway system for MESH self-organizing networks and satellite communication. First, it uses a hardware protocol conversion engine to perform integrity verification and protocol parsing on heterogeneous network data, and integrates cross-domain feedback for link quality assessment. Then, it forward-predicts the link status timing trend to generate routing decisions and proactively guide path selection. Based on this, according to the decisions, the payload is dynamically weighted by service type, labeled with sequence numbers, and encapsulated into target frames through hardware-level field mapping. Finally, it is transmitted across domains via the radio frequency channel, with the retransmission coordination unit monitoring the closed loop and providing feedback to the evaluation stage, forming an adaptive closed loop of "evaluation—decision—fragmentation—encapsulation—feedback". This approach significantly reduces protocol conversion latency, achieves seamless link switching and efficient bandwidth utilization, and ensures real-time reliable communication even in extreme environments where "link loss does not interrupt connection". Attached Figure Description

[0008] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0009] Figure 1 This is a block diagram of a bidirectional protocol conversion gateway system for MESH self-organizing network and satellite communication according to an embodiment of this application; Figure 2 This is a schematic diagram of the data flow of a bidirectional protocol conversion gateway system for MESH self-organizing network and satellite communication according to an embodiment of this application; Figure 3 This is a block diagram of the data verification and parsing and link status assessment module in a bidirectional protocol conversion gateway system for MESH self-organizing network and satellite communication according to an embodiment of this application. Figure 4 This is a block diagram of a hardware-level cross-network protocol encapsulation module in a MESH self-organizing network and satellite communication bidirectional protocol conversion gateway system according to an embodiment of this application. Detailed Implementation

[0010] Hereinafter, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0011] As indicated in this application and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" are not specifically singular and may include plural forms. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0012] While this application makes various references to certain modules of the systems according to embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The modules described are merely illustrative, and different aspects of the systems and methods may use different modules.

[0013] Flowcharts are used in this application to illustrate the operations performed by the system according to embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0014] The technical solution of this application proposes a bidirectional protocol conversion gateway system for MESH self-organizing network and satellite communication. Figure 1 This is a block diagram of a bidirectional protocol conversion gateway system for MESH self-organizing networks and satellite communication according to an embodiment of this application. Figure 2 This is a schematic diagram of the data flow in a bidirectional protocol conversion gateway system for MESH self-organizing networks and satellite communication according to an embodiment of this application. Figure 1 and Figure 2As shown, the MESH self-organizing network and satellite communication bidirectional protocol conversion gateway system 300 according to an embodiment of this application includes: a data verification and parsing and link state evaluation module 310, used to perform integrity verification and protocol parsing on the acquired heterogeneous network raw data stream through a hardware protocol conversion engine to obtain unified standard payload data, and to perform comprehensive link quality evaluation in conjunction with cross-domain transmission feedback messages to obtain link state characteristic parameters; a dynamic link routing prediction and decision module 320, used to predict and decide on the channel quality change trend of the terrestrial self-organizing network link and the satellite communication link based on the link state characteristic parameters to obtain link routing decision instructions; and a payload data aggregation and analysis module 320. The fragmentation and marking module 330 is used to aggregate and fragment unified standard payload data according to data type dynamic weights and mark sequence numbers based on link routing decision instructions to obtain serialized payload data blocks to be encapsulated; the hardware-level cross-network protocol encapsulation module 340 is used to perform hardware-level protocol field mapping encapsulation on the serialized payload data blocks to be encapsulated according to the target network standard determined by the link routing decision instructions to obtain target network encapsulated data frames; the cross-domain transmission and transmission status closed-loop module 350 is used to transmit the target network encapsulated data frames across domains through the corresponding physical layer radio frequency channel, and monitor the transmission status and packet loss retransmission behavior through the retransmission coordination unit to obtain cross-domain transmission feedback messages.

[0015] Specifically, the data verification and link status assessment module 310 is used to perform integrity verification and protocol parsing on the acquired heterogeneous network raw data stream through a hardware protocol conversion engine to obtain unified standard payload data, and to perform a comprehensive link quality assessment in conjunction with cross-domain transmission feedback messages to obtain link status characteristic parameters. It should be understood that in the bidirectional protocol conversion gateway system for MESH self-organizing networks and satellite communication, there is a fundamental problem of communication standard separation between the ground self-organizing network terminal and the low-Earth orbit satellite constellation: the ground MESH self-organizing network uses proprietary or dedicated protocols, which are completely incompatible with satellite communication protocols (such as DVB-S2X / RCS2 protocol, Tiantong-1 proprietary protocol), resulting in the inability to directly interact with data. The heterogeneous network raw data stream comes from the physical layer interfaces of different network standards, and its frame structure, encoding method, and verification mechanism are different. Without integrity verification and protocol parsing, subsequent intelligent link selection, multi-link aggregation and fragmentation, and hardware-level protocol field mapping and encapsulation will not be able to obtain reliable and uniformly formatted payload data for processing. Meanwhile, the protocol conversion gateway needs to ensure the continuous operation of the command link under extreme environments such as "circuit outage, network outage, and power outage." This requires the gateway to be able to perceive the channel quality status of the terrestrial ad hoc network link and the satellite communication link in real time, providing quantitative basis for subsequent link routing decisions. Traditional software protocol stack conversion requires a complete process of "unpacking → parsing → repackaging," with a latency typically exceeding 100 milliseconds, which cannot meet the needs of real-time command and dispatch. Therefore, in the technical solution of this application, a hardware protocol conversion engine performs integrity verification and protocol parsing on the raw data streams of heterogeneous networks, unifying the raw data from different network standards into payload data in a standard format, providing a clean, reliable, and consistent data foundation for subsequent processing. Furthermore, it combines physical layer link quality information and cross-domain transmission feedback messages to perform a comprehensive evaluation of link quality, outputting quantified link status characteristic parameters, providing real-time channel quality input for the forward prediction and routing decisions of the intelligent link selection module.

[0016] Figure 3 This is a block diagram of the data verification and parsing and link state assessment module in a bidirectional protocol conversion gateway system for MESH self-organizing networks and satellite communication according to an embodiment of this application. Figure 3As shown, the data verification and parsing and link state assessment module 310 includes: a frame verification and data stripping unit 311, used to perform frame integrity verification on the error verification sequence in the original data stream of the heterogeneous network, and strip physical layer link quality data from the verified data stream to obtain verified payload and protocol data and physical layer link quality data; a link quality weighted fusion unit 312, used to perform weighted fusion on the signal-to-noise ratio and received signal strength parameters in the physical layer link quality data and the packet loss rate data in the cross-domain transmission feedback message to obtain link state characteristic parameters; and a protocol parsing and data standardization unit 313, used to perform protocol unpacking and payload standardization processing on the verified payload and protocol data to obtain unified standard payload data.

[0017] Specifically, the frame verification and data stripping unit 311 is used to perform frame integrity verification on the error check sequence in the heterogeneous network raw data stream, and to strip physical layer link quality data from the verified data stream to obtain the verified payload, protocol data, and physical layer link quality data. The heterogeneous network raw data stream includes a protocol header, communication service payload, physical layer link quality data, and an error check sequence; these four components constitute a complete heterogeneous network data frame. In this process, firstly, the error check sequence field at the end of the heterogeneous network raw data stream is located. This verification sequence uses a cyclic redundancy check mechanism to protect the integrity of the protocol header, communication service payload, and physical layer link quality data of the entire data frame. The hardware protocol conversion engine recalculates the checksum of the received data frame using a hardware-level cyclic redundancy check (CRC) accelerator within the FPGA. It then compares the calculated result bit-by-bit with the error check sequence carried in the data frame. If the comparison matches, the frame passes integrity verification, indicating that no bit flips or frame truncation occurred during transmission. If the comparison does not match, the frame is marked as invalid and discarded, not proceeding to the next processing step. For data streams that pass frame integrity verification, the physical layer link quality data field is precisely located and extracted from the data frame based on the offset information of each field recorded in the protocol header. This field contains real-time channel measurement parameters such as signal-to-noise ratio (SNR) and received signal strength (RSSI) collected by the physical layer interface. After the extraction operation, the remaining protocol header and communication service payload in the data frame together constitute the verified payload and protocol data, while the extracted physical layer link quality data is output as an independent data stream to the link quality weighted fusion unit. This stripping operation is implemented in the FPGA hardware pipeline through field offset registers and data selectors, without CPU involvement, ensuring a hardware-level processing speed with a single-frame processing latency of less than 10 milliseconds.

[0018] Specifically, the link quality weighted fusion unit 312 is used to perform weighted fusion of the signal-to-noise ratio (SNR) and received signal strength (RSSI) parameters in the physical layer link quality data with the packet loss rate data in the cross-domain transmission feedback message to obtain link state feature parameters. The physical layer link quality data includes the SNR and RSSI parameters collected in real time from the physical layer interface corresponding to the current frame. These two parameters reflect the instantaneous physical layer quality state of the radio frequency channel at the current moment. In this process, the three dimensions of link quality parameters—SNR, RSSI, and packet loss rate—are integrated into a scalarized link state feature parameter through weighted fusion operations in the FPGA hardware. Specifically, the SNR parameter is normalized to obtain a normalized SNR component, the received signal strength parameter is normalized to obtain a normalized received signal strength component, and the packet loss rate data is reverse normalized to obtain a normalized transmission reliability component (the higher the packet loss rate, the lower this component). Then, corresponding weighting coefficients are assigned to the three normalized components, and a linear weighted sum is performed to finally output the link state feature parameter. This process can be expressed by the following formula: in, This represents the link state characteristic parameter, which is a scalar value for the comprehensive link quality assessment after weighted fusion. This parameter represents the signal-to-noise ratio in physical layer link quality data, and its unit is decibels (dB). This represents the normalized reference value for the signal-to-noise ratio parameter, taken as the maximum measurable signal-to-noise ratio of the system design. This represents the received signal strength parameter in the physical layer link quality data, with the unit being decibels and milliwatts (dBm). The normalized reference value for the received signal strength parameter is taken as the maximum measurable received signal strength designed for the system. This represents the packet loss rate data in the cross-domain transmission feedback message. The value is a dimensionless value between 0 and 1, where 0 represents no packet loss and 1 represents all packets lost. Represents the weighting coefficients of the signal-to-noise ratio; Represents the weighting coefficients for the received signal strength components; The weighting coefficients represent the transmission reliability components; the three weighting coefficients satisfy the constraints. Its specific value is determined based on the business priority strategy configuration. For example, under a high reliability priority strategy, it can be increased. The value of is chosen to highlight the weight of packet loss rate in the overall evaluation. By performing the above weighted fusion operation within each frame processing cycle, the output link state feature parameters are... It serves as the core input parameter for the subsequent intelligent link selection module to predict link quality change trends and make routing decisions.

[0019] Specifically, the protocol parsing and data standardization unit 313 is used to perform protocol unpacking and payload standardization processing on the verified payload and protocol data to obtain unified standard payload data. In this process, the protocol identifier header field in the verified payload and protocol data is first read. The protocol type identifier code in the protocol identifier header determines the source network standard to which the data frame belongs—that is, whether it comes from a terrestrial MESH self-organizing network (a customized protocol or proprietary MESH protocol based on IEEE 802.11s) or a satellite communication network (such as the DVB-S2X / RCS2 protocol of the Qianfan constellation or the proprietary protocol of Tiantong-1). Based on the determination result of the protocol type identifier code, the corresponding network standard's protocol parsing template is loaded from the protocol parsing template library pre-stored on the FPGA chip. This template defines the offset, length, and encoding format of each field in the source protocol frame structure. Driven by the protocol parsing template, the hardware protocol conversion engine peels off the encapsulation headers of each layer of the source protocol layer by layer within the FPGA pipeline, including the link layer frame header, network layer packet header, transport layer segment header, and other protocol control information, ultimately extracting pure communication service payload data. Furthermore, since communication service payloads from different network standards differ in byte alignment, byte order (big-endian or little-endian), and padding rules, the extracted communication service payloads undergo byte order conversion, field alignment and zero padding, and length standardization to convert them into a standard payload format uniformly defined within the system. The unified standard payload data output after protocol depackaging and payload standardization eliminates protocol differences between heterogeneous network standards, providing a clean payload data stream with consistent format and no standard independence for subsequent multi-link aggregation and fragmentation, sequence number marking, and target network protocol encapsulation.

[0020] Specifically, the dynamic link routing prediction and decision module 320 is used to predict and decide on the channel quality change trends of the terrestrial ad hoc network link and the satellite communication link based on link state characteristic parameters to obtain link routing decision instructions. It should be understood that in a bidirectional protocol conversion gateway system for MESH ad hoc networks and satellite communication, the terrestrial ad hoc network link and the satellite communication link are in a continuously dynamically changing channel environment. In typical application scenarios such as military operations, emergency rescue, and field exploration, satellite signals may suddenly attenuate due to interference or obstruction, and terrestrial MESH network nodes may become unusable due to damage or exceeding distance. Communication link interruptions are often sudden and unpredictable. Existing systems cannot dynamically select transmission paths based on channel quality and task priority. When satellite signals are interfered with or obstructed, they cannot automatically switch to the terrestrial ad hoc network; when terrestrial nodes are damaged, they cannot quickly switch to the satellite link. If a traditional passive link switching strategy is adopted—that is, triggering the switching action only after the link has been completely interrupted—data loss and communication interruption will occur during the switching process, failing to meet the stringent requirements of battlefield command and dispatch for communication continuity. Therefore, in the technical solution of this application, by analyzing the time series of historical link quality data and extrapolating forward, the trend of quality deterioration can be predicted before the link is completely interrupted and the routing switching decision can be completed in advance, so as to ensure the continuous smooth operation of the command link in the extreme environment of "road disconnection, network disconnection, and power outage", and realize the redundant communication guarantee capability of "no interruption of connection when the link is interrupted".

[0021] In practice, the link state characteristic parameters are first updated in the state database to obtain a time-series link state evolution matrix. The link state database stores real-time quality parameters and historical statistics for each link, organized by time and link dimensions. Within each frame processing cycle, upon receiving a new link state characteristic parameter, the link state database appends this parameter to the corresponding link's historical time-series record queue according to its link identifier (terrestrial MESH ad hoc network link or satellite communication link) and the current timestamp. The link state database maintains independent time-series record queues for terrestrial ad hoc network links and satellite communication links, with each queue storing link state characteristic parameter values ​​from multiple consecutive frame processing cycles in chronological order, forming a historical sequence of quality changes for that link. When the accumulated historical data points in the time-series record queue reach a preset time-series window length, the link state database organizes the historical time-series records of the terrestrial ad hoc network links and satellite communication links into a matrix, forming a time-series link state evolution matrix. The row dimension of the matrix corresponds to each historical sampling moment on the time axis, and the column dimension corresponds to different link identifiers (including at least two columns: terrestrial self-organizing network links and satellite communication links). Each element in the matrix is ​​the link status feature parameter value of the corresponding time and the corresponding link.

[0022] Next, the historical trends of bidirectional links in the time-series link state evolution matrix are forward extrapolated to obtain the forward-predicted link quality assessment vector. In this process, independent forward extrapolation calculations are performed on the historical time-series data of the terrestrial ad hoc network link column and the satellite communication link column in the time-series link state evolution matrix. For each link, the forward extrapolation calculation is based on the link's position within the time-series window. The predicted link quality value for a given link after several frame processing cycles is calculated using historical link status characteristic parameters and trend extrapolation methods such as linear regression or weighted moving average. The forward extrapolation employs a weighted linear extrapolation approach, assigning higher weights to data from more recent moments within the time window to enhance the prediction's sensitivity to recent link quality changes. Specifically, the formula for calculating the forward prediction value of a terrestrial ad hoc network link is as follows: in, This indicates that the terrestrial ad hoc network link will be available at a future time. Forward predicted link quality value; This indicates the current state of the terrestrial ad hoc network link. The link state characteristic parameter value; This indicates the time step of the forward prediction, i.e., how many frame processing cycles are expected to predict the link quality in the future. Indicates the first The weighting coefficients of the differences between adjacent time points are such that the difference closer to the current time point has a larger weight, satisfying the following condition: (i.e., linearly increasing weights); Indicates the first The difference in the change of link state characteristic parameters between adjacent time points reflects the instantaneous rate of change of link quality within that time period.

[0023] The forward prediction values ​​for satellite communication links are calculated using the same method: in, Indicates the satellite communication link at a future time. The forward-predicted link quality value is calculated; the meanings of the remaining parameters are consistent with the corresponding parameters in the forward prediction formula for terrestrial ad hoc network links. After completing the forward extrapolation calculation for the two links, the predicted values ​​of the two links are combined into a forward-predicted link quality evaluation vector. This process can be expressed by the formula: in, This represents the forward-predicted link quality assessment vector, which includes the terrestrial ad hoc network link and the satellite communication link at future time points. The predicted quality assessment value. This vector comprehensively reflects the expected quality status of the bidirectional link at future moments and is the core input for subsequent routing decision comparison and judgment.

[0024] Furthermore, the forward-predicted link quality assessment vector is compared with a preset link blocking threshold to obtain the comparison result. The comparison result is then encoded into a routing pattern according to the service priority strategy to obtain a dynamic link routing decision instruction. In this process, firstly, the predicted quality value of each link in the forward-predicted link quality assessment vector is compared with the preset link blocking threshold. The preset link blocking threshold is a pre-configured lower limit for link quality. When the predicted quality value of a link is lower than this threshold, it indicates that the link is highly likely to deteriorate to an unusable state in the future. The comparison and determination process is as follows: [The text abruptly ends here, likely due to an incomplete sentence or missing information.] Is it below the preset link blocking threshold? ,as well as Is it below the preset link blocking threshold? This yields the availability comparison results for each bidirectional link. Specifically, the mathematical expression for the comparison determination is: in, This indicates the availability comparison result of the terrestrial ad hoc network link. A value of 1 indicates that the link is predicted to be available, and a value of 0 indicates that the link is predicted to be unavailable. The results of the satellite communication link availability comparison have the following meanings: correspond; This represents the preset link blocking threshold, which is the lower limit of link quality pre-configured by the system based on communication reliability requirements.

[0025] After obtaining the comparison results, routing mode encoding is performed on the comparison results according to the service priority strategy to obtain dynamic link routing decision instructions. The decision logic of routing mode encoding is based on pre-configured strategies (such as lowest latency priority, highest reliability priority, lowest power consumption priority), combined with the availability comparison results of bidirectional links to determine the routing mode. The specific decision logic is as follows: when the ground self-organizing network link is available ( And the satellite communication link is available. When both links are available, the decision is to activate multi-link aggregation mode. The routing mode is encoded as an aggregation mode instruction, and the unified standard payload data is transmitted in fragments through both links simultaneously to improve effective throughput. When the ground ad hoc network links are available ( And the satellite communication link is unavailable. When satellites are interfered with or the carrier-to-noise ratio is too low, the decision is to automatically switch to a MESH link, and the routing mode is encoded as a MESH single-link transmission command; when the ground ad hoc network link is unavailable ( And the satellite communication link is available. In scenarios where ground nodes are damaged or exceed the specified distance, the decision is to automatically switch to the satellite link, with the routing mode encoded as a satellite single-link transmission command. When both links are available and the service priority policy is configured as lowest latency priority, the MESH link is used preferentially in normal communication scenarios (due to its low latency and low cost), with the routing mode encoded as a MESH priority transmission command. In multi-link aggregation mode, the dynamic link routing decision command also includes link prediction score ratio information, which is determined by the ratio of the predicted quality values ​​of the two links in the forward predicted link quality evaluation vector. in, This represents the link prediction score ratio, which guides the subsequent multi-link aggregation and sharding module to calculate the load allocation weight according to the prediction quality of each link—links with higher prediction quality will carry a larger proportion of data shards.

[0026] Specifically, the payload data aggregation, fragmentation, and marking module 330 is used to aggregate, fragment, and mark sequence numbers of unified standard payload data according to dynamic weights based on data type, based on link routing decision instructions, to obtain serialized payload data blocks to be encapsulated. It should be understood that in multi-link aggregation mode, terrestrial MESH ad hoc network links and satellite communication links are available simultaneously. The system needs to aggregate the bandwidth of the two links to improve effective throughput, which requires unified standard payload data to be reasonably fragmented and allocated to various links for transmission. However, different service types have significantly different requirements for transmission quality: critical command data has extremely high reliability requirements, voice data is sensitive to latency, and video data has high bandwidth requirements. If a simple uniform fragmentation strategy is adopted, it cannot guarantee that critical command data will be transmitted preferentially through high-reliability links, nor can it fully utilize the differentiated transmission characteristics of each link. Furthermore, after data is fragmented and transmitted through different links, the receiving end needs to be able to correctly identify the ownership and order of each fragment in order to correctly reassemble the scattered data fragments into a complete original payload. Therefore, in the technical solution of this application, firstly, application-layer-aware intelligent fragmentation weight calculation is performed based on the data service type and the predicted link quality status to ensure priority transmission of critical instructions; secondly, the unified standard payload data is precisely segmented into fixed lengths according to the weight calculation results, allocating the payload data to the byte range that each link should carry; furthermore, a globally unique serialization tag and offset information are injected into each data fragment to ensure that the receiving end can correctly reassemble it. Through the above processing, the core function of dynamic fragmentation transmission according to data type in multi-link fusion capability is realized, solving the technical problem in the prior art of lacking the bandwidth aggregation capability of simultaneously utilizing terrestrial MESH and satellite links and being unable to achieve redundancy guarantee of "uninterrupted connection in case of link failure".

[0027] In practice, the process begins with identifying the service type of the unified standard payload data using deep packet inspection (DPI). This is then combined with the link prediction score ratio from the dynamic link routing decision instruction to perform a policy lookup table matching to obtain the link load sharding weight coefficient. During this process, DPI is used to identify the service type of the unified standard payload data. DPI is an application-layer-aware data analysis technique that performs in-depth analysis of the payload content of the unified standard payload data. By matching predefined service characteristic patterns (such as protocol port numbers, payload format feature codes, and packet size distribution characteristics), it determines the service type carried by the current payload data—including command data (critical command and control instructions), voice data (real-time voice call streams), and video data (video surveillance or image transmission streams). The service type identification result is output in the form of a service type identifier code.

[0028] After completing the service type identification, the ratio of the service type identifier code to the link prediction score in the dynamic link routing decision instruction is calculated. A strategy lookup table is used to determine the link load fragmentation weight coefficients. The strategy lookup table matching process is based on a pre-configured fragmentation strategy table. This table uses a service type identifier and a link prediction score ratio range as a joint index key, recording the load weights that should be allocated to each link for various service types under different link quality ratios. The specific strategy for dynamically adjusting fragmentation size and weight based on data type is as follows: critical command data is prioritized for transmission through high-reliability links, voice data is prioritized for transmission through low-latency links, and video data is prioritized for transmission through high-bandwidth links. Specifically, when the service type is critical command data, regardless of the link prediction score ratio, the system prioritizes the weight of links with higher reliability (i.e., links with larger predicted values ​​in the forward prediction link quality assessment vector); when the service type is voice data, the system prioritizes the weight of low-latency links (usually terrestrial MESH links due to their low-latency characteristics); and when the service type is video data, the system prioritizes the weight of high-bandwidth links. This process can be expressed by the following formula: in, This represents the load fragmentation weighting coefficient of the terrestrial self-organizing network link, which is the proportion of the unified standard payload data that should be allocated to the terrestrial MESH link for transmission. This represents the load fragmentation weighting coefficient of the satellite communication link, i.e., the proportion that should be allocated to satellite link transmission; The link prediction score ratio in the dynamic link routing decision instruction is determined by the ratio of the sum of the predicted values ​​of the terrestrial ad hoc network links and the predicted values ​​of the two links in the forward prediction link quality assessment vector. This represents the service type bias factor, determined by a policy lookup table based on the service type identifier code—when the service type is critical command data and the ground MESH link has higher reliability. Take the larger value, when the service type is video data and the satellite link bandwidth is greater. Take the smaller value when the service type is voice data and the ground MESH link latency is lower. Take the larger value. The two weighting coefficients satisfy the constraints. When the dynamic link routing decision instruction is a single-link transmission mode (MESH single link or satellite single link), the weight coefficient of the available link is set to 1, and the weight coefficient of the unavailable link is set to 0. All payload data is transmitted through the only available link.

[0029] Next, based on the link load fragmentation weighting coefficient, the unified standard payload data is segmented into fragmented payload data unit streams according to the byte length that each link should carry. In this process, firstly, the byte length that each link should carry is calculated based on the total byte length of the unified standard payload data and the link load fragmentation weighting coefficient. Let the total byte length of the unified standard payload data be... The length of bytes that a terrestrial ad hoc network link should carry is 1. The length of bytes that a satellite communication link should carry is Subsequently, based on the byte length that each link should carry, the unified standard payload data is segmented into fixed-length segments according to the configuration strategy. Specifically, the byte stream of the unified standard payload data is divided into segments starting from the first byte, according to the preset maximum byte length per segment. Perform sequential segmentation. Total byte length allocated to terrestrial ad hoc network links. Divided into Each segment, the total number of bytes allocated to the satellite communication link. Divided into Each link has a fragment. The formula for calculating the number of fragments for each link is: in, This indicates the number of fragments allocated to the terrestrial ad hoc network link; Indicates the number of fragments allocated to the satellite communication link; This indicates the preset maximum byte length of a single fragment, which is determined by the fragment size parameter in the aggregation strategy configuration; This indicates a rounding up operation to ensure that the payload data is completely overwritten. When the actual byte length of the last fragment is less than... At this time, the fragment is generated according to the actual remaining byte length, without additional padding. After the fragmentation operation is completed, the unified standard payload data is fragmented into a total of Each data fragment is divided into several data segments, arranged in the order of division to form a fragmented payload data unit stream. Each data fragment in the fragmented payload data unit stream is labeled according to its corresponding target link identifier. Each fragment is labeled as a terrestrial ad hoc network link transmission fragment, and then... Each fragment is labeled as a satellite communication link transmission fragment.

[0030] Then, using the global transaction identifier and fragment index number, serialization tag injection and offset appending are performed on each data fragment in the fragmented payload data unit stream to obtain a serialized payload data block to be encapsulated. In this process, firstly, a globally unique global transaction identifier is generated for the currently processed unified standard payload data. This identifier is used to mark that all fragments generated from the same original payload data belong to the same transmission transaction, ensuring that the receiving end can correctly associate multiple fragments arriving through different links with the same original data. Specifically, the global transaction identifier remains unique throughout the entire lifecycle of the protocol conversion gateway system and is generated using an incrementing counter or a combination of timestamps. After the global transaction identifier is generated, a fragment index number is sequentially assigned to each data fragment in the fragmented payload data unit stream. The fragment index number starts from 0 and increments sequentially, indicating the relative position order of the fragment in the original payload data. The serialization tag injection operation injects the global transaction identifier and fragment index number as a tag header into the beginning of each data fragment, forming a serialization tag structure.

[0031] To ensure that the receiving end can accurately place each fragment into the correct byte position in the original payload data during reassembly, the sequence number marking unit calculates and appends byte offset information to each data fragment. The byte offset of each fragment represents the starting byte position of that fragment's data within the original unified standard payload data, and its calculation formula is as follows: in, Indicates the first The byte offset of each fragment in the original uniform standard payload data; Indicates the first The actual byte length of each slice; when hour, This means that the offset of the first fragment is zero, and its starting position corresponds to the first byte of the original payload data. The offset information is appended to the end of each fragment serialization tag as a fixed-length field.

[0032] After the serialization tag injection and offset appending operations are completed, each data fragment consists of two parts: a serialization tag header (containing a global transaction identifier, fragment index number, byte offset, target link identifier, and total fragment count information) and a fragment payload data body. All data fragments that have undergone serialization tag injection and offset appending are rearranged according to their link affiliation—fragments belonging to the same target link are arranged together in fragment index number order—ultimately forming a serialized payload data block to be encapsulated.

[0033] Specifically, the hardware-level cross-network protocol encapsulation module 340 is used to perform hardware-level protocol field mapping encapsulation on the serialized payload data blocks to be encapsulated according to the target network standard determined by the link routing decision instruction, so as to obtain the target network encapsulated data frame. It should be understood that in the bidirectional protocol conversion gateway system between MESH self-organizing networks and satellite communication, although the serialized payload data blocks output by the payload data aggregation, fragmentation, and tagging module 330 have completed intelligent fragmentation and serialization tag injection with service type awareness, their data format is still the standard payload format uniformly defined within the system, and they do not yet have the ability to be directly transmitted on the target network's physical layer radio frequency channel. Terrestrial MESH self-organizing networks use proprietary or dedicated protocols (such as customized protocols based on IEEE 802.11s, proprietary MESH protocols, etc.), which are completely incompatible with satellite communication protocols (such as the DVB-S2X / RCS2 protocol of the Qianfan constellation, and the proprietary protocol of Tiantong-1) in terms of frame structure, field definition, encoding format, and verification mechanism, resulting in the inability to directly exchange data. Serialized payload data blocks must undergo strict field mapping and encapsulation processing according to the protocol frame structure of the target network standard in order to be correctly deframed and recognized by the receiving terminal on the target network side. Traditional gateways use software protocol stack conversion, which requires a complete process of "unpacking → parsing → repackaging," with latency typically exceeding 100 milliseconds, failing to meet the requirements of real-time command and dispatch. Therefore, the technical solution in this application adopts a hardware-level pipelined processing architecture, where data frames directly complete protocol field mapping within the FPGA without CPU involvement. The single-frame conversion latency is less than 10 milliseconds, fundamentally solving the technical problem of high latency in traditional software protocol stack conversion and meeting the stringent real-time requirements of battlefield command and dispatch. Simultaneously, the corresponding protocol encapsulation template is automatically selected based on the target network standard determined by the dynamic link routing decision command, realizing bidirectional mapping and conversion capabilities between MESH protocol data frames and satellite protocol data frames, ensuring the protocol conversion gateway's adaptive encapsulation capability for different network standards.

[0034] Figure 4 This is a block diagram of a hardware-level cross-network protocol encapsulation module in a bidirectional protocol conversion gateway system for MESH self-organizing networks and satellite communication according to an embodiment of this application. Figure 4As shown, in the first embodiment of this application, the hardware-level cross-network protocol encapsulation module 340 includes: a target protocol template identification and mapping unit 341, used to identify the target protocol template and match the interface of the dynamic link routing decision command to obtain the target protocol mapping template parameters; a parallel field reassembly and bitstream alignment unit 342, used to perform parallel field reassembly and bitstream format alignment processing on the serialized payload data block to be encapsulated under the hardware clock drive based on the mapping topology determined by the target protocol mapping template parameters to obtain the primary protocol mapping payload frame unit; and a hardware-accelerated protocol frame complete encapsulation unit 343, used to perform synchronization word appending, control frame header encapsulation and checksum generation processing on the primary protocol mapping payload frame unit through a hardware-level cyclic redundancy check accelerator to obtain the target network encapsulated data frame.

[0035] Specifically, the target protocol template identification and mapping unit 341 is used to identify the target protocol template and match the interface of the dynamic link routing decision command to obtain the target protocol mapping template parameters. The dynamic link routing decision command includes a target link identifier field, which explicitly indicates the target network for the current data fragment transmission. When the target link identifier points to a terrestrial ad hoc network link, the serialized payload data block to be encapsulated needs to be encapsulated in a MESH protocol data frame format (such as a custom protocol frame format based on IEEE 802.11s or a proprietary MESH protocol frame format); when the target link identifier points to a satellite communication link, the serialized payload data block to be encapsulated needs to be encapsulated in a satellite protocol data frame format (such as the DVB-S2X / RCS2 protocol frame format of the Qianfan constellation or the proprietary protocol frame format of Tiantong-1).

[0036] After determining the target network standard, a protocol encapsulation template corresponding to that network standard is loaded from the protocol encapsulation template library pre-stored on the FPGA chip. This library stores encapsulation templates for various mainstream MESH protocol variants (including custom protocols based on IEEE 802.11s, proprietary MESH protocols, etc.) and various satellite protocol formats (such as the DVB-S2X / RCS2 protocol for the Qianfan constellation and the proprietary protocol for Tiantong-1). Each protocol encapsulation template defines complete protocol frame format parameters, including the starting offset, field length, encoding format, byte order requirements, synchronization word format, control frame header structure, and checksum generation polynomial for each field in the target protocol frame structure. After loading the corresponding encapsulation template, an interface matching operation is further performed—the target protocol field structures defined in the encapsulation template are matched and analyzed with the data format of the currently serialized payload data block to be encapsulated. This determines the specific field positions in the target protocol frame structure that each part of the source data (serialization tag header and fragmented payload data body) should be mapped to, generating a complete mapping topology. The mapping topology defines the target field position, offset, and required format conversion rules for each data unit in the serialized payload data block within the target protocol frame. After the target protocol template identification and interface matching operations are completed, the target protocol mapping template parameters are output. These parameters include the frame structure definition of the target protocol, the starting offset and effective length of each field, the mapping topology, the modulation and coding scheme identifier field value, the synchronization word format, the control frame header field definition, and all other encapsulation information required, such as the cyclic redundancy check generator polynomial.

[0037] Specifically, the parallel field reassembly and bitstream alignment unit 342 is used to perform parallel field reassembly and bitstream format alignment processing on the serialized payload data block to be encapsulated under the drive of a hardware clock, based on the mapping topology determined by the target protocol mapping template parameters, to obtain the primary protocol mapped payload frame unit. In this process, the hardware mapping logic uses the mapping topology determined by the target protocol mapping template parameters to reassemble each data unit in the payload data block into the payload field range of the target protocol in parallel, and then performs bitstream scrambling or format alignment processing under the drive of the FPGA hardware clock. Specifically, firstly, according to the mapping topology relationship defined in the target protocol mapping template parameters, the target position of each data unit in the serialized payload data block to be encapsulated (including global transaction identifier, fragment index number, byte offset, and other control information in the serialization tag header, as well as business data in the fragmented payload data body) in the target protocol frame payload field range is determined. At the FPGA hardware implementation level, the parallel field reassembly operation is implemented through multiple sets of parallel data selectors and shift register arrays. Within the same hardware clock cycle, the FPGA's internal hardware mapping logic simultaneously reads multiple data units from the serialized payload data block to be packaged and writes them in parallel to the corresponding payload field positions in the target protocol frame structure. The mapping topology determines the target field starting offset and effective length of each data unit. The hardware mapping logic configures the selection path of the data selector and the offset of the shift register based on these offset parameters, ensuring that each data unit is precisely placed to the correct bit position in the target protocol payload field during the parallel reassembly process. Because the FPGA adopts a pipelined processing architecture, the parallel field reassembly operation is completed in a single processing stage of the hardware pipeline. The reassembly operation of each data unit is executed in parallel rather than sequentially, thus not introducing additional pipeline latency and maintaining a hardware-level processing speed of less than 10 milliseconds for single-frame conversion latency.

[0038] After parallel field reassembly, the reassembled data needs to meet the specific requirements of the target network protocol for the bitstream format. Different network standards have different requirements for the encoding format of the bitstream in the data frame—for example, satellite communication protocols (such as DVB-S2X) require the payload data to undergo spectrum spreading scrambling to meet the spectral characteristics requirements of radio frequency transmission, while MESH protocols may require specific bit stuffing or escaping to ensure that frame delimiters do not appear in the payload data. The parallel field reassembly and bitstream alignment unit, driven by the FPGA hardware clock, performs bitstream format alignment operations specified by the target network standard on the reassembled payload field data. This includes byte alignment stuffing (ensuring strict alignment of each field data on bit boundaries), bit order conversion (converting between big-endian and little-endian according to the target protocol requirements), and bitstream scrambling (performing a pseudo-random sequence XOR operation on the payload data to achieve energy diffusion and meet the spectral requirements of radio frequency transmission). Bitstream scrambling is implemented in the FPGA through a linear feedback shift register. This shift register generates a pseudo-random sequence according to the scrambling generator polynomial specified by the target protocol, and performs a bitwise XOR operation between this sequence and the payload data to output the scrambled bitstream data. After the format alignment process is completed, the primary protocol mapping payload frame unit is output. This frame unit has the correct format and encoding of the target protocol payload field, but has not yet added the complete frame structure information such as the target protocol synchronization word, control frame header and frame check code.

[0039] Specifically, the hardware-accelerated protocol frame complete encapsulation unit 343 is used to perform synchronization word appending, control frame header encapsulation, and checksum generation processing on the primary protocol mapping payload frame unit through a hardware-level cyclic redundancy check accelerator to obtain the target network encapsulated data frame. In this process, firstly, according to the synchronization word format defined in the target protocol mapping template parameters, a synchronization word sequence specified by the target protocol is inserted at the beginning of the frame header of the primary protocol mapping payload frame unit. The synchronization word is a fixed bit pattern used by the physical layer of the target network for frame synchronization capture. The synchronization word format varies for different network standards—for example, the DVB-S2X protocol uses a specific physical layer start-of-frame (SOF) sequence, and the MESH protocol uses the preamble and frame delimiter defined by IEEE 802.11s. The synchronization word appending operation is implemented in the FPGA through a frame header insertion register. Under the control of the hardware clock, this register serially outputs the pre-stored synchronization word bit sequence to the beginning of the frame data stream, and then seamlessly connects to the data stream of the primary protocol mapping payload frame unit.

[0040] Following the synchronization word and preceding the payload data section, a control frame header as specified by the target protocol is inserted. The control frame header contains various control information fields required by the target network protocol—for satellite protocol data frames, it includes modulation and coding scheme identifiers, frame length indicators, and forward error correction coding parameters; for MESH protocol data frames, it includes frame control fields, duration / identifier fields, address fields, and sequence control fields. Specifically, based on the control frame header field structure defined in the target protocol mapping template parameters, the values ​​of each control field are sequentially filled into the frame header section according to the offset and length specified by the target protocol. The values ​​of each field in the control frame header are determined by the target protocol mapping template parameters; some fields are fixed values ​​(such as the protocol version number), while others are dynamic parameters for the current frame (such as the frame length indicator field, which is determined by the actual byte length of the primary protocol mapped payload frame unit).

[0041] After the synchronization word, control frame header, and payload data range (primary protocol mapping payload frame unit) are sequentially arranged to form a complete frame body, the hardware-accelerated protocol frame complete encapsulation unit performs checksum calculation on the frame body data using a hardware-level cyclic redundancy check (CRC) accelerator. The hardware-level CRC accelerator is implemented in the FPGA using a parallel CRC calculation circuit. Based on the CRC generator polynomial defined in the target protocol mapping template parameters, it performs CRC operations on all bits of the control frame header and payload data range to generate a checksum of the length specified by the target protocol. The CRC checksum is calculated using modulo-2 division; the remainder obtained by dividing the frame body data polynomial by the generator polynomial is the CRC checksum. Let the bit sequence of the frame body data be... The generator polynomial is CRC checksum is The calculation process for the check code is as follows: in, This represents the generated CRC checksum polynomial, whose coefficients constitute the bit sequence of the checksum. A bit sequence polynomial representation of the frame body data (the control frame header and payload data range); This represents the CRC generator polynomial specified by the target protocol; different protocol standards use different generator polynomials. This indicates the order of the generator polynomial, which is the bit length of the CRC checksum. This represents the modulo-2 polynomial division remainder operation. The hardware-level cyclic redundancy check (CRC) accelerator completes the CRC calculation of the entire frame of data within a single or a few hardware clock cycles using a parallel CRC calculation circuit, avoiding the high latency overhead of software bit-by-bit calculation. The generated CRC checksum is appended to the end of the frame data, forming a complete target network encapsulated data frame.

[0042] The final structure of the data frame encapsulated by the target network consists of four parts in sequence: a synchronization word in the frame header, a control frame header following the synchronization word, the payload data area (primary protocol mapped payload frame unit) following the control frame header, and a CRC checksum at the end of the frame. This data frame fully conforms to the protocol frame format specifications of the target network and can be directly and correctly identified, synchronously captured, and deframed by the receiving terminal on the target network side.

[0043] Specifically, research has revealed that in the bidirectional protocol conversion scenario between MESH self-organizing networks and satellite communication, the hardware-level pipelined field mapping sub-step undertakes the core task of parallel reassembly of serialized payload data blocks according to the target protocol frame structure. In the first embodiment, the hardware mapping logic utilizes the mapping topology determined by the target protocol mapping template parameters to reassemble each data unit in the payload data block into the payload field range of the target protocol in parallel. Subsequently, bitstream scrambling or format alignment processing is performed under the drive of the FPGA hardware clock. This processing flow implicitly assumes a key premise: the boundary positions of each field of the target protocol are statically fixed, that is, once the mapping topology is determined, the starting offset and length of each field are constant and will not change with the communication link state.

[0044] However, in the actual operation of low-Earth orbit (LEO) satellite constellations, the signal-to-noise ratio (SNR) of the satellite-to-ground link between the satellite terminal and the ground gateway continuously changes with the satellite's overhead trajectory. To maintain link availability, the satellite terminal frequently switches modulation and coding schemes based on real-time channel conditions—for example, switching from QPSK to 8PSK, or from low-rate forward error correction coding to high-rate coding. In LEO satellite communication protocols such as DVB-S2X / RCS2, a "variable-length field cascading dependency" is common: the actual length and coding format of downstream payload fields are not fixed values, but are dynamically determined by the values ​​of upstream control fields (such as the modulation and coding scheme identifier field). Specifically, when the modulation and coding scheme is switched, the forward error correction coding rate changes accordingly, the single-frame payload capacity changes accordingly, and this causes a cascading offset in the boundary positions of all subsequent fields.

[0045] The first embodiment uses a fixed mapping topology for parallel reassembly, completely disregarding the existence of the aforementioned variable-length field cascading dependencies. When the satellite link switches between different modulation and coding modes—which is extremely frequent in typical combat or emergency scenarios where low-Earth orbit satellites move rapidly and their elevation angles change continuously—the fixed field boundaries cannot adaptively follow the coding mode adjustment, leading to payload field misalignment, truncation, or padding overflow. This ultimately causes the target network-side receiver to fail to deframe the frame, and in severe cases, it can cause the entire satellite backhaul link to be interrupted.

[0046] To address the aforementioned technical problems, this application further proposes a second embodiment, which includes the following steps: First, by extracting the modulation and coding scheme identifier field value from the target protocol mapping template parameters, the starting offset and effective length of each downstream field are derived step-by-step based on the on-chip pre-stored cascading dependency table to obtain the dynamic field boundary description vector. It should be understood that in the scenario of rapid overhead transit of low-Earth orbit satellites, this identifier value will be frequently updated with the real-time fluctuations in the signal-to-noise ratio of the satellite-to-ground link, therefore it must be re-acquired at the beginning of each frame processing cycle. Based on this identifier value, the on-chip pre-stored cascading dependency table of the FPGA is queried—this table uses the modulation and coding mode as the index key and records the strict correspondence between the forward error correction coding rate and the effective payload capacity of a single frame under each mode. Through step-by-step derivation, the actual starting offset and effective length of each downstream field under the current mode are calculated, and the above offset and length information are combined and encoded into a dynamic field boundary description vector. This operation transforms the originally static and fixed mapping topology into a dynamic topology that can change in real time with the modulation and coding mode of the satellite link, enabling subsequent field mapping operations to adaptively adjust according to the link status, fundamentally eliminating the possibility of field misalignment due to mode switching.

[0047] Next, based on the actual starting offset and effective length of each field in the dynamic field boundary description vector as dynamic cutting anchors, adaptive segmentation and padding truncation alignment are performed on the serialized payload data block to be encapsulated to obtain boundary adaptive mapping payload frame units. Unlike the parallel reassembly based on a fixed offset in the first embodiment, the cutting boundary here is entirely determined by the modulation and coding state of the current frame, ensuring that the payload data is precisely cut into data segments that strictly match the capacity of each field of the target protocol according to the dynamic boundary. For payload capacity surplus or shortage caused by changes in coding rate, it is handled by the padding truncation adaptive operator: when the payload segment length is less than the target field capacity, padding symbols specified by the protocol are added to the end; when the payload segment length exceeds the target field capacity, the overflow part is marked as the payload to be transmitted in the next frame. Specifically, the calculation process of the padding truncation amount is as follows: in, This represents the amount of padding to be truncated for the j-th target protocol field. A positive value indicates the number of bytes that need to be padded, while a negative value indicates the number of overflow bytes that need to be truncated and marked for continued transmission. This represents the effective capacity of the j-th target field extracted from the dynamic field boundary description vector, and this value changes dynamically with the switching of modulation and coding modes; The first field in the dynamic field boundary description vector represents the... The starting offset of each field. Defined as zero. That is, the actual cutting length of the m-th source data segment; This represents the original byte length of the m-th data unit in the serialized payload data block; This indicates an indicator function, where the condition within the parentheses... The value is 1 when the condition is met, and 0 otherwise. It is used to filter out valid data segments that do not exceed the current field capacity to participate in the accumulation.

[0048] It should be noted that when When a tail padding operation is performed to fill in the field space, Overflow truncation is performed and excess data is marked as continued payload. This mechanism ensures that the data size of each payload field strictly matches the target protocol frame structure under dynamic switching of satellite link modulation and coding modes, avoiding frame de-framing anomalies triggered at the receiver due to inconsistent field lengths. After adaptive segmentation and boundary alignment are completed, the segments are rearranged according to the target protocol field order to generate boundary adaptive mapping payload frame units.

[0049] Furthermore, the boundary adaptive mapping payload frame unit undergoes spectral spreading scrambling and field-by-field offset integrity verification to obtain the primary protocol mapping payload frame unit. Specifically, driven by the FPGA hardware clock, the boundary adaptive mapping payload frame unit performs bitstream scrambling processing as specified by the target network standard to meet the spectral spreading requirements of radio frequency transmission. After scrambling, a hardware-level field boundary readback verification mechanism compares the actual offset of each field after scrambling with the expected value in the dynamic field boundary description vector. If an offset anomaly is found, a single-frame remapping operation is triggered, and the frame is rolled back to the segmentation stage for reprocessing, thus forming a hardware-level closed-loop guarantee for mapping correctness. After successful verification, the primary protocol mapping payload frame unit is output, seamlessly connecting with subsequent target network data frame encapsulation and verification sub-steps.

[0050] In summary, through the aforementioned control field-driven dynamic boundary recalculation and adaptive field mapping mechanism, the protocol conversion gateway can detect changes in the coding mode and adaptively adjust the field boundaries in real time within each frame processing cycle when facing extreme dynamic scenarios such as rapid overhead passage of low-Earth orbit satellites, continuous fluctuations in the signal-to-noise ratio of satellite-to-ground links, and frequent switching of modulation and coding schemes. This completely eliminates the payload misalignment, truncation, and padding overflow problems caused by the cascading dependencies of variable-length fields under the original fixed mapping topology. At the hardware implementation level, the on-chip pre-storage and step-by-step derivation calculation of the cascading dependency table are both completed within the FPGA pipeline, without introducing additional CPU interrupt overhead, maintaining a hardware-level processing speed of less than 10 milliseconds for single-frame conversion latency. Simultaneously, the collaborative work of the padding truncation adaptive operator and the field boundary readback verification mechanism ensures the frame decoding success rate on the target network side under high-frequency switching of modulation and coding modes, avoiding link-layer retransmission storms caused by single-frame mapping errors. This, in turn, improves the effective throughput and transmission reliability of the satellite backhaul link while ensuring the real-time performance of protocol conversion.

[0051] Specifically, the cross-domain transmission and transmission status closed-loop module 350 is used to transmit the target network encapsulated data frame across domains via the corresponding physical layer radio frequency channel, and to monitor the transmission status and packet loss retransmission behavior through the retransmission coordination unit to obtain cross-domain transmission feedback messages. It should be understood that in the bidirectional protocol conversion gateway system of MESH self-organizing network and satellite communication, the target network encapsulated data frame output by the hardware-level cross-network protocol encapsulation module 340 has fully conformed to the protocol frame format specification of the target network standard. However, the cross-domain physical transmission process of the data frame from the protocol conversion gateway to the target network receiving terminal is not a simple one-way transmission behavior. In extreme environments such as military operations, emergency rescue, and field exploration, where there are "circuit breaks, network outages, and power outages," both the ground MESH self-organizing network link and the satellite communication link face adverse factors such as channel fading, electromagnetic interference, and obstruction. During the cross-domain transmission process, the data frame may experience packet loss, delay jitter, or even transmission failure. If the protocol conversion gateway only performs unidirectional transmission without monitoring and feedback on the transmission status, the system will be unable to perceive the actual end-to-end transmission reliability. When packet loss occurs on one link, it will also be unable to quickly retransmit via another link, leading to the loss of critical command data and communication interruption. Meanwhile, the data verification and link status assessment module 310, when performing a comprehensive link quality assessment, needs to combine the packet loss rate data in the cross-domain transmission feedback message with weighted fusion calculations of the link status characteristic parameters. This means that the cross-domain transmission feedback message is a key feedback signal for the closed-loop control of the entire protocol conversion pipeline. It feeds back the end-to-end quality information during the actual transmission process to the first processing stage of the system, enabling the link quality assessment to not only be based on instantaneous physical layer measurement parameters but also to incorporate the cumulative statistical results during the actual transmission process, thereby achieving a more comprehensive and accurate link status perception. Therefore, in the technical solution of this application, the target network encapsulated data frame is reliably sent to the target network through the corresponding physical layer radio frequency channel, and when packet loss occurs on a certain link, it is quickly retransmitted through another link by the retransmission coordination unit, avoiding the timeout waiting of traditional TCP retransmission; and the status data during the transmission process is statistically analyzed and normalized and aggregated to generate cross-domain transmission feedback messages to be fed back to the system front-end module, forming a closed-loop control mechanism of "sending-monitoring-feedback-evaluation" of transmission status, ensuring the system's continuous perception and adaptive adjustment capability to changes in link quality.

[0052] In practice, the target network encapsulated data frame is first pushed to the corresponding radio frequency buffer for physical layer interface modulation to obtain the underlying transmission behavior characteristic data. During this process, the protocol conversion gateway is configured with an uplink channel (MESH→satellite) and a downlink channel (satellite→MESH), supporting full-duplex concurrent conversion. Correspondingly, it is configured with two independent physical layer radio frequency channels—a terrestrial MESH ad hoc network radio frequency channel and a satellite communication radio frequency channel. Each radio frequency channel is equipped with an independent radio frequency buffer to temporarily store the target network encapsulated data frame to be transmitted before the physical layer interface completes data frame modulation and transmission. When the target link identifier of the target network encapsulated data frame points to a terrestrial ad hoc network link, the data frame is pushed to the MESH radio frequency buffer; when the target link identifier points to a satellite communication link, the data frame is pushed to the satellite radio frequency buffer.

[0053] After receiving the target network-encapsulated data frame from the RF buffer, the physical layer interface sequentially performs transmission operations on the data frames in the buffer according to a first-in-first-out (FIFO) scheduling strategy. The physical layer interface transmission process includes digital baseband signal generation (converting the bitstream of the target network-encapsulated data frame into a baseband modulation symbol sequence), digital-to-analog conversion (converting the digital baseband signal into an analog signal), and RF up-conversion and power amplification (shifting the baseband analog signal to the RF carrier frequency specified by the target network standard and amplifying it to the rated transmit power). After completing the physical layer transmission operation for each data frame, the physical layer interface hardware automatically records the underlying transmission behavior characteristics of that frame, including the frame's transmission timestamp (recording the precise time the data frame leaves the RF transmit port), frame sequence identifier (corresponding to the global transaction identifier and fragment index number in the serialized payload data block), target link identifier, and transmission status flag (indicating whether the frame is being transmitted for the first time or as a retransmission). The underlying transmission behavior characteristics are buffered in the FPGA's on-chip memory in the form of a transmission record table, with each frame's transmission record occupying one line, arranged in chronological order of transmission time.

[0054] Next, based on the transmission records in the underlying transmission behavior feature data, the retransmission coordination unit calculates the round-trip delay and accumulates packet loss events for the physical layer acknowledgment signal to obtain the link transmission statistical characteristics. During this process, the retransmission coordination unit continuously monitors the acknowledgment signal (ACK signal) received from the target network side at the physical layer interface. When the target network receiving terminal successfully receives and deframes a target network encapsulated data frame, it returns a physical layer acknowledgment signal carrying a frame sequence identifier to the protocol conversion gateway via the reverse channel. Upon receiving the acknowledgment signal, the retransmission coordination unit extracts the frame sequence identifier and searches the transmission record table of the underlying transmission behavior feature data for a matching transmission record to obtain the frame's transmission timestamp. The retransmission coordination unit records the arrival timestamp of the acknowledgment signal and subtracts the corresponding transmission timestamp to calculate the round-trip delay of the frame. Specifically, the first... The formula for calculating the round-trip time of a frame is: in, Indicates the first The round-trip time of a frame is the time interval from when the frame is sent to when the corresponding acknowledgment signal is received. Indicates the first The frame corresponds to the timestamp of the received acknowledgment signal. Indicates the first The timestamp of a frame leaving the RF transmitter port is obtained from the transmission record table of the underlying transmission behavior characteristic data. Furthermore, the retransmission coordination unit sets a retransmission timeout timer for each transmitted target network encapsulated data frame. The timeout threshold of the timer is dynamically set based on the historical round-trip delay mean and variance of the link. When the retransmission timeout timer for a frame expires without receiving the corresponding physical layer acknowledgment signal, the retransmission coordination unit determines that a packet loss event has occurred, increments the packet loss event counter by 1, and triggers a retransmission operation for the frame. Specifically, the retransmission coordination unit retrieves a copy of the frame from the RF buffer (or extracts it from the FPGA on-chip retransmission buffer) and pushes the frame back to the RF buffer for another physical layer interface call. If the original transmission link for the frame remains unavailable, the frame is switched to the RF buffer of another available link for retransmission—that is, when packet loss occurs on one link, it is quickly retransmitted through another link, avoiding the timeout waiting of traditional TCP retransmission. The retransmission coordination unit marks the transmission status flag in the transmission record of the retransmitted frame as "retransmission" to distinguish it from the initial transmission. Within a statistical period, the retransmission coordination unit cumulatively records the round-trip time (RTT) value, the number of packet loss events, and the retransmission frequency distribution for each frame. At the end of the statistical period, the retransmission coordination unit summarizes and generates link transmission statistical characteristics, including the following statistics: average RTT, maximum RTT, total number of packet loss events, total number of transmitted frames, the retransmission frequency distribution sequence for each frame, and the packet loss rate. The packet loss rate is calculated using the following formula: in, This represents the packet loss rate within a statistical period, and its value is a dimensionless value between 0 and 1. This indicates the cumulative number of packet loss events within the statistical period; This represents the total number of frames sent within the statistical period (including initial transmissions and retransmissions). The link transmission statistical characteristics are output from this sub-step and passed to the next sub-step for normalized performance aggregation.

[0055] Furthermore, the retransmission distribution in the link transmission statistics is normalized and aggregated to obtain cross-domain transmission feedback messages. In this process, firstly, the retransmission coordination unit normalizes the retransmission count distribution sequence in the link transmission statistics. The retransmission count distribution sequence records the number of retransmissions for each frame within the statistical period (0 times indicates one successful transmission, 1 time indicates success after one retransmission, 2 times indicates success after two retransmissions, and so on). This distribution reflects the reliability and stability of the link transmission. The normalization process converts the retransmission count distribution into a normalized retransmission performance index, which is calculated by statistically analyzing the frame proportions at each retransmission count level and then applying a weighted performance score. The formula for calculating the normalized retransmission performance index is: in, This represents the normalized retransmission performance index, with a value ranging from 0 to 1. The larger the value, the better the transmission performance (i.e., most frames are sent successfully on the first try, and there are fewer retransmissions). Indicates the level of retransmission count. This indicates that the first send was successful. This indicates that the transmission was successful after one retransmission, and so on. Indicates the level of the maximum number of retransmissions observed within the statistical period; This indicates that the number of retransmissions within the statistical period is exactly 1. The number of frames; This indicates the total number of frames sent within the statistical period; Indicates the number of retransmissions. The proportion of frames in the total number of frames; Indicates the retransmission count level The corresponding performance weight factor increases with fewer retransmissions, reflecting that the first successfully transmitted frame has the highest performance.

[0056] Subsequently, the normalized retransmission performance index is aggregated with statistics such as packet loss rate and average round-trip time to generate a cross-domain transmission feedback message. The content structure of the cross-domain transmission feedback message includes packet loss rate data (directly used for the link quality weighted fusion calculation of the data verification and parsing and link state assessment module 310), normalized retransmission performance index (reflecting the overall efficiency of retransmission behavior), average round-trip time (reflecting the latency characteristics of the link), and the corresponding link identifier (identifying the target link to which the feedback message belongs). The cross-domain transmission feedback message is output in a standardized message format and fed back to the data verification and parsing and link state assessment module 310. The packet loss rate data, as the packet loss rate component of the cross-domain transmission feedback message in the link quality weighted fusion calculation, participates in the weighted fusion calculation of the link state feature parameters, forming a complete closed-loop control of transmission state from "sending—monitoring—feedback—evaluation—decision". Through this closed-loop mechanism, the protocol conversion gateway can continuously sense the actual end-to-end transmission quality of each link and reflect the changes in transmission quality in a timely manner in the link status characteristic parameters, thereby affecting the link quality trend prediction and route switching decision of the dynamic link routing prediction and decision module 320, and realizing the system's adaptive dynamic adjustment to changes in link quality.

[0057] As described above, the bidirectional protocol conversion gateway system 300 for MESH self-organizing network and satellite communication according to the embodiments of this application can be implemented in various wireless terminals, such as servers with a bidirectional protocol conversion gateway algorithm for MESH self-organizing network and satellite communication. In one possible implementation, the bidirectional protocol conversion gateway system 300 for MESH self-organizing network and satellite communication according to the embodiments of this application can be integrated into the wireless terminal as a software module and / or a hardware module. For example, the bidirectional protocol conversion gateway system 300 for MESH self-organizing network and satellite communication can be a software module in the operating system of the wireless terminal, or it can be an application developed for the wireless terminal; of course, the bidirectional protocol conversion gateway system 300 for MESH self-organizing network and satellite communication can also be one of many hardware modules of the wireless terminal.

[0058] Alternatively, in another example, the MESH self-organizing network and satellite communication bidirectional protocol conversion gateway system 300 and the wireless terminal can also be separate devices, and the MESH self-organizing network and satellite communication bidirectional protocol conversion gateway system 300 can be connected to the wireless terminal via wired and / or wireless networks, and transmit interactive information according to the agreed data format.

[0059] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A bidirectional protocol conversion gateway system for MESH self-organizing networks and satellite communication, characterized in that, include: The data verification and parsing and link status assessment module is used to perform integrity verification and protocol parsing on the acquired heterogeneous network raw data stream through the hardware protocol conversion engine to obtain unified standard payload data, and to perform comprehensive link quality assessment in combination with cross-domain transmission feedback messages to obtain link status characteristic parameters. The dynamic link routing prediction and decision module is used to predict and make decisions on the channel quality change trends of terrestrial ad hoc network links and satellite communication links based on link state characteristic parameters in order to obtain link routing decision instructions. The payload data aggregation, fragmentation and marking module is used to aggregate, fragment and mark sequence numbers of unified standard payload data according to dynamic weights of data types based on link routing decision instructions to obtain serialized payload data blocks to be encapsulated. The hardware-level cross-network protocol encapsulation module is used to perform hardware-level protocol field mapping encapsulation on the serialized payload data block to be encapsulated according to the target network standard determined by the link routing decision instruction, so as to obtain the target network encapsulated data frame. The cross-domain transmission and transmission status closed-loop module is used to transmit the target network-encapsulated data frame across domains via the corresponding physical layer radio frequency channel, and to monitor the transmission status and packet loss retransmission behavior through the retransmission coordination unit to obtain cross-domain transmission feedback messages.

2. The bidirectional protocol conversion gateway system for MESH self-organizing network and satellite communication according to claim 1, characterized in that, The raw data stream of a heterogeneous network includes a protocol identifier header, communication service payload, physical layer link quality data, and error check sequence.

3. The bidirectional protocol conversion gateway system for MESH self-organizing network and satellite communication according to claim 2, characterized in that, The data verification and parsing and link status assessment module includes: The frame verification and data stripping unit is used to perform frame integrity verification on the bit error verification sequence in the original data stream of the heterogeneous network, and strip the physical layer link quality data from the verified data stream to obtain the verified payload and protocol data and physical layer link quality data. The link quality weighted fusion unit is used to weight and fuse the signal-to-noise ratio and received signal strength parameters in the physical layer link quality data with the packet loss rate data in the cross-domain transmission feedback message to obtain the link state characteristic parameters. The protocol parsing and data standardization unit is used to perform protocol unpacking and load standardization processing on the verified load and protocol data to obtain unified standard load data.

4. The bidirectional protocol conversion gateway system for MESH self-organizing network and satellite communication according to claim 1, characterized in that, The dynamic link routing prediction and decision-making module is used for: Update the state database using the link state feature parameters to obtain the time-series link state evolution matrix; The historical trends of bidirectional links in the time-series link state evolution matrix are extrapolated forward to obtain the forward prediction link quality assessment vector. The comparison result is obtained by comparing the forward predicted link quality assessment vector with the preset link blocking threshold, and the comparison result is then encoded into a routing pattern according to the service priority strategy to obtain the dynamic link routing decision instruction.

5. The bidirectional protocol conversion gateway system for MESH self-organizing network and satellite communication according to claim 1, characterized in that, The payload data aggregation, sharding, and tagging module is used for: The service type of the unified standard payload data is identified by deep packet inspection, and the link prediction score ratio in the dynamic link routing decision instruction is combined with policy lookup table matching to obtain the link load fragmentation weight coefficient. Based on the link load fragmentation weight coefficient, the unified standard load data is divided into fixed-length segments according to the byte length that each link should carry to obtain fragmented load data unit streams. By using the global transaction identifier and fragment index number, serialization tag injection and offset appending are performed on each data fragment in the fragmented payload data unit stream to obtain a serialized payload data block to be encapsulated.

6. The bidirectional protocol conversion gateway system for MESH self-organizing network and satellite communication according to claim 1, characterized in that, Hardware-level cross-network protocol encapsulation module, including: The target protocol template identification and mapping unit is used to identify the target protocol template and match the interface of the dynamic link routing decision command to obtain the target protocol mapping template parameters. The parallel field reassembly and bitstream alignment unit is used to perform parallel field reassembly and bitstream format alignment on the serialized payload data block to be encapsulated under the hardware clock drive, based on the mapping topology determined by the target protocol mapping template parameters, to obtain the primary protocol mapping payload frame unit. The hardware-accelerated protocol frame complete encapsulation unit is used to perform synchronization word appending, control frame header encapsulation, and checksum generation on the primary protocol mapping payload frame unit through a hardware-level cyclic redundancy check accelerator to obtain the target network encapsulated data frame.

7. The bidirectional protocol conversion gateway system for MESH self-organizing network and satellite communication according to claim 1, characterized in that, The cross-domain sending and transmission status closed-loop module is used for: The target network encapsulated data frame is pushed to the corresponding radio frequency buffer for physical layer interface modulation to obtain the underlying transmission behavior characteristic data; Based on the transmission records in the underlying transmission behavior feature data, the retransmission coordination unit performs round-trip delay calculation and packet loss event accumulation statistics on the physical layer response signal to obtain the link transmission statistical characteristics. Normalization efficiency aggregation is performed on the retransmission distribution in the link transmission statistics to obtain cross-domain transmission feedback messages.

8. The bidirectional protocol conversion gateway system for MESH self-organizing network and satellite communication according to claim 6, characterized in that, Parallel field reassembly and bitstream alignment unit, used for: By extracting the modulation and coding scheme identifier field value from the target protocol mapping template parameters, the starting offset and effective length of each downstream field are derived step by step based on the on-chip pre-stored cascade dependency table to obtain the dynamic field boundary description vector. Based on the actual starting offset and effective length of each field in the dynamic field boundary description vector as the dynamic cutting anchor point, the serialized payload data block to be encapsulated is subjected to adaptive segmentation cutting and padding truncation alignment to obtain the boundary adaptive mapping payload frame unit. The boundary adaptive mapping payload frame unit is subjected to spectral spread scrambling and field-by-field offset integrity verification to obtain the primary protocol mapping payload frame unit.

Images