Patent Description:
<NUM> radio access technology is supported by a service-based architecture. A service-based architecture is a style of software design where services are provided to other components by application components, through a communication protocol over a network. The <NUM> Core Network is a mesh of interconnected services, which can be associated with various functions. One component of the <NUM> Core Network is a Network Repository Function (NRF) (which can also be called a "Network Function (NF) Repository Function"). The NRF can facilitate service registration and discovery so that various other network functions can discover each other. Details associated with <NUM> radio access technology and associated <NUM> Core Network are described in the 3GPP Technical Specification <NUM>. The document "<NPL>" discloses a NF discovery request with an optional query parameter defining the maximum number of NF Profiles to be returned in the query.

The invention is defined by a method, a system and a computer program as provided in the independent claims <NUM>, <NUM> and <NUM> respectively.

Techniques described herein are directed to controlling responses to discovery requests received via a Network Repository Function (NRF) in a Fifth Generation (<NUM>) mobile network. As described above, the NRF is responsible for providing a discovery response for specific Network Function (NF) producer types. For example, when a NF consumer (e.g., a <NUM> NF that consumes services) sends a discovery request, the NRF can access a list of NF producers (e.g., <NUM> NFs that provide services) for the NF producer type requested. In some examples, there can be several hundred NF producers, and as such, the NRF can respond to a discovery request indicating up to the several hundred NF producers. Techniques described herein are directed to a configurable parameter that can be used by the NRF to reduce the number of indications of NF producers that the NRF responds back to the NF consumer during such discovery events.

The configurable parameter, which can be referred to as a "rate limit control," can be configured by a NF operator (e.g., T-Mobile, AT&T, etc.) so that the number of indications (e.g., of NF producers) returned by the NRF meets or exceeds the number of service types available and provides redundancy, but is less than the total number of NF producers available for a NF producer type. As a result, each NF consumer need not include a load balancer for analyzing discovery responses and instead, the NRF optimizes and throttles the number of indications returned to NF consumers responsive to discovery requests. Thus, NF consumers are not flooded in response to a discovery request.

As described below, the <NUM> mobile network can include a control plane function group that handles control plane data. In some examples, the control plane function group can manage control plane systems and/or user plane systems that carry data traffic through the network via services availed by the various systems and/or components associated therewith. The NRF described above can be a component of the control plane function group. The NRF can include one or more data stores that store indications of NF producers and corresponding configurable parameters. Responsive to receiving a discovery request from a NF consumer, which can be another component of the control plane function group, the NRF can utilize a configurable parameter (e.g., a "rate limit control") to determine how many indications of NF producers, of a particular NF producer type, to include in a response to the discovery request. The number of indications of NF producers can be based on the configurable parameter and can be less than the total number of NF producers associated with the NF producer type. The NF consumer can then analyze the discovery response to access (or deny) services associated with the discovery request.

Techniques described herein offer various improvements to existing technology. As described above, each type of NF producer can be associated with several NF producers. In some examples, there can be as many as several hundred NF producers associated with an NF producer type. In existing technology, upon receiving a discovery request from a NF consumer, the NRF sends a discovery response that includes indications of all of the NF producers. Such a response can require a significant amount of signaling, consume network resources, and necessitate storage for storing the indications of all of the NF producers. Furthermore, the NF consumer can be flooded by discovery responses that include so many indications. Such flooding can lead to overload conditions in NF consumer. Such overload conditions can cause unavailability of network services. In some examples, the NF consumer can utilize a load balancer for balancing how the NF consumer processes the discovery response, to mitigate the flooding and resulting unavailability of network services.

Techniques described herein, are directed to a throttling mechanism (e.g., a configurable parameter or "rate limit control") that is associated with the NRF. The throttling mechanism can reduce a number of indications of NF producers that are provided to the NF consumer responsive to a discovery request. By reducing the number of indications of NF producers that are provided to the NF consumer, techniques described herein reduce the signaling required in such discovery events and can alleviate the need for a load balancer to be associated with each NF consumer (which can result in a cost savings for NF operators). Furthermore, techniques described herein conserve network resources and reduce the storage requirements for NF consumers. Techniques described herein thereby alleviate discovery response floods that can lead to overload conditions in NF consumers. Such overload conditions can cause unavailability of network services. As such, techniques described herein offer improvements to existing technology. Additional or alternative improvements can be observed throughout the discussion of <FIG> below.

<FIG> illustrates an example environment <NUM> for signaling between functions of a <NUM> mobile network, as described herein. Additional details associated with the <NUM> mobile network are described below with reference to <FIG>.

In <FIG>, a Network Function (NF) consumer <NUM> sends a discovery request <NUM> to a Network Repository Function (NRF) <NUM>. In at least one example, the NF consumer <NUM> can be any one of an Access and Mobility Management Function (AMF), an Authentication Server Function (AUSF), a Network Exposure Function (NEF), a Policy Control Function (PCF), a Session Management Function (SMF), a Unified Data Management (UDM), a Charging Function (CHF), an Equipment Identity Register (EIR), a Location Management Function (LMF), a Session Plane Function (SPF), or the like. Each of the NF consumers described above can be associated with a <NUM> mobile network and can provide services to user equipment (not pictured in <FIG>) via the <NUM> mobile network. Additional details associated with the NF consumers described above are provided below with reference to <FIG>.

In general, the NRF <NUM> can be implemented as a network function including functionality to support service discovery (e.g., receive a network function discovery request and provide information associated with the discovered network function instances to a requesting entity). In at least one example, the NRF <NUM> can maintain records of available network functions and their supported services. The NRF <NUM> can allow other network functions to subscribe and be notified of registrations from network functions of a given type. In some instances, the NRF <NUM> can receive utilization information, capability information, etc. from various network functions to provide such utilization information to the other network functions discussed herein. Further, the NRF <NUM> can select, assign, implement, or otherwise determine network functions to be used in a network based at least in part on utilization information, as discussed herein.

As described above, the NRF <NUM> can be implemented as a network function that can provide discovery responses to discovery requests in support of support service discovery. In at least one example, a discovery request, such as the discovery request <NUM>, can be associated with a particular NF producer type. In such an example, the discovery response <NUM> can provide indications of NF producers associated with the particular NF producer type.

<FIG> includes Network Function (NF) producer(s) <NUM>. The NF producer(s) <NUM> can be any one of a SMF, a UDM, an AUSF, a Short Message Service Function (SMSF), a LMF, a Network Slice Selection Function (NSSF), EIR, a Unified Data Repository (UDR), a CHF, a NEF, or the like. Each of the NF producers described above can be associated with a <NUM> mobile network and can provide services to user equipment (not pictured in <FIG>) via the <NUM> mobile network. In some examples, the <NUM> mobile network can include multiple instances of each type of NF producer described above. Additional details associated with the NF producers described above are provided below with reference to <FIG>.

In some examples, network functions can assume the role of either NF consumers or NF producers. That is, a NF consumer in a discovery event can be a NF producer in another discovery event. For example, in a first discovery event, a NF consumer can comprise the SMF and in a second discovery event, the SMF can comprise a NF producer. Table <NUM>, provided below, provides non-limiting examples of NF consumer-NF producer pairs.

In at least one example, each NF producer of the NF producer(s) <NUM> can register with the NRF <NUM>. That is, the NF producer can send a registration request <NUM> to the NRF <NUM>, which can include an indication of its presence and profile(s) associated with the NF producer. The registration request <NUM> can additionally include an indication of services available via the NF producer. The NRF <NUM> can store such information in one or more data stores <NUM> associated with the NRF <NUM>. In at least one example, the NRF <NUM> can provide a registration response <NUM> responsive to the registration request <NUM>. Additional details associated with such registration procedures are described in the 3GPP Technical Specification <NUM>.

In addition to storing the information provided via registration requests, such as the registration request <NUM>, the data store(s) <NUM> can store a data structure <NUM> that includes indications of NF producer types and corresponding rate limit controls. As described above, a NF operator associated with services provided via the <NUM> mobile network (e.g., T-Mobile, AT&T, etc.) can provide a configurable parameter, which can be referred to as a "rate limit control," that can indicate a number of indications of NF producer(s) to be provided responsive to a discovery request, such as the discovery request <NUM>.

In at least one example, the configurable parameter can be configured by the NF operator so that the number of indications (e.g., of NF producers) returned in a discovery response meets or exceeds the number of service types available for the NF producer type and provides redundancy, but is less than the total number of NF producers available for a NF producer type. That is, the configurable parameter can be determined based at least in part on a number of service types available for a NF producer type and a redundancy threshold. The redundancy threshold can be configurable also but can provide an assurance that the NRF <NUM> can provide a discovery response to a discovery request that includes indications of NF producers, even if an NF producer of a NF producer type is inoperable, unavailable, or the like. As such, the configurable parameter can be based at least in part on a number that satisfies the redundancy threshold. In at least one example, each NF producer type can be associated with its own configurable parameter. That is, a configurable parameter is particular to a NF producer type.

In at least one example, the NF consumer <NUM> can send a discovery request <NUM> to the NRF <NUM> for information associated with a particular NF producer type. The NRF <NUM> can perform a lookup, or other search, to determine the rate limit control associated with the NF producer type. Based at least in part on determining the rate limit control, the NRF <NUM> can generate a list of indications of NF producers associated with the NF producer type. In some examples, the NRF <NUM> may select a subset of indications of NF producers associated with the NF producer type from the total number of NF producers associated with the NF producer type. The number of indications in the subset can be determined based on the rate limit control. The NRF <NUM> can send the list of indications of the NF producers associated with the NF producer type to the NF consumer <NUM> via the discovery response <NUM>.

In some examples, the discovery response <NUM> can be associated with a timer corresponding to a time period after which the list of indications of NF producers associated with the NF producer type expires. The NF consumer <NUM> can store the list of indications of NF producers and, upon receiving a subsequent request, can determine whether the time period has lapsed (e.g., the list of indications of NF producers has expired). If the time period has lapsed, the NF consumer <NUM> can send a subsequent discovery request and the process described above can repeat itself. Additional details are described below with reference to <FIG> and <FIG>.

Take as an example, an instance where the NF consumer <NUM> is the AMF, which can provide authentication services for user equipment. Responsive to a new user equipment requesting to authenticate with the <NUM> mobile network, the AMF can send a discovery request <NUM> to the NRF <NUM> for information associated with the UDM (e.g., NF producer type of UDM). The UDM can provide generation of authentication credentials, user identification, access authorization, subscription management, and the like. The NRF <NUM> can perform a lookup, or other search, to determine the rate limit control associated with the NF producer type of UDM. In <FIG>, the rate limit control associated with the NF producer type of UDM is <NUM>. As such, the NRF <NUM> can generate a list of indications of UDMs. The list can have <NUM> indications, each associated with a different instance of a UDM. In some examples, the list of <NUM> indications can be a subset of a larger set of indications. For instance, in the example of UDM, there can be <NUM>-<NUM> instances of UDMs from which the NRF <NUM> can select the subset of <NUM>. The NRF <NUM> can send the list of indications of UDMs to the AMF via the discovery response <NUM>. The AMF can then analyze the list of indications of UDMs to determine whether the user associated with the user equipment is authenticated for accessing the <NUM> mobile network via the NF operator and can send a response to the user equipment indicating such.

Take as another non-limiting example, an instance where the NF consumer <NUM> is the AMF, which can provide session management for establishing data sessions for user equipment. Responsive to a new user equipment requesting to establish a new data session, the AMF can send a discovery request <NUM> to the NRF <NUM> for information associated with the SMF (e.g., NF producer type of SMF). The NRF <NUM> can perform a lookup, or other search, to determine the rate limit control associated with the NF producer type of SMF. In <FIG>, the rate limit control associated with the NF producer type of SMF is <NUM>. As such, the NRF <NUM> can generate a list of indications of SMFs. The list can have <NUM> indications, each associated with a different instance of a SMF. As described above, in some examples, the list of <NUM> indications can be a subset of a larger set of indications. The NRF <NUM> can send the list of indications of SMFs to the AMF via the discovery response <NUM>. The AMF can then analyze the list of indications of SMFs to facilitate the establishment of a data session for the user equipment.

<FIG> illustrates an example environment <NUM> including a user equipment and various components of a <NUM> mobile network, as described herein. The example environment <NUM> includes a user equipment (UE) <NUM> and various components implementing discovery events, as described herein. For example, the environment <NUM> includes the UE <NUM>, a (radio) access network (RAN) <NUM>, one or more user plane function(s) (UPF(s)) <NUM>, and a domain or data network (DN) <NUM>.

In accordance with various embodiments described herein, the terms "user equipment (UE)," "user device," "wireless communication device," "wireless device," "communication device," "mobile device," and "client device," can be used interchangeably herein to describe any UE (e.g., the UE <NUM>) that is capable of transmitting/receiving data wirelessly using any suitable wireless communications/data technology, protocol, or standard, such as Global System for Mobile Communications (GSM), Time Division Multiple Access (TDMA), Universal Mobile Telecommunications System (UMTS), Evolution-Data Optimized (EVDO), Long Term Evolution (LTE), Advanced LTE (LTE+), New Radio (NR), Generic Access Network (GAN), Unlicensed Mobile Access (UMA), Code Division Multiple Access (CDMA), Orthogonal Frequency Division Multiple Access (OFDM), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Advanced Mobile Phone System (AMPS), High Speed Packet Access (HSPA), evolved HSPA (HSPA+), Voice over internet protocol (VoIP), VoLTE, Institute of Electrical and Electronics Engineers' (IEEE) <NUM>. 1x protocols, WiMAX, Wi-Fi, Data Over Cable Service Interface Specification (DOCSIS), digital subscriber line (DSL), and/or any future internet protocol (IP)-based network technology or evolution of an existing IP-based network technology.

In general, the UE <NUM> can be implemented as any suitable type of computing device configured to communicate over a wired or wireless network, including, without limitation, a mobile phone (e.g., a smart phone), a tablet computer, a laptop computer, a portable digital assistant (PDA), a wearable computer (e.g., electronic/smart glasses, a smart watch, fitness trackers, etc.), an internet-of-things (IoT) device, an in-vehicle (e.g., in-car) computer, and/or any similar mobile device, as well as situated computing devices including, without limitation, a television (smart television), set-top-box (STB), desktop computer, an IoT device, and the like.

The UE <NUM> is configured to utilize various RANs, such as the RAN <NUM>, in order to access the DN <NUM>. In general, the DN <NUM> is agnostic to the access technology that is used to connect a UE to the DN <NUM>. In this manner, the UE <NUM> can connect to the DN <NUM> via the RAN <NUM>, which can include a <NUM>rd Generation Partnership Project (3GPP) RAN, such a GSM/EDGE RAN (GERAN), a Universal Terrestrial RAN (UTRAN), or an evolved UTRAN (E-UTRAN), or alternatively, via a "non-3GPP" RAN, such as a Wi-Fi RAN, or another type of wireless local area network (WLAN) that is based on the IEEE <NUM> standards. If the UE <NUM> accesses the DN <NUM> through a Wi-Fi access network, the RAN <NUM> may include a Wi-Fi access point (AP). Providing access to the DN <NUM> through non-3GPP RANs has opened the door to recent advancements in IMS-based services, such as the introduction of Wi-Fi calling, which allows users to initiate and receive calls over an available Wi-Fi AP. Environments can include any number and type of base stations representing any number and type of macrocells, microcells, picocells, or femtocells, for example, with any type or amount of overlapping coverage or mutually exclusive coverage.

In general, the UPF(s) <NUM> can be implemented as network function(s) including functionality to control data transfer between the UE <NUM> and the various components of the <NUM> mobile network. In some instances, the UPF(s) <NUM> can include functionality to act as an anchor point for radio access technology (RAT) handover (e.g., inter and intra), external protocol data unit (PDU) session point of interconnect to a data network (e.g., the internet), packet routing and forwarding, packet inspection and user plane portion of policy rule enforcement, traffic usage reporting, traffic routing, Quality of Service (QoS) handling for user plane (e.g., packet filtering, gating, uplink/downlink rate enforcement), uplink traffic verification, transport level packet marking in the uplink and downlink, downlink packet buffering and downlink data notification triggering, and the like.

In general, the DN <NUM> can include any public or private network(s), such as the Internet. In addition, the DN <NUM> may include one or more devices that can receive and transmit data. For example, the DN <NUM> may include any of media server(s), user device(s), and the like.

In general, a user can further utilize the UE <NUM> to communicate with other users and associated UEs via an IP multimedia subsystem (IMS) core (sometimes referred to as the "IMS core network," the "IMS network," the "Core Network (CN)," or the "IM CN Subsystem"), which can be at least a portion of the DN <NUM>. IMS is an architectural framework defined by the 3GPP for delivering IP multimedia to a UE, such as the UE <NUM>. The IMS core can be maintained and/or operated by one or more service providers, such as one or more wireless carriers ("carriers"), that provide IMS-based services to users who are associated with UEs, such as the UE <NUM>. For example, a service provider can offer multimedia telephony services that allow a user to call or message other users via the IMS core using his/her UE. In at least one example, the NF operator(s) described herein can correspond to service provider(s) as described herein. A user can also utilize an associated UE to receive, provide, or otherwise interact with various different IMS-based services by accessing the IMS core. It is to be appreciated that any number of base stations and/or IMS nodes can be included in the IMS network.

Accordingly, an operator of the IMS core can offer any type of IMS-based service, such as, telephony services, emergency services (e.g., E911), gaming services, instant messaging services, presence services, video conferencing services, social networking and sharing services, location-based services, push-to-talk services, and so on. In order to access these services (e.g., telephony services), a UE is configured to request establishment of a communication session. In the case of telephony services, the communication session can comprise a call (e.g., a voice-based communication session, such as a VoLTE call, or a Wi-Fi call).

In at least one example, as part of a control plane function group <NUM>, the example environment <NUM> includes, but is not limited to, a Network Exposure Function (NEF) <NUM>, an Authentication Server Function (AUSF) <NUM>, an Access and Mobility Management Function (AMF) <NUM>, a Policy Control Function (PCF) <NUM>, a Session Management Function (SMF) <NUM>, and a Unified Data Management (UDM) <NUM>. The control plane function group <NUM> can additionally include the NRF <NUM>, described above with reference to <FIG>. Furthermore, the control plane function group <NUM> can additionally or alternatively include other functions, including but not limited to, a charging function (CHF), an Equipment Identify Register (EIR), a Location Management Function (LMF), a Session Plane Function (SPF), a Short Message Service Function (SMSF), a Network Slice Selection Function (NSSF), or a Unified Data Repository (UDR). As described above, the network functions can assume roles of either NF consumers or NF producers.

In general, the NEF <NUM> can be implemented as a network function including functionality to securely expose services and/or capabilities provided by and amongst the various network functions, as discussed herein. In some instances, the NEF <NUM> receives information from other network functions and can store the received information as structured data using an interface to a data storage network function.

In general, the AUSF <NUM> can be implemented as a network function including functionality to provide authentication to various devices in the network. For example, the AUSF <NUM> can request device credentials (e.g., security key(s)), verify that a device is authorized to connect to a network, and/or control access to the network based on the device credentials.

In general, the AMF <NUM> can be implemented as a network function including functionality to provide UE-based authentication, authorization, mobility management, etc., to various UEs. In some instances, the AMF <NUM> can include functionality to terminate a RAN control plane interface between the UE <NUM> and other functions on the network. In some instances, the AMF <NUM> can include functionality to perform registration management of the UE <NUM> in a network, connection management, reachability management, mobility management, access authentication, access authorization, security anchor functionality (e.g., receiving and/or transmitting security keys during registration/authorization), and the like.

In general, the PCF <NUM> can be implemented as a network function including functionality to support unified policy framework to govern network behavior, provide policy rules to control plane functions and/or enforce such rules, and/or implement a front end to access subscription information relevant for policy decisions in a data repository.

In general, the SMF <NUM> can be implemented as a network function including functionality to manage communication sessions by and between UEs, and/or to provide internet protocol (IP) addresses to the UEs. In some instances, the SMF <NUM> can select a UPF to provide services to the UE <NUM> in response to receiving a request from the UE <NUM>, as discussed herein.

In general, the UDM <NUM> can be implemented as a network function including functionality to process authentication credentials, handle user identification processing, manage registration and/or mobility, manage subscriptions between a UE and a carrier, and/or manage short message service (SMS) data.

As described above, the control plane function group <NUM> can additionally or alternatively include other functions, including but not limited to, a CHF (e.g., a network function that can be implemented to provide connectivity charging), an EIR (e.g., a network function that can be implemented to provide equipment identity registration, authentication, and/or security services), a LMF (e.g., a network functionality that can be implemented to provide location determinations), a SPF (e.g., a network functionality that can be implemented to provide UE internet protocol (IP) address allocation and protocol data unit session control), a SMSF (e.g., a network functionality that can be implemented to provide SMS services), a NSSF (e.g., a network functionality that can be implemented to provide network slicking services), or a UDR (e.g., a network functionality that can be implemented to store user subscription data, policy data, structured data for exposure, application data, and the like).

The control plane function group <NUM> can be in communication with an application function (AF) <NUM>. In general, the AF <NUM> can be implemented as a network function including functionality to route traffic to/from applications operating on the <NUM> mobile network, facilitate accessing the NEF <NUM>, and interact with the policy framework for policy control in connection with the PCF <NUM>.

In general, the devices and network functions illustrated in the environment <NUM> can be communicatively coupled via one or more control planes which can pass controls and signaling by and between the various components discussed herein. Further, the environment <NUM> can include a plurality of each of the various functions (e.g., the SMF <NUM> can represent a plurality of SMFs, for example). That is, the functions illustrated can represent a NF type and each NF type can include one or more instances of the NF type. The environment <NUM> can further include additional functions and is not limited to those represented in <FIG>.

<FIG> illustrates example device(s) to techniques described herein. In some embodiments, some or all of the functionality discussed herein can be implemented in the device(s) <NUM>. Further, the device(s) <NUM> can be implemented as one or more server computers <NUM> (as illustrated in <FIG>), a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, such as a cloud infrastructure, and the like. It is to be understood in the context of this disclosure that the device(s) <NUM> can be implemented as a single device or as a plurality of devices with components and data distributed among them.

As illustrated, the device(s) <NUM> comprise a memory <NUM> storing the NEF <NUM>, the AUSF <NUM>, the NRF <NUM>, the UPF(s) <NUM>, the DN <NUM>, the AMF <NUM>, the PCF <NUM>, the SMF <NUM>, the UDM <NUM>, and the AF <NUM>. In additional or alternative examples, the memory <NUM> can store a CHF, an EIR, a LMF, a SPF, a SMSF, a NSSF, a UDR, or other network functions as described herein. In various embodiments, the memory <NUM> may also comprise additional functions and structures that are not explicitly described herein. Also, the device <NUM> includes processor(s) <NUM>, at least one removable storage <NUM> and at least one non-removable storage <NUM>, input device(s) <NUM>, output device(s) <NUM>, and transceiver(s) <NUM>.

Aspects of the NEF <NUM>, the AUSF <NUM>, the NRF <NUM>, the UPF(s) <NUM>, the DN <NUM>, the AMF <NUM>, the PCF <NUM>, the SMF <NUM>, the UDM <NUM>, the AF <NUM> (and the CHF, the EIR, the LMF, the SPF, the SMSF, the NSSF, the UDR, etc.) are discussed above with connection with at least <FIG> and <FIG>. In general, these functions comprise components of a <NUM> mobile network, as described above.

In various embodiments, the memory <NUM> is volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. One or more of the NEF <NUM>, the AUSF <NUM>, the NRF <NUM>, the UPF(s) <NUM>, the DN <NUM>, the AMF <NUM>, the PCF <NUM>, the SMF <NUM>, the UDM <NUM>, the AF <NUM> (and other functions, including but not limited to, the CHF, the EIR, the LMF, the SPF, the SMSF, the NSSF, the UDR, etc.) stored in the memory <NUM> can comprise methods, threads, processes, applications or any other sort of executable instructions. One or more of the NEF <NUM>, the AUSF <NUM>, the NRF <NUM>, the UPF(s) <NUM>, the DN <NUM>, the AMF <NUM>, the PCF <NUM>, the SMF <NUM>, the UDM <NUM>, the AF <NUM> (and other functions, including but not limited to, the CHF, the EIR, the LMF, the SPF, the SMSF, the NSSF, the UDR, etc.) can also include files and databases.

In some embodiments, the processor(s) <NUM> is a central processing unit (CPU), a graphics processing unit (GPU), or both CPU and GPU, or other processing unit or component known in the art.

The device <NUM> also includes additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in <FIG> by removable storage <NUM> and non-removable storage <NUM>. Tangible computer-readable media can include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Memory <NUM>, removable storage <NUM> and non-removable storage <NUM> are all examples of computer-readable storage media. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVDs), content-addressable memory (CAM), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the device <NUM>. Any such tangible computer-readable media can be part of the device <NUM>.

The device <NUM> also can include input device(s) <NUM>, such as a keypad, a cursor control, a touch-sensitive display, voice input device, etc., and output device(s) <NUM> such as a display, speakers, printers, etc. These devices are well known in the art and need not be discussed at length here.

As illustrated in <FIG>, the device <NUM> also includes one or more wired or wireless transceiver(s) <NUM>. For example, the transceiver(s) <NUM> can include a network interface card (NIC), a network adapter, a local area network (LAN) adapter, or a physical, virtual, or logical address to connect to the various base stations or networks contemplated herein, for example, or the various user equipment and servers. To increase throughput when exchanging wireless data, the transceiver(s) <NUM> can utilize multiple-input/multiple-output (MIMO) technology. The transceiver(s) <NUM> can comprise any sort of wireless transceivers capable of engaging in wireless, radio frequency (RF) communication. The transceiver(s) <NUM> can also include other wireless modems, such as a modem for engaging in Wi-Fi, WiMAX, Bluetooth, or infrared communication.

<FIG> and <FIG> illustrate example processes in accordance with embodiments of the disclosure. These processes are illustrated as logical flow graphs, each operation of which represents a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and/or in parallel to implement the processes.

<FIG> illustrates an example process <NUM> for implementing NRF discovery control, as described herein.

Block <NUM> illustrates receiving, at a Network Repository Function (NRF), indications of Network Function (NF) producers. In at least one example, each NF producer associated with a <NUM> mobile network can register with the NRF <NUM>. That is, a NF producer can send a registration request to the NRF <NUM>, which can include an indication of its presence and profile(s) associated with the NF producer. The registration request can additionally include an indication of services available via the NF producer. The NRF <NUM> can store such information in one or more data stores <NUM> associated with the NRF <NUM>. In some examples, the data store(s) <NUM> can include information received from a plurality of NF producers associated with the same NF producer type.

Block <NUM>, which is optional, illustrates sending a request for indications of NF producers. In an example, the NF producer(s) <NUM> can provide information to the NRF <NUM> in association with registration, as described above. In other examples, the NF producer(s) <NUM> can provide such information to the NRF <NUM> responsive to the NRF <NUM> sending a request for such information.

Block <NUM> illustrates associating, in the NRF, a configurable parameter with a NF producer type. As described above, a NF operator associated with services provided via the <NUM> mobile network (e.g., T-Mobile, AT&T, etc.) can provide a configurable parameter, which can be referred to as a "rate limit control," that can indicate a number of indications of NF producer(s) associated with a NF producer type to be provided responsive to a discovery request, such as the discovery request <NUM>. In at least one example, the configurable parameter can be configured by the NF operator so that the number of indications (e.g., of NF producers) returned in a discovery response meets or exceeds the number of service types available for the NF producer type and provides redundancy, but is less than the total number of NF producers available for a NF producer type. That is, the configurable parameter can be determined based at least in part on a number of service types available for a NF producer type and a redundancy threshold. The redundancy threshold can be configurable also but can provide an assurance that the NRF <NUM> can provide a discovery response to a discovery request that includes indications of NF producers, even if an NF producer of a NF producer type is inoperable, unavailable, or the like. As such, the configurable parameter can be based at least in part on a number that satisfies the redundancy threshold. In at least one example, each NF producer type can be associated with its own configurable parameter. That is, a configurable parameter is particular to a NF producer type.

In at least one example, the data store(s) <NUM> can store a data structure <NUM> that includes indications of NF producer types and corresponding rate limit controls. That is, the NRF <NUM> can associate configurable parameters provided by NF operators with corresponding NF producer types.

Block <NUM> illustrates receiving, from a Network Function (NF) consumer, a discovery request for information associated with the NF producer type. As described above, the NRF <NUM> can be implemented as a network function including functionality to support service discovery (e.g., receive a network function discovery request and provide information associated with the discovered network function instances to a requesting entity). In at least one example, the NRF <NUM> can maintain records of available network functions and their supported services. The NRF <NUM> can allow other network functions to subscribe and be notified of registrations from network functions of a given type. In at least one example, a NF consumer <NUM> can send a discovery request to the NRF <NUM> for information associated with a particular NF producer type.

Block <NUM> illustrates generating a list of NF producers based at least in part on the indications. In at least one example, responsive to receiving the request for information associated with the NF producer type, the NRF <NUM> can perform a lookup, or other search, to access indications of NF producers associated with the NF producer type. The NRF <NUM> can generate a list of indications of NF producers associated with the NF producer type. In at least one example, the initial list of indications of NF producers associated with the NF producer type can include indications of all NF producers associated with the NF producer type.

Block <NUM> illustrates determining whether a number of NF producers in the list exceeds the configurable parameter associated with the NF producer type. In at least one example, the NRF <NUM> can compare the number of indications of the NF producers with the configurable parameter to determine whether the number of indications exceeds the configurable parameter. If the number of indications does not exceed the configurable parameter, the NRF <NUM> can send a response based at least in part on the list of NF producers to the NF consumer <NUM>, as illustrated in block <NUM>. That is, the NRF <NUM> can send the list of indications of NF producers to the NF consumer <NUM>. However, if the number of indications exceeds the configurable parameter, the NRF <NUM> can select a subset of indications of the NF producers to generate another list, as illustrated in block <NUM>. The number of indications in the subset can be determined based on the configurable parameter. The NRF <NUM> can send the new (e.g., reduced) list of indications of the NF producers associated with the NF producer type to the NF consumer <NUM> via the discovery response, as illustrated in block <NUM>.

That is, the configurable parameter, which can be referred to as a "rate limit control," can be configured by the NF operator (e.g., T-Mobile, AT&T, etc.) so that the number of indications (e.g., of NF producers) returned by the NRF <NUM> (in association with a discovery response) meets or exceeds the number of service types available and provides redundancy, but is less than the total number of NF producers available for a NF producer type. As a result, the NF consumer <NUM> need not include a load balancer for sorting through discovery responses and instead, the NRF <NUM> optimizes and throttles the number of indications returned to NF consumer <NUM> responsive to the discovery request. Thus, NF consumer <NUM> is not flooded in response to a discovery request.

<FIG> illustrates another example process <NUM> for implementing NRF discovery control, as described herein.

Block <NUM> illustrates storing a list of Network Function (NF) producers, the list of NF producers being associated with a timer. As described above with reference to <FIG>, a NF consumer <NUM> can receive a list of indications of NF producers of a NF producer type from the NRF <NUM>, responsive to sending a discovery request to the NRF <NUM>. In some examples, the discovery response can be associated with a timer corresponding to a time period after which the list of indications of NF producers associated with the NF producer type expires. The NF consumer <NUM> can store the list of indications of NF producers.

Block <NUM> illustrates receiving a discovery request from a user equipment. As described above, a NF consumer <NUM> can receive a request (e.g., for services via the <NUM> mobile network) from a UE <NUM>.

Block <NUM> illustrates determining whether a period of time associated with the timer has lapsed. Upon receiving the request, the NF consumer <NUM> can determine whether the time period has lapsed (e.g., the list of indications of NF producers has expired). If the period of time has not lapsed, the NF consumer <NUM> can send a response to the user equipment based at least in part on the stored list of NF producers, as block <NUM> illustrates. If the period of time has lapsed, the NF consumer <NUM> can send a discovery request to a Network Repository Function (NFR) for an updated list of NF producers, as illustrated in block <NUM>. Responsive to sending the other discovery request, the NF consumer <NUM> can receive an updated list of NF producers (via the example process <NUM> described above with reference to <FIG>) and can store the (updated) list of NF producers(s), as illustrated in block <NUM>. In such an example, the updated list can be associated with a timer, indicating a period of time for which the updated list is valid (e.g., not expired).

Claim 1:
A method, implemented at a Network Repository Function, NRF (<NUM>), associated with a Fifth Generation, <NUM>, network, the method comprising:
receiving, from a Network Function, NF, consumer (<NUM>) associated with the <NUM> network, a discovery request (<NUM>) for information associated with a NF producer type;
receiving, from NF producers (<NUM>) associated with the NF producer type, indications of the NF producers;
storing in a data store (<NUM>, <NUM>) of the NRF, indications of NF producer types and corresponding configurable parameters, wherein a respective configurable parameter is configured for each NF producer type;
responsive to receiving the discovery request (<NUM>) for information associated with the NF producer type from the NF consumer (<NUM>), determining by the NRF, a respective configurable parameter associated with the NF producer type;
generating a list of NF producers based at least in part on the indications;
if a number of NF producers in the list of NF producers exceeds the respective configurable parameter associated with the NF producer type, selecting, based at least in part on the respective configurable parameter associated with the NF producer type, a subset of the list of NF producers; and
sending (<NUM>), responsive to receiving the discovery request, the subset of the list of NF producers to the NF consumer (<NUM>).