Message processing method and device and storage medium

Abstract

The invention provides a message processing method and device and a storage medium, and the method comprises the steps that a first communication device firstly receives service messages forwarded by a user plane function UPF node, and then forwards the service messages according to a tunnel classification table and a terminal service flow table. Wherein the tunnel classification table and the terminal service flow table are obtained by converting local global configuration information of the UPF node. According to the embodiment of the invention, the service processing capability of the UPF is expanded to the first communication equipment, and the message is unloaded and forwarded by means of the first communication equipment, so that the processing pressure of a core network UPF node can be effectively shared, the throughput of the core network UPF node can be improved, and the processing delay of the service message can be shortened and the network communication quality can be optimized through local rapid forwarding of the first communication equipment.

Description

Technical Field

[0001] The embodiments of the present application relate to, but are not limited to, the field of communications, and in particular to message processing methods, devices, and storage media. Background Art

[0002] The current surge in network traffic, significant traffic flows, microbursts, and low-latency demands pose challenges to the current core network user plane processing network element systems. Core network user plane user message processing relies on single-server hardware and software, with performance limited by the CPU processing power and maximum bandwidth constrained by the network interface card (NIC) hardware specifications. Existing traffic offload solutions have the following limitations: Offloading based on server-based smart NICs can reduce CPU load but cannot overcome the NIC's inherent bandwidth bottleneck; independent system offload methods such as edge computing rely on high-level control centers and are not suitable for use within a single core network user plane function (UPF) subsystem. Furthermore, switch-based remote offload technology in SDN networking cannot meet the complex tunnel parsing and layered traffic statistics requirements of the UPF, and the interaction process between the switch and controller is difficult to adapt to core network service requirements. Summary of the Invention

[0003] The embodiments of the present application provide a message processing method, device and storage medium, which can improve the core network UPF throughput and optimize the network communication quality.

[0004] On the one hand, an embodiment of the present application provides a message processing method, applied to a first communication device, the method comprising:

[0005] Receive service messages forwarded by the user plane function UPF node;

[0006] The service message is forwarded according to the tunnel classification table and the terminal service flow table, wherein the tunnel classification table and the terminal service flow table are converted according to the local global configuration information of the UPF node.

[0007] On the other hand, an embodiment of the present application also provides a communication device, comprising at least one processor; at least one memory for storing at least one program; and implementing the message processing method described above when at least one of the programs is executed by at least one of the processors.

[0008] On the other hand, an embodiment of the present application further provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute the message processing method described above.

[0009] On the other hand, an embodiment of the present application also provides a computer program product, including a computer program or computer instructions, characterized in that the computer program or the computer instructions are stored in a computer-readable storage medium, the processor of the business application reads the computer program or the computer instructions from the computer-readable storage medium, and the processor executes the computer program or the computer instructions, so that the communication device performs the message processing method as described above.

[0010] In an embodiment of the present application, a first communication device first receives service messages forwarded by a user plane function (UPF) node, and then forwards these service messages based on a tunnel classification table and a terminal service flow table. The tunnel classification table and the terminal service flow table are converted based on the local global configuration information of the UPF node. By extending the service processing capabilities of the UPF to the first communication device and using it to offload and forward messages, this embodiment of the present application not only effectively shares the processing pressure of the core network UPF node and improves its throughput, but also reduces service message processing latency through local rapid forwarding by the first communication device, thereby optimizing network communication quality. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 This is an architectural diagram of traffic processing between a core network U-plane server and a switch provided by one embodiment of the present application;

[0012] Figure 2 This is a flow chart of a message processing method provided by an embodiment of the present application;

[0013] Figure 3 This is a schematic diagram of communication address configuration provided by an embodiment of the present application;

[0014] Figure 4 This is a schematic diagram of the association action between tables provided by an embodiment of the present application;

[0015] Figure 5 This is an embodiment of the present application. Figure 2 Specific flow chart of step S220;

[0016] Figure 6 This is a schematic diagram of a flow chart of a first communication device processing a message according to an embodiment of the present application;

[0017] Figure 7 This is a flowchart of a first communication device processing a message provided by an embodiment of the present application;

[0018] Figure 8 This is a schematic diagram of an application environment provided by an embodiment of the present application;

[0019] Figure 9 This is a diagram of a remote switch architecture provided by an embodiment of the present application;

[0020] Figure 10 This is a schematic diagram of a ground-to-sky application scenario provided by an embodiment of the present application;

[0021] Figure 11 This is a schematic diagram of the control message format provided by an embodiment of the present application;

[0022] Figure 12 This is a schematic diagram of the interaction between the UPF node and the first communication device provided by an embodiment of the present application;

[0023] Figure 13 This is a schematic diagram of the interaction process between the UPF node and the first communication device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to make the purpose, technical methods and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0025] It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in an order different from that in the flowchart. In the description of the specification, claims and the above-mentioned drawings, the meaning of multiple (or multiple) is more than two, greater than, less than, exceed, etc. are understood to exclude the number itself, and above, below, within, etc. are understood to include the number itself. If there is a description of "first", "second", etc., it is only used for the purpose of distinguishing technical features, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features or implicitly indicating the order of the indicated technical features.

[0026] Cloud computing technology is now widely used across all areas of internet communications. In the communications sector, this has evolved from proprietary hardware to virtualized equipment. Large data centers and 5G core network equipment are integrating cloud-native technologies, relying on the device's CPU computing power to process packets or relying on network interface card hardware with intelligent offload capabilities to accelerate packet processing. Traffic offloading decentralizes traffic processing, allowing packets to be processed in a distributed manner, rather than passing through the core business system.

[0027] As 5G evolves to 5GA, applications such as 4K / 8K ultra-high-definition video and XR mixed reality in enhanced mobile broadband (eMBB) scenarios require single-user access bandwidths of up to 10Gbps. Ultra-reliable low-latency communication (uRLLC) scenarios for the industrial internet and telemedicine require end-to-end latency to be compressed to 0.5ms. This traffic pattern typically exhibits a mix of "significant traffic" and "microbursts."

[0028] The surge in network traffic, large-scale traffic, microbursts, and low latency requirements pose challenges to the current core network U-plane processing network element system. Currently, the core network user plane (User Plane, U-plane) relies on the software and hardware processing capabilities of a single server to process user messages. The performance bottleneck depends on the CPU performance, and the maximum bandwidth of a single server is limited by the network card bandwidth. Figure 1 As shown in the figure, in this networking architecture, the GW server serves as a server node on the user side of the core network. It has an internal service processing unit responsible for tasks such as packet forwarding and service logic processing. The server network card uses bond technology to aggregate multiple network ports to increase the link bandwidth on the network card side. Service traffic is connected to the server through switch 1 and switch 2 via two channels, traffic path 1 and traffic path 2, forming a multi-path load pattern for traffic. However, the throughput of a single server processing business will be limited by the bandwidth capacity of the server network port. Even if the performance of the internal service processing unit of the server is strong, if the network card bandwidth is insufficient, the overall traffic transmission will be limited, which clearly shows that network bandwidth restricts business processing capabilities.

[0029] Existing traffic offloading methods partially rely on server network interface card (NIC) hardware within the system, such as Smart NICs. This hardware replaces the CPU to perform partial traffic offloading, reducing CPU load and improving performance bottlenecks caused by CPU performance. However, this approach cannot address the inherent bandwidth limitations of the NIC itself. Other offloading methods, such as edge computing offloading, rely on independent systems, relying on a higher-level control center and are not suitable for use within a single UPF subsystem in the core network. In SDN networking, switch-based remote offloading technology relies on the OpenFlow protocol for flow table matching and action execution. However, due to the fixed actions supported by the protocol, it cannot meet the complex tunnel parsing and hierarchical traffic statistics requirements of the core network UPF. Furthermore, the interaction between the switch and the controller is difficult to adapt to the core network's service requirements.

[0030] In order to improve the UPF throughput and network communication quality, the embodiment of the present application provides a message processing method, a communication device and a computer-readable storage medium. When the processing method is applied to the first communication device, it first receives the service message forwarded by the user plane function UPF node, and then forwards these service messages according to the tunnel classification table and the terminal service flow table. Among them, the tunnel classification table and the terminal service flow table are converted according to the local global configuration information of the UPF node. The embodiment of the present application extends the service processing capability of the UPF to the first communication device, and uses it to unload and forward messages. It can not only effectively share the processing pressure of the core network UPF node and improve its throughput, but also shorten the processing delay of the service message through local fast forwarding, thereby optimizing the quality of network communication.

[0031] Based on the above analysis, the embodiments of the present application will be further described below in conjunction with the accompanying drawings.

[0032] Reference Figure 2 , Figure 2 This is a flow chart of a message processing method provided by an embodiment of the present application. The execution subject of the method may be a first communication device, and the process of the first communication device executing the method includes but is not limited to steps S210 to S220.

[0033] Step S210: receiving a service message forwarded by a user plane function (UPF) node;

[0034] Step S220: forwarding the service message according to the tunnel classification table and the terminal service flow table, wherein the tunnel classification table and the terminal service flow table are converted according to the local global configuration information of the UPF node.

[0035] Exemplarily, the first communication device is a network switch with custom programming capabilities, which locally integrates a large-capacity double data rate synchronous dynamic random access memory (DDR) and programmable hardware modules (such as data processors DPU, application-specific integrated circuits ASIC, field-programmable gate arrays FPGA, etc.). This type of switch supports users to customize functional logic based on business needs (for example, creating hash tables in local memory space, etc.) through a programmable architecture at the hardware level. In actual applications, the first communication device can receive and process tunnel table entries and flow table rules issued by the business control end (such as a UPF node), and perform table creation, update, deletion, etc. through the local programmable hardware module to realize the forwarding of business messages.

[0036] It is understood that the UPF node is a key component of the 5G core network and belongs to the user plane data processing unit. Its core function is to forward, route, and process user service data, including packet detection, QoS (Quality of Service) control, traffic offloading, and billing data collection. The UPF is separated from control plane functions (such as SMF session management) and can execute flow table rules according to control plane instructions to achieve efficient forwarding of service data.

[0037] It can be understood that a service message refers to a structured data transmission unit that carries actual service data (such as voice, video, text, application data, etc.). It typically consists of a protocol header (containing control information such as source / destination address, port number, protocol type, etc.) and a payload (the user's actual service data). It follows the encapsulation format of a specific network protocol (such as IP, TCP, UDP, etc.) and is used to transmit and process specific service information between network nodes. It is the data carrier for implementing various communication services. For example, HTTP data packets transmitted when browsing the web and message packets in instant messaging are all service messages.

[0038] For example, when the UPF node needs to offload traffic processing tasks to the network node to improve forwarding efficiency, the traffic offloading task can be performed with the help of the first communication device (such as a programmable switch). It is understandable that in the traditional mode, tasks such as message forwarding and QoS control are handled by the server CPU, which has limited processing capabilities and can easily become a performance bottleneck. By handing these tasks over to the first communication device, it can utilize its local large-capacity DDR memory and custom programming capabilities to achieve line-speed forwarding of service messages, thereby reducing server load and optimizing the overall throughput of the core network. Specifically, the UPF node can forward the service messages to be offloaded in the traffic processing task to the first communication device. After the first communication device receives the service messages forwarded by the UPF node, it forwards the service messages according to the tunnel classification table and the terminal service flow table. In this process, the UPF node identifies the service messages that need to be offloaded from the traffic processing task and forwards these messages to the first communication device, thereby transferring part of the traffic tasks originally handled by itself and reducing its own load. After receiving the service message forwarded by the UPF node, the first communication device can analyze and process the message based on the existing tunnel classification table and terminal service flow table, and forward the service message to the corresponding target network node according to the rules and paths recorded in the table, completing the forwarding work after traffic unloading.

[0039] For example, to ensure that the first communication device correctly performs the service message forwarding operation, the UPF node can send the tunnel configuration information and unloading rules corresponding to the service message to the first communication device, so that it can generate a local tunnel classification table and a terminal service flow table to realize message forwarding. Among them, the generation of the two types of table entries is essentially a structured conversion of the local global configuration information of the UPF node. The specific acquisition process is as follows: First, the UPF node parses its own global configuration information, generates a tunnel table containing complete tunnel classification rules, and sends all the locally configured tunnel table addresses to the first communication device. To ensure reliability, the tunnel table is sent one by one and supplemented by a response confirmation mechanism. That is, each time the UPF node sends a tunnel table entry, it needs to wait for the first communication device to return a successful reception confirmation of the table entry before triggering the next tunnel table entry. If no confirmation is received within a timeout or a failure feedback is received, the table entry is retransmitted. After receiving all the tunnel table entries, the first communication device merges them with the locally preset initial table (such as the basic rule table) to form the final tunnel classification table used for message classification and parsing. Then, after the first communication device completes the creation of the tunnel classification table, if the new service message is transmitted for the first time and the flow table rules cannot be matched to achieve forwarding unloading, the new service message can be sent to the UPF node for learning. After the UPF node receives the message and completes the learning of service forwarding information such as source / destination address, QoS parameters, and application type, it can generate a service flow table containing traffic unloading rules based on the learning results, and send the flow table creation or update information to the first communication device. Then, after receiving the service flow table information, the first communication device decodes and queries the local terminal service flow table. If the local terminal service flow table already exists (but there is no rule corresponding to the new service message), it can first report the statistical information of the currently unloaded traffic (such as traffic size, etc.) to the UPF node, and then perform the flow table update operation; if there is no local terminal service flow table, a new flow table can be created and the rules issued by the UPF can be mapped to the new table one by one, and finally a terminal service flow table containing complete traffic unloading rules is formed. This process ensures the consistency and integrity of business message classification and parsing rules and traffic offloading rules through a collaborative mechanism of reliable tunnel table transmission, first packet message learning, and dynamic creation / update of flow tables.

[0040] It should be noted that the tunnel table entries and service flow tables issued by the UPF node to the first communication device can be transmitted via control messages such as tunnel table configuration signaling and service flow table configuration instructions. These control messages are primarily used for management information exchange between the first communication device and the UPF node. They can implement functions such as table entry parameter configuration, rule synchronization, and status maintenance, ensuring that the first communication device generates accurate tunnel classification tables and terminal service flow tables based on the UPF node's policy instructions.

[0041] Exemplarily, after receiving a message, the first communication device can distinguish between control messages and service messages through the following process: first, extract the destination IP address and VLAN tag of the message, and use this as a query condition to match the tunnel classification table (the control signaling table entries and user plane tunnel table entries pre-stored in the table). If the destination IP and VLAN tag of the message match the control signaling-specific table entry in the tunnel classification table (such as the combination of the UPF control plane IP address and the specific control signaling VLAN), it is determined to be a control message (such as tunnel configuration signaling, keep-alive detection message) and the corresponding operation is performed (such as updating the local table entry or replying to the link confirmation); if the control signaling table entry is not matched, but it meets the user plane tunnel table entry, it is confirmed to be a service message.

[0042] For example, the local preset initial table of the first communication device can be generated based on the communication address configured by the user. The specific process is as follows: the user configures the local and peer communication addresses (such as IP address, port number, etc.) for controlling signaling interaction on the UPF node and the first communication device through the network maintenance and management system. Figure 3 As shown, the administrator configures the local communication address of the UPF node to 10.10.80.9 and the address of the other end (first communication device) to 10.10.80.3; at the same time, the administrator configures the local address of the first communication device to 10.10.80.3 and the address of the other end (UPF node) to 10.10.80.9, and establishes a control signaling interaction channel through bidirectional symmetric address configuration. After the first communication device obtains the configuration, it generates an initial table entry based on the local and other end communication addresses set by the user. This table entry can distinguish between business messages and control messages: when receiving a message, the first communication device can determine whether the message belongs to control signaling (such as a message sent by the flow table) or business data (such as a user data flow) based on the address rules in the initial table, thereby providing a basis for subsequent message classification processing.

[0043] For example, before receiving a service message forwarded by a user plane function (UPF) node, the first communication device may receive a keepalive detection message sent by the UPF node. As a type of control message, the keepalive detection message is primarily used to verify whether the communication link between the first communication device and the UPF node is available, ensuring the connectivity and reliability of the underlying transmission path before forwarding the service message.

[0044] Exemplarily, before receiving the service message forwarded by the UPF node, the first communication device may pre-execute a communication link availability verification process to ensure that the link status meets the communication requirements when the service data is transmitted. This verification process can be implemented by relying on the keep-alive detection message sent by the UPF node. The specific process includes: the UPF node can send a keep-alive detection message to the first communication device at a preset period (such as a frequency of 1 time / second) (this message belongs to the category of control messages for interaction between the two parties, including an IP header, a keep-alive message type, and link status query parameters, etc.). The purpose of this message is to verify whether the network connection between the two is unobstructed and whether the link is in an available state.

[0045] Exemplarily, in response to the communication link being in an available state, the first communication device may send a confirmation response to the keep-alive detection message to the UPF node, where the confirmation response is used to indicate that the communication link is available. That is, when the first communication device receives the keep-alive detection message and determines from the message that the communication link is in an available state (e.g., the message arrives on time and the integrity check is correct), it may send a confirmation response to the keep-alive detection message to the UPF node, thereby clearly indicating that the link connectivity is normal and providing feedback confirmation of the link validity for the subsequent offload transmission of service messages.

[0046] Exemplarily, in response to the communication link being in an unavailable state, the first communication device may send an exception message to the UPF node for the keep-alive detection message, and the exception message is used to indicate that the communication link is unavailable. That is to say, when the communication link is in an unavailable state, the first communication device may send an exception response message to the keep-alive detection message to the UPF node, clearly indicating that the link connection is abnormal. In particular, if the link abnormality is triggered by an abnormal keep-alive detection state or port overload, the first communication device may carry an abnormality type code and specific details (such as the link disconnection location, etc.) in the abnormal message to provide the UPF node with accurate fault location information.

[0047] Exemplarily, the encapsulation mechanism of the keep-alive detection message can use the communication address (including IP address and port number) of the UPF node and the first communication device as the identification parameter. The specific process is as follows: When the UPF node encapsulates the keep-alive detection message, it sets the source IP address of the message to its own communication address, and sets the destination IP address to the opposite communication address of the first communication device. The address pair can be pre-configured in both devices by the user through the network maintenance and management system.

[0048] For example, after the UPF node receives a response, if it receives a confirmation response, it determines that the link is normal and continues to forward the business message. If it receives an abnormal message, it triggers the link fault handling mechanism (such as switching to a backup link, reducing traffic load, etc.). If no response is received, it can retry the detection. After multiple consecutive failures, it is determined that the link is interrupted, thereby ensuring the reliability of the link status before the business message is transmitted.

[0049] See also Figure 4 , Figure 4 This is a schematic diagram of the inter-table association action provided by an embodiment of the present application. On the first communication device, the tunnel classification table and the terminal service flow table can both be stored in a hash table format, wherein the tunnel classification table uses "destination IP+VLAN" as the query key and the corresponding tunnel attribute value (such as tunnel type, encapsulation protocol parameters, etc.) as the value, and the terminal service flow table uses "quintuple+VLAN (virtual local area network)" as the key and the traffic unloading rule (such as unloading path, rewrite rule, etc.) as the value, and the two tables are associated through the tunnel attribute value. When the first communication device receives an incoming message, it can first extract the destination IP and VLAN of the message, and use this as the query key to match the tunnel classification table to obtain the tunnel attribute value. If the tunnel attribute value is used to determine that the current message belongs to a service message, the specific process for the first communication device to forward the service message according to the tunnel classification table and the terminal service flow table is as follows: the first communication device parses the tunnel encapsulation of the message, extracts the quintuple information (source IP / port, destination IP / port, protocol number) and the inner VLAN tag of the inner message. Then, the terminal service flow table is queried using the extracted quintuple information and VLAN tag as keys. If a valid entry is matched, the message is rewritten according to the tunnel encapsulation information indicated by the value field in the entry. After the message is rewritten, the first communication device can forward the message to the target path according to the forwarding rules defined in the terminal service flow table (such as the next hop IP).

[0050] It should be noted that the five-tuple information of the message consists of the source IP, destination IP, source port, destination port and protocol type, which is the key feature for the network layer and the transport layer to identify a unique data flow. When the five-tuple of the message is exactly the same, it belongs to the same data flow. The terminal service flow table can map the messages of the same data flow to the same forwarding rule by using the five-tuple and VLAN as hash keys. By pre-storing these mapping relationships in the table (such as specifying the unloading path, etc.), batch classification and directional processing of the same data flow messages can be achieved, thereby improving the efficiency of traffic unloading.

[0051] Exemplarily, when the first communication device receives an incoming message, extracts the destination IP and VLAN and uses them as keys to query the tunnel classification table, if no corresponding tunnel attribute value is matched, it directly extracts the message's quintuple and VLAN, and uses the quintuple and VLAN as keys to query the terminal service flow table.

[0052] It should be noted that when the hash table width of the programmable switch (first communication device) is sufficient, the tunnel classification table and the terminal service flow table can be merged into a long flow table to achieve coordinated matching of internal and external layer features. The long flow table operation continues to use the original message processing logic. For example, after the control message matches the control signaling table entry, an update or response is executed. After the service message matches the service flow table entry, it is unloaded according to the rules. If there is no match, the reporting learning mechanism is triggered.

[0053] See also Figure 5 The specific process of forwarding the service message according to the tunnel classification table and the terminal service flow table in step S220 may include but is not limited to steps S510 to S530.

[0054] Step S510: Identify the service message according to the tunnel classification table to obtain the message type of the service message;

[0055] Exemplarily, in step S510, the message type is determined by parsing the key features of the service message and matching them with the tunnel classification table. Specifically, the first communication device first extracts the destination IP address and VLAN tag in the message and uses them as query conditions to search the tunnel classification table. The corresponding tunnel attribute values (such as GTPU tunnel ID, encapsulation protocol type, etc.) are matched in the table to determine whether the message belongs to the tunnel encapsulation type (such as messages encapsulated by protocols such as GTP and GRE) or the bare packet type (such as original messages without additional tunnel encapsulation or containing only a Layer 2 VLAN tag). This process can provide a basic classification basis for matching subsequent traffic offload rules.

[0056] Step S520: selecting a target traffic offloading rule from multiple traffic offloading rules in the terminal service flow table according to the message type of the service message;

[0057] Exemplarily, in step S520, based on the message type determined in step S510, the first communications device may perform differentiated rule matching logic in the terminal service flow table. Specifically, if the message is of tunnel encapsulation type, the first communications device may further parse the inner five-tuple information of the message (source IP, destination IP, source port, destination port, protocol type) and VLAN tag, and use "five-tuple + VLAN tag" as the search key to match the corresponding traffic offload rule in the flow table. If the message is of a bare packet type, the flow table may be directly queried using the message's own five-tuple and VLAN tag as conditions to locate the target rule.

[0058] Step S530: Forward the service message according to the target traffic offloading rule.

[0059] Exemplarily, in step S530, after obtaining the target traffic unloading rule, the first communication device can perform the following operations according to the target traffic unloading rule to complete message forwarding: modify the message header parameters according to the rule requirements, such as adding a new VLAN tag, adjusting the QoS priority field, etc., to meet the transmission requirements of the target network; forward the processed message according to the path specified by the rule (such as the local data network exit, edge server interface, etc.) to achieve accurate unloading of service traffic from the UPF node to the target node.

[0060] Exemplarily, in response to a service packet failing to match the traffic offload rules in the terminal service flow table, the first communications device may report the service packet to a UPF node. That is, when a service packet fails to match the traffic offload rules in the terminal service flow table, the first communications device may report the service packet to the UPF node. After receiving the packet and completing learning of the service packet, the UPF node may send updated information about the tunnel table and service flow table to the first communications device. Upon receiving the message, the first communications device may update its local tunnel classification table and terminal service flow table based on this information. Specifically, the first communications device may extract the five-tuple and key payload characteristics of the service packet, encapsulate them into a traffic characteristics report, and report it to the UPF node. Upon receiving the report, the UPF node may parse the service characteristics and generate corresponding tunnel configuration parameters and traffic offload rules, and then send the generated information to the first communications device via control signaling. After parsing the signaling, the first communications device may synchronously update the local tunnel classification table and terminal service flow table, enabling adaptive processing of dynamic service flows and avoiding traffic forwarding anomalies caused by static configuration.

[0061] See also Figure 6 , Figure 6This is a flow chart of the first communication device processing a message provided by an embodiment of the present application. The message processing process is as follows: After the first communication device receives the message, it first extracts the destination IP address and VLAN tag of the message, and queries the tunnel classification table (hash table structure) based on the destination IP address and VLAN tag. If it hits (that is, the corresponding tunnel attribute value is queried), the message type is distinguished according to the tunnel attribute value. If it is a control message (such as tunnel table configuration signaling, keep-alive detection message), the signaling content is decoded and the corresponding operation is performed, for example: for tunnel table configuration signaling, the mapping relationship of the local tunnel classification table is updated; for keep-alive detection message, the link status confirmation response is replied after checking the integrity. If it is a service message, the tunnel encapsulation type (such as GTP, GRE, S2A, etc.) is parsed according to the attribute value, and the inner layer five-tuple (source / destination IP, port, protocol) and VLAN tag are extracted after stripping the tunnel header, and then this is used as the key to query the terminal service flow table (hash table structure). If there is no hit (that is, the corresponding tunnel attribute value cannot be found), the five-tuple and VLAN tag of the message can be directly extracted, and then the terminal service flow table can be queried with this as the key. When the corresponding traffic unloading rule is hit, the traffic unloading processing can be performed according to the instructions of the rule, including rewriting the message (such as adding a new encapsulation) and forwarding it to the specified path (such as the local data network, edge computing node, etc.); when the corresponding traffic unloading rule is not hit, the message can be sent to the UPF node so that the UPF node can relearn the tunnel table and flow table based on the message. Subsequently, the UPF node can generate a new tunnel table and flow table and send it to the first communication device, so that the first communication device can synchronously update the local tunnel classification table and terminal service flow table to ensure that subsequent messages of the same type are processed according to the new rules.

[0062] Exemplarily, in response to the exhaustion of the local unloading quota of the first communication device, the first communication device may send an unloading quota exhaustion message to the UPF node. Afterwards, in response to receiving the new terminal service flow table sent by the UPF node after the update based on the unloading quota exhaustion message, the first communication device may update the local terminal service flow table according to the new terminal service flow table. That is to say, when the first communication device detects that the local unloading quota is exhausted (such as the flow table resource usage reaches a threshold) when forwarding a service message, it may send an unloading quota exhaustion message with the currently unloaded traffic data to the UPF node, and at the same time suspend the traffic unloading function, that is, stop the message forwarding processing flow. After receiving the new terminal service flow table sent by the UPF based on the message, the first communication device may parse the signaling and update the local terminal service flow table (such as replacing or adding new unloading rules). After completion, it may re-enable the traffic unloading function and process subsequent messages according to the new rules. The currently offloaded traffic data sent by the first communication device to the UPF node may include at least the following information: the service message's five-tuple and VLAN tag, which uniquely identify the offloaded service flow; the cumulative number of bytes and messages of the offloaded traffic; and the local resources consumed during the offloading process. This information helps the UPF node understand the service attributes and resource consumption of the offloaded traffic, providing data support for subsequent dynamic adjustment of the traffic offloading strategy.

[0063] For example, during the service forwarding process of the first communication device, the UPF node can initiate a traffic query at any time. Figure 7 As shown, after the first communication device receives the query request, the execution process may include but is not limited to step S710 and step S730.

[0064] Step S710: Receive a query message carrying quintuple index information sent by a UPF node;

[0065] Step S720: extracting forwarding information of the service message based on the quintuple index;

[0066] Step S730: Send an information message containing forwarding information to the UPF node.

[0067] For example, in step S710, the UPF node may proactively send a query message to the first communication device to obtain the real-time offloading status (i.e., forwarding status) of the specified service. The message carries the five-tuple index information (source IP, destination IP, source port, destination port, protocol type) of the target service flow. After receiving the query message carrying the five-tuple index information sent by the UPF node and performing a validity check on the message, the first communication device may further perform processing based on the query message.

[0068] For example, in step S720, the first communication device may parse the five-tuple index in the query message and use it as a key to query the local terminal service flow table and traffic statistics cache. If a table entry is hit, the forwarding statistics of the service message may be further extracted, including but not limited to: the cumulative number of bytes of the offloaded traffic, the number of messages, the forwarding path identifier (such as the tunnel ID), the QoS parameter application status (such as the DSCP mark value), and the current forwarding rate. If the table entry is not hit, an error indicator such as "flow table entry does not exist" may be returned.

[0069] For example, in step S730, after extracting the forwarding information of the service message, the first communication device may encapsulate the extracted forwarding information into a traffic status response message (i.e., an information message) and send the message to the UPF node. The message may include fields such as a five-tuple index, a statistical data timestamp, and resource usage (such as the remaining lifetime of a flow table entry), so that the UPF node can adjust the traffic scheduling policy (such as updating the offload quota and optimizing the forwarding path) based on the information.

[0070] For example, in response to detecting the end of the forwarding process for a service packet, the first communications device may send a service termination notification to the UPF node. Subsequently, in response to receiving a flow deletion instruction sent by the UPF node in response to the service termination notification, the first communications device may delete the corresponding traffic offload rule from the terminal service flow table in accordance with the flow deletion instruction. That is, after forwarding a service packet, when the first communications device detects the end of the forwarding process for the service packet, it may send a service termination notification to the UPF node. Upon receiving the flow deletion instruction sent by the UPF node in response to the service termination notification, the first communications device may delete the corresponding traffic offload rule from the terminal service flow table in accordance with the flow deletion instruction.

[0071] Exemplarily, when the first communication device deletes the corresponding traffic unloading rule in the terminal service flow table according to the flow deletion instruction, it can delete the traffic unloading rule in the terminal service flow table that matches the five-tuple index according to the five-tuple index in the flow deletion instruction. Specifically, the logic of the first communication device executing the flow deletion instruction is as follows: When the first communication device receives the flow deletion instruction sent by the UPF node, it first parses the five-tuple index information carried in the instruction (including source IP, destination IP, source port, destination port, protocol type), and uses this as a query key to match the local terminal service flow table. Since the terminal service flow table uses the five-tuple and vlan tag as unique identifiers to store traffic unloading rules, the first communication device locates the corresponding table entry through hash search and deletes the table entry. Subsequently, the first communication device sends a flow deletion confirmation message to the UPF node.

[0072] Exemplarily, before deleting the corresponding traffic offloading rule in the terminal service flow table according to the flow deletion instruction, the first communication device may also send a traffic message containing offloading traffic statistics information to the UPF node, and the offloading traffic statistics information includes the traffic information of the terminal service flow table. Specifically, when the first communication device receives the flow deletion instruction, it can first parse the table item that matches the five-tuple index in the terminal service flow table, extract the historical statistical data corresponding to the traffic offloading rule (such as the cumulative number of offloading bytes, number of messages, duration, forwarding path occupancy time, number of QoS policy applications, etc.), encapsulate it into a traffic message and send it to the UPF node. After receiving the traffic message, the UPF node can synchronously update the global traffic ledger and perform subsequent actions (such as releasing the tunnel resources occupied by the flow) based on the traffic statistics results to ensure the continuity of the flow deletion operation.

[0073] For example, when the flow table information of the UPF node is updated (such as policy adjustment or rule change), an update instruction can be sent to the first communication device to enable it to perform any of the following operations: (1) Sending messages for re-matching: The in-transit service messages that are currently being processed and match the old flow table rules are sent back to the UPF node, and re-matched and forwarded based on the new flow table rules; (2) Deleting the flow table: Remove the old table entries corresponding to the rules before the update in the local terminal service flow table to avoid subsequent messages from mistakenly matching expired rules, and ensure that the traffic offloading logic is synchronized with the UPF global policy in real time.

[0074] Exemplarily, the first communication device receives a new tunnel classification table sent by the UPF node, and the first communication device can update the local tunnel classification table according to the new tunnel classification table. For example, when the network-side network element (such as SMF) actively reconfigures the tunnel table, or the user manually changes the tunnel parameters through the management interface, the UPF node generates a new tunnel classification table based on the configuration change and sends it to the first communication device. After the first communication device completes the local table entry update, it can synchronously return an update confirmation response to the UPF to ensure that subsequently received messages are classified and processed according to the new tunnel rules.

[0075] See also Figure 8 , Figure 8 This is a schematic diagram of an application environment provided by an embodiment of the present application. Figure 8In the example, the first communication device is used as a remote switch. Both remote switches 1 and 2 have custom programming modules and are equipped with large-capacity DDR memory, which supports users to expand functions through programming. The two types of remote switches can interact with the service processing unit in the UPF node. The interaction process is as follows: First, after the remote switch loads the code logic of the custom programming module, it can identify the control messages and service messages that the UPF node interacts with itself. After receiving such interaction messages, the remote switch can rely on the high-speed reading and writing capabilities of the DDR memory to implement the creation, query, and deletion of entries such as the tunnel classification table and the terminal service flow table (corresponding to Figure 9 ). When a service message is identified, the remote switch can first perform message parsing (e.g., extracting the message's five-tuple information) and preliminary classification through the basic functional modules. Based on the parsed information, the remote switch then queries the terminal service flow table in the local DDR memory. If a target flow table rule is matched, traffic offload processing (i.e., service message forwarding, e.g., forwarding the service message to a specified path according to the rule) is performed according to the target flow table rule.

[0076] See also Figure 10 , Figure 10 This is a schematic diagram of a ground-to-sky application scenario provided by an embodiment of the present application. Figure 10 In this example, the first communication device is used as an example of an offload switch. In the ground-to-ground integrated architecture, the ground core network deploys UPF nodes and offload switches. The UPF nodes communicate with the offload switch, data network nodes, and gateway stations respectively, and the gateway stations are synchronously connected to the onboard UPF. User traffic packets sent by UE devices are first connected to the onboard UPF and then backhauled to the ground UPF via the gateway station. After the ground UPF forwards the traffic to the offload switch, the offload switch identifies and intercepts the service traffic (service message collection) that can be processed locally based on the traffic offload rules in the local terminal service flow table, and forwards it directly to the data network node, avoiding traffic backhaul for onboard processing, thereby reducing the load on the onboard UPF node.

[0077] See also Figure 11 , Figure 11This is a schematic diagram of the control message format provided by an embodiment of the present application. The encoding format of the control message exchanged between the UPF node and the first communication device includes an IP header, a message type, and a message content area. Among them, the IP header carries the control plane source IP and destination IP configured by the user, as well as a preset reserved protocol field (which can be used to distinguish the transmission protocol type); the message type is used to identify the control function of the message, covering internal signaling instruction types such as keep-alive, tunnel table delivery / deletion, flow table delivery / deletion, and traffic query; the message content area is subdivided into an index area and a content area, wherein the index area can be used to locate the target configuration item, and the content area can encapsulate specific signaling parameters (such as tunnel encapsulation protocol, peer address, or flow table matching rules, action instructions) to realize parameterized transmission of control logic.

[0078] See also Figure 12 , Figure 12 This is a schematic diagram of the interaction between the UPF node and the first communication device provided by an embodiment of the present application. Figure 12 In the figure, the first communication device is used as a remote unloading switch (corresponding to the remote unloading switches 1 and 2 in the figure), and the UPF node establishes a distributed docking architecture with the remote unloading switch through multiple service processing units. When the remote unloading switch receives the service load message and queries the terminal service flow table, if the matching fails due to the first transmission of the new service flow, the message metadata such as the five-tuple can be uploaded to the corresponding service processing unit through the control channel. After receiving the metadata, the service processing unit parses the service characteristics (such as protocol type) and matches the global policy, generates a new tunnel table and service flow table, and sends it to the remote unloading switch through control signaling. Subsequent received messages are classified and unloaded and forwarded through the tunnel classification table and the terminal service flow table. When the service processing unit adjusts and updates the flow table information, it can synchronously send an update instruction to the remote switch to enable it to perform any of the following operations: send the in-transit message being processed to the UPF node for re-matching according to the new rules; delete the old flow table entries that have failed locally to release resources. If the remote switch detects that the offload quota is exhausted (e.g., insufficient remaining space in the flow table), it can send a message containing information such as the currently offloaded traffic data to the service processing unit, triggering quota reallocation and rule issuance. When the remote offload switch completes service message forwarding, it can report the flow information and traffic statistics such as the five-tuple, tunnel ID, and cumulative byte count of the service flow to the corresponding service processing unit so that the UPF node can update the policy.

[0079] See also Figure 13 , Figure 13This is a schematic diagram of the interaction process between the UPF node and the first communication device provided by an embodiment of the present application. The interaction process between the UPF node and the first communication device starts with periodic keep-alive detection. Specifically, the UPF node can send a keep-alive detection message to the first communication device at a frequency of 1 time / second. The first communication device confirms that the communication link between the two is available by returning a keep-alive confirmation response carrying link status information (such as response time, check value). When the link is unobstructed, the UPF node transmits the tunnel table information to the first communication device one by one and creates a local tunnel classification table to provide basic rules for subsequent message classification. When the first communication device receives the first packet payload message and queries the terminal service flow table, if there is no matching table entry due to the first transmission of a new service flow, the message can be sent to the UPF node. After learning the message characteristics, the UPF node can generate and send the service flow table information containing the traffic unloading rules that match the message. When there is no local flow table, the first communication device can create a terminal service flow table using a hash table structure, and then perform traffic unloading according to the rules in the table. If the first communication device detects during the processing that the local unloading quota has been reached (such as the flow table item occupancy rate exceeds the preset threshold), it can immediately stop the traffic unloading and report the exhaustion message carrying the remaining quota and the unloaded traffic statistics to the UPF, triggering the UPF node to regenerate and send the service flow table adapted to the current resource status. After receiving the flow table update instruction, the first communication device parses the new rules in the signaling and updates the local table items. It can also synchronously report the traffic information containing the updated terminal service flow table to the UPF node. When receiving the traffic query message from the UPF node, the first communication device can quickly retrieve the terminal service flow table based on the five-tuple index carried by the query, extract the statistics of the corresponding flow table (including the cumulative number of bytes unloaded by the message, the forwarding path, etc.) and report it. If the first communication device receives a traffic deletion instruction, it accurately locates the hash table item corresponding to the terminal service flow table, performs the deletion operation and reports the traffic information of the terminal service flow table to ensure that the flow table information at both ends is synchronized in real time. It should be noted that the specific execution details in the above process have been elaborated in detail in the previous embodiments. Taking the link "UPF node transmits tunnel table information to the first communication device one by one and creates a local tunnel classification table" as an example, its complete implementation logic is described in the embodiment as follows: the UPF node parses its own global configuration information, generates a tunnel table containing complete tunnel classification rules, and sends all locally configured tunnel table addresses to the first communication device. To ensure reliability, the tunnel table is issued one by one and supplemented by a response confirmation mechanism. That is, each time the UPF node sends a tunnel table entry, it must wait for the first communication device to return a successful reception confirmation of the entry before triggering the issuance of the next tunnel table entry. If no confirmation is received within the timeout or a failure feedback is received, the entry is retransmitted. After the first communication device receives all tunnel table entries, it merges them with the locally preset initial table (such as the basic rule table) to form the final tunnel classification table used for message classification and parsing.Similarly, the specific implementation details of other process steps (such as flow table update, quota reporting, etc.) can be found in the corresponding descriptions in the above embodiments. To avoid repetition, the underlying implementation logic of each link will not be repeated in this process.

[0080] In addition, an embodiment of the present application also discloses a communication device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the message processing method as in any of the previous embodiments.

[0081] In addition, an embodiment of the present application further discloses a computer-readable storage medium, which stores computer-executable instructions for executing the message processing method in any of the previous embodiments.

[0082] In addition, an embodiment of the present application also discloses a computer program product, including a computer program or computer instructions, which are stored in a computer-readable storage medium. The processor of the device reads the computer program or computer instructions from the computer-readable storage medium, and the processor executes the computer program or computer instructions, so that the device executes the message processing method as in any of the previous embodiments.

[0083] Those skilled in the art will appreciate that all or some of the steps and systems in the method disclosed above can be implemented as software, firmware, hardware, and appropriate combinations thereof. Some physical components or all physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, and the computer-readable medium can include computer storage media (or non-transitory media) and communication media (or temporary media). As known to those skilled in the art, the term computer storage media is included in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data) and is volatile and non-volatile, removable, and non-removable. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROM, digital versatile disks (DVD), or other optical disk storage, magnetic cassettes, magnetic tapes, disk storage, or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, as is well known to those skilled in the art, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0084] The above is a specific description of the preferred implementation of the present application, but the present application is not limited to the above implementation mode. Technical personnel familiar with the field can also make various equivalent modifications or substitutions without violating the spirit of the present application. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present application.

Claims

1. A message processing method, applied to a first communication device, comprising: Receive service messages forwarded by the user plane function UPF node; The service message is forwarded according to the tunnel classification table and the terminal service flow table, wherein the tunnel classification table and the terminal service flow table are converted according to the local global configuration information of the UPF node.

2. The message processing method according to claim 1, characterized in that: The forwarding of the service message according to the tunnel classification table and the terminal service flow table includes: Identify the service message according to the tunnel classification table to obtain the message type of the service message; Selecting a target traffic unloading rule from a plurality of traffic unloading rules in the terminal service flow table according to the message type of the service message; The service message is forwarded according to the target traffic offloading rule.

3. The message processing method according to claim 1, characterized in that: Before receiving the service message forwarded by the user plane function UPF node, the method includes: Receive a keep-alive detection message sent by the UPF node, where the keep-alive detection message is used to verify whether the communication link between the first communication device and the UPF node is in an available state.

4. The message processing method according to claim 3, characterized in that: The method further comprises one of the following: In response to the communication link being in an available state, sending a confirmation response to the keep-alive detection message to the UPF node, where the confirmation response is used to indicate that the communication link is available; In response to the communication link being in an unavailable state, an abnormal message for the keep-alive detection message is sent to the UPF node, where the abnormal message is used to indicate that the communication link is unavailable.

5. The message processing method according to claim 1, characterized in that: The method further comprises: In response to exhaustion of a local offload quota of the first communication device, sending an offload quota exhaustion message to the UPF node; In response to receiving a new terminal service flow table sent by the UPF node after being updated based on the unloading quota exhaustion message, the local terminal service flow table is updated according to the new terminal service flow table.

6. The message processing method according to claim 1, characterized in that: The method further comprises: Receive a query message carrying quintuple index information sent by the UPF node; Extracting forwarding information of the service message based on the quintuple index; Send an information message containing the forwarding information to the UPF node.

7. The message processing method according to claim 1, characterized in that: After forwarding the service message, the method further includes: In response to detecting that the forwarding process of the service message is completed, sending a service termination notification to the UPF node; In response to receiving the flow deletion instruction sent by the UPF node according to the service termination notification, the corresponding traffic unloading rule in the terminal service flow table is deleted according to the flow deletion instruction.

8. The message processing method according to claim 7, characterized in that: The deleting the corresponding traffic unloading rule in the terminal service flow table according to the flow deletion instruction includes: According to the five-tuple index in the flow deletion instruction, the traffic unloading rule matching the five-tuple index in the terminal service flow table is deleted.

9. The message processing method according to claim 8, characterized in that: Before deleting the traffic offloading rule matching the quintuple index in the flow deletion instruction in the terminal service flow table, the method further includes: A traffic message containing offload traffic statistical information is sent to the UPF node, where the offload traffic statistical information includes traffic information of the terminal service flow table.

10. The message processing method according to claim 1, characterized in that: The method further comprises: In response to the service message not matching the traffic unloading rule of the terminal service flow table, the service message is reported to the UPF node.

11. The message processing method according to claim 1, wherein: The method further comprises: In response to receiving the new tunnel classification table sent by the UPF node, the local tunnel classification table is updated according to the new tunnel classification table.

12. A communication device, characterized in that: include: at least one processor; at least one memory for storing at least one program; When at least one of the programs is executed by at least one of the processors, the message processing method according to any one of claims 1 to 11 is implemented.

13. A computer-readable storage medium storing computer-executable instructions, characterized in that: The computer-executable instructions are used to execute the message processing method described in any one of claims 1 to 11.

Images