Technique for configuring a core network function for network function discovery

Abstract

A technique is provided for configuring a Network Function, NF, in a core network domain of a telecommunication network for NF discovery in the core network domain. The core network domain comprises NFs of at least a first NF type and a second NF type different from the first NF type, wherein the NFs are centrally registered in an NF registry capable of NF type-dependent NF discovery. A method aspect of the technique comprises the following steps performed by the NF registry: receiving, from an NF, an information request message directed at obtaining information about services supported by the NF registry, and sending, responsive to the information request message, to the NF an information response message indicative of whether or not the NF registry supports NF type-independent NF discovery.

Description

[0001] Technique for Configuring a Core Network Function

[0002] for Network Function Discovery

[0003] Technical Field

[0004] The present disclosure generally relates to aspects in a core network domain of a telecommunication network. In more detail, a technique for configuring a network function in the core network domain for discovery of other network functions in the core network domain is presented. The technique can be implemented in the form of methods, apparatuses, systems and a computer program product.

[0005] Background

[0006] The core network domain of modern telecommunication networks is based on what is called a Service-Based Architecture (SBA). For example, the 5th Generation (5G) telecommunication network as standardized by the 3rd Generation Partnership Project (3GPP) relies on SBA for its core network domain.

[0007] According to the SBA paradigm, the core network domain is decomposed into well-defined, standardized Network Functions (NFs) that communicate with each other using standardized interfaces and protocols. SBA organizes NFs into service consumers and service producers. The NFs are configured to automatically discover each other, and utilize the services offered to each other.

[0008] SBA enhances flexibility, scalability and efficiency of the core network domain.

[0009] However, in view of the increasing number and the dynamic nature of NFs and NF services, complexity of the network architecture increases also. The increasing complexity leads to the need for an automatic mechanism that allows NFs to discover and communicate with each other without the need for a static configuration. These challenges are the key reason behind the introduction of a so-called Network Repository Function (NRF) in the core network domain.

[0010] In previous generations of core network domains, if a new network element is added or the capability of an existing network element is expanded, the network operator had to reconfigure all the remaining networks elements with the information needed to address the newly added network element or the new capability. The NRF removes the need for such a cumbersome network re-configuration. The NRF can beconsidered to constitute a central registry, holding information about every NF, which can then be shared with any NF, when required. In practice, when adding a new NF to the core network domain, this new NF only needs to interact with the NRF in order to register its profile and discover all the existing NFs and NF services.

[0011] To maintain its database and to have an up-to-date view of the network topology, the NRF allows NFs to register and deregister themselves, their supported services and to update their status. Additionally, the NRF allows NFs to subscribe to status updates of other NFs. Any registration, deregistration or status change of an NF can thus be notified to other NFs, keeping local NF caches up-to-date and thus minimizing the number of NRF queries.

[0012] The NRF provides various services to other NFs. One such service is NF discovery. NF discovery is the process of automatically determining what instances of a service presently fulfil a given request. Upon receipt of a discovery request message from an NF service consumer, the NRF checks its database and selects a list of available service producers from the registered NFs based on selected query parameters specified by the consumer NF in the discovery request message.

[0013] The NF discovery request message as defined in 3GPP Technical Specification (TS) 29.510 v. 19.2.0 includes, as a mandatory parameter, the NF type of the target NF that is to be discovered. Assume that in an exemplary Session Management Function (SMF) selection process, an Access and Mobility Management Function (AMF) wishes to discover all the available SMFs as target NFs. As explained above, all the NFs (including the AMF and SMFs) have previously registered their profiles in the NRF. The consumer AMF thus initiates a discovery request message to the NRF, searching, as target NF, for an available SMF fitting its requirements. Responsive to the discovery request message, the NRF checks its local database for the target NF and selects one or more SMFs that fit the AMF requirements. The NRF then replies to the AMF with a discovery response message. This message includes a list of available producer NFs (i.e., SMFs), which allows the AMF to send a PDU session request to a particular one of the listed SMFs for session establishment.

[0014] The NF discovery procedure discussed above works well for NFs that know their target NF and, thus, can indicate the target NF in the NF discovery request message. There are situations, however, in which this procedure does not work so well.

[0015] Assume that a producer NF wishes to notify all of its consumer NFs about a certain event. A challenge resides in that the Network Exposure Function (NEF), as anexemplary NF, may be deployed in certain core network setups but may not be deployed in other core network setups (e.g., dependent on operator preferences). This means, in turn, that an NF that is to send a discovery request message needs to know the actual core network setup in particular regard to NEF so as to determine whether NEF, as a target NF, has to be, or can be, discovered or not. Similar situations arise in case a new NF consumer is defined in the future by 3GPP, such as the Internet Protocol (IP) Multimedia Sub-System (IMS) Application Server (AS) NF.

[0016] As a consequence, the NFs may need to be pre-configured to know their service consumers in a particular core network setup, or the NFs require a software update each time a new or existing NF type becomes their new NF consumer in future. Apparently, such approaches are against the "zero-touch" paradigm and against other NRF principles as well, because any NF shall be able to discover via NRF the relevant topology of the core network domain without any pre-configuration.

[0017] Summary

[0018] Therefore, there is a need for a technique for efficiently and flexibly configuring a core network function for discovery of other network functions in the core network domain.

[0019] According to a first aspect, a method of configuring a Network Function, NF, in a core network domain of a telecommunication network for NF discovery in the core network domain is provided, wherein the core network domain comprises NFs of at least a first NF type and a second NF type different from the first NF type, and wherein the NFs are centrally registered in an NF registry capable of NF typedependent NF discovery. The method comprises the following steps performed by the NF registry: receiving, from an NF, an information request message directed at obtaining information about services supported by the NF registry, and sending, responsive to the information request message, to the NF an information response message indicative of whether or not the NF registry supports NF type-independent NF discovery.

[0020] According to a second aspect, a method of configuring a Network Function, NF, in a core network domain of a telecommunication network for NF discovery in the core network domain is provided, wherein the core network domain comprises NFs of at least a first NF type and a second NF type different from the first NF type, and wherein the NFs are centrally registered in an NF registry capable of NF type-dependent NF discovery. The method comprises the following steps performed by the NF: sending, to the NF registry, an information request message directed at obtaining information about services supported by the NF registry; and receiving, responsive to the information request message and from the NF registry, an information response message indicative of whether or not the NF registry supports NF type-independent NF discovery.

[0021] The following optional implementations apply both to the first aspect and the second aspect, as well as to other aspects of the present disclosure.

[0022] In one implementation, the NF registry supports one or more discovery query parameters. The one or more discovery query parameters may be usable as filter criteria by the NFs for NF discovery. In such an implementation, the information response message may be indicative of at least one discovery query parameter for which the NF registry supports NF type-independent NF discovery. At least one of the one or more discovery query parameters may be configured to assume two or more different parameter values, and the information response message (that is indicative of the at least one discovery parameter) may further indicate at least one parameter value for which the NF registry supports NF type-independent NF discovery. As an example, one of the at least one discovery query parameter may relate to a notification message, and it may be configured to assume two or more parameter values indicative of different notification messages for which the NF registry supports NF type-independent NF discovery.

[0023] In certain implementations, the information response message may indicate at least one service exposed by the NF registry and one or more features supported by the at least one exposed service. The at least one service exposed by the NF registry may be supported by the NF registry. The at least one exposed service may be indicated in the information response message as a Universal Resource Indicator (URI) of the at least one service. This URI may be used by an NF for calling the at least one service. Different exposed services may be associated with different URIs.

[0024] The at least one exposed service may include an NF discovery service. NF typeindependent NF discovery may be one of several possible features supported by the NF discovery service. In one variant, the information response message indicates that the NF registry supports NF type-independent NF discovery when that feature is referenced in the information request message. In another variant, the information response message indicates that the NF registry does not support NF type-independent NF discovery when that feature is not referenced in the information request message. The features may be referenced in the information response message by numbers or any other designators.

[0025] In certain implementations, the method performed by the NF registry includes receiving, from one of the NFs, an NF discovery request message directed at an NF discovery and sending, in response to the NF discovery request message, an NF discovery response message to the NF. In certain implementations, the method performed by the NF includes sending, to the NF registry, an NF discovery request message directed at an NF discovery and receiving, in response to the NF discovery request message, an NF discovery response message from the NF registry. The NF sending the discovery request message may be a service consumer NF or a service producer NF.

[0026] In such implementations, the NF discovery request message may not specify an NF type for the NF discovery (e.g., it may not specify a target NF type for NF discovery). In the first aspect, the NF from which the discovery request message is received by the NF registry may be the NF to which the information response message has been sent before by the NF registry, and wherein the information response message may have been indicative of the NF registry supporting NF type-independent NF discovery.

[0027] The NF discovery request message may specify one of the at least one discovery query parameter for which the NF registry supports NF type-independent NF discovery. Moreover, the NF discovery request message may specify one of at least one parameter value for which the NF registry supports NF type-independent NF discovery.

[0028] The NF discovery response message may indicate NFs of the first NF type and of the second NF type. A content of the NF discovery response message may not be limited to a particular NF type. The content may only be limited by one or more discovery query parameters and, optionally, one or more related parameter values as signalled to the NF registry in the discovery request message.

[0029] The NF registry may be a Network Repository Function, NRF, in accordance with 3GPP Technical Specification 29.510, in particular version 19.2.0 or later. The or each NF may be compliant with 3GPP Technical Specification 29.510, in particular version 19.2.0 or later.The information request message may be a bootstrapping information request message in accordance with 3GPP Technical Specification 29.510, in particular version 19.2.0 or later. The discovery request message and the discovery response message may be compliant with 3GPP Technical Specification 29.510, in particular version 19.2.0 or later.

[0030] According to a third aspect, a method of controlling a Network Function, NF, in a core network domain of a telecommunication network for NF discovery in the core network domain is provided, wherein the core network domain comprises NFs centrally registered in an NF registry. The method comprises the following step performed by the NF registry: sending a message to the NF, the message indicating that the NF registry supports NF type-independent NF discovery. The message may be a solicited response message or an unsolicited message.

[0031] According to a fourth aspect, a method of controlling a Network Function, NF, in a core network domain of a telecommunication network for NF discovery in the core network domain is provided, wherein the core network domain comprises NFs centrally registered in an NF registry. The method comprises the following step performed by the NF: receiving a message from the NF registry, the message indicating that the NF registry supports NF type-independent NF discovery.

[0032] The methods of the third and fourth aspect may comprise the steps and other features described herein for the methods of the first and second aspects.

[0033] A further aspect is directed at a computer program product comprising program code portions to perform the method of any of the method aspects presented herein when the computer program product is executed on one or more processors. The computer program product may be stored on a processor-readable recording medium.

[0034] Also provided is a network function registry configured to perform the steps of the first or third method aspect presented herein. Further provided is a network function configured to perform the steps of the second or fourth method aspect presented herein.Moreover, a system comprising both the network function registry and the network function is provided. The system may be configured in accordance with 3GPP Technical Specification 29.510, in particular version 19.2.0 or later.

[0035] Brief Description of the Drawings

[0036] Further aspects, details and advantages of the present disclosure will become apparent from the following detailed description and the drawings, wherein

[0037] Fig. 1 illustrates an exemplary system in accordance with the present disclosure; Fig. 2 illustrates an exemplary communication device in accordance with the present disclosure;

[0038] Fig. 3 illustrates an exemplary network node of a radio access network in accordance with the present disclosure;

[0039] Fig. 4 illustrates an exemplary network node of a core network domain in accordance with the present disclosure;

[0040] Fig. 5 illustrates a flow diagram of method aspects of the present disclosure;

[0041] Fig. 6 illustrates an exemplary signalling diagram in which aspects of the present disclosure can be implemented;

[0042] Fig. 7 illustrates a first signalling diagram in accordance with the present disclosure;

[0043] and

[0044] Fig. 8 illustrates a second signalling diagram in accordance with the present disclosure.

[0045] Detailed Description

[0046] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which the same reference numerals denote the same or similar components. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0047] Fig. 1 shows an example of a communication system 100 in which the present disclosure can be implemented. In the example, the communication system 100 comprises a telecommunication network 102 that includes an access network (AN) domain 104, such as a radio access network (RAN) domain, and a core network (CN) domain 106, which includes one or more core network nodes 108 (CN-NN).The access network domain 104 includes one or more radio access network nodes (RAN-NN), such as network nodes 110a and 110b (one or more of which may be generally referred to as network nodes 110), or any other or similar 3GPP access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node 110 in the access network domain 104 is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes 110 include disaggregated implementations or portions thereof.

[0048] The network nodes 110 of the access network 104 facilitate direct or indirect connection of communication devices, in particular user equipment (UE), such as by connecting UEs 112a, 112b, 112c (one or more of which may be generally referred to as UEs 112) to the core network domain 106 over one or more wireless connections. Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves or radio waves suitable for conveying information without the use of wires, cables, or other material conductors.

[0049] The UEs 112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 110 and other communication devices. Similarly, the network nodes 110 of the radio network domain 104 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 112 and / or with other network nodes or equipment in the telecommunication network 102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 102.

[0050] In the depicted example, the core network domain 106 includes one more core network nodes 108 that are structured with hardware and software components. Features of these network nodes 108 may be substantially similar to those described with respect to the UEs and / or network nodes 110, such that the descriptions thereof are generally applicable to the corresponding components of the core network nodes 108. Example core network nodes 110 include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier Deconcealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User PlaneFunction (UPF).

[0051] As a whole, the communication system 100 of Fig. 1 enables connectivity between the UEs 112 and one or more of the network nodes 108, 110. In that sense, the communication system 100 may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox. In preferred implementations, the communication system 100 is configured to comply with the 3GPP 5G or 6G standard. In some examples, the telecommunication network 102 is a cellular network that implements 3GPP standardized features (e.g., according to the 3GPP 5G or 6G standard).

[0052] Fig. 2 shows an exemplary communication device, referred to as UE 112, in accordance with the present disclosure. The UE 112 of Fig. 2 presents additional details of the UE 112 of Fig. 1.

[0053] As used herein, a UE 112 refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes 108. 110 and / or other UEs 112. Examples of a UE 112 include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage / playback device, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), la ptop- mounted equipment (LME), an Augmented Reality (AR) or Virtual Reality (VR) device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE 112 identified by 3GPP, including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0054] The UE 112 includes processing circuitry 202 that is operatively coupled to a memory 210, a communication interface 212, and / or any other component, or anycombination thereof. Certain UEs 112 may utilize all or a subset of the components shown in Fig. 2. The level of integration between the components may vary from one UE 112 to another UE 112. Further, certain UEs 112 may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0055] The processing circuitry 202 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 210. The processing circuitry 202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 202 may include multiple central processing units (CPUs).

[0056] The memory 210 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 210 includes one or more application programs, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data. The memory 210 may store, for use by the UE 112, any of a variety of various operating systems or combinations of operating systems. The memory 210 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external minidual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as 'SIM card.' The memory 210 may allow the UE 112 to access instructions, applicationprograms and the like, stored on transitory or non-transitory memory media, to offload data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 210, which may be or comprise a device-readable storage medium.

[0057] The processing circuitry 202 may be configured to communicate with the access network domain 104 or other device nor network using the communication interface 212. The communication interface 212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 222. The communication interface 212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 218 and / or a receiver 220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 218 and receiver 220 may be coupled to one or more antennas (e.g., antenna 222) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0058] Fig. 3 shows a network node 110 of the radio network domain 104. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a communication device such as a UE, and / or with other network nodes or equipment, in the telecommunication network 102. Examples of network nodes 110 include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU). The network node 200 is preferably associated with the access network 104 and, thus, is also referred to as RAN-NN 200 herein.

[0059] The network node 110 includes a processing circuitry 302, a memory 304, a communication interface 306, and a power source 308. The network node 110 may be composed of multiple physically separate components. In some embodiments, the processing circuitry 302 includes a system on a chip (SOC).

[0060] In some embodiments, the processing circuitry 302 includes one or more of radio frequency (RF) transceiver circuitry 312 and baseband processing circuitry 314. In some embodiments, the radio frequency (RF) transceiver circuitry 312 and the baseband processing circuitry 314 may be on separate chips (or sets of chips),boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 312 and baseband processing circuitry 314 may be on the same chip or set of chips, boards, or units. The memory 304 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 302. The memory 304 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 302 and utilized by the network node 110. The memory 304 may be used to store any calculations made by the processing circuitry 302 and / or any data received via the communication interface 306. In some embodiments, the processing circuitry 302 and memory 304 is integrated.

[0061] The communication interface 306 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface 306 comprises port(s) / terminal(s) 316 to send and receive data, for example to and from a network over a wired connection. The communication interface 306 also includes radio front-end circuitry 318 that may be coupled to, or in certain embodiments a part of, the antenna 310. Radio front-end circuitry 318 comprises filters 320 and amplifiers 322. The radio front-end circuitry 318 may be connected to an antenna 310 and processing circuitry 302. The radio front-end circuitry may be configured to condition signals communicated between antenna 310 and processing circuitry 302. The radio front-end circuitry 318 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 318 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 320 and / or amplifiers 322. The radio signal may then be transmitted via the antenna 310. Similarly, when receiving data, the antenna 310 may collect radio signals which are then converted into digital data by the radio front-end circuitry 318. The digital data may be passed to the processing circuitry 302. In other embodiments, the communication interface may comprise different components and / or different combinations of components.The antenna 310 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 310 may be coupled to the radio front-end circuitry 318 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 310 is separate from the network node 110 and connectable to the network node 110 through an interface or port.

[0062] Fig. 4 illustrates another network node 108 in accordance with the present disclosure. This network node 108 is associated with the core network domain 106. The network node 108 comprises at least one processor that is part of the processing circuitry 402, and at least one memory 404. The memory 404 stores instructions which, when executed by the at least one processor, cause the at least one processor to perform one or more steps described herein for NFs such as the NRF. The network node 108 may host one or more different NFs, or portions thereof, with other NFs or NF portions being hosted by other network nodes 108 of the core network domain 106. Each network node 108 may communicate with one or more RAN-NNs 110 and / or other networks (such as the Internet) via its communication interface 406. Memory 404 and / or processing circuitry 402 may be virtualized components and / or distributed over multiple locations, and they may generally configured as described above with reference to memory 210 or 304 and processing circuitry 202 or 302.

[0063] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.With reference to Fig. 1, the core network 106 of the telecommunication network 102 can be implemented using a Service-Based Architecture (SBA). In such an implementation, the core network domain 106 is decomposed into Network Functions (NFs) that communicate with each other using standardized interfaces and protocols. The NFs can be realized as software applications distributed over one or more of the core network nodes 108. Where appropriate, the term "NF" covers one or more NF instances of a particular NF type.

[0064] SBA organizes NFs into service consumers and service producers. The NFs are configured to automatically discover each other, and utilize the services offered to each other. To facilitate NF discovery, a special NF called NF registry (or Network Repository Function, NRF, according to 3GPP standards) is configured to store information about every NF, which can then be shared with any NF, when required. So when adding a new NF to the core network domain 106, this new NF only needs to interact with the NRF in order to register its profile and discover all the existing NFs and NF services.

[0065] To maintain its database and to have an up-to-date view of the network topology, the NRF allows NFs to register and deregister themselves, their supported services and to update their status. Additionally, the NRF allows NFs to subscribe to status updates of other NFs. Any registration, deregistration or status change of an NF can thus be notified to other NFs. Such notification allow the NFs to keep local caches up-to-date and thus minimize the number of NRF queries.

[0066] The NRF provides various services to other NFs. One such service is NF discovery. NF discovery is the process of automatically determining what instances of a service presently fulfil a given discovery request. Upon receipt of a discovery request message from an NF service consumer, the NRF checks its database and selects a list of available service producers from the registered NFs based on selected parameters specified by the consumer NF in its discovery request message.

[0067] The NF discovery request message defined in 3GPP TS 29.510 v. 19.2.0 includes, as a mandatory parameter, the NF type of the target NF that is to be discovered (see also 3GPP TS 29.502 v. 19.2.0). This means that the target NF type needs to be known in advance, although certain procedures that rely on NF discovery do not depend on any NF type. It has thus been found that the requirement of indicating the target NF in the discovery request message can lead to an undesirable overhead in regard to communication and / or configuration. On the other hand, simply omittingthe target NF indication by the requesting NF can likewise lead to communication issues (e.g., with legacy NRFs expecting such information in the discovery request message or in the context of specific discovery queries).

[0068] It is thus proposed that an NF registry, such as an NRF, in the core network domain 106 of the telecommunication network 102 specifically configures (e.g., controls) the NFs in the core network domain 106 for discovery of other NFs in a way that the NFs, after their configuration, are aware of whether or not the NF registry supports NF type-independent NF discovery. Such NF type-independent NF discovery may be supported by the NF registry in addition to NF type-dependent NF discovery. In other words, the NF registry may in some implementations also be capable of NF typedependent NF discovery.

[0069] Fig. 5 illustrates in a flow diagram 500 an exemplary method implementation of an NF configuration procedure jointly performed by an NF 502 and an NF registry 504 in the core network domain 106. The NF 502 and the NF registry 504 may be hosted by one or more of the core network nodes 108 of Fig. 1. It will be assumed that the NFs in the core network domain 106 are at least of a first NF type and a second NF type different from the first NF type. In an exemplary 3GPP implementation of a 5G telecommunication network 102, the NFs in the core network domain 106 may at least comprise AMFs (first NF type) and SMFs (second NF type). The NFs in the core network domain 106, including NF 502, are centrally registered in the NF registry 504.

[0070] With reference to step 510 of Fig. 5, the NF configuration procedure is triggered by the NF 502 sending to the NF registry 504 an information request message. The information request message is directed at obtaining information about services supported (e.g., exposed) by the NF registry 504. Such services may, for example, include a discovery service and, optionally, one or more further services, such as an authentication service. In some implementations, the information request message may not specifically be directed at (e.g., only) inferring the NF registry's capability to support NF type-independent NF discovery. Rather, the information request message may generally be directed at inferring the NF registry's capability to support one or more of a plurality of different services (possibly including various features of each service). In other implementations, the information request message may specifically be directed at (e.g., only) inferring the NF registry's capability to support NF typeindependent NF discovery.In step 520, the NF registry 504 receives the information request message from the NF 502. The NF registry 504 then generates an information response message. The information response message generated by the NF registry 504 is indicative of whether or not the NF registry 504 supports NF type-independent NF discovery. To this end, the information response message may include an attribute, a flag or any other information element suitable of expressing the NF repository's capability to support NF type-independent NF discovery.

[0071] In some variants, the information response message indicates at least one service exposed by the NF registry 504 and, optionally, one or more features supported by the at least one exposed service. The at least one service exposed by the NF registry 504 may be indicated in the information response message as URI of the at least one service.

[0072] In the context of Fig. 5, the at least one exposed service indicated in the information response message generated by the NF registry 504 may include an NF discovery service. The information response message may further be indicative of whether or not NF type-independent NF discovery is supported as a feature of the NF discovery service. As an example, the information response message may indicate that the NF registry 504 supports NF type-independent NF discovery when that feature is referenced (e.g., included as a dedicated number or other dedicated item of information) in the information request message. On the other hand, the information response message may indicate that the NF registry does not support NF typeindependent NF discovery when that feature is not referenced in the information request message.

[0073] In step 530, the information response message generated by the NR registry 504 is sent to the NF 502 to inform the NF 502 about whether or not the NF registry 504 supports NF type-independent NF discovery. The information response message is received by the NF 502 in step 540, and the NF 502 is thus configured for upcoming NF discovery procedures, as illustrated in Fig. 5 by optional steps 550 to 580.

[0074] It will in the following be assumed that the information response message received by the NF 502 in step 540 is indicative of the fact that the NF registry 504 does support NF type-independent NF discovery. In some variants, the NF 502 may additionally (e.g., by default) support NF type-dependent NF discovery. In case the NF registry 504 supports NF type-dependent NF discovery by default, this capability of the NF registry 504 will not explicitly need to be communicated to the NF 502(e.g., in the information response message or otherwise). Rather, the NF 502 may in such variants be statically configured to always send discovery request messages including an NF type unless a particular NF registry 504, as in the present case, has explicitly signalled its support of NF type-dependent NF discovery.

[0075] At a certain point in time after receipt of the information response message in step 540, the NF 502 will need to send a discovery request message to the NF registry 504 (see step 550 in Fig. 5). Since the NF registry 504 has previously signalled its support of NF type-dependent NF discovery, the discovery request message sent in step 550 will not be indicative of (i.e., specify) any target NF type, but one or more other discovery query parameters (and, optionally, associated parameter values). As an example, the discovery request message may be indicative of a geographic area of interest.

[0076] The NF registry 504 receives the discovery request message in step 560 and generates a discovery response message based on the one or more discovery query parameters specified in the discovery request message. If, in the above example, the discovery request message is indicative of a geographic area of interest, the NF registry 504 will determine all NFs registered at the NF registry 504 for this geographic area, and regardless of their specific NF type. The discovery response message thus generated with thus be indicative of NFs of multiple types, such as both AMFs and SMFs in an exemplary 3GPP-compliant 5G telecommunication network 102.

[0077] In step 570 of Fig. 5, the discovery response message thus generated is sent to the NF 502. The NF 502 receives the discovery response message in step 580 and processes the information contained therein as required.

[0078] In an exemplary 3GPP scenario compliant with in 3GPP TS 29.510 v. 19.2.0, the information request message and the information response message exchanged in steps 510 to 540 of Fig. 5 may belong to a bootstrapping procedure. Support of NF type-independent NF discovery by the NF registry 504 (i.e., the NRF) may be indicated as a dedicated feature of NF discovery service provided by the NR registry 504. The information response message may thus signal whether (or not) the NF registry 504 supports NF type-independent NF discovery by including (or not including) an associated new feature number. Table 6.2.9-1 of 3GPP TS 29.510 v. 19.2.0 could thus be extended by an exemplary new feature number 57 as shown inthe following table, wherein the text in italics The feature supports the query parameters indicated in anyNfTypeConditions may be optional:

[0079] Table 6.2.9-1: Features of supported Features attribute used by Nnrf_NFDiscovery service

[0080]

[0081]

[0082] In some variants, it may be desirable to limit NF discoveries without indication of a target NF type to certain query parameters supported by the NF registry 504 (and, optionally, certain query parameter values), as indicated by the text in italics for feature number 57 in the above table. In such variants, the information response message may be indicative, as a filter criteria, of one or more discovery query parameters for which the NF registry 504 supports NF type-independent NF discovery. In case one of the discovery query parameters can assume two or more different parameter values, the information response message may further indicate at least one parameter value for which the NF registry 504 supports NF typeindependent NF discovery.If it is intended to limit NF discoveries without indication of a target NF type to certain query parameters supported by the NF registry 504, table 6.4.6.2.2-1 of 3GPP TS 29.510 v. 19.2.0 could thus be extended by a new attribute (e.g., information element, or IE) "anyNfTypeConditions".

[0083]

[0084]

[0085] In the above example, the discovery parameters and their values may be taken from 3GPP TS 29.500 and / or table 6.2.3.2.3.1-1 of 3GPP TS 29.510 v. 19.2.0.

[0086] In the following, some concrete examples with be described with reference to a 3GPP-compliant 5G telecommunication network 102 that implements the configuration procedure as outlined above.

[0087] In a first example, it is assumed that a UDR has lost its data or experienced another data inconsistency (e.g., due to a re-start or a re-instantiation). As a consequence, the UDR as producer NF has to notify all of its service consumers (e.g., AMF, SMF, NEF, etc.) of this event so that the data can be restored in the UDR by its different consumers either directly (e.g., by NEF) or indirectly (via UDM, e.g., by AMF). The UDR thus needs to discover the network addresses (such as the callback URIs) of all its service consumers that need to be notified of the data inconsistency, which in turn requires that the UDR sends corresponding a discovery request message for the corresponding target NFs to the NRF.

[0088] Reference is now made to the signalling diagram 600 of Fig. 6, which corresponds to a portion of Figure 6.7.2-1 of 3GPP TS 23.527 v. 19.2.0.In step 0, UDR consumers 602 and UDM consumers 604 define callbackUri for data restoration in their NF profiles registered in NRF 504.

[0089] In step 1, UDR consumers 604 store temporary data in UDR (as an exemplary NF 502). The UDR consumers 604 may set their identity in the request to UDR 502, when accessing it for the first time. The UDR 502 stores the received identity and creates for each UDR consumer 604 a subscription on notification for a potential UDR data inconsistency. The UDR 502 may provide to the UDR consumer 604 the Reset-ID if assigned by the UDR 502 for the temporary data stored in UDR 502.

[0090] The UDM (not shown in Fig. 6) stores temporary data as requested by its consumers 602. UDM consumers 602 may set dataRestorationCallbackUri in the request of their registration to UDM. In this case, the UDM stores the dataRestorationCallbackUri locally and creates for each UDM consumer 602 a subscription on notification for the potential UDR data inconsistency. If received from UDR 502, the UDM also provides the Reset-ID assigned by the UDR 502 to the UDM consumers 602. When an NF other than UDM creates or updates a resource directly or via UDM in UDR 502, the NF sets or stores lastSynchronizationTime in a relevant profile. If the NF receives a Reset-ID directly or via UDM from UDR 502, the NF stores it in the profile.

[0091] In step 2, the UDR 502 detects corruption, loss, or any other inconsistency in temporary data caused due to certain scenarios (e.g., failure and restart of the UDR 502, or migration of the data from an old UDR to a new UDR).

[0092] As a consequence, the UDR 502 queries NRF 504 in the first substep of step sequence 3 based on the identity stored in step 1 and discovers in the second substep the callback URI for data restoration in UDR consumers' NF profiles. If no UDR consumer 604 impacted by the restoration event provided its identity in step 1, the UDR 502 discovers via NRF 504 the callback URI of one suitable UDR consumer instance to send the notification to. The UDR 502 sends an Nudr_DR_Notification request to the callback URI to notify the UDR consumers 604 of the potential UDR data inconsistency (third substep in the step sequence 3 of Fig. 6). The Nudr_DR_Notification request may contain temporary data identifier(s) (e.g. Reset-IDs) and an impacted period (i.e. lastReplicationTime and recoveryTime).

[0093] If the UDR consumer 604 is the UDM, the UDM forwards the notification to the UDM consumers 602 (see step sequence 4 of Fig. 6, last substep). The UDM discovers thecallback URI for data restoration for UDM consumers 602 within its Public Land Mobile Network (PLMN) in UDM the consumers' NF profiles through querying NRF 504 (see first and second substeps of Fig. 6). Optionally, the UDM may find the callback URI for data restoration for UDM consumers 602 (especially UDM consumers 602 outside its PLMN) if provided by the UDM consumer 602 during UDM consumer registration in UDM and locally stored in UDM in stepl.

[0094] In the above example, a challenge resides in that NEF, as an exemplary NF, may be deployed in certain core network setups but may not be deployed in other core network setups (e.g., dependent on operator preferences). This means, in turn, that the UDR 502 that is to send the discovery request message needs to know the actual core network setup in particular regard to NEF so as to determine whether NEF, as a target NF, has to be discovered or not. It is to be remembered that the NF discovery request message defined in 3GPP TS 29.510 v. 19.2.0 includes, as a mandatory parameter, the NF type of the target NF that is to be discovered. A similar situation arises in case a new UDR consumer 604 is defined in the future by 3GPP, such as the IP IMS AS NF. To address such situations, the UDR 502 would require a preconfiguration to know the target NF types it may encounter in a particular setup of a particular core network domain 106, which is against the "zero-touch" paradigm and against other NRF principles as well, because any NF 502 shall be able to discover via NRF 504 the relevant topology of the core network domain 106 without any preconfiguration.

[0095] With the principles discussed above, NFs 502 are enabled to discover via NRF 504 the relevant topology of the core network domain 106 in an efficient manner (e.g., without any a priori knowledge or pre-configuration). The efficiency gain is illustrated in the signalling diagram 700 of Fig. 7 for the scenario discussed above with reference to Fig. 6.

[0096] In step 1 of Fig. 7 (corresponding to steps 510 and 520 of Fig. 5), the NF 502 sends a bootstrapping request message to the NRF 504. The NF 502 can be the UDM or the UDR of Fig. 6 (in Fig. 6, the UDM is one of the UD consumers 604).

[0097] In step 2 of Fig. 7 (corresponding to steps 530 and 540 of Fig. 5), the NRF 504 responds with a bootstrapping response message to NF 502 (see Figure 5.5.2.2.1-1 of 3GPP TS 29.510 v. 19.2.0). The bootstrapping response message includes a Bootstrappinginfo data structure as shown in table 6.4.6.2.2-1 of 3GPP TS 29.510 v.

[0098] 19.2.0. For the NF discovery service exposed by the NRF 504 in theBootstrappinginfo data structure, the new feature Any-NF-Type is indicated in the bootstrapping response message illustrated in Fig. 7 (in accordance with the extended table 6.2.9-1 of 3GPP TS 29.510 v. 19.2.0 as shown above, see new feature number 57). The NF 502 is thus informed that the NRF 504 supports NF type-independent NF discovery. Moreover, the Bootstrappinginfo data structure additionally includes the anyNfTypeConditions attribute explained above with reference to the extended table 6.4.6.2.2-1 of 3GPP TS 29.510 v. 19.2.0.

[0099] The NF 502 is thus informed that the NRF 504 supports NF type-independent NF discovery for the discovery query parameter (i.e., discovery factor) "notification-type" with the parameter value "DATA_RESTORATION_NOTIFICATION"), i.e., for the particular discovery messaging illustrated by steps 3 and 4 of Fig. 6 for . In other words, the UDR 502 is configured for situations in which its intended discovery factor is notification type=DATA_RESTORATION_NOTIFICATION to not mandatorily include the target NF type in the discovery request message.

[0100] As such, in step 3 of Fig. 7, the NF 502 sends an NF discovery request message to the NRF 504 referring to the notification type=DATA_RESTORATION_NOTIFICATION but not including (i.e., omitting) the target NF type. Step 3 of Fig. 7 corresponds to steps 550 and 560 of Fig. 5, the first substep of step sequence 3 in Fig. 6 (for the UDR) and the second substep of step sequence 4 in Fig. 6 (for the UDM acting as UDR consumer 604).

[0101] Then, in step 4 of Fig. 7, the NRF 504 returns an NF discovery response message to the NF 502 which includes the callback URIs of all NF instances across all NF types that have registered their callback URI for data restoration purposes. Step 4 of Fig. 7 corresponds to steps 570 and 580 of Fig. 5, the second substep of step sequence 3 of Fig. 6 (for the UDR) and the third substep of step sequence 4 in Fig. 6 (for the UDM acting as UDR consumer 604).

[0102] Based on the information obtained in step 4 of Fig. 7, the NF 502 (e.g., the UDR or UDM) can send a data restoration notification to the callback URIs of all of its consumer NFs regardless of their NF type. The approach illustrated in Fig. 7 is efficient in various regards. For example, the NF 502 can perform network topology discovery without having to be aware of the deployed NF types. Moreover, even assuming that the NF 502 knows the NF types of all of its consumer NFs, the NF 502 does not have to send separate discovery request messages per NF type, but only a single such message to cover any NF type.Evidently, the principles underlying the present disclosure, which enable NFs 502 to discover via NRF 504 the relevant topology of the core network domain 106 without any cumbersome pre-configuration, is not limited to the exemplary scenario discussed above with reference to Figs. 6 and 7. Signalling diagram 800 of Fig. 8 illustrates an alternative scenario similar to the scenario of signalling diagram 700 but for another use case. In the use case of Fig. 8, the NRF 504 enables a Network Data Analytics Function (NWDAF), as another exemplary NF 502, to discover all NF instances deployed in a certain geographical area regardless of their NF type.

[0103] Deviating from the signalling scenario of Fig. 7, the bootstrapping response message sent by the NFR 504 in step 2 of Fig. 8 indicates "preferred-locality" as the discovery query parameter for which NF type-independent NF discovery is enabled. Thus, in the discovery request message sent in step 3 of Fig. 8, the target NF type can be omitted, and the NF 502 learns in step 4 of Fig. 8 from the NRF 504 all NF instances deployed in a certain geographical region regardless of their NF type.

[0104] As has become apparent from the above description of exemplary embodiments, communication and configuration overhead is reduced when an NF registry is configured to advertise its capability to handle NF type-independent NF discovery procedures. NFs can thus be configured to not mandatorily include a target NF type in their NF discovery request message. The handling of NF type-independent NF discovery procedures can be limited by the NF registry to one or more query parameters and, thus, to certain NF-sided processes that particularly benefit from NF type-independent NF discovery procedures (e.g., processes that do not depend on any NF type like the two examples illustrated in Figs. 7 and 8). Additionally, NF discovery for different NF types can be bundled in a single discovery request / response messaging step sequence.

Claims

Claims1. A method of configuring a Network Function, NF (502), in a core network domain (106) of a telecommunication network (102) for NF discovery in the core network domain (106), wherein the core network domain (106) comprises NFs of at least a first NF type and a second NF type different from the first NF type, and wherein the NFs are centrally registered in an NF registry (504) capable of NF typedependent NF discovery, the method comprising the following steps performed by the NF registry (504):receiving (520), from an NF (502), an information request message directed at obtaining information about services supported by the NF registry (504);sending (530), responsive to the information request message, to the NF (502) an information response message indicative of whether or not the NF registry (504) supports NF type-independent NF discovery.

2. The method of claim 1, whereinthe NF registry (504) supports one or more discovery query parameters, and wherein the information response message is indicative of at least one discovery query parameter for which the NF registry (504) supports NF type-independent NF discovery.

3. The method of claim 2, whereinat least one of the one or more discovery query parameters is configured to assume two or more different parameter values, and wherein the information response message indicative of the at least one discovery parameter further indicates at least one parameter value for which the NF registry (504) supports NF typeindependent NF discovery.

4. The method of claim 3, whereinone of the at least one discovery query parameter relates to a notification message and is configured to assume two or more parameter values indicative of different notification messages for which the NF registry (504) supports NF typeindependent NF discovery.

5. The method of any of the preceding claims, whereinthe information response message indicates at least one service exposed by the NF registry (504) and one or more features supported by the at least one exposed service, wherein the at least one exposed service includes an NF discoveryservice and wherein NF type-independent NF discovery is one of several possible features supported by the NF discovery service.

6. The method of claim 5, whereinthe information response message indicates that the NF registry (504) supports NF type-independent NF discovery when that feature is referenced in the information request message.

7. The method of claim 5, whereinthe information response message indicates that the NF registry (504) does not support NF type-independent NF discovery when that feature is not referenced in the information request message.

8. The method of any of claims 5 to 7, whereinthe at least one service exposed by the NF registry (504) is indicated in the information response message as a Universal Resource Indicator, URI, of the at least one service.

9. The method of any of the preceding claims, further comprising receiving (550), from one of the NFs (502), an NF discovery request message directed at an NF discovery; andsending (560), in response to the NF discovery request message, an NF discovery response message to the NF (502).

10. The method of claim 9, whereinthe NF discovery request message does not specify an NF type for the NF discovery.

11. The method of claim 10, whereinthe NF (502) from which the discovery request message is received is the NF (502) to which the information response message has been sent before by the NF registry (504), and wherein the information response message was indicative of the NF registry (504) supporting NF type-independent NF discovery.

12. The method of claim 10 or 11 in combination with at least claim 2, whereinthe NF discovery request message specifies one of the at least one discovery query parameter for which the NF registry (504) supports NF type-independent NF discovery.

13. The method of claim 12 in combination with at least claim 3, wherein the NF discovery request message specifies one of at least one parameter value for which the NF registry (504) supports NF type-independent NF discovery.

14. The method of any of claims 9 to 13, whereinthe NF discovery response message indicates NFs of the first NF type and of the second NF type.

15. The method of any of the preceding claims, whereinthe NF registry (504) is a Network Repository Function, NRF, in accordance with 3GPP Technical Specification 29.510, in particular version 19.2.0 or later.

16. The method of any of the preceding claims, whereinthe information request message is a bootstrapping information request message in accordance with 3GPP Technical Specification 29.510, in particular version 19.2.0 or later.

17. A method of configuring a Network Function, NF (502), in a core network domain (106) of a telecommunication network (102) for NF discovery in the core network domain (106), wherein the core network domain (106) comprises NFs of at least a first NF type and a second NF type different from the first NF type, and wherein the NFs are centrally registered in an NF registry (504) capable of NF typedependent NF discovery, the method comprising the following steps performed by the NF (502):sending (520), to the NF registry (504), an information request message directed at obtaining information about services supported by the NF registry (504);receiving (530), responsive to the information request message and from the NF registry (504), an information response message indicative of whether or not the NF registry (504) supports NF type-independent NF discovery.

18. The method of claim 17, whereinthe NF registry (504) supports one or more discovery query parameters, and wherein the information response message is indicative of at least one discovery query parameter for which the NF registry (504) supports NF type-independent NF discovery.

19. The method of claim 18, whereinat least one of the one or more discovery query parameters is configured to assume two or more different parameter values, and wherein the information response message indicative of the at least one discovery parameter further indicates at least one parameter value for which the NF registry (504) supports NF typeindependent NF discovery.

20. The method of claim 19, whereinone of the at least one discovery query parameter relates to a notification message and is configured to assume two or more parameter values indicative of different notification messages for which the NF registry (504) supports NF typeindependent NF discovery.

21. The method of any of the claims 17 to 20, whereinthe information response message indicates at least one service exposed by the NF registry (504) and one or more features supported by the at least one exposed service, wherein the at least one exposed service includes an NF discovery service and wherein NF type-independent NF discovery is one of several possible features supported by the NF discovery service.

22. The method of claim 21, whereinthe information response message indicates that the NF registry (504) supports NF type-independent NF discovery when that feature is referenced in the information request message.

23. The method of claim 21, whereinthe information response message indicates that the NF registry (504) does not support NF type-independent NF discovery when that feature is not referenced in the information request message.

24. The method of any of claims 21 to 23, whereinthe at least one service exposed by the NF registry (504) is indicated in the information response message as a Universal Resource Indicator, URI, of the at least one service.

25. The method of any of claims 17 to 24, further comprisingsending (570), to the NF registry (504), an NF discovery request message directed at an NF discovery; andreceiving (580), in response to the NF discovery request message, an NF discovery response message from the NF registry (504).

26. The method of claim 25, whereinthe NF discovery request message does not specify an NF type for the NF discovery.

27. The method of claim 26, whereinthe information response message received from the NF registry (504) was indicative of the NF registry (504) supporting NF type-independent NF discovery.

28. The method of claim 26 or 27 in combination with at least claim 18, whereinthe NF discovery request message specifies one of the at least one discovery query parameter for which the NF registry (504) supports NF type-independent NF discovery.

29. The method of claim 28 in combination with at least claim 19, wherein the NF discovery request message specifies one of at least one parameter value for which the NF registry (504) supports NF type-independent NF discovery.

30. The method of any of claims 25 to 29, whereinthe NF discovery response message indicates NFs of the first NF type and of the second NF type.

31. The method of any of claims 17 to 30, whereinthe NF (502) is compliant with 3GPP Technical Specification 29.510, in particular version 19.2.0 or later.

32. The method of any of claims 17 to 31, whereinthe information request message is a bootstrapping information request message in accordance with 3GPP Technical Specification 29.510, in particular version 19.2.0 or later.

33. A computer program product comprising program code portions to perform the method of any of claims 1 to 32 when the computer program product is executed on one or more processors.

34. The computer program product of claim 33, stored on a processor-readable recording medium.

35. A network function registry configured to perform the steps of any of claims 1 to 16.

36. A network function configured to perform the steps of any of claims 17 to 32.

37. A network system comprising the network function registry of claim 35 and the network function of claim 36.

38. The system of claim 37, wherein the system is configured in accordance with 3GPP Technical Specification 29.510, in particular version 19.2.0 or later.

Images