An optimization method for edge data transmission and computing task offloading in integrated computing network scenarios

Abstract

This invention proposes an optimized method for edge data transmission and computational task offloading in converged computing network scenarios. Through steps such as protocol identification, local protocol conversion, cloud-assisted processing of unknown protocols, packet tunneling encapsulation, packet parsing and storage, and state transition processing, it effectively processes data packets from multiple communication protocols, optimizing data transmission efficiency. Furthermore, this technical solution establishes a comprehensive model and employs an improved deep deterministic policy gradient algorithm to dynamically evaluate and optimize task offloading and migration decisions, reducing latency and improving processing speed and quality. Addressing the shortcomings of existing edge computing solutions in the collaborative optimization of data transmission and task processing, this invention proposes an efficient, flexible, and multi-protocol compatible optimization method, significantly improving network performance and user experience.

Description

Technical Field

[0001] This invention relates to the fields of communication networks and data processing technology, and specifically to a collaborative optimization method for data transmission and edge computing task offloading. Background Technology

[0002] With the rapid development of advanced technologies such as cloud computing, the Internet of Things (IoT), and 5G, the demand for data transmission and computing is exploding across various industries. Currently, networks are placing increasingly higher demands on data transmission efficiency and computing task processing capabilities. Against this backdrop, edge computing, as an emerging computing paradigm, aims to reduce network latency and improve data processing speed by processing data at the network edge, closer to the user, thereby optimizing the user experience. However, existing edge computing solutions still face many challenges in handling multi-protocol data transmission, offloading computing tasks, and co-optimizing with network transmission.

[0003] On the one hand, existing network environments contain various communication protocols, such as TCP, LoRa, and RS232. The poor compatibility between these protocols complicates and inefficiently transmits and processes data packets. Furthermore, the rapid increase in the number of devices leads to a surge in the types and quantities of data packets, placing immense pressure on network transmission and computational tasks. On the other hand, task offloading strategies are crucial in edge computing. Appropriate task offloading can not only reduce computational latency but also effectively utilize edge computing resources. However, dynamically determining task offloading based on real-time network conditions and the current load of edge nodes, and migrating tasks in response to changes in the network environment caused by user mobility, remain pressing technical challenges that need to be addressed.

[0004] In summary, as edge computing applications continue to expand, higher demands are placed on the coordinated optimization of data transmission and computational task processing. Ensuring efficient data transmission while simultaneously guaranteeing efficient computational task processing has become a key technical challenge in edge computing. Therefore, there is an urgent need for a technical solution that can effectively address these issues to support the coordinated optimization of efficient data transmission and computational task offloading. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention proposes an optimized method for edge data transmission and computational task offloading in fused computing network scenarios, comprising:

[0006] Step (1): Protocol identification (including multiple communication protocols such as TCP, UDP, RS232, RS485, CAN, Modbus, etc.) and preliminary processing. After receiving a data packet, the switch extracts and parses the packet header fields to determine whether the data packet belongs to a locally known protocol, and completes the identification of the data transmission destination address, source address, transmission type, and other status parameters. For example, in a multi-protocol industrial network, due to the differences in frame structure and data transmission characteristics between RS485 and CAN protocols, traditional equipment is difficult to achieve efficient compatibility in a multi-protocol environment, which can easily lead to data transmission delays or losses. Through this step, the switch can quickly identify and classify data packets, ensure accurate processing of data from each protocol, avoid conflicts between protocols, thereby improving the compatibility and data processing efficiency of multi-protocol networks, and providing a reliable communication foundation for complex network environments.

[0007] Step (2): Perform local protocol translation and conversion. For data packets with known local protocols, the switch initiates a protocol conversion mechanism to complete the translation process based on the protocol type and forwarding port information. Specific steps include: filling in necessary protocol data, reconstructing and replacing the original data packet header, and standardizing the storage of the original data packet header information. This process ensures that the switch can effectively perform conversion operations between different protocol formats in a multi-protocol environment, thereby achieving accurate data transmission in heterogeneous network environments. For example, in the interoperability scenario between TCP and LoRa protocols, the switch seamlessly completes the adaptation and interoperability between protocols through a dynamic protocol conversion mechanism, successfully solving the problem of poor protocol compatibility in heterogeneous networks and significantly improving data transmission efficiency and network throughput.

[0008] Step (3): Cloud-based assistance in handling unknown protocols. If the data packet does not conform to a locally known protocol, the switch sends a query or processing request to the cloud server, including the protocol information and transmission information of the data packet. This mechanism significantly enhances the system's compatibility and adaptability in heterogeneous protocol environments by leveraging the powerful computing capabilities and knowledge base resources of the cloud. For example, in edge computing scenarios of the Industrial Internet of Things, when sensors use non-standard protocols, the switch performs protocol translation through cloud parsing, enabling data packets to be accurately transmitted to the central control node, thereby ensuring the integrity and validity of the data flow. If the cloud fails to parse the protocol, the switch records the relevant error information and feeds it back to the knowledge base to support subsequent system optimization and protocol extension work. This method effectively solves the interoperability problem in multi-protocol environments, improving the system's dynamic adaptability and data transmission efficiency.

[0009] Step (4): Packet Tunnel Encapsulation. After receiving a data packet, the switch first parses the header fields and queries the local mapping information. Based on the network transmission protocol, the switch constructs and encapsulates a new protocol header, setting a new destination, sending address, and port to ensure that the data can be accurately transmitted to the target node. If the local mapping query fails, the switch sends a request to the cloud server, which queries the mapping library and returns control information to guide the switch to make necessary adjustments. The switch updates the mapping table based on the cloud feedback, modifies the data packet fields, and completes the final encapsulation. This process effectively supports cross-protocol data transmission, especially in dynamic network environments and under complex protocol conditions, which can improve the system's adaptability, data transmission reliability, and effectiveness. For example, when data packets are converted between the TCP protocol and the LoRa protocol, the switch can flexibly handle protocol differences, ensuring that data can be seamlessly transmitted to the target node, significantly optimizing the utilization of network resources.

[0010] The above four steps are used to align the formats of various data packets from different communication networks. The following sections will explain packet reception and processing, and mapping to the Data Plane Development Kit (DPDK) function library for subsequent high-speed forwarding.

[0011] Step (5): Packet parsing, storage, and state transition processing. The `parse_ethernet` function parses the Ethernet header, extracting the destination MAC address, source MAC address, Ethernet type, and checksum sequence. The state transition is determined based on the `etherType` field value: 0x9999 to network identifier resolution, 0x0806 to ARP, 0x0800 to IPv4, 0x86DD to IPv6, and other values ​​are accepted by default. The `parse_arp`, `parse_sinet`, `parse_ipv4`, and `parse_ipv6` functions process the corresponding protocol headers, directly receiving the packet or determining further state transitions. Specifically, `parse_arp` parses ARP packets, extracting the opcode, source / destination MAC address, and IP address, deciding whether to receive the packet directly or perform address resolution; `parse_sinet` parses SINet packets, extracting the protocol identifier and data priority, performing priority processing or standard load forwarding; `parse_ipv4` and `parse_ipv6` process IPv4 / IPv6 packets, extracting the source / destination address and protocol fields, and if fragmented, transitioning to fragment reassembly state to ensure correct packet reception and processing. For example, in a multi-protocol environment, when a device receives packets from both TCP and LoRa protocols, traditional processing methods may lead to poor protocol compatibility, transmission delays, and low efficiency. Through a parsing and state transition mechanism, the switch uses the etherType field to quickly identify the protocol type and select the most appropriate processing flow. For ARP packets, the parse_arp function determines whether address resolution is needed based on the opcode and MAC / IP address, avoiding delays; the parse_sinet function adjusts the forwarding strategy according to priority, ensuring timely processing of high-priority data; for IPv4 / IPv6 packets, if fragmentation is detected, the system jumps to the fragmentation reassembly state to ensure data integrity. This dynamically adjusted processing flow can solve protocol compatibility issues, improve data processing efficiency and network throughput, and optimize task offloading and data transmission efficiency in edge computing.

[0012] Step (6): Perform mapping lookup. Mapping lookup involves six processing strategies: ARP, SINET, IPv4, IPv6 processing, and SINET encapsulation and decapsulation. Executing these strategies according to specific parameters can effectively solve compatibility issues in multi-protocol environments. First, the ARP strategy matches the target IP address, looks up the target MAC address in the local ARP table, and fills in the source MAC and IP addresses to ensure accurate packet forwarding and avoid delays and packet loss caused by address mismatches. For the SINET protocol, the switch determines the next-hop MAC address based on the destination identifier and updates the Ethernet frame header to ensure smooth packet transmission and avoid forwarding failures caused by target address mismatches. The IPv4 / IPv6 strategy extracts the source and destination IP addresses and combines them with routing information for intelligent encapsulation, optimizing the packet transmission path and reducing delays caused by inaccurate routing. For SINET encapsulation, the switch fills in proprietary header information such as data priority to meet specific transmission requirements and optimize bandwidth utilization; during decapsulation, the protocol header is correctly removed and restored to the standard format, ensuring effective packet forwarding in multi-protocol networks. By using mapping lookup and protocol processing, data transmission efficiency can be significantly improved, ensuring seamless data transmission and processing in a multi-protocol environment, thereby effectively supporting the collaborative optimization of task offloading and data transmission in edge computing.

[0013] Step (7): The forwarding module in the switch is responsible for efficient packet reception and forwarding. Through DPDK initialization, the switch can directly access network card hardware resources, bypassing the traditional kernel network stack and significantly reducing packet processing latency. In addition, by combining CPU and thread binding technology, specific processing tasks are assigned to designated CPU cores, effectively avoiding performance overhead caused by frequent task switching between multiple cores. By optimizing EAL parameter configuration (such as cores, ports, and queues), the switch can achieve precise resource allocation, thereby improving the parallelization capability of packet processing. On this basis, the introduction of large page memory technology reduces memory allocation fragmentation and lowers the cache hit failure rate, further improving the running efficiency of the forwarding process. Through these optimization methods, the switch can achieve high throughput and low latency packet processing in a multi-protocol environment, meeting the demand for high-performance forwarding in edge computing scenarios, thereby effectively improving the collaborative efficiency of data transmission and task offloading.

[0014] Step (8): Establish an independent comprehensive model for each user and edge computing node. This model defines computing power parameters and network status parameters for each edge node based on the user's location, movement speed, computing needs, and the edge node's processing capabilities, communication latency, and service range. These parameters include CPU computing power, memory capacity, bandwidth resources, and network latency. Taking a typical smart city application scenario as an example, multiple sensors and user devices generate data in real time in the urban environment, such as traffic flow monitoring and environmental monitoring. To effectively schedule these computing tasks, it is necessary to dynamically adjust task offloading and resource allocation strategies according to changes in user location and task requirements. For example, during peak hours, the city's traffic management system needs to process a large amount of data from different sensors in real time. At this time, edge nodes must reasonably schedule computing tasks and allocate processing resources to avoid excessive latency. In this process, data quality is improved by collecting user and device geographic location information, real-time computing needs, and edge node load and network response, combined with data preprocessing techniques (such as normalization and noise reduction). Subsequently, machine learning algorithms (such as support vector machines or neural networks) are used to train and optimize the model, dynamically adjusting the task scheduling strategy and responding in real time to changes in network status and user needs. For example, when network latency is high, the model can determine to offload some computing tasks to other edge nodes with lighter loads, or reduce computing bottlenecks through a better resource allocation scheme.

[0015] Step (9): Task offloading decision. Using the improved DDPG algorithm, the algorithm comprehensively evaluates network status, user location and computing needs, as well as the load and resource status of edge nodes, to dynamically decide on the target node for task offloading. This algorithm considers the node's computing power, communication latency, and load status to generate an optimized offloading strategy, thereby effectively reducing latency and network overhead while ensuring task execution efficiency. The improved algorithm can adapt to changes in the network environment in real time, especially in scenarios with high user mobility or large fluctuations in network conditions, continuously optimizing task scheduling to ensure timely task completion. Finally, task data and configuration information are efficiently transmitted to the selected edge node to complete the computing task, promoting dynamic collaborative optimization of edge computing resources and improving overall system performance and resource utilization.

[0016] Step (10): Task Migration Decision. By continuously monitoring user movement trajectories, network status fluctuations, and edge node load, the system can automatically trigger a task migration mechanism when it detects a decline in connection quality or excessive node load. Using an improved Deep Deterministic Policy Gradient (DDPG) algorithm, the system comprehensively analyzes the computing power, current load, and communication latency of candidate edge nodes to select the optimal node for task takeover. This method effectively addresses the impact of user mobility and network condition fluctuations, avoiding delays and uneven resource allocation caused by untimely or unreasonable task migration. During the migration process, the system ensures the safe transfer of task status and data, avoids service interruptions, and ensures seamless continuation of task execution on the new node. This mechanism not only enhances the reliability of task processing but also significantly improves the utilization efficiency and overall performance of system resources, thereby ensuring the high efficiency and stability of task processing in the edge computing environment.

[0017] The technical solution of the present invention has the following advantages:

[0018] 1) Multi-protocol support and flexibility: By identifying and preliminarily processing various communication protocols (such as TCP, UDP, RS232, RS485, CAN, Modbus, etc.), this method can adapt to data packets from various communication networks, improving the system's compatibility and flexibility.

[0019] 2) Efficient protocol translation and conversion: This method ensures efficient processing and forwarding of data packets, reduces data transmission latency, and improves overall network performance through local protocol translation and conversion mechanisms and cloud-assisted handling of unknown protocols.

[0020] 3) Optimized packet encapsulation and mapping lookup: Through packet tunnel encapsulation and mapping lookup strategies, this method can effectively manage and optimize the transmission path of packets, reduce packet loss and errors during transmission, and enhance the reliability of data transmission.

[0021] 4) Improved processing performance and efficiency: By applying DPDK technology, this method bypasses the traditional kernel network stack and directly binds to the network card, significantly improving the performance and efficiency of data processing, especially in high-speed data transmission scenarios.

[0022] 5) Dynamic and flexible task offloading and migration decision-making: By adopting the improved Deep Deterministic Policy Gradient (DDPG) algorithm, this method can dynamically determine task offloading and migration based on real-time network conditions and the load of edge computing nodes, optimize computing resource allocation, reduce communication latency, and improve the speed and quality of task processing. Attached Figure Description

[0023] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below.

[0024] Figure 1 This is a flowchart of the overall solution of the present invention;

[0025] Figure 2 This is the data packet processing state transition process in step (5) of the present invention;

[0026] Figure 3 This is a schematic diagram of the task unloading and migration process in steps (8) to (10) of the present invention;

[0027] Figure 4 This is the overall algorithm flowchart of the present invention. Detailed Implementation

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

[0029] Figure 1 This is a flowchart illustrating an optimized method for edge data transmission and computing task offloading in a converged computing network scenario according to an embodiment of the present invention. Figure 2 This is a state transition diagram for heterogeneous transport protocol processing. Figure 3 This is a system architecture diagram for identifier registration and resolution.

[0030] like Figure 1 As shown, the present invention comprises 10 steps.

[0031] Step (1): The switch is equipped with a protocol identification engine. This engine automatically identifies and classifies various communication protocols, including TCP, UDP, RS232, RS485, CAN, and Modbus, by matching packet headers. Commonly used protocol information is stored locally on the switch, and a dynamically updated protocol database is established in the cloud to store the characteristics and parsing rules of various communication protocols. This database allows administrators or automated tools to add new protocol features and update existing protocol rules, ensuring that the protocol identification engine can adapt to changes in the network environment.

[0032] Step (2): The switch has a built-in protocol conversion engine. This engine can read the packet header based on the protocol type and target forwarding port information of the data packet, and identify the protocol type of the data packet based on the specific pattern of these bytes. For protocols such as TCP, UDP, RS232, RS485, CAN, and Modbus, the characteristic bytes and positions of each protocol header are defined, and appropriate conversion rules are dynamically selected. Field extraction logic is implemented according to the specifications of each protocol. For example, for TCP and UDP packets, the source port and destination port fields are extracted; for RS232 and RS485, the control signals of the data flow are extracted, etc. Necessary information, such as source address, destination address, and transport type, is extracted from the packet header using bit manipulation and byte shifting techniques. Conversion rules are written for each known protocol, specifying how to convert the packet header information of the original protocol into the target protocol format.

[0033] Step (3): Establish a protocol knowledge translation database on a cloud server. This database stores the characteristics, formats, and conversion rules of various known protocols. Regularly update the database to incorporate new protocol information and update the conversion rules of existing protocols. Develop an API interface to receive packet identification requests from the switch. This interface can handle query requests containing packet protocol information and transmission information. Implement request parsing logic to extract key information from the received request, such as packet header data and protocol type identifiers.

[0034] Based on the received data packet information, a query is performed in the protocol knowledge translation database to determine if a matching protocol conversion rule exists. If the query is successful, the corresponding protocol conversion information is extracted from the database, including the header format of the new protocol and the necessary conversion logic. Based on the query results, processing conversion information is generated. This includes the header template of the new protocol, instructions on which information needs to be extracted from the original data packet, and how to populate this information in the new header. The processing conversion information is encapsulated and sent back to the requesting switch. If an unknown protocol processing notification is received, the relevant information is recorded and the switch is informed that it cannot process the request.

[0035] Step (4): The switch parses the header fields of the received data packets to confirm the existence of local mapping rules. If they exist, the switch immediately constructs a new protocol header based on these rules, including updated destination addresses and port information, so that data packets can be efficiently forwarded according to the transport protocol. If no local mapping rules exist, the switch sends a request to the cloud server to obtain the necessary mapping information. Once the mapping instructions are received from the cloud, the switch updates its local mapping table according to these instructions and adjusts the header information of the data packets accordingly, completing the tunnel encapsulation process. This process ensures that even in the absence of local mapping information, data packets can be correctly encapsulated and forwarded to the correct destination.

[0036] Step (5): The system first extracts the Ethernet header information of the data packet by parsing the Ethernet header using the `parse_ethernet` function. Based on the value of the `etherType` field in the header, the system determines the next state: if it is 0x9999, it jumps to the identifier resolution state; if it is 0x0806, it jumps to the ARP resolution state; if it is 0x0800, it jumps to the IPv4 resolution state; if it is 0x86DD, it jumps to the IPv6 resolution state; if it is any other value, it enters the default state and directly receives the data packet. The ARP header information is processed using the `parse_arp` function, and the data packet is received directly after extraction. The header information is processed using the `parse_sinet` function, and the system determines whether to jump to the IPv4 or IPv6 resolution state, or enter the default state to receive the data packet, based on the value of the `nextheader` field. The IPv4 and IPv6 header information are processed using the `parse_ipv4` and `parse_ipv6` functions respectively, and the data packet is received directly after extraction.

[0037] Step (6): The switch automatically identifies and processes different types of data packets according to the state transition process. First, by analyzing the destination IP address of the data packet, the switch applies the ARP policy to automatically fill in the source MAC address and IP address, and sets the appropriate forwarding port. For SINET protocol data packets, the system matches the destination identifier, automatically sets the next hop of the data packet, and updates the Ethernet frame header information. When an IPv4 or IPv6 data packet is identified and corresponding mapping information exists, the switch prepares to perform intelligent encapsulation to optimize data transmission. In addition, during SINET encapsulation and decapsulation, the switch can fill in or modify the data packet header information as needed to ensure that the data packet can be correctly forwarded to the target node.

[0038] like Figure 2 As shown, after receiving a data packet, the module first parses the Ethernet frame header to extract the MAC address. Simultaneously, it selects the next migration state based on the protocol type field in the Ethernet frame. If the protocol state matches the SmartLink identifier field, it jumps to SmartLink identifier header parsing and stores the data transmission destination identifier and source identifier. As the identifier module design indicates, network transmission uses an encapsulated data packet structure; therefore, after the identifier field, it also needs to parse IPv4, IPv6, and other data packet headers. At this point, the module will continue to select the parsing state based on the next header field of the data packet.

[0039] Taking IPv4 resolution as an example, after the state transition, the module stores the source IP address and destination IP address of the data packet and continues to select the next transition state based on the protocol field in the data packet header. Depending on the protocol field, the data packet will jump to a TCP or UDP state, at which point the sending and receiving port information is stored. At this point, the data packet parsing is complete, and all data is stored for the next matching action. In addition, considering that data packet transmission in an IPv4 network requires destination IP address and MAC address resolution, the state transition diagram also includes an ARP protocol resolution state for hardware address translation.

[0040] Step (7): First, perform DPDK initialization. This process is completed through Environment Abstraction Layer (EAL) parameter parsing, including device driver registration and initialization, PCI network card information acquisition, and network card device and memory initialization. Specific steps include:

[0041] Register and initialize device drivers, storing device driver information in the device driver information table; scan PCI network cards in the system, obtain and record network card address, ID, device address space, and driver type in the network card terminal list; establish a mapping relationship between the device driver information table and the network card terminal list, and record it in the network card driver list; map PCI resources to the virtual address space, allocate resources for the device, and initialize the resources; set up transmit and receive queues according to user configuration, and request and initialize ring space;

[0042] Then, data packet transmission is performed using a polling-driven model, bypassing the Linux kernel protocol stack and directly processing data packet sending and receiving in user space. Specifically, this includes:

[0043] Packet reception: Initialize the receive descriptor, fill the physical address of the receive buffer memory block into the descriptor, and reset the receive success flag. The network card fills the received data packets into the receive buffer memory block and sets the receive success flag in the receive descriptor. The queue polling thread checks the receive success flag, stores the data packets in the function input array, and re-initializes the receive descriptor for the next packet reception.

[0044] Packet transmission: Initialize the packet descriptor, extract the packet buffer memory block information and fill it into the packet descriptor. The network card sends data packets according to the packet descriptor. The polling thread checks the packet transmission end flag, and reclaims the packet descriptor and memory buffer block after completion.

[0045] Step (8): Establish a comprehensive model for each user and edge computing node. This model is based on the user's location, mobility speed, computing needs, and the edge node's processing power, communication latency, and service range. Define computing power parameters and network status parameters for each edge node, including CPU computing power, memory capacity, bandwidth resources, and network latency. Calculate the time for users to upload and unload tasks through time analysis, considering factors such as channel gain and user equipment power. For tasks unloaded to the edge computing node, the computation time is affected by computing power and interference power. For local computing tasks, the computation time is determined by local computing power. For highly mobile users, consider task migration; the migration time is affected by channel gain and interference power.

[0046] Step (9): As Figure 4 As shown, first, a state space S is established, defining the states in the network environment, including information such as network load, user request characteristics, and server resource utilization. A state s∈S can be represented as s=(l, r u c), where l is the network load and r u Here, is the user request characteristic, and 'c' is the server resource utilization rate. Establish an action space A, defining the possible operations, i.e., the decision to unload or retain a service. An action a∈A can be represented as a={0,1}, where 0 represents retaining the service and 1 represents unloading the service.

[0047] Establish a reward function R(s, a), and design a reward function to evaluate the merits of each decision. The reward function should consider factors such as resource utilization efficiency and user satisfaction. For example, when resource utilization is high and user satisfaction is improved, the reward function can provide a positive reward. Specifically, the reward function can be expressed as:

[0048] R(s,a)=α×Utilization(c)+β×Satisfaction(r u )

[0049] Where α and β are weighting coefficients, Utilization(c) represents resource utilization rate, and Satisfaction(r) u () indicates user satisfaction.

[0050] To construct a DDPG neural network, we first establish an Actor network: define a neural network that takes the current state s as input and outputs the predicted unloading policy action a. The Actor network is then used to approximate the policy function π(s|θ). π ), where θ π These are the parameters of the Actor network. A Critic network is built, and another neural network is defined to estimate the value Q(s, a|θ) of the state-action pair. Q ), where θQ These are the parameters of the Critic network. The output of the Critic network helps the Actor network update its policy. The DDPG algorithm is trained using historical data and reward signals. The DDPG algorithm continuously updates the parameters of the Actor and Critic networks to gradually converge the policy to the optimal policy. The update formula for the DDPG algorithm is as follows:

[0051]

[0052] Among them, L Q λ is the loss function of the Critic network, J is the objective function of the Actor network, and λ is the target function of the Actor network. Q and λ π It is the learning rate.

[0053] The system performs policy prediction: when the system is in a certain state, the trained Actor network predicts the optimal unloading policy. This policy can be to unload a service or to retain the service to maximize cumulative rewards. Real-time decision-making: based on the predicted unloading policy, the system decides in real time whether to execute the unloading operation. This decision-making process can be performed periodically to adapt to changes in the network state.

[0054] Step (10): The system continuously monitors user mobility and the status of the edge network. This includes information such as user weight, connection quality, and bandwidth utilization. Monitoring can be achieved through periodic packet transmission, signal strength measurement, and network performance analysis. Simultaneously, the system monitors the load of edge nodes in real time, including metrics such as CPU utilization, memory usage, and task queue length.

[0055] In task migration decision-making, the system state can be modeled as a Markov balance process (MDP). The state s∈S can be represented as s=(p i q i b i , l j m j , t j ),in:

[0056] ·p i User u i The plane,

[0057] ·q i User u i The connection quality,

[0058] ·b i User u i Bandwidth utilization.

[0059] ·l j It is the edge node ej Load conditions (such as CPU utilization).

[0060] ·m j It is the edge node e j Memory usage.

[0061] t j It is the edge node e j The length of the task queue.

[0062] Action space A is defined as A = {a i j}, where a ij User u i Should the task be migrated to the edge node e? j Action a i j can be represented as a ij = {0, 1}, where 0 indicates no migration and 1 indicates migration to e. j .

[0063] The reward function is designed as the negative of the total cost of task migration and the task processing latency:

[0064]

[0065] Where D i It is the size of the task data, B i j is an edge node e i and e j The communication bandwidth between them, S is the task state size, f j It is the edge node e j The computing power of C 迁移 It represents the migration cost, taking into account both communication and computation delays. α, β, and γ are weighting coefficients.

[0066] In task migration decision-making, a task migration decision is triggered when one of the following occurs: the user moves to the coverage area of ​​a new edge node; the network connection quality deteriorates to a certain threshold; or the edge node load is too high, reaching a certain critical value τ.

[0067] Chengtong selects the optimal target edge node e through an improved DDPG handshake method. j This is done to minimize the total cost of task migration and the new processing latency. The migration cost is calculated as follows:

[0068]

[0069] The optimization objective is to minimize the total cost of task migration and the new processing latency:

[0070]

[0071] When performing task migration, the system should save the current task status and data to ensure safe migration. Then, the task data is transferred to the target edge node, the task is executed on the target edge node, and the task status and data transmission path are updated to ensure that users can access the migrated task.

Claims

1. An optimization method for edge data transmission and computational task offloading in a converged computing network scenario, characterized in that, Includes the following steps: (1) Protocol identification and preliminary processing: The switch identifies and processes data packets of various communication protocols and performs preliminary data packet classification; (2) Local protocol translation and conversion: Locally translate and convert data packets of known protocols, and align the data packet header information; (3) Cloud-assisted processing of unknown protocols: For data packets with unknown protocols, the switch requests cloud assistance for translation and processing; (4) Data packet tunneling: Data packets are tunneled and encapsulated to optimize the data transmission path based on the Fusion Computing Network Protocol; (5) Data packet parsing, storage and state transition processing: The function parses the data packet header information and determines the state transition of the subsequent processing flow based on the value of the etherType field; (6) Mapping lookup: Perform mapping lookup, including multi-protocol processing and encapsulation and decapsulation, and forward data packets according to the matching results; (7) Forwarding module optimization: The forwarding module is optimized through CPU binding and big page memory configuration technology to improve data processing performance; (8) Comprehensive model establishment: Establish a model for each user and edge computing node, taking into account location, movement speed and computing needs, and optimize task offloading decisions; (9) Task offloading decision: Dynamically select the best edge node for computing tasks, based on network, user status and node load optimization; (10) Task migration decision: Real-time monitoring of user mobility and network status; based on edge node load, using an improved DDPG algorithm, migrating tasks to the most suitable edge node; characterized in that the decision process uses a reward function R(s,a) to evaluate the total cost and latency of task migration, the reward function being defined as: Among them, D i It is the size of the task data, B i j is the communication bandwidth between the current node and the target node, S is the task state size, and f is the communication bandwidth between the current node and the target node. j It refers to the computing power of the target node, C. 迁移 It is the migration cost that combines communication delay and computing delay, and α, β, γ are weighting coefficients.

2. The optimization method for edge data transmission and computation task offloading in a fused computing network scenario according to claim 1, characterized in that, Step (1) includes the identification and processing of the data transmission destination / source address, data transmission type, and other status parameters.

3. The optimization method for edge data transmission and computation task offloading in a fused computing network scenario according to claim 1, characterized in that, Step (2) involves standardizing the format of each protocol field during the protocol conversion process to ensure correct data parsing and transmission.

4. The optimization method for edge data transmission and computation task offloading in a fused computing network scenario according to claim 1, characterized in that, Step (3) includes querying the protocol definition, data structure and conversion rules related to the unknown protocol, and returning the processed conversion information.

5. An edge computing resource management system, comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the method as described in claim 1.

6. The edge computing resource management system according to claim 5, characterized in that, The protocol identification module can automatically identify data packets of various communication protocols, including but not limited to TCP, UDP, RS232, RS485, CAN, and Modbus.

7. The edge computing resource management system according to claim 5, characterized in that, The protocol conversion module and the cloud-assisted processing module work together to process data packets with unknown protocols and optimize the data packet processing flow for known protocols.

8. A system for packet processing and state transition, characterized in that, The system is configured to perform the method described in steps (1) to (7) of claim 1.

9. A system for packet processing and state transition according to claim 8, characterized in that, The packet tunneling encapsulation module is based on the network transmission protocol. The switch builds and encapsulates a new protocol header and sets a new destination, sending address and port.

10. A system for packet processing and state transition according to claim 8, characterized in that, The packet parsing, storage, and state transition processing module is responsible for performing state transition processing on packets based on Ethernet header information and other protocol-specific fields.

Images