A data processing method, device and readable storage medium

Abstract

The application discloses a data processing method, device and readable storage medium. The method comprises the following steps: when an initial request message in a packet forwarding control protocol message format is acquired, acquiring a node identifier of a first network node and a message identifier of the initial request message, and generating encryption verification data based on the node identifier and the message identifier; adding the encryption verification data to the initial request message to obtain a target request message; and sending the target request message to a second network node, wherein the target request message is used to instruct the second network node to perform message checking on the target request message based on the encryption verification data carried in the target request message, to obtain a message checking result corresponding to the target request message, and to perform message processing based on the message checking result. The application can meet the requirement of flexible deployment of a session management network element, and improve the security of the packet forwarding control protocol.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a data processing method, apparatus, and readable storage medium. Background Technology

[0002] The Packet Forwarding Control Protocol (PFCP) is an application-layer protocol based on the User Datagram Protocol (UDP). It is one of the main new protocols introduced for the 5G core network and is also used in the 4G core network (i.e., LTE (Long Term Evolution) EPC) to separate the control plane (CP) and user plane (UP, also known as the data plane). In the 5G core network, the Session Management Function (SMF) and User Plane Function (UPF) can interact using the PFCP protocol.

[0003] In relevant PFCP protocol applications, different SMFs and different UPFs are identified by Node IDs (i.e., node identifiers). Node IDs can be the IP (Internet Protocol) address of the corresponding network element or the FQDN (Qualified Domain Name). The Node ID is carried in PFCP association establishment, update, release, node reporting, and session establishment request messages to indicate the network element to which the request message belongs. To ensure message security and avoid abnormal scenarios such as spoofing attacks or configuration errors, the receiver of the PFCP request message will perform a matching and verification of the source IP and Node ID upon receiving the request message. If the match fails, appropriate exception handling is performed. When a network attacker obtains the relevant IP and Node ID, the source IP verification mechanism cannot defend against attacks that involve double spoofing of both IP and Node ID, thus reducing the security of the PFCP protocol. Summary of the Invention

[0004] This application provides a data processing method, apparatus, and readable storage medium that can meet the needs of flexible deployment of session management network elements and improve the security of packet forwarding control protocols.

[0005] One embodiment of this application provides a data processing method, which is executed by a first network node, including:

[0006] When an initial request message with a packet forwarding control protocol message format is obtained, the node identifier of the first network node and the message identifier of the initial request message are obtained, and encrypted verification data is generated based on the node identifier and the message identifier.

[0007] Add encrypted verification data to the initial request message to obtain the target request message;

[0008] The target request message is sent to the second network node. The target request message is used to instruct the second network node to perform message verification on the target request message based on the encrypted verification data carried in the target request message, obtain the message verification result corresponding to the target request message, and process the message based on the message verification result.

[0009] One embodiment of this application provides a data processing method, which is executed by a second network node, including:

[0010] Receive the target request message sent by the first network node; the target request message is obtained by the first network node adding encrypted verification data to the initial request message with the packet forwarding control protocol message format; the encrypted verification data is generated by the first network node based on the node identifier of the first network node and the message identifier of the initial request message;

[0011] Obtain the encrypted verification data carried in the target request message, perform message verification on the target request message based on the encrypted verification data, obtain the message verification result corresponding to the target request message, and process the message based on the message verification result.

[0012] One embodiment of this application provides a data processing apparatus, including:

[0013] The encryption module is used to obtain the node identifier of the first network node and the message identifier of the initial request message when an initial request message with a packet forwarding control protocol message format is obtained, and to generate encrypted verification data based on the node identifier and the message identifier.

[0014] The update module is used to add encrypted verification data to the initial request message to obtain the target request message;

[0015] The sending module is used to send the target request message to the second network node. The target request message is used to instruct the second network node to perform message verification on the target request message based on the encrypted verification data carried in the target request message, obtain the message verification result corresponding to the target request message, and perform message processing based on the message verification result.

[0016] One embodiment of this application provides a data processing apparatus, including:

[0017] The receiving module is used to receive the target request message sent by the first network node; the target request message is obtained by the first network node adding encrypted verification data to the initial request message with the packet forwarding control protocol message format; the encrypted verification data is generated by the first network node based on the node identifier of the first network node and the message identifier of the initial request message.

[0018] The verification module is used to obtain the encrypted verification data carried in the target request message, perform message verification on the target request message based on the encrypted verification data, obtain the message verification result corresponding to the target request message, and perform message processing based on the message verification result.

[0019] One embodiment of this application provides a network element device, including: a processor and a memory;

[0020] The processor is connected to a memory, which stores a computer program. When the computer program is executed by the processor, the network element device performs the method provided in the embodiments of this application.

[0021] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a network element device having the processor performs the method provided in this application.

[0022] One embodiment of this application provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a network element device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the network element device to perform the method provided in this application embodiment.

[0023] In this embodiment, when a first network node receives an initial request message with a packet forwarding control protocol message format, it can obtain its node identifier and the message identifier of the initial request message. Based on the obtained node identifier and message identifier, it can generate encrypted verification data. Furthermore, the first network node can add this encrypted verification data to the initial request message to obtain a target request message. This target request message can then be sent to a second network node. Subsequently, the second network node can perform message verification on the target request message based on the encrypted verification data carried by the target request message, thereby obtaining the message verification result corresponding to the target request message. Based on this message verification result, message processing can be performed. Here, the first network node refers to the initiator of the request message, which can be a session management network element or a user plane network element; while the second network node refers to the receiver of the request message, which can also be a user plane network element or a session management network element. Therefore, this embodiment does not employ the source IP verification mechanism in the original packet forwarding control protocol and does not limit the node identifier configured on the first network node, thus meeting the flexible deployment requirements of the session management network element (e.g., it can be deployed in the cloud). In addition, by using newly added encrypted verification data for message verification, problems such as large-scale business anomalies caused by configuration errors can be avoided, and network attackers can also defend against spoofing attacks on network nodes, thereby improving the security of the packet forwarding control protocol. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of a system architecture provided in an embodiment of this application;

[0025] Figure 2 This is a schematic diagram of a data processing scenario provided in an embodiment of this application;

[0026] Figure 3 This is a flowchart illustrating a data processing method provided in an embodiment of this application;

[0027] Figure 4 This is a flowchart illustrating a data processing method provided in an embodiment of this application;

[0028] Figure 5 This is a schematic diagram of the interaction flow of a data processing method provided in an embodiment of this application;

[0029] Figure 6 This is an interactive schematic diagram of a coupling establishment process provided in an embodiment of this application;

[0030] Figure 7 This is an interactive schematic diagram of a coupling establishment process provided in an embodiment of this application;

[0031] Figure 8This is an interactive schematic diagram of a coupling update process provided in an embodiment of this application;

[0032] Figure 9 This is an interactive schematic diagram of a coupling update process provided in an embodiment of this application;

[0033] Figure 10 This is an interactive schematic diagram of a node reporting process provided in an embodiment of this application;

[0034] Figure 11 This is an interactive schematic diagram of a coupling release process provided in an embodiment of this application;

[0035] Figure 12 This is an interactive schematic diagram of a session establishment process provided in an embodiment of this application;

[0036] Figure 13 An interactive schematic diagram of a session modification process provided in the application embodiment;

[0037] Figure 14 This is an interactive schematic diagram of a session reporting process provided in an embodiment of this application;

[0038] Figure 15 This is an interactive schematic diagram of a session deletion process provided in the application embodiment;

[0039] Figure 16 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0040] Figure 17 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0041] Figure 18 This is a schematic diagram of the structure of a network element device provided in an embodiment of this application;

[0042] Figure 19 This is a schematic diagram of the structure of a data processing system provided in an embodiment of this application. Detailed Implementation

[0043] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0044] The technical solutions of this application embodiment can be applied to various communication systems, such as: Global System for Mobile communication (GSM), Code Division Multiple Access (CDMA) system, Wideband Code Division Multiple Access (WCDMA) system, General Packet Radio Service (GPRS), Long Term Evolution (LTE) system, LTE Frequency Division Duplex (FDD) system, LTE Time Division Duplex (TDD) system, Universal Mobile Telecommunications System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX) system, 4th Generation (4G) mobile communication system, future 5th Generation (5G) mobile communication system, or subsequent evolved mobile communication systems, etc.

[0045] Please see Figure 1 , Figure 1 This is a schematic diagram of a system architecture provided in an embodiment of this application. In mobile communication, such as... Figure 1 The system architecture shown may include an application server cluster, a user equipment cluster, a radio access network (RAN), and a core network. The application server cluster may include one or more application servers; the number of application servers in the cluster is not limited here. For example, ... Figure 1 As shown, the multiple application servers may specifically include application server 100a, application server 100b, ..., application server 100m. It should be understood that communication connections may exist between the application servers; for example, there is a communication connection between application server 100a and application server 100b.

[0046] It is understood that the application server in this application embodiment can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud database, cloud services, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and artificial intelligence platforms.

[0047] like Figure 1 In the system architecture shown, the user equipment cluster can include one or more user equipments; the number of user equipments in the user equipment cluster is not limited here. For example, as Figure 1 As shown, the multiple user equipments may specifically include user equipment 200a, user equipment 200b, ..., user equipment 200n. It should be understood that communication connections may exist between user equipments; for example, a communication connection exists between user equipment 200a and user equipment 200b.

[0048] It is understood that the user equipment (UE) in the embodiments of this application may include terminal devices (e.g., smartphones, tablets, laptops, desktop computers, PDAs), access terminals, terminals in V2X (Vehicle to X) communication, user units, user stations, mobile stations, mobile stations, remote stations, remote terminals, mobile devices, user terminals, wireless communication devices, user agents, or user devices. The user equipment may also be a cellular phone, cordless phone, Session Initiation Protocol (SIP) phone, Wireless Local Loop (WLL) station, Personal Digital Assistant (PDA), handheld device with wireless communication capabilities, computing device or other processing device connected to a wireless modem, in-vehicle device, wearable device (e.g., smartwatches, smart bracelets), smart computer, etc., terminal devices in future 5G networks or terminal devices in future evolved Public Land Mobile Networks (PLMNs), etc., and the embodiments of this application do not limit this. User equipment may also include V2X devices, such as vehicles or on-board units (OBUs) within vehicles. User equipment can be fixed-location or mobile.

[0049] like Figure 1 In the system architecture shown, multiple access network elements (also known as access devices, for example) can be deployed in the wireless access network. Figure 1The access network element 300a in the network is mainly responsible for the access and management of user equipment on the radio side. It is understandable that... Figure 1 The access network element 300a shown can be an access device for user equipment to access the mobile communication system wirelessly. For example, it can be a base station NodeB, an evolved NodeB, a base station (gNodeB, gNB) in a 5G mobile communication system, a base station in a future mobile communication system, or an access node in a Wireless Fidelity (WiFi) system. It can also be a wireless controller in a Cloud Radio Access Network (CRAN) scenario, or it can be a relay station, access point, vehicle-mounted equipment, wearable devices, and network equipment in a future 5G network or a network equipment in a future evolved PLMN (Public Land Mobile Network). The embodiments of this application do not limit the specific technology and specific equipment form adopted by the access network element.

[0050] In this context, different user equipment (UE) devices within a UE cluster can correspond to different access network elements, or different UE devices can correspond to the same access network element. Here, the access network element corresponding to each UE device is not limited. This embodiment will use access network element 300a as an example to illustrate this. Figure 1 As shown, any user equipment in the user equipment cluster can have a communication connection with access network element 300a. For example, there is a communication connection between user equipment 200a and access network element 300a. The communication connection method is not limited; it can be via 4G wireless access or 5G wireless access, etc. This application does not impose any restrictions on this.

[0051] like Figure 1 In the system architecture shown, the core network can deploy a series of core network elements (also known as core network equipment, network functions, etc.). These core network elements work together to perform authentication, accounting, and mobility management for user equipment. Optionally, core network elements may include a Mobility Management Entity (MME), a Broadcast Multicast Service Center (BMSC), or corresponding functional entities in the 5G system (5GS), such as session management network elements and user plane network elements.

[0052] Among them, core network elements and access network elements can be independent and different physical devices, or the functions of core network elements and access network elements can be integrated into the same physical device, or a physical device can integrate some of the functions of core network elements and some of the functions of access network elements.

[0053] It should be noted that the core network elements involved in the embodiments of this application mainly include user plane network elements (e.g., Figure 1 User plane network element 300b) and session management network element (e.g., Figure 1 The session management network element (300c) is used in this section. Other core network elements (such as policy control network elements and mobility management network elements) are not listed one by one. Therefore, only these two types of network elements are briefly introduced here, as follows:

[0054] (1) UPF (User Plane Function): Primarily responsible for data routing and forwarding on the user plane of the mobile core network, and interconnecting with external data networks (DNs, such as operator services, the Internet, or third-party services). UPF is the main module for processing user plane data in the 5G core network. In the embodiments of this application, UPF can also be referred to as a user plane network element or user plane network element.

[0055] (2) SMF (Session Management Function): Primarily responsible for session establishment, modification, and release; user plane selection and control; and UE IP address allocation. In this embodiment, SMF can also be referred to as the session management network element.

[0056] It should be noted that the aforementioned user plane network element, session management network element, and access network element are merely names, and these names do not limit the device itself. For example, a session management network element can also be called a session management function entity, or a session management function, etc. This application does not limit the device name. In 5G networks and other future networks, the network elements mentioned in the embodiments of this application may also have other names, and there is no limitation on this.

[0057] Optionally, the user plane network element and the session management network element can be separate network elements, or they can be implemented by multiple network elements, or they can be a functional module within a network element. This application embodiment does not limit this.

[0058] like Figure 1As shown, any application server in the application server cluster can have a communication connection (e.g., a leased line connection) with the user plane network element 300b, so that each application server can interact with the user plane network element 300b through the communication connection. For example, there is a communication connection between application server 100a and user plane network element 300b.

[0059] It should be noted that a 5G system can contain multiple reference points. Here, a reference point refers to the mutual access interface agreed upon between two network functions (network elements or functional entities) or between a network function and an external device. Different network functions can interact through the agreed reference points. For example, access network elements and user plane network elements communicate through reference point N3, user plane network elements and session management network elements communicate through reference point N4, and user plane network elements and data networks communicate through reference point N6.

[0060] It should be noted that, as Figure 1 The system architecture shown may also include a bearer network (i.e., a transmission network). Figure 1 (Not shown in the diagram), where the bearer network can consist of a series of operator switching and routing equipment, mainly used to transmit control signaling and user data between the radio access network and the core network.

[0061] Optional, Figure 1 The system architecture shown can be applied to 4G networks, 5G networks, and other possible future networks. This application does not specifically limit this.

[0062] It is understandable that, such as Figure 1The system architecture shown can be applied to business scenarios supporting edge computing (such as Mobile Edge Computing, or MEC). In this scenario, the application servers in the application server cluster can be either Edge Application Servers (EAS) or central application servers. Edge computing refers to a platform that integrates network, computing, storage, and application core capabilities at the network edge, close to the source of objects or data, to provide edge intelligent services locally, meeting the key needs of industry digitalization in areas such as agile connectivity, real-time business, data optimization, application intelligence, security, and privacy protection. Edge computing enables operators and third-party services to be hosted closer to the user's access point, thereby achieving efficient service delivery by reducing end-to-end latency and load on the transmission network. It is understandable that, due to the high speed, low latency, and massive connectivity of fifth-generation mobile communication technology (5G), 5G service requirements necessitate pushing services as far down as possible to the network edge to achieve local traffic offloading and reduce network latency caused by network transmission and multi-level service forwarding. In other words, the rollout of 5G has increased the demand for edge computing. Furthermore, the combination of edge computing and 5G can help networks address bandwidth, latency, and security issues when faced with sudden and sustained surges in traffic. Therefore, for ease of understanding, the following explanation uses the above system architecture applied to a 5G edge computing scenario as an example.

[0063] like Figure 1As shown, in a 5G network, suppose any user equipment in the aforementioned user equipment cluster (for example, any one of user equipment 200a, user equipment 200b, or user equipment 200n) wants to access a data network outside the mobile communication network, such as the Internet or WAP (Wireless Application Protocol). If a user equipment (UE) can access a network such as a wireless application protocol (WAPT) or an enterprise intranet, it can initiate an access request. Access network element 300a can forward the requested service flow (e.g., audio and video streams generated by the application client on the UE) to a core network element UPF (e.g., the user plane element 300b mentioned above) in the 5G core network (i.e., 5GCore, or 5GC). After forwarding through the core network element UPF, the service flow can be sent to an application server (e.g., application server 100a mentioned above) in an external data network. Other core network elements in the 5G core network (such as core network element SMF, e.g., session management element 300c mentioned above) are mainly control plane elements, responsible for processing signaling, implementing mobility management, session management, policy control, etc., thereby controlling the entire process. Here, the service flow can also be called service data or user data, and can be transmitted in the form of data packets, data packets, etc. This application embodiment does not limit this.

[0064] It should be noted that in edge computing scenarios, an application service may consist of multiple edge application servers (such as those typically deployed at different sites) Figure 1Application servers 100a, 100b, and 100m (shown in the diagram) provide services. These multiple edge application servers carrying services may use a single IP address (Internet Protocol Address) or different IP addresses. Typically, an application server for a particular application client may be deployed in a central application server or an edge application server. To route the application client's traffic to an edge application server, the user device needs to know the IP address of the edge application server providing the service. The user device can perform discovery to obtain the IP address of a suitable edge application server (e.g., the closest edge application server to the user device, such as application server 100a mentioned above). This allows the traffic flow to be routed by the user plane network element 300b to the edge application server corresponding to that IP address, optimizing service latency, traffic routing paths, and user service experience. Therefore, edge application server discovery is the process by which the user device uses the Domain Name System (DNS) to find the IP address of a suitable edge application server. The Domain Name System (DNS) is an Internet service that acts as a distributed database mapping domain names to IP addresses, enabling users to access the Internet more conveniently. It is understandable that the user plane network element 300b can be deployed flexibly, such as being deployed locally in the business area, thereby shortening the service latency.

[0065] The 5G core network supports PDU (Packet Data Unit) connection services between user equipment and the data network. PDU connection services are manifested through PDU sessions (i.e., packet data unit sessions). A PDU session refers to a data path for communication between a user equipment and the data network. In other words, by establishing, modifying, or releasing PDU sessions through session management procedures, user equipment can achieve data access functionality. Taking user equipment 200a as an example, assuming user equipment 200a wants to obtain a certain edge application service, it can initiate a PDU session establishment request to the session management element 300c. During the PDU session establishment process, the session management element 300c can obtain edge application server deployment information through PDU session-related policy information provided by the Policy Control Function (PCF). Then, the session management element 300c can select the appropriate DNS server according to relevant rules and provide the address of that DNS server to user equipment 200a. Furthermore, user equipment 200a can send a DNS query request to the DNS server. The DNS server can then find the IP address of the appropriate edge application server and return it to user equipment 200a. User equipment 200a can then use the received IP address as its service access address to access the corresponding edge application server. For example, assuming the process ultimately finds application server 100a, application server 100a can provide user equipment 200a with corresponding edge application services, such as local caching, local forwarding for enterprise networks, optimization for video / game services, location services, and vehicle-to-everything (V2X) connectivity.

[0066] It's understandable that for ultra-high bandwidth services, mobile edge computing (such as...) can be used... Figure 1 The deployment of application server clusters (as shown) in a nearby location enables the processing of ultra-high bandwidth traffic locally, which can greatly reduce the impact of high bandwidth on the backbone network. Typical scenarios include live broadcasts of stadium games, live broadcasts of concerts, and mobile content distribution.

[0067] In the control plane, the session management network element and the user plane network element are interconnected via the N4 interface (i.e., the N4 reference point) and use the Packet Forwarding Control Protocol (PFCP) to transmit control information messages (i.e., PFCP messages). The session management network element can control the user plane network element to create and modify PFCP sessions through PFCP messages, instructing the packet detection rules, forwarding rules, QoS (Quality of Service) enforcement rules, and usage reporting rules of the PFCP session. This enables the user plane network element to perform functions such as forwarding, QoS, and billing for 5G user data packets. The user plane network element can also report the idle traffic status, billing data, and cache reports of the 5G user terminal through PFCP messages, triggering the session management network element to perform subsequent processing based on the current state of the user equipment.

[0068] The packet forwarding control protocol is based on the UDP / IP protocol. By configuring the PFCP IP address, a PFCP association (or simply association) can be established between the session management network element 300c and the user plane network element 300b, enabling the session management network element 300c to subsequently use the resources of the user plane network element 300b, i.e., establishing a PFCP session. N4 association management can include PFCP association establishment, PFCP association update, PFCP association release, and PFCP heartbeat detection. Furthermore, only after the session management network element 300c and the user plane network element 300b successfully establish a PFCP association through the N4 interface can a PFCP session for that PFCP association be established on the user plane network element 300b, and related control information be transmitted by sending PFCP request messages (i.e., PFCP packets). N4 session management can include PFCP session establishment, modification, and release.

[0069] It should be noted that the above PDU session establishment process also includes the establishment and modification process of the PFCP session. Through the PFCP session establishment process, the session management network element 300c can send PDR (Packet Detection Rule), FAR (Forwarding Action Rule), URR (Usage Reporting Rule), QER (QoS Enforcement Rule) and other information to the user plane network element 300b to realize packet data detection and forwarding processing, and at the same time complete the allocation of GTP-U (GPRS (General Packet Radio Service) Tunneling Protocol User plane function) tunnel resources on the core network side to realize the transmission of uplink service flows on user equipment 200a. Among them, URR and QER are optional. Through the PFCP session modification process, the session management network element 300c can provide access network tunnel information and corresponding forwarding rules to the user plane network element 300b. Through this process, the downlink channel is established, and the user plane network element 300b can send the downlink packets buffered for the PDU session to the user equipment 200a.

[0070] In the PFCP protocol, user plane network elements can also be called user plane functions or user plane nodes (i.e., network nodes with user plane functions), and can support one or more PFCP entities. Similarly, in the packet forwarding control protocol, session management network elements can also be called control plane functions or control plane nodes (i.e., network nodes with control plane functions), and can support one or more PFCP entities. In the embodiments of this application, user plane nodes and control plane nodes can be collectively referred to as network nodes (i.e., PFCP Nodes). Each network node can be identified by a unique node identifier (i.e., Node ID), which can be set to a corresponding FQDN, IP address, or other agreed-upon information. This embodiment of the application does not limit this. For ease of distinction, in this embodiment, the network node sending the request message (PFCP message) can be referred to as the first network node, and similarly, the network node receiving the request message can be referred to as the second network node. It is understood that the first and second network nodes have equivalent but different functions. For example, when the session management network element 300c initiates a connection establishment request message to the user plane network element 300b, the session management network element 300c can be considered the first network node, and the user plane network element 300b can be considered the second network node. It is understood that, depending on the actual application scenario, the first and second network nodes can be interchanged at any time. That is, in scenario A, a network node can act as the first network node, while in scenario B, the same network node can act as the second network node.

[0071] Furthermore, each request message sent by a network node carries a corresponding message identifier to identify different request messages. It can be understood that in the same PFCP session, the message identifier carried by each request message can be unique. The message identifier can be a specified message sequence number or a randomly generated message sequence number, or it can be a message sequence number generated based on a specific message identifier generation strategy, or it can be other agreed information. This application embodiment does not limit this.

[0072] This application provides an improved method for the PFCP protocol, which enhances the flexibility and security of the PFCP protocol. Specifically, when a first network node receives an initial request message with a Packet Forwarding Control Protocol message format, it can obtain the node identifier of the first network node and the message identifier of the initial request message. Then, it can generate encrypted verification data based on the obtained node identifier and message identifier (e.g., encrypting the node identifier and the message identifier). Further, the first network node can add the encrypted verification data to the initial request message to obtain a target request message for sending to a second network node. The first network node can then send the target request message to the second network node. Upon receiving the target request message, the second network node can perform message verification based on the encrypted verification data carried in the target request message to obtain the message verification result corresponding to the target request message, and can perform message processing based on the message verification result. Here, the initial request message is generated by the first network node based on the PFCP protocol, and therefore has the Packet Forwarding Control Protocol (PFCP) message format. The target request message can be understood as a request message obtained by the first network node based on an improved PFCP protocol, optimizing the initial request message (i.e., adding the aforementioned encrypted verification data). It can be understood that the target request message still has the PFCP message format, and assuming no information tampering occurs during transmission, it will still carry the same node identifier and message identifier as the initial request message. Therefore, the second network node can quickly verify whether the node identifier and message identifier have been tampered with using the encrypted verification data.

[0073] As described above, the improved PFCP protocol does not employ the source IP verification mechanism of the original PFCP protocol, and it does not limit the node identifier configured for the first network node. This allows it to meet the flexible deployment requirements of session management network elements (e.g., deployment in the cloud). Therefore, the method provided in this application is applicable to the process of migrating the 5G private network core network element SMF to a remote deployment location. Furthermore, by using newly added encrypted verification data for message verification, it can avoid large-scale service anomalies caused by configuration errors (e.g., PFCP sessions associated with PFCP associations dropping due to misconfigured duplicate PFCP Node IDs). It can also defend against network attackers masquerading as network nodes, thereby improving the security of the packet forwarding control protocol.

[0074] For ease of understanding, please refer to the following: Figure 2 , Figure 2 This is a schematic diagram of a data processing scenario provided in an embodiment of this application. The data processing scenario mainly describes the data interaction between a first network node and a second network node, for example... Figure 2The network node 20A shown can be used as the first network node, and correspondingly, as... Figure 2 The network node 20B shown can serve as a second network node. Network node 20A can be a user plane node (e.g., the one described above). Figure 1 In the corresponding embodiment, user plane network element 300b), network node 20B can be a control plane node (e.g., the one described above). Figure 1 The corresponding session management network element 300c in the embodiment); or, the network node 20A can be a control plane node (e.g., the one described above). Figure 1 In the corresponding embodiment, the session management network element 300c), then the network node 20B can be a user plane node (for example, the one mentioned above). Figure 1 The user plane network element 300b in the corresponding embodiment is not limited in this application embodiment.

[0075] like Figure 2 As shown, network node 20A can obtain an initial request message (e.g., request message 201) with a packet forwarding control protocol message format. Furthermore, network node 20A can obtain its own node identifier (e.g., node identifier 20a), and simultaneously, it can obtain the message identifier of the aforementioned initial request message (e.g., message identifier 201a). It is understood that the node identifier of network node 20A can be configured when deploying the network node 20A, and the message identifier of the initial request message can be obtained simultaneously with the generation of the initial request message.

[0076] It is understood that in actual business scenarios (e.g., 5G business scenarios), the embodiments of this application can support multiple message types, which may include association establishment message type, association update message type, association release message type, node report message type, session establishment message type, session modification message type, session deletion message type, session report message type, or other specified message types. Network nodes with different functions can support one or more different types of request messages. For example, the session management network element can generate a request message with the association establishment message type to initiate the association establishment process to the user plane network element.

[0077] Furthermore, network node 20A can generate encrypted verification data 202 based on the obtained node identifier 20a and message identifier 201a. It is understood that, to improve the reliability and security of data transmission, network node 20A can encrypt the node identifier 20a and message identifier 201a. For example, a pre-configured key can be used to encrypt both, thereby obtaining encrypted verification data 202. This embodiment does not limit the specific encryption strategy used; for example, symmetric encryption strategies or asymmetric encryption strategies can be used. Furthermore, network node 20A can add the generated encrypted verification data 202 to the aforementioned request message 201, thereby obtaining the corresponding target request message (e.g., request message 203). For example, network node 20A can add a specific field (e.g., a data verification field) to the request message 201 to fill in the encrypted verification data 202 into that field, thus using the request message with the added encrypted verification data as the target request message. Subsequently, network node 20A can send the obtained request message 203 to network node 20B.

[0078] Furthermore, after receiving the request message 203 sent by network node 20A, network node 20B can obtain the encrypted verification data (i.e., encrypted verification data 202) carried by the request message 203. Subsequently, it can perform message verification on the request message 203 based on the encrypted verification data 202. It can be understood that different encryption strategies will correspond to different verification processes. For example, if network node 20A uses the configured key to encrypt the above node identifier 20a and message identifier 201a to obtain encrypted verification data 202, then network node 20B can parse the node identifier to be verified, the message identifier to be verified, and the encrypted verification data 202 carried by the request message 203. Then, it can use the key configured locally by network node 20B to calculate the obtained node identifier to be verified and message identifier to be verified. The calculation result can be compared with the encrypted verification data 202 to obtain the message verification result 204 corresponding to the request message 203. Finally, network node 20B can process the message based on the message verification result 204.

[0079] Optionally, if the message verification result 204 is a successful verification result, meaning the request message 203 is successfully verified, network node 20B can perform normal business processing based on the request message 203 and can return a corresponding response message to network node 20A. For example, assuming the message type of the request message 203 sent by network node 20A is a connection establishment message type, after network node 20B successfully verifies the request message 203, it can establish the corresponding PFCP connection for network node 20A locally and respond successfully. Conversely, if the message verification result 204 is a failed verification result, meaning the request message 203 fails to be verified, network node 20B can perform an exception handling process, such as directly ignoring the request message 203.

[0080] It is understood that, based on the message types listed above, the data processing scenarios described above may specifically include: association establishment scenario, association update scenario, association release scenario, node reporting scenario, session establishment scenario, session modification scenario, session deletion scenario, session reporting scenario, etc. Specific business scenarios will not be listed one by one here.

[0081] As described above, this application embodiment can verify request messages by adding encrypted verification data, thereby replacing the source IP verification mechanism in the original packet forwarding control protocol. In other words, it upgrades and optimizes the source IP verification mechanism, thereby improving the security of the packet forwarding control protocol. Furthermore, unlike the source IP verification mechanism, this application embodiment does not require network nodes to be bound only to the IP address corresponding to their node identifier. Instead, it supports configuring any specified information as the corresponding node identifier. For example, for a session management network element, when deployed locally using common methods, its configured node identifier can be the IP address or FQDN of the session management network element; when deployed in the cloud (e.g., Kubernetes in the cloud, a container cluster management system, often abbreviated as k8s), its configured node identifier can be the node port address (i.e., the Node Port IP address) of the session management service (SMF service) associated with the session management network element. Therefore, it can meet the need for flexible deployment of session management network elements (e.g., deployment on Kubernetes, especially Kubernetes in the cloud). Kubernetes is an open-source Linux container automation platform that enables automated deployment, scaling, and maintenance of container clusters. These container clusters can span public, private, and hybrid clouds. Each container is isolated from the others, has its own file system, and processes within containers do not interfere with each other. It can differentiate computing resources, and compared to virtual machines, containers can be deployed quickly. Furthermore, because containers are decoupled from the underlying infrastructure and its file system, they can be migrated across different types of clouds or operating systems.

[0082] It is understandable that user plane network elements can also be deployed in a similar manner, which will not be elaborated here.

[0083] The specific implementation methods for network node 20A to generate encrypted verification data based on the obtained node identifier and the message identifier of the initial request message, and to add it to the initial request message to obtain the target request message, and for network node 20B to perform message verification based on the encrypted verification data carried in the target request message, can be found below. Figures 3-15 The description in the corresponding embodiments.

[0084] Please see Figure 3 , Figure 3 This is a flowchart illustrating a data processing method provided in an embodiment of this application. This data processing method can be implemented by a first network node (e.g., the one described above). Figure 2 The network node 20A shown is executed. For example... Figure 3 As shown, the data processing method may include at least the following S101-S103:

[0085] S101, when an initial request message with a packet forwarding control protocol message format is obtained, the node identifier of the first network node and the message identifier of the initial request message are obtained, and encrypted verification data is generated based on the node identifier and the message identifier;

[0086] Specifically, the first network node can first generate an initial request message with a packet forwarding control protocol message format. It is understood that the packet forwarding control protocol message format here is the same as the message format defined in the original packet forwarding control protocol, and this application embodiment does not modify it. For ease of understanding, please refer to Table 1, which indicates a packet forwarding control protocol message format provided in this application embodiment:

[0087] Table 1

[0088]

[0089] As can be seen from Table 1 above, the request message in this application embodiment (such as the initial request message and the target request message obtained subsequently) should include a PFCP message header, and depending on its message type, it may be followed by an information element (IE). That is, the number of information elements can be zero or more. This application embodiment does not limit the number of information elements.

[0090] The length of the PFCP message header is variable; for example, the length of the PFCP message header can be an integer multiple of 4 bytes, and this embodiment of the application does not limit this. The PFCP message header may include information such as a message version field, a FO (Follow On) identifier, a message priority field, a session endpoint identifier field (Session EndpointIdentifier, SEID, also known as a session endpoint identifier), a message type field, a message length field, and a message sequence number field. It should be noted that request messages can be divided into node-related request messages (e.g., association establishment request messages) and session-related request messages (e.g., session establishment request messages). The PFCP message headers corresponding to the two types of request messages are different. For example, the PFCP message header of a node-related request message should not include a session identifier field, but should include a message sequence number field; while the PFCP message header of a session-related request message should include both a session identifier field and a message sequence number field.

[0091] The information elements can be categorized into four main types based on requirements: Mandatory, Conditional, Conditional-Optional, and Optional. Their specific use is determined by different request messages. For clarity, please refer to Table 2, which indicates the format of information elements in a packet forwarding control protocol provided in this application embodiment.

[0092] Table 2

[0093]

[0094] As shown in Table 2 above, the length of each information element is variable and includes a type field and a length field. The type field indicates the type of the information element, and its value can range from 0 to 32767 (or other values ​​outside this range). The length field indicates the length of the information element (excluding the first 4 bytes, represented by "n" in Table 2). The remaining bytes can contain IE-specific data or content related to grouped IEs, such as the node identifier corresponding to the network node that sent the request message.

[0095] It is understood that the initial request message generated by the first network node can have the message format described in Table 1 above, and the initial request message can contain one or more information elements (the format of which can be found in Table 2 above). This embodiment of the application does not limit the number and type of information elements contained in the initial request message. The message identifier of the initial request message can be the message sequence number (i.e., the field value of the message sequence number field) contained in the PFCP message header of the initial request message. Optionally, the information elements contained in the initial request message may carry the node identifier of the first network node, depending on the message type of the initial request message.

[0096] It should be noted that the embodiments of this application can support multiple message types, which can be divided into three main categories: the first type of message type, the second type of message type, and the third type of message type. The first type of message type may include association establishment message types; the second type of message type may include association update message types, association release message types, session establishment message types, and node report message types; the third type of message type may include session modification message types, session deletion message types, and session report message types. It is understood that the message content contained in different types of request messages may vary.

[0097] Optionally, when the message type of the initial request message is a first type message, the initial request message with the first type message may include the network address (e.g., IP address) of the first network node, the node identifier of the first network node, and the message identifier (e.g., message sequence number) of the initial request message. Since the establishment of the PFCP connection is the basis for subsequent interaction between the first and second network nodes, to enhance the reliability of the PFCP connection to a certain extent, the message identifier of the initial request message can be randomly generated by the first network node. For example, the first network node can randomly generate an integer as the message identifier of the initial request message.

[0098] In one feasible implementation, the embodiments of this application can support both session management network elements initiating association establishment procedures and user plane network elements initiating association establishment procedures. Therefore, when the first network node generating the initial request message with the association establishment message type is a session management network element, the corresponding second network node is a user plane network element; or, optionally, when the first network node generating the initial request message with the association establishment message type is a user plane network element, the corresponding second network node is a session management network element.

[0099] Optionally, when the message type of the initial request message is the second type, the initial request message with the second type can include the network address of the first network node, the node identifier of the first network node, and the message identifier of the initial request message. Here, the message identifier of the initial request message is determined based on the historical message identifier of the previous request message. The historical request message refers to the request message preceding the initial request message. For example, when the historical message identifier is an integer, the result of incrementing the historical message identifier (e.g., adding 1 to the historical message identifier) ​​can be used as the message identifier of the initial request message. That is, since the PFCP association is established, the message identifiers of request messages generated in chronological order can be a series of incrementing integers.

[0100] In one feasible implementation, the embodiments of this application can support both session management network elements initiating association update processes and user plane network elements initiating association update processes. Therefore, when the first network node generating the initial request message with the association update message type is a session management network element, the corresponding second network node is a user plane network element; or, optionally, when the first network node generating the initial request message with the association update message type is a user plane network element, the corresponding second network node is a session management network element.

[0101] In one feasible implementation, the embodiments of this application can support the session management network element to initiate the association release process and the session establishment process. Therefore, when the first network node that generates the initial request message with the association release message type or the session establishment message type is the session management network element, the corresponding second network node is the user plane network element.

[0102] In one feasible implementation, the embodiments of this application can support user plane network elements to initiate node reporting processes. Therefore, when the first network node that generates an initial request message with a node reporting message type is a user plane network element, the corresponding second network node is a session management network element.

[0103] Optionally, when the message type of the initial request message is a third type message, the initial request message with the third type message may include the network address of the first network node and the message identifier of the initial request message. Here, the message identifier of the initial request message is determined based on the historical message identifier of the historical request message, which refers to the previous request message of the initial request message.

[0104] In one feasible implementation, the embodiments of this application can support session management network elements to initiate session modification and session deletion processes. Therefore, when the first network node that generates an initial request message with a session modification message type or a session deletion message type is a session management network element, the corresponding second network node is a user plane network element.

[0105] In one feasible implementation, the embodiments of this application can support user plane network elements to initiate node reporting processes. Therefore, when the first network node generating the initial request message with the node reporting message type is a user plane network element, the second network node is a session management network element.

[0106] It is understood that message types not listed in the embodiments of this application can also be classified with reference to the above description, and will not be listed one by one in the embodiments of this application.

[0107] As can be seen from the above, the method provided in this application embodiment can be applied to various related scenarios such as association establishment, association update, association release, node reporting, session establishment, session modification, session deletion, and session reporting. Although the message type and message content of the initial request message differ in different scenarios, the first network node can perform the optimization processing described in this application embodiment based on the improved PFCP protocol. It can be understood that the improved PFCP protocol does not change the deployment method of the PFCP protocol transceiver module, thereby enabling the improved PFCP protocol to be compatible with the original network architecture and improving the deployment flexibility of network nodes (e.g., session management network elements) while ensuring protocol reliability.

[0108] To enhance the security of the PFCP protocol, when establishing a PFCP association between the first and second network nodes, the starting message sequence number of the corresponding association establishment request message can be randomly generated. After successful association establishment, the message sequence numbers corresponding to the request messages initiated by the two network nodes can be sequentially incremented. This ensures that the message identifiers of different request messages change dynamically with the request messages. Therefore, the encrypted verification data obtained subsequently based on the message identifiers and the node identifier of the first network node also changes dynamically with the request messages, thereby increasing the difficulty of cracking the encrypted verification data. In addition, other message identifier generation strategies can be used to generate message identifiers to achieve similar effects; this application does not limit the specific strategies employed.

[0109] It should be noted that the embodiments of this application do not limit the node identifiers configured for the session management network element and the user plane network element.

[0110] For example, optionally, when the first network node is a session management network element and the session management network element is deployed in a non-cloud deployment mode, the node identifier of the session management network element can be the network address (e.g., IP address) of the session management network element or the fully qualified domain name (i.e., FQDN) of the session management network element.

[0111] Optionally, when the first network node is a session management network element and the session management network element is deployed in the cloud, the node identifier of the session management network element can be the node port address of the session management service associated with the session management network element. For example, when the session management network element is deployed in Kubernetes in a stateless manner, there can be multiple SMF instances, and one SMF instance can correspond to one SMF Pod. In this case, the PFCPNode ID (i.e., external communication address) configured for each SMF instance can be the Node PortIP address (i.e., node port address) of the associated SMF service (i.e., session management service), while the IP address (i.e., internal communication address) of the PFCP socket bound to the SMF service is the IP address of each SMF Pod (which may be a local IP address), and the IP address of each SMF Pod is different. Since external entities (e.g., the UPF that needs to be connected) cannot perceive these SMF instances, they can only see the IP addresses on the load balancer (i.e., the Node Port IP addresses mentioned above). Therefore, regardless of the number of SMF instances, the IP address of the data packets received externally will always be the IP address on the load balancer. Similarly, after receiving data packets from external entities, the load balancer can distribute them to available SMF Pods using a specified load balancing algorithm (e.g., round-robin, random, least connections, source address hashing, weighted, etc.). The corresponding SMF instances will then process the data packets. In this process, the load balancer can perform Network Address Translation (NAT) on the received data packets, thereby achieving the purpose of address reuse.

[0112] As can be seen from the above, the embodiments of this application can support scenarios where the external IP and internal IP are the same when the session management network element is deployed locally via a non-cloud deployment method, and can also be compatible with scenarios where the external IP and internal IP are different when the session management network element is deployed in the cloud via a cloud deployment method, thereby meeting the needs of flexible deployment of the session management network element.

[0113] It should be noted that, optionally, when the external IP and internal IP of the first network node are detected to be the same, the first network node and the second network node can also use the source IP verification mechanism provided in the original PFCP protocol to verify the initial request message. That is to say, the source IP verification mechanism can still be retained in this application embodiment, but the specific verification mechanism used needs to be selected according to the actual situation.

[0114] Optionally, when the first network node is a user plane network element, the node identifier of the user plane network element can be the network address (e.g., IP address) or the fully qualified domain name (FQDN) of the user plane network element. It is understood that if the user plane network element is also deployed in the cloud using a similar cloud deployment method, its configured node identifier can refer to the node identifier configured for the session management network element described above; this embodiment will not elaborate on this.

[0115] It should be noted that the discovery methods between session management network elements and user plane network elements can include NRF (Network Repository Function, which supports service discovery) discovery and local configuration. This application embodiment does not limit the discovery method used. For example, the configuration process is illustrated below using local configuration as an example:

[0116] (1) When deploying the session management network element, configure its own PFCP Node ID, PFCP key or key certificate, and the Node ID of the user plane network element to be connected, and bind the corresponding PFCP IP address according to the actual environment, such as 0.0.0.0:8805;

[0117] (2) When deploying user plane network elements, configure your own PFCP Node ID, PFCP key or key certificate, and the Node ID of the session management network element to be connected, and bind the corresponding PFCP IP address according to the actual environment, such as 0.0.0.0:8805.

[0118] Based on this, the first network node can obtain its configured node identifier and the message identifier of the aforementioned initial request message, and then generate encrypted verification data based on the obtained node identifier and message identifier. In this embodiment, various encryption strategies (e.g., symmetric encryption, asymmetric encryption, etc.) can be used to encrypt the node identifier and the message identifier to obtain the corresponding encrypted verification data. It is understood that, compared to directly transmitting and verifying the node identifier, verifying the message using encrypted verification data is more secure and reliable.

[0119] Optionally, the first network node can obtain the node private key configured by the first network node based on a symmetric encryption strategy, and then use the node private key of the first network node to encrypt the obtained node identifier and message identifier to obtain encrypted verification data.

[0120] Optionally, the first network node can obtain the key certificate sent by the second network node indicated in the initial request message based on an asymmetric encryption strategy. It can then obtain the second network node's public key from this key certificate and use it to encrypt the obtained node identifier and message identifier to obtain encrypted verification data. Here, the key certificate can be signed by a Certificate Authority (CA, a trusted organization) using its own private key to confirm that the transmitted node public key originates from the second network node. Therefore, after receiving the key certificate, the first network node can use the CA's public key to verify the signature. If the signature is proven valid, the first network node will accept the node public key in the key certificate as the second network node's public key.

[0121] In addition, other encryption strategies (e.g., hash algorithms) can be used to encrypt node identifiers and message identifiers. This application does not limit the specific encryption strategy used.

[0122] Regardless of the encryption strategy employed, when encrypting the node identifier and message identifier, optionally, the node identifier and message identifier can be combined and encrypted simultaneously; alternatively, the node identifier and message identifier can be encrypted separately, and the results can be processed. For example, the node identifier can be encrypted to obtain first encrypted data, and the message identifier can be encrypted to obtain second encrypted data. Then, encrypted verification data can be obtained based on the first and second encrypted data. For instance, the first and second encrypted data can be encrypted again to obtain encrypted verification data; or, for another example, the first and second encrypted data can be combined to obtain encrypted verification data. It is understood that the specific encryption algorithm used in this application is not limited, as long as the first network node and the second network node agree on it.

[0123] S102, add encrypted verification data to the initial request message to obtain the target request message;

[0124] It is understandable that skipping source IP verification would lead to a decrease in security. Therefore, this application embodiment restores or even improves the security of the PFCP protocol by adding encrypted verification data to the initial request message. Based on this, to ensure compatibility with the packet forwarding control protocol message format shown in Table 1 above, this application embodiment can add encrypted verification data by adding a new verification data information element. Specifically, the first network node can first add a verification data information element to the initial request message. This verification data information element has the packet forwarding control protocol information element format shown in Table 2 above. For example, for ease of understanding, please also refer to Table 3, which indicates the format of a verification data information element (PFCP Authentication IE) provided in this application embodiment:

[0125] Table 3

[0126]

[0127] As shown in Table 3 above, in one embodiment, the verification data information element can have 8 bytes, specifically including a data type field (Type), a data length field (Length), and a data authentication field (Authentication). The data type field occupies the first and second bytes of the verification data information element, and its value is the type field value (represented by "T" in Table 3). It can be understood that the value of the type field can be an unused value from 0 to 32767, such as 700, 701, 800, etc. This application embodiment does not limit the specific value of the type field. The data length field occupies the third and fourth bytes of the verification data information element, and its value is the length field value. In this application embodiment, the specific value of the length field is 4 (in bytes). It can be understood that the verification data information element can further include other necessary information, and the specific value of the length field will change accordingly. The data authentication field occupies the fifth to eighth bytes of the verification data information element and is used to fill encrypted verification data. Optionally, the encrypted verification data can be a 32-bit integer.

[0128] Based on this, the first network node can set the field value (Authentication Value) of the data authentication field to the aforementioned encrypted authentication data, and finally use the initial request message with the added encrypted authentication data as the target request message.

[0129] In other words, when configuring session management network elements and user plane network elements, the corresponding PFCP key or key certificate can be configured, and the corresponding node identifier and message sequence number can be encrypted in the PFCP request message to generate corresponding encrypted verification data (e.g., a 32-bit integer), which is then sent to the peer network node in the PFCP Authentication IE. The receiver can further verify the message after receiving the PFCP request message.

[0130] As can be seen from the above, in this embodiment of the application, without changing the message format defined in the PFCP protocol, encrypted verification data encapsulated in IE format can be added to the PFCP request message, thereby achieving forward and backward compatibility of the PFCP protocol. Moreover, the overhead introduced by the encrypted verification data for the encoding and decoding of the PFCP request message is small, and the performance burden improvement is not significant. Therefore, the transmission efficiency of the PFCP connection can be guaranteed.

[0131] Optionally, in one feasible implementation, the addition of verification data elements can be selected through automatic or manual configuration. For example, when data is transmitted between the first and second network nodes via a specific encrypted tunnel, since network attackers cannot crack or tamper with the data, in this scenario where transmission reliability can be ensured, it is possible to choose not to add verification data elements to the sent request message (i.e., no encrypted verification data is added). Correspondingly, the second network node does not need to perform message verification. Conversely, if security and reliability cannot be ensured, it is possible to add verification data elements to the sent request message.

[0132] Based on this, optionally, in the embodiments of this application, a configuration identifier can be added to the initial request message. The configuration identifier can be set based on the actual business scenario. For example, if the configuration identifier is a first configuration identifier, it indicates that the current transmission is insecure. Therefore, the first network node can encrypt its node identifier and the message identifier of the initial request message to obtain encrypted verification data, and add a verification data information element to the initial request message. Then, the field value of the data verification field in the verification data information element can be set to encrypted verification data, and finally the target request message is obtained and sent to the second network node. If the configuration identifier is a second configuration identifier, it indicates that the current transmission is secure and reliable, and the first network node can directly send the initial request message to the second network node.

[0133] S103, the target request message is sent to the second network node. The target request message is used to instruct the second network node to perform message verification on the target request message based on the encrypted verification data carried in the target request message, obtain the message verification result corresponding to the target request message, and perform message processing based on the message verification result.

[0134] Specifically, the first network node can send the obtained target request message to the second network node. Upon receiving the target request message, the second network node can perform message verification based on the encrypted verification data carried in the message, thereby obtaining the message verification result. The second network node can then process the message based on this verification result. The specific process of the second network node's message verification will be detailed later. Figure 4 The corresponding implementation examples will not be elaborated here.

[0135] As described above, the improved PFCP protocol provided in this application embodiment can generate target request messages carrying encrypted verification data. Since neither the session management network element nor the user plane network element performs source IP verification on the target request message, it can meet the flexible deployment requirements of the session management network element (e.g., deployed in Kubernetes). Furthermore, the session management network element and the user plane network element can achieve access within a VPC (Virtual Private Cloud, a dynamically configured pool of public cloud computing resources), cross-VPC access, and even cross-public network access. It is understood that encrypting node identifiers and message identifiers by adding a new PFCP Authentication IE can improve the security of the PFCP protocol, preventing network attackers from obtaining PFCP Node IDs and PFCP IPs to impersonate PFCP nodes in the network. It also enables the avoidance of large-scale business anomalies caused by configuration errors. In addition, the overhead introduced by the PFCP request message encoding and decoding in this application embodiment is small, the performance improvement is not significant, and forward and backward compatibility of PFCP can be achieved.

[0136] Please see Figure 4 , Figure 4 This is a flowchart illustrating a data processing method provided in an embodiment of this application. This data processing method can be implemented by a second network node (e.g., the one described above). Figure 2 The network node 20B shown is executed. For example... Figure 4 As shown, the data processing method may include at least the following S201-S202:

[0137] S201, Receive the target request message sent by the first network node;

[0138] Specifically, the second network node can receive a target request message sent by the first network node. This target request message is obtained by the first network node adding encrypted verification data to an initial request message with a packet forwarding control protocol message format. The encrypted verification data is generated by the first network node based on its node identifier and the message identifier of the initial request message. The specific process by which the first network node generates the target request message can be found above. Figure 3 The corresponding implementation examples will not be described in detail here.

[0139] S202, obtain the encrypted verification data carried by the target request message, perform message verification on the target request message based on the encrypted verification data, obtain the message verification result corresponding to the target request message, and perform message processing based on the message verification result.

[0140] It is understandable that, since the target request message may be subjected to spoofing attacks by network attackers during transmission, or the first network node may be configured with an incorrect node identifier, the second network node, upon receiving the target request message, can perform message verification. Only if the verification is successful will the normal business processing flow continue; otherwise, an exception handling process will be initiated. For ease of understanding and distinction, this embodiment of the application may refer to the message identifier carried by the target request message as the message identifier to be verified, and the node identifier obtained based on the target request message as the node identifier to be verified.

[0141] Specifically, the second network node can obtain encrypted verification data, a message identifier to be verified, and a node identifier to be verified based on the target request message. Furthermore, it can compare and verify the node identifier to be verified and the message identifier to be verified based on the obtained encrypted verification data, thereby obtaining the message verification result corresponding to the target request message.

[0142] It can be understood that, since the message content corresponding to different message types may not be the same, the specific process of obtaining encrypted verification data, the message identifier to be verified, and the node identifier to be verified is related to the message type of the target request message.

[0143] For example, optionally, when the message type of the target request message is a first type message type or a second type message type, the second network node can parse the target request message to obtain the verification data information element, the node identifier to be verified, and the message identifier to be verified carried by the target request message, and then read the encrypted verification data (i.e. the field value of the data verification field) from the data verification field contained in the verification data information element.

[0144] Optionally, when the message type of the target request message is the third type, the target request message does not carry the node identifier of the first network node. Therefore, the second network node can parse the target request message to obtain the verification data information element, the session identifier to be verified (SEID), and the message identifier to be verified carried by the target request message. Then, it can read the encrypted verification data from the data verification field contained in the verification data information element. At the same time, it can obtain the session context associated with the session identifier to be verified, and then obtain the node identifier to be verified from the session context.

[0145] In this context, it can be understood that the encrypted verification data is generated by the first network node encrypting its node identifier and the message identifier of the initial request message based on a specific encryption strategy (see above for details). Figure 3 As in S101 of the corresponding embodiment, the second network node can compare and verify the identifier of the node to be verified and the identifier of the message to be verified based on the encryption strategy adopted by the first network node.

[0146] For example, optionally, the second network node can obtain its private key based on a symmetric encryption strategy. It can then use this private key to encrypt the identifier of the node to be verified and the identifier of the message to be verified, obtaining the data to be verified. The symmetric encryption strategy instructs the first network node to encrypt its node identifier and the message identifier of the initial request message using its private key, thus obtaining encrypted verification data. It can be understood that the private key of the first network node is the same as that of the second network node. Further, the second network node can compare the obtained data to be verified with the encrypted verification data. Optionally, if the data to be verified is found to be the same as the encrypted verification data, the message verification result corresponding to the target request message is determined to be a successful verification result; conversely, if the data to be verified is found to be different from the encrypted verification data, the message verification result corresponding to the target request message is determined to be a failed verification result.

[0147] Optionally, the second network node can obtain its private key based on an asymmetric encryption strategy. It can then decrypt the encrypted verification data using this private key to obtain the corresponding node identifier and message identifier. The asymmetric encryption strategy instructs the first network node to encrypt the node identifier and the message identifier of the initial request message using the public key corresponding to the second network node's private key, thus obtaining the encrypted verification data. It can be understood that the second network node's public key can be sent to the first network node via a key certificate. Further, the second network node can compare the obtained node identifier with the node identifier to be verified, and simultaneously compare the obtained message identifier with the message identifier to be verified. Optionally, if both the node identifier and the message identifier are the same, the message verification result for the target request message is considered successful; conversely, if either the node identifier or the message identifier is different, the message verification result for the target request message is considered unsuccessful.

[0148] Finally, the second network node can process the message based on the obtained message verification result. Optionally, if the message verification result is successful, the second network node can perform business processing based on the target request message, and then generate a response message associated with the target request message and return the response message to the first network node. Conversely, if the message verification result is unsuccessful, the second network node can stop responding to the target request message; for example, to reduce resource waste, it can directly ignore the target request message.

[0149] As described above, after receiving the target request message generated by the first network node based on the improved PFCP protocol, the second network node can parse the corresponding node identifier to be verified, message identifier to be verified, and verification data information elements to perform message verification on the target request message. This improves the security of the PFCP protocol, defends against spoofing attacks, and avoids the impact of configuration errors on services. Furthermore, it enables flexible deployment of 5G core network session management elements in the cloud.

[0150] Further, please see Figure 5 , Figure 5 This is a schematic diagram of the interaction flow of a data processing method provided in an embodiment of this application. This data processing method can be implemented by a first network node (e.g., the one described above). Figure 2 The network node 20A shown) and the second network node (e.g., the one mentioned above) Figure 2 The network nodes 20B shown below execute this together. For example... Figure 5As shown, the data processing method may include at least:

[0151] S301, when an initial request message with a packet forwarding control protocol message format is obtained, the first network node obtains the node identifier of the first network node and the message identifier of the initial request message.

[0152] For details on the implementation of S301, please refer to the above. Figure 3 The S101 in the corresponding embodiment will not be described again here.

[0153] S302, the first network node encrypts the obtained node identifier and message identifier based on the encryption strategy to obtain encrypted verification data;

[0154] For details on the implementation of S302, please refer to the above. Figure 3 The S101 in the corresponding embodiment will not be described again here.

[0155] S303, The first network node adds a verification data information element to the initial request message;

[0156] For details on the implementation of S303, please refer to the above. Figure 3 The S102 in the corresponding embodiment will not be described again here.

[0157] S304, The first network node adds encrypted verification data to the verification data information element and uses the initial request message with added encrypted verification data as the target request message;

[0158] For details on the implementation of S304, please refer to the above. Figure 3 The S102 in the corresponding embodiment will not be described again here.

[0159] S305, the first network node sends the target request message to the second network node;

[0160] For details on the implementation of S305, please refer to the above. Figure 3 The corresponding embodiment of S103 will not be described again here.

[0161] S306, after receiving the target request message sent by the first network node, the second network node obtains the encrypted verification data, the message identifier to be verified, and the node identifier to be verified according to the target request message.

[0162] For details on the implementation of S306, please refer to the above. Figure 4 The corresponding embodiment of S202 will not be described again here.

[0163] S307, the second network node compares and verifies the identifier of the node to be verified and the identifier of the message to be verified based on the encrypted verification data, and obtains the message verification result corresponding to the target request message;

[0164] For details on the implementation of S307, please refer to the above. Figure 4 The corresponding embodiment of S202 will not be described again here.

[0165] S308, when the message verification result is a successful verification result, the second network node performs business processing based on the target request message and generates a response message associated with the target request message;

[0166] For details on the implementation of S308, please refer to the above. Figure 4 The corresponding embodiment of S202 will not be described again here.

[0167] S309, the second network node returns a response message to the first network node;

[0168] For details on the implementation of S309, please refer to the above. Figure 4 The corresponding embodiment of S202 will not be described again here.

[0169] S310, when the message verification result is a verification failure, the second network node stops responding to the target request message.

[0170] For details on the implementation of S310, please refer to the above. Figure 4 The steps of S202 in the corresponding embodiment will not be described again here. Furthermore, the beneficial effects of using the same method will also not be described again.

[0171] It should be noted that the method provided in this application embodiment can be applied to service scenarios where session management network elements and user plane network elements interact. For ease of understanding, please refer to the following descriptions. Figures 6-15 The corresponding implementation examples.

[0172] Please see Figure 6 , Figure 6 This is an interactive schematic diagram of a coupling establishment process provided in an embodiment of this application. For example... Figure 6 As shown, this association establishment process can be initiated by the session management network element, which acts as the first network node, while the user plane network element acts as the second network node. The specific interaction process is as follows:

[0173] S11, the session management network element initiates a PFCP Association Setup Request (i.e., a target request message with an association setup message type in this scenario) to the user plane network element. The association setup request carries the node identifier (i.e., SMF Node ID, e.g., 192.168.100.100) configured by the session management network element, the bound PFCP IP address (i.e., network address, e.g., 10.10.10.100), and a randomly generated message sequence number (i.e., message identifier). The node identifier and message sequence number can then be encrypted using its configured key (e.g., the node private key of the session management network element). The calculated 32-bit integer can be used as encrypted verification data A1 to fill the data verification field contained in the verification data information element of the association setup request.

[0174] S12: After receiving the association establishment request, the user plane network element can parse the node identifier B1 and message identifier C1 to be verified in the association establishment request, and encrypt the node identifier B1 and message identifier C1 to be verified using a locally configured key (e.g., the node private key of the user plane network element). The calculated result can be used as the data to be verified, D1. Then, the data to be verified, D1, can be compared with the encrypted verification data, A1, to obtain the message verification result corresponding to the association establishment request. When the message verification result indicates that the message verification is successful, S13 is executed; when the message verification result indicates that the message verification fails, the association establishment request is ignored.

[0175] S13. After the user plane network element verification association establishment request is successful, the corresponding PFCP association can be established locally for the session management network element, and a successful response is returned, that is, the association establishment response (PFCP Association Setup Response) is returned.

[0176] Similarly, please see Figure 7 , Figure 7 This is an interactive schematic diagram of a coupling establishment process provided in an embodiment of this application. For example... Figure 7 As shown, this association establishment process can be initiated by a user plane network element, which can act as the first network node, while the session management network element acts as the second network node. The specific interaction process is as follows:

[0177] S21, the user plane network element initiates a PFCP Association Setup Request (i.e., a target request message with an association setup message type in this scenario) to the session management network element. The association setup request carries the node identifier (i.e., UPF Node ID, e.g., 192.168.100.102) configured by the user plane network element, the bound PFCP IP address (i.e., network address, e.g., 10.10.10.102), and a randomly generated message sequence number (i.e., message identifier). The node identifier and message sequence number can then be encrypted using the configured key (e.g., the node private key of the user plane network element). The calculated 32-bit integer can be used as encrypted verification data A2 to fill the data verification field contained in the verification data information element of the association setup request.

[0178] S22: After receiving the connection establishment request, the session management network element can parse the node identifier B2 and message identifier C2 to be verified in the connection establishment request, and encrypt the node identifier B2 and message identifier C2 using a locally configured key (e.g., the node private key of the session management network element). The calculated result can be used as the data to be verified, D2. Then, the data to be verified, D2, can be compared with the encrypted verification data, A2, to obtain the message verification result corresponding to the connection establishment request. When the message verification result indicates that the message verification is successful, S23 is executed; when the message verification result indicates that the message verification fails, the connection establishment request is ignored.

[0179] S23. After the session management network element verifies the association establishment request and it is successful, the corresponding PFCP association can be established locally for the user plane network element and a successful response is returned, that is, the association establishment response (PFCP Association Setup Response) is returned.

[0180] Similarly, please see Figure 8 , Figure 8 This is an interactive schematic diagram of a coupling update process provided in an embodiment of this application. For example... Figure 8 As shown, this association update process can be initiated by the session management network element, which acts as the first network node, while the user plane network element acts as the second network node. The specific interaction process is as follows:

[0181] S31, the session management network element initiates a PFCP AssociationUpdate Request (i.e., a target request message with an association update message type in this scenario) to the user plane network element. The association update request carries the node identifier (i.e., SMF Node ID, e.g., 192.168.100.100) configured by the session management network element, the bound PFCP IP address (i.e., network address, e.g., 10.10.10.100), and an incrementing message sequence number (i.e., message identifier). The node identifier and message sequence number can then be encrypted using its configured key (e.g., the node private key of the session management network element). The calculated 32-bit integer can be used as encrypted verification data A3 to fill the data verification field contained in the verification data information element of the association update request.

[0182] S32, after receiving the association update request, the user plane network element can parse the node identifier B3 and message identifier C3 to be verified in the association update request, and encrypt the node identifier B3 and message identifier C3 to be verified using a locally configured key (e.g., the node private key of the user plane network element). The calculated result can be used as the data to be verified D3. Then, the data to be verified D3 can be compared with the encrypted verification data A3 to obtain the message verification result corresponding to the association update request. When the message verification result indicates that the message verification is successful, S33 is executed; when the message verification result indicates that the message verification fails, the association update request is ignored.

[0183] S33. After the user plane network element verification association update request is successful, the corresponding PFCP association can be updated and a successful response is returned, that is, a PFCP Association Update Response is returned.

[0184] Similarly, please see Figure 9 , Figure 9 This is an interactive schematic diagram of a coupling update process provided in an embodiment of this application. For example... Figure 9 As shown, this association update process can be initiated by a user plane network element, which acts as the first network node and the session management network element as the second network node. The specific interaction process is as follows:

[0185] S41, the user plane network element initiates a PFCP AssociationUpdate Request (i.e., a target request message with an association update message type in this scenario) to the session management network element. The association update request carries the node identifier (i.e., UPF Node ID, e.g., 192.168.100.102) configured by the user plane network element, the bound PFCP IP address (i.e., network address, e.g., 10.10.10.102), and an incrementing message sequence number (i.e., message identifier). The node identifier and message sequence number can then be encrypted using the configured key (e.g., the node private key of the user plane network element). The calculated 32-bit integer can be used as encrypted verification data A4 to fill the data verification field contained in the verification data information element of the association update request.

[0186] S42, after receiving the association update request, the session management network element can parse the node identifier B4 and message identifier C4 to be verified in the association update request, and encrypt the node identifier B4 and message identifier C4 to be verified using a locally configured key (e.g., the private key of the session management network element). The calculated result can be used as the data to be verified, D4. Then, the data to be verified, D4, can be compared with the encrypted verification data, A4, to obtain the message verification result corresponding to the association update request. When the message verification result indicates that the message verification is successful, S43 is executed; when the message verification result indicates that the message verification fails, the association update request is ignored.

[0187] S43. After the session management network element verifies the association update request and it is successful, the corresponding PFCP association can be updated and a successful response is returned, that is, the association update response (PFCP Association Update Response) is returned.

[0188] Similarly, please see Figure 10 , Figure 10 This is an interactive schematic diagram of a node reporting process provided in an embodiment of this application. For example... Figure 10 As shown, this node reporting process can be initiated by a user plane network element, which can act as the first network node, while the session management network element acts as the second network node. The specific interaction process is as follows:

[0189] S51, the user plane network element initiates a node report request (PFCP Node Report Request, i.e., a target request message with a node report message type in this scenario) to the session management network element. The node report request carries the node identifier (i.e., UPF Node ID, e.g., 192.168.100.102) configured by the user plane network element, the bound PFCP IP address (i.e., network address, e.g., 10.10.10.102), and an incrementing message sequence number (i.e., message identifier). The node identifier and message sequence number can then be encrypted using its configured key (e.g., the node private key of the user plane network element). The calculated 32-bit integer can be used as encrypted verification data A5 to fill the data verification field contained in the verification data information element of the node report request.

[0190] S52, after receiving the node report request, the session management network element can parse the node identifier B5 and message identifier C5 to be verified in the request, and encrypt them using a locally configured key (e.g., the session management network element's node private key). The calculated result can be used as the data to be verified, D5. This data can then be compared with the encrypted verification data A5 to obtain the message verification result corresponding to the node report request. If the verification result indicates successful verification, proceed to S53; if the verification result indicates failed verification, ignore the node report request.

[0191] S53 After the session management network element verifies the node report request successfully, it performs the corresponding processing and responds successfully, that is, returns the node report response (PFCP Node Report Response).

[0192] Similarly, please see Figure 11 , Figure 11 This is an interactive schematic diagram of a coupling release process provided in an embodiment of this application. For example... Figure 11 As shown, this association release process can be initiated by the session management network element, which acts as the first network node and the user plane network element as the second network node. The specific interaction process is as follows:

[0193] S61, the session management network element initiates a PFCP Association Release Request (i.e., a target request message with an association release message type in this scenario) to the user plane network element. The association release request carries the node identifier (i.e., SMF Node ID, e.g., 192.168.100.100) configured by the session management network element, the bound PFCP IP address (i.e., network address, e.g., 10.10.10.100), and an incrementing message sequence number (i.e., message identifier). The node identifier and message sequence number can then be encrypted using its configured key (e.g., the node private key of the session management network element). The calculated 32-bit integer can be used as encrypted verification data A6 to fill the data verification field contained in the verification data information element of the association release request.

[0194] S62, after receiving the association release request, the user plane network element can parse the node identifier B6 and message identifier C6 to be verified in the association release request, and encrypt the node identifier B6 and message identifier C6 to be verified using a locally configured key (e.g., the node private key of the user plane network element). The calculated result can be used as the data to be verified D6. Then, the data to be verified D6 can be compared with the encrypted verification data A6 to obtain the message verification result corresponding to the association release request. When the message verification result indicates that the message verification is successful, S63 is executed; when the message verification result indicates that the message verification fails, the association release request is ignored.

[0195] S63. After the user plane network element verification association release request is successful, the local PFCP association and related sessions can be released, and a success response is returned, that is, an association release response (PFCP Association Release Response).

[0196] Similarly, please see Figure 12 , Figure 12 This is an interactive schematic diagram of a session establishment process provided in an embodiment of this application. For example... Figure 12 As shown, the session establishment process can be initiated by the session management network element, which acts as the first network node, while the user plane network element acts as the second network node. The specific interaction process is as follows:

[0197] S71, the session management network element initiates a session establishment request (PFCP SessionEstablishment Request, i.e., a target request message with a session establishment message type in this scenario) to the user plane network element. The session establishment request carries the node identifier (i.e., SMF Node ID, e.g., 192.168.100.100) configured by the session management network element, the bound PFCP IP address (i.e., network address, e.g., 10.10.10.100), and an incrementing message sequence number (i.e., message identifier). The node identifier and message sequence number can then be encrypted using its configured key (e.g., the node private key of the session management network element). The calculated 32-bit integer can be used as encrypted verification data A7 to fill the data verification field contained in the verification data information element of the session establishment request.

[0198] S72, after receiving the session establishment request, the user plane network element can parse the node identifier B7 and message identifier C7 to be verified in the session establishment request, and encrypt the node identifier B7 and message identifier C7 using a locally configured key (e.g., the user plane network element's node private key). The calculated result can be used as the data to be verified, D7. Then, the data to be verified, D7, can be compared with the encrypted verification data, A7, to obtain the message verification result corresponding to the session establishment request. When the message verification result indicates that the message verification is successful, S73 is executed; when the message verification result indicates that the message verification fails, the session establishment request is ignored.

[0199] S73 After the user plane network element verifies the session establishment request and it is successful, it can allocate the corresponding resources for the session locally and respond successfully, that is, return the session establishment response (PFCP Session Establishment Response).

[0200] Similarly, please see Figure 13 , Figure 13 An interactive schematic diagram of a session modification process is provided in the application embodiment. For example... Figure 13 This demonstrates that the session modification process can be initiated by the session management network element, which acts as the first network node, while the user plane network element acts as the second network node. The specific interaction process is as follows:

[0201] S81, the session management network element initiates a session modification request (PFCP SessionModification Request, i.e., a target request message with a session modification message type in this scenario) to the user plane network element. The session modification request carries the bound PFCP IP address (i.e., network address, for example, 10.10.10.100) and an incrementing message sequence number (i.e., message identifier), but does not carry the configured node identifier. However, the node identifier and message sequence number can still be encrypted using its configured key (e.g., the node private key of the session management network element). The calculated 32-bit integer can be used as encrypted verification data A8 to fill the data verification field contained in the verification data information element of the session modification request.

[0202] S82, after receiving the session modification request, the user plane network element can parse the session identifier E1 to be verified and the message identifier C8 to be verified in the session modification request, and then obtain the session context associated with the session identifier E1 to be verified, and extract the corresponding node identifier B8 to be verified from the session context.

[0203] Furthermore, the node identifier B8 to be verified and the message identifier C8 to be verified are encrypted using a locally configured key (e.g., the node private key of the user plane network element). The calculated result can be used as the data to be verified, D8. This data D8 can then be compared with the encrypted verification data A8 to obtain the message verification result corresponding to the session modification request. When the message verification result indicates successful verification, step S83 is executed; when the message verification result indicates failed verification, the session modification request is ignored.

[0204] S83 After a user plane network element successfully verifies a session modification request, it can modify the local session resources and respond successfully, i.e., return a session modification response (PFCP Session Modification Response).

[0205] Similarly, please see Figure 14 , Figure 14 This is an interactive schematic diagram of a session reporting process provided in an embodiment of this application. For example... Figure 14 As shown, this session reporting process can be initiated by a user plane network element, which acts as the first network node, while the session management network element acts as the second network node. The specific interaction process is as follows:

[0206] S91, the user plane network element initiates a session report request (PFCP Session Report Request, i.e., a target request message with a session report message type in this scenario) to the session management network element. The session report request carries the bound PFCP IP address (i.e., network address, for example, 10.10.10.102) and an incrementing message sequence number (i.e., message identifier), but does not carry the configured node identifier. However, the node identifier and message sequence number can still be encrypted using its configured key (e.g., the node private key of the user plane network element). The calculated 32-bit integer can be used as encrypted verification data A9 to fill the data verification field contained in the verification data information element in the session report request.

[0207] S92, after receiving the session report request, the session management network element can parse the session identifier E2 and message identifier C9 to be verified in the session report request, and then obtain the session context associated with the session identifier E2. From this session context, the corresponding node identifier B9 to be verified is extracted. Furthermore, the node identifier B9 and message identifier C9 to be verified can be encrypted using a locally configured key (e.g., the private key of the session management network element's node). The calculated result can be used as the data to be verified, D9. The data to be verified, D9, can then be compared with the encrypted verification data A9 to obtain the message verification result corresponding to the session report request. When the message verification result indicates successful message verification, S93 is executed; when the message verification result indicates failed message verification, the session report request is ignored.

[0208] S93 After the session management network element successfully verifies the session report request, it performs the corresponding processing and responds successfully, that is, returns the session report response (PFCP Session Report Response).

[0209] Similarly, please see Figure 15 , Figure 15 This is an interactive schematic diagram of a session deletion process provided in the application embodiment. For example... Figure 15 As shown, the session deletion process can be initiated by the session management network element, which acts as the first network node, while the user plane network element acts as the second network node. The specific interaction process is as follows:

[0210] S1, the session management network element initiates a session deletion request (PFCP Session DeletionRequest, i.e., a target request message with session deletion message type in this scenario) to the user plane network element. The session deletion request carries the bound PFCP IP address (i.e., network address, for example, 10.10.10.100) and an incrementing message sequence number (i.e., message identifier), but does not carry the configured node identifier. However, the node identifier and message sequence number can still be encrypted using its configured key (e.g., the node private key of the session management network element). The calculated 32-bit integer can be used as encrypted verification data A10 to fill the data verification field contained in the verification data information element of the session deletion request.

[0211] S2, after receiving the session deletion request, the user plane network element can parse the session identifier E3 and the message identifier C10 to be verified in the session deletion request, and then obtain the session context associated with the session identifier E3, and extract the corresponding node identifier B10 to be verified from the session context.

[0212] Furthermore, the node identifier B10 to be verified and the message identifier C10 to be verified are encrypted using a locally configured key (e.g., the node private key of the user plane network element). The calculated result can be used as the data to be verified, D10. This data D10 can then be compared with the encrypted verification data A10 to obtain the message verification result corresponding to the session deletion request. If the message verification result indicates successful verification, step S3 is executed; if the message verification result indicates failed verification, the session deletion request is ignored.

[0213] S3. After the user plane network element successfully verifies the session deletion request, it can delete the local session resources and respond successfully, that is, return the session deletion response (PFCP Session Deletion Response).

[0214] Please see Figure 16 This is a schematic diagram of the structure of a data processing apparatus provided in an embodiment of this application. The data processing apparatus can be a computer program (including program code) running on a network element device; for example, the data processing apparatus is application software. The apparatus can be used to execute corresponding steps in the data processing method provided in the embodiments of this application. Figure 16 As shown, the data processing device 1 may include: an encryption module 11, an update module 12, and a sending module 13;

[0215] Encryption module 11 is used to obtain the node identifier of the first network node and the message identifier of the initial request message when an initial request message with a packet forwarding control protocol message format is obtained, and to generate encrypted verification data based on the node identifier and the message identifier.

[0216] The encryption module 11 may include: a first encryption unit 111 and a second encryption unit 112;

[0217] The first encryption unit 111 is used to obtain the node private key of the first network node based on the symmetric encryption strategy, and to encrypt the node identifier and message identifier using the node private key of the first network node to obtain encrypted verification data.

[0218] The second encryption unit 112 is used to obtain the key certificate sent by the second network node indicated by the initial request message based on an asymmetric encryption strategy, obtain the node public key of the second network node from the key certificate, and encrypt the node identifier and message identifier using the node public key of the second network node to obtain encrypted verification data.

[0219] The specific functional implementation methods of the first encryption unit 111 and the second encryption unit 112 can be found in the above description. Figure 3 The S101 in the corresponding embodiment will not be described again here.

[0220] Update module 12 is used to add encrypted verification data to the initial request message to obtain the target request message;

[0221] The update module 12 may include: an element addition unit 121 and a data addition unit 122;

[0222] The element adding unit 121 is used to add a verification data information element to the initial request message; the verification data information element includes a data type field, a data length field, and a data verification field; the field value of the data type field is the type field value, and the field value of the data length field is the length field value; the verification data information element has the packet forwarding control protocol information element format;

[0223] The data adding unit 122 is used to set the field value of the data verification field to encrypted verification data and use the initial request message with the added encrypted verification data as the target request message.

[0224] The specific functional implementation methods of the element adding unit 121 and the data adding unit 122 can be found in the above description. Figure 3 The S102 in the corresponding embodiment will not be described again here.

[0225] The sending module 13 is used to send the target request message to the second network node. The target request message is used to instruct the second network node to perform message verification on the target request message based on the encrypted verification data carried in the target request message, obtain the message verification result corresponding to the target request message, and perform message processing based on the message verification result.

[0226] The specific functional implementation methods of encryption module 11, update module 12, and sending module 13 can be found in the above description. Figure 3 The steps S101-S103 in the corresponding embodiments will not be described again here. Furthermore, the beneficial effects of using the same method will also not be described again.

[0227] Please see Figure 17 This is a schematic diagram of the structure of a data processing apparatus provided in an embodiment of this application. The data processing apparatus can be a computer program (including program code) running on a network element device; for example, the data processing apparatus is application software. The apparatus can be used to execute corresponding steps in the data processing method provided in the embodiments of this application. Figure 17 As shown, the data processing device 2 may include: a receiving module 21 and a verification module 22;

[0228] The receiving module 21 is used to receive a target request message sent by the first network node; the target request message is obtained by the first network node adding encrypted verification data to the initial request message with the packet forwarding control protocol message format; the encrypted verification data is generated by the first network node based on the node identifier of the first network node and the message identifier of the initial request message.

[0229] Verification module 22 is used to obtain the encrypted verification data carried by the target request message, perform message verification on the target request message based on the encrypted verification data, obtain the message verification result corresponding to the target request message, and perform message processing based on the message verification result;

[0230] The verification module 22 may include: a data acquisition unit 221, a comparison and verification unit 222, a verification success unit 223, and a verification failure unit 224.

[0231] The data acquisition unit 221 is used to acquire encrypted verification data, the message identifier to be verified, and the node identifier to be verified according to the target request message;

[0232] Specifically, the data acquisition unit 221 is used to parse the target request message when the message type of the target request message is a first type message type or a second type message type, to obtain the verification data information element, the node identifier to be verified, and the message identifier to be verified carried by the target request message; and to read encrypted verification data from the data verification field contained in the verification data information element.

[0233] Specifically, the data acquisition unit 221 is used to parse the target request message when the message type of the target request message is the third type of message, to obtain the verification data information element, the session identifier to be verified, and the message identifier to be verified carried by the target request message; to read encrypted verification data from the data verification field contained in the verification data information element; to obtain the session context associated with the session identifier to be verified, and to obtain the node identifier to be verified from the session context;

[0234] The comparison and verification unit 222 is used to compare and verify the identifier of the node to be verified and the identifier of the message to be verified based on the encrypted verification data, and to obtain the message verification result corresponding to the target request message.

[0235] The comparison and verification unit 222 may include: an identifier encryption subunit 2221, a first comparison subunit 2222, a first determination subunit 2223, a second determination subunit 2224, a data decryption subunit 2225, a second comparison subunit 2226, a third determination subunit 2227, and a fourth determination subunit 2228.

[0236] The encryption subunit 2221 is used to obtain the private key of the second network node based on a symmetric encryption strategy, and to encrypt the identifier of the node to be verified and the identifier of the message to be verified using the private key of the second network node to obtain the data to be verified; the symmetric encryption strategy is used to instruct the first network node to encrypt the identifier of the node and the message identifier using the private key of the first network node to obtain encrypted verification data; the private key of the first network node is the same as the private key of the second network node.

[0237] The first comparison subunit 2222 is used to compare the data to be verified with the encrypted verification data;

[0238] The first determining subunit 2223 is used to determine the message verification result corresponding to the target request message as a successful verification result if the data to be verified is the same as the encrypted verification data.

[0239] The second determining subunit 2224 is used to determine the message verification result corresponding to the target request message as a verification failure result if the data to be verified is different from the encrypted verification data.

[0240] The data decryption subunit 2225 is used to obtain the private key of the second network node based on an asymmetric encryption strategy, and to decrypt the encrypted verification data using the private key of the second network node to obtain the node identifier and message identifier. The asymmetric encryption strategy is used to instruct the first network node to encrypt the node identifier and message identifier using the public key corresponding to the private key of the second network node to obtain the encrypted verification data. The public key of the second network node is sent to the first network node by the second network node through a key certificate.

[0241] The second comparison subunit 2226 is used to compare the node identifier with the node identifier to be verified, and to compare the message identifier with the message identifier to be verified.

[0242] The third determining subunit 2227 is used to determine the message verification result corresponding to the target request message as a successful verification result if the node identifier is the same as the node identifier to be verified and the message identifier is the same as the message identifier to be verified.

[0243] The fourth determining subunit 2228 is used to determine the message verification result corresponding to the target request message as a verification failure result if the node identifier is different from the node identifier to be verified, or if the message identifier is different from the message identifier to be verified.

[0244] The specific functional implementation methods of the identification encryption subunit 2221, the first comparison subunit 2222, the first determination subunit 2223, the second determination subunit 2224, the data decryption subunit 2225, the second comparison subunit 2226, the third determination subunit 2227, and the fourth determination subunit 2228 can be found above. Figure 4 The corresponding embodiment of S202 will not be described again here.

[0245] The verification success unit 223 is used to perform business processing based on the target request message if the message verification result is a verification success result, generate a response message associated with the target request message, and return the response message to the first network node.

[0246] The verification failure unit 224 is used to stop responding to the target request message if the message verification result is a verification failure result.

[0247] The specific functional implementation methods of the data acquisition unit 221, comparison and verification unit 222, verification success unit 223, and verification failure unit 224 can be found above. Figure 4 The corresponding embodiment of S202 will not be described again here.

[0248] The specific functional implementation of the receiving module 21 and the verification module 22 can be found in the above description. Figure 4The steps S201-S202 in the corresponding embodiments will not be described again here. Furthermore, the beneficial effects of using the same method will also not be described again.

[0249] Please see Figure 18 This is a structural schematic diagram of a network element device provided in an embodiment of this application. For example... Figure 18 As shown, the network element device 1000 may include: a processor 1001, a network interface 1003, and a memory 1004. Furthermore, the network element device 1000 may also include: at least one communication bus 1002. The communication bus 1002 is used to implement communication between these components. The network interface 1003 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1004 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1004 may also be at least one storage device located remotely from the aforementioned processor 1001. Figure 18 As shown, the memory 1004, which serves as a computer-readable storage medium, may include an operating system, a network communication module, and a device control application. In this embodiment, the network element device 1000 may be a session management network element or a user plane network element.

[0250] In such Figure 18 In the network element device 1000 shown, the network interface 1003 provides network communication functionality; while the processor 1001 can be used to call the device control application stored in the memory 1004 to execute the aforementioned... Figure 3 , Figure 4 , Figure 5 The description of the data processing method in any corresponding embodiment will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0251] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the aforementioned data processing apparatus 1 and data processing apparatus 2. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figure 3 , Figure 4 , Figure 5 The description of the data processing method in any corresponding embodiment is already provided, and therefore will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

[0252] The aforementioned computer-readable storage medium can be an internal storage unit of the data processing apparatus or network element device provided in any of the foregoing embodiments, such as a hard disk or memory of the network element device. The computer-readable storage medium can also be an external storage device of the network element device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the network element device. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of the network element device. The computer-readable storage medium is used to store the computer program and other programs and data required by the network element device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0253] Furthermore, it should be noted that this application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of the network element device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the network element device to perform the aforementioned... Figure 3 , Figure 4 , Figure 5 The method is provided in any of the corresponding embodiments. Furthermore, the beneficial effects of using the same method will not be repeated here. For technical details not disclosed in the computer program products or computer program embodiments involved in this application, please refer to the description of the method embodiments of this application.

[0254] For further details, please see Figure 19 , Figure 19 This is a schematic diagram of the structure of a data processing system provided in an embodiment of this application. The data processing system 3 may include a data processing device 1a and a data processing device 2a. The data processing device 1a may be the one described above. Figure 16 Regarding the data processing device 1 in the corresponding embodiment, it can be understood that the data processing device 1a can be integrated into the above-mentioned... Figure 2 The network node 20A in the corresponding embodiment will not be described in detail here. The data processing device 2a can be the one described above. Figure 17 Regarding the data processing device 2 in the corresponding embodiment, it can be understood that the data processing device 2a can be integrated into the above-mentioned... Figure 2 The network node 20B in the corresponding embodiment will not be described again here. Furthermore, the beneficial effects of using the same method will also not be described again. For technical details not disclosed in the embodiments of the data processing system involved in this application, please refer to the description of the method embodiments of this application.

[0255] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0256] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0257] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method, characterized in that, The method is executed by the first network node and includes: When an initial request message with a packet forwarding control protocol message format is obtained, the node identifier of the first network node and the message identifier of the initial request message are obtained, and encrypted verification data is generated based on the node identifier and the message identifier. If the first network node is a session management network element and the session management network element is deployed in the cloud, then the node identifier of the session management network element is the node port address of the session management service associated with the session management network element. One session management network element corresponds to one session management container in the cloud, and the session management service is used to provide load balancing scheduling for multiple session management containers in the cloud. The encrypted verification data is added to the initial request message to obtain the target request message; The target request message is sent to the second network node. The target request message is used to instruct the second network node to compare and verify the identifier of the node to be verified and the identifier of the message to be verified in the target request message based on the encrypted verification data in the target request message, so as to obtain the message verification result corresponding to the target request message, and to process the message based on the message verification result; the identifier of the node to be verified is obtained based on the target request message.

2. The method according to claim 1, characterized in that, When the message type of the initial request message is the first type of message, the initial request message includes the network address of the first network node, the node identifier of the first network node, and the message identifier of the initial request message; the message identifier of the initial request message is randomly generated by the first network node; the first type of message includes the association establishment message type.

3. The method according to claim 1, characterized in that, When the message type of the initial request message is the second type of message, the initial request message includes the network address of the first network node, the node identifier of the first network node, and the message identifier of the initial request message; the message identifier of the initial request message is determined based on the historical message identifier of the historical request message, and the historical request message refers to the previous request message of the initial request message; the second type of message includes association update message type, association release message type, session establishment message type, and node report message type.

4. The method according to claim 1, characterized in that, When the message type of the initial request message is the third type of message, the initial request message includes the network address of the first network node and the message identifier of the initial request message; the message identifier of the initial request message is determined based on the historical message identifier of the historical request message, and the historical request message refers to the previous request message of the initial request message; the third type of message includes session modification message type, session deletion message type and session report message type.

5. The method according to claim 1, characterized in that, The generation of encrypted verification data based on the node identifier and the message identifier includes: Based on a symmetric encryption strategy, the private key of the first network node is obtained, and the node identifier and the message identifier are encrypted using the private key of the first network node to obtain encrypted verification data.

6. The method according to claim 1, characterized in that, The generation of encrypted verification data based on the node identifier and the message identifier includes: Based on an asymmetric encryption strategy, the key certificate sent by the second network node indicated by the initial request message is obtained, the node public key of the second network node is obtained from the key certificate, and the node identifier and the message identifier are encrypted using the node public key of the second network node to obtain encrypted verification data.

7. The method according to claim 1, characterized in that, The step of adding the encrypted verification data to the initial request message to obtain the target request message includes: A verification data information element is added to the initial request message; the verification data information element includes a data type field, a data length field, and a data verification field; the field value of the data type field is the type field value, and the field value of the data length field is the length field value; the verification data information element has a packet forwarding control protocol information element format; Set the field value of the data verification field to the encrypted verification data, and use the initial request message with the added encrypted verification data as the target request message.

8. A data processing method, characterized in that, The method is executed by the second network node and includes: The system receives a target request message sent by a first network node. The target request message is obtained by the first network node adding encrypted verification data to an initial request message with a packet forwarding control protocol message format. The encrypted verification data is generated by the first network node based on the node identifier of the first network node and the message identifier of the initial request message. If the first network node is a session management network element and the session management network element is deployed in a cloud manner, then the node identifier of the session management network element is the node port address of the session management service associated with the session management network element. One session management network element corresponds to one session management container in the cloud. The session management service is used to provide load balancing scheduling for multiple session management containers in the cloud. The encrypted verification data carried in the target request message is obtained. The identifier of the node to be verified and the identifier of the message to be verified in the target request message are compared and verified to obtain the message verification result corresponding to the target request message. The message processing is performed based on the message verification result. The identifier of the node to be verified is obtained based on the target request message.

9. The method according to claim 8, characterized in that, The step of obtaining the encrypted verification data carried in the target request message, comparing and verifying the identifier of the node to be verified and the identifier of the message to be verified in the target request message based on the encrypted verification data, and obtaining the message verification result corresponding to the target request message includes: Based on the target request message, obtain the encrypted verification data, the message identifier to be verified, and the node identifier to be verified; Based on the encrypted verification data, the identifier of the node to be verified and the identifier of the message to be verified are compared and verified to obtain the message verification result corresponding to the target request message.

10. The method according to claim 9, characterized in that, The step of obtaining the encrypted verification data, the message identifier to be verified, and the node identifier to be verified according to the target request message includes: When the message type of the target request message is the first message type or the second message type, the target request message is parsed to obtain the verification data information elements, the node identifier to be verified, and the message identifier to be verified carried by the target request message. The encrypted verification data is read from the data verification field contained in the verification data information element.

11. The method according to claim 9, characterized in that, The step of obtaining the encrypted verification data, the message identifier to be verified, and the node identifier to be verified according to the target request message includes: When the message type of the target request message is the third type of message, the target request message is parsed to obtain the verification data information elements, the session identifier to be verified, and the message identifier to be verified carried by the target request message. Read the encrypted verification data from the data verification field contained in the verification data information element; Obtain the session context associated with the session identifier to be verified, and obtain the node identifier to be verified from the session context.

12. The method according to claim 9, characterized in that, The step of comparing and verifying the identifier of the node to be verified and the identifier of the message to be verified based on the encrypted verification data to obtain the message verification result corresponding to the target request message includes: Based on a symmetric encryption strategy, the private key of the second network node is obtained, and the node identifier to be verified and the message identifier to be verified are encrypted using the private key of the second network node to obtain the data to be verified; the symmetric encryption strategy is used to instruct the first network node to encrypt the node identifier and the message identifier using the private key of the first network node to obtain the encrypted verification data; the private key of the first network node is the same as the private key of the second network node. The data to be verified is compared with the encrypted verification data; If the data to be verified is the same as the encrypted verification data, then the message verification result corresponding to the target request message is determined to be a successful verification result. If the data to be verified is different from the encrypted verification data, then the message verification result corresponding to the target request message is determined to be a verification failure result.

13. The method according to claim 9, characterized in that, The step of comparing and verifying the identifier of the node to be verified and the identifier of the message to be verified based on the encrypted verification data to obtain the message verification result corresponding to the target request message includes: Based on an asymmetric encryption strategy, the private key of the second network node is obtained, and the encrypted verification data is decrypted using the private key of the second network node to obtain the node identifier and the message identifier. The asymmetric encryption strategy instructs the first network node to encrypt the node identifier and the message identifier using the public key corresponding to the private key of the second network node to obtain the encrypted verification data. The public key of the second network node is sent to the first network node by the second network node through a key certificate. The node identifier is compared with the node identifier to be verified, and the message identifier is compared with the message identifier to be verified. If the node identifier is the same as the node identifier to be verified, and the message identifier is the same as the message identifier to be verified, then the message verification result corresponding to the target request message is determined to be a successful verification result. If the node identifier is different from the node identifier to be verified, or if the message identifier is different from the message identifier to be verified, then the message verification result corresponding to the target request message is determined to be a verification failure result.

14. A data processing apparatus, characterized in that, include: The encryption module is used to obtain the node identifier of the first network node and the message identifier of the initial request message when an initial request message with a packet forwarding control protocol message format is obtained, and to generate encrypted verification data based on the node identifier and the message identifier. If the first network node is a session management network element and the session management network element is deployed in the cloud, then the node identifier of the session management network element is the node port address of the session management service associated with the session management network element. One session management network element corresponds to one session management container in the cloud. The session management service is used to provide load balancing scheduling for multiple session management containers in the cloud. The update module is used to add the encrypted verification data to the initial request message to obtain the target request message; The sending module is used to send the target request message to the second network node. The target request message is used to instruct the second network node to compare and verify the identifier of the node to be verified and the identifier of the message to be verified in the target request message based on the encrypted verification data in the target request message, to obtain the message verification result corresponding to the target request message, and to process the message based on the message verification result. The identifier of the node to be verified is obtained based on the target request message.

15. A data processing apparatus, characterized in that, include: The receiving module is used to receive the target request message sent by the first network node; The target request message is obtained by the first network node adding encrypted verification data to the initial request message with the packet forwarding control protocol message format; the encrypted verification data is generated by the first network node based on the obtained node identifier of the first network node and the message identifier of the initial request message; if the first network node is a session management network element and the session management network element is deployed in the cloud, then the node identifier of the session management network element is the node port address of the session management service associated with the session management network element, one session management network element corresponds to one session management container in the cloud, and the session management service is used to provide load balancing scheduling for multiple session management containers in the cloud; The verification module is used to obtain the encrypted verification data carried in the target request message, compare and verify the identifier of the node to be verified and the identifier of the message to be verified in the target request message based on the encrypted verification data, obtain the message verification result corresponding to the target request message, and perform message processing based on the message verification result. The identifier of the node to be verified is obtained based on the target request message.

16. A network element device, characterized in that, include: Processor and memory; The processor is connected to the memory, wherein the memory is used to store a computer program, and the processor is used to invoke the computer program to cause the network element to perform the method according to any one of claims 1-13.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a network element having the processor to perform the method according to any one of claims 1-13.

18. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, the computer instructions being adapted to be read and executed by a processor to cause a network element having the processor to perform the method of any one of claims 1-13.

Images