Gateway intelligent acceleration method and system for cloud collaboration and terminal interaction

Abstract

The invention relates to the technical field of gateway acceleration, and discloses a gateway intelligent acceleration method and system for cloud collaboration and terminal interaction. The method comprises the steps that a gateway collects hardware fingerprints, loads a drive through an insmod instruction, allocates a fixed cache and an elastic cache, establishes MQTT long connection to send a heartbeat packet, and receives edge nodes to establish pre-connection; the cloud receives a backbone network routing table UPDATE message through a BGP protocol, and generates a path instruction containing an edge node address; and according to the path instruction, the gateway forwards the data packet scheduled by the WRED to the edge node address and forwards the data packet to a game server through the edge node. According to the method, a real-time communication channel between the gateway and the cloud is established through MQTT long connection, the high-priority game flow transmission quality is preferentially guaranteed when the network is congested, packet loss of competitive games is avoided, it is guaranteed that game data packets are always transmitted along the optimal path, game delay is effectively reduced, and the stability and reliability of an acceleration system are improved.

Description

A gateway intelligent acceleration method and system for cloud collaboration and terminal interaction Technical Field

[0001] This invention relates to the field of gateway acceleration technology, and in particular to a gateway intelligent acceleration method and system for cloud collaboration and terminal interaction. Background Technology

[0002] Existing game acceleration solutions suffer from the following main problems: First, the gateway communicates with the cloud using HTTP polling or timed synchronization, resulting in status reporting cycles of tens of seconds. The cloud cannot perceive real-time changes in gateway operation and network quality, leading to delayed acceleration strategy adjustments and an inability to respond promptly to network congestion or node failures. Second, the use of fixed-priority queues or simple weighted polling lacks a dynamic packet loss control mechanism. During network congestion, game data packets are treated the same as regular traffic, causing excessive packet loss and impacting the user experience. Third, path planning relies on static routing tables, with update cycles lasting hours or even days. This makes them unable to adapt to dynamic changes such as backbone network congestion and node failures, resulting in data packets being forwarded to high-latency nodes and increasing game latency. Summary of the Invention

[0003] The main objective of this invention is to provide a gateway intelligent acceleration method and system for cloud collaboration and terminal interaction. This invention establishes a real-time communication channel between the gateway and the cloud through an MQTT long connection, prioritizes the transmission quality of high-priority game traffic when the network is congested, avoids packet loss in competitive games, ensures that game data packets are always transmitted along the optimal path, effectively reduces game latency and improves the stability and reliability of the acceleration system.

[0004] To achieve the above objectives, this invention provides a gateway intelligent acceleration method for cloud-based collaboration and terminal interaction, comprising the following steps: the gateway collects hardware fingerprints, loads drivers via the insmod command and allocates fixed and elastic caches, establishes an MQTT long connection to send heartbeat packets, and receives pre-connection requests from edge nodes; the cloud receives backbone network routing table UPDATE messages via the BGP protocol and generates path instructions containing edge node addresses; according to the path instructions, the gateway forwards data packets scheduled by WRED to the edge node addresses and forwards them to the game server via the edge nodes.

[0005] Optionally, in a first implementation of the first aspect of the present invention, the gateway collects hardware fingerprints, loads drivers via the insmod command, allocates fixed and elastic caches, establishes an MQTT long connection, sends heartbeat packets, and receives responses from edge nodes to establish pre-connections. This includes: the gateway obtaining CPU model, memory capacity, firmware version, and network port speed and combining them to generate a hardware fingerprint; matching the hardware fingerprint with a driver pool; loading drivers via the insmod command; allocating fixed caches to store binary feature libraries and data packet cache queues; dynamically allocating elastic caches based on remaining memory; initiating TLS connections to the MQTT Broker and subscribing to command topics and publishing status topics; encapsulating CPU utilization, memory usage, acceleration status, real-time latency, and packet loss rate into heartbeat packets and sending them; and receiving response information containing edge node addresses and port numbers to establish pre-connections.

[0006] Optionally, in the second implementation of the first aspect of the present invention, after the receiving edge node establishes a pre-connection, the method further includes: performing a hash lookup on the destination IP and destination port of the game data packet against a binary feature library; when the hash lookup result is a mismatch, skipping the IP header and TCP header and scanning the feature code with a preset window size and step value, parsing the operator label of the GTP tunnel header extension field, and obtaining the traffic type code; generating a corresponding traffic priority tag according to the traffic type code and writing it into the TOS field of the game data packet IP header in binary encoding, and extracting the source IP, source port, destination IP, and destination port 5-tuple as an index to establish a session table entry in the hash table.

[0007] Optionally, in the third implementation of the first aspect of the present invention, when the hash lookup result is not a match, the IP header and TCP header are skipped, and the feature code is scanned with a preset window size and step value, and the operator label of the extended field of the GTP tunnel header is parsed to obtain the traffic type code, including: when the hash lookup result is not a match, skipping the IP header and TCP header, sliding the game data packet payload according to the preset window size and moving the window position according to the preset step value; performing binary comparison of each window content with the feature code in the binary feature library to obtain the feature code scanning result; when the feature code scanning result is not a match, extracting the first byte of the extended field from the GTP tunnel header of the game data packet as the traffic type code and the second byte as the game server cluster identifier.

[0008] Optionally, in a fourth implementation of the first aspect of the present invention, the method further includes: obtaining the current queue length and the historical average queue length according to the traffic priority marker, and calculating the average queue length based on the current queue length and the historical average queue length; comparing the average queue length with a preset minimum threshold and a maximum threshold; when the average queue length is between the minimum threshold and the maximum threshold, calculating the packet loss probability and generating a random number, comparing the random number with the packet loss probability to determine whether to discard the data packet; generating a token according to the traffic priority marker, checking the number of tokens in the token bucket and deducting the number of tokens corresponding to the data packet size when the data packet is dequeued, and forwarding the data packet.

[0009] Optionally, in a fifth implementation of the first aspect of the present invention, generating tokens according to the traffic priority marker, checking the number of tokens in the token bucket and deducting the number of tokens corresponding to the data packet size when the data packet is dequeued, and forwarding the data packet, includes: setting the capacity and token generation rate of the token bucket according to the reserved bandwidth rate; converting the data packet size into the required number of tokens and comparing it with the number of available tokens in the token bucket when the data packet is dequeued; deducting the required number of tokens when the number of available tokens is sufficient and allowing dequeueing; blocking and waiting for token generation when the number of available tokens is insufficient; allocating the number of dequeue time slots according to the traffic priority marker within a preset scheduling period, and dequeuing data packets sequentially from the queues corresponding to each traffic priority marker according to the allocated number of time slots and forwarding them.

[0010] Optionally, in the sixth implementation of the first aspect of the present invention, the cloud receives the backbone network routing table UPDATE message via the BGP protocol and generates a path instruction containing the edge node address, including: extracting the NLRI, AS_PATH, NEXT_HOP, and MED attributes from the backbone network routing table UPDATE message and storing them in a routing table of a prefix tree structure; generating a network topology map by combining the CPU utilization, bandwidth utilization, and number of connections in the edge node load data; and, based on the network topology map, calculating the edge weights of the measured round-trip time, packet loss rate, and node CPU utilization of the link, maintaining open and closed sets, selecting the node with the smallest f value to expand until the target node is reached, and then backtracking to generate a path instruction containing the edge node address.

[0011] Optionally, in the seventh implementation of the first aspect of the present invention, based on the network topology graph, the edge weights of the measured round-trip time, packet loss rate, and node CPU utilization of the link are calculated, and the open set and closed set are maintained. The node with the smallest f value is selected and expanded until the target node is reached. Then, the path instruction containing the edge node address is generated. This includes: multiplying the link round-trip time, link packet loss rate, and node CPU utilization by the corresponding delay weight coefficient, stability weight coefficient, and load weight coefficient respectively, and summing them to obtain the edge weights and assigning them to the corresponding link edges of the network topology graph; initializing the open set to include gateway nodes, cyclically selecting the node with the smallest f value from the open set and moving it into the closed set, expanding the corresponding neighbor nodes, calculating the g value and h value, and updating the parent node pointer; when the target node enters the closed set, generating the path instruction containing the edge node address by backtracking the parent node pointer.

[0012] Optionally, in the eighth implementation of the first aspect of the present invention, according to the path instruction, the gateway forwards the data packet scheduled by WRED to the edge node address and forwards it to the game server through the edge node, including: parsing the edge node address and port number from the path instruction, modifying the destination address of the data packet scheduled by WRED to the edge node address, modifying the destination port to the port number while keeping the source address as the user equipment IP address, and forwarding it to the edge node address using SNAT; the edge node receives the data packet scheduled by WRED, reads the IP header TOS field to obtain the traffic priority mark, looks up the forwarding rules according to the traffic priority mark and the destination port, and forwards it to the game server.

[0013] This invention also provides a gateway intelligent acceleration system for cloud collaboration and terminal interaction, comprising: a connection establishment module, used by the gateway to collect hardware fingerprints, load drivers via the insmod command, allocate fixed and elastic caches, establish MQTT long connections to send heartbeat packets, and receive pre-connection requests from edge nodes; a path generation module, used by the cloud to receive backbone network routing table UPDATE messages via the BGP protocol and generate path instructions containing edge node addresses; and a data forwarding module, used by the gateway to forward data packets scheduled by WRED to the edge node addresses and then forward them to the game server via the edge nodes, according to the path instructions.

[0014] In summary, this invention establishes a real-time communication channel between the gateway and the cloud via an MQTT long connection. It uses fixed-period heartbeat packets to report operational metrics such as CPU utilization, memory usage, latency, and packet loss rate. The cloud can monitor the gateway status in real time and immediately issue optimization commands or trigger fault self-healing when an anomaly is detected. Compared to the traditional HTTP polling method, this significantly reduces status synchronization latency and fault response time. By combining a sliding window algorithm with Boyer-Moore pattern matching to scan game data packets for feature codes and parsing the fixed fields of traffic labels added by the operator in the GTP tunnel header, multi-level accurate traffic identification is achieved with high accuracy and short processing time. Based on traffic priority marking, an exponentially weighted moving average algorithm is used to calculate the average queue length. The packet loss probability is dynamically calculated based on the relationship between the queue length and the minimum and maximum thresholds. Combined with a token bucket mechanism, bandwidth is reserved for traffic of different priorities. The WRED algorithm can prioritize the transmission quality of high-priority game traffic during network congestion, avoiding packet loss in competitive games. The cloud receives real-time UPDATE messages from the operator's backbone network routing table via the BGP protocol, obtains dynamic information such as link status changes and bandwidth utilization, and calculates the optimal transmission path by combining edge node load data. The path update cycle is short and can adapt to dynamic network changes. When link congestion or node overload is detected, it automatically bypasses the fault point and replans the path to ensure that game data packets are always transmitted along the optimal path, effectively reducing game latency and improving the stability and reliability of the acceleration system. Attached Figure Description

[0015] Figure 1 is a schematic diagram of the steps of a gateway intelligent acceleration method for cloud collaboration and terminal interaction in an embodiment of the present invention; Figure 2 is a structural block diagram of a gateway intelligent acceleration system for cloud collaboration and terminal interaction in an embodiment of the present invention.

[0016] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0018] Referring to Figure 1, this embodiment provides a gateway intelligent acceleration method for cloud collaboration and terminal interaction, including the following steps: S1, the gateway collects hardware fingerprints, loads drivers via the insmod command, allocates fixed and elastic caches, establishes an MQTT long connection to send heartbeat packets, and receives pre-connection requests from edge nodes; S2, the cloud receives backbone network routing table UPDATE messages via the BGP protocol and generates path instructions containing edge node addresses; S3, according to the path instructions, the gateway forwards data packets scheduled by WRED to the edge node addresses and forwards them to the game server via the edge nodes.

[0019] In one example, the gateway collects hardware fingerprints, loads the driver via the `insmod` command, allocates fixed and elastic caches, establishes an MQTT long connection, sends heartbeat packets, and receives responses from edge nodes to establish pre-connections. This process includes: the gateway obtaining the CPU model, memory capacity, firmware version, and network port speed, combining them to generate a hardware fingerprint; matching the hardware fingerprint with the driver pool; loading the driver via the `insmod` command; allocating fixed caches to store binary signature libraries and data packet cache queues; dynamically allocating elastic caches based on remaining memory; initiating a TLS connection to the MQTT Broker and subscribing to command topics and publishing status topics; encapsulating CPU utilization, memory usage, acceleration status, real-time latency, and packet loss rate into heartbeat packets and sending them; and receiving response information containing edge node addresses and port numbers to establish pre-connections.

[0020] In this example, within one second of device power-on, the hardware adaptation module sequentially performs system resource information collection operations. It extracts CPU model information by reading the ` / proc / cpuinfo` file, such as common embedded processor models like MediaTek MT7621, Qualcomm IPQ8072, or Broadcom BCM63138. It also obtains the current physical memory capacity using the `free -m` command, extracts the OpenWRT firmware version identifier by parsing the ` / etc / openwrt_version` file using shell commands, and identifies the actual Ethernet port speed using the results returned by the `ethtool eth0` command. These four indicators are then encoded according to a preset format and concatenated to generate a hardware fingerprint string. This hardware fingerprint, as the sole basis for resource adaptation, is submitted to the local driver pool search logic for matching against a set of driver configurations categorized by CPU architecture. If a match is successful, the `insmod` command is immediately executed to dynamically load the corresponding driver module into the kernel space, thereby activating the packet processing logic optimized for that architecture. If a match fails, it automatically downgrades to a general-purpose compatible driver to ensure uninterrupted system operation. After driver loading is complete, a 32MB fixed cache area is allocated in the memory resource pool according to the initialization configuration. This cache area stores the binary format feature library files that game acceleration depends on, containing IP address ranges, port numbers, and feature code data for over 2000 games. It also maintains multiple priority data packet caching queues. In addition to the fixed cache, a maximum of 16MB of elastic cache space is dynamically allocated based on the actual remaining memory. This area is used for runtime needs such as temporary session table maintenance, statistical indicator calculation, and intermediate forwarding buffering. After local resources are prepared, the gateway communication module starts and initializes the MQTT client. It initiates a connection request based on a TLS encrypted channel to port 8883 according to the pre-configured cloud Broker address. After a successful connection, it subscribes to the command topic " / cloud / command / {device ID}" to receive path instructions, parameter configurations, and feature library update notifications. At the same time, it publishes its own status to the topic " / gateway / status / {device ID}" so that the cloud can obtain the device's operating status in real time. The status data publishing process is based on constructing heartbeat packets with a 1-second cycle. The heartbeat packets encapsulate multiple key indicators in JSON format, including CPU and memory usage information obtained in real time through the proc file system, as well as flags indicating the current acceleration status (e.g., 0 indicates no acceleration, 1 indicates acceleration), the real-time network latency value corresponding to the current game (obtained by performing ICMP probes on the target server to obtain the RTT value), and the packet loss rate (calculated based on the ratio of the number of data packets lost to the number of data packets sent per unit time). To reduce network overhead, the heartbeat packets are compressed using the ZLIB compression algorithm after generation, compressing the original approximately 1.2KB of data to no more than 400 bytes before being sent to the cloud via the MQTT protocol.After receiving the heartbeat packet, the cloud parses the device identifier and returns response data containing multiple edge node candidate information. The response lists the node IP address, port number, and current node load status. Based on this information, the gateway initiates a TCP three-way handshake operation to each node in turn to establish a pre-connection. The pre-connection is in the SYN_SENT state and is only used to quickly establish a session channel without transmitting actual business data.

[0021] In one example, after the receiving edge node establishes a pre-connection, the process further includes: performing a hash lookup of the destination IP and destination port of the game data packet against a binary signature database; when the hash lookup result is a no-match, skipping the IP header and TCP header and scanning the signature code with a preset window size and step value, parsing the carrier label in the extended field of the GTP tunnel header to obtain the traffic type code; generating a corresponding traffic priority tag based on the traffic type code and writing it into the TOS field of the game data packet IP header in binary encoding, and extracting the source IP, source port, destination IP, and destination port 5-tuple as an index to establish a session table entry in the hash table.

[0022] In this example, upon receiving external traffic, the gateway schedules its local traffic identification module to perform a combined matching operation between the destination IP address and destination port of the incoming data packets. The matching process is based on a hash lookup using a binary feature library pre-loaded into a fixed cache area. This feature library stores the mapping relationship between server IP ranges (using CIDR format, such as 192.168.0.0 / 16) and corresponding port ranges (such as 10000–10100) covering over 2000 games. By constructing a hash index table, the destination address and port are used as the key to input into the lookup function to obtain a preliminary result. If the hash lookup is successful, the corresponding game ID is identified, and the data packet is classified. If the hash lookup fails, meaning no match is found in the feature library, a secondary identification mechanism is activated to identify game protocol characteristics through feature code matching. This process first skips the first 40 bytes of the data packet, namely the IP header (20 bytes) and TCP header (20 bytes). Starting from byte 41, a sliding window-based signature scanning operation is performed. The sliding window size is fixed at 128 bytes, with a step size of 64 bytes, forming a continuously covering stream of data segments. At each window position, the captured data segment is compared byte-by-byte with the key protocol codes in known game handshake messages in the signature database. The comparison process uses the Boyer-Moore algorithm to improve matching efficiency, and on a typical embedded CPU architecture, the matching delay can be controlled to within 100 microseconds. If a match is still unsuccessful, the process proceeds to the third-level identification logic: parsing the GTP tunnel header extension field tagged by China Mobile operators for some game traffic in the backbone network. Bytes 12 to 20 of the GTP header are extracted from the data packet payload structure and decomposed into an 8-byte extension area. The first 2 bytes are the traffic type code (e.g., 0x0001 for competitive games, 0x0002 for cloud gaming, 0x0003 for IPTV, etc.), and the last 6 bytes are the service cluster identifier. Traffic type codes are used to look up preset traffic priority mappings and map them to one of six bandwidth scheduling levels, such as Level 6 for competitive games and Level 5 for cloud gaming. The priority is encoded as a 4-bit binary value and written to the high 4 bits (bits 4 to 7) of the TOS field in the IP header of the original data packet. After writing, the five-tuple information of the current data packet—source IP address, source port number, destination IP address, destination port number, and transport protocol type—is extracted as a composite key to construct a hash index for the traffic session table. A new entry is created for each five-tuple in the session table. This entry stores status parameters such as the game ID, priority flag, session creation time, cumulative transmitted bytes, and packet loss statistics for the most recent second, and is organized in a memory structure using a hash mapping method to ensure a query time complexity of O(1).

[0023] In one example, when the hash lookup result is not a match, the IP header and TCP header are skipped, and the signature is scanned with a preset window size and step value. The operator label in the extended field of the GTP tunnel header is parsed to obtain the traffic type code. This includes: when the hash lookup result is not a match, skipping the IP header and TCP header, sliding the game data packet payload according to the preset window size and moving the window position according to the preset step value; performing a binary comparison between the content of each window and the signature in the binary signature library to obtain the signature scan result; when the signature scan result is not a match, extracting the first byte of the extended field from the GTP tunnel header of the game data packet as the traffic type code and the second byte as the game server cluster identifier.

[0024] In this example, when the destination IP address and destination port number of a game data packet fail to match in the signature database during the hash lookup process, the system automatically enters the signature verification process to further identify unknown traffic. Using offset control logic, the system skips the first 40 bytes of the packet's protocol header information (20 bytes of IP header and 20 bytes of TCP header), treating the remaining portion as the payload area and scanning it according to a preset sliding window mechanism. The sliding window size is set to 128 bytes, and the step size is set to 64 bytes, covering all valid data segments that may embed protocol features during the scan. Starting from byte 41, the sliding window sequentially extracts bytes within its range and compares the data within each window byte-by-byte with a binary signature sequence stored locally in a fixed cache. The signature is a unique byte pattern with structural characteristics in the handshake packet, authentication packet, or heartbeat packet of each game protocol, such as a fixed prefix sequence, magic number, or asymmetric encryption start identifier. To improve comparison efficiency, the Boyer-Moore string matching algorithm is used to perform fast matching of signatures, achieving an average linear time complexity within each window, thereby controlling the comparison time of a single window to within 100 microseconds. After scanning and comparing all sliding windows, if no valid match is found with any signature, i.e., the signature scan result is a miss, the process enters the three-level identification logic based on operator traffic tags. In this stage, the extended field information for service classification is extracted by parsing the GTP tunnel header structure encapsulated in the data packet. The extended field is located between bytes 12 and 20 of the GTP header offset. This 8-byte extended area is parsed into multiple field segments. The first byte is defined as the traffic type code, indicating the service category to which the current data packet belongs. For example, 0x01 represents competitive games, 0x02 represents cloud gaming platform services, and 0x03 represents IPTV video streams. The following second byte is parsed as the game server cluster identifier code, which is used to characterize the service deployment cluster or regional node number to which the target server belongs.

[0025] In one example, the method further includes: obtaining the current queue length and the historical average queue length based on the traffic priority flag, and calculating the average queue length based on the current queue length and the historical average queue length; comparing the average queue length with a preset minimum threshold and a maximum threshold; when the average queue length is between the minimum threshold and the maximum threshold, calculating the packet loss probability and generating a random number, comparing the random number with the packet loss probability to determine whether to discard the data packet; generating a token based on the traffic priority flag, checking the number of tokens in the token bucket and deducting the number of tokens corresponding to the data packet size when the data packet is dequeued, and forwarding the data packet.

[0026] In this example, data packets are allocated to the corresponding sending queues based on traffic priority, and the current real-time length and historical average length of the queue are obtained. The historical average length is updated using an exponentially weighted moving average method, and the average length is calculated using the formula. (t) = (1 - weight) × average length (t-1) + Weight × Current Length (t) The average queue length is calculated, with a weighting coefficient set to a preset minimum value to smooth out instantaneous fluctuations and enhance responsiveness to long-term trends. The average queue length is compared to the minimum and maximum thresholds corresponding to this priority level. If the average length is below the minimum threshold, the queue pressure is low, and packets can pass directly without triggering drop. If the average length is above the maximum threshold, packet drop is performed with the highest probability of packet loss. When the average queue length is between the minimum and maximum thresholds, the current packet drop probability is calculated linearly using the formula: Packet Drop Probability = Maximum Packet Drop Probability × (Average Queue Length - Minimum Threshold) ÷ (Maximum Threshold - Minimum Threshold), yielding the probability that packet should be dropped at that moment. A random number between zero and one is generated and compared to the packet drop probability. If the random number is less than the packet drop probability, the current packet is determined to be dropped and not added to the queue; otherwise, the packet is allowed to join the queue and participate in subsequent scheduling. After a data packet passes the packet loss detection and successfully enters the queue, the scheduling module, when preparing the data packet for dequeueing, enters the token bucket management process according to its corresponding traffic priority level. Tokens are periodically generated according to the bandwidth guarantee rate preset for the traffic priority and filled into the token bucket of the corresponding priority. Each token corresponds to a unit of data packet forwarding capability. When a data packet is dequeued, the system checks in real time whether there are enough tokens in the current token bucket. If the number of available tokens is greater than or equal to the number of tokens required by the data packet (i.e., the data packet length divided by eight), the deduction operation is completed and the data packet is allowed to be forwarded. If the number of available tokens is insufficient, the data packet is blocked waiting for token generation. The maximum waiting time is no more than ten milliseconds. If enough tokens are not obtained after the timeout, forced forwarding is executed and the outstanding token amount is recorded for future repayment.

[0027] In one example, tokens are generated based on the traffic priority markers. When a data packet is dequeued, the number of tokens in the token bucket is checked, and the number of tokens corresponding to the data packet size is deducted before forwarding the data packet. This includes: setting the capacity and token generation rate of the token bucket according to the reserved bandwidth rate; when a data packet is dequeued, converting the data packet size into the required number of tokens and comparing it with the number of available tokens in the token bucket; when there are enough available tokens, deducting the required number of tokens to allow dequeueing; when there are insufficient available tokens, blocking and waiting for token generation; allocating the number of dequeue time slots within a preset scheduling period according to the traffic priority markers, and dequeuing data packets sequentially from the queues corresponding to each traffic priority marker according to the allocated number of time slots and forwarding them.

[0028] In this example, the token bucket capacity limit and token generation rate are set according to the reserved bandwidth rate for each traffic level. The token bucket capacity equals the reserved bandwidth multiplied by the unit time and converted to bytes. The token generation rate equals the total amount of data allowed to pass per second divided by eight. For example, when reserving 30 megabits per second of bandwidth, the capacity is 3.75 megabytes, and the token generation rate is 30 megabits divided by eight, which is 3.75 megabits per second. When a data packet is ready to be dequeued, the length of the current data packet is converted to the required number of tokens. The data packet length unit is converted from bytes to bits and divided by eight to obtain the number of tokens to be deducted from the current data packet. This value is compared with the number of tokens available in the current token bucket. If the number of available tokens is greater than or equal to the number of required tokens, it means that there are enough tokens. The corresponding number of tokens is immediately deducted from the token bucket, and the data packet is allowed to enter the dequeue process. If the number of available tokens is less than the number of required tokens, it means that the current available bandwidth is full. The data packet is blocked in the queue, waiting for the token generator to fill in new tokens in a subsequent cycle to meet the data packet forwarding conditions. The blocking waiting process sets a maximum waiting time threshold. If enough tokens are not acquired within the set time, forced forwarding is selected, and the outstanding token amount is recorded. Under the token mechanism constraint, the scheduling module initiates polling scheduling logic based on the priority marking of data packets. In each scheduling cycle, a corresponding number of dequeue slots are allocated according to each priority level. For example, level 6 is allocated six slots, level 5 is allocated five slots, level 4 is allocated four slots, and so on, down to level 1, which is allocated one slot. In each scheduling cycle, starting from the queue with the highest priority level, data packets that meet the conditions are retrieved sequentially according to the slot order and dequeued. Before dequeuing, the token availability is checked again to ensure that the forwarding operation does not exceed the bandwidth constraint boundary.

[0029] In one example, the cloud receives a backbone routing table UPDATE message via the BGP protocol and generates a path instruction containing edge node addresses. This includes: extracting the NLRI, AS_PATH, NEXT_HOP, and MED attributes from the backbone routing table UPDATE message and storing them in a prefix tree structure routing table; generating a network topology map by combining the CPU utilization, bandwidth utilization, and number of connections from the edge node load data; and, based on the network topology map, calculating the edge weights of the measured round-trip time, packet loss rate, and node CPU utilization, maintaining open and closed sets, selecting the node with the smallest f-value to expand until the target node is reached, and then backtracking to generate a path instruction containing edge node addresses.

[0030] In this example, the operator's cloud-based scheduling platform establishes neighbor connections with the backbone network routers via the Border Gateway Protocol (BGP) and continuously receives routing table UPDATE messages from the backbone network. Upon receiving each UPDATE message, the scheduling platform parses and extracts the NLRI field (network reachability prefix), the AS_PATH field (Autonomous System path sequence), the NEXT_HOP field (next-hop address), and the MED attribute field (used for link priority evaluation). These four attributes are then written as structured data into a prefix tree structure in memory, constructing a dynamic routing table that supports longest prefix matching. The prefix tree uses IP address prefixes as index nodes and performs insertion and lookup operations bit-by-bit, completing any prefix lookup operation within tens of microseconds. The cloud platform continuously aggregates real-time operational status data from all edge nodes, including resource metrics such as CPU utilization, uplink and downlink bandwidth utilization, and the number of active TCP connections obtained by parsing node status files or network interfaces. This node operational data is then integrated with the routing table structure to construct a complete network topology map. Vertices in the topology map represent backbone router nodes and acceleration nodes deployed at the access edge, while edges represent network connections between nodes. Edge weights are calculated based on multiple measured performance metrics, including measured round-trip latency, packet loss rate, and CPU resource load of the target node. Based on the network topology map, a path search module is initiated, employing a path search algorithm with a heuristic estimation function to calculate the shortest path. During execution, the algorithm maintains two dynamic sets: an open set and a closed set. The open set stores network nodes to be expanded, while the closed set records nodes for which path evaluation has been completed. The algorithm starts at the access node where the gateway is located and selects the node with the smallest current f-value from the open set to expand the search. The f-value is the estimated total path cost, which equals the sum of the known path cost and the heuristic function estimate. The heuristic function uses the geographical distance between the target node and the current node to estimate latency. For each expanded node, a latency weight is obtained by multiplying the link RTT value by 60%, a stability weight is obtained by subtracting the packet loss rate by 30%, and a load weight is obtained by subtracting the node's CPU utilization rate by 10%. The sum of these three weighted results forms the total edge cost. If a new path cost is found that is better than the currently known optimal path cost, the parent node pointer and total cost record of that node are updated, and it is added to the open set for further expansion. The algorithm repeats node expansion and cost updates until the target node enters the closed set, at which point the search stops. That is, based on the target node, the path is traced back up from the parent node pointer, layer by layer, to reconstruct an optimal path from the starting point to the ending point.The addresses of each hop node in the optimal path, the actual address of the selected edge node, the target server address, and the relevant forwarding port number are packaged into a structured path instruction and sent to the gateway device in a fixed-length format through a message publishing mechanism, so that the gateway can use the optimal path to perform data forwarding during the actual acceleration process.

[0031] In one example, based on the network topology graph, edge weights are calculated for measured round-trip time, packet loss rate, and node CPU utilization. Open and closed sets are maintained, and the node with the smallest f-value is selected and expanded until the target node is reached. Then, backtracking is performed to generate a path instruction containing edge node addresses. This includes: multiplying the link round-trip time, link packet loss rate, and node CPU utilization by their respective delay weight coefficient, stability weight coefficient, and load weight coefficient, and summing the results to obtain edge weights, which are then assigned to the corresponding link edges in the network topology graph; initializing the open set to include gateway nodes; cyclically selecting the node with the smallest f-value from the open set and moving it into the closed set, expanding the corresponding neighbor nodes, calculating g and h values, and updating the parent node pointer; and generating a path instruction containing edge node addresses by backtracking the parent node pointer after the target node enters the closed set.

[0032] In this example, in the constructed network topology graph, for each link edge representing a network connection, the measured round-trip time (RTT), packet loss rate, and CPU utilization of the connected node are obtained. These three metrics are then multiplied by preset weighting coefficients for latency, stability, and load, respectively. The RTT weighting coefficient is 60%, the link stability weighting coefficient is 30%, and the node load weighting coefficient is 10%. By summing these three weighted results, the comprehensive edge weight of the current link edge is calculated and assigned to the corresponding edge structure in the network topology graph. This weight represents the relative cost of the path in actual transmission, thus quantifying the dynamic characteristics of the network. After the edge weight assignment is complete, the path search module initiates the path calculation process, initializes the open set, adds the access node where the current gateway is located to the open set and sets its path cost to zero, and initializes the closed set to empty. The algorithm begins by executing a loop. In each iteration, it selects the node with the smallest f-value from the open set. The f-value consists of two parts: the actual total cost g from the starting point to the node and the heuristically estimated cost h from the node to the target node. The heuristic cost h is calculated by dividing the geographical distance between nodes by the speed of light and multiplying by a discount factor, and is used to roughly represent the potential cost of subsequent paths. After selecting the node with the smallest f-value, it is moved from the open set to the closed set, and all its directly connected neighbors are expanded. For each neighbor node, the g-value from the starting point to the current node is calculated and compared with the recorded historical g-values. If the calculated g-value is smaller, the neighbor node's g-value is updated, its parent node pointer is set to the current node, and it is added to the open set. This operation is continuously repeated, gradually expanding the most promising path nodes in each round and continuously optimizing the path selection based on dynamic edge weights, until the target node is successfully added to the closed set, indicating that a path with the smallest total cost has been fully confirmed. At this point, the expansion stops. Instead, starting from the target node, the system backtracks upwards along the recorded parent node pointers until it reaches the gateway starting node, thus reconstructing a complete optimal path. This path sequentially includes information about the gateway node, backbone router nodes, selected edge nodes, and each hop node leading to the target game server. The optimal path is encapsulated as a structured path instruction, which identifies the network address, transmission port number, and node sequence of the selected edge nodes. This path instruction is then sent to the target gateway via a long-lived connection mechanism, guiding it to use the latest calculated path for packet forwarding during the acceleration process.

[0033] In one example, according to the path instruction, the gateway forwards the WRED-scheduled data packet to the edge node address and then forwards it to the game server through the edge node. This includes: parsing the edge node address and port number from the path instruction; modifying the destination address of the WRED-scheduled data packet to the edge node address and the destination port to the port number while keeping the source address as the user device IP address; and forwarding it to the edge node address using SNAT. The edge node receives the WRED-scheduled data packet, reads the IP header TOS field to obtain the traffic priority flag, looks up the forwarding rules based on the traffic priority flag and the destination port, and forwards it to the game server.

[0034] In this example, after receiving the path instruction from the cloud at the gateway, the system performs structured parsing of the instruction, extracting the allocated edge node address and corresponding transmission port number, and using the edge node address and port as the target endpoint of the accelerated path. For data packets that have completed WRED scheduling, the gateway performs a destination address and port redirection operation before sending them. It modifies the destination IP address field in the original data packet to the edge node address in the path instruction and replaces the destination port field with the port number specified in the path instruction, ensuring that the data packet is correctly guided to the designated edge node during network transmission. Simultaneously, to ensure that response data can be correctly returned to the user device, the source IP address field remains unchanged while modifying the data packet header information; that is, the user terminal's real IP address continues to be used, avoiding packet path confusion or session identification failure due to source address changes. After completing the destination address and port replacement, the gateway uses source address translation to forward the data packet. This means that through the source address translation mechanism, the data packet is encapsulated in the transmission channel leading to the edge node and sent to the edge node address, realizing the accelerated path connection from the gateway to the edge node. Upon receiving a WRED-scheduled data packet forwarded from the gateway, the edge node reads the Type of Service (TOS) field in the IP header and parses out the four-bit binary priority flag set by the gateway. This flag indicates the traffic level of the current data packet; for example, level six represents competitive games, level five represents cloud gaming, and level four represents IPTV. The edge node uses the priority flag and the destination port number in the received data packet as dual search criteria to check its local forwarding table for a matching forwarding rule. The forwarding rules record the target server address and forwarding port for various game services on the current edge node. If a match is found, the edge node redirects the data packet to the corresponding target game server address according to the found rule, retaining the original TOS field information. This ensures the data packet maintains its priority scheduling attribute within the carrier's backbone network, achieving end-to-end quality of service assurance. During this process, the edge node optimizes the forwarding action based on local load conditions or multi-path strategies, such as selecting the server interface with the lowest load for outbound forwarding or performing round-robin balancing on multiple server clusters for the same game service to improve overall acceleration performance and stability. When the target game server receives the data packet and returns a response, the response packet will return to the edge node along the original path. The edge node restores the return path according to the session state information in the forwarding table, and then sends the response data back to the original gateway. The gateway then delivers the response packet to the user device through the destination address restoration and port translation mechanism.

[0035] Referring to Figure 2, this embodiment provides a gateway intelligent acceleration system for cloud collaboration and terminal interaction, including: a connection establishment module 1, used by the gateway to collect hardware fingerprints, load drivers via the insmod command, allocate fixed and elastic caches, establish an MQTT long connection to send heartbeat packets, and receive pre-connection requests from edge nodes; a path generation module 2, used by the cloud to receive backbone network routing table UPDATE messages via the BGP protocol and generate path instructions containing edge node addresses; and a data forwarding module 3, used by the gateway to forward data packets scheduled by WRED to the edge node addresses according to the path instructions, and then forward them to the game server via the edge nodes.

[0036] In this embodiment, the specific implementation of each unit in the above system embodiment is described in the above method embodiment, and will not be repeated here.

[0037] 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, system, article, or method 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, system, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, system, article, or method that includes that element.

[0038] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A gateway intelligent acceleration method for cloud-based collaboration and terminal interaction, characterized in that, include: The gateway collects hardware fingerprints, loads drivers and allocates fixed and elastic caches via the insmod command, establishes MQTT long connections to send heartbeat packets, and receives pre-connections from edge nodes. The cloud receives the backbone network routing table UPDATE message via the BGP protocol and generates a path instruction containing the edge node address. According to the path instruction, the gateway forwards the data packet scheduled by WRED to the edge node address and then forwards it to the game server through the edge node.

2. The gateway intelligent acceleration method for cloud collaboration and terminal interaction according to claim 1, characterized in that, The gateway collects hardware fingerprints, loads drivers via the `insmod` command, allocates fixed and elastic caches, establishes MQTT long connections, sends heartbeat packets, and receives responses from edge nodes to establish pre-connections. This process includes: the gateway obtaining CPU model, memory capacity, firmware version, and network port speed, combining them to generate a hardware fingerprint; matching the hardware fingerprint with the driver pool; loading the driver via the `insmod` command; allocating fixed caches to store binary signature libraries and data packet cache queues; dynamically allocating elastic caches based on remaining memory; initiating TLS connections to the MQTT Broker and subscribing to command topics and publishing status topics; encapsulating CPU utilization, memory usage, acceleration status, real-time latency, and packet loss rate into heartbeat packets and sending them; and receiving response information containing edge node addresses and port numbers to establish pre-connections.

3. The gateway intelligent acceleration method for cloud collaboration and terminal interaction according to claim 1, characterized in that, After the receiving edge node establishes a pre-connection, the process also includes: performing a hash lookup of the destination IP and destination port of the game data packet against the binary signature database; when the hash lookup result is a no-match, skipping the IP header and TCP header and scanning the signature code with a preset window size and step value, parsing the carrier label in the extended field of the GTP tunnel header, and obtaining the traffic type code; generating a corresponding traffic priority tag based on the traffic type code and writing it into the TOS field of the IP header of the game data packet in binary encoding, and extracting the source IP, source port, destination IP, and destination port 5-tuple as an index to establish a session table entry in the hash table.

4. The gateway intelligent acceleration method for cloud collaboration and terminal interaction according to claim 3, characterized in that, When the hash lookup result is not a match, the IP header and TCP header are skipped, and the signature is scanned with a preset window size and step value. The operator label in the extended field of the GTP tunnel header is parsed to obtain the traffic type code. This includes: when the hash lookup result is not a match, the IP header and TCP header are skipped, the game data packet payload is slid according to the preset window size and the window position is moved according to the preset step value; the content of each window is compared with the signature in the binary signature library to obtain the signature scan result; when the signature scan result is not a match, the first byte of the extended field of the game data packet is extracted as the traffic type code and the second byte is extracted as the game server cluster identifier from the GTP tunnel header of the game data packet.

5. The gateway intelligent acceleration method for cloud collaboration and terminal interaction according to claim 4, characterized in that, Also includes: The current queue length and the historical average queue length are obtained based on the traffic priority flag, and the average queue length is calculated based on the current queue length and the historical average queue length. The average queue length is compared with a preset minimum threshold and a maximum threshold. When the average queue length is between the minimum threshold and the maximum threshold, the packet loss probability is calculated and a random number is generated. The random number is compared with the packet loss probability to determine whether to discard the data packet. Tokens are generated according to the traffic priority label. When the data packet is dequeued, the number of tokens in the token bucket is checked and the number of tokens corresponding to the data packet size is deducted before forwarding the data packet.

6. The gateway intelligent acceleration method for cloud collaboration and terminal interaction according to claim 5, characterized in that, Generate tokens based on the traffic priority markers. When a data packet is dequeued, check the number of tokens in the token bucket, deduct the number of tokens corresponding to the data packet size, and forward the data packet. This includes: setting the capacity and token generation rate of the token bucket according to the reserved bandwidth rate; when a data packet is dequeued, converting the data packet size into the required number of tokens and comparing it with the number of available tokens in the token bucket; when there are enough available tokens, deducting the required number of tokens to allow dequeueing; when there are insufficient available tokens, blocking and waiting for token generation; allocating the number of dequeue time slots according to the traffic priority markers within a preset scheduling period, and sequentially dequeuing data packets from the queues corresponding to each traffic priority marker according to the allocated number of time slots and forwarding them.

7. The gateway intelligent acceleration method for cloud collaboration and terminal interaction according to claim 6, characterized in that, The cloud receives backbone network routing table UPDATE messages via the BGP protocol and generates path instructions containing edge node addresses. This includes: extracting NLRI, AS_PATH, NEXT_HOP, and MED attributes from the backbone network routing table UPDATE message and storing them in a prefix tree structure routing table; generating a network topology map by combining CPU utilization, bandwidth utilization, and connection count from edge node load data; and, based on the network topology map, calculating edge weights for measured round-trip time, packet loss rate, and node CPU utilization, maintaining open and closed sets, selecting the node with the smallest f-value to expand until the target node is reached, and then backtracking to generate path instructions containing edge node addresses.

8. The gateway intelligent acceleration method for cloud collaboration and terminal interaction according to claim 7, characterized in that, Based on the network topology, the edge weights of the measured round-trip time, packet loss rate, and node CPU utilization are calculated, and the open and closed sets are maintained. The node with the smallest f-value is selected and expanded until the target node is reached. Then, the process is backtracked to generate a path instruction containing the edge node address. This includes: multiplying the link round-trip time, link packet loss rate, and node CPU utilization by the corresponding delay weight coefficient, stability weight coefficient, and load weight coefficient, respectively, and summing them to obtain the edge weights, which are then assigned to the corresponding link edges in the network topology; initializing the open set to include the gateway node; cyclically selecting the node with the smallest f-value from the open set and moving it into the closed set, expanding the corresponding neighbor nodes, calculating the g and h values, and updating the parent node pointer; and generating a path instruction containing the edge node address by backtracking the parent node pointer after the target node enters the closed set.

9. The gateway intelligent acceleration method for cloud collaboration and terminal interaction according to claim 8, characterized in that, According to the path instructions, the gateway forwards the WRED-scheduled data packets to the edge node address and then forwards them to the game server through the edge node. This includes: parsing the edge node address and port number from the path instructions; modifying the destination address of the WRED-scheduled data packets to the edge node address and the destination port to the specified port number while keeping the source address as the user device IP address; and forwarding the packets to the edge node address using SNAT. The edge node receives the WRED-scheduled data packets, reads the IP header TOS field to obtain the traffic priority flag, searches for forwarding rules based on the traffic priority flag and the destination port, and forwards the packets to the game server.

10. A gateway intelligent acceleration system for cloud collaboration and terminal interaction, characterized in that, The steps of the gateway intelligent acceleration method for cloud collaboration and terminal interaction as described in any one of claims 1 to 9 include: a connection establishment module, used by the gateway to collect hardware fingerprints, load drivers via the insmod command, allocate fixed cache and elastic cache, establish an MQTT long connection to send heartbeat packets, and receive pre-connection establishment from edge nodes; a path generation module, used by the cloud to receive backbone network routing table UPDATE messages via the BGP protocol and generate path instructions containing edge node addresses; and a data forwarding module, used by the gateway to forward data packets scheduled by WRED to the edge node addresses and forward them to the game server via the edge nodes according to the path instructions.

Images