Methods, systems, and computer-readable media for concealing network function instance identifiers

Abstract

Methods, systems, and computer-readable media for hiding network function (NF) instance identifiers (IDs) in a communication network are disclosed. A method for hiding NF instance IDs in a communication network occurs at a network repository function (NRF) comprising at least one processor. The method comprises: receiving, from a first NF, a NF registration request message for registering a first NF instance of the first NF, wherein the NF registration request message comprises a first NF instance ID for identifying the first NF instance; storing, in a data repository, a mapping between the first NF instance ID and at least one pseudo NF instance ID, wherein the data repository comprises mappings between NF instance IDs and related pseudo NF instance IDs; and generating and sending, to the first NF, a NF registration response message comprising the at least one pseudo NF instance ID for identifying the first NF instance.

Description

[0001] Priority Statement

[0002] This application claims priority to U.S. Patent Application Serial No. 17 / 314,300, filed May 7, 2021, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] This article describes topics related to enhancing security in fifth-generation (5G) and subsequent generation communication networks. More specifically, this article describes topics related to methods, systems, and computer-readable media for hiding network function (NF) instance identifiers (IDs) in 5G and subsequent generation communication networks. Background Technology

[0004] In fifth-generation (5G) communication networks, network nodes that provide services are called producer network functions (NFs). Network nodes that consume services are called consumer NFs. A network function can be both a producer NF and a consumer NF, depending on whether it is consuming or providing services.

[0005] A given producer NF can have multiple service endpoints, where a service endpoint is a contact point of one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of an Internet Protocol (IP) address and a port number, or by a fully qualified domain name that resolves to an IP address and port number on the network node hosting the producer NF. An NF instance is an instance of the producer NF that provides a service. A given producer NF can include more than one NF instance. It should also be noted that multiple NF instances can share the same service endpoint.

[0006] Producer NFs register with the NF Repository Function (NRF). The NRF maintains service profiles for available NF instances, identifying the services supported by each NF instance. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF. Besides consumer NFs, another network node that can subscribe to receive information about NF service instances is the Service Communication Agent (SCP). The SCP subscribes to the NRF and obtains information about the reachability and service profiles of producer NF service instances. Consumer NFs connect to the SCP, and the SCP load balances traffic among producer NF service instances providing the required services, or routes traffic directly to the target producer NF instance.

[0007] Besides SCPs, other examples of intermediate proxy nodes or groups of network nodes that route traffic between producer NFs and consumer NFs include Secure Edge Protection Proxies (SEPPs), serving gateways, and nodes in 5G serving meshes. SEPPs are network nodes used to protect control plane traffic exchanged between different 5G Public Land Mobile Networks (PLMNs). Therefore, SEPPs perform various amounts of message filtering, control, and topology hiding on Application Programming Interface (API) messages.

[0008] However, security measures need to be improved at one or more NFs. Summary of the Invention

[0009] Methods, systems, and computer-readable media for hiding Network Function (NF) instance identifiers (IDs) in a communication network are disclosed. One method for hiding an NF instance ID occurs at an NF repository function (NRF) including at least one processor. The method includes: receiving from a first NF an NF registration request message for registering a first NF instance of the first NF, wherein the NF registration request message includes a first NF instance ID for identifying the first NF instance; storing in a data repository a mapping between the first NF instance ID and at least one pseudo NF instance ID, wherein the data repository includes a mapping between the NF instance ID and associated pseudo NF instance IDs; and generating and sending to the first NF an NF registration response message including the at least one pseudo NF instance ID for identifying the first NF instance.

[0010] An example system for hiding NF instance IDs in a communication network includes an NRF, which includes at least one processor and a memory. The NRF is configured to: receive from a first NF an NF registration request message for registering a first NF instance of the first NF, wherein the NF registration request message includes a first NF instance ID for identifying the first NF instance; store in a data store a mapping between the first NF instance ID and at least one pseudo NF instance ID, wherein the data store includes a mapping between the NF instance ID and the associated pseudo NF instance ID; and generate and send to the first NF an NF registration response message including the at least one pseudo NF instance ID for identifying the first NF instance.

[0011] An example non-transitory computer-readable medium includes computer-executable instructions embodied therein, which, when executed by at least one processor of at least one computer, cause the at least one computer to perform the following steps at an NRF including at least one processor: receiving from a first NF an NF registration request message for registering a first NF instance of the first NF, wherein the NF registration request message includes a first NF instance ID for identifying the first NF instance; storing in a data store a mapping between the first NF instance ID and at least one pseudo NF instance ID, wherein the data store includes a mapping between the NF instance ID and the associated pseudo NF instance ID; and generating and sending to the first NF an NF registration response message including the at least one pseudo NF instance ID for identifying the first NF instance.

[0012] According to one aspect of the subject matter described herein, a first NF can be configured to: receive from an NRF an NF registration response message including at least one pseudo NF instance ID for identifying a first NF instance, wherein each of the at least one pseudo NF instance ID is different from the first NF instance ID used to identify the first NF instance; store the at least one pseudo NF instance ID associated with the first NF instance ID; and, when sending a request or response message, use the first pseudo NF instance ID from the at least one pseudo NF instance ID to identify the sender.

[0013] According to one aspect of the subject matter described herein, a first NF can be configured to: receive an NF discovery request message from a consumer NF instance including at least one query parameter; use the at least one query parameter and a data store to select an NF profile including a first pseudo NF instance ID; and send the NF profile including the first pseudo NF instance ID to the consumer NF instance.

[0014] According to one aspect of the subject described in this article, the first pseudo NF instance ID can be used by the consumer NF instance to request an access token, NF profile, or NF subscription associated with the first NF instance.

[0015] According to one aspect of the subject described in this article, the first pseudo NF instance ID can be used by the consumer NF instance to communicate with the first NF instance via a service-based interface (SBI).

[0016] According to one aspect of the subject matter described herein, an NRF can be configured to: receive a service request message for performing an action associated with a first NF instance, wherein the service request message includes an ID for the first NF instance; use the ID and a data store containing associations between the NF instance ID and related pseudo-NF instance IDs to determine whether the service request message is valid or invalid; in response to determining that the service request message is invalid, perform an invalid message action; and in response to determining that the service request message is valid, perform an action associated with the first NF instance.

[0017] According to one aspect of the subject described in this article, an NF that hides the NF instance ID (e.g., by using a pseudo NF instance ID) may include a producer NF, a policy control function (PCF), a binding support function (BSF), a service communication broker (SCP), a secure edge protection broker (SEPP), a network slice selection function (NSSF), a network exposure function (NEF), a unified data repository (UDR), or a 5GC NF.

[0018] According to one aspect of the subject described in this article, invalid message actions may include discarding the request message or notifying the network operator or management system.

[0019] According to one aspect of the subject matter described herein, service request messages may include NF registration request messages, NF update request messages, or NF deregistration request messages.

[0020] According to one aspect of the subject matter described in this article, determining that a service request message (such as an NF registration request message, an NF update request message, or an NF deregistration request message) is invalid includes determining that the ID in the service request message is one of one or more pseudo NF instance IDs associated with a first NF instance ID.

[0021] The subjects described herein can be implemented in hardware, software, firmware, or any combination thereof. Therefore, the terms “function,” “node,” or “module” as used herein refer to hardware used to implement the described features, which may also include software and / or firmware components. In one example implementation, the subjects described herein can be implemented using a computer-readable medium on which computer-executable instructions are stored, which, when executed by a computer’s processor, control the computer to perform steps. Example computer-readable media suitable for implementing the subjects described herein include non-transitory computer-readable media, such as disk storage devices, chip storage devices, programmable logic devices, and application-specific integrated circuits (ASICs). Furthermore, computer-readable media implementing the subjects described herein can reside on a single device or computing platform or can be distributed across multiple devices or computing platforms. Attached Figure Description

[0022] The subject matter described herein will now be explained with reference to the accompanying drawings, in which:

[0023] Figure 1 This is a network diagram illustrating the fifth-generation (5G) network architecture;

[0024] Figure 2 This is a diagram illustrating an example network node used to hide the Network Function (NF) instance identifier (ID) in a 5G communication network;

[0025] Figure 3 This is a message flow diagram illustrating an example NF discovery scenario involving NF instance IDs;

[0026] Figure 4 This is a message flow diagram illustrating the use of a sample NF access token, including the NF instance ID;

[0027] Figure 5 This is a diagram illustrating example ID data that shows the NF instance ID and the associated pseudo-NF instance ID;

[0028] Figure 6 This is a diagram illustrating the example ID used by the message type and the associated pseudo-NF instance ID;

[0029] Figure 7 This is a message flow diagram illustrating an example NF discovery scenario involving a pseudo NF instance ID;

[0030] Figure 8 This is a message flow diagram illustrating the use of a sample NF access token that includes a pseudo NF instance ID;

[0031] Figure 9 This is a message flow diagram illustrating the example verification of the NF cancellation request message; and

[0032] Figure 10 This is a flowchart illustrating an example process for hiding the NF instance ID in a communication network. Detailed Implementation

[0033] This document describes methods, systems, and computer-readable media for hiding Network Function (NF) instance identifiers (IDs) in fifth-generation (5G) communication networks. In 5G communication networks, NF instance IDs are used to uniquely identify 5G NF instances. For example, NF repository functions use NF instance IDs for NF management, NF discovery, and NF access token services. Furthermore, consumer NFs use NF instance IDs for client authentication based on Client Credential Assertion (CCA). NFs also use NF instance IDs to share their identity; for example, Access and Mobility Management Functions (AMFs) use their NF instance IDs during UEContextManagement (UECM) service registration. Because NF instance IDs uniquely identify NFs, exposing NF instance IDs outside their Public Land Mobile Network (PLMN) may implicitly expose the PLMN's topology to the outside world. For example, NF instance IDs may leak from the visitor network due to compromised security within the visitor network (such as the lack of Transport Layer Security (TLS) between NFs).

[0034] While the Secure Edge Protection Agent (SEPP) provides some security measures for inter-PLMN communication, it cannot hide the NF instance ID because the NF instance ID can be embedded in the access token, which is immutable due to JSON Web Signature (JWS) signing. Furthermore, the NF instance ID is used for NF update and NF deregistration service operations. Therefore, a leaked NF instance ID could be misused in denial-of-service (DoS) attacks (e.g., by hackers), for example, by sending unauthorized NF update or NF deregistration request messages.

[0035] Based on some aspects of the subject matter described herein, methods, systems, mechanisms, and / or techniques are disclosed for hiding NF instance IDs in communication networks by using pseudo NF instance IDs instead of NF instance IDs in various scenarios. For example, according to various aspects described herein, an NRF can generate and / or assign pseudo NF instance IDs during NF registration. In this example, the pseudo NF instance ID can be shared with the NF in the NF registration response. In some embodiments, the pseudo NF instance ID can be used to identify NFs in various scenarios (e.g., inter-PLMN communication), thereby mitigating NF instance ID leakage and related misuse. In some embodiments, for example, to further mitigate NF instance ID misuse, the actual NF instance ID (instead of the pseudo NF instance ID) can be used for NF registration, NF update, and NF deregistration.

[0036] Advantageously, by utilizing one or more of the techniques, systems and / or methods described herein, NRF or other entities can enhance security (e.g., prevent DoS attacks or other malicious acts) by using pseudo NF instance IDs and / or reducing the applicability of NF instance IDs to NF registration, NF update, and NF deregistration scenarios.

[0037] Reference will now be made in detail to various embodiments of the subject matter described herein, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts.

[0038] Figure 1 It is a block diagram illustrating an example 5G system network architecture (such as a home 5G core (5GC) network). Figure 1 The architecture includes NRF 100 and SCP 101, which can reside within the same Home Public Land Mobile Network (PLMN). As described above, NRF 100 can maintain profiles of available producer NF service instances and their supported services, and allows consumer NFs or SCPs to subscribe to and be notified of new / updated producer NF service instance registrations. SCP 101 can also support service discovery and producer NF instance selection. SCP 101 can perform load balancing for connections between consumer NFs and producer NFs. Additionally, using the methods described herein, SCP 101 can perform selection and routing based on preferred NF locations.

[0039] NRF 100 is a repository for service profiles used by NFs or producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain an NF or service profile or a producer NF instance from NRF 100. An NF or service profile is a JavaScript Object Markup (JSON) data structure defined in 3GPP Technical Specification (TS) 29.510. The NF or service profile definition includes at least one of a Fully Qualified Domain Name (FQDN), an Internet Protocol (IP) version 4 (IPv4) address, or an IP version 6 (IPv6) address. Figure 1 In this context, any node (except NRF 100) can be either a consumer NF or a producer NF, depending on whether it is requesting or providing services. In the illustrated example, nodes include a Policy Control Function (PCF) 102 that performs policy-related operations in the network, a Unified Data Management (UDM) function 104 that manages user data, and an Application Function (AF) 106 that provides application services. Figure 1The nodes in the diagram further include a Session Management Function (SMF) 108, which manages the session between the Access and Mobility Management Function (AMF) 110 and the PCF 102. AMF 110 performs mobility management operations similar to those performed by the Mobility Management Entity (MME) in a 4G network. The Authentication Server Function (AUSF) 112 performs authentication services for user equipment (e.g., User Equipment (UE) 114) seeking network access.

[0040] The Network Slice Selection Function (NSSF) 116 provides network slicing services for devices seeking access to specific network capabilities and characteristics associated with a network slice. The Network Exposure Function (NEF) 118 provides an application programming interface (API) for application functions seeking information about Internet of Things (IoT) devices and other UEs attached to the network. NEF 118 performs functions similar to the Service Capability Exposure Function (SCEF) in 4G networks.

[0041] Radio Access Network (RAN) 120 connects UE 114 to the network via a radio link. This can be achieved using a gNode B (gNB). Figure 1 The UE 114 accesses the wireless access network 120 via a wireless access point (not shown) or other wireless access points. The User Plane Function (UPF) 122 can support various proxy functionalities for user plane services. An example of such proxy functionalities is the Multipath Transmission Control Protocol (MPTCP) proxy functionality. The UPF 122 can also support performance measurement functionalities, which the UE 114 can use to obtain network performance measurements. Figure 1 The diagram also illustrates Data Network (DN) 124, through which the UE accesses data network services such as Internet services.

[0042] The Secure Edge Protection Agent (SEPP) 126 filters incoming traffic from another PLMN and performs topology hiding on traffic leaving the home PLMN. SEPP 126 can communicate with the SEPP in the external PLMN that manages the security of that external PLMN. Therefore, traffic between NFs in different PLMNs can traverse two SEPP functions, one for the home PLMN and the other for the external PLMN.

[0043] SEPP 126 can utilize the N32-c and N32-f interfaces. The N32-c interface is the control plane interface between two SEPPs, used to perform initial handshakes (such as TLS handshakes) and negotiate various parameters for N32-f interface connections and related message forwarding. The N32-f interface is the forwarding interface between two SEPPs, used to forward various communications (such as 5GC request messages) between consumer NFs and producer NFs after application-level security protection.

[0044] One issue with existing 5G architectures is that they can allow NF instance IDs to be leaked to various entities. This could lead to or allow malicious entities to perform various malicious actions, such as unauthorized or improper NF deregistration request messages using the leaked or collected NF instance ID. For example, if a compromised NF in a trusted (but compromised or hacked) visitor PLMN (V-PLMN) can access a home PLMN (H-PLMN), the compromised NF might receive an NF instance ID used to identify a specific NF instance via the NF discovery process. In this example, the compromised NF in the trusted V-PLMN could use its NF instance ID obtained from the NF discovery process to spoof a specific NF instance and send an NF deregistration request message, thereby triggering or initiating a denial-of-service (DoS) attack. Therefore, even with existing authorization procedures, 5G architectures can benefit from enhanced security and / or related technologies that use temporary or pseudo-NF instance IDs instead of actual NF instance IDs, thereby mitigating NF instance ID leakage and related problems.

[0045] It should be understood that, Figure 1 This is for illustrative purposes, and the above is related to... Figure 1 All related nodes and / or modules, locations and / or functionalities can be changed, modified, added or removed.

[0046] Figure 2 This is a diagram illustrating an example network node 200 used to hide NF instance IDs in a 5G communication network. Node 200 can represent any suitable one or more entities for performing various aspects of authorization, registration, and / or security functions, such as hiding NF instance IDs and / or associated topology information. In some embodiments, node 200 can represent or include one or more 5GC NFs, such as NRF, SEPP, SCP, PCF, NSSF, NEF, Unified Data Repository (UDR), Binding Support Function (BSF), etc. In some embodiments, node 200 can represent or include consumer NFs or producer NFs. In some embodiments, node 200 can represent or include authorization servers, data repositories, network gateways, network proxies, edge security devices, or other functionalities.

[0047] In some embodiments, node 200 or related modules (e.g., security modules) may be configured (e.g., via programming logic) to detect, generate, acquire, or allocate pseudo-NF instance IDs during the NF registration process. For example, in the case where node 200 includes an NRF, node 200 or related modules may receive a 5G NF registration request message for registering a first NF instance, wherein the 5G NF registration request message includes the first NF instance ID. In this example, node 200 or related modules may determine one or more pseudo-NF instance IDs associated with the first NF instance ID, wherein each of the one or more pseudo-NF instance IDs can be used to refer to the first NF instance in place of the first NF instance ID. Continuing this example, node 200 or related modules may generate and send a 5G NF registration response message including the one or more pseudo-NF instance IDs.

[0048] In some embodiments, node 200 or related modules (e.g., security modules) can be configured to use pseudo NF instance IDs for various communication scenarios. For example, if node 200 includes NF instances that have registered with NRF 100 and received a set of assigned pseudo NF instance IDs from NRF 100 in a 5G NF registration response message, node 200 or related modules (e.g., security modules) can be configured to identify them using pseudo NF instance IDs in various 5G request messages (in addition to NF registration, NF update, and NF deregistration request messages) and respond to various 5G messages directed to one of the pseudo NF instance IDs associated with node 200.

[0049] refer to Figure 2 Node 200 may include one or more communication interfaces 202 for transmitting messages via a communication environment (e.g., a home 5GC network). For example, the communication interface(s) 202 may include a first communication interface for communicating with a first set of SEPPs 126 in the home network, a second communication interface for communicating with a second set of SEPPs 126 in the home network, and a third communication interface for communicating with other entities in the home network.

[0050] Node 200 may include a security module (SM) 204. SM 204 may be any suitable entity (e.g., software executing on at least one processor) for performing one or more aspects associated with the use and / or verification of a pseudo NF instance ID. In some embodiments, SM 204 may be configured to receive a 5G NF registration request message for registering a first NF instance (wherein the 5G NF registration request message includes the first NF instance ID) and to generate and send a 5G NF registration response message including one or more pseudo NF instance IDs associated with the first NF instance ID, wherein each of the one or more pseudo NF instance IDs may be used to refer to the first NF instance in place of the first NF instance ID.

[0051] In some embodiments, SM 204 can be configured to use pseudo NF instance IDs for various communication scenarios. For example, SM 204 can be configured to analyze one or more 5G messages to be sent and, at an appropriate time before sending, replace the NF instance ID with the corresponding pseudo NF instance ID, such as performing a replacement other than NF registration, NF update, and NF deregistration request messages. In this example, SM 204 can also be configured to verify that the pseudo NF instance ID is valid or appropriate for various received 5G messages.

[0052] In some embodiments, SM 204 may be configured to access or utilize a data store containing one or more associations between NF instance IDs and pseudo NF instance IDs. For example, SM 204 may be configured to: receive a service request message from a consumer NF instance for discovering a first NF instance; use the data store storing associations between NF instance IDs and associated pseudo NF instance IDs to determine a first pseudo NF instance ID among the one or more pseudo NF instance IDs associated with the first NF instance ID; and send the first pseudo NF instance ID to the consumer NF instance.

[0053] In some embodiments, SM 204 can be configured for message verification. For example, SM 204 can be configured to: receive a request message for performing an action associated with a first NF instance, wherein the request message includes an ID for the first NF instance; and use that ID and a data store storing the association between the NF instance ID and the associated pseudo-NF instance ID to determine whether the request message is valid or invalid. In this example, if the request message is deemed invalid, SM 204 can be configured to perform an invalid message action (e.g., discard the request message or notify the network operator or management system of the problem). Continuing with this example, if the request message is deemed valid, SM 204 can be configured to perform a valid message action (e.g., process the request message or forward the request message to another node for processing).

[0054] In some embodiments, SM 204 can determine that a request message is invalid by analyzing the message type of a received message and determining that the message type cannot be represented by a pseudo-NF instance ID. For example, SM 204 can determine that an NF registration request message, NF update request message, or NF deregistration request message that includes a pseudo-NF instance ID is invalid or improper, and can discard or otherwise ignore the request message.

[0055] In some embodiments, such as when node 200 is SEPP 126, SM 204 can be configured to monitor N32-f interface connections for inter-PLMN messages (e.g., HTTP / 2 messages) and verify these messages before sending them to another destination. For example, for a first inter-PLMN 5G NF deregistration message, SM 204 can determine that the request message is valid (e.g., the message includes a real or non-fake NF instance ID) and send it to NRF 100 for processing. In another example, for a second inter-PLMN 5G NF deregistration message, SM 204 can determine that the request message is invalid (e.g., the message includes a fake NF instance ID) and discard the request message or prevent it from being received by NRF 100.

[0056] Node 200 can access (e.g., read information from or write information to data store 206) data store 206. Data store 206 can be any suitable entity (e.g., computer-readable medium or memory) for storing various types of data. In some embodiments, data store 206 may include authentication information for user devices and / or information for hiding NF instance IDs or related message verification. For example, data store 206 may include data records or entries indicating the association between NF instance IDs and pseudo NF instance IDs. In some embodiments, data store 206 may include logic for obtaining, generating, or assigning pseudo NF instance IDs to NF instances, logic for obtaining NF instance identification information from various inter-PLMN messages, logic for performing message verification using stored authentication information, and / or logic for implementing or triggering invalid or valid message actions.

[0057] It should be understood that, Figure 2 The descriptions therein are for illustrative purposes, and node 200 may include additional and / or different modules, components, or functionalities.

[0058] Figure 3This is a message flow diagram illustrating an example NF discovery scenario involving NF instance IDs. In some embodiments, H-NRF 100 (without SM 204) can receive NF discovery request messages requesting NFs to provide specific services or information, and can provide NF discovery responses including NF instance IDs that identify a specific NF instance, such as where the NF instance ID is a unique identifier. In such embodiments, an external NF discovery requester (e.g., in V-PLMN 1 300) can receive actual (e.g., non-pseudo) NF instance IDs for communicating with various NF instances in the home network (e.g., H-PLMN 298), and therefore, nodes in V-PLMN 300 can learn or know the actual NF instance IDs of these NF instances.

[0059] refer to Figure 3 For example, prior to step 301, an NF registration procedure may occur for registering producer NF 296 (e.g., a specific NF instance). During or concurrently with the NF registration procedure, H-NRF 100 may store the NF instance ID associated with and provided by producer NF 296. For example, the NF instance ID associated with producer NF 296 may be globally unique within the PLMN (e.g., H-PLMN 298) of the H-NRF 100 where producer NF 296 is being registered. In this example, the NF instance ID can be used to identify, refer to, and / or communicate with producer NF 296.

[0060] In step 301, an NF discovery request message can be sent from consumer NF 294 to V-NRF 100 in V-PLMN 1 300 to request an NF instance that can provide specific services or related information from H-PLMN 298.

[0061] In step 302, an NF discovery request message can be sent from V-NRF 100 to V-SEPP 126 for forwarding to H-NRF 100 in H-PLMN 298.

[0062] In step 303, the NF discovery request message (e.g., as an HTTP / 2 message) can be forwarded from V-SEPP 126 to H-SEPP 126 via the N32-f interface.

[0063] In step 304, an NF discovery request message can be sent from H-SEPP 126 to H-NRF 100. For example, H-NRF 100 receives the NF discovery request message and selects a suitable NF instance (i.e., producer NF296) for providing services or information.

[0064] In step 305, an NF discovery response may be generated that includes or indicates the NF instance ID identifying producer NF 296, and the NF discovery response may be sent from H-NRF 100 to H-SEPP 126 for forwarding to V-PLMN 300.

[0065] In step 306, the NF discovery response (e.g., as an HTTP / 2 message) can be forwarded from H-SEPP126 to V-SEPP126 via the N32-f interface.

[0066] In step 307, the NF discovery response can be sent from V-SEPP 126 to V-NRF 100.

[0067] In step 308, the NF discovery response can be sent from V-NRF 100 to consumer NF 294.

[0068] In some embodiments, consumer NF 294 may use NF instance ID to request services or related data from producer 296 (e.g., via an SBI request message).

[0069] It should be understood that, Figure 3 This is for illustrative purposes and may use different and / or additional messages and / or actions. It should also be understood that the various messages and / or actions described herein may appear in different orders or sequences.

[0070] Figure 4 This is a message flow diagram illustrating the use of an example NF access token that includes an NF instance ID. In some embodiments, the H-NRF 100 (without SM 204) can provide an access token that includes an NF instance ID for identifying a specific NF instance, such as where the NF instance ID is a unique identifier. In such embodiments, an external access token requester (e.g., in V-PLMN 1 300) can receive the actual (e.g., non-pseudo) NF instance ID for communicating with various NF instances in the home network (e.g., H-PLMN 298), and therefore, nodes in the V-PLMN 300 can learn or know the actual NF instance IDs of these NF instances.

[0071] refer to Figure 4For example, prior to step 401, an NF registration procedure may occur for registering producer NF 296 (e.g., a specific NF instance). During or concurrently with the NF registration procedure, H-NRF 100 may store the NF instance ID associated with and provided by producer NF 296. For example, the NF instance ID associated with producer NF 296 may be globally unique within the PLMN (e.g., H-PLMN 298) of the H-NRF 100 where producer NF 296 is being registered. In this example, the NF instance ID can be used to identify, refer to, and / or communicate with producer NF 296.

[0072] In step 401, an access token request message can be sent from consumer NF 294 to V-NRF 100 in V-PLMN 1 300 to access services or related information from H-PLMN 298. For example, consumer NF 294 in V-PLMN 1 300 could represent a network node requesting an access token (e.g., an OAuth2 access token) in order to (e.g., from producer NF 296) receive services or related information from its home network.

[0073] In step 402, an access token request message can be sent from V-NRF 100 to V-SEPP 126 for forwarding to H-NRF 100 in H-PLMN 298.

[0074] In step 403, the access token request message (e.g., as an HTTP / 2 message) can be forwarded from V-SEPP 126 to H-SEPP 126 via the N32-f interface.

[0075] In step 404, an access token request message can be sent from H-SEPP 126 to H-NRF 100. For example, H-NRF 100 can receive the access token request message and select the appropriate NF instance (i.e., producer NF 296) for providing services or information.

[0076] In step 405, H-NRF 100 may generate an access token that includes or indicates the NF instance ID used to identify producer NF 296, and send the access token from H-NRF 100 to H-SEPP 126 in the access token response for forwarding to V-PLMN 300.

[0077] In step 406, the access token response (e.g., as an HTTP / 2 message) can be forwarded from H-SEPP 126 to V-SEPP 126 via the N32-f interface.

[0078] In step 407, the access token response can be sent from V-SEPP 126 to V-NRF 100.

[0079] In step 408, the access token response can be sent from V-NRF 100 to consumer NF 294.

[0080] In step 409, an SBI request message including an access token can be sent from consumer NF 294 to V-SEPP126 for forwarding to H-PLMN 298.

[0081] In step 410, the SBI request message (e.g., as an HTTP / 2 message) can be forwarded from V-SEPP 126 to H-SEPP 126 via the N32-f interface.

[0082] In step 411, the SBI request message can be sent from H-SEPP 126 to producer NF 296.

[0083] In step 412, for example after verifying the access token, an SBI response providing the requested service or information can be generated and sent from producer NF 296 to H-SEPP 126 for forwarding to V-PLMN 300.

[0084] In step 413, the SBI response (e.g., as an HTTP / 2 message) can be forwarded from H-SEPP126 to V-SEPP126 via the N32-f interface.

[0085] In step 414, the SBI response can be sent from V-SEPP 126 to consumer NF 294.

[0086] It should be understood that, Figure 4 This is for illustrative purposes and may use different and / or additional messages and / or actions. It should also be understood that the various messages and / or actions described herein may appear in different orders or sequences.

[0087] Figure 5 This is a diagram illustrating example ID data 500 indicating an NF instance ID and its associated pseudo-NF instance ID. For example, ID data 500 may indicate a mapping (e.g., association) between an NF instance ID and one or more pseudo-NF instance IDs. In some embodiments, the ID mapping or association may be statically configured by the operator or dynamically generated by the NRF 100 and can be shared with the NF. For example, during the NF registration process associated with an NF, the pseudo-NF instance ID assigned to the NF may be shared in the NF registration response sent to the NF.

[0088] In some embodiments, node 200, H-NRF 100, or SM 204 can be configured to assign pseudo-NF instance IDs based on various rules and / or logic. For example, H-NRF 100 can be configured to assign at least one unique pseudo-NF instance ID to an NF registered with H-NRF 100. In another example, H-NRF 100 can be configured to assign a set of 3 to 6 unique pseudo-NF instance IDs to an NF registered with H-NRF 100. In some embodiments, each pseudo-NF instance ID associated with or assigned to a particular NF instance can be non-contiguous and / or generated or assigned to reduce the likelihood that the corresponding actual (non-pseudo) NF instance ID can be derived or identified.

[0089] In some embodiments, an NF (e.g., producer NF 296) may store its own pseudo-NF instance ID and may use and / or provide one of these pseudo-NF instance IDs instead of its actual NF instance ID for identification. For example, when an NF is sending a 5GC request message, the NF may use one of its pseudo-NF instance IDs instead of its actual NF instance ID to identify itself. In this example, the NF may utilize a selection algorithm (e.g., based on polling, pseudo-random, request type, or time) to select a specific pseudo-NF instance ID from its set of pseudo-NF instance IDs. Continuing this example, the NF may use the same pseudo-NF instance ID to process transactions with the same node or network, for example, by storing state information and / or using a hash function.

[0090] refer to Figure 5 The table representing ID data 500 includes columns and / or fields for NF instance ID and corresponding pseudo-NF instance ID. The NF instance ID field may store information representing the NF instance ID that can be used to identify a specific NF instance. In some embodiments, each NF instance ID may be globally unique within the PLMN (e.g., H-PLMN 298) of the H-NRF 100 for which the corresponding NF instance is being registered. In some embodiments, the NF instance ID may be in the format of a Universally Unique Identifier (UUID) version 4, as described in IETF RFC 4122. For example, the NF instance ID "ID1" can represent a 128-bit UUID, where the 16 bytes (e.g., octets) of the UUID are represented as 32 hexadecimal digits, and these digits are displayed in the format 8-4-4-4-12, as five hyphen-separated groups, for a total of 36 characters (32 hexadecimal characters and 4 hyphens), such as "4947a69a-f61b-4bc1-b9da-47c9c5d14b64".

[0091] The pseudo-NF instance ID field can represent one or more pseudo-NF instance IDs assigned to and / or associated with the corresponding NF instance ID. In some embodiments, such as similar to the actual NF instance ID, each pseudo-NF instance ID can be globally unique within the PLMN (e.g., H-PLMN 298) of the H-NRF 100 that is registering the corresponding NF instance, but may be temporary (e.g., assigned to the same NF instance within its validity period or during registration) and may subsequently be reassigned to another NF instance (e.g., after an NF deregistration procedure). In some embodiments, the format of the pseudo-NF instance ID can be the same as the actual NF instance ID, such as the UUID version 4 format. For example, the pseudo instance ID “PID2” can represent a 128-bit UUID such as “5162f79a-c31b-4bc1-c8da-27e5c5d34b22”.

[0092] As shown in the figure, Figure 5 The first line in the table indicates the association between the NF instance ID "ID1" and the pseudo NF instance IDs "PID2", "PID4" and "PID7"; Figure 5 The second line in the text indicates the association between the NF instance ID "ID2" and the pseudo NF instance IDs "PID61", "PID40", "PID55", "PID32" and "PID34"; Figure 5 The third line in the text indicates the association between the NF instance ID "ID3" and the pseudo NF instance IDs "PID27", "PID21" and "PID25"; Figure 5 The fourth line in the text indicates the association between the NF instance ID "ID4" and the pseudo NF instance IDs "PID72", "PID29", "PID33" and "PID11"; Figure 5 The fifth line in the code indicates the association between the NF instance ID "ID5" and the pseudo NF instance IDs "PID16", "PID22", "PID64" and "PID96".

[0093] It should also be understood that ID data 500 is for illustrative purposes and can be used in addition to [other purposes]. Figure 5 Different and / or additional data beyond the data described herein may be used to indicate default values ​​for specific data portions or other information. Furthermore, various data structures and / or computer-readable media may be used to store (e.g., in data storage 206) and manage ID data 500.

[0094] Figure 6This is a diagram illustrating example ID usage data 600, indicating message types and the use of associated pseudo-NF instance IDs. ID usage data 600 can indicate various types of messages associated with 5G services (e.g., inter-PLMN messages) and whether a pseudo-NF instance ID can be used for authentication purposes. For example, when UE 114 roams in V-PLMN 1 300, various communications involving multiple NF instances can occur between V-PLMN 1 300 and H-PLMN 298. In this example, inter-PLMN messages can be sent between V-PLMN 1 300 and H-PLMN 298 via SEPP 126 in their respective networks. While some messages can successfully utilize pseudo-NF instance IDs, others (e.g., NF registration, NF update, and NF deregistration request messages) may require actual NF instance IDs to be successfully authenticated and processed. For example, H-NRF 100 can discard or ignore any NF registration, NF update, and NF deregistration request messages with pseudo-NF instance identifiers, thereby reducing the chance of malicious or hacked external nodes attempting to deregister network nodes.

[0095] In some embodiments, such as during message verification, node 200, H-NRF 100, or SM 204 can be configured to identify the message type of a received message (e.g., an inter-PLMN message) and use ID usage data 600 to determine whether the actual NF instance ID is included in the received message. If not, it determines whether the pseudo NF instance ID in the received message is acceptable or permitted. For example, if an NF subscription request message includes a pseudo NF instance ID identifying producer NF 296, node 200 or SM 204 may consider the NF subscription request message valid. However, if an NF update request message includes the same pseudo NF instance ID but does not include the actual NF instance ID associated with producer NF 296, node 200 or SM 204 may consider the NF update request message invalid (or improper).

[0096] refer to Figure 6 The table indicating that ID uses data 600 includes columns and / or fields for message type and pseudo-NF instance ID (e.g., indicating whether the pseudo-NF instance ID is available or allowed for the corresponding message type). The message type field can store information indicating the type of message associated with the NF instance. For example, Figure 6 The example message types described include NF registration messages, NF update messages, NF deregistration messages, NF discovery messages, NF profile messages, NF access token messages, and SBI messages.

[0097] The pseudo-NF instance ID field can indicate whether the pseudo-NF instance ID is available or allowed for the corresponding message type. For example, ... Figure 6 The use of fake NF instance IDs is not permitted in valid NF registration messages, NF update messages, and NF deregistration messages; however, the use of fake NF instance IDs is permitted in valid NF discovery messages, NF profile messages, NF access token messages, and SBI messages.

[0098] It should also be understood that the ID using data 600 is for illustrative purposes and can be used in addition to... Figure 6 Different and / or additional data beyond the data described herein may be used to indicate default values ​​for specific data sections or other information. Furthermore, various data structures and / or computer-readable media may be used to store (e.g., in data storage 206) and manage ID usage data 600.

[0099] Figure 7 This is a message flow diagram illustrating an example NF discovery scenario involving NF instance IDs. In some embodiments, H-NRF 100 or its SM 204 may receive NF discovery request messages requesting NFs to provide specific services or information, and may provide an NF discovery response including a pseudo NF instance ID to identify a specific NF instance, such as where the pseudo NF instance ID is one of a plurality of temporary instance IDs assigned during the NF registration process or predetermined by the network operator. In such embodiments, an external NF discovery requester (e.g., in V-PLMN 1 300) may receive a pseudo NF instance ID for communicating with various NF instances in the home network (e.g., H-PLMN 298), and therefore, nodes in V-PLMN 300 will not learn or know the actual NF instance IDs of these NF instances.

[0100] refer to Figure 7 For example, prior to step 701, an NF registration procedure may occur for registering producer NF 296 (e.g., a specific NF instance). During or concurrently with the NF registration procedure, one or more pseudo-NF instance IDs corresponding to producer NF 296 may be allocated and / or stored for use by one or more entities (e.g., H-NRF 100). For example, producer NF 296 may register with H-NRF 100 using NF instance ID “ID45” and may receive a set of pseudo-NF instance IDs from H-NRF 100, such as “PID23”, “PID44”, and “PID55”. In this example, this set of pseudo-NF instance IDs may be uniquely assigned to producer NF 296 within a predetermined time period or when producer NF 296 registers with its home network.

[0101] In step 701, an NF discovery request message can be sent from consumer NF 294 to V-NRF 100 in V-PLMN 1 300 to request an NF instance that can provide specific services or related information from H-PLMN 298.

[0102] In step 702, an NF discovery request message can be sent from V-NRF 100 to V-SEPP 126 for forwarding to H-NRF 100 in H-PLMN 298.

[0103] In step 703, the NF discovery request message (e.g., as an HTTP / 2 message) can be forwarded from V-SEPP 126 to H-SEPP 126 via the N32-f interface.

[0104] In step 704, an NF discovery request message can be sent from H-SEPP 126 to H-NRF 100.

[0105] In step 705, H-NRF 100 or SM 204 therein may receive an NF discovery request message, determine or select a suitable NF instance (i.e., producer NF 296) for providing services or information; and identify the corresponding pseudo NF instance ID used to identify producer NF 296.

[0106] In step 706, an NF discovery response, including or indicating a pseudo NF instance ID that identifies producer NF 296, can be sent from H-NRF 100 to H-SEPP 126 for forwarding to V-PLMN 300.

[0107] In step 707, the NF discovery response (e.g., as an HTTP / 2 message) can be forwarded from H-SEPP126 to V-SEPP126 via the N32-f interface.

[0108] In step 708, the NF discovery response can be sent from V-SEPP 126 to V-NRF 100.

[0109] At step 709, the NF discovery response can be sent from V-NRF 100 to consumer NF294.

[0110] In some embodiments, consumer NF 294 may use a pseudo NF instance ID to request services or related data from producer 296 (e.g., via an SBI request message).

[0111] It should be understood that, Figure 7This is for illustrative purposes and may use different and / or additional messages and / or actions. It should also be understood that the various messages and / or actions described herein may appear in different orders or sequences.

[0112] Figure 8 This is a message flow diagram illustrating the use of an example NF access token that includes a pseudo NF instance ID. In some embodiments, the H-NRF 100 or its SM 204 can be configured to provide an access token that includes a pseudo NF instance ID for identifying a specific NF instance, such that the pseudo NF instance ID is one of a plurality of temporary instance IDs assigned during the NF registration process or predetermined by the network operator. In such embodiments, an external NF discovery requester (e.g., in a V-PLMN 1 300) can receive a pseudo NF instance ID for communicating with various NF instances in the home network (e.g., H-PLMN 298), and therefore, nodes in the V-PLMN 300 will not learn or know the actual NF instance IDs of these NF instances.

[0113] refer to Figure 8 For example, prior to step 801, an NF registration procedure may occur for registering producer NF 296 (e.g., a specific NF instance). During or concurrently with the NF registration procedure, one or more pseudo-NF instance IDs corresponding to producer NF 296 may be allocated and / or stored for use by one or more entities (e.g., H-NRF 100). For example, producer NF 296 may register with H-NRF 100 using NF instance ID “ID45” and may receive a set of pseudo-NF instance IDs from H-NRF 100, such as “PID23”, “PID44”, and “PID55”. In this example, this set of pseudo-NF instance IDs may be uniquely assigned to producer NF 296 within a predetermined time period or when producer NF 296 registers with its home network.

[0114] In step 801, an access token request message can be sent from consumer NF 294 to V-NRF 100 in V-PLMN 1 300 to access services or related information from H-PLMN 298. For example, consumer NF 294 in V-PLMN 1 300 could represent a network node requesting an access token (e.g., an OAuth2 access token) in order to (e.g., from producer NF 296) receive services or related information from its home network.

[0115] In step 802, an access token request message can be sent from V-NRF 100 to V-SEPP 126 for forwarding to H-NRF 100 in H-PLMN 298.

[0116] In step 803, the access token request message (e.g., as an HTTP / 2 message) can be forwarded from V-SEPP 126 to H-SEPP 126 via the N32-f interface.

[0117] In step 804, an access token request message can be sent from H-SEPP 126 to H-NRF 100.

[0118] In step 805, H-NRF 100 or SM 204 therein may receive an access token message, select a suitable NF instance (e.g., producer NF 296) for providing services or information, and generate an access token that includes or indicates a pseudo NF instance ID for identifying the selected NF instance.

[0119] In step 806, an access token response including the access token can be generated and sent from H-NRF 100 to H-SEPP 126 for forwarding to V-PLMN 300.

[0120] In step 807, the access token response (e.g., as an HTTP / 2 message) can be forwarded from H-SEPP 126 to V-SEPP 126 via the N32-f interface.

[0121] In step 808, the access token response can be sent from V-SEPP 126 to V-NRF 100.

[0122] In step 809, the access token response can be sent from V-NRF 100 to consumer NF 294.

[0123] In step 810, an SBI request message including an access token can be sent from consumer NF 294 to V-SEPP126 for forwarding to H-PLMN 298.

[0124] In step 811, the SBI request message (e.g., as an HTTP / 2 message) can be forwarded from V-SEPP 126 to H-SEPP 126 via the N32-f interface.

[0125] In step 812, the SBI request message can be sent from H-SEPP 126 to producer NF 296.

[0126] In step 813, producer NF 296 may use the pseudo NF instance ID obtained from the access token in the received SBI request message for verification purposes. For example, producer NF 296 may store (e.g., by H-NRF 100 during the NF registration process) a set of pseudo NF instance IDs assigned to itself. In this example, producer NF 296 may verify that the received pseudo NF instance ID matches a pseudo NF instance ID in that set of pseudo NF instance IDs.

[0127] In step 814, for example after verifying the access token, an SBI response providing the requested service or information can be generated and sent from producer NF 296 to H-SEPP 126 for forwarding to V-PLMN 300.

[0128] In step 815, the SBI response (e.g., as an HTTP / 2 message) can be forwarded from H-SEPP126 to V-SEPP126 via the N32-f interface.

[0129] In step 816, the SBI response can be sent from V-SEPP 126 to consumer NF 294.

[0130] It should be understood that, Figure 8 This is for illustrative purposes and may use different and / or additional messages and / or actions. It should also be understood that the various messages and / or actions described herein may appear in different orders or sequences.

[0131] Figure 9This is a message flow diagram illustrating example verification of an NF deregistration request message. In some embodiments, the H-NRF100 or its SM 204 can be configured to perform message verification using an NF instance ID or a pseudo NF instance ID. For example, after the ID data associated with the first NF instance (NF1) 896 (e.g., the NF instance ID and the corresponding pseudo NF instance ID) is stored during the NF1 896 registration process, the H-NRF100 or its SM 204 can monitor ingress messages associated with the NF instance (e.g., PLMN-to-PLMN and / or HTTP / 2 messages) and can use the stored ID data to determine whether each of these ingress messages is valid before processing, forwarding, and / or responding to the ingress message. If H-NRF 100 or SM 204 determines that the NF instance ID or pseudo-NF instance ID in the message does not match the associated stored ID data or is not suitable for the message type, H-NRF 100 or SM 204 may consider the message invalid and perform invalid message actions, such as discarding one or more PLMNs and / or reporting the event to the network operator or network management system. If H-NRF 100 or SM 204 determines that the NF instance ID or pseudo-NF instance ID in the message matches the associated stored ID data and is suitable for the message type, H-NRF 100 or SM 204 may consider the message valid and perform valid message actions, such as allowing the reception and processing of inbound messages at the intended destination.

[0132] refer to Figure 9 For example, prior to step 901, an NF registration procedure for registering NF1 896 may occur. During or concurrently with the NF registration procedure, one or more pseudo-NF instance IDs corresponding to NF1 896 may be allocated and / or stored for use by one or more entities (e.g., H-NRF 100). For example, NF1 896 may register with H-NRF 100 using NF instance ID “ID1”, and may receive a set of pseudo-NF instance IDs from H-NRF 100, such as “PID1”, “PID2”, and “PID3”. In this example, this set of pseudo-NF instance IDs may be uniquely assigned to NF1 896 within a predetermined time period or when NF1 896 registers with its home network.

[0133] In some embodiments, after NF1 896 has registered with H-NRF 100, consumer NF instance (NF2) 898 may request an NF profile or related information (such as an NF instance ID) associated with a specific service or NF and attempt to abuse that message. For example, NF2 898 may be, or appear to be, a 5G NF instance located in V-PLMN 1 300. In this example, NF2 898 may be compromised, hacked, or otherwise configured to perform or attempt to perform malicious or improper actions, such as launching a DoS attack using a learned NF instance or a fake NF instance.

[0134] In step 901, an NF discovery request message for discovering NF instances that provide services or data can be sent from NF2898 to H-NRF 100 (e.g. via V-SEPP 126 and H-SEPP 126 (not shown)).

[0135] In step 902, after receiving the NF discovery request message, H-NRF 100 and / or SM 204 can identify the relevant NF instance (e.g., NF1 896) used to provide services or data, and can determine a pseudo NF instance ID “PID1” used to communicate with and / or refer to that NF instance. In this example, H-NRF 100 and / or SM 204 can generate an NF discovery response indicating the pseudo NF instance ID.

[0136] In step 903, an NF discovery response (e.g., as an HTTP / 2 message) including a pseudo NF instance ID “PID1” for communicating with NF1 896 and / or referring to NF1 896 can be sent from H-NRF 100 to NF2 898 (e.g., via V-SEPP 126 and H-SEPP 126 (not shown)).

[0137] In step 904, an NF deregistration request message for deregistering NF1 896 can be sent from NF2 898 to H-NRF100, and this NF deregistration request message may include a pseudo NF instance ID “PID1”. For example, NF2 898 in V-PLMN 1 300 may be compromised, hacked, or otherwise configured to attempt to deregister NF1 896. However, because NF2 898 does not know the actual NF instance ID of NF1 896 (e.g., “ID1”), NF2 898 uses the pseudo NF instance ID “PID1” to attempt to deregister NF1 896.

[0138] In step 905, H-NRF 100 or its SM 204 may receive the NF deregistration request message, execute a message verification procedure, determine that the NF deregistration request message is invalid, and perform an invalid message action, such as discarding the NF deregistration request message. For example, H-NRF 100 or SM 204 may identify that the NF deregistration request message lacks an actual or non-fake NF instance ID, thereby indicating that the NF deregistration request message is illegitimate or invalid (e.g., fraudulent), and should not be responded to.

[0139] In step 906, a second NF deregistration request for deregistering NF1896 can be sent from NF1896 to H-NRF100, and the NF deregistration request message may include its actual or non-pseudo NF instance ID "ID1".

[0140] In step 907, H-NRF 100 or its SM 204 may receive the second NF deregistration request message, execute a message verification procedure, determine that the second NF deregistration request message is valid, and perform an invalid message action. For example, H-NRF 100 or SM 204 may identify that the second NF deregistration request message includes an actual or non-fake NF instance ID, thereby indicating that the NF deregistration request message is valid and should be responded to.

[0141] In step 908, for example after determining that the second NF deregistration request message is valid, H-NRF 100 or SM204 can deregister NF1 896 and send an NF deregistration response to NF1 896 indicating that NF1 896 has been successfully deregistered.

[0142] It should be understood that, Figure 9 This is for illustrative purposes and may use different and / or additional messages and / or actions. It should also be understood that the various messages and / or actions described herein may appear in different orders or sequences.

[0143] Figure 10 This is a diagram illustrating an example process 1000 for hiding an NF instance ID in a communication network. In some embodiments, the example process 1000 or portions thereof described herein may be executed at a network node or by a network node (e.g., NRF100, node 200, SM 204 and / or another module, NF, or node).

[0144] In step 1002, an NF registration request message (e.g., a 5G NF registration request message) for registering a first NF instance can be received, wherein the NF registration request message includes a first NF instance ID for identifying the first NF instance.

[0145] In step 1004, a mapping between a first NF instance ID and at least one pseudo NF instance ID may be stored, wherein the data storage includes a mapping between NF instance IDs and related pseudo NF instance IDs.

[0146] In step 1006, an NF registration response message (e.g., a 5G NF registration response message) may be generated and sent, which includes at least one pseudo NF instance ID used to identify the first NF instance.

[0147] In some embodiments, the first NF can be configured to: receive from the NRF an NF registration response message including at least one pseudo NF instance ID for identifying the first NF instance, wherein each of the at least one pseudo NF instance ID is different from the first NF instance ID used to identify the first NF instance; store the at least one pseudo NF instance ID associated with the first NF instance ID; and use the first pseudo NF instance ID among the at least one pseudo NF instance IDs to identify the sender when sending a request or response message.

[0148] In some embodiments, an NF (e.g., H-NRF 100) may be configured to: receive a service request message from a consumer NF instance for discovering a first NF instance; use a data store that stores the association between NF instance IDs and associated pseudo NF instance IDs to determine a first pseudo NF instance ID from one or more pseudo NF instance IDs associated with the first NF instance ID; and send the first pseudo NF instance ID to the consumer NF instance.

[0149] In some embodiments, a consumer NF instance may use a first pseudo NF instance ID to request an access token, NF profile, or NF subscription associated with the first NF instance.

[0150] In some embodiments, a consumer NF instance may use a first pseudo NF instance ID to communicate with a first NF instance via SBI.

[0151] In some embodiments, a network node (e.g., H-NRF 100 or H-SEPP 126) may be configured to: receive a service request message for performing an action associated with a first NF instance, wherein the service request message includes an ID for the first NF instance; use the ID and a data store containing associations between the NF instance ID and related pseudo-NF instance IDs to determine whether the service request message is valid or invalid; in response to determining that the service request message is invalid, perform an invalid message action; and in response to determining that the service request message is valid, perform a valid message action.

[0152] In some embodiments, the network node used to verify the request message using the pseudo NF instance ID in the request message may include NRF, producer NF, PCR, BSF, SCP, NSSF, NEF, UDR, or 5GC NF.

[0153] In some embodiments, invalid message actions may include discarding the request message or notifying the network operator or management system.

[0154] In some embodiments, a service request message may include an NF registration request message, an NF update request message, or an NF deregistration request message.

[0155] In some embodiments, determining that a request message (e.g., an NF registration request message, an NF update request message, or an NF deregistration request message) is invalid includes determining that the ID in the service request message is one of one or more pseudo NF instance IDs associated with a first NF instance ID and that the pseudo NF instance ID is not permitted by the message or its message type.

[0156] It should be understood that process 1000 is for illustrative purposes and different and / or additional actions may be used. It should also be understood that the various actions described herein may appear in different orders or sequences.

[0157] It should be understood that while some aspects of the topics described herein have been discussed with reference to 5G networks, various other networks can utilize aspects of the topics described herein. For example, any network utilizing NF instance IDs or similar IDs can use the features, mechanisms, and techniques described herein to assign or associate pseudo or temporary identifiers, and use those pseudo or temporary IDs for various network interactions, such as inter-PLMN communication.

[0158] It should be understood that while some aspects of the topics described herein have been discussed with reference to NRF-related messages, various other messages may utilize pseudo-NF instance IDs or other aspects of the topics described herein. For example, a UECM registration request issued by the AMF may be identified using a pseudo-NF instance ID during UECM service registration. Furthermore, it should be understood that the pseudo-NF instance ID can be used in various message types, such as message payloads and / or headers. For example, the pseudo-NF instance ID may be part of access tokens and CCA tokens. In another example, the pseudo-NF instance ID may be in a Load Control Information (LCI) header or an Overload Control Information (OCI) header.

[0159] It should be noted that Node 200, SM 204, and / or the functionality described herein can constitute a dedicated computing device. Furthermore, Node 200, SM 204, and / or the functionality described herein can improve network security and / or message authentication techniques in communication networks. For example, by using pseudo-NF instance IDs and / or reducing the use of NF instance IDs to NF registration, NF update, and NF deregistration scenarios, malicious activities and their negative consequences (such as DoS attacks, customer data theft, etc.) can be mitigated and / or prevented. In this example, by utilizing one or more techniques and / or methods described herein, H-NRF 100 or SM 204 therein can prevent DoS attacks using leaked NF instance IDs to attempt unauthorized NF updates or NF deregistrations. Moreover, such techniques and / or methods described herein can be applied to multiple services or related interfaces, including, for example, nudm-sdm, nudm-uecm, npcf-uepolicy, nsmf-pdusession, nssf-nsselection, nnrf-disc, and / or nnrf-nfm.

[0160] The contents of each of the following references are incorporated herein in their entirety by reference to the extent that they differ from this document and to the extent that they supplement, explain, provide background or teach the methods, techniques and / or systems used in this document.

[0161] References:

[0162] 4.3GPP TS29.510; 3 rd Generation Partnership Project; TechnicalSpecification Group Core Network and Terminals; 5G System; Network FunctionRepository Services; Stage 3(Release 17),V17.1.0

[0163] (March 2021)

[0164] 5.3GPP TS 33.501; 3 rd Generation Partnership Project;TechnicalSpecification Group Services and System Aspects;Security Architecture andProcedures for the 5G System;(Release 17),V17.1.0

[0165] (March 2021)

[0166] 6.RFC 4122: A Universally Unique IDentifier(UUID)URN Namespace; Leach, P., Mealling, M. and Salz, R.; (2005).

[0167] It should be understood that various details of the currently disclosed subject matter can be changed without departing from the scope of the subject matter itself. Furthermore, the foregoing description is for illustrative purposes only and not for limiting purposes.

Claims

1. A method for hiding a Network Function (NF) instance identifier ID in a communication network, the method comprising: At the NF repository function NRF, which includes at least one processor: Receive an NF registration request message from the first NF for registering a first NF instance, wherein the NF registration request message includes a first NF instance identifier ID for identifying the first NF instance; The data store stores a mapping between a first NF instance ID and at least one pseudo NF instance ID, wherein the data store includes a mapping between NF instance IDs and associated pseudo NF instance IDs. Generate and send an NF registration response message to the first NF, including at least one pseudo NF instance ID used to identify the first NF instance; For ingress messages of different message types that include at least one pseudo NF instance ID at the NRF, the validity of the ingress message is determined based on whether the pseudo NF instance ID can be used or is allowed to be used for that message type. In response to determining that the ingress message is invalid, an invalid message action is performed; and In response to confirming that the incoming message is valid, execute the valid message action.

2. The method according to claim 1, comprising: At the first NF: Receive the NF registration response message from the NRF, which includes the at least one pseudo NF instance ID, wherein each of the at least one pseudo NF instance IDs is different from the first NF instance ID; Store the at least one pseudo NF instance ID associated with the first NF instance ID; as well as When sending a request or response message, the at least one pseudo NF instance ID is used to identify the sender.

3. The method according to claim 1 or claim 2, comprising: At the NRF: Receive an NF discovery request message from the consumer NF instance, which includes at least one query parameter; Use the at least one query parameter and the data repository to select an NF profile that includes the first pseudo-NF instance ID associated with the first NF instance; as well as Send an NF profile including the first pseudo NF instance ID to the consumer NF instance.

4. The method of claim 3, wherein the first pseudo NF instance ID can be used by the consumer NF instance to request an access token or NF subscription associated with the first NF instance.

5. The method of claim 3 or claim 4, wherein the first pseudo NF instance ID can be used by the consumer NF instance to communicate with the first NF instance via the service-based interface SBI.

6. The method according to any one of the preceding claims, comprising: At the NRF: Receive a service request message from the consumer NF instance for performing an action associated with the first NF instance, wherein the service request message includes the ID of the first NF instance; The ID and the data repository are used to determine whether the service request message is valid or invalid; In response to determining that the service request message is invalid, an invalid message action is performed; as well as In response to determining that the service request message is valid, a valid message action is performed.

7. The method of claim 6, wherein the invalid message action includes discarding the service request message or notifying the network operator or management system.

8. The method according to claim 6 or claim 7, wherein the service request message includes an NF registration request message, an NF update request message, or an NF deregistration request message.

9. The method of claim 8, wherein determining that the service request message is invalid includes determining that the ID in the service request message is one of the at least one pseudo NF instance ID associated with the first NF instance.

10. The method according to any one of the preceding claims, wherein the first NF includes a producer network function NF, a policy control function PCF, a binding support function BSF, a service communication proxy SCP, a security edge protection proxy SEPP, a network slice selection function NSSF, a network exposure function NEF, a unified data repository UDR, or a fifth-generation 5G core NF.

11. A system for hiding a Network Function (NF) instance identifier ID in a communication network, the system comprising: NF repository functionality NRF includes: At least one processor; and A security module, implemented by the at least one processor, is used for: Receive an NF registration request message from the first NF for registering a first NF instance, wherein the NF registration request message includes a first NF instance identifier ID for identifying the first NF instance; The data store stores a mapping between a first NF instance ID and at least one pseudo NF instance ID, wherein the data store includes a mapping between NF instance IDs and associated pseudo NF instance IDs. Generate and send an NF registration response message to the first NF, including at least one pseudo NF instance ID used to identify the first NF instance; For ingress messages of different message types that include at least one pseudo NF instance ID at the NRF, the validity of the ingress message is determined based on whether the pseudo NF instance ID can be used or is allowed to be used for that message type. In response to determining that the ingress message is invalid, an invalid message action is performed; and In response to confirming that the incoming message is valid, execute the valid message action.

12. The system of claim 11, comprising a first NF, wherein the first NF is configured as follows: Receive the NF registration response message from the NRF, which includes the at least one pseudo NF instance ID, wherein each of the at least one pseudo NF instance IDs is different from the first NF instance ID; Store the at least one pseudo-NF instance ID associated with the first NF instance ID; and When sending a request or response message, the at least one pseudo NF instance ID is used to identify the sender.

13. The system of claim 11 or claim 12, wherein the NRF is configured to: Receive an NF discovery request message from the consumer NF instance, which includes at least one query parameter; Use the at least one query parameter and the data store to select an NF profile that includes the first pseudo-NF instance ID associated with the first NF instance; and Send an NF profile including the first pseudo NF instance ID to the consumer NF instance.

14. The system of claim 13, wherein the first pseudo NF instance ID can be used by the consumer NF instance to request an access token or NF subscription associated with the first NF instance.

15. The system of claim 13 or claim 14, wherein the first pseudo NF instance ID can be used by the consumer NF instance to communicate with the first NF instance via a service-based interface (SBI).

16. The system according to any one of claims 11 to 15, wherein the NRF is configured to: Receive a service request message from the consumer NF instance for performing an action associated with the first NF instance, wherein the service request message includes the ID of the first NF instance; The ID and the data repository are used to determine whether the service request message is valid or invalid; In response to determining that the service request message is invalid, an invalid message action is performed; as well as In response to determining that the service request message is valid, a valid message action is performed.

17. The system of claim 16, wherein the invalid message action includes discarding the service request message or notifying the network operator or management system.

18. The system of claim 16 or claim 17, wherein the service request message includes an NF registration request message, an NF update request message, or an NF deregistration request message, and wherein determining that the service request message is invalid includes determining that the ID in the service request message is one of the at least one pseudo NF instance ID associated with the first NF instance.

19. The system according to any one of claims 11 to 18, wherein the first NF includes a producer network function NF, a policy control function PCF, a binding support function BSF, a service communication proxy SCP, a secure edge protection proxy SEPP, a network slice selection function NSSF, a network exposure function NEF, a unified data repository UDR, or a fifth-generation 5G core NF.

20. A non-transitory computer-readable medium having executable instructions stored thereon, the executable instructions, when executed by at least one processor of a computer, causing the computer to perform the following steps: At the Network Function NF Repository Function NRF, which includes at least one processor: Receive an NF registration request message from the first NF for registering a first NF instance, wherein the NF registration request message includes a first NF instance identifier ID for identifying the first NF instance; The data store stores a mapping between a first NF instance ID and at least one pseudo NF instance ID, wherein the data store includes a mapping between NF instance IDs and associated pseudo NF instance IDs. Generate and send an NF registration response message to the first NF, including at least one pseudo NF instance ID used to identify the first NF instance; For ingress messages of different message types that include at least one pseudo NF instance ID at the NRF, the validity of the ingress message is determined based on whether the pseudo NF instance ID can be used or is allowed to be used for that message type. In response to determining that the ingress message is invalid, an invalid message action is performed; and In response to confirming that the incoming message is valid, execute the valid message action.

Images