Low-delay data processing method and system in edge computing environment
By utilizing 5G networks and UPF for packet parsing and dynamic routing optimization in an edge computing environment, the latency and load balancing issues in existing edge computing architectures are resolved, achieving efficient and accurate data processing and meeting the needs of low-latency services.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-15
- Publication Date
- 2026-04-07
AI Technical Summary
Existing edge computing data processing architectures cannot dynamically adjust to real-time network conditions and changing business needs, resulting in increased data processing latency and low resource utilization. In particular, in wide-area distributed scenarios, load balancing is insufficient, making it difficult to meet the high requirements of low-latency business applications.
Data packets containing user identifiers and service data are sent through the 5G wireless access network. The user plane function UPF of 5G base stations and edge equipment rooms is used to parse data packets and extract real-time location information. An initial traffic splitting strategy is generated by combining the pre-configured DNN and the routing decision is dynamically optimized based on multi-dimensional network performance parameters to achieve accurate and efficient routing and processing of data packets.
It achieves efficient and accurate routing of data packets, reduces transmission latency and packet loss, improves the real-time performance and resource utilization of data processing, and meets the real-time data processing needs of vertical industries.
Smart Images

Figure CN121815336A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of edge computing technology, and in particular to a low-latency data processing method and system in an edge computing environment. Background Technology
[0002] With the deepening of digital and intelligent transformation in vertical industries such as energy and industrial manufacturing, extremely high demands are being placed on the real-time performance, reliability, and security of data processing in edge computing scenarios. 5G networks, with their high bandwidth and low latency characteristics, have become a key technology supporting edge computing. However, existing edge computing data processing architectures have many shortcomings, making it difficult to meet the high-requirement, low-latency business applications.
[0003] Specifically, existing technologies have the following prominent problems at the data processing level: First, traditional data offloading strategies are usually based on static configurations, such as fixed DNNs or simple user location information. Once such strategies are formulated, they cannot be dynamically adjusted according to real-time network conditions and changing business needs during data processing. When network congestion occurs or a certain edge service server is overloaded, the system cannot detect and recalculate data routes in real time, causing data packets to still be transmitted along the original rigid path, resulting in increased data processing latency or even packet loss, which may make it difficult to guarantee the service quality of critical services. Second, in scenarios with wide-area distribution characteristics, such as wind farms, existing solutions lack accurate load balancing mechanisms based on multi-dimensional information. Data processing requests may be concentrated on one or a few service servers, while other servers are idle. This is usually because the initial offloading strategy fails to fully consider real-time link load and server processing capacity, relying only on simple round-robin or hash algorithms, leading to the generation of data processing hotspots and reducing the throughput efficiency and resource utilization of the entire edge computing system. Summary of the Invention
[0004] The technical problem to be solved by the present invention is to provide a low-latency data processing method and system in an edge computing environment. It constructs an end-to-end low-latency data pipeline from the terminal to the edge server. By combining identity, location, initial service diversion and dynamic optimization based on real-time network status, it achieves accurate and efficient routing and processing of data at the edge.
[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows: Firstly, a low-latency data processing method in an edge computing environment, the method comprising: The terminal device sends data packets containing user identifiers and service data through the 5G wireless access network; After receiving the data packet, the 5G base station forwards the data packet to the User Plane Function (UPF) deployed in the edge data room through the transmission network; The User Plane Function (UPF) parses the received data packets and extracts the user identifier and real-time location information; based on the user identifier, real-time location information, and pre-configured Dedicated Data Network Name (DNN), it generates an initial traffic splitting strategy. In response to the initial traffic splitting strategy, network performance parameters, including packet processing latency, link load rate, and signal quality indicators, are collected in real time; a multi-dimensional evaluation matrix is constructed based on the network performance parameters; the multi-dimensional evaluation matrix is input into a pre-trained dynamic evaluation model for analysis to obtain strategy optimization parameters; The initial traffic splitting strategy is dynamically optimized using strategy optimization parameters to obtain the optimized traffic splitting strategy; based on the optimized traffic splitting strategy, uplink traffic classification (UL CL) processing and data identification are performed on data packets to obtain the final routing decision; Based on the final routing decision, the classified and identified data packets are routed to the corresponding business servers through the local network; The service server receives data packets routed to the local machine, performs application-layer business processing, and completes low-latency data responses.
[0006] Secondly, a low-latency data processing system in an edge computing environment includes: The terminal access module is used by terminal devices to send data packets containing user identifiers and service data through the 5G wireless access network. The base station transmission module is used to forward the data packet to the user plane function UPF deployed in the edge equipment room through the transmission network after the 5G base station receives the data packet; The policy generation module is used by the User Plane Function (UPF) to parse the received data packets, extract the user identifier and real-time location information, and generate an initial traffic splitting policy based on the user identifier, real-time location information, and a pre-configured Dedicated Data Network Name (DNN). The optimization module is used to respond to the initial traffic splitting strategy by collecting network performance parameters in real time, including packet processing latency, link load rate, and signal quality indicators; constructing a multi-dimensional evaluation matrix based on the network performance parameters; and inputting the multi-dimensional evaluation matrix into a pre-trained dynamic evaluation model for analysis to obtain strategy optimization parameters. The routing decision module is used to dynamically optimize the initial traffic splitting strategy using policy optimization parameters to obtain the optimized traffic splitting strategy; based on the optimized traffic splitting strategy, it performs uplink traffic classification (UL CL) processing and data identification on data packets to obtain the final routing decision; The data routing module is used to route classified and identified data packets to the corresponding business servers through the local network based on the final routing decision. The business processing module is used by the business server to receive data packets routed to the local machine, perform application layer business processing, and complete low-latency data response.
[0007] Thirdly, a computing device includes: One or more processors; A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.
[0008] Fourthly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.
[0009] The above-described solution of the present invention has at least the following beneficial effects: Terminal devices transmit data packets containing user identifiers and service data through the 5G wireless access network. Leveraging the high bandwidth and low latency of the 5G network, data transmission efficiency and stability are ensured. After receiving the data packets, the 5G base station forwards them to the edge data center's UPF via the transmission network. The edge-deployed UPF shortens the data packet transmission path, reducing latency losses from cross-regional transmission. The UPF parses the data packets to extract user identifiers and real-time location information, and combines this with a pre-configured DNN to generate an initial traffic splitting strategy. This initial strategy fully adapts to user identity, real-time location, and service type, achieving traffic splitting guidance based on identity, location, and service. Real-time collection of multi-dimensional network performance parameters, such as data packet processing latency, link load rate, and signal quality indicators, comprehensively and accurately reflects the current network transmission status, avoiding the bias caused by single-parameter evaluation. The initial traffic splitting strategy is dynamically adjusted using strategy optimization parameters, allowing the strategy to flexibly adapt to changes in network status. Uplink traffic classification (UL) is also implemented. The combination of CL processing and data recognition ensures that routing decisions follow optimized policy guidelines while accurately matching the business attributes of individual data packets. Based on the final routing decision, data packets are routed to the corresponding business servers via the local network. Short-path transmission on the local network further reduces data forwarding time and minimizes latency and losses caused by intermediate nodes. After receiving the data packets, the business servers perform application-layer business processing and complete low-latency responses. Application-layer processing can directly execute corresponding logic based on the business type of the data packets, resulting in highly targeted and efficient processing. The response process is efficiently integrated with the preceding data transmission and routing stages, without redundant steps. Combined with the advantages of local network backhaul, it ensures that business requests receive rapid feedback, fully meeting the core real-time data processing requirements of vertical industries. Attached Figure Description
[0010] Figure 1This is a flowchart illustrating a low-latency data processing method in an edge computing environment, provided by an embodiment of the present invention.
[0011] Figure 2 This is a schematic diagram of a low-latency data processing system in an edge computing environment provided by an embodiment of the present invention. Detailed Implementation
[0012] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
[0013] like Figure 1 As shown, embodiments of the present invention propose a low-latency data processing method in an edge computing environment, the method comprising the following steps: Step 100: The terminal device sends a data packet containing the user identifier and service data through the 5G wireless access network; Step 200: After receiving the data packet, the 5G base station forwards the data packet to the User Plane Function (UPF) deployed in the edge data room through the transmission network; Step 300: The User Plane Function (UPF) parses the received data packets and extracts the user identifier and real-time location information; and generates an initial traffic splitting strategy based on the user identifier, real-time location information, and pre-configured Dedicated Data Network Name (DNN). Step 400: In response to the initial traffic splitting strategy, network performance parameters, including packet processing latency, link load rate, and signal quality indicators, are collected in real time; a multi-dimensional evaluation matrix is constructed based on the network performance parameters; the multi-dimensional evaluation matrix is input into a pre-trained dynamic evaluation model for analysis to obtain strategy optimization parameters; Step 500: Dynamically optimize the initial traffic splitting strategy using strategy optimization parameters to obtain the optimized traffic splitting strategy; perform uplink traffic classification UL CL processing and data identification on data packets based on the optimized traffic splitting strategy to obtain the final routing decision; Step 600: Based on the final routing decision, the classified and identified data packets are routed to the corresponding business servers through the local network; Step 700: The service server receives the data packets routed to the local machine, performs application layer service processing, and completes a low-latency data response.
[0014] In this embodiment of the invention, relying on the high bandwidth and large connectivity characteristics of 5G technology, efficient connection between the terminal and the network is achieved, and user identification and service data are transmitted quickly, providing complete basic data for subsequent data processing. By forwarding data to the edge data center UPF via the transmission network, the data transmission path is shortened, latency loss during transmission is reduced, and data packet transmission efficiency is improved. Key information is parsed and extracted, and combined with a pre-configured DNN to generate an initial strategy, achieving accurate matching between the traffic splitting strategy and user and service scenarios, enhancing the targeting of traffic splitting decisions. Multi-dimensional collection of network performance parameters constructs an evaluation matrix, comprehensively capturing network operating status. Model analysis is used to mine data correlation value, providing comprehensive data support for strategy optimization. The traffic splitting strategy is dynamically optimized to adapt to network changes, and uplink traffic classification and data identification improve the accuracy of data processing, ensuring that routing decisions meet real-time business needs. Local network routing reduces cross-network transmission links, reduces data transmission loss and latency, and ensures that classified data is quickly delivered to the target service server. The service server processes the locally routed data specifically, combining prior low-latency transmission and accurate routing to quickly complete application layer business processing, improving data response efficiency.
[0015] In a preferred embodiment of the present invention, step 100 above, in which the terminal device sends a data packet containing a user identifier and service data through a 5G wireless access network, includes: Step 101 involves encapsulating the user identifier and business data using a protocol to generate a raw data frame to be transmitted. Specifically, this includes: First, the terminal device preprocesses the acquired user identifier and business data. The user identifier may include identification information such as the terminal's IMSI and MSISDN, while the business data may include business-related data such as wind turbine operating parameters in a wind farm and environmental data collected by sensors. Next, the terminal device determines the field structure of the protocol data unit according to a preset encapsulation protocol adapted to the reliability requirements of data transmission in edge computing scenarios, such as TCP / IP or industry-specific data transmission protocols. This structure must include an identity field and a business load field. Subsequently, the terminal device fills the preprocessed user identifier into the identity field according to the format specified in the protocol, and fills the business data into the business load field after classifying it according to attributes such as data type and collection time. Finally, the terminal device performs integrity verification calculations on the protocol data units after the fields are filled, for example, by calculating checksums or cyclic redundancy check values, to confirm that the user identifier and business data have not been lost or misaligned during the field filling process, thereby generating a structurally complete and accurately correlated raw data frame to be transmitted.
[0016] Step 102 involves adding the protocol headers required by the 5G wireless access network to the original data frame to be transmitted, forming a data packet conforming to the 5G air interface transmission standard, and sending it through the physical channel of the 5G wireless access network. Specifically, this includes: First, the terminal device, based on the protocol stack specifications of the 5G wireless access network, such as the 5G NR protocol stack defined by 3GPP, determines the protocol header levels to be added and the field composition of each layer's protocol header. The protocol headers at least include the PDCP layer protocol header, the RLC layer protocol header, and the MAC layer protocol header. Next, the terminal device performs PDCP layer processing on the original data frame, according to the PDCP layer protocol... The protocol header is added according to the specified field format. This header must carry information such as sequence number and encryption identifier. The sequence number is used for subsequent data reassembly, and the encryption identifier is adapted to data security requirements. After that, the terminal device performs RLC layer processing on the data after adding the PDCP layer protocol header. Based on the transmission unit size of the 5G air interface physical channel, the length of the data block composed of the original data frame and the PDCP layer protocol header is calculated, and based on this length, it is determined whether segmentation is required. If segmentation is required, fields such as segmentation identifier and segmentation sequence number are added to the RLC layer protocol header. If segmentation is not required, a complete data identifier field is added.
[0017] Next, the terminal device processes the data processed by the RLC layer using the MAC layer. Combining the scheduling information issued by the 5G base station, it adds fields such as resource allocation identifier (to indicate the physical channel resource location) and priority identifier (to adapt to the real-time requirements of service data, such as the priority of equipment control data in wind farms being higher than that of ordinary monitoring data) to the MAC layer protocol header. Finally, the terminal device integrates the protocol headers of each layer with the original data frame to form a data packet that conforms to the 5G air interface transmission standard, and sends it through the physical channel of the 5G wireless access network, such as the uplink shared channel PUSCH. This process ensures that the data packet can be correctly identified and parsed by the 5G base station, while adapting to the high bandwidth and low latency transmission characteristics of the 5G network, providing a guarantee for the efficient forwarding of subsequent data packets to the edge UPF.
[0018] In this embodiment of the invention, the user identifier and business data are integrated into the original data frame through protocol encapsulation, which enables the orderly association of the two key pieces of information, ensures the integrity of the data in subsequent transmission and processing, avoids the loss of processing efficiency caused by information dispersion, and lays the foundation for the rapid extraction of core information in subsequent stages. A protocol header conforming to the 5G air interface transmission standard is added to the original data frame, so that the data packet meets the transmission specifications of the 5G wireless access network, ensures that the data packet can be transmitted stably in the 5G physical channel, reduces transmission errors caused by protocol mismatch, and adapts to the transmission characteristics of the 5G air interface, improving the adaptability and reliability of data transmission.
[0019] In a preferred embodiment of the present invention, step 200, after the 5G base station receives the data packet, forwards the data packet to the User Plane Function (UPF) deployed in the edge data room through the transmission network, includes: Step 201: The RF unit of the 5G base station receives the data packet through the 5G air interface physical channel and performs signal demodulation and baseband processing to obtain a baseband-processed data packet. Specifically, this includes: First, the RF unit of the 5G base station determines the receiving frequency band, time slot resources, and modulation method matching the terminal device according to the air interface physical channel parameters specified in the 5G NR protocol, and then receives the wireless data packet sent by the terminal through a preset physical channel (such as the uplink shared channel PUSCH); Next, the RF unit performs signal demodulation processing on the received wireless data packet, converting the high-frequency RF signal into an intermediate frequency signal and a baseband analog signal in sequence, and then converting the baseband analog signal into a digital signal through analog-to-digital conversion, completing the format conversion from wireless signal to digital data; Subsequently, baseband processing is performed on the converted digital signal, including signal filtering to remove noise interference introduced during transmission, signal equalization to compensate for fading distortion of the air interface channel, and data block synchronization to ensure the continuity of the data sequence. Through the above series of processing, the distorted and noisy digital signal is optimized into a well-structured and accurate digital data packet, thus obtaining a baseband-processed data packet.
[0020] Step 202 involves parsing the baseband-processed data packets to verify their integrity and extracting the protocol headers from each layer of the 5G air interface protocol stack to obtain the core data frame. Specifically, this includes: First, based on the baseband-processed data packets, protocol parsing is performed according to the hierarchical structure of the 5G air interface protocol stack, which is from bottom to top: MAC layer, RLC layer, and PDCP layer. The MAC layer protocol header is parsed first to obtain air interface transmission-related information such as resource allocation identifiers and priority identifiers. Then, the RLC layer protocol header is parsed to confirm the data segmentation status or complete data identifier. Finally, the PDCP layer protocol header is parsed to extract information such as sequence number and encryption identifier. Next, to verify whether there is information loss or misalignment of the data packets during air interface transmission and baseband processing. Or it may be tampered with. Based on the integrity verification information carried in the PDCP layer protocol header, such as the Cyclic Redundancy Check (CRC) value or checksum, the integrity verification calculation is performed on the baseband-processed data packet. If the verification result is consistent with the preset value, the data packet is determined to be complete and valid. If the verification fails, a retransmission mechanism is triggered to obtain the complete data packet. Subsequently, based on the confirmation that the data packet is complete and valid, the protocol headers of each layer are stripped in sequence according to the protocol stack level, that is, the MAC layer protocol header is stripped first, then the RLC layer protocol header is stripped, and finally the PDCP layer protocol header is stripped to remove redundant information that is only applicable to 5G air interface transmission, thereby obtaining the core data frame containing user identifiers and service data. Among them, user identifiers are such as IMSI and MSISDN, and service data are such as wind turbine operating parameters and sensor data collected in wind farms.
[0021] Step 203: The core data frame is carried over the transmission network, encapsulated into a data packet format suitable for transmission over fiber optic or IP networks, and forwarded to the User Plane Function (UPF). Specifically, this includes: First, for the core data frame, determining the corresponding encapsulation protocol specification based on the medium type of the transmission network. The medium type of the transmission network is either fiber optic or IP. If the transmission network is fiber optic, SDH or WDM protocols are used; if it is IP, the Ethernet protocol is used. Next, according to the selected encapsulation protocol, adding the necessary transport layer headers to the core data frame. For example, in an IP network scenario, an IP header is first added to include the source IP address (5G base station transmission port IP) and the destination IP address (edge machine IP). The 5G base station first extracts the IP address of the edge UPF (User Plane Functional Utility) and routing control information. Then, based on the real-time requirements of the business data, TCP or UDP protocol headers are added to achieve reliable data transmission control or low-latency transmission. Subsequently, the encapsulated data packet undergoes a transmission network compatibility check to ensure that the protocol header fields are complete and the format conforms to the transmission specifications, avoiding transmission interruptions due to format incompatibility. Finally, the transmission interface unit of the 5G base station sends the encapsulated data packet to the routing node of the transmission network according to the preset routing strategy. The routing node determines the forwarding path based on the destination IP address (the IP address of the edge UPF) and forwards the data packet layer by layer through the fiber optic link or IP routing node of the transmission network, finally delivering the data packet to the user plane functional Utility UPF deployed in the edge data room.
[0022] In this embodiment of the invention, after receiving data packets through the 5G air interface physical channel, the 5G base station radio frequency unit performs signal demodulation and baseband processing, which can accurately restore the wireless signal transmitted over the air interface into digital data packets, ensuring that no information distortion or loss occurs during the conversion from wireless signal to digital signal. Protocol parsing of the baseband-processed data packets can accurately identify the structure and content of each layer of the protocol in the data packet. Integrity verification can promptly check whether the data packets are damaged or missing during air interface transmission or baseband processing, ensuring the validity of the data entering subsequent stages. Stripping the protocol headers of each layer in the 5G air interface protocol stack removes redundant information applicable only to air interface transmission, extracting the core data frame containing user identification and service data, clearing obstacles for efficient forwarding in the subsequent transmission network and reducing the occupation of transmission resources by invalid data. Encapsulating the core data frame through the transmission network into a format suitable for fiber optic or IP network transmission enables the core data frame to accurately adapt to the medium characteristics and protocol specifications of the transmission network, avoiding transmission interruptions or delays caused by format incompatibility.
[0023] In a preferred embodiment of the present invention, step 300 above, in which the User Plane Function (UPF) parses the received data packets and extracts the user identifier and real-time location information therein; and generates an initial traffic splitting strategy based on the user identifier, real-time location information, and a pre-configured Dedicated Data Network Name (DNN), includes: Step 301 involves decapsulating the data packets received from the transmission network using the GTP-U tunnel protocol to recover the user plane protocol data units. Specifically, this includes: First, the UPF receives data packets forwarded by the transmission network. These packets carry GTP-U tunnel encapsulation information, which is the standard format for 5G core network user plane data transmission. The GTP-U protocol identifier field in the packet header must be identified to confirm that the data packet is user plane data carried by a GTP-U tunnel. Next, according to the GTP-U protocol specification defined by 3GPP, key fields in the tunnel header are parsed, including the Tunnel Endpoint Identifier (TEID) and Protocol Type Identifier. The TEID is used to locate the corresponding data transmission tunnel, and the Protocol Type Identifier is used to confirm the data type carried within the tunnel. Subsequently, based on the parsed tunnel header information, the GTP-U tunnel encapsulation layer is stripped, redundant fields used only for tunnel transmission are removed, and the original data carried within the tunnel is restored to a protocol data unit conforming to the user plane data transmission specification, i.e., the user plane protocol data unit.
[0024] Step 302 involves parsing the protocol header of the user plane protocol data unit and extracting the user identification information contained therein. Simultaneously, the Tracking Area Code (TAI) is extracted from the user plane data packet header of the N3 interface as real-time location information. Specifically, this includes: First, based on the user plane protocol data unit recovered in step 301, its protocol header is parsed according to the protocol type corresponding to the data unit. For example, in the IPv4 / IPv6 protocol, user identity-related information is located in the session association field of the protocol header. For instance, user identification information such as the International Mobile Subscriber Identity (IMSI) and the Mobile Service Digital Network Number (MSISDN) are extracted from the context association field of the PDU session to ensure that the extracted user identification uniquely corresponds to the specific terminal and its associated service entity. Second, since the N3 interface is the user plane data transmission interface between the 5G base station and the UPF, its data packet header carries network location-related identifiers. Therefore, the Tracking Area Code (TAI) is further extracted from the location information field of the user plane data packet header received from the N3 interface. This TAI consists of the Mobile Country Code (MCC), the Mobile Network Code (MNC), and the Tracking Area Code (TAI), which accurately reflects the network tracking area where the terminal is currently located and is used as real-time location information.
[0025] Step 303: Based on the real-time location information and the topological relationship of the pre-configured service area, an attribution determination is made to obtain the user's target service area identifier. Specifically, this includes: First, the UPF pre-stores the topological relationship data of the service areas. This data includes the TAI list, geographical coverage, and associated edge service server clusters for each service area. The topological relationship data is customized according to the actual deployment scenario, such as the wind turbine distribution area of a wind farm or the substation control area. Next, the real-time location information (TAI) is compared with the pre-configured TAI list of each service area one by one to determine whether the TAI is included in the TAI list of a certain service area. If the real-time TAI belongs to the TAI list of a certain service area, it is further confirmed whether the geographical coverage of the service area matches the actual location of the terminal (the geographical area mapped by the TAI) to avoid misjudgment caused by TAI cross-coverage. Finally, if the above comparison and confirmation are successful, the unique identifier of the service area is determined as the user's target service area identifier. The unique identifier of the service area includes, for example, the area code and name.
[0026] Step 304 involves matching and calculating the user identifier, target service area identifier, and pre-configured dedicated data network name (DNN) to obtain a policy mapping relationship. Specifically, this includes: First, pre-configuring the dedicated data network name (DNN). This involves: 1) Conducting a vertical industry business scenario analysis, targeting core businesses in industries such as energy and industrial manufacturing, such as wind turbine equipment control, environmental data monitoring, historical operation data statistics, and fault alarm reporting in wind power plants, classifying them according to real-time requirements, data transmission bandwidth requirements, and security isolation levels. 2) Assigning a unique dedicated data network name (DNN) to each type of business to ensure different business types correspond to different DNNs, avoiding data transmission conflicts. For example, assigning the wind turbine equipment control business the DNN "windpower-control," the environmental data monitoring business the DNN "windpower-monitor," and the historical operation data statistics business the DNN "windpower-monitor." The business-assigned DNN is windpower-statistics. Subsequently, each DNN is bound to the core resource information of its corresponding business, including the server cluster type supporting the business, data transmission protocol specifications, and security encryption policies. Specifically, server cluster types are configured such as low-latency server clusters for control DNNs and high-storage server clusters for statistical DNNs. Data transmission protocol specifications are configured such as UDP for control DNNs to ensure low latency and TCP for statistical DNNs to ensure reliability. Security encryption policies are configured such as end-to-end encryption for control DNNs and transport layer encryption for monitoring DNNs. Finally, the DNN names, corresponding business types, bound resource information, and security policies are compiled into a standardized DNN configuration table. After review by industry technical experts and verification through actual business scenario testing, this table is imported into the UPF local storage module to complete the pre-configuration of the DNNs, providing a business association foundation for subsequent policy matching.
[0027] Next, the UPF has a pre-stored policy matching rule base, which is built based on the business needs of vertical industries. This rule base includes association rules such as business permissions corresponding to user identifiers, available server clusters corresponding to target service area identifiers, and business types corresponding to pre-configured dedicated data network names (DNNs). For example, in a wind farm, a specific user identifier (wind turbine control terminal) corresponds to wind turbine operation data processing permissions, the pre-configured `windpower-control` corresponds to wind power equipment control services, and the pre-configured `windpower-monitor` corresponds to environmental data monitoring services. Then, the user identifier extracted in step 302, the target service area identifier obtained in step 303, and the pre-configured dedicated data network name (DNN) are matched in a three-dimensional collaborative manner. First, the range of business types that the user can access is filtered based on the user identifier, such as wind turbine control. Terminals can only access device control services. The system then filters server clusters within the target service area that support these services, such as low-latency server clusters in the wind turbine area. Finally, a Data Node (DNN) determines the specific data transmission path rules, such as the direct transmission path from windpower-control to the core control server. During the matching process, if multiple potential matching results appear, such as two server clusters supporting control services matching the same user in the same area, a second filtering is performed based on pre-configured priority rules (such as service response efficiency priority and server load priority) to ensure the matching result is unique and suited to the current business requirements. Ultimately, the correspondence between the matched user identifier, target service area identifier, DNN, accessible server clusters, and transmission rules is determined as a policy mapping relationship.
[0028] Step 305: Based on the policy mapping relationship, generate an initial traffic distribution policy containing the target service server address and priority weights. Specifically, this includes: First, extracting specific service server information within the accessible server cluster from the policy mapping relationship, including the IP address and port number of each server. Combining this with the network routing rules corresponding to the target service area identifier, selecting the server most suitable for the current user's service as the target service server. For example, in a wind farm, data from the wind turbine control terminal is preferentially routed to edge service servers near the booster station to reduce transmission latency. Second, determining the priority weights based on the type of service data. For example, real-time control data from wind turbines (such as speed regulation commands) has a high priority weight. The historical operation data statistics of wind turbines are given a medium priority weight, while the general environmental monitoring data is given a low priority weight. The priority weight setting should refer to the business importance level of the vertical industry to ensure that critical business data is processed first. Then, the IP address and port number of the target business server are associated and integrated with the corresponding priority weight, and the basic rules for data transmission are supplemented, such as the transmission protocol type (TCP / UDP) and data fragment size threshold. Finally, the integrated information is encapsulated according to the preset strategy format to form a complete initial traffic distribution strategy. This strategy must clearly define the target address and processing priority of the data routing to ensure that subsequent data transmission and processing can be directly executed according to this strategy.
[0029] In this embodiment of the invention, by decapsulating the data packets received by the transmission network using the GTP-U tunnel protocol, redundant information in the tunnel encapsulation layer can be accurately removed, and the user plane protocol data unit can be completely recovered. By parsing the protocol header of the user plane protocol data unit to extract user identification information, it is possible to directly associate it with a specific user and the corresponding service affiliation. At the same time, the tracking area code (TAI) is extracted from the header of the N3 interface data packet as real-time location information, which can obtain the user's current network location association data in real time. Based on the real-time location information and the topological relationship of the pre-configured service area, the affiliation judgment can be performed, which can combine the topological attributes such as the geographical coverage and network resource distribution of the service area to define the target service area to which the user currently belongs and generate an identifier. By matching and calculating the user identifier, the target service area identifier, and the pre-configured dedicated data network name (DNN), it is possible to achieve the association and integration of multi-dimensional information and build a precise policy mapping relationship between users, areas, and service networks. Based on the policy mapping relationship, an initial traffic splitting policy containing the target service server address and priority weight is generated, which can clarify the specific direction of data routing, and at the same time, the processing priority of different service data can be distinguished by priority weight.
[0030] In a preferred embodiment of the present invention, step 400, in response to the initial traffic splitting strategy, involves real-time acquisition of network performance parameters, including packet processing latency, link load rate, and signal quality indicators; constructing a multi-dimensional evaluation matrix based on the network performance parameters; and inputting the multi-dimensional evaluation matrix into a pre-trained dynamic evaluation model for analysis to obtain strategy optimization parameters, including: Step 401: Based on the critical path determined by the initial traffic splitting strategy, timestamp the data packet at the ingress and egress nodes of the User Plane Function (UPF). The data packet processing delay is obtained by calculating the timestamp difference. Specifically, this includes: First, based on the initial traffic splitting strategy generated in step 305, determining the critical data transmission path pointed to by the strategy. This path covers the core processing nodes within the UPF from data packet reception to forwarding. A timestamp recording module needs to be deployed on the UPF's data packet reception and forwarding interfaces, respectively. The reception interface is the ingress node, and the forwarding interface is the egress node. This module is synchronized with the UPF's system clock to ensure the consistency of time recording. Next, when the data packet arrives at the UPF ingress node via the transmission network, the timestamp recording module automatically adds a first timestamp to the data packet. This timestamp contains... The system displays year, month, day, hour, minute, second, and millisecond-level time information, along with a unique identifier for the data packet, such as the user identifier and business data ID extracted earlier. Subsequently, when the data packet completes the protocol parsing and session association processes within the UPF and arrives at the exit node, the timestamp recording module adds a second timestamp to the data packet, which also contains complete time information and a unique identifier. Then, through the time difference calculation module within the UPF, the first and second timestamps of the same data packet are called, and the value of the second timestamp is subtracted from the value of the first timestamp to obtain the processing time of the data packet within the UPF, i.e., the data packet processing latency. During this process, the consistency of the unique identifier of the data packet must be checked synchronously to ensure that the two timestamps used to calculate the difference correspond to the same data packet, avoiding latency calculation errors due to data misalignment.
[0031] Step 402: Based on the path status reflected by the data packet processing delay, trigger the traffic statistics device of the transmission network node to collect its throughput and port capacity data within a set sampling period. Calculate the link load rate by the ratio of throughput to port capacity. Specifically, this includes: First, the UPF pre-stores a path status judgment threshold, which is set based on the requirements of low-latency services in edge computing scenarios. For example, the processing delay threshold for wind turbine control data in a wind farm is set to 50ms. Compare the data packet processing delay calculated in step 401 with this threshold. If the delay is less than the threshold, the path status is determined to be good; if the delay is greater than or equal to the threshold, the path is determined to have a congestion risk, and further link load data needs to be collected. Then, when a path is determined to have a congestion risk, the UPF sends a signal to the transmission network nodes involved in the path. The transmission network node sends a traffic statistics trigger command. For transmission network nodes such as fiber optic routing nodes and IP switching nodes, this command includes a set sampling period, such as 100ms, which can be adjusted according to the real-time requirements of the service. Subsequently, after receiving the trigger command, the traffic statistics unit of the transmission network node counts the total number of data packets passing through the node in real time within the sampling period. Combined with the average size of the data packets, it calculates the total data transmission volume within the sampling period, i.e., throughput. At the same time, it reads the hardware configuration parameters of the node's port to determine the maximum data transmission capacity of the port, i.e., port capacity, such as 10Gbps. Then, through the calculation module built into the traffic statistics unit, it calculates the ratio of the throughput within the sampling period as the numerator and the port capacity as the denominator. The result is presented in percentage form, which is the link load rate.
[0032] Step 403: Based on the network congestion status indicated by the link load rate, activate the radio frequency measurement unit of the 5G base station to obtain the original measured values of the reference signal received power (RSRP) and signal-to-noise ratio (SINR). Through weighted calculation, obtain the signal quality indicators, specifically including: First, based on the link load rate, the UPF pre-stores a congestion judgment threshold. If the link load rate exceeds 70%, it is determined that there is a congestion tendency. Compare the current link load rate with this threshold. If the load rate is lower than the threshold, it is determined that the network has no obvious congestion, and there is no need to activate radio frequency measurement. If the load rate is higher than or equal to the threshold, it is determined that the network has a congestion tendency, and the signal quality of the wireless transmission link needs to be further evaluated. At this time, the UPF sends a radio frequency measurement activation command to the corresponding 5G base station. This command contains the terminal identifier to be measured (based on the user identifier association extracted above). Then, after receiving the activation command, the radio frequency measurement unit of the 5G base station aligns with the associated terminal... Within the wireless coverage area where the terminal is located, raw measurements of the Reference Signal Received Power (RSRP) and Signal-to-Noise Ratio (SINR) are continuously collected within a set measurement period (e.g., 50ms). RSRP reflects the strength of the base station signal received by the terminal, and SINR reflects the ratio of signal to interference. Subsequently, weighting coefficients are set for RSRP and SINR according to the priority requirements of edge computing services. For example, wind turbine control services in wind farms are more sensitive to signal strength, so the RSRP weighting coefficient is set to 0.4 and the SINR weighting coefficient is set to 0.6. For ordinary environmental monitoring services, the weighting coefficients are adjusted to RSRP 0.3 and SINR 0.7. These weighting coefficients can be preset according to industry scenarios. After that, the collected raw RSRP value is multiplied by the corresponding weighting coefficient to obtain the RSRP weighted value. Similarly, the SINR weighted value is calculated. The two weighted values are added together to obtain the signal quality index.
[0033] Step 404 involves aggregating packet processing latency, link load rate, and signal quality indicators to form network performance parameters. Specifically, this includes: First, deploying a performance parameter aggregation module within the UPF. This module establishes a data interaction channel with the timestamp calculation unit in step 401, the traffic statistics unit in step 402, and the radio frequency measurement unit in step 403, ensuring that parameters of each dimension can be transmitted to the aggregation module in real time. Next, the aggregation module aligns the parameters according to a time sequence, using a set acquisition period as the time unit. For example, if the acquisition period is 100ms, consistent with the sampling period in step 402, the packet processing latency, link load rate, and signal quality indicators collected within the same period are associated as a set of data. Then, a time stamp and data source identifier are added to each set of data. The time stamp corresponds to the start time of the acquisition period, and the data source identifier corresponds to the node where the parameter was acquired, such as the UPF ingress and egress nodes, transmission node A, and base station B, ensuring that the network location corresponding to the parameter can be traced later. Finally, multiple sets of associated data are integrated into structured data in chronological order. This data constitutes the network performance parameters covering the three dimensions of time, load, and signal.
[0034] Step 405: Perform standardization transformation on the network performance parameters, mapping packet processing latency, link load rate, and signal quality indicators to a unified numerical space to generate standardized parameter vectors. Specifically, this includes: First, analyzing the original dimensions and numerical ranges of each network performance indicator. The dimension of packet processing latency is milliseconds (ms), with a typical range of 10ms to 200ms; the dimension of link load rate is percentage (%), with a range of 0% to 100%; and the dimension of signal quality indicators is decibels (dB), with a typical range of -120dB to -50dB. Since the dimensions and ranges of each indicator differ significantly, standardization transformation is needed to eliminate magnitude interference. Next, using the Min-Max standardization method, the maximum and minimum thresholds for each indicator in an edge computing scenario are preset. For example, the maximum threshold for packet processing latency is set to 200ms and the minimum threshold to 10ms; the maximum threshold for link load rate is set to 100% and the minimum threshold to 0%; and the maximum threshold for signal quality index is set to -50dB and the minimum threshold to -120dB. Then, each index in each group of network performance parameters is standardized. Taking packet processing latency as an example, the actual value of the index is subtracted from the minimum threshold, and then divided by the difference between the maximum and minimum thresholds to obtain the standardized value of the index. Similarly, the standardization calculations for link load rate and signal quality index are completed, so that the standardized values of the three indices are mapped to a unified numerical space of 0 to 1. Finally, the three standardized indices within the same collection period are arranged in a fixed order: packet processing latency, link load rate, and signal quality index, forming a one-dimensional standardized parameter vector.
[0035] Step 406 involves constructing a multi-dimensional evaluation matrix containing latency, load, and signal strength based on the standardized parameter vector. Specifically, this includes: First, determining the dimensional structure of the multi-dimensional evaluation matrix, where rows correspond to different sampling periods, and each row represents the network performance status at a given time point; columns correspond to three standardized metrics: standardized packet processing latency, standardized link load rate, and standardized signal quality metrics. The number of columns is fixed at 3, and the number of rows is determined according to a preset matrix construction duration (e.g., 5 seconds, corresponding to 50 100ms sampling periods); then, extracting parameters from the standardized parameter vector generated in step 405 within the specified construction duration in chronological order. All vectors are processed, for example, the standardized parameter vectors of 50 consecutive sampling periods are extracted. Then, each standardized parameter vector is used as a row in a matrix and filled into the matrix in chronological order. The first element of the vector corresponds to the first column of the matrix (delay), the second element corresponds to the second column (load), and the third element corresponds to the third column (signal), ensuring that the position of each element in the matrix accurately corresponds to the indicator type and time node. Finally, the completed matrix is checked for integrity to see if there are any missing elements or misplaced vectors. If so, the parameters of the corresponding time nodes are collected or the vector order is adjusted to ensure that the matrix data is complete and the structure is well-organized.
[0036] Step 407: Process the multi-dimensional evaluation matrix using a pre-trained dynamic evaluation model to obtain policy optimization parameters; wherein, the processing includes: the pre-trained dynamic evaluation model comprises an input layer, a feature extraction layer, a multilayer perceptron network, and an output layer connected in sequence; the input layer receives the multi-dimensional evaluation matrix; the feature extraction layer performs feature parsing on the matrix to obtain feature vectors containing latency, load, and signal quality indicators; the feature vectors are input into the multilayer perceptron network, and nonlinear transformation and feature recombination are performed through hidden layers to obtain the network state and the adaptation value of the splitting policy; the output layer performs feature parsing on the network state and the splitting policy. The adaptation evaluation value of the flow strategy is processed by parameter mapping to generate strategy optimization parameters. Specifically, this includes: First, when building a pre-trained dynamic evaluation model, the construction of the training sample set and the design of the model structure must be completed. The construction of the training sample set requires collecting a large amount of network performance data and corresponding flow splitting strategy adaptation cases in edge computing scenarios, covering wide-area distributed scenarios such as wind farms and other vertical industry scenarios such as energy and industrial manufacturing. The network performance data should include packet processing latency, link load rate, and signal quality indicators at different time points. Based on these data, a multi-dimensional evaluation matrix is formed according to the matrix construction logic in step 406 as the sample input. For each matrix annotation, the optimal traffic splitting strategy parameters are adjusted. These parameters need to be determined based on actual business optimization effects and industry expert experience. For example, in a wind farm scenario, server switching parameters correspond to high-load links, and priority adjustment parameters correspond to low signal quality, ensuring the effectiveness of the samples and scenario relevance. The model structure design needs to match the data analysis requirements of edge computing scenarios. The number of neurons in the input layer needs to be precisely adapted to the number of rows and columns of the multi-dimensional evaluation matrix. For example, when the matrix is 50 rows and 3 columns, the number of neurons in the input layer is set to 150 to ensure that the matrix data is completely input into the model. The feature extraction layer needs to be able to identify the time-varying trends of various performance indicators and indicators. The ability to correlate between standards can be achieved through sliding window analysis to capture features such as continuously increasing latency, load fluctuations, and the linkage between load and signal quality. The multilayer perceptron network is set with two hidden layers. The number of neurons in the first hidden layer is set to twice the dimension of the feature vector to fully learn feature information. The number of neurons in the second hidden layer is set to half that of the first layer to simplify model complexity and avoid redundant calculations. The output layer needs to pre-store a table of correspondence between fitness evaluation values and policy adjustment parameters. This table is formulated based on historical optimization cases and business priority requirements. For example, when the fitness score is lower than 60, parameters such as server address switching and weight increase by 5% are used to ensure that optimization parameters can be quickly mapped and generated in the future.
[0037] Next, the constructed model is trained using gradient descent. First, the weights and biases of neurons in each layer of the model are initialized. Then, the multi-dimensional evaluation matrix from the training sample set is input into the model in batches. This matrix is processed step-by-step through the input layer, feature extraction layer, and multilayer perceptron network to calculate the optimized policy parameters predicted by the model. The predicted parameters are compared with the optimal adjustment parameters labeled on the samples, and the deviation is calculated as the loss value. Based on the loss value, the weights and biases of neurons in each layer are adjusted in reverse using gradient descent. This process is iterated repeatedly. After each iteration, the model performance is evaluated using a validation set (independent data separated from the sample set). If overfitting occurs, the model complexity is adjusted by reducing the number of hidden layer neurons and increasing sample diversity until the loss value is below a preset threshold and the parameter prediction accuracy evaluated on the validation set meets the standard. Finally, the generalization ability of the model is verified using an independent test set. This independent test set consists of data that was not used in training and validation, ensuring that the model can still output accurate policy optimization parameters in unseen edge computing scenarios. This completes the construction and training of the pre-trained dynamic evaluation model.
[0038] Subsequently, the model processing stage begins. First, the input layer receives the multi-dimensional evaluation matrix constructed in step 406. The input layer normalizes and verifies the incoming data, adjusting it to the numerical range used during model training, such as the 0-1 range, to avoid affecting the model's analytical accuracy due to data range fluctuations. Then, the feature extraction layer performs feature analysis on the matrix, identifying the time-varying trends of each column's indicators, such as whether packet processing latency shows a continuous upward trend or whether link load rate fluctuates frequently. It also analyzes the correlation between different indicators, such as whether signal quality indicators decrease synchronously when link load rate increases. Based on these analyses, the two-dimensional structured data of the matrix is transformed into a one-dimensional feature vector. This vector encompasses the core changing characteristics of network performance, providing a concise and crucial input for subsequent deep processing. Then, the feature vector is further processed... The feature vector is input into a multilayer perceptron network. Using the pre-determined weights and biases of each neuron during pre-training, a nonlinear transformation is performed in two hidden layers to strengthen key features in the feature vector, such as high load and low signal quality, which affect the adaptability of the traffic splitting strategy. At the same time, irrelevant features, such as minor latency fluctuations, are weakened. Finally, the network state is output as an evaluation value of the adaptability between the current initial traffic splitting strategy and the network state. This value reflects the degree of matching between the initial strategy and the current network state in a quantitative form. Finally, the output layer performs parameter mapping processing on the adaptability evaluation value. According to the pre-stored correspondence table, when the adaptability evaluation value is lower than a preset threshold, specific parameters are generated, such as switching the target business server address to a server with lower load in the same area or increasing the priority weight of key business data by 5%. These parameters are the strategy optimization parameters.
[0039] In this embodiment of the invention, by combining the critical path determined by the initial traffic splitting strategy, timestamping data packets at the UPF inlet and outlet nodes and calculating the processing delay by the timestamp difference, the core data transmission path pointed to by the initial traffic splitting strategy can be directly locked, ensuring a strong correlation between the collected delay data and the execution path of the traffic splitting strategy, and avoiding interference from irrelevant path data. Based on the path status reflected by the data packet processing delay, the traffic statistics device of the transmission network node is triggered to collect throughput and port capacity data within a set sampling period, and then the link load rate is calculated by the ratio of the two. This enables targeted triggering of performance parameter collection, rather than indiscriminate collection. Continued data collection reduces unnecessary resource consumption; by associating network congestion status with the link load rate, the RF measurement unit of the 5G base station is activated to obtain the raw measurements of RSRP and SINR, and then signal quality indicators are obtained through weighted calculation. This allows for dynamic activation of signal measurements based on link congestion, avoiding redundant measurements when the link is in good condition and optimizing resource usage; by aggregating packet processing latency, link load rate, and signal quality indicators to form network performance parameters, this integrates scattered time, load, and signal dimension data into a complete set of performance parameters, avoiding the biased evaluation caused by isolated data from each dimension. The aforementioned network performance parameters are standardized, mapping latency, load rate, and signal quality metrics of different dimensions to a unified numerical space and generating standardized parameter vectors. This eliminates weight imbalances caused by differences in units and numerical ranges; for example, the millisecond unit of latency and the percentage unit of load rate no longer have magnitude interference. A multi-dimensional evaluation matrix containing latency, load, and signal quality is constructed based on the standardized parameter vectors. This transforms linear parameter vectors into a structured matrix form, clearly presenting the relationships between performance dimensions rather than a scattered list of values. A pre-trained dynamic evaluation model is then used to evaluate the multi-dimensional... The evaluation matrix is processed to obtain policy optimization parameters, and a hierarchical processing structure enables in-depth analysis of the multi-dimensional evaluation matrix. The input layer ensures that the matrix data is completely entered into the model, avoiding information loss. The feature extraction layer can mine the correlation features of latency, load, and signal quality in the matrix, rather than simply extracting a single parameter. The nonlinear transformation and feature recombination of the multilayer perceptron can capture the deep influence relationship between various performance dimensions, rather than being limited to linear correlation. The parameter mapping of the output layer directly transforms the evaluation results into specific parameters that can be used for policy optimization, providing an effective and feasible adjustment basis for the dynamic optimization of the subsequent initial diversion policy.
[0040] In a preferred embodiment of the present invention, step 500 involves dynamically optimizing the initial traffic splitting strategy using strategy optimization parameters to obtain an optimized traffic splitting strategy; and performing uplink traffic classification (UL CL) processing and data identification on data packets based on the optimized traffic splitting strategy to obtain the final routing decision, including: Step 501: Based on the strategy optimization parameters, dynamically adjust the priority weights in the initial traffic splitting strategy to generate an optimized traffic splitting strategy. The optimized traffic splitting strategy includes the target service server address and the adjusted priority weights. Specifically, it includes: First, extracting the strategy optimization parameters obtained in step 407. These parameters include a weight adjustment coefficient, a target server load threshold, and a service priority calibration rule. The weight adjustment coefficient is determined based on real-time network performance, such as link load rate and signal quality. For example, when the load of a target service server is below a preset threshold (e.g., 50%), the weight adjustment coefficient is set to 1.1; if the load is close to the threshold (e.g., 65%), it is set to 0.9. Next, calling the initial traffic splitting strategy generated in step 305, extracting the initial priority weights. These weights are initially preset according to the service type. For example, the weight of wind turbine control service in a wind farm is set to 0.9, environmental monitoring service is set to 0.5, and historical data statistics service is set to 0. 0.3; Subsequently, the adjusted weight is dynamically adjusted according to the calculation logic of adjusted weight = initial priority weight × weight adjustment coefficient. For example, the initial weight of wind turbine control business is 0.9 multiplied by the adjustment coefficient of 1.1, resulting in an adjusted weight of 0.99. The initial weight of environmental monitoring business is 0.5 multiplied by the adjustment coefficient of 0.9, resulting in an adjusted weight of 0.45. After that, the adjusted weight is checked for compliance with business priority to ensure that the adjusted weight of critical business (such as wind turbine control) is still higher than that of ordinary business. If the adjusted weight of critical business is lower than that of ordinary business, the weight correction mechanism is triggered to force the weight of critical business to be set to no less than the preset minimum value, such as 0.8. Finally, the adjusted priority weight is integrated with the target business server address in the original initial traffic distribution strategy. Target server addresses with load exceeding the threshold (such as 70%) are removed, and alternative server addresses with lower load in the same area are added to form an optimized traffic distribution strategy that includes the correspondence between the target business server address and the adjusted priority weight.
[0041] Step 502: Based on the target service server address and adjusted priority weight in the optimized traffic splitting strategy, perform uplink traffic classification (UL) CL processing on the data packets to determine the initial forwarding path of the data packets. Specifically, this includes: First, based on the optimized traffic splitting strategy, construct a mapping table of priority weight, service type, and target server address. For example, adjusted weights of 0.8 to 1.0 correspond to critical services such as wind turbine control and equipment fault diagnosis, matching low-latency server addresses near the booster station; weights of 0.5 to 0.7 correspond to ordinary services such as environmental monitoring and equipment status statistics, matching server addresses with moderate load in the region; weights of 0.1 to 0.4 correspond to low-priority services such as historical data backup and non-real-time reports, matching server addresses with low load at the edge of the region. Next, associate the service type of the currently pending data packets. By parsing the user identifier (such as IMSI) or service identifier field in the data packet header, determine the service type of the data packet, such as wind turbine control service. Then, match the corresponding priority weight range in the mapping table according to the service type, thereby locking the set of target service server addresses associated with that range. Finally, perform uplink traffic classification (UL) CL processing. In the CL (Client-Server) process, data packets are grouped according to their priority weight from high to low. High-priority data packets are assigned to the server with the lowest latency in the target server address set, such as wind turbine control data packets being assigned to server 1 at the booster station. Low-priority data packets can be assigned to servers with lower load in the address set, such as historical data data packets being assigned to server 3 at the area edge. Finally, based on the assigned target server address and the routing topology of the transmission network, the transmission path from the UPF (Upstream Power Provider) to the target server is determined. This path includes information such as transmission nodes and link identifiers, and is the initial forwarding path for the data packets.
[0042] Step 503: Based on the initial forwarding path, perform deep packet inspection on the data packets to identify the business data types and Service Level Agreement (SLA) requirements. Specifically, this includes: First, determining the scope of deep packet inspection. Unlike surface protocol inspection, which only parses IP and TCP / UDP headers, deep inspection requires analyzing the application layer data of the data packets to extract business characteristic fields. For example, in a wind farm scenario, the analysis checks whether the application layer data contains fields such as wind turbine speed adjustment commands and pitch angle control parameters. If so, it is determined to be wind turbine control business data; if it contains fields such as ambient temperature collection values and wind speed statistics, it is determined to be environmental monitoring business data; if it contains fields such as monthly power generation reports, it is determined to be historical data statistics business data. Next, establish a preset association library between business data types and SLA requirements. This library is configured based on the business needs of vertical industries. For example, the SLA requirements for wind turbine control business are set as transmission latency less than or equal to 40ms and data reliability greater than or equal to 99.99%. For environmental monitoring services, the transmission latency is set to be less than or equal to 100ms, data reliability to be greater than or equal to 99.9%, and packet loss rate to be less than or equal to 0.1%. For historical data statistics services, the transmission latency is set to be less than or equal to 300ms, data reliability to be greater than or equal to 99.5%, and packet loss rate to be less than or equal to 0.5%. Subsequently, deep packet inspection is used to further extract the SLA identifier field (if any) carried in the data packets. For example, some service data packets define explicit service level parameters in their application layer header, where the latency requirement field is set to 35 milliseconds and the reliability requirement field is set to 99.995%. If the data packet does not carry an SLA identifier field, the corresponding SLA requirement is matched in the preset association library according to the aforementioned determined service data type. Finally, the determined service data type and the determined SLA requirement are integrated to form an association record of data packet, service type, and SLA, providing a business dimension basis for subsequent path calibration.
[0043] Step 504: The initial forwarding path is calibrated and calculated based on the service data type and Service Level Agreement (SLA) requirements to obtain the final routing decision. Specifically, this includes: First, obtaining the network performance prediction data corresponding to the initial forwarding path determined in step 502. This data is calculated based on the real-time state of the transmission network, including the estimated transmission delay, estimated reliability, estimated packet loss rate, and real-time load rate of the target server. The estimated transmission delay is calculated using path length and link bandwidth; the estimated reliability is calculated using historical link failure probabilities; and the estimated packet loss rate is calculated using link load rate. Next, the estimated network performance data is compared with the SLA requirements determined in step 503. For example, the initial forwarding path prediction data for wind turbine control service data packets... If the estimated latency is 45ms, while the SLA requires a latency of less than or equal to 40ms, the initial path is determined not to meet the SLA requirements. If the estimated performance of the initial path meets the SLA requirements, such as an estimated latency of 32ms less than or equal to 40ms and a load rate of 55% less than or equal to 70%, the initial path is temporarily included in the candidate route set. If the initial path does not meet the SLA requirements, alternative server addresses that were not selected by the initial path but meet the SLA requirements and have a load rate less than or equal to the threshold (e.g., 70%) are selected from the target service server address set corresponding to the optimized traffic splitting strategy. For example, the booster station server 2 with an estimated latency of 30ms and a load rate of 50% is selected. At the same time, the transmission path information corresponding to these alternative server addresses is obtained to form a set of alternative paths.
[0044] Subsequently, to further quantify the adaptability of paths in terms of spatial distribution and transmission efficiency, a cone lateral area algorithm is introduced to construct a path coverage efficiency coefficient to assist in evaluating the rationality of the paths. Specifically, the transmission nodes involved in each path (including initial candidate paths and alternative paths) are regarded as points on the circumference of the base of a cone. The radius r of the base is set as the average straight-line distance (in km) from these transmission nodes to the UPF. This distance is calculated using the node coordinates in the transmission network topology. For example, if a path contains 3 transmission nodes with distances to the UPF of 2km, 3km, and 4km respectively, then the average distance, i.e., the radius r of the base, is 3km. The shortest straight-line distance from the UPF to the target server is set as the height h of the cone (in km). For example, the shortest straight-line distance from the UPF to server 2 of the booster station is... If the straight-line distance is 5km, then h = 5km. Based on the calculation logic of the generatrix length of a cone, the generatrix length l is determined by the Pythagorean theorem, which is the distance from the vertex to the circumference of the bottom surface on the lateral surface of the cone. Then, the lateral surface area S corresponding to each path is obtained according to the formula for calculating the lateral surface area of a cone. Since the size of the lateral surface area S is related to the range of nodes covered by the path and the path length, the smaller the lateral surface area, the shorter the transmission distance and the more concentrated the node distribution, and the better the transmission efficiency and load balancing potential, provided that the necessary nodes are covered. Based on this, the lateral surface areas S of all paths are standardized. Taking the maximum lateral surface area as the benchmark, the path coverage efficiency coefficient of each path is calculated, which is the ratio of the maximum lateral surface area to the current path lateral surface area. The coefficient ranges from 0 to 1. The closer the coefficient is to 1, the better the path coverage efficiency.
[0045] Next, all paths in the candidate route set and alternative path set are comprehensively scored across multiple dimensions, including performance, load balancing, and coverage efficiency. The scoring weights are set according to business requirements; for example, in wind turbine control businesses, SLA satisfaction accounts for 50% of the weight, with SLA satisfaction metrics including the average latency and reliability compliance rates. Server load rate accounts for 30% of the weight, where the server load rate is the difference between the current load rate and the regional average load rate, and a lower value is better. Path coverage efficiency coefficient accounts for 20% of the weight. After calculating the score for each path in each dimension, the scores are summed to obtain the comprehensive score. For example, if an alternative path has an SLA satisfaction score of 95, a load rate score of 85, and a path coverage efficiency coefficient score of 90, then the comprehensive score = 95 × 50% + 85 × 30% + 90 × 20% = 91. The comprehensive scores of all paths are compared, and the path with the highest comprehensive score is selected.
[0046] Finally, the path with the highest comprehensive score is subject to final verification to confirm that its estimated transmission latency, reliability, and packet loss rate all meet the business SLA requirements, and that the real-time load rate of the target server does not exceed the threshold. If the verification passes, the path is determined as the final routing decision. This decision must include complete information such as the target business server address, the identifiers of all nodes involved in the transmission path, the link identifiers, and the path coverage efficiency coefficient to ensure that subsequent data transmission can be performed along this path.
[0047] In this embodiment of the invention, the priority weights in the initial traffic splitting strategy are dynamically adjusted and calculated through strategy optimization parameters, rather than using fixed weights. This allows the priority weights to adapt to changes in current network performance and service requirements, ensuring that high-importance services (such as wind turbine control services in wind farms) always have a reasonable priority ratio. Uplink traffic classification (UL CL) processing is performed based on the target service server address specified in the optimized traffic splitting strategy and the adjusted priority weights. This ensures that the traffic classification process closely follows the optimized strategy, rather than blindly classifying traffic. Deep packet analysis is performed on data packets based on the initial forwarding path, rather than just surface protocol analysis. This allows for in-depth analysis of the service data types (such as real-time control data and historical statistics from wind farms) and Service Level Agreement (SLA) requirements (such as latency thresholds and reliability standards) carried in the data packets. The initial forwarding path is calibrated by combining service data types and SLA requirements, rather than directly using the initial path. This ensures that the path calibration process fully adapts to actual service needs. For example, for wind turbine control data requiring low latency, the initial path is calibrated to meet its SLA latency requirements, while path constraints can be appropriately relaxed for ordinary monitoring data.
[0048] In a preferred embodiment of the present invention, step 600, based on the final routing decision, routes the classified and identified data packets to the corresponding service server via the local network, including: Step 601: Parse the final routing decision to obtain the target service server address; query the local routing table based on the target service server address to determine the next-hop exit port and the corresponding Virtual Local Area Network (VLAN) identifier. Specifically, this includes: First, calling the final routing decision, which contains the IP address of the target service server, the local network transmission node identifier, and pre-configured VLAN association rules. For example, the IP address of the target service server in a wind farm is 192.168.5.10 for wind turbine control and 192.168.5.20 for environmental monitoring. Next, using the routing decision parsing module built into the UPF, extract the target service server IP address from the decision, while filtering out external node information that does not belong to the local network in the transmission path, retaining only forwarding-related fields within the local network. Then, query the static routing table stored locally in the UPF. This routing table pre-stores the correspondence between target server IP address ranges, next-hop IP addresses, and exit ports, for example, 192.168.5.0. The target server in the / 24 network segment has a unified next-hop IP address of the local gateway 192.168.5.1, corresponding to the GigabitEthernet0 / 1 port of the UPF. Next, based on the pre-configured target server IP address and VLAN tag mapping table, the VLAN to which the target server belongs is determined. For example, 192.168.5.10 (wind turbine control server) corresponds to VLAN 10, and 192.168.5.20 (environmental monitoring server) corresponds to VLAN 20. This mapping table is formulated according to the local network planning of the wind farm; different VLANs are used to isolate different types of service data to avoid mutual interference. Finally, the determined next-hop egress port (e.g., GigabitEthernet0 / 1) and VLAN tag (e.g., VLAN 10) are integrated, forming an association record of target server IP, next-hop port, and VLAN tag, providing clear forwarding parameters for subsequent Layer 2 frame reconstruction.
[0049] Step 602: Based on the next-hop egress port and the corresponding Virtual LAN (VLAN) identifier, perform Layer 2 frame reconstruction processing on the data packet, adding the corresponding destination MAC address and VLAN tag to obtain the data frame to be forwarded. Specifically, this includes: First, querying the UPF's ARP cache table based on the next-hop IP address corresponding to the next-hop egress port, such as 192.168.5.1. This cache table records the correspondence between IP addresses and MAC addresses within the local network in real time. For example, the MAC address corresponding to 192.168.5.1 is 00-1A-2B-3C-4D-5E. If the ARP cache table does not contain the MAC address corresponding to the IP address, an ARP request is triggered, sending an ARP broadcast packet to the local network. After the next-hop device (such as the local gateway) responds, the cache table is updated to ensure the accuracy of the destination MAC address acquisition. Next, determine the Layer 2 frame reconstruction format, adopting a Layer 2 Type II frame structure, including a preamble, start-of-frame delimiter, destination MAC address, and source MAC address (the MAC address of the UPF egress port, such as...). The frame consists of three layers: a layer 2 frame and a layer 3 data structure. The layers 1 and 2 are defined as follows: 1) a layer 2 frame with a layer 3 data structure; 2) a layer 3 data structure with a layer 4 data structure; 3) a layer 4 data structure with a layer 5 data structure; 4) a layer 2 frame with a layer 3 data structure; 5) a layer 4 data structure with a layer 5 data structure; 6) a layer 2 data structure with a layer 3 data structure; 7) a layer 2 data structure with a layer 3 data structure; 8) a layer 2 data structure with a layer 3 data structure; 9) a layer 2 data structure with a layer 3 data structure; 10) a layer 2 data structure with a layer 3 data structure; 10) a layer 2 data structure with a layer 3 data structure; 11) a layer 2 data structure with a layer 3 data structure; 12) a layer 2 data structure with a layer 3 data structure; 13) a layer 2 data structure with a layer 3 data structure; 14) a layer 2 data structure with a layer 3 data structure; 15) a layer 2 data structure with a layer 3 data structure; 16) a layer 2 data structure with a layer 3 data structure; 17) a layer 2 data structure with a layer 3 data structure; 18) a layer 2 data structure with a layer 3 data structure; 19) a layer 2 data structure with a layer 3 data structure; 10 ...
[0050] Step 603: The data frame to be forwarded is processed by MAC address table matching and VLAN tag exchange through the local network switching device to complete the final forwarding to the corresponding service server network interface. Specifically, this includes: First, the data frame to be forwarded enters the local network switching device through the next-hop egress port of the UPF (such as GigabitEthernet0 / 1). The switching device first parses the VLAN tag in the frame, extracts the VLAN ID, such as 10, and determines the port range corresponding to the VLAN according to the VLAN partitioning rules built into the switch, such as the GigabitEthernet port of the switch. Net0 / 2 to GigabitEthernet0 / 10 all belong to VLAN 10, ensuring that data frames only circulate within their respective VLANs and avoiding invalid cross-VLAN propagation. Next, the switching device extracts the destination MAC address from the frame, such as 00-1A-2B-3C-4D-5E. If it's a cross-switch forwarding, it's the MAC address of the next-hop switch; if it's a direct connection to a server, it's the MAC address of the server's network card. It then queries its own MAC address table, which dynamically records the relationship between MAC address, VLAN, and corresponding port. For example, 00-1A-2B-3C-4D-5E corresponds to VLAN 10. 0. Port GigabitEthernet0 / 3; If the destination MAC address is not recorded in the MAC address table, the switching device only sends a flooding request within the current VLAN. After the destination device responds, the MAC address table is updated to avoid resource waste caused by network-wide flooding. Subsequently, if the data frame needs to be forwarded across multiple switching devices, such as when the target server is located under a switch in another computer room, VLAN tag switching processing needs to be performed. For example, when forwarding from the first switch (VLAN 10) to the second switch, the port information in the tag is updated to the ingress port identifier of the second switch, while the VLAN ID remains unchanged. To ensure that the VLAN affiliation remains unchanged during cross-device transmission, when a data frame arrives at the port of the switch directly connected to the target service server (such as GigabitEthernet0 / 3), the switch verifies whether the VLAN ID of the frame matches the VLAN to which the port belongs. If they match, the VLAN tag is removed to prevent the server from receiving invalid frames with tags. Finally, the switch sends the processed Layer 2 data frame to the network interface of the target service server (such as the gigabit network card interface of the server) through the directly connected port. After receiving the frame, the server's network card performs a CRC check. If the check passes, the IP datagram is extracted and processed at the application layer.
[0051] In this embodiment of the invention, the target service server address is obtained by parsing the final routing decision, avoiding routing errors caused by missing address information or parsing errors. Simultaneously, the local routing table is queried based on the target server address to determine the next-hop exit port and corresponding VLAN tag, eliminating the need for cross-network routing resource calls, reducing the time spent on obtaining routing information, and improving path location efficiency. Based on the next-hop exit port and VLAN tag, the data packet undergoes Layer 2 frame reconstruction, adding the corresponding destination MAC address and VLAN tag, ensuring that the data frame to be forwarded fully conforms to the local network's Layer 2 transmission specifications, avoiding forwarding failures or data loss due to frame format incompatibility. The addition of the destination MAC address directly... The system directs data frames to the port of the next-hop network device, ensuring targeted transmission and reducing invalid forwarding. Data frames to be forwarded undergo MAC address table matching and VLAN tag switching via local network switching equipment. MAC address table matching quickly locates the destination port of the data frame, reducing flooding and improving forwarding efficiency. VLAN tag switching dynamically adapts to the VLAN requirements of different network segments based on the local network topology, ensuring that data frames maintain the correct network affiliation when transmitted across network segments, ultimately forwarding them to the corresponding network interface of the service server. This avoids path offsets or port mismatches during data transmission, ensuring that data packets reach the target server efficiently and accurately.
[0052] In a preferred embodiment of the present invention, step 700, in which the service server receives data packets routed to its local machine, performs application-layer service processing, and completes a low-latency data response, includes: Step 701: Receive data frames through the network interface of the service server. Perform protocol stack decapsulation processing on the data frames, sequentially stripping the Layer 2 frame header, IP header, and transport layer protocol header to recover the application layer data payload. Specifically, this includes: First, the network interface of the service server (e.g., an IEEE 802.3 standard gigabit network card) receives data frames forwarded by the local network switching device in step 603. This data frame carries a Layer 2 structure conforming to the IEEE 802.3 standard Type II and has been isolated by VLAN to ensure it is the target service type, such as wind turbine control service in a wind farm. Next, the server's built-in network protocol stack initiates the decapsulation process. First, perform a cyclic redundancy check (CRC) on the data frame. If the check fails, the frame is discarded to prevent erroneous data from entering subsequent processing. If the check passes, the Layer 2 frame header is stripped. This header contains the destination MAC address, source MAC address, and VLAN tag field. The MAC address is the server's network card MAC address, and the source MAC address is the switching device port MAC address. After stripping, the IP datagram is retained. Subsequently, the IP datagram is parsed, extracting the version number, protocol type, and source IP address from the IP header. The packet header includes fields such as address and destination IP address. Protocol types are identified by symbols like 6 for TCP and 17 for UDP. The source IP address is the IP address of the terminal device, such as 192.168.5.100 for the wind turbine control terminal. The destination IP address is the IP address of the server, such as 192.168.5.10. After confirming that the IP address matches the server's own IP address, the IP packet header is stripped to obtain the transport layer message. Then, based on the protocol type in the IP packet header, the transport layer protocol header is stripped accordingly. If it's TCP, fields such as source port, destination port, and sequence number are extracted. If it is a UDP protocol, the corresponding port field is extracted. The source port is the terminal service port, such as 50001, and the destination port is the server service port, such as 8080. After ensuring that the port is consistent with the preset service port (such as wind turbine control service bound to port 8080), the transport layer protocol header is stripped. Finally, the remaining data stream is determined as the application layer data payload. This payload may contain service information such as wind turbine speed adjustment commands and equipment status query requests from the wind farm. At the same time, the payload length is checked to ensure that it is consistent with the length field in the transport layer message to avoid data truncation.
[0053] Step 702: Parse the application layer data payload according to the predefined application layer protocol, and extract the business operation instructions and parameter information. Specifically, this includes: First, to ensure that the application layer protocol can adapt to the business characteristics and equipment requirements of vertical industries such as wind power plants, it is necessary to complete the formulation and pre-storage of the predefined application layer protocol. The specific process includes: conducting a survey of business requirements in vertical industries, and for the core business scenarios of wind power plants, such as wind turbine speed regulation, equipment status query, fault alarm reporting, historical data statistics, etc., jointly clarifying the requirements of each industry with equipment manufacturers (such as wind turbine manufacturers) and operation and maintenance teams. The document outlines the instruction types, data interaction frequency, parameter accuracy requirements, and security verification rules for each service. Based on the survey results, it designs the overall protocol structure, determining that the protocol consists of four parts: a fixed-length protocol header, an instruction identifier segment, parameter fields, and an integrity verification segment. The fixed-length protocol header is 10 bytes, containing the protocol version number, total data length, and verification identifier. The instruction identifier segment is 2 bytes, used to distinguish business operation types. The parameter fields have a dynamic length, allocated according to the business type. The integrity verification segment is 4 bytes, employing a cyclic redundancy check algorithm. Subsequently, the specific format and value range of each field are defined. The instruction identifier segment uses hexadecimal encoding: 0x01 represents speed adjustment, 0x02 represents status query, and 0x03 represents fault alarm reporting. The target speed parameter (adapted to speed adjustment services) uses a 4-byte unsigned integer format, with a value range limited to 0 to 1800 r / min, corresponding to the rated speed of the fan, to avoid damage to the equipment due to exceeding the range. The adjustment duration parameter (adapted to speed adjustment services) uses a 4-byte unsigned integer format, with a value range limited to 10 to 300 seconds. Considering the mechanical adjustment characteristics of the fan, too short a duration can easily lead to mechanical shock, while too long a duration will affect the service response efficiency. Equipment status parameters... The data (adaptation status query business) uses 2-byte binary bits for identification, with each bit corresponding to a device status, such as bit0 representing power status and bit1 representing wind turbine operating status. Then, a protocol specification document is compiled, such as "Wind Turbine Remote Control Application Layer Protocol V1.0", which details the correspondence between business operation instructions, field positions, parameter formats, value ranges, data interaction processes, and exception handling mechanisms. After multiple rounds of internal technical reviews and confirmation of customer requirements, the protocol specification is imported into the application layer parsing module of the business server to complete the protocol pre-storage and ensure that the server can perform subsequent parsing operations according to the specification.
[0054] After completing the formulation and pre-storage of the aforementioned predefined application layer protocol, the server's application layer parsing module reads the protocol header of the application layer data payload. First, it verifies whether the protocol version number matches the version in the pre-stored specification. If both are V1.0, a version mismatch triggers the protocol compatibility mechanism, such as calling backward compatibility parsing logic. If the versions match, it extracts the total data length field from the protocol header, confirming that the length of the currently received application layer data payload matches this field value to avoid data truncation. Next, it identifies the instruction identifier field, comparing its value with the instruction encoding table in the pre-stored protocol specification. For example, if instruction identifier 0x01 is read, it's determined to be a fan speed adjustment instruction; if 0x02 is read, it's determined to be a device status query instruction. Then, it locates the corresponding parameter field based on the instruction type, extracting the parameter value according to the mapping relationship between instruction and parameter field positions in the protocol specification. For example, in a speed adjustment instruction, the parameter field starts from the 13th byte of the application layer data payload. The first 4 bytes are the target speed parameter; for example, if the extracted hexadecimal data 0x000005DC is converted to decimal (1500 r / min), the last 4 bytes are... Adjusting the duration parameter, for example, if the extracted hexadecimal data 0x0000003C is converted to decimal, it is 60 seconds; then, the extracted parameter information is checked for compliance, referring to the preset parameter value range in the pre-stored protocol specification. For example, if the rated speed of the fan is 1800 r / min, and the target speed parameter is 2000 r / min (exceeding the upper limit of the value range), the parameter is determined to be out of standard, triggering the parameter correction mechanism to forcibly adjust the parameter to the rated maximum value of 1800 r / min. If the adjustment duration parameter is 5 seconds (below the value range), it is considered that the parameter is out of standard. If the parameter is deemed invalid (within the limit), a parameter correction mechanism is triggered, adjusting the parameter to the lower limit value of 10 seconds. If the parameter is within the compliant range, the original value is retained. Finally, the verified business operation instructions and parameter information are integrated. Business operation instructions, such as speed adjustment, and parameter information, such as target speed of 1500 r / min and adjustment duration of 60 seconds, are organized into business processing input data according to a predefined structured format (such as instruction type, parameter 1 name, parameter 1 value, parameter 2 name, and parameter 2 value), providing a clear and compliant basis for subsequent business logic calculations.
[0055] Step 703: Based on the business operation instructions and parameter information, perform corresponding business logic calculations to obtain the response data payload. Specifically, this includes: First, according to the business operation instruction type determined in step 702, call the preset business logic module in the server. For example, the wind turbine speed adjustment instruction corresponds to calling the wind turbine speed control logic module, and the equipment status query instruction corresponds to calling the equipment status acquisition logic module. Taking wind turbine speed adjustment in a wind power plant as an example, after calling the module, first read the current operating data of the wind turbine. This data is stored in real time in the local database of the server, including the current speed of 1200 r / min, operating temperature of 45℃, and load rate of 40%. At the same time, acquire the latest real-time image frame of the wind turbine blade. This image is acquired by the wind turbine nacelle camera every second and stored synchronously in the database to help determine whether the blade attitude is normal.
[0056] Considering that wind turbine speed regulation must take into account the mechanical safety of the blades and avoid additional mechanical losses during the regulation process due to abnormal blade posture (such as offset or deformation), an image pixel-to-line distance algorithm needs to be introduced to verify the posture of the blades in real-time images. The application of this algorithm requires first completing image preprocessing and setting a reference line, and then determining the blade state through pixel distance calculation: First, the acquired blade image frames are preprocessed, including grayscale conversion and edge detection, to obtain a set of key pixels on the blade edges. Grayscale conversion converts the color image to grayscale to simplify calculations, and edge detection extracts pixels from the blade edge contour and removes background interference pixels. Each pixel in this set is represented by (x, y) coordinates, where x is the horizontal pixel position and y is the vertical pixel position. Next, the pre-stored blade reference line parameters are called; this reference line is the central axis of the blade during normal operation. The line is determined through multiple calibrations of blade images under normal operating conditions, and its parameters are stored in the algorithm configuration library, including parameters such as the slope and intercept of the line. Then, according to the calculation logic of the distance from the image pixel to the line, sampling points in the set of pixels on the blade edge are selected sequentially. To balance calculation efficiency and accuracy, a sampling point is selected every 5 pixels. The (x, y) coordinates of each sampling point are substituted into the distance calculation logic to obtain the distance value from each sampling point to the reference line. Then, according to the wind turbine blade safety operation standard, a preset distance threshold is set, such as 0 to 5 pixels. If it exceeds this range, it is determined that there is a slight deviation in the blade attitude. If it exceeds 10 pixels, it is determined that there is a significant abnormality. The percentage of pixels whose distance exceeds the threshold among all sampling points is counted. If the percentage is less than 5%, the blade attitude is determined to be normal. If the percentage is between 5% and 15%, it is determined that there is a slight deviation. If the percentage exceeds 15%, it is determined that there is a significant abnormality.
[0057] Next, combining the extracted parameter information (target speed 1500 r / min, adjustment time 60 s) with the blade attitude verification results, logical calculations are performed: first, the speed adjustment difference is calculated, 1500 - 1200 = 300 r / min; then, based on the wind turbine hardware characteristics (maximum adjustment rate is 10 r / min / s), the theoretical adjustment time is calculated, 300 ÷ 10 = 30 s; if the blade attitude is normal and the percentage of sampling points exceeding the threshold is less than 5%, then the adjustment time of 60 s in the parameters is deemed compliant, and the theoretical adjustment rate of 10 r / min / s is applied. If the blades are slightly misaligned, exceeding the threshold by 5% to 15%, the adjustment rate needs to be reduced (e.g., to 7 r / min / s) to reduce mechanical shock. In this case, the theoretical adjustment time is recalculated: 300 ÷ 7 ≈ 42.86 s, which is still less than the parameter adjustment time of 60 s. The adjusted rate is then used. If the blades are obviously abnormal, exceeding the threshold by more than 15%, the safety protection mechanism is triggered. The speed increase is temporarily suspended, the adjustment rate is set to 0 r / min / s, and a blade abnormality warning message is generated.
[0058] Subsequently, response data is generated. In addition to the original adjustment confirmation flag, actual adjustment rate, estimated completion time, current speed feedback, and operating temperature feedback, blade attitude verification results and image analysis basis are also required to ensure that the response data can fully reflect the factors considered in the adjustment decision. Among them, the adjustment confirmation flag is 0x00, which means confirmed execution and 0x01 means not to execute for the time being. The actual adjustment rate is such as 10 r / min / s or 7 r / min / s. The estimated completion time is such as 30s or 42.86s. The current speed feedback is 1200 r / min. The operating temperature feedback is 45℃. The blade attitude verification results are such as normal blade attitude, slight blade deviation, and obvious blade abnormality. The image analysis basis is such as the percentage of pixels exceeding the threshold is 2%.
[0059] Next, the calculated response data is logically verified. In addition to confirming that the adjustment rate does not exceed the safe operating range of the wind turbine (the maximum adjustment rate does not exceed 15 r / min / s) and the estimated completion time does not exceed the business tolerance threshold (the wind turbine adjustment business tolerance threshold is 120s), it is also necessary to verify whether the protection measures under abnormal blade conditions are effective. For example, whether the adjustment rate is set to 0 when the blade is obviously abnormal. If the verification passes, the response data is retained. If it fails, the calculation logic is adjusted (such as further reducing the adjustment rate or extending the estimated completion time) and recalculated. Finally, the verified response data is organized into a response data payload according to the format of the predefined application layer protocol. The data is arranged in the order of confirmation identifier, blade attitude verification result, actual adjustment rate, estimated completion time, current speed, operating temperature, and percentage of pixels exceeding the threshold. This ensures that the payload structure conforms to the protocol specifications and enables the terminal side to fully understand the basis of the speed adjustment decision through the response data, including the blade image analysis results.
[0060] Step 704: Encapsulate the response data payload according to a predefined application layer protocol, sequentially adding a transport layer protocol header, an IP packet header, and a Layer 2 frame header to obtain a response data packet conforming to the network transmission format. Specifically, this includes: First, based on the response data payload, adding an application layer protocol header according to the application layer protocol. This header contains fields such as protocol version, response identifier, and payload length. For example, the protocol version is V1.0, and the response identifier (0x80) represents a business response, ensuring the integrity of the application layer data structure. Next, according to the transport layer protocol type extracted in step 701, such as TCP, add a transport layer... The protocol header, if it's a TCP protocol, includes the source port (server service port 8080), destination port (terminal service port 50001), acknowledgment sequence number (based on the sequence number sent by the terminal in step 701 plus 1), and window size (e.g., 8192 bytes). If it's a UDP protocol, the corresponding port field is included to ensure that the transport layer information matches the information sent by the terminal for a return trip. Then, an IP header is added, including the source IP address, destination IP address, protocol type, time to live (TTL), and checksum. The source IP address is the service server IP 192.168.5. .10, the destination IP address is the terminal device's IP address 192.168.5.100, the protocol type is the corresponding transport layer protocol, and the time-to-live (TTL) is set to 64 to avoid infinite forwarding in the local network and ensure that the IP layer can correctly route to the terminal; then, add a Layer 2 frame header, query the server's ARP cache table to obtain the destination MAC address, i.e., the terminal device's MAC address, such as 00-3A-4B-5C-6D-7E. If the terminal is not in the ARP cache, an ARP request is sent to obtain it, and the destination MAC field is filled in, along with the server's network card MAC address (00-2A-3B-...). (4C-5D-6E) Fill in the source MAC field, add a VLAN tag field according to the VLAN identifier (such as VLAN10) in step 601, tag type 0x8100, VLANID10, set the frame type field, 0x0800 represents IP packet; finally, perform a format compliance check on the encapsulated response data packet to confirm that the length and value range of each layer protocol header field comply with IEEE802.3, TCP / IP and other standards, and calculate the CRC check value of the layer 2 frame and add it to the frame tail to ensure that the data packet can be correctly identified and forwarded in the local network.
[0061] Step 705 involves sending a response data packet conforming to the network transmission format to the local network through the network interface of the service server to complete a low-latency data response. Specifically, this includes: First, the network interface module of the service server reads the encapsulated response data packet. After confirming that the CRC check of the data packet passes, it obtains the VLAN identifier in the data packet, such as VLAN 10, and maps the data packet to the network port of the corresponding VLAN on the server, such as binding VLAN 10 to the server's GigabitEthernet0 / 2 port. Next, the network interface module sends the data packet to the directly connected local network switching device according to the local network's transmission rate, such as a gigabit transmission rate of 1000Mbps. During the transmission process, the port transmission status is monitored in real time. If a transmission timeout occurs, a retransmission mechanism is triggered. The number of retransmissions does not exceed 3, with each retransmission spaced 10ms apart, to avoid frequent retransmissions increasing latency. Subsequently, after receiving the data packet, the switching device, based on the steps in step 603... The system uses MAC address table matching logic to quickly locate the port corresponding to the destination MAC address (terminal device MAC), such as the GigabitEthernet0 / 5 port of a switch. Simultaneously, it verifies that the VLAN ID of the data packet matches the VLAN affiliation of the port (both are VLAN 10). Once confirmed, the data packet is forwarded to the port where the terminal device is located. Next, the service server waits for a response confirmation from the terminal device, such as an ACK packet from the TCP protocol. If an ACK is received within a preset timeout period (e.g., 200ms, adapted to the low-latency requirements of wind farms), the response is considered successfully sent. If no ACK is received, a retransmission mechanism is triggered. Finally, the server records key information about this response in its local log, including sending time, terminal IP, response type, and time consumed, for subsequent maintenance analysis. This also releases temporary resources used in this service processing, such as cached parameter data and protocol header information.
[0062] In this embodiment of the invention, after receiving data frames through the network interface of the business server, the Layer 2 frame header, IP packet header, and transport layer protocol header are sequentially stripped according to the protocol stack layer, rather than being unordered or cross-layer decapsulation. This ensures that redundant transmission control information at each layer is accurately removed, avoiding interference from residual protocol header fields with application layer data parsing. Parsing the application layer data payload according to a predefined application layer protocol, rather than relying on dynamic or non-standard protocols, ensures the consistency and stability of the parsing logic, avoiding parsing deviations caused by protocol inconsistencies. Executing corresponding business logic calculations based on extracted business operation instructions and parameter information, rather than blindly calculating without instructions, allows the business processing to closely align with actual business needs, resulting in highly targeted calculations. For example, for wind turbine control instructions, preset speed adjustment can be directly invoked. The logic module calculates the response data payload based on the input target speed parameters, ensuring that the response data payload contains only the necessary information for the business, such as adjustment confirmation commands and current speed feedback values, without any redundant or invalid data. This ensures the conciseness and usability of the response data. The response data payload is encapsulated according to a predefined application layer protocol, sequentially adding the transport layer protocol header, IP packet header, and Layer 2 frame header, rather than scrambling the protocol stack order or omitting necessary fields. This ensures that the encapsulated response data packet fully conforms to network transmission format standards, avoiding response failures or routing errors due to format incompatibility. The response data packet conforming to the transmission format is sent to the local network through the business server's network interface, rather than through cross-regional or wide area networks, fully utilizing the advantages of short-path transmission on the local network and reducing transmission latency of the response data.
[0063] like Figure 2 As shown, embodiments of the present invention also provide a low-latency data processing system in an edge computing environment, comprising: The terminal access module is used by terminal devices to send data packets containing user identifiers and service data through the 5G wireless access network. The base station transmission module is used to forward the data packet to the user plane function UPF deployed in the edge equipment room through the transmission network after the 5G base station receives the data packet; The policy generation module is used by the User Plane Function (UPF) to parse the received data packets, extract the user identifier and real-time location information, and generate an initial traffic splitting policy based on the user identifier, real-time location information, and a pre-configured Dedicated Data Network Name (DNN). The optimization module is used to respond to the initial traffic splitting strategy by collecting network performance parameters in real time, including packet processing latency, link load rate, and signal quality indicators; constructing a multi-dimensional evaluation matrix based on the network performance parameters; and inputting the multi-dimensional evaluation matrix into a pre-trained dynamic evaluation model for analysis to obtain strategy optimization parameters. The routing decision module is used to dynamically optimize the initial traffic splitting strategy using policy optimization parameters to obtain the optimized traffic splitting strategy; based on the optimized traffic splitting strategy, it performs uplink traffic classification (UL CL) processing and data identification on data packets to obtain the final routing decision; The data routing module is used to route classified and identified data packets to the corresponding business servers through the local network based on the final routing decision. The business processing module is used by the business server to receive data packets routed to the local machine, perform application layer business processing, and complete low-latency data response.
[0064] It should be noted that this system is a system corresponding to the above method. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.
[0065] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.
Claims
1. A low-latency data processing method in an edge computing environment, characterized in that, The method includes: Step 100: The terminal device sends a data packet containing the user identifier and service data through the 5G wireless access network; Step 200: After receiving the data packet, the 5G base station forwards the data packet to the User Plane Function (UPF) deployed in the edge data room through the transmission network; Step 300: The User Plane Function (UPF) parses the received data packets and extracts the user identifier and real-time location information; and generates an initial traffic splitting strategy based on the user identifier, real-time location information, and pre-configured Dedicated Data Network Name (DNN). Step 400: In response to the initial traffic splitting strategy, network performance parameters, including packet processing latency, link load rate, and signal quality indicators, are collected in real time; a multi-dimensional evaluation matrix is constructed based on the network performance parameters; the multi-dimensional evaluation matrix is input into a pre-trained dynamic evaluation model for analysis to obtain strategy optimization parameters; Step 500: Dynamically optimize the initial traffic splitting strategy using strategy optimization parameters to obtain the optimized traffic splitting strategy; perform uplink traffic classification UL CL processing and data identification on data packets based on the optimized traffic splitting strategy to obtain the final routing decision; Step 600: Based on the final routing decision, the classified and identified data packets are routed to the corresponding business servers through the local network; Step 700: The service server receives the data packets routed to the local machine, performs application layer service processing, and completes a low-latency data response.
2. The low-latency data processing method in an edge computing environment according to claim 1, characterized in that, Step 200 includes: The radio frequency unit of the 5G base station receives the data packet through the 5G air interface physical channel and performs signal demodulation and baseband processing to obtain the baseband processed data packet. The baseband-processed data packets are parsed to verify their integrity and the protocol headers of each layer in the 5G air interface protocol stack are stripped to obtain the core data frames. The core data frames are carried over the transmission network, encapsulated into data packets in a format suitable for transmission over fiber optic or IP networks, and forwarded to the User Plane Function (UPF).
3. The low-latency data processing method in an edge computing environment according to claim 2, characterized in that, Step 300 includes: The data packets received from the transmission network are decapsulated using the GTP-U tunneling protocol to recover the user plane protocol data units; The protocol header of the user plane protocol data unit is parsed to extract the user identification information contained therein. At the same time, the tracking area code (TAI) is extracted from the header of the user plane data packet of the N3 interface as real-time location information. Based on the real-time location information and the topological relationship between the pre-configured service area, the user's target service area identifier is obtained by determining the attribution. The user identifier, target service area identifier, and pre-configured dedicated data network name (DNN) are matched and calculated to obtain the policy mapping relationship; Based on the policy mapping relationship, an initial traffic splitting policy containing the target business server address and priority weight is generated.
4. The low-latency data processing method in an edge computing environment according to claim 3, characterized in that, Step 400 includes: Based on the critical path determined by the initial traffic splitting strategy, the data packet is timestamped at the ingress and egress nodes of the User Plane Function (UPF), and the data packet processing delay is obtained by calculating the timestamp difference. Based on the path status reflected by the packet processing delay, the traffic statistics device of the transmission network node is triggered to collect its throughput and port capacity data within a set sampling period. The link load rate is obtained by calculating the ratio of throughput to port capacity. Based on the network congestion status indicated by the link load rate, the radio frequency measurement unit of the 5G base station is activated to obtain the original measured values of the reference signal received power (RSRP) and signal-to-noise ratio (SINR). The signal quality index is obtained through weighted calculation. Data packet processing latency, link load rate, and signal quality indicators are aggregated to form network performance parameters.
5. The low-latency data processing method in an edge computing environment according to claim 4, characterized in that, Step 400 also includes: The network performance parameters are standardized by performing a transformation process, mapping packet processing latency, link load rate, and signal quality indicators to a unified numerical space to generate a standardized parameter vector. A multi-dimensional evaluation matrix including latency, load, and signal is constructed based on the standardized parameter vector. The multi-dimensional evaluation matrix is processed by a pre-trained dynamic evaluation model to obtain policy optimization parameters. The processing includes: the pre-trained dynamic evaluation model comprising an input layer, a feature extraction layer, a multilayer perceptron network, and an output layer connected in sequence; the input layer receives the multi-dimensional evaluation matrix; the feature extraction layer performs feature parsing on the matrix to obtain feature vectors containing latency, load, and signal quality indicators; the feature vectors are input into the multilayer perceptron network, and nonlinear transformation and feature recombination are performed through hidden layers to obtain a network state and traffic splitting policy fit evaluation value; the output layer performs parameter mapping processing on the network state and traffic splitting policy fit evaluation value to generate policy optimization parameters.
6. The low-latency data processing method in an edge computing environment according to claim 5, characterized in that, Step 500 includes: Based on the strategy optimization parameters, the priority weights in the initial traffic splitting strategy are dynamically adjusted and calculated to generate an optimized traffic splitting strategy. The optimized traffic splitting strategy includes the target service server address and the adjusted priority weights. Based on the target service server address and adjusted priority weight in the optimized traffic splitting strategy, uplink traffic classification (UL CL) processing is performed on the data packets to determine the initial forwarding path of the data packets; Based on the initial forwarding path, perform deep packet analysis on the data packets to identify the service data types and service level agreement (SLA) requirements; The initial forwarding path is calibrated and calculated based on the data type of the service and the service level agreement (SLA) requirements to obtain the final routing decision.
7. The low-latency data processing method in an edge computing environment according to claim 6, characterized in that, Step 600 includes: Parse the final routing decision to obtain the target service server address; query the local routing table based on the target service server address to determine the next-hop exit port and the corresponding virtual LAN VLAN identifier; Based on the next-hop exit port and the corresponding virtual LAN VLAN identifier, the data packet is reconstructed using Layer 2 frame reconstruction, and the corresponding destination MAC address and VLAN tag are added to obtain the data frame to be forwarded. The data frames to be forwarded are processed by MAC address table matching and VLAN tag exchange through the local network switching device to complete the final forwarding to the corresponding business server network interface.
8. The low-latency data processing method in an edge computing environment according to claim 7, characterized in that, Step 700 includes: Data frames are received through the network interface of the business server. The data frames are decapsulated and processed by protocol stack decapsulation. The Layer 2 frame header, IP packet header and transport layer protocol header are stripped in sequence to recover the application layer data payload. The application layer data payload is parsed according to a predefined application layer protocol to extract business operation instructions and parameter information. Based on the business operation instructions and parameter information, perform corresponding business logic calculations to obtain the response data payload; The response data payload is encapsulated according to a predefined application layer protocol, and a transport layer protocol header, an IP packet header, and a layer 2 frame header are added in sequence to obtain a response data packet that conforms to the network transmission format. The response data packet conforming to the network transmission format is sent to the local network through the network interface of the business server to complete the low-latency data response.
9. A low-latency data processing system in an edge computing environment, the system implementing the method as described in any one of claims 1 to 8, characterized in that, include: The terminal access module is used by terminal devices to send data packets containing user identifiers and service data through the 5G wireless access network. The base station transmission module is used to forward the data packet to the user plane function UPF deployed in the edge equipment room through the transmission network after the 5G base station receives the data packet; The policy generation module is used by the User Plane Function (UPF) to parse the received data packets and extract the user identifier and real-time location information. An initial traffic splitting strategy is generated based on the user identifier, real-time location information, and pre-configured dedicated data network name (DNN). The optimization module is used to collect network performance parameters, including packet processing latency, link load rate, and signal quality indicators, in real time in response to the initial traffic splitting strategy. Based on the network performance parameters, a multi-dimensional evaluation matrix is constructed; The multi-dimensional evaluation matrix is input into a pre-trained dynamic evaluation model for analysis to obtain policy optimization parameters; The routing decision module is used to dynamically optimize the initial traffic splitting strategy using policy optimization parameters to obtain the optimized traffic splitting strategy. Based on the optimized traffic splitting strategy, uplink traffic classification (UL CL) processing and data identification are performed on the data packets to obtain the final routing decision; The data routing module is used to route classified and identified data packets to the corresponding business servers through the local network based on the final routing decision. The business processing module is used by the business server to receive data packets routed to the local machine, perform application layer business processing, and complete low-latency data response.
10. A computing device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the method as described in any one of claims 1 to 8.
Citation Information
Patent Citations
Service processing method and system in 5G edge computing scene
CN113766629A
Data distribution method, device and equipment
CN116782259A
Information processing method, device and equipment
CN116887350A
Application data distribution method and device, electronic equipment and storage medium
CN117241320A
Data distribution method and device, related equipment and computer readable storage medium
CN119496739A