Method, system, and computer-readable medium for hiding network function instance identifiers

Abstract

A method, system, and computer-readable medium for hiding a network function (NF) instance identifier (ID) in a communication network are disclosed. One method for hiding a NF instance ID in a communication network is performed in an NF repository function (NRF) having at least one processor. The method includes receiving an NF registration request message from a first NF to register a first NF instance of the first NF, the NF registration request message including the first NF instance ID for identifying the first NF instance, the method further includes storing a mapping between the first NF instance ID and at least one pseudo NF instance ID in a data store, the data store including the mapping between the NF instance ID and the associated pseudo NF instance ID, and the method further includes generating and sending to the first NF a NF registration response message including the at least one pseudo NF instance ID for identifying the first NF instance.

Description

[Technical Field]

[0001] Priority claims This application claims the benefit of priority to U.S. Patent Application No. 17 / 314,300, filed May 7, 2021, the entire disclosure of which is incorporated herein by reference.

[0002] Technical Field The subject matter described herein relates to enhancing security in fifth generation (5G) and subsequent generation communication networks. More particularly, the subject matter described herein relates to methods, systems, and computer-readable media for hiding network function (NF) instance identifiers (IDs) in fifth generation (5G) and subsequent generation communication networks. [Background technology]

[0003] background In fifth-generation (5G) communication networks, a network node that provides a service is referred to as a producer Network Function (NF). A network node that consumes a service is referred to as a consumer NF. A network function can be both a producer NF and a consumer NF, depending on whether it is consuming or providing a service.

[0004] A given producer NF may have many service endpoints, which are contact points for one or more NF instances hosted by the producer NF. A service endpoint is identified by an Internet Protocol (IP) address and port number, or a combination of a fully qualified domain name that resolves to an IP address and a port number on the network node hosting the producer NF. An NF instance is an instance of a producer NF that provides a service. A given producer NF may include two or more NF instances. Note also that multiple NF instances can share the same service endpoint.

[0005] Producer NFs register with the NF Repository Function (NRF). The NRF maintains service profiles of available NF instances that identify the services supported by each NF instance. Consumer NFs may subscribe to receive information about producer NF instances that have registered with the NRF. In addition to consumer NFs, another type of network node that may subscribe to receive information about NF service instances is the service communication proxy (SCP). The SCP subscribes to the NRF to obtain reachability and service profile information about producer NF service instances. Consumer NFs connect to the service communication proxy, which either load balances traffic among producer NF service instances that offer the required service or routes traffic directly to the destination producer NF instance.

[0006] In addition to SCPs, other examples of intermediate proxy nodes or groups of network nodes that route traffic between producer and consumer NFs include security edge protection proxies (SEPPs), service gateways, and nodes in a 5G service mesh. SEPPs are network nodes used to protect control plane traffic exchanged between different 5G public land mobile networks (PLMNs). As such, SEPPs perform varying amounts of message filtering, policing, and topology hiding on application programming interface (API) messages.

[0007] However, improved security measures are needed in one or more NFs. Summary of the Invention

[0008] overview A method, system, and computer-readable medium for hiding Network Function (NF) instance identifiers (IDs) in a communication network are disclosed. One method for hiding NF instance IDs in a communication network is performed in an NF repository function (NRF) having at least one processor. The method includes receiving an NF registration request message from a first NF to register a first NF instance of the first NF, the NF registration request message including the first NF instance ID for identifying the first NF instance, the method further includes storing a mapping between the first NF instance ID and at least one pseudo NF instance ID in a data store, the data store including the mapping between the NF instance IDs and associated pseudo NF instance IDs, and the method further includes generating and transmitting an NF registration response message to the first NF, the NF registration response message including the at least one pseudo NF instance ID for identifying the first NF instance.

[0009] One exemplary system for hiding NF instance IDs in a communication network includes an NRF with at least one processor and a memory, wherein the NRF is configured to receive an NF Registration Request message from a first NF requesting to register a first NF instance of the first NF, the NF Registration Request message including the first NF instance ID for identifying the first NF instance, the NRF is configured to store a mapping between the first NF instance ID and at least one pseudo NF instance ID in a data store, the data store including the mapping between the NF instance IDs and associated pseudo NF instance IDs, and the NRF is configured to generate and send to the first NF a NF Registration Response message including the at least one pseudo NF instance ID for identifying the first NF instance.

[0010] One exemplary non-transitory computer-readable medium includes computer-executable instructions embodied in the non-transitory computer-readable medium, which, when executed by at least one processor of at least one computer, cause the at least one computer to perform steps including receiving, from a first NF, an NF registration request message requesting to register a first NF instance of the first NF, the NF registration request message including a first NF instance ID for identifying the first NF instance, storing a mapping between the first NF instance ID and at least one pseudo NF instance ID in a data store, the data store including the mapping between the NF instance IDs and associated pseudo NF instance IDs, and generating and sending to the first NF a NF registration response message including the at least one pseudo NF instance ID for identifying the first NF instance.

[0011] According to one aspect of the subject matter described herein, a first NF may 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 of the first NF, wherein each of the at least one pseudo NF instance ID is different from the first NF instance ID for identifying the first NF instance, and the first NF may be configured to store the at least one pseudo NF instance ID associated with the first NF instance ID and to use the first pseudo NF instance ID of the at least one pseudo NF instance ID for source identification when sending a request or response message.

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

[0013] According to one aspect of the subject matter described herein, the first pseudo NF instance ID may be usable by a consumer NF instance to request an access token, an NF profile, or an NF subscription associated with the first NF instance.

[0014] According to one aspect of the subject matter described herein, the first pseudo NF instance ID may be usable by a consumer NF instance to communicate with the first NF instance over a service-based interface (SBI).

[0015] According to one aspect of the subject matter described herein, an NRF may be configured to receive a service request message for performing an action associated with a first NF instance, the service request message including an ID of the first NF instance, and the NRF may be configured to: determine, using a data store containing an association between the ID and the NF instance ID and an associated pseudo NF instance ID, whether the service request message is valid or invalid; perform an invalid message action in response to a determination that the service request message is invalid; and perform the action associated with the first NF instance in response to a determination that the service request message is valid.

[0016] According to one aspect of the subject matter described herein, an NF that hides an 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 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 5GC NF.

[0017] According to one aspect of the subject matter described herein, the invalid message action may include discarding the request message or notifying a network operator or management system.

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

[0019] According to one aspect of the subject matter described herein, determining that a service 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 an ID in the service request message is one of one or more pseudo NF instance IDs associated with the first NF instance ID.

[0020] The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. Thus, the terms "function," "node," or "module" as used herein refer to hardware that may also include software and / or firmware components for implementing the described features. In one exemplary embodiment, the subject matter described herein may be implemented using a computer-readable medium storing computer-executable instructions that, when executed by a computer's processor, control a computer to perform steps. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application-specific integrated circuits. Additionally, computer-readable media implementing the subject matter described herein may be located on a single device or computing platform or distributed across multiple devices or computing platforms.

[0021] The subject matter described herein will now be described with reference to the accompanying drawings. [Brief explanation of the drawings]

[0022] [Figure 1] FIG. 1 is a network diagram illustrating an exemplary fifth-generation (5G) network architecture. [Figure 2] FIG. 1 illustrates an example network node for hiding a network function (NF) instance identifier (ID) in a 5G communication network. [Figure 3] FIG. 10 is a message flow diagram illustrating an example NF discovery scenario with NF instance ID. [Figure 4] FIG. 10 is a message flow diagram illustrating the use of an exemplary NF access token including an NF instance ID. [Figure 5]FIG. 10 illustrates exemplary ID data showing NF instance IDs and associated pseudo NF instance IDs. [Figure 6] FIG. 10 illustrates exemplary ID usage data showing the use of message types and associated pseudo NF instance IDs. [Figure 7] FIG. 10 is a message flow diagram illustrating an example NF discovery scenario involving pseudo NF instance IDs. [Figure 8] FIG. 10 is a message flow diagram illustrating the use of an exemplary NF access token including a pseudo NF instance ID. [Figure 9] FIG. 10 is a message flow diagram illustrating an example validation of an NF deregistration request message. [Figure 10] 10 is a flowchart illustrating an example process for hiding NF instance IDs in a communication network. DETAILED DESCRIPTION OF THE INVENTION

[0023] Detailed Description The subject matter described herein relates to a method, system, and computer-readable medium 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, an NF repository function (NRF) uses the NF instance ID for NF management, NF discovery, and NF access token services. Additionally, consumer NFs use the NF instance ID for client credential assertion (CCA)-based client authentication. NFs also use the NF instance ID to share their identity; for example, an access and mobility management function (AMF) uses its NF instance ID during UE context management (UECM) service registration. Because the NF instance ID uniquely identifies an NF, exposing the NF instance ID outside of their public land mobile network (PLMN) may implicitly expose the PLMN's topology to the outside world. For example, the NF instance ID may be leaked from the visited network due to security compromises within the visited network, such as not using Transport Layer Security (TLS) between NFs.

[0024] Although the Security Edge Protection Proxy (SEPP) provides some security measures for inter-PLMN communications, the SEPP cannot hide the NF instance ID because the NF instance ID can be embedded in the access token, which cannot be altered due to the JSON Web Signature (JWS) signature. Furthermore, the NF instance ID is used for NF update and NF deregistration service operations. Therefore, a leaked NF instance ID can be exploited (e.g., by a hacker) in a denial-of-service (DoS) attack, for example, by sending an unauthorized NF update or NF deregistration request message.

[0025] According to 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, an NRF according to various aspects described herein may generate and / or assign a pseudo NF instance ID during NF registration of an NF. In this example, the pseudo NF instance ID may be shared with the NF in an NF registration response. In some embodiments, the pseudo NF instance ID may be used to identify the NF in various scenarios (e.g., inter-PLMN communications), thereby mitigating NF instance ID leakage and associated misuse. In some embodiments, for example, to further mitigate NF instance ID misuse, actual NF instance IDs (rather than pseudo NF instance IDs) may be used for NF registration, NF update, and NF deregistration.

[0026] Advantageously, by utilizing one or more techniques, systems, and / or methods described herein, an NRF or other entity may enhance security (e.g., prevent DoS attacks or other malicious actions) by using pseudo NF instance IDs and / or reducing the use of NF instance IDs for NF registration, NF update, and NF deregistration scenarios.

[0027] 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 numbers will be used throughout the drawings to refer to the same or like parts.

[0028] FIG. 1 is a block diagram illustrating an example 5G system network architecture, e.g., a Home 5G Core (5GC) network. The architecture of FIG. 1 includes an NRF 100 and an SCP 101, which may be located within the same home public land mobile network (PLMN). As described above, the NRF 100 maintains profiles of available producer NF service instances and their supported services, allowing consumer NFs or SCPs to subscribe to new / updated producer NF service instances and be notified of their registrations. The SCP 101 can also support service discovery and selection of producer NF instances. The SCP 101 can perform load balancing of connections between consumer NFs and producer NFs. Additionally, using the methodologies described herein, the SCP 101 can perform preferred NF location-based selection and routing.

[0029] The NRF 100 is a repository of NF or service profiles of producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain the NF or service profile or the producer NF instance from the NRF 100. The NF or service profile is a JavaScript Object Notation (JSON) data structure defined in 3rd Generation Partnership Project (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. In FIG. 1, any of the nodes (other than the NRF 100) can be either a consumer NF or a producer NF depending on whether they are requesting or providing a service. In the illustrated example, the node includes a Policy Control Function (PCF) 102 that enforces policy-related operations in the network, a User Data Management (UDM) Function 104 that manages user data, and an Application Function (AF) 106 that provides application services. The node shown in Figure 1 further includes a Session Management Function (SMF) 108 that manages sessions between an Access and Mobility Management Function (AMF) 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by a Mobility Management Entity (MME) in a 4G network. An Authentication Server Function (AUSF) 112 performs authentication services for user devices, such as User Equipment (UE) 114, that are seeking access to the network.

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

[0031] The radio access network (RAN) 120 connects the UE 114 to a network via a wireless link. The radio access network 120 may be accessed using a gNodeB (gNB) (not shown in FIG. 1) or other wireless access point. The user plane function (UPF) 122 may support various proxy functions for user plane services. One example of such a proxy function is a multipath transmission control protocol (MPTCP) proxy function. The UPF 122 may also support a performance measurement function that may be used by the UE 114 to obtain network performance measurements. Also shown in FIG. 1 is a data network (DN) 124 through which the UE accesses data network services, such as Internet services.

[0032] The Security Edge Protection Proxy (SEPP) 126 filters incoming traffic from another PLMN and enforces topology hiding for traffic exiting the home PLMN. The SEPP 126 can communicate with a SEPP in a foreign PLMN that manages the security of the foreign PLMN. Thus, traffic between NFs in different PLMNs can traverse two SEPP functions, one for the home PLMN and the other for the foreign PLMN.

[0033] The SEPP 126 may utilize an N32-c interface and an N32-f interface. The N32-c interface is a control plane interface between two SEPPs that can be used to perform an initial handshake (e.g., a TLS handshake) and negotiate various parameters of the N32-f interface connection and associated message transfer. The N32-f interface is a transport interface between two SEPPs that can be used to transport various communications (e.g., 5GC request messages) between consumer and producer NFs after applying application-level security protections.

[0034] One challenge with the existing 5G architecture is that it may allow NF instance IDs to be leaked to various entities, potentially contributing to or enabling malicious entities to perform various malicious actions, such as using the leaked or harvested NF instance ID to perform unauthorized or inappropriate NF deregistration request messages for NF instances. 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 may receive an NF instance ID to identify a specific NF instance via an NF discovery procedure. In this example, the compromised NF in the trusted V-PLMN may trigger or launch a denial of service (DOS) attack by spoofing a specific NF instance using the NF instance ID obtained from the NF discovery procedure and sending an NF deregistration request message. Therefore, even with existing authentication procedures, 5G architectures may benefit from security enhancements and / or related techniques that use temporary or pseudo NF instance IDs instead of real NF instance IDs, thereby mitigating NF instance ID leakage and related abuse.

[0035] It will be appreciated that FIG. 1 is for illustrative purposes and that the various nodes and / or modules, locations, and / or functions described above in connection with FIG. 1 may be changed, modified, added, or deleted.

[0036] 2 illustrates an example network node 200 for hiding NF instance IDs in a 5G communications network. Node 200 may represent any suitable entity or entities for implementing various aspects of authentication, registration, and / or security functions, e.g., hiding NF instance IDs and / or associated topology information. In some embodiments, node 200 may represent or include one or more 5GC NFs, e.g., an NRF, a SEPP, an SCP, a PCF, an NSSF, an NEF, a Unified Data Repository (UDR), a Binding Support Function (BSF), etc. In some embodiments, node 200 may represent or include a consumer NF or a producer NF. In some embodiments, node 200 may represent or include an authentication server, a data repository, a network gateway, a network proxy, an edge security device, or other function.

[0037] In some embodiments, node 200 or an associated module (e.g., a security module) may be configured (e.g., via programming logic) to detect, generate, obtain, or assign a pseudo NF instance ID during an NF registration procedure. For example, if node 200 includes an NRF, node 200 or an associated module may receive a 5G NF Registration Request message for registering a first NF instance, the 5G NF Registration Request message including the first NF instance ID. In this example, node 200 or an associated module may determine one or more pseudo NF instance IDs associated with the first NF instance ID, each of the one or more pseudo NF instance IDs usable to refer to the first NF instance in place of the first NF instance ID. Continuing with this example, node 200 or an associated module may generate and transmit a 5G NF Registration Response message including the one or more pseudo NF instance IDs.

[0038] In some embodiments, node 200 or an associated module (e.g., a security module) may be configured to use pseudo NF instance IDs for various communication scenarios. For example, if node 200 includes an NF instance registered with NRF 100 and receives a set of assigned pseudo NF instance IDs in a 5G NF Registration Response message from NRF 100, node 200 or an associated module (e.g., a security module) may be configured to use the pseudo NF instance IDs for identification in various 5G request messages (excluding NF Registration, NF Update, and NF Deregistration Request messages) and to respond to various 5G messages targeted to one of the pseudo NF instance IDs associated with node 200.

[0039] 2, node 200 may include one or more communication interfaces 202 for communicating messages over a communication environment, e.g., a home 5GC network. For example, communication interface 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.

[0040] 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 implementing one or more aspects associated with using and / or validating pseudo NF instance IDs. In some embodiments, SM 204 may be configured to receive a 5G NF Registration Request message for registering a first NF instance, the 5G NF Registration Request message including the first NF instance ID, and SM 204 may be configured to generate and transmit a 5G NF Registration Response message including one or more pseudo NF instance IDs associated with the first NF instance ID, each of the one or more pseudo NF instance IDs usable to refer to the first NF instance in place of the first NF instance ID.

[0041] In some embodiments, SM204 may be configured to use the pseudo NF instance ID for various communication scenarios. For example, SM204 may be configured to analyze one or more transmitted 5G messages and, when appropriate, replace the NF instance ID with the corresponding pseudo NF instance ID before transmission, e.g., when performing the replacement except for NF Registration, NF Update, and NF Deregistration Request messages. In this example, SM204 may also be configured to verify that the pseudo NF instance ID is valid or appropriate for various received 5G messages.

[0042] In some embodiments, SM204 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, SM204 may be configured to receive a service request message to discover a first NF instance from a consumer NF instance, determine a first pseudo NF instance ID of the one or more pseudo NF instance IDs associated with the first NF instance ID using the data store that stores associations between NF instance IDs and associated pseudo NF instance IDs, and send the first pseudo NF instance ID to the consumer NF instance.

[0043] In some embodiments, SM204 may be configured for message validation. For example, SM204 may be configured to receive a request message to perform an action associated with a first NF instance, the request message including an ID of the first NF instance, and SM204 may be configured to determine whether the request message is valid or invalid using a data store that stores the ID and an association between the NF instance ID and the associated pseudo NF instance ID. In this example, if the request message is deemed invalid, SM204 may be configured to perform an invalid message action (e.g., discard the request message or notify a network operator or management system about this issue). Continuing with this example, if the request message is deemed valid, SM204 may be configured to perform a valid message action (e.g., process the request message or forward the request message to another node for processing).

[0044] In some embodiments, SM204 may determine that the request message is invalid by analyzing the message type of the received message and determining that the message type cannot use a pseudo NF instance ID. For example, SM204 may determine that an NF Registration Request message, an NF Update Request message, or an NF Deregistration Request message that includes a pseudo NF instance ID is invalid or inappropriate, and may discard or otherwise ignore the request message.

[0045] In some embodiments, for example, when node 200 is a SEPP 126, SM 204 may be configured to monitor the N32-f interface connection for inter-PLMN messages (e.g., HTTP / 2 messages) and validate the messages before sending them to another destination. For example, for a first inter-PLMN 5G NF deregistration message, SM 204 may determine that the request message is valid (e.g., the message includes a real or non-pseudo 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 may determine that the request message is invalid (e.g., the message includes a pseudo NF instance ID) and discard the request message or prevent it from being received by NRF 100.

[0046] Node 200 may access data store 206 (e.g., read information from and / or write information to data store 206). Data store 206 may be any suitable entity (e.g., a computer-readable medium or memory) for storing various data. In some embodiments, data store 206 may include user device authentication information and / or related information used for NF instance ID concealment or associated message validation. For example, data store 206 may include data records or entries indicating an association between an NF instance ID and a pseudo NF instance ID. 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 validation using the stored authentication information, and / or logic for performing or triggering invalid or valid message actions.

[0047] It will be appreciated that FIG. 2 and the associated description are for illustrative purposes, and that node 200 may include additional and / or different modules, components, or functionality.

[0048] 3 is a message flow diagram illustrating an example NF discovery scenario involving NF instance IDs. In some embodiments, the H-NRF 100 (without the SM 204) may receive an NF discovery request message requesting an NF to provide a particular service or information, and may provide an NF discovery response including an NF instance ID to identify the particular NF instance, e.g., if the NF instance ID is a unique identifier. In such embodiments, an external NF discovery requester (e.g., in the V-PLMN1 300) may receive actual (e.g., non-pseudo) NF instance IDs for communicating with various NF instances in the home network (e.g., the H-PLMN 298), and thus, nodes in the V-PLMN 300 may learn or know the actual NF instance IDs of those NF instances.

[0049] 3, for example, before step 301, an NF registration procedure may be performed to register the producer NF 296 (e.g., a particular NF instance). During or concurrently with the NF registration procedure, the H-NRF 100 may store an NF instance ID associated with and provided by the producer NF 296. For example, the NF instance ID associated with the producer NF 296 may be globally unique within the PLMN (e.g., H-PLMN 298) of the H-NRF 100 in which the producer NF 296 is registered. In this example, the NF instance ID may be usable to identify, reference, and / or communicate with the producer NF 296.

[0050] In step 301, an NF discovery request message may be sent from consumer NF 294 to V-NRF 100 within V-PLMN1 300 to request an NF instance that can provide a particular service or related information from H-PLMN 298.

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

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

[0053] In step 304, an NF discovery request message may be sent from the H-SEPP 126 to the H-NRF 100. For example, the H-NRF 100 receives the NF discovery request message and selects an appropriate NF instance, i.e., a producer NF 296, for providing the service or information.

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

[0055] In step 306, the NF discovery response (eg, as an HTTP / 2 message) may be forwarded from the H-SEPP 126 to the V-SEPP 126 via the N32-f interface.

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

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

[0058] In some embodiments, the consumer NF 294 may use the NF instance ID to request a service or related data from the producer 296, for example, via an SBI request message.

[0059] It will be appreciated that Figure 3 is for illustrative purposes and that different and / or additional messages and / or actions may be used. It will also be appreciated that the various messages and / or actions described herein may occur in a different order or sequence.

[0060] 4 is a message flow diagram illustrating the use of an exemplary NF access token including an NF instance ID. In some embodiments, the H-NRF 100 (without the SM 204) may provide an access token including an NF instance ID to identify a particular NF instance, e.g., if the NF instance ID is a unique identifier. In such embodiments, an external access token requestor (e.g., in the V-PLMN1 300) may receive actual (e.g., non-pseudo) NF instance IDs for communicating with various NF instances in the home network (e.g., the H-PLMN 298), and thus, nodes in the V-PLMN 300 may learn or know the actual NF instance IDs of those NF instances.

[0061] 4, for example, before step 401, an NF registration procedure may be performed to register the producer NF 296 (e.g., a particular NF instance). During or concurrently with the NF registration procedure, the H-NRF 100 may store an NF instance ID associated with and provided by the producer NF 296. For example, the NF instance ID associated with the producer NF 296 may be globally unique within the PLMN (e.g., H-PLMN 298) of the H-NRF 100 in which the producer NF 296 is registered. In this example, the NF instance ID may be usable to identify, reference, and / or communicate with the producer NF 296.

[0062] In step 401, an access token request message may be sent from a consumer NF 294 in V-PLMN1 300 to V-NRF 100 to access a service or related information from H-PLMN 298. For example, consumer NF 294 in V-PLMN1 300 may represent a network node that requests an access token (e.g., an OAuth2 access token) to receive a service or related information in a home network from producer NF 296, for example.

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

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

[0065] In step 404, the access token request message may be sent from the H-SEPP 126 to the H-NRF 100. For example, the H-NRF 100 may receive the access token request message and select an appropriate NF instance, i.e., the producer NF 296, to provide the service or information.

[0066] In step 405, the H-NRF100 may generate an access token that includes or indicates an NF instance ID to identify the producer NF296, and may send the access token from the H-NRF100 to the H-SEPP126 in an access token response for forwarding to the V-PLMN300.

[0067] In step 406, the access token response (eg, as an HTTP / 2 message) may be transferred from H-SEPP 126 to V-SEPP 126 via the N32-f interface.

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

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

[0070] In step 409, an SBI request message including the access token may be sent from the consumer NF 294 to the V-SEPP 126 for forwarding to the H-PLMN 298.

[0071] In step 410, the SBI request message (eg, as an HTTP / 2 message) may be transferred from V-SEPP 126 to H-SEPP 126 via the N32-f interface.

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

[0073] In step 412, for example, after validating the access token, an SBI response providing the requested service or information may be generated and sent from the producer NF296 to the H-SEPP126 for forwarding to the V-PLMN300.

[0074] In step 413, the SBI response (eg, as an HTTP / 2 message) may be transferred from H-SEPP 126 to V-SEPP 126 via the N32-f interface.

[0075] In step 414, the SBI response may be transmitted from the V-SEPP 126 to the consumer NF 294.

[0076] 4 is for illustrative purposes and that different and / or additional messages and / or actions may be used. It will also be appreciated that the various messages and / or actions described herein may occur in a different order or sequence.

[0077] 5 is a diagram illustrating example ID data 500 indicating NF instance IDs and associated pseudo NF instance IDs. For example, the 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 an operator or dynamically generated by the NRF 100 and shared with the NF. For example, during an NF registration procedure 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.

[0078] In some embodiments, node 200, H-NRF 100, or SM 204 may be configured to assign pseudo NF instance IDs based on various rules and / or logic. For example, H-NRF 100 may be configured to assign at least one unique pseudo NF instance ID to an NF that registers with H-NRF 100. In another example, H-NRF 100 may be configured to assign a set of three to six unique pseudo NF instance IDs to an NF that registers with H-NRF 100. In some embodiments, each pseudo NF instance ID associated with or assigned to a particular NF instance may be non-contiguous and / or may be generated or assigned to reduce the likelihood of being able to guess or figure out the corresponding actual (non-pseudo) NF instance ID.

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

[0080] 5, a table representing ID data 500 includes columns and / or fields for NF instance IDs and corresponding pseudo NF instance IDs. The NF instance ID field may store information to represent an NF instance ID that can be used to identify a particular 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 to which the corresponding NF instance is registered. In some embodiments, the format of the NF instance ID may be a Universally Unique Identifier (UUID) version 4, as described in IETF RFC 4122. For example, the NF instance ID "ID1" may represent a 128-bit UUID, with 16 bytes (e.g., octets) of the UUID represented as 32 hexadecimal digits, which appear in five groups separated by hyphens in the form 8-4-4-4-12, totaling 36 characters (32 hexadecimal characters and four hyphens), e.g., "4947a69a-f61b-4bc1-b9da-47c9c5d14b64".

[0081] 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, for example, like the actual NF instance ID, each pseudo NF instance ID may be globally unique within the PLMN (e.g., H-PLMN 298) of the H-NRF 100 to which the corresponding NF instance is registered, but may be temporary (e.g., assigned to the same NF instance for a lifetime or while registered) and may be reassigned to another NF instance later (e.g., after an NF deregistration procedure). In some embodiments, the format of the pseudo NF instance ID may be the same as the actual NF instance ID, e.g., UUID version 4 format. For example, the pseudo instance ID "PID2" may represent a 128-bit UUID such as "5162f79a-c31b-4bc1-c8da-27e5c5d34b22".

[0082] As shown, the first row of FIG. 5 shows the association between NF instance ID “ID1” and pseudo NF instance IDs “PID2,” “PID4,” and “PID7,” the second row of FIG. 5 shows the association between NF instance ID “ID2” and pseudo NF instance IDs “PID61,” “PID40,” “PID55,” “PID32,” and “PID34,” the third row of FIG. 5 shows the association between NF instance ID “ID3” and pseudo NF instance IDs “PID27,” “PID21,” and “PID25,” the fourth row of FIG. 5 shows the association between NF instance ID “ID4” and pseudo NF instance IDs “PID72,” “PID29,” “PID33,” and “PID11,” and the fifth row of FIG. 5 shows the association between NF instance ID “ID5” and pseudo NF instance IDs “PID16,” “PID22,” “PID64,” and “PID96.”

[0083] It will also be appreciated that ID data 500 is for illustrative purposes, and that different and / or additional data than that shown in Figure 5 may be used to indicate default values ​​for particular data portions or other information. Additionally, ID data 500 may be stored (e.g., in data storage device 206) and managed using a variety of data structures and / or computer-readable media.

[0084] FIG. 6 is a diagram illustrating example ID usage data 600 showing the use of message types and associated pseudo NF instance IDs. The ID usage data 600 may 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 validation purposes. For example, when the UE 114 is roaming within the V-PLMN1 300, various communications between the V-PLMN1 300 and the H-PLMN 298 involving multiple NF instances may occur. In this example, inter-PLMN messages may be transmitted between the V-PLMN1 300 and the H-PLMN 298 via the SEPP 126 in the respective networks. While some messages may successfully utilize the pseudo NF instance ID, other messages (e.g., NF Registration, NF Update, and NF Deregistration Request messages) may require an actual NF instance ID to be successfully validated and processed. For example, the H-NRF 100 may discard or ignore any NF registration, NF update, and NF deregistration request messages that have a pseudo NF instance identifier, thereby reducing the opportunity for a malicious or hacked external node to attempt to deregister a network node.

[0085] In some embodiments, for example, during message validation, node 200, H-NRF 100, or SM 204 may 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 an actual NF instance ID is included in the received message, and if not, whether a pseudo NF instance ID in the received message is acceptable or permitted. For example, node 200 or SM 204 may consider an NF subscription request message to be valid if the NF subscription request message includes a pseudo NF instance ID that identifies the producer NF 296, but may consider an NF update request message to be invalid (or inappropriate) if the NF update request message includes the same pseudo NF instance ID but does not include an actual NF instance ID associated with the producer NF 296.

[0086] 6, a table representing ID usage data 600 includes columns and / or fields for message type and pseudo NF instance ID usage (e.g., indicating whether a pseudo NF instance ID is available or allowed for a corresponding message type). The message type field may store information to represent a type of message associated with an NF instance. For example, example message types shown in FIG. 6 include an NF registration message, an NF update message, an NF deregistration message, an NF discovery message, an NF profile message, an NF access token message, and an SBI message.

[0087] The pseudo NF instance ID usage field may indicate whether pseudo NF instance IDs are available or allowed for the corresponding message type. For example, as shown in FIG. 6, valid NF registration messages, NF update messages, and NF deregistration messages do not allow pseudo NF instance IDs, but valid NF discovery messages, NF profile messages, NF access token messages, and SBI messages allow pseudo NF instance IDs.

[0088] It will also be appreciated that the identity usage data 600 is for illustrative purposes only, and that different and / or additional data than that shown in Figure 6 may be used to indicate default values ​​for particular data portions or other information. Additionally, the identity usage data 600 may be stored (e.g., in the data storage device 206) and managed using a variety of data structures and / or computer-readable media.

[0089] 7 is a message flow diagram illustrating an example NF discovery scenario involving an NF instance ID. In some embodiments, H-NRF 100 or SM 204 therein may receive an NF discovery request message requesting an NF to provide a particular service or information, and may provide an NF discovery response including a pseudo NF instance ID to identify a particular NF instance, e.g., where the pseudo NF instance ID is one of multiple temporary instance IDs assigned during the NF registration procedure or predetermined by the network operator. In such embodiments, an external NF discovery requester (e.g., in V-PLMN1 300) may receive pseudo NF instance IDs for communicating with various NF instances in the home network (e.g., H-PLMN 298), and thus, nodes in V-PLMN 300 do not learn or know the actual NF instance IDs of those NF instances.

[0090] 7, for example, before step 701, an NF registration procedure may be performed to register the producer NF 296 (e.g., a particular NF instance). During or concurrently with the NF registration procedure, one or more pseudo NF instance IDs corresponding to the producer NF 296 may be assigned and / or stored for use by one or more entities, e.g., the H-NRF 100. For example, the producer NF 296 may register with the H-NRF 100 using the NF instance ID "ID45" and may receive from the H-NRF 100 a set of pseudo NF instance IDs, e.g., "PID23," "PID44," and "PID55." In this example, the set of pseudo NF instance IDs may be uniquely assigned to the producer NF 296 for a predetermined amount of time or while the producer NF 296 is registered in the home network.

[0091] In step 701, an NF discovery request message may be sent from the consumer NF 294 to the V-NRF 100 within the V-PLMN1 300 to request an NF instance that can provide a particular service or related information from the H-PLMN 298.

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

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

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

[0095] In step 705, the H-NRF 100 or the SM 204 therein may receive the NF discovery request message, determine or select an appropriate NF instance, i.e., a producer NF 296, for providing the service or information, and identify a corresponding pseudo NF instance ID for identifying the producer NF 296.

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

[0097] In step 707, the NF discovery response (eg, as an HTTP / 2 message) may be forwarded from the H-SEPP 126 to the V-SEPP 126 via the N32-f interface.

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

[0099] In step 709, an NF discovery response may be sent from the V-NRF 100 to the consumer NF 294.

[0100] In some embodiments, the consumer NF 294 may use the pseudo NF instance ID to request a service or related data from the producer 296, for example, via an SBI request message.

[0101] 7 is for illustrative purposes and that different and / or additional messages and / or actions may be used. It will also be appreciated that the various messages and / or actions described herein may occur in a different order or sequence.

[0102] 8 is a message flow diagram illustrating the use of an exemplary NF access token including a pseudo NF instance ID. In some embodiments, H-NRF 100 or SM 204 therein may be configured to provide an access token including a pseudo NF instance ID to identify a particular NF instance, e.g., where the pseudo NF instance ID is one of multiple temporary instance IDs assigned during the NF registration procedure or predetermined by a network operator. In such embodiments, an external NF discovery requestor (e.g., in V-PLMN1 300) may receive pseudo NF instance IDs for communicating with various NF instances in the home network (e.g., H-PLMN 298), and thus, nodes in V-PLMN 300 do not learn or know the actual NF instance IDs of those NF instances.

[0103] 8, for example, before step 801, an NF registration procedure may be performed to register the producer NF 296 (e.g., a particular NF instance). During or concurrently with the NF registration procedure, one or more pseudo NF instance IDs corresponding to the producer NF 296 may be assigned and / or stored for use by one or more entities, e.g., the H-NRF 100. For example, the producer NF 296 may register with the H-NRF 100 using the NF instance ID "ID45" and may receive from the H-NRF 100 a set of pseudo NF instance IDs, e.g., "PID23," "PID44," and "PID55." In this example, the set of pseudo NF instance IDs may be uniquely assigned to the producer NF 296 for a predetermined amount of time or while the producer NF 296 is registered in the home network.

[0104] In step 801, an access token request message may be sent from a consumer NF 294 in V-PLMN1 300 to V-NRF 100 to access a service or related information from H-PLMN 298. For example, consumer NF 294 in V-PLMN1 300 may represent a network node that requests an access token (e.g., an OAuth2 access token) to receive a service or related information in a home network from producer NF 296, for example.

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

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

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

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

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

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

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

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

[0113] In step 810, an SBI request message including the access token may be sent from the consumer NF 294 to the V-SEPP 126 for forwarding to the H-PLMN 298.

[0114] In step 811, the SBI request message (eg, as an HTTP / 2 message) may be transferred from V-SEPP 126 to H-SEPP 126 via the N32-f interface.

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

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

[0117] In step 814, for example, after validating the access token, an SBI response providing the requested service or information may be generated and sent from the producer NF296 to the H-SEPP126 for forwarding to the V-PLMN300.

[0118] In step 815, the SBI response (eg, as an HTTP / 2 message) may be transferred from H-SEPP 126 to V-SEPP 126 via the N32-f interface.

[0119] In step 816, the SBI response may be transmitted from the V-SEPP 126 to the consumer NF 294.

[0120] 8 is for illustrative purposes and that different and / or additional messages and / or actions may be used. It will also be appreciated that the various messages and / or actions described herein may occur in a different order or sequence.

[0121] 9 is a message flow diagram illustrating an example validation of an NF deregistration request message. In some embodiments, the H-NRF 100, or the SM 204 therein, may be configured to perform message validation using an NF instance ID or a pseudo NF instance ID. For example, after storing ID data (e.g., an NF instance ID and a corresponding pseudo NF instance ID) associated with a first NF instance (NF1) 896 during the registration procedure of the first NF instance (NF1), the H-NRF 100, or the SM 204 therein, may monitor ingress messages (e.g., inter-PLMN and / or HTTP / 2 messages) associated with the NF instance and may determine whether each of these ingress messages is valid using the stored ID data before processing, forwarding, and / or responding to the ingress message. If the 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 appropriate for that type of message, the H-NRF 100 or SM 204 may consider the message invalid and perform an invalid message action, e.g., one or more discards between PLMNs, and / or report the event to a network operator or network management system. If the 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 appropriate for that type of message, the H-NRF 100 or SM 204 may consider the message valid and perform a valid message action, e.g., allowing the ingress message to be received and processed at its intended destination.

[0122] 9 , for example, before step 901, an NF registration procedure may occur to register NF1 896. During or concurrently with the NF registration procedure, one or more pseudo NF instance IDs corresponding to NF1 896 may be assigned and / or stored for use by one or more entities, e.g., H-NRF100. For example, NF1 896 may register with H-NRF100 using NF instance ID “ID1” and may receive from H-NRF100 a set of pseudo NF instance IDs, e.g., “PID1,” “PID2,” and “PID3.” In this example, the set of pseudo NF instance IDs may be uniquely assigned to NF1 896 for a predetermined amount of time or while NF1 896 is registered in the home network.

[0123] In some embodiments, after NF1 896 registers with H-NRF 100, consumer NF instance (NF2) 898 may request an NF profile or related information (e.g., an NF instance ID) associated with a particular service or NF and attempt to misuse that information. For example, NF2 898 may be, or appear to be, a 5G NF instance located within V-PLMN1 300. In this example, NF2 898 may be compromised, hacked, or otherwise configured to perform or attempt to perform malicious or inappropriate actions, such as launching a DoS attack using the learned NF instance ID or pseudo NF instance ID.

[0124] In step 901, an NF discovery request message to discover an NF instance to provide a service or data may be sent from NF2 898 to H-NRF100, for example, via V-SEPP126 and H-SEPP126 (not shown).

[0125] In step 902, after receiving the NF discovery request message, the H-NRF 100 and / or SM 204 may identify an associated NF instance (e.g., NF1 896) for providing the service or data and may determine a pseudo NF instance ID "PID1" for communicating with and / or referencing the NF instance. In this example, the H-NRF 100 and / or SM 204 may generate an NF discovery response indicating the pseudo NF instance ID.

[0126] In step 903, an NF discovery response including a pseudo NF instance ID "PID1" for communicating with and / or referencing NF1 896 may be sent (e.g., as an HTTP / 2 message) from H-NRF100 to NF2 898, for example, via V-SEPP126 and H-SEPP126 (not shown).

[0127] In step 904, an NF deregistration request message to deregister NF1 896 may be sent from NF2 898 to H-NRF 100 and may include the pseudo NF instance ID "PID1." For example, NF2 898 in V-PLMN1 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 (e.g., "ID1") of NF1 896, NF2 898 uses the pseudo NF instance ID "PID1" in its deregistration attempt for NF1 896.

[0128] In step 905, the H-NRF 100 or the SM 204 therein may receive the NF deregistration request message, perform a message validation 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, the H-NRF 100 or the SM 204 may identify that the NF deregistration request message lacks a real or non-pseudo NF instance ID, thereby indicating that the NF deregistration request message is improper or invalid (e.g., fraudulent) and should not be answered.

[0129] In step 906, a second NF deregistration request message to deregister NF1 896 may be sent from NF1 896 to H-NRF100 and may include its actual or non-pseudo NF instance ID "ID1".

[0130] In step 907, the H-NRF 100 or the SM 204 therein may receive the second NF deregistration request message, perform a message validation procedure, determine that the second NF deregistration request message is valid, and perform an invalid message action. For example, the H-NRF 100 or the SM 204 may identify that the second NF deregistration request message includes a real or non-pseudo NF instance ID, thereby indicating that the NF deregistration request message is valid and should be answered.

[0131] In step 908, for example, after determining that the second NF deregistration request message is valid, the H-NRF100 or SM204 may deregister NF1 896 and send an NF deregistration response to NF1 896 indicating successful deregistration of NF1 896.

[0132] 9 is for illustrative purposes and that different and / or additional messages and / or actions may be used. It will also be appreciated that the various messages and / or actions described herein may occur in a different order or sequence.

[0133] 10 illustrates an example process 1000 for hiding NF instance IDs in a communication network. In some embodiments, the example process 1000 described herein, or portions thereof, may be implemented in or by a network node, e.g., NRF 100, node 200, SM 204, and / or another module, NF, or node.

[0134] In step 1002, an NF registration request message (e.g., a 5G NF registration request message) for registering a first NF instance of a first NF may be received, the NF registration request message including a first NF instance ID for identifying the first NF instance.

[0135] In step 1004, a mapping between the first NF instance ID and at least one pseudo NF instance ID may be stored, the data store including a mapping between the NF instance ID and the associated pseudo NF instance ID.

[0136] In step 1006, a NF registration response message (e.g., a 5G NF registration response message) including at least one pseudo NF instance ID for identifying the first NF instance may be generated and transmitted.

[0137] In some embodiments, a first NF may 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 of the first NF, wherein each of the at least one pseudo NF instance ID is different from the first NF instance ID for identifying the first NF instance, and the first NF may be configured to store the at least one pseudo NF instance ID associated with the first NF instance ID and to use the first pseudo NF instance ID of the at least one pseudo NF instance ID for source identification when sending a request or response message.

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

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

[0140] In some embodiments, the consumer NF instance may communicate with the first NF instance over the SBI using the first pseudo NF instance ID.

[0141] In some embodiments, a network node (e.g., the H-NRF 100 or the H-SEPP 126) may be configured to receive a service request message for performing an action associated with a first NF instance, the service request message including an ID of the first NF instance, and the network node may be configured to use a data store association between the ID and the NF instance ID and an associated pseudo NF instance ID to determine whether the service request message is valid or invalid, and to perform an invalid message action in response to a determination that the service request message is invalid, and to perform a valid message action in response to a determination that the service request message is valid.

[0142] In some embodiments, the network node for validating the request message using the pseudo NF instance ID in the request message may include an NRF, a producer NF, a PCR, a BSF, an SCP, an NSSF, an NEF, a UDR, or a 5GC NF.

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

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

[0145] In some embodiments, determining that the 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 the first NF instance ID, and that the pseudo NF instance ID is not allowed for that message or that message type.

[0146] It will be appreciated that process 1000 is for illustrative purposes and that different and / or additional actions may be used. It will also be appreciated that the various actions described herein may be performed in a different order or sequence.

[0147] Although some aspects of the subject matter described herein are discussed with reference to 5G networks, it will be appreciated that various other networks may utilize some aspects of the subject matter described herein. For example, any network utilizing NF instance IDs or similar IDs may 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, e.g., inter-PLMN communications.

[0148] Although some aspects of the subject matter described herein are discussed with reference to NRF-related messages, it will be appreciated that various other messages may utilize the pseudo NF instance ID or other aspects of the subject matter described herein. For example, a UECM registration request by an AMF may utilize the pseudo NF instance ID for identification during UECM service registration. Furthermore, it will be appreciated that the pseudo NF instance ID may be used in various message types, e.g., message payloads and / or headers, of which it is part. For example, the pseudo NF instance ID may be part of an access token and a CCA token. In another example, the pseudo NF instance ID may be in a Load Control Information (LCI) header or an Overload Control Information (OCI) header.

[0149] It should be noted that node 200, SM 204, and / or the functionality described herein may constitute a dedicated computing device. Additionally, node 200, SM 204, and / or the functionality described herein may improve the technical areas of network security and / or message validation in communication networks. For example, by using pseudo NF instance IDs and / or reducing the use of NF instance IDs for NF registration, NF update, and NF deregistration scenarios, malicious activities and their negative consequences (e.g., DoS attacks, customer data theft, etc.) may 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 may prevent DoS attacks that attempt unauthorized NF updates or NF deregistrations using leaked NF instance IDs. Additionally, such techniques and / or methods described herein may be applicable 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.

[0150] The disclosure of each of the following cited references is incorporated herein by reference in its entirety to the extent not inconsistent with the present specification and to the extent that it supplements, explains, provides background to, or teaches about the methods, techniques, and / or systems employed herein.

[0151] References: 1. 3GPP TS 29.510; 3 rdGeneration Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 17), V17.1.0 (2021-03). 2. 3GPP TS 33.501; 3 rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System; (Release 17), V17.1.0 (2021-03). 3. RFC4122: A Universally Unique IDentifier (UUID) URN Namespace; Leach, P., Mealling, M. and Salz, R.; (2005). It will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Further, the above description is for purposes of illustration only, and not limitation.

Claims

1. 1. A method for hiding a Network Function (NF) instance identifier (ID) in a communication network, comprising: A NF Repository Function (NRF) comprising at least one processor, receiving an NF registration request message from a first NF requesting to register a first NF instance of the first NF, the NF registration request message including a first NF instance identifier (ID) for identifying the first NF instance; The method comprises in a NF Repository Function (NRF) comprising at least one processor: and storing a mapping between the first NF instance ID and at least one pseudo NF instance ID in a data store, the data store including a mapping between NF instance IDs and associated pseudo NF instance IDs; The method comprises in a NF Repository Function (NRF) comprising at least one processor: generating and sending to the first NF a NF registration response message including the at least one pseudo NF instance ID for identifying the first NF instance; The method further comprises:

2. The method further comprises, in the first NF: receiving, from the NRF, the NF registration response message including the at least one pseudo NF instance ID, wherein each of the at least one pseudo NF instance ID is different from the first NF instance ID; The method further comprises, in the first NF: storing the at least one pseudo NF instance ID associated with the first NF instance ID; using the at least one pseudo NF instance ID for source identification when sending a request or response message; The method of claim 1 further comprising:

3. In the NRF, receiving an NF discovery request message from a consumer NF instance, the NF discovery request message including at least one query parameter; selecting an NF profile including a first pseudo NF instance ID associated with the first NF instance using the at least one query parameter and the data store; sending the NF profile including the first pseudo NF instance ID to the consumer NF instance; The method of claim 1 , comprising:

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

5. 4. The method of claim 3, wherein the first pseudo NF instance ID is usable by the consumer NF instance to communicate with the first NF instance over a service-based interface (SBI).

6. The method further comprises, in the NRF: receiving a service request message from a consumer NF instance to perform an action associated with the first NF instance, the service request message including an ID of the first NF instance; The method further comprises, in the NRF: using the ID and the data store to determine whether the service request message is valid or invalid; performing an invalid message action in response to determining that the service request message is invalid; and performing a valid message action in response to determining that the service request message is valid; and The method of claim 1 further comprising:

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

8. The method of claim 6 , wherein the service request message comprises an NF registration request message, an NF update request message, or an NF deregistration request message.

9. 9. The method of claim 8, wherein determining that the service request message is invalid comprises 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. 2. The method of claim 1, wherein the first NF comprises 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. 1. A system for hiding a network function (NF) instance identifier (ID) in a communication network, comprising: Equipped with NF Repository Function (NRF), The NF repository function: at least one processor; and a security module implemented by said at least one processor, said security module performing the method of any one of claims 1 to 10.

12. A program causing at least one processor of a computer to execute the method according to any one of claims 1 to 10.

Images