Patent Description:
The subject matter described herein relates to enhancing security in fifth generation (<NUM>) and subsequent generation communications 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 <NUM> and subsequent generation communications networks.

In fifth generation (<NUM>) communications networks, a network node that provides service is referred to as a producer network function (NF). A network node that consumes services 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 service.

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

Producer NFs register with a NF repository function (NRF). The NRF maintains service profiles of 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. In addition to consumer NFs, another type of network node that can subscribe to receive information about NF service instances is a service communication proxy (SCP). The SCP subscribes with the NRF and obtains reachability and service profile information regarding producer NF service instances. Consumer NFs connect to the SCP, and the SCP load balances traffic among producer NF service instances that provide the required service or directly routes the traffic to the destination producer NF instance.

In addition to the SCP, other examples of intermediate proxy nodes or groups of network nodes that route traffic between producer and consumer NFs include the security edge protection proxy (SEPP), the service gateway, and nodes in the <NUM> service mesh. The SEPP is the network node used to protect control plane traffic that is exchanged between different <NUM> public land mobile networks (PLMNs). As such, the SEPP performs various amounts of message filtering, policing, and topology hiding for application programming interface (API) messages.

However, there exists a need for improved security measures at one or more NFs.

<NPL>) studies and evaluates architecture enhancements on potential optimizations to the Release <NUM> Service-Based Architecture (SBA) in order to provide higher flexibility and better modularization of the <NUM> Systems for the easier definition of different network slices and to enable better re-use of the defined services.

<CIT> discloses a method performed by a resolver in a core network of a wireless communication system.

<CIT> discloses a <NUM> core network method based on NRF authority levels.

The present invention is directed to subject-matter as disclosed by the appended claims.

The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. As such, the terms "function" "node" or "module" as used herein refer to hardware, which may also include software and/or firmware components, for implementing the feature being described. In one example implementation, the subject matter described herein may be implemented using a computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps. Example 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. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.

The subject matter described herein relates to methods, systems, and computer readable media for hiding network function (NF) instance identifiers (IDs) in fifth generation (<NUM>) communications networks. In <NUM> communications networks, NF instance IDs are used to uniquely identify a <NUM> NF instance. For example, an NF repository function (NRF) uses NF instance IDs for NF management, NF discovery, and NF access token services. Further, consumer NFs use NF instance IDs for client credential assertion (CCA) based client authentication. NFs also use NF instance IDs for sharing their identification, e.g., an access and mobility management function (AMF) uses its NF instance ID during a UEContextManagement (UECM) service registration. Since an NF instance ID uniquely identifies an NF, exposing NF instance IDs outside their public land mobile network (PLMN) may implicitly expose the PLMN's topology the outside world. For example, NF instance IDs can leak from a visitor network because of compromised security in the visitor network, such as not using transport layer security (TLS) between NFs.

While a security edge protection proxy (SEPP) provides some security measures for inter-PLMN communications, the SEPP is unable to hide NF instance IDs as NF instance IDs can be embedded in access tokens which cannot be modified because of JSON Web Signature (JWS) signing. Further, NF instance IDs are used for NF update and NF deregistration service operations. Hence, leaked NF instance IDs can be misused (e.g., by a hacker) in denial of service (DoS) attacks, e.g., by sending unauthorized NF update or NF deregistration request messages.

In accordance with some aspects of the subject matter described herein, methods, systems, mechanisms, and/or techniques are disclosed for hiding NF instance IDs in a communications network by using pseudo NF instance IDs in lieu of NF instance IDs in various scenarios. For example, an NRF in accordance with various aspects described herein can generate and/or assign pseudo NF instance IDs during NF registration of an NF. In this example, the pseudo NF instance IDs may be shared with the NF in an NF registration response. In some embodiments, pseudo NF instance IDs may be used for identifying the NF in various scenarios (e.g., inter-PLMN communications), thereby mitigating leakage of NF instance IDs and related misuse. In some embodiments, e.g., to further mitigate NF instance ID misuse, actual NF instance IDs (but not pseudo NF instance IDs) may be used for NF registration, NF update, and NF deregistration.

Advantageously, by utilizing one or more techniques, systems, and/or methods described herein, a 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 usage of NF instance IDs to NF registration, NF update, NF deregistration scenarios.

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.

<FIG> is a block diagram illustrating an example <NUM> system network architecture, e.g., a home <NUM> core (5GC) network. The architecture in <FIG> includes an NRF <NUM> and an SCP <NUM>, which may be located in the same home public land mobile network (PLMN). As described above, NRF <NUM> may maintain profiles of available producer NF service instances and their supported services and allow consumer NFs or SCPs to subscribe to and be notified of the registration of new/updated producer NF service instances. SCP <NUM> may also support service discovery and selection of producer NF instances. SCP <NUM> may perform load balancing of connections between consumer and producer NFs. In addition, using the methodologies described herein, SCP <NUM> may perform preferred NF location based selection and routing.

NRF <NUM> is a repository for NF or service profiles of producer NF instances. In order to communicate with a producer NF instance, a consumer NF or an SCP must obtain the NF or service profile or the producer NF instance from NRF <NUM>. The NF or service profile is a JavaScript object notation (JSON) data structure defined in Third Generation Partnership Project (3GPP) Technical Specification (TS) <NUM>. The NF or service profile definition includes at least one of a fully qualified domain name (FQDN), an Internet protocol (IP) version <NUM> (IPv4) address, or an IP version <NUM> (IPv6) address. In <FIG>, any of the nodes (other than NRF <NUM>) can be either consumer NFs or producer NFs, depending on whether they are requesting or providing services. In the illustrated example, the nodes include a policy control function (PCF) <NUM> that performs policy related operations in a network, a unified data management (UDM) function <NUM> that manages user data, and an application function (AF) <NUM> that provides application services. The nodes illustrated in <FIG> further include a session management function (SMF) <NUM> that manages sessions between access and mobility management function (AMF) <NUM> and PCF <NUM>. AMF <NUM> performs mobility management operations similar to those performed by a mobility management entity (MME) in <NUM> networks. An authentication server function (AUSF) <NUM> performs authentication services for user devices, such as user equipment (UE) <NUM>, seeking access to the network.

A network slice selection function (NSSF) <NUM> provides network slicing services for devices seeking to access specific network capabilities and characteristics associated with a network slice. A network exposure function (NEF) <NUM> provides application programming interfaces (APIs) for application functions seeking to obtain information about Internet of things (IoT) devices and other UEs attached to the network. NEF <NUM> performs similar functions to the service capability exposure function (SCEF) in <NUM> networks.

A radio access network (RAN) <NUM> connects UE <NUM> to the network via a wireless link. Radio access network <NUM> may be accessed using a g-Node B (gNB) (not shown in <FIG>) or other wireless access point. A user plane function (UPF) <NUM> can support various proxy functionality for user plane services. One example of such proxy functionality is multipath transmission control protocol (MPTCP) proxy functionality. UPF <NUM> may also support performance measurement functionality, which may be used by UE <NUM> to obtain network performance measurements. Also illustrated in <FIG> is a data network (DN) <NUM> through which UEs access data network services, such as Internet services.

Security edge protection proxy (SEPP) <NUM> filters incoming traffic from another PLMN and performs topology hiding for traffic exiting the home PLMN. SEPP <NUM> may communicate with an SEPP in a foreign PLMN which manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs may traverse two SEPP functions, one for the home PLMN and the other for the foreign PLMN.

SEPP <NUM> may utilize an N32-c interface and an N32-f interface. An N32-c interface is a control plane interface between two SEPPs usable for performing an initial handshake (e.g., a TLS handshake) and negotiating various parameters for an N32-f interface connection and related message forwarding. An N32-f interface is a forwarding interface between two SEPPs usable for forwarding various communications (e.g., 5GC request messages) between a consumer NF and a producer NF after applying application level security protection.

One issue with the existing <NUM> architecture is that the existing <NUM> architecture can allow leakage of NF instance IDs to various entities, which can contribute to or allow malicious entities to perform various malicious actions, e.g., unauthorized or improper NF deregistration request message of an NF instance using a leaked or gleaned NF instance ID. For example, if a compromised NF in a trusted (but compromised or hacked) visitor PLMN (V-PLMN) has access to a home PLMN (H-PLMN), the compromised NF may receive an NF instance ID for identifying a particular NF instance via an NF discovery procedure. In this example, the compromised NF in a trusted V-PLMN can trigger or initiate a denial of service (DOS) attack by spoofing the particular NF instance and sending an NF deregistration request message using the NF instance ID it has obtained from the NF discovery procedure. Hence, even with existing authorization procedures, <NUM> architecture can benefit from enhanced security and/or related techniques that use temporary or pseudo NF instance IDs in lieu of actual NF instance IDs, thereby mitigating leakage of NF instance IDs and related misuse.

It will be appreciated that <FIG> is for illustrative purposes and that various nodes and/or modules, locations, and/or functionality described above in relation to <FIG> may be changed, altered, added, or removed.

<FIG> is a diagram illustrating an example network node <NUM> for hiding NF instance IDs in a <NUM> communications network. Node <NUM> may represent any suitable entity or entities for performing various aspects of authorization, registration, and/or security functions, e.g., hiding NF instance IDs and/or related topology information. In some embodiments, node <NUM> may represent or include one or more 5GC NFs, e.g., an NRF, a SEPP, a SCP, a PCF, an NSSF, an NEF, a unified data repository (UDR), a binding support function (BSF), etc. In some embodiments, node <NUM> may represent or include a consumer NF or a producer NF. In some embodiments, node <NUM> may represent or include an authorization server, a data repository, a network gateway, a network proxy, an edge security device, or other functionality.

In some embodiments, node <NUM> or a related module (e.g., a security module) may be configured (e.g., via programming logic) to detect, generate, obtain, or assign pseudo NF instance IDs during an NF registration procedure. For example, where node <NUM> includes an NRF, node <NUM> or a related module may receive a <NUM> NF registration request message for registering a first NF instance, wherein the <NUM> NF registration request message comprises a first NF instance ID. In this example, node <NUM> or a related module 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 is usable for referring to the first NF instance in lieu of the first NF instance ID. Continuing with this example, node <NUM> or a related module may generate and send a <NUM> NF registration response message comprising the one or more pseudo NF instance IDs.

In some embodiments, node <NUM> or a related module (e.g., a security module) may be configured to use pseudo NF instance IDs for various communication scenarios. For example, where node <NUM> includes an NF instance that has registered with an NRF <NUM> and has received from NRF <NUM> a set of assigned pseudo NF instance IDs in a <NUM> NF registration response message, node <NUM> or a related module (e.g., a security module) may be configured to use a pseudo NF instance ID for identification in various <NUM> request messages (except NF registration, NF update, and NF deregistration request messages) and to respond to various <NUM> messages that are directed to one of the pseudo NF instance IDs associated with node <NUM>.

Referring to <FIG>, node <NUM> may include one or more communications interface(s) <NUM> for communicating messages via a communications environment, e.g., a home 5GC network. For example, communications interface(s) <NUM> may include a first communication interface for communicating with a first set of SEPPs <NUM> in a home network, a second communications interface for communicating with a second set of SEPPs <NUM> in a home network, and a third communications interface for communicating with other entities in a home network.

Node <NUM> may include a security module (SM) <NUM>. SM <NUM> may be any suitable entity (e.g., software executing on at least one processor) for performing one or more aspects associated with using and/or validating pseudo NF instance IDs. In some embodiments, SM <NUM> may be configured for receiving a <NUM> NF registration request message for registering a first NF instance, wherein the <NUM> NF registration request message comprises a first NF instance ID and generating and sending a <NUM> NF registration response message comprising 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 is usable for referring to the first NF instance in lieu of the first NF instance ID.

In some embodiments, SM <NUM> may be configured to use pseudo NF instance IDs for various communication scenarios. For example, SM <NUM> may be configured for analyzing one or more <NUM> messages that are to be sent and replacing an NF instance ID with a corresponding pseudo NF instance ID prior to sending when appropriate, e.g., performing replacements except for NF registration, NF update, and NF deregistration request messages. In this example, SM <NUM> may also be configured for verifying that pseudo NF instance IDs are valid or appropriate for various received <NUM> messages.

In some embodiments, SM <NUM> may be configured for accessing or utilizing a data store containing one or more associations between an NF instance IDs and pseudo NF instance IDs. For example, SM <NUM> may be configured for receiving, from a consumer NF instance, a service request message for discovering the first NF instance; determining, using a data store storing associations between NF instance IDs and related pseudo NF instance IDs, a first pseudo NF instance ID of the one or more pseudo NF instance IDs associated with the first NF instance ID; and sending, to the consumer NF instance, the first pseudo NF instance ID.

SM <NUM> is configured for message validation. For example, SM <NUM> may be configured for receiving a request message for performing an action associated with a first NF instance, wherein the request message comprises an ID for the first NF instance; determining, using the ID and a data store storing associations between NF instance IDs and related pseudo NF instance IDs, that the request message is valid or invalid. In this example, if the request message is deemed invalid, SM <NUM> may be configured for performing an invalid message action (e.g., discarding the request message or notifying a network operator or a management system about the issue). Continuing with this example, if the request message is deemed valid, SM <NUM> may be configured for performing a valid message action (e.g., processing the request message or forwarding the request message to another node for processing).

SM <NUM> determines that a request message is invalid by analyzing a message type of a received message and determining that the message type cannot use a pseudo NF instance ID. For example, SM <NUM> may determine that an NF registration request message, an NF update request message, or an NF deregistration request message comprising a pseudo NF instance ID is invalid or improper and may discard or otherwise ignore the request message.

In some embodiments, e.g., where node <NUM> is SEPP <NUM>, SM <NUM> may be configured for monitoring an N32-f interface connection for inter-PLMN messages (e.g., HTTP/<NUM> messages) and for validating the messages before being sent to another destination. For example, for a first inter-PLMN <NUM> NF deregistration message, SM <NUM> may determine that the request message is valid (e.g., that the message includes an actual or non-pseudo NF instance ID) and send it to NRF <NUM> for processing. In another example, for a second inter-PLMN <NUM> NF deregistration message, SM <NUM> may determine that the request message is invalid (e.g., that the message includes a pseudo NF instance ID) and discard or prevent the request message from being received by NRF <NUM>.

Node <NUM> may access (e.g., read from and/or write information to) data storage <NUM>. Data storage <NUM> may be any suitable entity (e.g., a computer readable medium or memory) for storing various data. In some embodiments, data storage <NUM> may include authentication information for user devices and/or related information used in hiding NF instance IDs or related message validation. For example, data store <NUM> may include data records or entries indicating associations between NF instance IDs and pseudo NF instance IDs. In some embodiments, data storage <NUM> 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 stored authentication information, and/or logic for implementing or triggering an invalid message action or valid message action.

It will be appreciated that <FIG> and its related description are for illustrative purposes and that node <NUM> may include additional and/or different modules, components, or functionality.

<FIG> is a message flow diagram illustrating an example NF discovery scenario involving an NF instance ID. In some embodiments, H-NRF <NUM> (without SM <NUM>) may receive an NF discovery request message requesting an NF for providing a particular service or information and may provide an NF discovery response comprising an NF instance ID for identifying a particular NF instance, e.g., where the NF instance ID is a unique identifier. In such embodiments, foreign NF discovery requesters (e.g., in V-PLMN <NUM> <NUM>) may receive actual (e.g., non-pseudo) NF instance IDs for communicating with various NF instances in a home network (e.g., H-PLMN <NUM>) and, as such, nodes in V-PLMN <NUM> may learn or know actual NF instance IDs for those NF instances.

Referring to <FIG>, e.g., prior to step <NUM>, an NF registration procedure for registering producer NF <NUM> (e.g., a particular NF instance) may occur. During or concurrent to the NF registration procedure, H-NRF <NUM> may store an NF instance ID associated with and provided by producer NF <NUM>. For example, the NF instance ID associated with producer NF <NUM> may be globally unique inside the PLMN (e.g., H-PLMN <NUM>) of H-NRF <NUM> where producer NF <NUM> is being registered. In this example, the NF instance ID may be usable for identifying, referring to, and/or communicating with producer NF <NUM>.

In step <NUM>, an NF discovery request message may be sent from consumer NF <NUM> to V-NRF <NUM> in V-PLMN <NUM> <NUM> for requesting NF instance that can provide a particular service or related information from H-PLMN <NUM>.

In step <NUM>, the NF discovery request message may be sent from V-NRF <NUM> to V-SEPP <NUM> for forwarding to H-NRF <NUM> in H-PLMN <NUM>.

In step <NUM>, the NF discovery request message (e.g., as an HTTP/<NUM> message) may be forwarded from V-SEPP <NUM> to H-SEPP <NUM> via an N32-f interface.

In step <NUM>, the NF discovery request message may be sent from H-SEPP <NUM> to H-NRF <NUM>. For example, H-NRF <NUM> receive the NF discovery request message and select an appropriate NF instance, i.e., producer NF <NUM>, for providing the service or information.

In step <NUM>, an NF discovery response comprising or indicating the NF instance ID identifying producer NF <NUM> may be generated and sent from H-NRF <NUM> to H-SEPP <NUM> for forwarding to V-PLMN <NUM>.

In step <NUM>, the NF discovery response (e.g., as an HTTP/<NUM> message) may be forwarded from H-SEPP <NUM> to V-SEPP <NUM> via an N32-f interface.

In step <NUM>, the NF discovery response may be sent from V-SEPP <NUM> to V-NRF <NUM>.

In step <NUM>, the NF discovery response may be sent from V-NRF <NUM> to consumer NF <NUM>.

In some embodiments, consumer NF <NUM> may use the NF instance ID to request service or related data from producer <NUM>, e.g., via an SBI request message.

It will be appreciated that <FIG> is for illustrative purposes and that different and/or additional messages and/or actions may be used. It will also be appreciated that various messages and/or actions described herein may occur in a different order or sequence.

<FIG> is a message flow diagram illustrating usage of an example NF access token comprising an NF instance ID. In some embodiments, H-NRF <NUM> (without SM <NUM>) may provide an access token comprising an NF instance ID for identifying a particular NF instance, e.g., where the NF instance ID is a unique identifier. In such embodiments, foreign access token requesters (e.g., in V-PLMN <NUM> <NUM>) may receive actual (e.g., non-pseudo) NF instance IDs for communicating with various NF instances in a home network (e.g., H-PLMN <NUM>) and, as such, nodes in V-PLMN <NUM> may learn or know actual NF instance IDs for those NF instances.

In step <NUM>, an access token request message may be sent from consumer NF <NUM> to V-NRF <NUM> in V-PLMN <NUM> <NUM> for accessing a service or related information from H-PLMN <NUM>. For example, consumer NF <NUM> in a V-PLMN <NUM> <NUM> may represent a network node requesting an access token (e.g., an OAuth2 access token) so as to receive a service or related information in a home network, e.g., from producer NF <NUM>.

In step <NUM>, the access token request message may be sent from V-NRF <NUM> to V-SEPP <NUM> for forwarding to H-NRF <NUM> in H-PLMN <NUM>.

In step <NUM>, the access token request message (e.g., as an HTTP/<NUM> message) may be forwarded from V-SEPP <NUM> to H-SEPP <NUM> via an N32-f interface.

In step <NUM>, the access token request message may be sent from H-SEPP <NUM> to H-NRF <NUM>. For example, H-NRF <NUM> may receive the access token request message and select an appropriate NF instance, i.e., producer NF <NUM>, for providing the service or information.

In step <NUM>, H-NRF <NUM> may generate an access token comprising or indicating the NF instance ID for identifying producer NF <NUM> and may send the access token in an access token response from H-NRF <NUM> to H-SEPP <NUM> for forwarding to V-PLMN <NUM>.

In step <NUM>, the access token response (e.g., as an HTTP/<NUM> message) may be forwarded from H-SEPP <NUM> to V-SEPP <NUM> via an N32-f interface.

In step <NUM>, the access token response may be sent from V-SEPP <NUM> to V-NRF <NUM>.

In step <NUM>, the access token response may be sent from V-NRF <NUM> to consumer NF <NUM>.

In step <NUM>, an SBI request message comprising the access token may be sent from consumer NF <NUM> to V-SEPP <NUM> for forwarding to H-PLMN <NUM>.

In step <NUM>, the SBI request message (e.g., as an HTTP/<NUM> message) may be forwarded from V-SEPP <NUM> to H-SEPP <NUM> via an N32-f interface.

In step <NUM>, the SBI request message may be sent from H-SEPP <NUM> to producer NF <NUM>.

In step <NUM>, e.g., after validating the access token, an SBI response providing a requested service or information may be generated and sent from producer NF <NUM> to H-SEPP <NUM> for forwarding to V-PLMN <NUM>.

In step <NUM>, the SBI response (e.g., as an HTTP/<NUM> message) may be forwarded from H-SEPP <NUM> to V-SEPP <NUM> via an N32-f interface.

In step <NUM>, the SBI response may be sent from V-SEPP <NUM> to consumer NF <NUM>.

<FIG> is a diagram illustrating example ID data <NUM> indicating NF instance IDs and related pseudo NF instance IDs. For example, ID data <NUM> may indicate mappings (e.g., associations) between an NF instance ID and one or more pseudo NF instance IDs. In some embodiments, an ID mapping or association may be statically configured by an operator or may be dynamically generated by NRF <NUM> and may be shared with an NF. For example, during an NF registration procedure associated with an NF, pseudo NF instance IDs assigned to the NF may be shared in an NF registration response sent to the NF.

In some embodiments, node <NUM>, H-NRF <NUM>, or SM <NUM> may be configured to assign pseudo NF instance IDs based on various rules and/or logic. For example, H-NRF <NUM> may be configured to assign at least one unique pseudo NF instance ID to NFs that register with H-NRF <NUM>. In another example, H-NRF <NUM> may be configured to assign a set of between <NUM> and <NUM> unique pseudo NF instance IDs to NFs that register with H-NRF <NUM>. In some embodiments, each pseudo NF instance ID associated with or assigned to a particular NF instance may be non-sequential and/or generated or assigned for reducing the likelihood that a corresponding actual (non-pseudo) NF instance ID can be deduced or discerned.

In some embodiments, an NF (e.g., producer NF <NUM>) may store its own pseudo NF instance IDs and may use and/or provide one of those pseudo NF instance IDs for identification in lieu 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 for identifying 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) for selecting 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, e.g., by storing state information and/or using a hashing function.

Referring to <FIG>, a table representing ID data <NUM> comprises columns and/or fields for NF instance IDs and corresponding pseudo NF instance IDs. An NF instance ID field may store information for representing an NF instance ID usable for identifying a particular NF instance. In some embodiments, each NF instance ID may be globally unique inside the PLMN (e.g., H-PLMN <NUM>) of H-NRF <NUM> where a corresponding NF instance is registered. In some embodiments, the format of an NF instance ID may be a universally unique identifier (UUID) version <NUM>, as described in IETF RFC <NUM>. For example, an NF instance ID 'ID1' may represent a <NUM>-bit UUID where <NUM> bytes (e.g., octets) of the UUID are represented as <NUM> hexadecimal digits, and where the digits are displayed in five groups separated by hyphens, in the form <NUM>-<NUM>-<NUM>-<NUM>-<NUM> for a total of <NUM> characters (<NUM> hexadecimal characters and <NUM> hyphens), e.g., "4947a69a-f61b-4bc1-b9da-47c9c5d14b64".

A pseudo NF instance IDs field may represent one or more pseudo NF instance IDs assigned to and/or associated with a corresponding NF instance ID. In some embodiments, e.g., similar to an actual NF instance ID, each pseudo NF instance ID may be globally unique inside the PLMN (e.g., H-PLMN <NUM>) of H-NRF <NUM> where a corresponding NF instance is registered, but may be temporary (e.g., assigned to same NF instance for a valid period or while registered) and may be re-assigned to another NF instance later (e.g., after an NF deregistration procedure). In some embodiments, the format of a pseudo NF instance ID may be the same as an actual NF instance ID, e.g., a UUID version <NUM> format. For example, pseudo instance ID 'PID2' may represent a <NUM>-bit UUID such as "5162f79a-c31b-4bc1-c8da-27e5c5d34b22".

As depicted, the first row in <FIG> indicates an association between NF instance ID 'ID1' and pseudo NF instance IDs "PID2", "PID4", and "PID7"; the second row in <FIG> indicates an association between NF instance ID 'ID2' and pseudo NF instance IDs "PID61", "PID40", "PID55", "PID32", and "PID34"; the third row in <FIG> indicates an association between NF instance ID 'ID3' and pseudo NF instance IDs "PID27", "PID21", and "PID25"; the fourth row in <FIG> indicates an association between NF instance ID 'ID4' and pseudo NF instance IDs "PID72", "PID29", "PID33", and "PID11"; the fifth row in <FIG> indicates an association between NF instance ID 'ID5' and pseudo NF instance IDs "PID16", "PID22", "PID64", and "PID96".

It will also be appreciated that ID data <NUM> is for illustrative purposes and that different and/or additional data than the data depicted in <FIG> may be usable for indicating default values for particular data portions or other information. Further, ID data <NUM> may be stored (e.g., in data storage <NUM>) and managed using various data structures and/or computer readable media.

<FIG> is a diagram illustrating example ID usage data <NUM> indicating message types and related pseudo NF instance ID usage. ID usage data <NUM> may indicate various types of messages (e.g., inter-PLMN messages) associated with <NUM> services and whether a pseudo NF instance ID can be used for validation purposes. For example, when UE <NUM> is roaming in V-PLMN <NUM> <NUM>, various communications between V-PLMN <NUM> <NUM> and H-PLMN <NUM> that involve multiple NF instances may occur. In this example, inter-PLMN messages may be sent between V-PLMN <NUM> <NUM> and H-PLMN <NUM> via SEPPs <NUM> in the respective networks. While some messages can successfully utilize pseudo NF instance IDs, other messages (e.g., NF registration, NF update, and NF deregistration request messages) may require actual NF instance IDs to be successfully validated and processed. For example, H-NRF <NUM> may discard or ignore any NF registration, NF update, and NF deregistration request messages that have pseudo NF instance identifiers, thereby reducing the chance of a malicious or hacked foreign node trying to deregister a network node.

During message validation, node <NUM>, H-NRF <NUM>, or SM <NUM> is configured to identify a message type of a received message (e.g., inter-PLMN message) and determine, using ID usage data <NUM>, 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 allowed. For example, node <NUM> or SM <NUM> may deem an NF subscription request message as valid if the NF subscription request message includes a pseudo NF instance ID identifying producer NF <NUM>, but may deem an NF update request message as invalid (or improper) if it includes the same pseudo NF instance ID but not the actual NF instance ID associated with producer NF <NUM>.

Referring to <FIG>, a table representing ID usage data <NUM> comprises columns and/or fields for message type and pseudo NF instance ID usage (e.g., indicating whether pseudo NF instance IDs are usable or allowed for a corresponding message type). A message type field may store information for representing a type of message associated with NF instances. For example, example message types depicted in <FIG> include NF registration messages, NF update messages, NF deregistration messages, NF discovery messages, NF profile messages, NF access token messages, and SBI messages.

A pseudo NF instance ID usage field may indicate whether pseudo NF instance IDs are usable or allowed for a corresponding message type. For example, as depicted in <FIG>, 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 do allow pseudo NF instance IDs.

It will also be appreciated that ID usage data <NUM> is for illustrative purposes and that different and/or additional data than the data depicted in <FIG> may be usable for indicating default values for particular data portions or other information. Further, ID usage data <NUM> may be stored (e.g., in data storage <NUM>) and managed using various data structures and/or computer readable media.

<FIG> is a message flow diagram illustrating an example NF discovery scenario involving an NF instance ID. In some embodiments, H-NRF <NUM> or SM <NUM> therein may receive an NF discovery request message requesting an NF for providing a particular service or information and may provide an NF discovery response comprising a pseudo NF instance ID for identifying a particular NF instance, e.g., where the pseudo NF instance ID is one of multiple temporary instance IDs assigned during an NF registration procedure or predetermined by a network operator. In such embodiments, foreign NF discovery requesters (e.g., in V-PLMN <NUM> <NUM>) may receive pseudo NF instance IDs for communicating with various NF instances in a home network (e.g., H-PLMN <NUM>) and, as such, nodes in V-PLMN <NUM> will not learn or know actual NF instance IDs for those NF instances.

Referring to <FIG>, e.g., prior to step <NUM>, an NF registration procedure for registering producer NF <NUM> (e.g., a particular NF instance) may occur. During or concurrent to the NF registration procedure, one or more pseudo NF instance IDs corresponding to producer NF <NUM> may be assigned and/or stored for use by one or more entities, e.g., H-NRF <NUM>. For example, producer NF <NUM> may register with H-NRF <NUM> using an NF instance ID 'ID45' and may receive, from H-NRF <NUM>, 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 producer NF <NUM> for a predetermined amount of time or while producer NF <NUM> is registered with the home network.

In step <NUM>, the NF discovery request message may be sent from H-SEPP <NUM> to H-NRF <NUM>.

In step <NUM>, H-NRF <NUM> or SM <NUM> therein may receive the NF discovery request message, determine or select an appropriate NF instance, i.e., producer NF <NUM>, for providing the service or information; and identify a corresponding pseudo NF instance ID for identifying producer NF <NUM>.

In step <NUM>, an NF discovery response comprising or indicating the pseudo NF instance ID identifying producer NF <NUM> may be sent from H-NRF <NUM> to H-SEPP <NUM> for forwarding to V-PLMN <NUM>.

In some embodiments, consumer NF <NUM> may use the pseudo NF instance ID to request service or related data from producer <NUM>, e.g., via an SBI request message.

<FIG> is a message flow diagram illustrating usage of an example NF access token comprising a pseudo NF instance ID. In some embodiments, H-NRF <NUM> or SM <NUM> therein may be configured to provide an access token comprising a pseudo NF instance ID for identifying a particular NF instance, e.g., where the pseudo NF instance ID is one of multiple temporary instance IDs assigned during an NF registration procedure or predetermined by a network operator. In such embodiments, foreign NF discovery requesters (e.g., in V-PLMN <NUM> <NUM>) may receive pseudo NF instance IDs for communicating with various NF instances in a home network (e.g., H-PLMN <NUM>) and, as such, nodes in V-PLMN <NUM> will not learn or know actual NF instance IDs for those NF instances.

In step <NUM>, the access token request message may be sent from H-SEPP <NUM> to H-NRF <NUM>.

In step <NUM>, H-NRF <NUM> or SM <NUM> therein may receive the access token request message, select an appropriate NF instance (e.g., producer NF <NUM>) for providing the service or information, and generate an access token comprising or indicating a pseudo NF instance ID for identifying the selected NF instance.

In step <NUM>, an access token response comprising the access token may be generated and sent from H-NRF <NUM> to H-SEPP <NUM> for forwarding to V-PLMN <NUM>.

In step <NUM>, producer NF <NUM> may use the pseudo NF instance ID obtained from the access token in the received SBI request message for validation purposes. For example, producer NF <NUM> may store a set of pseudo NF instance IDs assigned to itself, e.g., by H-NRF <NUM> during an NF registration procedure. In this example, producer NF <NUM> may confirm that the received pseudo NF instance ID matches a pseudo NF instance ID in the set of pseudo NF instance IDs.

<FIG> is a message flow diagram illustrating example validation of NF deregistration request messages. In some embodiments, H-NRF <NUM> or SM <NUM> 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 corresponding pseudo NF instance IDs) associated with a first NF instance (NF1) <NUM> during a registration procedure for NF1 <NUM>, H-NRF <NUM> or SM <NUM> therein may monitor ingress messages (e.g., e.g., inter-PLMN and/or HTTP/<NUM> messages) associated with NF instances and may determine whether each of these ingress messages are valid using the stored ID data before processing, forwarding, and/or responding to the ingress message. If H-NRF <NUM> or SM <NUM> determines that the NF instance ID or pseudo NF instance ID in the message does not match the relevant stored ID data or is not appropriate for the type of message, then H-NRF <NUM> or SM <NUM> may deem the message invalid and perform an invalid message action, e.g., discarding one or more of the inter-PLMN and/or report the event to a network operator or a network management system. If H-NRF <NUM> or SM <NUM> determines that the NF instance ID or pseudo NF instance ID in the message matches the relevant stored ID data and is appropriate for the type of message, then H-NRF <NUM> or SM <NUM> therein may deem the message valid and perform a valid message action, e.g., allowing the ingress message to be received at an intended destination and processed.

Referring to <FIG>, e.g., prior to step <NUM>, an NF registration procedure for registering NF1 <NUM> may occur. During or concurrent to the NF registration procedure, one or more pseudo NF instance IDs corresponding to NF1 <NUM> may be assigned and/or stored for use by one or more entities, e.g., H-NRF <NUM>. For example, NF1 <NUM> may register with H-NRF <NUM> using an NF instance ID 'ID1' and may receive, from H-NRF <NUM>, 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 <NUM> for a predetermined amount of time or while NF1 <NUM> is registered with the home network.

In some embodiments, after NF1 <NUM> has registered with H-NRF <NUM>, a consumer NF instance (NF2) <NUM> 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 the information. For example, NF2 <NUM> may be or appear to be a <NUM> NF instance located in a V-PLMN <NUM> <NUM>. In this example, NF2 <NUM> may be compromised, hacked, or otherwise configured to perform or attempt to perform malicious or improper actions, such as initiate DoS attacks using learned NF instance IDs or pseudo NF instance IDs.

In step <NUM>, an NF discovery request message for discovering an NF instance to provide service or data may be sent from NF2 <NUM> to H-NRF <NUM>, e.g., via V-SEPP <NUM> and H-SEPP <NUM> (not shown).

In step <NUM>, after receiving the NF discovery request message, H-NRF <NUM> and/or SM <NUM> may identify a relevant NF instance (e.g., NF1 <NUM>) for providing the service or data and may determine a pseudo NF instance ID 'PID1' for communicating with and/or referring to that NF instance. In this example, H-NRF <NUM> and/or SM <NUM> may generate an NF discovery response that indicates the pseudo NF instance ID.

In step <NUM>, an NF discovery response (e.g., as an HTTP/<NUM> message) comprising a pseudo NF instance ID 'PID1' for communicating with and/or referring to NF1 <NUM> may be sent from H-NRF <NUM> to NF2 <NUM>, e.g., via V-SEPP <NUM> and H-SEPP <NUM> (not shown).

In step <NUM>, an NF deregistration request message for deregistering NF1 <NUM> may be sent from NF2 <NUM> to H-NRF <NUM> and may include the pseudo NF instance ID 'PID1'. For example, NF2 <NUM> in a V-PLMN <NUM> <NUM> may be compromised, hacked, or otherwise configured to try to deregister NF1 <NUM>. However, because NF2 <NUM> does not know the actual NF instance ID (e.g., 'ID1') of NF1 <NUM>, NF2 <NUM> uses the pseudo NF instance ID 'PID1' in its deregistration attempt of NF1 <NUM>.

In step <NUM>, H-NRF <NUM> or SM <NUM> 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, e.g., discard the NF deregistration request message. For example, H-NRF <NUM> or SM <NUM> may identify that the NF deregistration request message lacks an actual 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.

In step <NUM>, a second NF deregistration request message for deregistering NF1 <NUM> may be sent from NF1 <NUM> to H-NRF <NUM> and may include its actual or non-pseudo NF instance ID 'ID1'.

In step <NUM>, H-NRF <NUM> or SM <NUM> therein may receive the second NF deregistration request message, perform a message validation procedure, and determine that the second NF deregistration request message is valid, and perform an invalid message action. For example, H-NRF <NUM> or SM <NUM> may identify that the second NF deregistration request message include an actual or non-pseudo NF instance ID, thereby indicating that the NF deregistration request message is valid and should be answered.

In step <NUM>, e.g., after determining that the second the NF deregistration request message is valid, H-NRF <NUM> or SM <NUM> may deregister NF1 <NUM> and send an NF deregistration response to NF1 <NUM> indicating that NF1 <NUM> has been deregistered successfully.

<FIG> is a diagram illustrating an example process <NUM> for hiding NF instance IDs in a communications network. In some embodiments, example process <NUM> described herein, or portions thereof, may be performed at or performed by a network node, e.g., NRF <NUM>, node <NUM>, SM <NUM>, and/or another module, NF, or node.

In step <NUM>, an NF registration request message (e.g., a <NUM> NF registration request message) for registering a first NF instance of a first NF may be received, wherein the NF registration request message includes a first NF instance ID for identifying the first NF instance.

In step <NUM>, a mapping between the first NF instance ID and at least one pseudo NF instance ID may be stored, wherein the data store includes mappings between NF instance IDs and related pseudo NF instance IDs.

In step <NUM>, an NF registration response message (e.g., an <NUM> NF registration response message) including the at least one pseudo NF instance ID for identifying the first NF instance may be generated and sent.

In some embodiments, a first NF may be configured for receiving, 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 a first NF instance ID for identifying the first NF instance; storing the at least one pseudo NF instance ID associated with the first NF instance ID; and using a first pseudo NF instance ID of the at least one pseudo NF instance ID for sender identification when sending a request or response message.

In some embodiments, an NF (e.g., H-NRF <NUM>) may be configured for receiving, from a consumer NF instance, a service request message for discovering a first NF instance; determining, using a data store storing associations between NF instance IDs and related pseudo NF instance IDs, a first pseudo NF instance ID of one or more pseudo NF instance IDs associated with the first NF instance ID; and sending, to the consumer NF instance, the first pseudo NF instance ID.

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

In some embodiments, a consumer NF instance may use the first pseudo NF instance ID to communicate with the first NF instance via an SBI.

In some embodiments, a network node (e.g., H-NRF <NUM> or H-SEPP <NUM>) may be configured for receiving a service request message for performing an action associated with a first NF instance, wherein the service request message comprises an ID for the first NF instance; determining, using the ID and a data store associations between NF instance IDs and related pseudo NF instance IDs, that the service request message is valid or invalid; in response to determining that the service request message is invalid, performing an invalid message action; and in response to determining that the service request message is valid, performing a valid message action.

In some embodiments, a network node for validating a request message using a 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.

In some embodiments, an invalid message action may include discarding a request message or notifying a network operator or a management system.

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.

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 an ID in the service request message is one of the one or more pseudo NF instance IDs associated with the first NF instance ID and that pseudo NF instance IDs are not allowed for that message or its message type.

It will be appreciated that process <NUM> is for illustrative purposes and that different and/or additional actions may be used. It will also be appreciated that various actions described herein may occur in a different order or sequence.

It will be appreciated that while some aspects of the subject matter described herein has been discussed with reference to <NUM> networks various other networks may utilize some aspects of the subject matter described herein. For example, any network that utilizes NF instance IDs or similar IDs may use 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.

It will be appreciated that while some aspects of the subject matter described herein has been discussed with reference to NRF related messages various other messages may utilize pseudo NF instance IDs or other aspects of the subject matter described herein. For example, an UECM registration request by AMF may utilize a pseudo NF instance ID for identification during a UECM service registration. Further, it will be appreciated that pseudo NF instance IDs may be used in various message types of portions thereof, e.g., a message payload and/or header. For example, a pseudo NF Instance ID may be part of an access token and CCA token. In another example, a pseudo NF instance ID may be in a load control information (LCI) header or an overload control information (OCI) header.

It should be noted that node <NUM>, SM <NUM>, and/or functionality described herein may constitute a special purpose computing device. Further, node <NUM>, SM <NUM>, and/or functionality described herein can improve the technological field of network security and/or message validation in a communications network. For example, by using pseudo NF instance IDs and/or reducing the usage of NF instance IDs to NF registration, NF update, NF deregistration scenarios, malicious activities and their negative consequences (e.g., 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 <NUM> or SM <NUM> therein can prevent DOS attacks that use leaked NF instance IDs to attempt unauthorized NF updates or NF deregistrations. Further, 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.

Claim 1:
A method for hiding network function, NF, instance identifiers, IDs, in a communications network, the method comprising:
at an NF repository function, NRF, comprising 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 identifier, ID, for identifying the first NF instance (<NUM>);
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 mappings between NF instance IDs and related pseudo NF instance IDs (<NUM>);
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 (<NUM>);
determining, for different types of ingress messages at the NRF that include the at least one pseudo NF instance ID, whether the ingress message is valid based on whether the pseudo NF instance ID is usable or allowed for that message type;
in response to determining that the ingress message is invalid, performing an invalid message action; and in response to determining that the ingress message is valid, performing a valid message action.