Method and system for multi-link fusion transmission based on udp bypass header compression

Abstract

The application discloses a multi-link fusion transmission method and system based on UDP bypass header compression, and relates to the technical field of communication. The method comprises the following steps: a sending end intercepts a service message, extracts a five-tuple for lookup or establishes a connection identifier; a physical transmission link is selected based on link quality, and an IP header source address is modified; an LLC control frame is inserted between the first 4 bytes and the last 4 bytes of an original UDP header, a UDP destination port is modified into a private port, and the encapsulated message is sent; a receiving end identifies a bypass message, parses the LLC control frame from the UDP header, restores the original five-tuple through the connection identifier, recovers the IP header and the transport layer header, deletes the LLC control frame, and recombines and submits. For TCP service, the sending end modifies the IP protocol type into UDP, the receiving end reversely restores, and a proxy acknowledgement mechanism is adopted to respond to a TCP source end. The application greatly reduces the multi-link fusion transmission overhead, improves the narrowband link utilization rate, and improves the wireless environment TCP transmission performance.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to a multi-link converged transmission method based on UDP bypass header compression. Background Technology

[0002] With the widespread deployment and deep integration of various wireless communication standards such as 5G, Narrowband Internet of Things (NB-IoT), private network trunking communication, and low-Earth orbit satellite internet, utilizing multiple heterogeneous wireless links for data fusion transmission to improve the overall throughput, bandwidth utilization, and transmission reliability of communication systems has become an important research direction in the fields of wireless communication and emergency communication. Especially in emergency communication scenarios, systems not only need to simultaneously carry multiple types of service flows such as file downloads, video surveillance streams, real-time voice calls, and control commands, but also need to ensure communication resilience in extreme environments through highly reliable fusion transmission across multiple network standards.

[0003] However, due to limitations in spectrum resources and terminal costs, emergency communications often require the combined use of high-bandwidth links (such as 5G) and low-bandwidth links (such as narrowband private networks and satellite communication links). Narrowband and satellite networks have relatively limited transmission bandwidth, often supporting only tens of Kbps to a few Mbps. Therefore, the system must minimize the overhead of protocol encapsulation during converged transmission to maximize the efficiency of effective data transmission. Currently, the mainstream technical solutions for achieving multi-link converged transmission are mainly the following three:

[0004] The first approach is a multi-link converged transmission scheme based on Internet Protocol (IP) tunneling. Traditional IP tunneling technology treats the original IP service packets as the tunnel payload, re-encapsulating them with a new IP header and a new User Datagram Protocol (UDP) header before transmission. Specifically, this involves adding an extra 28 bytes of tunnel encapsulation overhead to the original packet, typically 20 bytes of IP header and 8 bytes of UDP header. For high-bandwidth links, this 28-byte overhead is negligible; however, in scenarios with extremely limited transmission bandwidth, such as narrowband private networks and satellite communication links, excessive encapsulation overhead will severely restrict the transmission space of effective data, leading to a sharp decline in bandwidth utilization. Especially in applications with short average packet lengths, tunnel encapsulation overhead can account for more than 40% of the total packet length, resulting in a significant reduction in effective throughput.

[0005] The second approach is a multipath transmission scheme based on the Transmission Control Protocol (TCP). Multipath TCP establishes multiple TCP sub-connections at both ends to achieve parallel data transmission along multiple paths, offering advantages such as adaptive traffic scheduling and path-level fault recovery. However, due to the unstable channel conditions in wireless transmission links, fading and interference lead to significant packet loss. The TCP retransmission mechanism used triggers a congestion control algorithm upon detecting packet loss, causing the sending window to shrink drastically. This results in a sharp decline in TCP transmission performance under wireless packet loss conditions, sometimes even worse than single-path transmission.

[0006] The third approach is based on robust header compression. This technique maintains the context state of the sender and receiver on the link, compressing the header to 1 to 3 bytes, significantly reducing overhead. However, its limitations lie in its reliance on point-to-point link context synchronization. If packet loss occurs, leading to context corruption, a long reconstruction time is required. Furthermore, it is often only suitable for single-hop point-to-point transmission and does not directly adapt to multi-link aggregation and routing mechanisms. In addition, it has poor support for sudden service flow switching and struggles to provide stable compression performance in dynamic multi-link environments. Summary of the Invention

[0007] The main objective of this application is to provide a multi-link fusion transmission method based on UDP bypass header compression, including the following steps:

[0008] Step S1: The original service message to be sent is intercepted by the sending end, and the five-tuple information of the original service message is extracted. The five-tuple information includes the source IP address, destination IP address, protocol type, source port and destination port.

[0009] Step S2: The sending end searches for the corresponding connection identifier in the local connection table based on the five-tuple information; if the search fails, a new connection identifier is allocated, and the five-tuple information is bound to the new connection identifier. The five-tuple information and the new connection identifier are then synchronized to the receiving end via control signaling.

[0010] Step S3: The sending end obtains the real-time link quality of multiple heterogeneous transmission links, selects the optimal physical transmission link, and modifies the source IP address of the IP header of the original service packet to the exit IP address of the optimal physical transmission link.

[0011] Step S4: The sending end determines the protocol type of the original service message: if it is UDP, then proceed to step S5; if it is TCP, then modify the protocol type in the IP header to UDP and proceed to step S5.

[0012] Step S5: The sending end inserts an LLC control frame between the first 4 bytes and the last 4 bytes of the UDP header of the original service message. The first 4 bytes are the source port and destination port fields, and the last 4 bytes are the length and checksum fields. The destination port of the UDP header is modified to the private port number preset by the receiving end. The LLC control frame contains at least the connection identifier and the link identifier.

[0013] Step S6: After encapsulating the MAC header, the sending end sends the processed message to the receiving end through the optimal physical transmission link; the receiving end intercepts the bypass message whose destination port is the private port number, locates and parses the LLC control frame at an offset of 4 bytes from the UDP header, and obtains the connection identifier and link identifier.

[0014] Step S7: The receiving end uses the connection identifier as an index to look up the local connection information table, obtains the corresponding original 5-tuple information, restores the source IP of the IP header to the original source IP, and if it is a TCP service, restores the protocol type to TCP, and restores the source port and destination port of the transport layer header.

[0015] Step S8: The receiving end deletes the LLC control frame, moves the last 4 bytes of the UDP header and the payload data forward to cover the LLC control frame, restores the standard IP header and transport layer header structure, and submits them to the upper-layer protocol stack in sequence.

[0016] In one embodiment, step S1 specifically includes:

[0017] Configure flow table filtering policies at the data egress point of the sending end to capture IP data packets to be sent in real time;

[0018] Determine whether the source IP address of the IP data packet matches a preset virtual IP address; if the source IP address matches the preset virtual IP address, then determine that the IP data packet is an original service packet that needs to be bypassed, and proceed to the next step; if the source IP address does not match the preset virtual IP address, then directly allow the IP data packet to pass without subsequent bypassing processing.

[0019] Extract the five-tuple information from the original service message. The five-tuple information includes the source IP address, destination IP address, protocol type, source port, and destination port.

[0020] In one embodiment, step S2 specifically includes:

[0021] The sending end uses the five-tuple information as the query keyword to perform a hash lookup in the local connection table maintained by the sending end to determine whether the five-tuple information has been bound to the corresponding connection identifier.

[0022] If the hash lookup is successful, the found connection identifier is directly obtained as the connection identifier for the current service flow; if the hash lookup is unsuccessful, the original service message is determined to be a new service flow, the sending end allocates an unused connection number from a preset idle connection number pool, and combines the connection number with the sending end's terminal identifier to form the connection identifier; subsequently, the sending end writes the mapping record of the five-tuple information and the connection identifier into the local connection table;

[0023] If a new connection identifier is assigned, the sending end constructs a connection establishment control signaling and sends the five-tuple information and the assigned connection identifier to the receiving end through a preset signaling channel or out-of-band channel, so that the receiving end, after receiving the connection establishment control signaling, synchronously saves the correspondence between the five-tuple information and the connection identifier in its local connection information table.

[0024] In one embodiment, step S3 specifically includes:

[0025] The transmitting end measures the link quality parameters of the multiple heterogeneous transmission links in real time according to a preset detection period. The link quality parameters include at least the round-trip time (RTT), real-time packet loss rate, and current available bandwidth of each link.

[0026] The transmitting end calculates a comprehensive score for each of the multiple heterogeneous transmission links according to a preset weighted scoring rule. The comprehensive score is negatively correlated with the round-trip time (RTT) and the real-time packet loss rate, and positively correlated with the current available bandwidth. The physical link with the highest comprehensive score is selected as the current optimal transmission link.

[0027] The sending end extracts the IP header of the original service message, modifies the source IP address in the IP header to the physical egress IP address corresponding to the current optimal transmission link, and recalculates the IP header checksum based on the modified IP header.

[0028] In one embodiment, step S4 specifically includes:

[0029] The sending end reads the IP header of the original service message, extracts the protocol type field in the IP header, and determines whether the current value of the protocol type field represents the UDP protocol or the TCP protocol.

[0030] If the value of the protocol type field is determined to be UDP, the original service message content remains unchanged, and step S5 is directly performed; if the value of the protocol type field is determined to be TCP, the sending end modifies the value of the protocol type field in the IP header from TCP to UDP, while keeping the TCP header and TCP payload data in the TCP service message intact in the original message position without modification.

[0031] The processed message is then used as the message to be compressed, and the process proceeds to step S5.

[0032] In one embodiment, step S5 specifically includes:

[0033] The sending end locates the UDP header from the original service message and logically splits the UDP header into the first 4 bytes and the last 4 bytes. The first 4 bytes are the source port and destination port fields in the UDP header, and the last 4 bytes are the length and checksum fields in the UDP header.

[0034] The sending end inserts the LLC control frame after the first 4 bytes of the UDP header and before the last 4 bytes, and fills the connection sequence number field, terminal identifier field, link identifier field and length field in the LLC control frame according to the connection identifier found in step S2, the link identifier selected in step S3 and the payload length of the current message respectively.

[0035] The sending end modifies the destination port field in the first 4 bytes of the UDP header to the private port number preset by the receiving end, and then concatenates the first 4 bytes of the UDP header, the LLC control frame, and the last 4 bytes of the UDP header together to form the bypass message structure to be transmitted together with the subsequent original UDP payload.

[0036] The LLC control frame specifically includes the following fields:

[0037] The connection identifier field contains the connection sequence number and terminal identifier, which is used by the receiving end to look up the local connection information table to obtain the original quintuple;

[0038] The fragmentation control field contains a fragmentation flag and a fragmentation sequence number, which are used by the receiving end for fragmentation identification and reassembly.

[0039] The retransmission flag field is used to indicate whether the current message is a retransmission message;

[0040] The link identifier field is used to identify the physical link used by the current packet;

[0041] The length field is used to record the length of the payload data;

[0042] The checksum field is used for data integrity verification.

[0043] In one embodiment, step S6 specifically includes:

[0044] The sending end encapsulates a MAC header, sets the destination MAC address in the MAC header to the MAC address of the next-hop network device, sets the source MAC address in the MAC header to the exit MAC address corresponding to the optimal physical transmission link, and then sends the encapsulated bypass message into the sending queue of the optimal physical transmission link and sends it to the receiving end through the physical interface.

[0045] The receiving end intercepts the incoming IP data packets at the data entry point and identifies the bypass packet by checking whether the protocol type of the IP data packet is UDP and whether the value of the destination port field is the private port number.

[0046] The receiving end locates the start position of the UDP header of the bypass message, locates the LLC control frame by offsetting a fixed length from the start position of the UDP header, reads and parses each field of the LLC control frame, and extracts the connection identifier and the link identifier from them.

[0047] In one embodiment, step S7 specifically includes:

[0048] The receiving end extracts the connection identifier, uses the connection sequence number and the terminal identifier as a joint index, and performs a matching search in the connection information table maintained locally by the receiving end to obtain the original five-tuple information corresponding to the bypass message.

[0049] The receiving end modifies and restores the source IP address in the bypass packet IP header to the original source IP address and the destination IP address in the IP header to the original destination IP address based on the original source IP address and the original destination IP address in the original 5-tuple information, and recalculates the IP header checksum based on the modified IP header content.

[0050] The receiving end reads the original protocol type from the original 5-tuple information; if the original protocol type is UDP, then the source port of the UDP header in the bypass message is directly restored to the original source port and the destination port is restored to the original destination port, and the UDP checksum is recalculated; if the original protocol type is TCP, then the receiving end first restores the protocol type field in the IP header of the bypass message from UDP to TCP, then restores the source port and destination port of the TCP header to the original source port and the original destination port, and finally recalculates the TCP checksum to complete the complete restoration of the message transport layer header.

[0051] In one embodiment, step S8 specifically includes:

[0052] The receiving end locates the starting position of the LLC control frame, the last 4 bytes of the UDP header, and the subsequent payload data in the current bypass message. It then moves the last 4 bytes of the UDP header and the subsequent payload data forward as a whole through a memory shifting operation, directly overwriting and erasing the space occupied by the LLC control frame. This allows the first 4 bytes of the UDP header to be seamlessly joined with the last 4 bytes of the UDP header, restoring the standard-length UDP header structure.

[0053] The receiving end makes a judgment based on the fragmentation flag and fragmentation sequence number obtained from parsing. If the fragmentation flag indicates no fragmentation, the current message is determined to be a complete message, and the process proceeds directly to the next step. If the fragmentation flag indicates the first fragment, middle fragment, or last fragment, the current message is determined to be a fragmented message. The receiving end caches the current fragment in the local receiving and reassembling window and sorts them according to the fragmentation sequence number. When all fragments corresponding to the same original message are received in the receiving and reassembling window, they are reassembled from the first fragment to the last fragment according to the fragmentation sequence number to restore the complete original service message.

[0054] The receiving end checks the continuity of the sequence number of the restored complete original service message in its respective service flow. If the sequence number of the current message is continuous with the sequence number of the previously submitted message, the receiving end immediately submits the current message to the upper-layer protocol stack. If the sequence number of the current message is not continuous and there is a gap in the sequence number, the receiving end temporarily stores the current message in the receiving window and starts a timeout wait or sends a retransmission request to the sending end. After the missing intermediate message in the receiving window is successfully received and reassembled, the receiving end submits multiple consecutive messages in the receiving window to the upper-layer protocol stack in the order of the original sequence numbers.

[0055] Therefore, this application has the following beneficial effects:

[0056] First, it significantly reduces the overhead of multi-link converged transmission. This application abandons the traditional IP tunneling model, which requires adding an outer IP header (20 bytes) and an outer UDP header (8 bytes) totaling 28 bytes of overhead to the original packet. Instead, it creatively embeds a single 8-byte Logical Link Control (LLC) frame between the first 4 bytes and the last 4 bytes of the UDP header. This "embedded" encapsulation strategy saves at least 20 bytes of transmission overhead per packet compared to traditional tunneling solutions. In bandwidth-constrained narrowband private networks and satellite communication links, especially when dealing with high-frequency, small-sized service packets, this solution can significantly reduce the proportion of invalid payload and significantly improve the transmission efficiency of effective data and the utilization rate of link bandwidth.

[0057] Second, it is completely transparent to upper-layer applications and compatible with both UDP and TCP protocol stacks. The receiving end restores the five-tuple information, recovers the IP / transport layer port and checksum by looking up a table, and physically removes the LLC control frame, thus accurately restoring the message to a standard IP / UDP or IP / TCP structure. The entire compression process is completely shielded from upper-layer applications and the underlying physical link, requiring no modifications to existing applications, while achieving seamless compatibility between UDP and TCP services.

[0058] Third, this solution addresses the industry pain point of TCP transmission performance collapse in wireless environments. It "masquerades" the TCP protocol number as UDP, completely avoiding the problem of frequent congestion control triggered by multiple sub-connections in high-packet-loss wireless scenarios, which leads to a sharp drop in the sending window. Simultaneously, the receiving end utilizes a proxy acknowledgment mechanism to immediately send a response to the TCP source end after restoring the packet, significantly reducing end-to-end round-trip latency and substantially improving the actual throughput and transmission stability of TCP services in harsh wireless links.

[0059] Fourth, it possesses adaptive routing and highly reliable reassembly capabilities. The transmitter establishes a weighted scoring rule based on round-trip time (RTT), real-time packet loss rate, and available bandwidth to achieve dynamic optimal distribution across multiple links. Combined with the fragmentation flag and fragmentation sequence number in the LLC control frame, it perfectly adapts to the differences between different physical links. The receiver, through the receive window and out-of-order reordering mechanism, ensures highly reliable in-order delivery of data under out-of-order transmission across multiple links, significantly improving the overall robustness of multi-link aggregated transmission. Attached Figure Description

[0060] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0061] Figure 1 This is a system flowchart of a multi-link converged transmission method based on UDP bypass header compression;

[0062] Figure 2 A cost comparison chart between the traditional tunnel design and the design proposed in this application;

[0063] Figure 3 This is a schematic diagram of the LLC control frame field structure;

[0064] Figure 4 Comparison of UDP packet structures before and after inserting LLC control frames;

[0065] Figure 5A simplified flowchart of the UDP service sending end processing flow. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0067] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0068] To address the shortcomings of existing technologies, this application provides a multi-link converged transmission method based on UDP bypass header compression, including steps S1-S8, as described above. Figure 1 , Figure 1 This is a system flowchart of a multi-link converged transmission method based on UDP bypass header compression.

[0069] Step S1: The original service message to be sent is intercepted by the sending end, and the five-tuple information of the original service message is extracted. The five-tuple information includes the source IP address, destination IP address, protocol type, source port and destination port.

[0070] Step S2: The sending end searches for the corresponding connection identifier in the local connection table based on the five-tuple information; if the search fails, a new connection identifier is allocated, and the five-tuple information is bound to the new connection identifier. The five-tuple information and the new connection identifier are then synchronized to the receiving end via control signaling.

[0071] Step S3: The sending end obtains the real-time link quality of multiple heterogeneous transmission links, selects the optimal physical transmission link, and modifies the source IP address of the IP header of the original service packet to the exit IP address of the optimal physical transmission link.

[0072] Step S4: The sending end determines the protocol type of the original service message: if it is UDP, then proceed to step S5; if it is TCP, then modify the protocol type in the IP header to UDP and proceed to step S5.

[0073] Step S5: The sending end inserts an LLC control frame between the first 4 bytes and the last 4 bytes of the UDP header of the original service message. The first 4 bytes are the source port and destination port fields, and the last 4 bytes are the length and checksum fields. The destination port of the UDP header is modified to the private port number preset by the receiving end. The LLC control frame contains at least the connection identifier and the link identifier.

[0074] Step S6: After encapsulating the MAC header, the sending end sends the processed message to the receiving end through the optimal physical transmission link; the receiving end intercepts the bypass message whose destination port is the private port number, locates and parses the LLC control frame at an offset of 4 bytes from the UDP header, and obtains the connection identifier and link identifier.

[0075] Step S7: The receiving end uses the connection identifier as an index to look up the local connection information table, obtains the corresponding original 5-tuple information, restores the source IP of the IP header to the original source IP, and if it is a TCP service, restores the protocol type to TCP, and restores the source port and destination port of the transport layer header.

[0076] Step S8: The receiving end deletes the LLC control frame, moves the last 4 bytes of the UDP header and the payload data forward to cover the LLC control frame, restores the standard IP header and transport layer header structure, and submits them to the upper-layer protocol stack in sequence.

[0077] Specifically, in this embodiment, addressing the shortcomings of existing technologies, this application provides a multi-link fusion transmission method based on UDP bypass header compression, the method comprising steps S1 to S8. (Refer to...) Figure 1 , Figure 1 This is a system flowchart of the multi-link converged transmission method based on UDP bypass header compression provided in the embodiments of this application. The method is executed with the cooperation of the sending end and the receiving end, and specifically includes the following steps:

[0078] Step S1: The sending end intercepts the original service packet to be sent and extracts the five-tuple information of the original service packet. Specifically, the sending end deploys a flow table filtering module at the data egress point. This module monitors the protocol stack output queue or the driver of the physical network card in real time. By checking whether the source IP address of the packet is a preset virtual IP address and whether the protocol type is UDP or TCP, it determines whether the packet belongs to a service packet that needs to be bypassed. After confirming that it is an original service packet to be processed, its core identity information at the network layer and transport layer, namely the five-tuple information, is extracted, which includes the source IP address, destination IP address, protocol type, source port, and destination port.

[0079] In step S2, the sending end searches for the corresponding connection identifier in its local connection table based on the five-tuple information. If the search fails, a new connection identifier is allocated, and the five-tuple information is bound to the new connection identifier. The five-tuple information and the new connection identifier are then synchronized to the receiving end via control signaling. Specifically, the sending end maintains a local connection mapping table based on a hash table, using the five-tuple as the input key for efficient searching. If the hash matches, the bound connection identifier (composed of the connection sequence number and the terminal identifier) ​​is directly extracted. If the hash does not match, the current packet is determined to belong to a new service flow. The sending end allocates an unused connection sequence number from a preset pool of 0-255 free sequence numbers and combines it with the sending end's own terminal identifier to form the connection identifier for this new flow. To ensure the receiving end can correctly reconstruct the connection, the sending end constructs a dedicated connection establishment control signaling, sending the five-tuple information and the allocated connection identifier to the receiving end via an out-of-band signaling channel. Upon receiving this signaling, the receiving end synchronizes and saves it in its locally maintained connection information table.

[0080] Step S3: The sending end obtains the real-time link quality of multiple heterogeneous transmission links, selects the optimal physical transmission link, and modifies the source IP address in the IP header of the original service packet to the egress IP address of the optimal physical transmission link. Specifically, the sending end continuously (e.g., every 100ms) probes the status of each physical link, measuring the round-trip time (RTT), real-time packet loss rate, and current available bandwidth. Then, according to a preset weighted scoring mechanism, it calculates the comprehensive score for each link and selects the physical link with the highest score (i.e., the best overall quality) as the transmission channel for the current original service packet. After routing is completed, the sending end directly modifies the source IP address field in the IP header, replacing it with the actual physical egress IP of the selected optimal physical link. Then, it recalculates the IP header checksum based on the new IP header content to ensure that the IP packet is routed and transmitted normally in the network.

[0081] Step S4: The sending end determines the protocol type of the original service message: if it is UDP, proceed to step S5; if it is TCP, modify the protocol type in the IP header to UDP and proceed to step S5. Specifically, since the method of this application is based on a connectionless bypass transmission architecture, special processing is required for TCP services. The sending end determines the protocol type by reading the protocol number field in the IP header: if the protocol number is 17, it means the original service is UDP, and proceed directly to the next step; if the protocol number is 6, it means the original service is TCP, and the sending end modifies the protocol number in the IP header from 6 to 17 (i.e., from TCP to UDP), but its TCP header and payload data are completely preserved. This operation makes the TCP service appear as a disguised UDP message in the actual cross-link transmission process at the underlying level, avoiding the congestion control collapse problem of maintaining TCP sub-connections in multi-link scenarios.

[0082] Step S5: The sending end inserts an LLC control frame between the first 4 bytes and the last 4 bytes of the UDP header of the original service message. The first 4 bytes are the source port and destination port fields, and the last 4 bytes are the length and checksum fields. The destination port of the UDP header is modified to a private port number preset by the receiving end. The LLC control frame contains at least the connection identifier and link identifier, which is the core encapsulation operation of this application. The sending end first logically splits the UDP header into its first 4 bytes and last 4 bytes, and inserts an 8-byte LLC control frame in the "gap" between them. This LLC control frame contains the following fields: length field (2 bytes, recording payload length), checksum field (2 bytes, data integrity), control bit field (2 bytes, covering fragmentation flag, fragment sequence number, retransmission flag, and link identifier, etc.), connection sequence number field (1 byte), and terminal identifier field (1 byte). The sending end fills in the connection identifier obtained in S2 and the link identifier obtained in S3. Meanwhile, the destination port in the first 4 bytes of the UDP header is modified to a private port number pre-agreed with the receiver, so that the receiver can quickly filter out bypass packets through this specific port value. Then, the split first 4 bytes, LLC control frame and last 4 bytes are reassembled to form the final UDP packet to be sent.

[0083] In step S6, after the sending end encapsulates the Media Access Control (MAC) header, it sends the processed message to the receiving end through the optimal physical transmission link. The receiving end intercepts the bypass message whose destination port is the private port number, locates and parses the LLC control frame 4 bytes off the UDP header, and obtains the connection identifier and link identifier. Specifically, after completing the UDP header modification, the sending end continues to encapsulate the MAC header at the link layer, setting the destination MAC address to the next-hop router address and the source MAC address to the egress physical network card address, and then sends it through the selected optimal link. The receiving end sets up a packet filtering engine at the data ingress point to perform deep packet inspection on all incoming IP packets. When it finds that the protocol type of the IP packet is UDP and the UDP destination port exactly matches the preset private port number, it determines that the message is a bypass message that needs further processing. The receiving end then locates the starting position of the UDP header of the bypass message, precisely offsets 4 bytes from the starting position, accurately reads and parses the 8-byte LLC control frame, and extracts the connection identifier used for indexing the 5-tuple and the link identifier used for link statistics.

[0084] Step S7: The receiving end uses the connection identifier as an index to look up the local connection information table, obtains the corresponding original 5-tuple information, restores the source IP in the IP header to the original source IP, and if it is a TCP service, restores the protocol type to TCP, and restores the source port and destination port in the transport layer header. Specifically, the receiving end uses the parsed connection sequence number and terminal identifier as a combined index to perform a reverse lookup in the local connection information table to restore the original 5-tuple information corresponding to the bypass message before it was intercepted by the sending end. Subsequently, the receiving end uses the original source IP and original destination IP obtained from the table lookup to rewrite and restore the source and destination IP in the IP header, and recalculates the IP checksum. Next, the protocol type field in the original 5-tuple is read: if the original protocol is UDP, the UDP port is directly restored and the UDP checksum is recalculated; if the original protocol is TCP, the receiving end needs to change the protocol type in the IP header from UDP back to TCP, restore the source and destination ports in the TCP header, and recalculate the TCP checksum according to the TCP protocol specification to ensure that the TCP packet can pass the check in the local protocol stack, thus realizing the complete restoration of the packet transport layer header information.

[0085] In step S8, the receiving end deletes the LLC control frame, moves the last 4 bytes of the UDP header and the payload data forward to cover the LLC control frame, restoring the standard IP header and transport layer header structure, and submits it to the upper-layer protocol stack in sequence. Specifically, the receiving end performs a physical-level byte shifting operation, moving the last 4 bytes of the UDP header and the following UDP payload data forward by 8 bytes, directly overwriting and erasing the space occupied by the original LLC control frame. After the shift, the first 4 bytes and the last 4 bytes of the UDP header are seamlessly joined, restoring the standard 8-byte UDP header structure. At this point, the message has been completely restored to the standard "IP header + UDP / TCP header + payload" structure initially sent by the service source. The receiving end further checks the fragmentation flag parsed from the LLC frame. If it is a fragmented packet, it is buffered and joined according to the sequence number; if a sequence number gap is found, it is temporarily stored in the receiving window to await completion. When the message is complete and the sequence numbers are consecutive, the restored original message is immediately submitted to the upper-layer protocol stack or local application in sequence. At this point, the sending and receiving ends have completed a full multi-link fusion transmission closed loop based on UDP bypass header compression.

[0086] Through the close cooperation of steps S1 to S8 above, this application effectively solves the problem of low effective bandwidth utilization of traditional IP tunnels (with an additional 28 bytes of outer IP and UDP header) in narrowband links. At the same time, by modifying the TCP protocol type and introducing a proxy confirmation mechanism, it eliminates the adverse impact of wireless link packet loss on the TCP congestion control window, and realizes low-overhead multi-link converged transmission that is compatible with UDP and TCP services and completely transparent to the application layer.

[0087] As shown in the figure Figure 2 A direct comparison of the significant differences in packet encapsulation structure and overhead between traditional tunneling schemes and the scheme presented in this application is presented. Traditional tunneling schemes require additional encapsulation of an outer MAC address, an outer IP header (20 bytes), and an outer UDP header (8 bytes) in addition to the original IP and UDP headers, resulting in substantial additional transmission overhead per packet. The scheme presented in this application abandons this external encapsulation model, creatively splitting the original UDP header logically, retaining the first 4 bytes of "port information" and the last 4 bytes of "UDP original header information" (i.e., length and checksum), and inserting a mere 8-byte LLC control frame in the middle. Based on this "embedded" header compression modification, this application eliminates the need for additional outer IP / UDP headers. Calculations show that compared to traditional tunneling schemes, this scheme saves approximately 20 bytes of additional overhead per packet transmission. In narrowband private network and satellite communication scenarios with extremely limited bandwidth, this structural optimization can significantly increase the proportion of effective payload and greatly improve the transmission efficiency of service data.

[0088] In one embodiment, step S1 specifically includes:

[0089] Configure flow table filtering policies at the data egress point of the sending end to capture IP data packets to be sent in real time;

[0090] Determine whether the source IP address of the IP data packet matches a preset virtual IP address; if the source IP address matches the preset virtual IP address, then determine that the IP data packet is an original service packet that needs to be bypassed, and proceed to the next step; if the source IP address does not match the preset virtual IP address, then directly allow the IP data packet to pass without subsequent bypassing processing.

[0091] Extract the five-tuple information from the original service message. The five-tuple information includes the source IP address, destination IP address, protocol type, source port, and destination port.

[0092] Specifically, in this embodiment, a flow table filtering strategy is first configured at the data egress point of the sending end to capture IP data packets to be sent in real time. Specifically, a bypass packet capture module is deployed at the sending end between the system's protocol stack output queue and the underlying physical network card driver. This module does not interfere with the normal protocol stack processing flow; instead, it uses bypass mirroring or zero-copy technology to continuously monitor and capture all IP data packets sent in the uplink direction from the host side, ensuring that no service flow requiring processing is missed.

[0093] Secondly, it is determined whether the source IP address of the IP data packet matches a preset virtual IP address. In this embodiment, the sending end pre-configures a unique virtual IP address (e.g., 10.10.10.1). This virtual IP is only used as an internal service identifier and does not belong to any physical interface IP. The bypass packet capture module extracts the source IP field of each captured IP data packet and compares it precisely with the preset virtual IP address. If the source IP address matches the preset virtual IP address, the current IP data packet is determined to be an original service packet that needs to be bypassed, and it immediately enters the subsequent bypass processing flow; otherwise, if the source IP address does not match the preset virtual IP address, it means that the packet belongs to the system management packet or other non-local service packet sent by the sending end itself, and the sending end directly allows it to pass to the physical network card without performing subsequent header compression or multi-link bypass processing. This filtering strategy based on source IP matching can quickly complete the filtering of service packets at the network layer without modifying the upper-layer application configuration.

[0094] Finally, the five-tuple information is extracted from the original service messages determined to require bypass processing. If a message is determined to be pending processing, the sending end further parses the IP header and transport layer header of the message to extract the five-tuple information that uniquely identifies a service flow in the network. The five-tuple information specifically includes the source IP address, destination IP address, protocol type (i.e., TCP or UDP), source port, and destination port. This extracted five-tuple information will serve as the unique key index for connection identifier lookup and binding in subsequent step S2, thereby ensuring that subsequent data flows can be correctly identified and transmitted in sequence on multiple heterogeneous links.

[0095] In one embodiment, step S2 specifically includes:

[0096] The sending end uses the five-tuple information as the query keyword to perform a hash lookup in the local connection table maintained by the sending end to determine whether the five-tuple information has been bound to the corresponding connection identifier.

[0097] If the hash lookup is successful, the found connection identifier is directly obtained as the connection identifier for the current service flow; if the hash lookup is unsuccessful, the original service message is determined to be a new service flow, the sending end allocates an unused connection number from a preset idle connection number pool, and combines the connection number with the sending end's terminal identifier to form the connection identifier; subsequently, the sending end writes the mapping record of the five-tuple information and the connection identifier into the local connection table;

[0098] If a new connection identifier is assigned, the sending end constructs a connection establishment control signaling and sends the five-tuple information and the assigned connection identifier to the receiving end through a preset signaling channel or out-of-band channel, so that the receiving end, after receiving the connection establishment control signaling, synchronously saves the correspondence between the five-tuple information and the connection identifier in its local connection information table.

[0099] Specifically, in this embodiment, after successfully extracting the quintuple information, the sending end uses it as a query key to perform a fast matching search in the connection table based on a hash map structure maintained locally by the sending end. By utilizing the time complexity characteristics of the hash table, it determines whether the current business flow quintuple has been bound to a certain connection identifier.

[0100] If the hash lookup is successful, the sender directly extracts the found bound connection identifier and uses it as the flow identifier for the current packet, without needing to re-establish the mapping relationship. If the hash lookup fails, it indicates that the current packet belongs to a completely new service flow, and the sender initiates the connection establishment process. First, the sender allocates an unused connection number from a preset pool of idle connection numbers in the range of 0 to 255, either sequentially or randomly. Then, the allocated connection number is combined with the terminal identifier preset at the factory or during the configuration of the sender device to form a unique connection identifier used within this application. Since the terminal identifier distinguishes different sending devices, and the connection number distinguishes different service flows within the same device, this double-tuple identifier is unique and collision-free across the entire network. Subsequently, the sender completely writes the mapping record of the service flow five-tuple information and the newly generated connection identifier into the local connection table, ensuring that any subsequent packet belonging to this service flow can directly reuse this unique identifier.

[0101] To ensure the receiving end has the ability to fully reconstruct the service message, if step S2 involves allocating a new connection identifier, the sending end must immediately construct a specific connection establishment control signaling after completing local writing. The payload of this control signaling must fully contain the original service's five-tuple information and the allocated new connection identifier. The sending end reliably sends this control signaling to the receiving end through a pre-configured independent dedicated signaling channel or out-of-band transmission channel (e.g., a fixed UDP port or TCP control connection). Upon receiving the connection establishment control signaling, the receiving end parses the five-tuple and connection identifier, and synchronously saves this mapping relationship in its locally maintained connection information table. Through this closed-loop synchronization mechanism, the sending end does not need to carry the complete five-tuple information in each subsequent data packet transmission; it can index the original five-tuple using only the tiny connection identifier in the LLC control frame, laying the foundation for significantly reducing single-packet transmission overhead.

[0102] In one embodiment, step S3 specifically includes:

[0103] The transmitting end measures the link quality parameters of the multiple heterogeneous transmission links in real time according to a preset detection period. The link quality parameters include at least the round-trip time (RTT), real-time packet loss rate, and current available bandwidth of each link.

[0104] The transmitting end calculates a comprehensive score for each of the multiple heterogeneous transmission links according to a preset weighted scoring rule. The comprehensive score is negatively correlated with the round-trip time (RTT) and the real-time packet loss rate, and positively correlated with the current available bandwidth. The physical link with the highest comprehensive score is selected as the current optimal transmission link.

[0105] The sending end extracts the IP header of the original service message, modifies the source IP address in the IP header to the physical egress IP address corresponding to the current optimal transmission link, and recalculates the IP header checksum based on the modified IP header.

[0106] Specifically, in this embodiment, the transmitting end first periodically sends dedicated link quality probe messages to the receiving end according to a preset fixed probe period (e.g., every 100 milliseconds or 500 milliseconds) to obtain the current status of each heterogeneous wireless transmission link in real time. Specific link quality parameters include at least the round-trip time (RTT), real-time packet loss rate, and currently available bandwidth for each physical link. In practice, the transmitting end can obtain the RTT by recording the time difference between probe requests and responses, obtain the packet loss rate by statistically analyzing the proportion of probe messages lost per unit time, and obtain the currently available bandwidth by monitoring the occupancy rate of the sending queue or the link layer rate. The real-time acquisition of these parameters provides accurate data support for subsequent intelligent scheduling.

[0107] Secondly, the sending end maintains a weighted scoring engine. This engine normalizes the three link quality parameters obtained according to preset weighted scoring rules, and then calculates a comprehensive score for each heterogeneous transmission link. It is important to emphasize that the calculation rules for this comprehensive score have a clear physical meaning: it is always negatively correlated with the RTT and the real-time packet loss rate. That is, the lower the RTT and the smaller the packet loss rate, the smoother the link, and the higher the score; conversely, if the latency is too high or packet loss is severe, the score will drop sharply. At the same time, this comprehensive score is positively correlated with the currently available bandwidth; that is, the more bandwidth remaining on the link, the higher the score. Through this multi-dimensional weighted scoring mechanism, the sending end can accurately quantify and evaluate the actual carrying capacity of each physical link, and ultimately select the physical link with the highest comprehensive score as the "optimal transmission link" to carry the current original service message, ensuring that the transmission achieves the best balance between latency and success rate.

[0108] Finally, after determining the optimal transmission link, the sender enters the hardware adaptation phase of the IP layer. The sender first precisely extracts the IP header of the original service packet, reading its source IP, destination IP, and checksum fields. To ensure the sent data packet can be routed correctly on the selected optimal physical link, the sender must modify the source IP address field in the IP header to the actual physical exit IP address corresponding to that optimal physical transmission link. Since the source IP address in the IP header has undergone a substantial change, the original IP header checksum is invalid. Therefore, the sender must strictly follow the calculation specifications of the IP protocol stack, recalculating and filling the IP header checksum field according to the modified complete IP header content. This operation is crucial because if the checksum is not recalculated, intermediate routers will treat it as an invalid data packet and discard it directly, directly causing the bypass transmission to fail. At this point, the sender has completed dynamic routing and IP layer adaptation operations based on multi-dimensional link quality awareness.

[0109] In one embodiment, step S4 specifically includes:

[0110] The sending end reads the IP header of the original service message, extracts the protocol type field in the IP header, and determines whether the current value of the protocol type field represents the UDP protocol or the TCP protocol.

[0111] If the value of the protocol type field is determined to be UDP, the original service message content remains unchanged, and step S5 is directly performed; if the value of the protocol type field is determined to be TCP, the sending end modifies the value of the protocol type field in the IP header from TCP to UDP, while keeping the TCP header and TCP payload data in the TCP service message intact in the original message position without modification.

[0112] The processed message is then used as the message to be compressed, and the process proceeds to step S5.

[0113] Specifically, in this embodiment, the sending end first reads the IP header of the original service message, extracts the protocol type field in the IP header, and determines whether the current value of the field represents the UDP protocol or the TCP protocol.

[0114] If the value of the protocol type field is determined to be UDP, since the bypass header compression mechanism of this application is naturally adapted to the connectionless characteristics of UDP, the sending end does not need to make any protocol-level changes to the message, and directly keeps the original service message content unchanged, and then proceeds to step S5 to insert the LLC control frame.

[0115] Conversely, if the value of the protocol type field is determined to be TCP, the sending end executes the core special processing flow for TCP services in this embodiment. The sending end modifies the value of the protocol type field in the IP header from TCP to UDP. A crucial technical point in this process is that the sending end must strictly ensure that the TCP header and TCP payload data in the TCP service message are completely preserved in their original positions, without any deletion or modification. In other words, although the protocol number of the outer network layer has undergone a substantial change, the sequence number, acknowledgment number, window size, flags (including SYN, ACK, etc.) contained in the TCP header, as well as the application layer payload immediately following it, are all embedded intact in the message's payload data. This design logic of "changing the protocol number at the outer layer and preserving the integrity at the inner layer" allows the TCP data stream to be completely "disguised" as UDP datagrams in the underlying bypass, enabling connectionless independent transmission over multiple heterogeneous wireless links. This approach fundamentally avoids the additional handshake overhead caused by traditional solutions such as MPTCP in multi-link scenarios that maintain multiple TCP sub-connections. More importantly, it completely solves the problem of transmission performance collapse caused by the drastic contraction of the TCP congestion control window when there is a sudden packet loss in the wireless link.

[0116] Finally, after completing the differential judgment and conversion processing of the above protocol types, the sending end treats the processed messages as messages to be compressed, and then proceeds to step S5 for subsequent LLC control frame insertion and transmission operations. Through the above dual-mode compatibility processing for UDP and TCP services, this patented solution achieves seamless compatibility with the existing underlying protocol stack, ensuring that the entire multi-link transmission system remains completely transparent to upper-layer application services.

[0117] In one embodiment, step S5 specifically includes:

[0118] The sending end locates the UDP header from the original service message and logically splits the UDP header into the first 4 bytes and the last 4 bytes. The first 4 bytes are the source port and destination port fields in the UDP header, and the last 4 bytes are the length and checksum fields in the UDP header.

[0119] The sending end inserts the LLC control frame after the first 4 bytes of the UDP header and before the last 4 bytes, and fills the connection sequence number field, terminal identifier field, link identifier field and length field in the LLC control frame according to the connection identifier found in step S2, the link identifier selected in step S3 and the payload length of the current message respectively.

[0120] The sending end modifies the destination port field in the first 4 bytes of the UDP header to the private port number preset by the receiving end, and then concatenates the first 4 bytes of the UDP header, the LLC control frame, and the last 4 bytes of the UDP header together to form the bypass message structure to be transmitted together with the subsequent original UDP payload.

[0121] The LLC control frame specifically includes the following fields:

[0122] The connection identifier field contains the connection sequence number and terminal identifier, which is used by the receiving end to look up the local connection information table to obtain the original quintuple;

[0123] The fragmentation control field contains a fragmentation flag and a fragmentation sequence number, which are used by the receiving end for fragmentation identification and reassembly.

[0124] The retransmission flag field is used to indicate whether the current message is a retransmission message;

[0125] The link identifier field is used to identify the physical link used by the current packet;

[0126] The length field is used to record the length of the payload data;

[0127] The checksum field is used for data integrity verification.

[0128] Specifically, in this embodiment, the sending end first accurately locates the start position of the standard UDP header in the original service message, and then logically splits the standard UDP header according to its inherent field structure, dividing it into two independent parts: the first 4 bytes and the last 4 bytes. The first 4 bytes carry the original source port and destination port fields, used to identify the communication endpoint of the application layer; the last 4 bytes carry the UDP length field and the UDP checksum field, used to indicate the data packet length and ensure data integrity.

[0129] Secondly, the sending end inserts an 8-byte LLC control frame directly into the "gap" between the first 4 bytes and the last 4 bytes of the UDP header. Simultaneously, the sending end, based on the connection identifier (composed of connection sequence number and terminal identifier) ​​obtained through a hash lookup table in step S2 and the link identifier selected based on link quality in step S3, and considering the actual UDP payload length of the current packet, fills the connection sequence number, terminal identifier, link identifier, and length fields in the LLC control frame accordingly. Furthermore, the fragmentation flag, fragmentation sequence number, and retransmission flag subfields in the LLC control frame are also configured synchronously according to the current packet situation, providing a basis for the receiving end to perform fragmentation reassembly and deduplication.

[0130] Subsequently, the sending end makes a crucial modification to the first 4 bytes of the UDP header, changing the destination port field value in the first 4 bytes to a private port number pre-agreed upon by the receiving end, which serves as the unique identifier for the receiving end to identify bypass packets at the data entry point.

[0131] Finally, the sending end sequentially concatenates the first 4 bytes of the modified UDP header, the newly inserted LLC control frame, and the last 4 bytes of the original UDP header, followed immediately by the original UDP payload data, forming a complete bypass message structure to be sent. This embedded modification eliminates the need for additional encapsulation of outer IP and UDP headers at the link layer. Compared to the traditional IP tunneling scheme, which requires an additional 28 bytes of overhead (20 bytes of outer IP header + 8 bytes of outer UDP header), this application adds only 8 bytes of LLC frames through internal message structure adjustments, resulting in a net saving of approximately 20 bytes of transmission overhead per packet. This significantly improves payload transmission efficiency in low-bandwidth scenarios such as narrowband private networks and satellite communications.

[0132] As shown in the figure Figure 3 This paper demonstrates the specific field structure of the custom 8-byte LLC control frame defined in this application. This structure is the core link for achieving low-overhead message restoration and multi-link transmission scheduling. From Figure 3 It is clearly visible that the control frame is divided into: a 2-byte "length" field and a 2-byte "checksum" field, used to ensure the length identification and integrity verification of the data payload; followed by a 2-byte control bit field, which is finely divided into 2 bits for "fragmentation status", 5 bits for "fragmentation sequence number", 1 bit for "retransmission identifier", 2 bits for "link identifier", and 6 bits for "reserved bits", ensuring ordered fragment reassembly, out-of-order retransmission processing, and link quality statistics in multi-link environments. The "connection ID" (8 bits) and "node ID" (8 bits) at the end together form a unique connection identifier for the entire network. The receiving end only needs to use this dual ID combination index to accurately locate the five-tuple information, without carrying lengthy source / destination IP and port in the message. Thus, with only 8 bytes of overhead, it can achieve accurate binding and restoration of all core session states, which strongly supports the low-overhead transmission system of this patent.

[0133] As shown in the figure Figure 4This diagram visually demonstrates a detailed comparison of the UDP packet structure before and after the insertion of the LLC control frame in this application. The upper layer of the diagram represents the standard UDP packet structure, consisting of an Ethernet header (14 bytes), an IP header (20 bytes), a standard 8-byte UDP header (including source / destination ports, length, and checksum), and a UDP payload. The lower layer represents the bypass packet structure of this application, the core of which lies in the "embedded" splitting and modification of the standard UDP header: retaining the first 4 bytes of the original UDP header's "port information" (source / destination ports), precisely inserting an 8-byte "LLC transport header" in the middle, followed by the last 4 bytes of the original UDP header's "original UDP header information" (length and checksum), and finally the original UDP payload. This structure accurately maps the core encapsulation logic of this application, cleverly embedding the control signaling necessary for multi-link transmission seamlessly into the gaps within the UDP header without adding an outer IP header or outer UDP header. This lays a solid structural foundation for the subsequent accurate location decompression and lossless, low-overhead packet restoration at the receiving end.

[0134] In one embodiment, step S6 specifically includes:

[0135] The sending end encapsulates a MAC header, sets the destination MAC address in the MAC header to the MAC address of the next-hop network device, sets the source MAC address in the MAC header to the exit MAC address corresponding to the optimal physical transmission link, and then sends the encapsulated bypass message into the sending queue of the optimal physical transmission link and sends it to the receiving end through the physical interface.

[0136] The receiving end intercepts the incoming IP data packets at the data entry point and identifies the bypass packet by checking whether the protocol type of the IP data packet is UDP and whether the value of the destination port field is the private port number.

[0137] The receiving end locates the start position of the UDP header of the bypass message, locates the LLC control frame by offsetting a fixed length from the start position of the UDP header, reads and parses each field of the LLC control frame, and extracts the connection identifier and the link identifier from them.

[0138] Specifically, in this embodiment, firstly, during the transmission phase at the sending end, after completing the LLC control frame insertion and UDP port modification in step S5, the sending end needs to further encapsulate the MAC address at the data link layer. Based on the network topology information of the selected optimal physical transmission link, the sending end extracts the MAC address of the next-hop network device as the destination MAC address in the MAC header; simultaneously, it sets the MAC address of the physical egress network card corresponding to the physical link as the source MAC address in the MAC header. After encapsulation, the sending end sends the fully encapsulated bypass message to the network driver transmission queue of the optimal physical transmission link, waiting for the underlying physical interface to arbitrate according to the queue order and transmit it to the receiving end via a wireless RF antenna or wired interface, ensuring that the message is transmitted out at the physical layer along the optimal path.

[0139] Next, during the receiver identification phase, the receiver is configured with a deep packet inspection engine at the data entry point to continuously capture the status of each arriving IP datagram. The receiver executes a two-condition logical judgment process: first, it checks whether the network layer protocol type of the IP datagram is UDP; if it is UDP, it further reads the destination port field of the UDP header and determines whether its value precisely matches the private port number pre-configured by the receiver. Only when both of the above conditions are met simultaneously, the receiver determines that the packet is a bypass packet that requires special processing as defined in this application, thereby separating it from the massive background traffic.

[0140] Finally, during the parsing phase at the receiving end, after confirming that it is a bypass message, the receiving end quickly locates the start position of the UDP header. Since this application strictly specifies in step S5 that the LLC control frame is located at a fixed position after the first 4 bytes of the UDP header, the receiving end directly offsets 4 bytes (i.e., the length of the first 4 bytes of the UDP header) from the start position of the UDP header to accurately locate the start boundary of the LLC control frame. Subsequently, according to the preset 8-byte LLC frame field definition rules, the receiving end reads and parses key fields such as the connection sequence number, terminal identifier, and link identifier in the LLC control frame, and extracts the connection identifier (composed of the connection sequence number and terminal identifier) ​​and the link identifier as the unique index credentials for finding the original five-tuple information and link quality statistics in the next step S7. At this point, the receiving end has completed the accurate identification of the bypass message and the extraction of core identifier information, preparing the data for subsequent message restoration and submission.

[0141] In one embodiment, step S7 specifically includes:

[0142] The receiving end extracts the connection identifier, uses the connection sequence number and the terminal identifier as a joint index, and performs a matching search in the connection information table maintained locally by the receiving end to obtain the original five-tuple information corresponding to the bypass message.

[0143] The receiving end modifies and restores the source IP address in the bypass packet IP header to the original source IP address and the destination IP address in the IP header to the original destination IP address based on the original source IP address and the original destination IP address in the original 5-tuple information, and recalculates the IP header checksum based on the modified IP header content.

[0144] The receiving end reads the original protocol type from the original 5-tuple information; if the original protocol type is UDP, then the source port of the UDP header in the bypass message is directly restored to the original source port and the destination port is restored to the original destination port, and the UDP checksum is recalculated; if the original protocol type is TCP, then the receiving end first restores the protocol type field in the IP header of the bypass message from UDP to TCP, then restores the source port and destination port of the TCP header to the original source port and the original destination port, and finally recalculates the TCP checksum to complete the complete restoration of the message transport layer header.

[0145] Specifically, in this embodiment, step S7 is essentially the core step for the receiving end to perform data backtracking and protocol reversal on the bypass message. This step first uses the connection identifier (including connection sequence number and terminal identifier) ​​parsed in the previous step as a combined index to perform a precise match search in the connection information table maintained locally by the receiving end. Since the connection sequence number may be reused between different sending end devices, this application innovatively adopts a dual-field combined index mechanism of "terminal identifier + connection sequence number", which effectively avoids the five-tuple collision and disorder problem in cross-sender scenarios, and ensures that the complete original five-tuple information corresponding to the bypass message before it is bypassed and compressed by the sending end can be accurately obtained. This information includes the original source IP, original destination IP, original protocol type, original source port, and original destination port.

[0146] The receiving end then enters the IP layer reconstruction phase. Based on the original source IP and original destination IP in the original 5-tuple information, the receiving end performs precise targeted modification of the IP header of the current bypass packet: the source IP address, which has been modified to the physical egress IP, is restored to the original virtual source IP at the time of interception; the destination IP address in the IP header is restored to the original communication destination IP. During this process, because the core IP address field of the IP layer has undergone substantial changes, the original checksum of the IP header has become completely invalid. The receiving end must strictly follow the IP protocol specifications and recalculate and fill the IP header checksum field according to the entire content of the modified IP header to prevent intermediate routing forwarding devices or the local protocol stack from judging the legitimate packet as a corrupted packet and discarding it due to checksum errors.

[0147] Finally, the receiving end performs the transport layer header restoration operation, which is divided into two parallel processing branches based on the original protocol type. If the original protocol type is UDP, the receiving end directly modifies the current UDP header according to the source port and destination port in the original five-tuple, and recalculates the UDP checksum; if the original protocol type is TCP, since the sending end changed the IP protocol number from TCP (6) to UDP (17) in step S4, the receiving end must perform a strict protocol inversion operation: first, restore the protocol type field in the IP header from UDP to TCP, and then restore the source port and destination port in the TCP header. Since step S4 of this application preserves the integrity of the TCP header and payload, after restoring the port, the receiving end must strictly recalculate the TCP checksum and write it into the TCP header according to the TCP pseudo-header overlay rules (including source IP, destination IP, protocol number and TCP length). Through the above-mentioned hierarchical and precise restoration actions, this step completes the logical reconstruction of the complete header information from the network layer to the transport layer, laying the foundation for the physical deletion of LLC control frames and restoration of the standard message structure in the next step S8.

[0148] In one embodiment, step S8 specifically includes:

[0149] The receiving end locates the starting position of the LLC control frame, the last 4 bytes of the UDP header, and the subsequent payload data in the current bypass message. It then moves the last 4 bytes of the UDP header and the subsequent payload data forward as a whole through a memory shifting operation, directly overwriting and erasing the space occupied by the LLC control frame. This allows the first 4 bytes of the UDP header to be seamlessly joined with the last 4 bytes of the UDP header, restoring the standard-length UDP header structure.

[0150] The receiving end makes a judgment based on the fragmentation flag and fragmentation sequence number obtained from parsing. If the fragmentation flag indicates no fragmentation, the current message is determined to be a complete message, and the process proceeds directly to the next step. If the fragmentation flag indicates the first fragment, middle fragment, or last fragment, the current message is determined to be a fragmented message. The receiving end caches the current fragment in the local receiving and reassembling window and sorts them according to the fragmentation sequence number. When all fragments corresponding to the same original message are received in the receiving and reassembling window, they are reassembled from the first fragment to the last fragment according to the fragmentation sequence number to restore the complete original service message.

[0151] The receiving end checks the continuity of the sequence number of the restored complete original service message in its respective service flow. If the sequence number of the current message is continuous with the sequence number of the previously submitted message, the receiving end immediately submits the current message to the upper-layer protocol stack. If the sequence number of the current message is not continuous and there is a gap in the sequence number, the receiving end temporarily stores the current message in the receiving window and starts a timeout wait or sends a retransmission request to the sending end. After the missing intermediate message in the receiving window is successfully received and reassembled, the receiving end submits multiple consecutive messages in the receiving window to the upper-layer protocol stack in the order of the original sequence numbers.

[0152] Specifically, in this embodiment, the receiving end first precisely locates the starting memory address of the LLC control frame, the last 4 bytes of the UDP header, and the subsequent payload data in the current bypass message. Since the LLC control frame is inserted between the first 4 bytes and the last 4 bytes of the UDP header in step S5, the receiving end then calls the memory relocation processing module to perform a lightweight byte-level memory copy operation: the last 4 bytes of the UDP header and all subsequent payload data are moved forward by 8 bytes (i.e., the length of the LLC control frame), directly overwriting and physically erasing the space occupied by the LLC control frame. After this operation, the first 4 bytes and the last 4 bytes of the UDP header are seamlessly joined together, restoring the standard 8-byte complete UDP header structure. Combined with the IP header and transport layer port information restored in step S7, the bypass message is now completely restored to the conventional protocol message format of "IP header + standard UDP / TCP header + payload," completely eliminating the additional control structure traces introduced into the transmission link by this patented method.

[0153] Next, the fragmented message is reassembled. The receiving end extracts the fragmentation flag and fragmentation sequence number obtained in step S6 to determine the fragmentation status. If the fragmentation flag indicates no fragmentation (value 3), it means that the current message is a complete original service message and does not need to be reassembled, proceeding directly to the next step; if the fragmentation flag indicates the first fragment (value 2), the middle fragment (value 0), or the last fragment (value 1), it means that the original message was fragmented into multiple fragments at the sending end due to MTU limitations or multi-link load balancing strategies. At this time, the receiving end opens a local receive reassembly window and stores the current fragment in the corresponding memory location within the window according to the fragmentation sequence number. The sending end promises the receiving end the integrity of all fragments under this index through the connection identifier and fragmentation sequence number in the LLC control frame. When all fragments corresponding to the same original message are collected in the receive reassembly window, they are assembled sequentially from the first fragment to the last fragment according to the fragmentation sequence number, accurately restoring the complete original service message.

[0154] Finally, the packets are submitted in order. After reconstructing the complete packet, the receiving end further extracts the packet's sequence number in the original service flow (for UDP, this is the auto-incrementing sequence number within the LLC frame; for TCP, it reads the original TCP sequence number). It then checks if this sequence number is consecutive to the sequence number of the last packet successfully submitted to the upper-layer protocol stack. If the current packet's sequence number is consecutive, it proves that the packet flow has achieved lossless order preservation on the out-of-order, connectionless heterogeneous wireless link, and the current packet is immediately delivered to the upper-layer protocol stack. If the current packet's sequence number is not consecutive, with gaps (i.e., a packet with a missing intermediate sequence number), the receiving end temporarily stores the current packet in the waiting queue of the receiving window and simultaneously initiates a retransmission request mechanism or a timeout waiting timer until the missing intermediate packet is successfully received, reassembled, and completed. Then, the receiving end submits a group of consecutive packets buffered in the receiving window to the upper-layer protocol stack in strict order of the original sequence numbers. (See figure.) Figure 5 This demonstrates the entire process of UDP uplink service processing at the sending end. It includes: intercepting packets and extracting the five-tuple to establish a connection; dynamically selecting a route and modifying the IP header based on real-time link quality; the core step being inserting an LLC control frame into the UDP header and modifying the destination port; and finally, adaptive fragmentation, independent encapsulation of the MAC header, and transmission via the optimal physical link.

[0155] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0156] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0157] It should be particularly noted that, through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, or of course, by hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0158] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A multi-link converged transmission method based on UDP bypass header compression, characterized in that, Includes the following steps: Step S1: The original service message to be sent is intercepted by the sending end, and the five-tuple information of the original service message is extracted. The five-tuple information includes the source IP address, destination IP address, protocol type, source port and destination port. Step S2: The sending end searches for the corresponding connection identifier in the local connection table based on the five-tuple information; If the search fails, a new connection identifier is assigned, and the five-tuple information is bound to the new connection identifier. The five-tuple information and the new connection identifier are then synchronized to the receiving end via control signaling. Step S3: The sending end obtains the real-time link quality of multiple heterogeneous transmission links, selects the optimal physical transmission link, and modifies the source IP address of the IP header of the original service packet to the exit IP address of the optimal physical transmission link. Step S4: The sending end determines the protocol type of the original service message: if it is UDP, then proceed to step S5. If it is TCP, then change the protocol type in the IP header to UDP and execute step S5; Step S5: The sending end inserts an LLC control frame between the first 4 bytes and the last 4 bytes of the UDP header of the original service message. The first 4 bytes are the source port and destination port fields, and the last 4 bytes are the length and checksum fields. The destination port of the UDP header is modified to the private port number preset by the receiving end. The LLC control frame contains at least the connection identifier and the link identifier. Step S6: After encapsulating the MAC header, the sending end sends the processed message to the receiving end through the optimal physical transmission link; the receiving end intercepts the bypass message whose destination port is the private port number, locates and parses the LLC control frame at an offset of 4 bytes from the UDP header, and obtains the connection identifier and link identifier. Step S7: The receiving end uses the connection identifier as an index to look up the local connection information table, obtains the corresponding original 5-tuple information, restores the source IP of the IP header to the original source IP, and if it is a TCP service, restores the protocol type to TCP, and restores the source port and destination port of the transport layer header. Step S8: The receiving end deletes the LLC control frame, moves the last 4 bytes of the UDP header and the payload data forward to cover the LLC control frame, restores the standard IP header and transport layer header structure, and submits them to the upper-layer protocol stack in sequence.

2. The method according to claim 1, characterized in that, Step S1 specifically includes: Configure flow table filtering policies at the data egress point of the sending end to capture IP data packets to be sent in real time; Determine whether the source IP address of the IP data packet matches a preset virtual IP address; if the source IP address matches the preset virtual IP address, then determine that the IP data packet is an original service packet that needs to be bypassed, and proceed to the next step; if the source IP address does not match the preset virtual IP address, then directly allow the IP data packet to pass without subsequent bypassing processing. Extract the five-tuple information from the original service message. The five-tuple information includes the source IP address, destination IP address, protocol type, source port, and destination port.

3. The method according to claim 1, characterized in that, Step S2 specifically includes: The sending end uses the five-tuple information as the query keyword to perform a hash lookup in the local connection table maintained by the sending end to determine whether the five-tuple information has been bound to the corresponding connection identifier. If the hash lookup is successful, the found connection identifier is directly obtained as the connection identifier for the current service flow; if the hash lookup is unsuccessful, the original service message is determined to be a new service flow, the sending end allocates an unused connection number from a preset idle connection number pool, and combines the connection number with the sending end's terminal identifier to form the connection identifier; subsequently, the sending end writes the mapping record of the five-tuple information and the connection identifier into the local connection table; If a new connection identifier is assigned, the sending end constructs a connection establishment control signaling and sends the five-tuple information and the assigned connection identifier to the receiving end through a preset signaling channel or out-of-band channel, so that the receiving end, after receiving the connection establishment control signaling, synchronously saves the correspondence between the five-tuple information and the connection identifier in its local connection information table.

4. The method according to claim 1, characterized in that, Step S3 specifically includes: The transmitting end measures the link quality parameters of the multiple heterogeneous transmission links in real time according to a preset detection period. The link quality parameters include at least the round-trip time (RTT), real-time packet loss rate, and current available bandwidth of each link. The transmitting end calculates a comprehensive score for each of the multiple heterogeneous transmission links according to a preset weighted scoring rule. The comprehensive score is negatively correlated with the round-trip time (RTT) and the real-time packet loss rate, and positively correlated with the current available bandwidth. The physical link with the highest comprehensive score is selected as the current optimal transmission link. The sending end extracts the IP header of the original service message, modifies the source IP address in the IP header to the physical egress IP address corresponding to the current optimal transmission link, and recalculates the IP header checksum based on the modified IP header.

5. The method according to claim 1, characterized in that, Step S4 specifically includes: The sending end reads the IP header of the original service message, extracts the protocol type field in the IP header, and determines whether the current value of the protocol type field represents the UDP protocol or the TCP protocol. If the value of the protocol type field is determined to be UDP, the original service message content remains unchanged, and step S5 is directly performed; if the value of the protocol type field is determined to be TCP, the sending end modifies the value of the protocol type field in the IP header from TCP to UDP, while keeping the TCP header and TCP payload data in the TCP service message intact in the original message position without modification. The processed message is then used as the message to be compressed, and the process proceeds to step S5.

6. The method according to claim 1, characterized in that, Step S5 specifically includes: The sending end locates the UDP header from the original service message and logically splits the UDP header into the first 4 bytes and the last 4 bytes. The first 4 bytes are the source port and destination port fields in the UDP header, and the last 4 bytes are the length and checksum fields in the UDP header. The sending end inserts the LLC control frame after the first 4 bytes of the UDP header and before the last 4 bytes, and fills the connection sequence number field, terminal identifier field, link identifier field and length field in the LLC control frame according to the connection identifier found in step S2, the link identifier selected in step S3 and the payload length of the current message respectively. The sending end modifies the destination port field in the first 4 bytes of the UDP header to the private port number preset by the receiving end, and then concatenates the first 4 bytes of the UDP header, the LLC control frame, and the last 4 bytes of the UDP header together to form the bypass message structure to be transmitted together with the subsequent original UDP payload. The LLC control frame specifically includes the following fields: The connection identifier field contains the connection sequence number and terminal identifier, which is used by the receiving end to look up the local connection information table to obtain the original 5-tuple; The fragmentation control field contains a fragmentation flag and a fragmentation sequence number, which are used by the receiving end for fragmentation identification and reassembly. The retransmission flag field is used to indicate whether the current message is a retransmission message; The link identifier field is used to identify the physical link used by the current packet; The length field is used to record the length of the payload data; The checksum field is used for data integrity verification.

7. The method according to claim 1, characterized in that, Step S6 specifically includes: The sending end encapsulates a MAC header, sets the destination MAC address in the MAC header to the MAC address of the next-hop network device, sets the source MAC address in the MAC header to the exit MAC address corresponding to the optimal physical transmission link, and then sends the encapsulated bypass message into the sending queue of the optimal physical transmission link and sends it to the receiving end through the physical interface. The receiving end intercepts the incoming IP data packets at the data entry point and identifies the bypass packet by checking whether the protocol type of the IP data packet is UDP and whether the value of the destination port field is the private port number. The receiving end locates the start position of the UDP header of the bypass message, locates the LLC control frame by offsetting a fixed length from the start position of the UDP header, reads and parses each field of the LLC control frame, and extracts the connection identifier and the link identifier from them.

8. The method according to claim 1, characterized in that, Step S7 specifically includes: The receiving end extracts the connection identifier, uses the connection sequence number and the terminal identifier as a joint index, and performs a matching search in the connection information table maintained locally by the receiving end to obtain the original five-tuple information corresponding to the bypass message. The receiving end modifies and restores the source IP address in the bypass packet IP header to the original source IP address and the destination IP address in the IP header to the original destination IP address based on the original source IP address and the original destination IP address in the original 5-tuple information, and recalculates the IP header checksum based on the modified IP header content. The receiving end reads the original protocol type from the original 5-tuple information; if the original protocol type is UDP, then the source port of the UDP header in the bypass message is directly restored to the original source port and the destination port is restored to the original destination port, and the UDP checksum is recalculated; if the original protocol type is TCP, then the receiving end first restores the protocol type field in the IP header of the bypass message from UDP to TCP, then restores the source port and destination port of the TCP header to the original source port and the original destination port, and finally recalculates the TCP checksum to complete the complete restoration of the message transport layer header.

9. The method according to claim 1, characterized in that, Step S8 specifically includes: The receiving end locates the starting position of the LLC control frame, the last 4 bytes of the UDP header, and the subsequent payload data in the current bypass message. It then moves the last 4 bytes of the UDP header and the subsequent payload data forward as a whole through a memory shifting operation, directly overwriting and erasing the space occupied by the LLC control frame. This allows the first 4 bytes of the UDP header to be seamlessly joined with the last 4 bytes of the UDP header, restoring the standard-length UDP header structure. The receiving end makes a judgment based on the fragmentation flag and fragmentation sequence number obtained from parsing. If the fragmentation flag indicates no fragmentation, the current message is determined to be a complete message, and the process proceeds directly to the next step. If the fragmentation flag indicates the first fragment, middle fragment, or last fragment, the current message is determined to be a fragmented message. The receiving end caches the current fragment in the local receiving and reassembling window and sorts them according to the fragmentation sequence number. When all fragments corresponding to the same original message are received in the receiving and reassembling window, they are reassembled from the first fragment to the last fragment according to the fragmentation sequence number to restore the complete original service message. The receiving end checks the continuity of the sequence number of the restored complete original service message in its respective service flow. If the sequence number of the current message is continuous with the sequence number of the previously submitted message, the receiving end immediately submits the current message to the upper-layer protocol stack. If the sequence number of the current message is not continuous and there is a gap in the sequence number, the receiving end temporarily stores the current message in the receiving window and starts a timeout wait or sends a retransmission request to the sending end. After the missing intermediate message in the receiving window is successfully received and reassembled, the receiving end submits multiple consecutive messages in the receiving window to the upper-layer protocol stack in the order of the original sequence numbers.

Images