Network function discovery and selection based on energy information

Abstract

A method performed by a first NF instance (e.g., AMF, SMF). The method includes obtaining subscription information for a subscriber, wherein the subscription information comprises energy preference information and the energy preference information comprises energy source preference information identifying at least a first preferred energy source type (e.g., solar, wind, thermal, water) and / or energy efficiency preference information indicating whether or not the subscriber has a preference to be served by energy efficient NF instances. The method also includes using the energy preference information as selection criteria for selecting a second NF instance (e.g., PCF, SMF, UPF).

Description

NETWORK FUNCTION DISCOVERY AND SELECTION BASED ON ENERGY INFORMATION TECHNICAL FIELD

[0001] Disclosed are embodiments related to discovering and selecting a network function based on energy information such as, for example, the network function’s energy efficiency and / or the network function’s power source. BACKGROUND

[0002] FIG.1 illustrates an exemplifying wireless communication system 100 represented as a Fifth Generation (5G) network architecture comprising an Access Network (AN) (e.g., a Radio AN (RAN)) and a Core network (CN) comprising network entities in the form of network functions (NFs). Typically, the AN comprises base stations, e.g., such as evolved Node Bs (eNBs) or 5G base stations (gNBs) or similar. As shown in FIG.1, user equipments (UEs) (i.e., any communication device, including: mobile phones, tablets, computers, routers, gateways, sensors, appliances, vehicles, extended reality (XR) devices (e.g., Augmented Reality(AR), Virtual Reality (VR), Mixed Reality (MR) devices) communicate with an Access and Mobility Management Function (AMF) via the AN. As further shown in FIG.1, the 5G CN (a.k.a., “5GC”) NFs include: a Network Slice Selection Function (NSSF), an Authentication Server Function (AUSF), a Unified Data Management (UDM), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a User Plane Function (UPF), a Policy Control Function (PCF), a NF Repository Function (NRF), a Location Management Function (LMF), and a Network Data Analytic Function (NWDAF).

[0003] The NRF supports at least the following functionalities: 1) maintains the NF instance profiles of the available NF instances and their supported services; 2) allows other NF instances to subscribe to, and get notified about, changes to an NF Profile; and 3) supports a discovery function. The NRF can receive a set of one or more query parameters (“a query”) from an NF instance, use the query to identify NF instances that match the query, and respond to the query by transmitting to the NF instance that sent the query the NF instance profiles for the NF instances that matched the query. Features of the NRF are specified in Third Generation Partnership Project (3GPP) Technical Specification (TS) 29.510 V18.2.0 (hereafter “TS 29.510”).

[0004] A number of 5GC NFs of different types are always instantiated per default in the 5GC, e.g., such as an AMF, a NRF, a PCF and a SMF etc. Other 5GC NFs may be instantiated as needed and several NFs of the same type can also be instantiated if required, e.g., to distribute load to additional NF(s) of the same type. Thus, an NF instance may be seen as an example or a specimen of a certain NF. Herein, the terms NF and NF instance areused interchangeably, unless otherwise expressly stated or is apparent from the context in which the terms are used. An NF instance exposes one or more NF Service Instances.

[0005] NF Instance Registration Procedure

[0006] A core network NF instance in the service based 5GC registers its NF instance profile (or “NF profile” or “profile” or “NFProfile” for short) at the NRF. That is, the registering NF instance sends a registration request to the NRF, which request comprises the profile of the registering NF instance. The profile is typically included in the request as a JavaScript Object Notation (JSON) object or other similar data object. The profile indicates the one or more NF services that are supported by the registering NF instance (i.e., the NFProfile may include one or more NFService IEs). Generally, a profile may comprise one or more of the following information elements (IEs) (e.g., attribute name value pairs (AVPs)) for the registering NF: NF type identifier, fully qualified domain name (FQDN) or IP address, name(s) of supported service(s), etc. The NRF stores the profile of the registering NF and preferably marks the registering NF instance as available. The registration may take place when the NF instance becomes operative for the first time or upon an activation of an individual NF service within the NF instance, e.g., triggered after a scaling operation. The NF instance may register / expose one or more NF services.

[0007] NF Instance Discovery

[0008] When a first NF instance (also referred to as an “NF service consumer”) intends to utilize an NF service supported by a second NF instance (also referred to as an “NF service producer”), the first NF instance will initiate an NF discovery process (a.k.a., NF service discovery process) with the NRF. Thus, the NF service consumer (e.g., an SMF, an AMF, etc.) sends a discover request to the NRF, which request comprises discovery information (e.g., a query). The discovery information may be included in the request as a JSON data object (e.g., file) or similar. The discovery information may indicate a target NF type (e.g., the discovery information may include the following attribute-value-pair: target-nf-type=X). Generally, the target NF type may e.g., be any of NSSF, NEF, AUSF, AMF, PCF, SMF, UDM or AF or similar. Upon receiving the query, the NRF determines a set of one or more NF instances that match the query sends to the NF service consumer a response to the discovery request (a.k.a., “query response”).

[0009] TS 29.510 specifies that NF or NF service selection is based on information contained in the data structures (e.g., NFProfiles) stored in NRF. In particular, the fields that are used for the NF or NF service selection decision may include the priority, capacity and load. Priority is the priority relative to other NFs of the same type to be used for NF selection. Capacity is the static capacity information, which can be expressed as an absolute value or as a relative value with respect to the capacity of other NF instances of the same type. Load is dynamic load information that indicates the current load percentage of the NF. The load, capacity and priority parameters, if present, are used for NF selection and load balancing.

[0010] Green Initiatives - Selecting NF instances based on Energy Efficiency

[0011] Different NF instance of the same type (e.g., a first SMF instance and a second SMF instance) may consume a disparate amount of energy. This can be, for example, because some NF instance implementations are specifically optimized to reduce the amount of energy consumed, or because some implementations are faulty and consume an excessive amount of energy due to their bad software quality.

[0012] It is desirable, of course, to allow for NF instance discovery and selection aiming at selecting the NF instances that are the most energy efficient, and thus minimizing the energy consumption in the operator's network. Accordingly, patent application publication WO2022 / 058049 describes a system in which information on the energy efficiency of the NF instances is stored in their respective profiles. For example, WO2022 / 058049 discloses “including a ... parameter in the NFProfile (e.g., an NFService within the NFProfile) in [the] NRF, so called ‘efficiency’, denoting how efficient in terms of energy consumption is the corresponding NF instance or [specific] NF service [provided by the NF instance].” This enables discovering and selecting the most energy efficient NF instances.

[0013] It should be noted that wireless communication systems beyond 5G, such as e.g.5G Advanced or 6G, may comprise other network entities (e.g., other network functions), or combination of network functions, providing at least the same functionalities or services as the NFs explicitly referred to herein (e.g. AMF, SMF, PCF and NRF). SUMMARY

[0014] Certain challenges presently exist. For instance, while WO2022 / 058049 provides a useful way to select NF instances based on energy efficiency, it does not mention also selecting NF instances based on the sources from which the NF instances obtain their energy. Accordingly, WO2022 / 058049 does not take the type of energy source into account, which means that an NF which is efficient but powered by a dirty energy source (e.g.,. coal) could be selected over a less energy efficient NF instance powered by a clean (a.k.a., “green”) energy source (e.g., solar, wind, hydro, etc.). Additionally, WO2022 / 058049 does not describe a way to allow a subscriber to influence the selection of green NF instances (e.g., NF instances that receive significant energy from a clean source and / or NF instances that have a high energy efficiency rating) that will be used to serve the subscriber.

[0015] Accordingly, in one aspect there is provided a method performed by a first NF instance (e.g., AMF, SMF). The method includes obtaining subscription information for a subscriber, wherein the subscription information comprises energy preference information and the energy preference information comprises energy source preference information identifying at least a first preferred energy source type (e.g., solar, wind, thermal, water) and / or energy efficiency preference information indicating whether or not the subscriber has a preference to be served by energy efficient NF instances. The method also includes using the energy preference information as selection criteria for selecting a second NF instance (e.g., PCF, SMF, UPF).

[0016] In another aspect there is provided a method performed by a first NF instance (e.g., AMF, SMF) for registering with a repository function (RF) (e.g., a 5G NRF). The method includes receiving from a management server energy source type information identifying at least a first energy source type, wherein the first NF instance receives at least some of its energy from an energy source of the first energy source type. The method also includes transmitting to the RF a registration message comprising an NF profile for the first NF instance, wherein the NF profile for the first NF instance comprises information identifying the first energy source type.

[0017] In another aspect there is provided a computer program comprising instructions which when executed by processing circuitry of a network node causes the network node to perform any of the methods disclosed herein. In one embodiment, there is provided a carrier containing the computer program wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium. In another aspect there is provided a network node that is configured to perform the methods disclosed herein. The network node may include memory and processing circuitry coupled to the memory.

[0018] An advantage of the embodiments is that they make it possible to select the best suited NF instance because the type of energy source can be taken into account. Hence, if a subscriber prefers NF instances that are powered by a clean energy source, then a less efficient NF instance powered by solar may be selected over a more efficient NF instance powered by coal. From a business perspective, the embodiments make it possible for a core network service provider (CSP) to provide an offer that is based on being environmentally friendly, possibly at expense of data latency if, for example, an energy / environmentally friendly UPF is selected placed at a location more far away than a not so environmental friendly UPF. But this latency vs. environmentally friendly tradeoff is one that an increasing number of subscribers are willing to make. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0020] FIG.1 illustrates an exemplifying wireless communication system.

[0021] FIG.2 illustrates subscriber data according to an embodiment.

[0022] FIG.3 is a message flow diagram illustrating an NF registration process according to an embodiment.

[0023] FIG.4 is a message flow diagram illustrating an NF instance discovery and selection process according to an embodiment.

[0024] FIG.5 is a message flow diagram illustrating an NF instance discovery and selection process according to an embodiment.

[0025] FIG.6A is a flowchart illustrating a process according to an embodiment.

[0026] FIG.6B is a flowchart illustrating a process according to an embodiment.

[0027] FIG.7 is a block diagram of a network node according to an embodiment. DETAILED DESCRIPTION

[0028] As noted above, WO2022 / 058049 provides a useful way to select NF instances based on energy efficiency, but it does not mention also selecting NF instances based on the sources from which the NF instances obtain their energy. Additionally, WO2022 / 058049 does not describe a way to allow a subscriber to influence the selection of “green” NF instances (e.g., NF instances that receive significant energy from a clean source and / or NF instances that have a high energy efficiency rating) that will be used to serve the subscriber.

[0029] Accordingly, in one embodiment, energy preference information can be added to a subscriber’s subscription data and energy usage information can be added to the NFProfile. In one embodiment, the energy preference information comprises energy source preference information identifying at least a first preferred energy source type (e.g., solar, wind, thermal, water) and / or energy efficiency preference information indicating whether or not the subscriber has a preference to be served by energy efficient NF instances. This energy information that can be added to the subscription data and to the NFProfile enable a subscriber to influence a first NF instance to select a green NF instance to serve the subscriber’s devices. That is, some or all of the energy preference information can be used as selection criteria during NF Discovery. An advantage of the embodiments is that they make it possible to select the best suited NF because the type of energy source can be taken into account. Hence, if a subscriber prefers NF instances that are powered by a clean energy source, then a less efficient NF instance powered by solar may be selected over a more efficient NF instance powered by coal.

[0030] 5G Subscription Data

[0031] FIG.2, which is a copy of Figure 6.1.3.1-1 from 3GPP TS 29.503 V18.1.0 (“TS 29.503”), shows the different sets of subscriber data that is stored for a particular subscriber, which is identified by a Subscription Permanent Identifier (SUPI). Hence, if an NF instance knows the subscribers SUPI, the NF instance can use the SUPI to retrieves via the UDM one or more of the sets of subscriber data linked to the SUPI, such as, for example, the Access and Mobility Subscription Data (“am-data”) or the Session Management Subscription data (“sm-data”). In one embodiment, if a subscriber would like to have then network operator select “green” NF instances, then the subscriber’s energy preference information mentioned above is added to the am-data and the sm-data. For example, in one embodiment, the following two new information elements (IE) (e.g., attribute_name-value-pairs) are added tothe subscriber’s am-data: energyEfficiencyAccepted and wantedEnergySource. Similarly, these same to IEs are also added to the subscriber’s sm-data.

[0032] The syntax and semantics for these IEs is shown in Table 1 below. TABLE 1 Attribute_Name Data Type Cardinality Description energyEfficiencyAccepted boolean 0..1 Indicates that Energy consumption is more important than other characteristics like latency, bandwidth, etc. TRUE: indicates that the most energy optimized NF selection is acceptable FALSE or absent: indicates that the most energy optimized NF selection is not acceptable wantedEnergySource String 0..1 Type of Energy Source (e.g., one or more of “clean”, “green”, “solar”, “wind”, “hydro”, etc.).

[0033] Table 5 and Table 6 show additional IEs that may be included in the am-data and sm-data, respectively.

[0034] NF Instance Registration

[0035] Typically, before an NF instance can be discovered by other NF instances, the NF instance must register its profile with the NRF. FIG.3 illustrates an example registration procedure. As illustrated in FIG.3, a management server (MS) 302 (e.g., an operations, administration and management (OAM) server, an operational support system (OSS) server, management data analytics function (MDAF), etc.) provides to an NF 304 a message m301 comprising configuration data for NF 304. In this example, the configuration data includes, among other things, an energy efficiency value (e.g., 90) indicating an energy efficiency of NF 304 and information specifying one or more types of energy sources from which NF 304 obtains its energy. In this example, NF 304 obtains at least some of its energy from a solar energy source.

[0036] After receiving the configuration data, NF 304 (or NF 304 for short) generates an NFProfile (e.g., a JSON object) that includes an energy efficiency IE that contains the specified energy efficiency value and an energy source IE that identifies the specified set of energy source types. In one embodiment, the energy source IE further contains, for each specified energy source type, a value indicating the percentage of energy NF 304 obtains from anenergy source of said type. For example, the energy source IE may contain the following string: “Solar:75%; Non- Green:25%.” As another example, the energy source IE may contain the following string: “Green:90%; Non- Green:10%”. Additional IEs that may be included in the NFProfile created by NF 304 are shown and described in Table 2 below.

[0037] After generating the NFProfile, NF 304 transmits a message m303 comprising the NFProfile to NRF 306, which will then store the NFProfile, thereby enabling NF 304 to be discovered by other NF instances. For instance, in one embodiment, NF 304 sends to NRF 306 a Hypertext Transfer Protocol (HTTP) PUT request message. The PUT request message includes a header that contains the resource URI representing NF 304. The resource URI is determined by NF 304. The payload body of the PUT request contain the representation of NF 304 (i.e., the NFProfile created by NF 304).

[0038] NF 304 (or another entity) may also update NF 304’s NFProfile that is stored at the NRF. For example, if NF 304’s energy efficiency changes, NF 304 (or another entity) may update NF 304’s NFProfile at the NRF to replace the existing energy efficiency value, which is out-of-date, with the up-to-date energy efficiency value. For example, as described in WO2022 / 058049, the NRF may subscribe to the NWDAF for energy efficiency analytics of an NF, including an indication of the efficiency analytics, for example as an Event-ID. In response, the the NWDAF sends to the MS a request to get energy consumption information of the NF. Thereafter, the MS sends to the NWDAF an energy consumption report for the NF, the energy consumption, e.g. in terms of Jules, etc., and optionally, a timespan or timestamp pertaining to the energy consumption. The NWDAF sends to the MS a request or subscription request for computing resources usage information for the NF (e.g., the NF’s CPU usage, memory usage, etc.) and then the MS sends to the NWDAF a computing resources usage information report for the NF, the computing resources usage information, e.g. number of executed instructions, CPU cycles, memory utilization, etc., and optionally, a timespan or timestamp pertaining to the computing resources usage information. The NWDAF may also get the number of UEs, sessions, uplinks, and / or downlinks being handled by the NF and / or the throughput by sending a request to the NF. Using the above information that it has collected for the NF, the NWDAF executes analytics processes and derives the an efficiency value considering the information received. For example, the energy consumption information is one input value and the computing resource usage information and / or the number of UEs, sessions, and or links is another input value from which the efficiency can be derived. As an example, an efficiency value can be calculated as the ratio of computing resource and / or memory usage divided by the number of subscribers and / or sessions and / or throughput on the specific NF to obtain an efficiency value indicating Energy / Resource used per user, session, or Gb uplink & downlink. One could also measure power consumption directly via existing tools, e.g., Kepler (Kubernetes-based Efficient Power Level Exporter), Scaphandre, Smartwatt and use those as input for the energy efficiency parameter per user. After the NWDAF calculates the efficiency value, the NWDAF may transmit to the NRF an update profile message containing the efficnecy value and causingthe NRF to update the NF’s NFProfile to replace the existing efficiency value with the newly calculated efficiency value.

[0039] NF Instance Discovery and Selection

[0040] FIG.4 illustrates an example discovery and selection procedure in which an NF instance 402 (or NF 402 for short) (e.g., an AMF) discovers and selects one or more NF instances (e.g., a PCF). In the illustrated example, the discovery and selection procedure is triggered by NF 402 receiving a message m403 that was transmitted by a UE 401. Message m403 may be 5G Registration Request message that UE 401 transmitted to register with a 5GC. In an embodiment in which message m403 is Registration Request message that does not include a Subscriber Concealed Identifier (SUCI) and NF 402 is not able to obtain the SUCI from another NF instance and does not itself have the SUCI (or corresponding SUPI), NF 402 transmits an identity request message m405 to UE 401 and UE 401 responds by transmitting an identity response message m407 comprising the SUCI, which conceals a SUPI for the subscription under which UE 401 is operating.

[0041] After obtaining the SUPI, NF 402 transmits to a UDM 404 a request message m409 comprising the SUPI and requesting a set of subscriber data linked to the SUPI (e.g., in case NF 402 is an AMF, AMF 402 requests the am-data linked with the SUPI). As noted above, the am-data may include the energyEfficiencyAccepted and / or wantedEnergySource IEs. In response to receiving message m409, UDM 404 transmits to NF 402 a response message m411 responsive to message m409, where m411 contains the requested subscriber data.

[0042] In one embodiment, after obtaining the requested subscriber data, NF 402 transmits to NRF 306 a request message m413 (e.g., HTTP GET) comprising a query, which comprises query parameters. NRF 306 uses the query to find NFProfiles that satisfy the query and then transmits to NF 402 a response message m415 containing at least some of the NFProfiles that satisfy the query. In one embodiment, at least one NFProfile included in response message m415 includes an energy source IE specifying one or more types of energy sources from which the NF instance identified by the NFProfile obtains its energy. Additional IEs that may be included in the NFProfile are shown and described in Table 4.

[0043] In one embodiment, if the retrieved subscriber data includes information identifying a preferred type of energy source, then NF 402 includes as one of the query parameters the preferred type of energy source. For example, the query included in message m413 may include the following query parameter: “preferred- energysource=Clean.” As another example, the query may include the following query parameter: “preferred- energysource=Solar.” Accordingly, if the preferred-energysource query parameter is present in the query, NRF 306 may decide that, if an NFProfile does not indicate that the corresponding NF instance obtains energy from an energy source of the type indicated in the preferred-energysource query parameter, then the NFProfile will not satisfy the query. In this way, NF 402 may receive from NRF 306 only NFProfiles of NF instances that receive energy from anenergy source of the subscriber’s preferred energy source type. Additional query parameters that may be included in the query are shown and described in Table 3 below.

[0044] In one embodiment, if the query includes the preferred-energysource attribute, then message m415 may indicate whether all the returned NFProfiles match or do not match the query parameter preferred- energysource. For instance, message m415 may include an indicator (e.g., “preferredEnergySourceMatchInd”) that indicates whether all the returned NFProfiles match or do not match the query parameter preferred-energysource (e.g., if indicator is TRUE: Match; if indicator is FALSE (or not present): Not Match).

[0045] After receiving response message m415, NF 402 selects one of the NFProfiles (step s417) and then transmits a message m419 to the NF instance identified by the selected NFProfile. For example, NF 402 selects a PCF instance and transmits to the selected PCF instance a policy association request.

[0046] If NRF 306 returns a plurality of NFProfiles in response message m415, then, in one embodiment, as a result of the subscription data indicating that the subscriber prefers NF 402 to select the most energy efficient NF instance (e.g., after NF 402 determines that the energyEfficiencyAccepted attribute is included in the subscription data and the value of the attribute is set to TRUE), NF 402 uses the energy efficiency information included in the profiles to select the NFProfile having the highest energy efficient value.

[0047] In one embodiment, even if the retrieved subscriber data includes information identifying a preferred type of energy source, NF 402 does not include as one of the query parameters the preferred type of energy source. Hence, in this embodiment, NRF 306 will not filter NFProfiles based one energy source type. Accordingly, NF 402 will itself perform the energy source type filtering. That is, for example, if NRF 306 returns a set of NFProfiles, NF 402 will remove from the set any NFProfile that does not indicate that its corresponding NF instance is powered an energy source of the subscriber’s preferred energy source type, thereby forming a set of candidate NFProfiles. NF 402 then selects an NFProfile from the set of candidate NFProfiles (e.g., the selection may be based on energy efficiency as described above). In this way, NF 402 selects an energy efficient NF instance that receives energy from an energy source of the subscriber’s preferred energy source type.

[0048] FIG.5 is a message flow showing another use case. In this use case UE 401 transmits a session establishment request message m501, which is received by an AMF 502. After receiving message m501, AMF 502 discovers and selects an SMF (i.e. ,SMF 504 in this example). More specifically, AMF 502 transmits to NRF 306 a request message m503 (e.g., HTTP GET) comprising a query, which comprises a set of one or more query parameters, at least one of which indicates that AMF 502 wants NFProfiles belonging to SMFs. NRF 306 uses the query to find SMF NFProfiles that satisfy the query and then transmits to AMF 502 a response message m505 containing at least some of the NFProfiles that satisfy the query. In one embodiment, if the retrieved subscriber data associated with UE 401 includes information identifying a preferred type of energy source, then AMF 402 includes asone of the query parameters the preferred type of energy source. In this way, AMF 402 may receive from NRF 306 only NFProfiles of SMF instances that receive energy from an energy source of the subscriber’s preferred energy source type. After receiving the SMF NFProfiles, AMF 502 selects one of the NFProfiles in the same manner as described above with respect to step s417.

[0049] For example, if NRF 306 returns a plurality of SMF NFProfiles in response message m503, then, in one embodiment, as a result of the subscription data indicating that the subscriber prefers AMF 502 to select the most energy efficient SMF instance, AMF 502 uses the energy efficiency information included in the profiles to select the NFProfile having the highest energy efficient value. Moreover, if NRF 306 does not filter NFProfiles based one energy source type, then AMF 502 may itself perform the energy source type filtering. That is, for example, if NRF 306 returns a set of NFProfiles, AMF 502 may remove from the set any NFProfile that does not indicate that its corresponding SMF instance is powered an energy source of the subscriber’s preferred energy source type, thereby forming a set of candidate NFProfiles. AMF 402 then selects an NFProfile from the set of candidate NFProfiles. In this way, AMF 402 selects an energy efficient SMF instance that receives energy from an energy source of the subscriber’s preferred energy source type. After selecting the SM instance, AMF 402 sends to the selected SMF instance a message m507 (e.g., a create context request).

[0050] SMF 504 transmits to UDM 404 a request message m509 comprising the SUPI for UE 401 and requesting a set of subscriber data linked to the SUPI (e.g., in this case, SMF 504 requests the sm-data linked with the SUPI). As noted above, the sm-data may include the energyEfficiencyAccepted and / or wantedEnergySource IEs. In response to receiving message m509, UDM 404 transmits to SMF 504 a response message m511 responsive to message m509, where m511 contains the requested sm-data.

[0051] In one embodiment, after obtaining the requested sm-data, SMF 504 transmits to NRF 306 a request message m513 (e.g., HTTP GET) comprising a query, which comprises query parameters, at least one of which indicates that SMF 504 wants NFProfiles belonging to UPFs. NRF 306 uses the query to find NFProfiles that satisfy the query and then transmits to SMF 504 a response message m515 containing at least some of the NFProfiles that satisfy the query. In one embodiment, SMF 504 includes as one of the query parameters the preferred type of energy source. Accordingly, if the preferred-energysource query parameter is present in the query, NRF 306 may decide that, if an NFProfile does not indicate that the corresponding NF instance obtains energy from an energy source of the type indicated in the preferred-energysource query parameter, then the NFProfile will not satisfy the query. In this way, SMF 504 may receive from NRF 306 only NFProfiles of UPF instances that receive energy from an energy source of the subscriber’s preferred energy source type. In one embodiment, if the query includes the preferred-energysource attribute, then message m515 may indicate whether all the returned NFProfiles match or do not match the query parameter preferred-energysource.

[0052] After receiving response message m515, SMF 504 selects one of the UPF NFProfiles (step s517) and then transmits a message m519 to the UPF instance identified by the selected NFProfile (i.e., UPF 590). For example, SMF 504 transmits to the selected UPF instance a session establishment request message.

[0053] If NRF 306 returns a plurality of NFProfiles in response message m515, then, in one embodiment, as a result of the subscription data indicating that the subscriber prefers SMF 504 to select the most energy efficient NF instance, SMF 504 uses the energy efficiency information included in the profiles to select the NFProfile having the highest energy efficient value.

[0054] In one embodiment, even if the retrieved subscriber data includes information identifying a preferred type of energy source, SMF 504 does not include as one of the query parameters the preferred type of energy source. Hence, in this embodiment, NRF 306 will not filter NFProfiles based one energy source type. Accordingly, SMF 504 will itself perform the energy source type filtering. That is, for example, if NRF 306 returns a set of NFProfiles, SMF 504 will remove from the set any NFProfile that does not indicate that its corresponding NF instance is powered by an energy source of the subscriber’s preferred energy source type, thereby forming a set of candidate NFProfiles. SMF 504 then selects an NFProfile from the set of candidate NFProfiles (e.g., the selection may be based on energy efficiency as described above). In this way, SMF 504 selects an energy efficient UPF instance that receives energy from an energy source of the subscriber’s preferred energy source type.

[0055] FIG.6A is a flow chart illustrating a process 600, according to an embodiment. Process 600 may begin in step s602. Step s602 comprises obtaining subscription information for a subscriber, wherein the subscription information comprises energy preference information and the energy preference information comprises energy source preference information identifying at least a first preferred energy source type (e.g., solar, wind, thermal, water) and / or energy efficiency preference information indicating whether or not the subscriber has a preference to be served by energy efficient NF instances. Step s604 comprises using the energy preference information as selection criteria for selecting a second NF instance (e.g., PCF, SMF, UPF).

[0056] In some embodiments, using the energy preference information as selection criteria for selecting a second NF instance (e.g., PCF, SMF, UPF) comprises: after obtaining the subscription information, transmitting to a repository function, RF (e.g., 5G NRF), a query for discovering NF instance profiles; receiving from the RF a set of one or more NF instance profiles selected by the RF based on the query, wherein each NF instance profile included in the set of NF instance profiles identifies an NF instance; and using the energy preference information as selection criteria for selecting one of the identified NF instances.

[0057] In some embodiments, the energy preference information comprises the energy source preference information, the set of NF instance profiles includes at least a first NF instance profile, and using the energy preference information as selection criteria for selecting one of the identified NF instances comprises determiningwhether the first NF instance profile indicates that the NF instance identified by the first NF instance profile receives energy from an energy source of the first preferred energy source type.

[0058] In some embodiments, the energy preference information comprises the energy efficiency preference information, the set of NF instance profiles includes at least a first NF instance profile and a second NF instance profile, and as a result of the energy efficiency preference information indicating that the subscriber has a preference to be served by energy efficient NF instances, comparing the energy efficiency of the NF instance identified by the first NF instance profile with the energy efficiency of the NF instance identified by the second NF instance profile.

[0059] In some embodiments, the energy preference information comprises the energy source preference information and the energy efficiency preference information, the set of NF instance profiles includes at least a first NF instance profile and a second NF instance profile, and using the energy preference information as selection criteria for selecting one of the identified NF instances comprises: determining whether the first NF instance profile indicates that the NF instance identified by the first NF instance profile receives energy from an energy source of the first preferred energy source type; determining whether the second NF instance profile indicates that the NF instance identified by the second NF instance profile receives energy from an energy source of the first preferred energy source type; and as a result of the energy efficiency preference information indicating that the subscriber has a preference to be served by energy efficient NF instances and determining that both the first and second NF instance profiles identify an NF instance that receives energy from an energy source of the first preferred energy source type, comparing the energy efficiency of the NF instance identified by the first NF instance profile with the energy efficiency of the NF instance identified by the second NF instance profile.

[0060] In some embodiments, the energy preference information comprises the energy source preference information, and the query comprises energy source type information identifying the first preferred energy source type.

[0061] In some embodiments, the energy preference information comprises the energy efficiency preference information, the set of NF instance profiles includes at least a first NF instance profile and a second NF instance profile, and as a result of the energy efficiency preference information indicating that the subscriber has a preference to be served by energy efficient NF instances, comparing the energy efficiency of the NF instance identified by the first NF instance profile with the energy efficiency of the NF instance identified by the second NF instance profile.

[0062] In some embodiments process 600 further includes, after obtaining the subscription information and prior transmitting the query to the RF: determining whether the energy preference information comprises the energy source preference information; and after determining that the energy preference information comprises theenergy source preference information, constructing the query so that the query comprises an energy source query parameter identifying the first preferred energy source type (e.g., the query includes the AVP: “preferred- energysource=Clean”).

[0063] In some embodiments, the first NF instance is an instance of an access management function (e.g., AMF), and the method further comprises, prior to obtaining the subscription information for the subscriber, receiving a registration request message (e.g., message m403) comprising a subscriber identifier (e.g., SUCI or Temporary ID) for identifying the subscriber, and using the energy preference information as selection criteria for selecting a second NF instance (e.g., PCF, SMF, UPF) comprises using the energy preference information as selection criteria for selecting an instance of a session management function.

[0064] In some embodiments, the first NF instance is an instance of an access management function (e.g., AMF), and the method further comprises, prior to obtaining the subscription information for the subscriber, receiving a request message (e.g., registration request m403 or PDU session establishment request m501) comprising a subscriber identifier for identifying the subscriber, and using the energy preference information as selection criteria for selecting a second NF instance comprises using the energy preference information as selection criteria for selecting an instance of a policy function or an instance of a session management function.

[0065] In some embodiments, the first NF instance is an instance of a session management function (e.g., SMF), and the method further comprises, prior to obtaining the subscription information for the subscriber, receiving a request message (e.g., create context request m507) comprising a subscriber identifier for identifying the subscriber, and using the energy preference information as selection criteria for selecting a second NF instance comprises using the energy preference information as selection criteria for selecting an instance of a user plane function.

[0066] FIG.6B is a flow chart illustrating a process 610, according to an embodiment. Process 610 may begin in step s612. Step s612 comprises receiving from a management server (e.g., MS 302) energy source type information identifying at least a first energy source type, wherein the first NF instance receives at least some of its energy from an energy source of the first energy source type. Step s614 comprises transmitting to the RF a registration message m303 comprising an NF profile for the first NF instance, wherein the NF profile for the first NF instance comprises information identifying the first energy source type. In some embodiments, process 610 further includes receiving from the management server an energy efficiency value indicating an energy efficiency of the first NF instance, wherein the NF profile for the first NF instance further comprises the energy efficiency value.

[0067] FIG.7 is a block diagram of a network node 700, according to some embodiments, which can be used to implement any of the NF instances disclosed herein (e.g., AMF, SMF, NRF, UDM). For instance, in embodiments where an NF instance consists of software, network node 700 may run (or execute a virtual machinethat runs) the NF instance. As shown in FIG.7, network node 700 may comprise: processing circuitry (PC) 702, which may include one or more processors (P) 755 (e.g., one or more general purpose microprocessors and / or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed (e.g., network node 700 may be a distributed computing apparatus comprising two or more computers or a monolithic computing apparatus consisting of a single computer); at least one network interface 748 (e.g., a physical interface or air interface) comprising a transmitter (Tx) 745 and a receiver (Rx) 747 for enabling network node 700 to transmit data to and receive data from other nodes connected to a network 110 (e.g., an Internet Protocol (IP) network) to which network interface 748 is connected (physically or wirelessly) (e.g., network interface 748 may be coupled to an antenna arrangement comprising one or more antennas for enabling network node 700 to wirelessly transmit / receive data); and a storage unit (a.k.a., “data storage system”) 708, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. In embodiments where PC 702 includes a programmable processor, a computer readable storage medium (CRSM) 742 may be provided. CRSM 742 may store a computer program (CP) 743 comprising computer readable instructions (CRI) 744. CRSM 742 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI 744 of computer program 743 is configured such that when executed by PC 702, the CRI causes network node 700 to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, network node 700 may be configured to perform steps described herein without the need for code. That is, for example, PC 702 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and / or software.

[0068] While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0069] As used herein transmitting a message “to” or “toward” an intended recipient encompasses transmitting the message directly to the intended recipient or transmitting the message indirectly to the intended recipient (i.e., one or more other nodes are used to relay the message from the source node to the intended recipient). Likewise, as used herein receiving a message “from” a sender encompasses receiving the message directly from the sender or indirectly from the sender (i.e., one or more nodes are used to relay the message from the sender to the receiving node). Further, as used herein “a” means “at least one” or “one or more.”

[0070] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

[0071] Additional InformationTABLE 2 (NFProfile IEs) (TS 29.5106.1.6.2.2-1)Attribute name Data type P Cardinality Description nfInstanceId NfInstanceId M 1 Unique identity of the NF Instance. nfType NFType M 1 Type of Network Function nfStatus NFStatus M 1 Status of the NF Instance (NOTE 5) (NOTE 16) collocatedNfInstances array(Collocated O 1..N Information related to collocated NF type(s) and NfInstance) corresponding NF Instances when the NF is collocated with NFs supporting other NF types. (NOTE 21) In this release of the specification, following collocation scenarios are supported (see clause 6.1.6.2.99): - a MB-SMF collocated with a SMF; - a MB-UPF collocated with a UPF. nfInstanceName string O 0..1 Human readable name of the NF Instance heartBeatTimer integer C 0..1 Time in seconds expected between 2 consecutive heart-beat messages from an NF Instance to the NRF. It may be included in the registration request. When present in the request it shall contain the heartbeat time proposed by the NF service consumer. It shall be included in responses from NRF to registration requests (PUT) or in NF profile updates (PUT or PATCH). If the proposed heartbeat time is acceptable by the NRF based on the local configuration, it shall use the same value as in the registration request; otherwise the NRF shall override the value using a preconfigured value. plmnList array(PlmnId) C 1..N PLMN(s) of the Network Function (NOTE 7). This IE shall be present if this information is available for the NF. If neither the plmnList IE nor the snpnList IE are provided, PLMN ID(s) of the PLMN of the NRF are assumed for the NF. snpnList array(PlmnIdNid) C 1..N SNPN(s) of the Network Function. This IE shall be present if the NF pertains to one or more SNPNs.sNssais array(ExtSnssai) O 1..N S-NSSAIs of the Network Function. If not provided, and if the perPlmnSnssaiList attribute is not present, the NF can serve any S-NSSAI. When present this IE represents the list of S-NSSAIs supported in all the PLMNs listed in the plmnList IE. If the sNSSAIs attribute is provided in at least one NF Service, the S-NSSAIs supported by the NF Profile shall be the set or a superset of the S- NSSAIs of the NFService(s). perPlmnSnssaiList array(PlmnSnssai O 1..N This IE may be included when the list of S-NSSAIs ) supported by the NF for each PLMN it is supporting is different. When present, this IE shall include the S- NSSAIs supported by the Network Function for each PLMN supported by the Network Function. When present, this IE shall override sNssais IE. (NOTE 9) If the perPlmnSnssaiList attribute is provided in at least one NF Service, the S-NSSAIs supported per PLMN in the NF Profile shall be the set or a superset of the perPlmnSnssaiList of the NFService(s). nsiList array(string) O 1..N NSI identities of the Network Function. If not provided, the NF can serve any NSI. fqdn Fqdn C 0..1 FQDN of the Network Function (NOTE 1) (NOTE 2) (NOTE 18). For AMF, the FQDN registered with the NRF shall be that of the AMF Name (see 3GPP TS 23.003

[0012] clause 28.3.2.5). interPlmnFqdn Fqdn C 0..1 If the NF needs to be discoverable by other NFs in a different PLMN, then an FQDN that is used for inter- PLMN routing as specified in 3GPP TS 23.003

[0012] shall be registered with the NRF (NOTE 8). A change of this attribute shall result in triggering a "NF_PROFILE_CHANGED" notification from NRF towards subscribing NFs located in the same or a different PLMN, but in the latter case the new value shall be notified as a change of the "fqdn" attribute. ipv4Addresses array(Ipv4Addr) C 1..N IPv4 address(es) of the Network Function (NOTE 1) (NOTE 2) (NOTE 18) ipv6Addresses array(Ipv6Addr) C 1..N IPv6 address(es) of the Network Function (NOTE 1) (NOTE 2) (NOTE 18)allowedPlmns array(PlmnId) O 1..N PLMNs allowed to access the NF instance. If not provided, any PLMN is allowed to access the NF. This attribute shall not be included in profile change notifications to subscribed NFs, unless the subscribing entity explicitly requested so, in the "completeProfileSubscription" attribute in the subscription request message, and the NRF authorized such a request (see clauses 5.2.2.6.2 and 6.1.6.2.17). (NOTE 17) allowedSnpns array(PlmnIdNid) O 1..N SNPNs allowed to access the NF instance. If this attribute is present in the NFService and in the NF profile, the attribute from the NFService shall prevail. The absence of this attribute in both the NFService and in the NF profile indicates that no SNPN, other than the SNPN(s) registered in the snpnList attribute of the NF Profile (if the NF pertains to an SNPN), is allowed to access the service instance. This attribute shall not be included in profile change notifications to subscribed NFs, unless the subscribing entity explicitly requested so, in the "completeProfileSubscription" attribute in the subscription request message, and the NRF authorized such a request (see clauses 5.2.2.6.2 and 6.1.6.2.17). (NOTE 17) allowedNfTypes array(NFType) O 1..N Type of the NFs allowed to access the NF instance. If not provided, any NF type is allowed to access the NF. This attribute shall not be included in profile change notifications to subscribed NFs, unless the subscribing entity explicitly requested so, in the "completeProfileSubscription" attribute in the subscription request message, and the NRF authorized such a request (see clauses 5.2.2.6.2 and 6.1.6.2.17). (NOTE 17)allowedNfDomains array(string) O 1..N Pattern (regular expression according to the ECMA- 262 dialect [8]) representing the NF domain names within the PLMN of the NRF allowed to access the NF instance. If not provided, any NF domain is allowed to access the NF. This attribute shall not be included in profile change notifications to subscribed NFs, unless the subscribing entity explicitly requested so, in the "completeProfileSubscription" attribute in the subscription request message, and the NRF authorized such a request (see clauses 5.2.2.6.2 and 6.1.6.2.17). (NOTE 17) allowedNssais array(ExtSnssai) O 1..N S-NSSAI of the allowed slices to access the NF instance. If not provided, any slice is allowed to access the NF. This attribute shall not be included in profile change notifications to subscribed NFs, unless the subscribing entity explicitly requested so, in the "completeProfileSubscription" attribute in the subscription request message, and the NRF authorized such a request (see clauses 5.2.2.6.2 and 6.1.6.2.17). (NOTE 17)priority integer O 0..1 Priority (relative to other NFs of the same type) within the range 0 to 65535, to be used for NF selection; lower values indicate a higher priority. Priority may or may not be present in the nfServiceList parameters, xxxInfo parameters and in this attribute. Priority in the nfServiceList has precedence over the priority in this attribute (NOTE 4). Priority in xxxInfo parameter shall only be used to determine the relative priority among NF instances with the same priority at NFProfile / NFService. The NRF may overwrite the received priority value when exposing an NFProfile with the Nnrf_NFDiscovery service. capacity integer O 0..1 Static capacity information within the range 0 to 65535, expressed as a weight relative to other NF instances of the same type; if capacity is also present in the nfServiceList parameters, those will have precedence over this value. (NOTE 4). load integer O 0..1 Dynamic load information, within the range 0 to 100, indicates the current load percentage of the NF. loadTimeStamp DateTime O 0..1 It indicates the point in time in which the latest load information (sent by the NF in the "load" attribute of the NF Profile) was generated at the NF Instance. If the NF did not provide a timestamp, the NRF should set it to the instant when the NRF received the message where the NF provided the latest load information. locality string O 0..1 Operator defined information about the location of the NF instance (e.g. geographic location, data center) (NOTE 3)extLocality map(string) O 1..N Operator defined information about the location of the NF instance. (NOTE 3) The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters, representing a type of locality as defined in clause 6.1.6.3.x. Example: { "DATA_CENTER": "dc-123", "CITY": "Los Angeles", "STATE": "California" } udrInfo UdrInfo O 0..1 Specific data for the UDR (ranges of SUPI, group ID …) udrInfoList map(UdrInfo) O 1..N Multiple entries of UdrInfo. This attribute provides additional information to the udrInfo. udrInfoList may be present even if the udrInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. udmInfo UdmInfo O 0..1 Specific data for the UDM (ranges of SUPI, group ID…) udmInfoList map(UdmInfo) O 1..N Multiple entries of UdmInfo. This attribute provides additional information to the udmInfo. udmInfoList may be present even if the udmInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. ausfInfo AusfInfo O 0..1 Specific data for the AUSF (ranges of SUPI, group ID…) ausfInfoList map(AusfInfo) O 1..N Multiple entries of AusfInfo. This attribute provides additional information to the ausfInfo. ausfInfoList may be present even if the ausfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. amfInfo AmfInfo O 0..1 Specific data for the AMF (AMF Set ID, …)amfInfoList map(AmfInfo) O 1..N Multiple entries of AmfInfo. This attribute provides additional information to the amfInfo. amfInfoList may be present even if the amfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. smfInfo SmfInfo O 0..1 Specific data for the SMF (DNN's, …). (NOTE 12) smfInfoList map(SmfInfo) O 1..N Multiple entries of SmfInfo. This attribute provides additional information to the smfInfo. smfInfoList may be present even if the smfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. (NOTE 12) upfInfo UpfInfo O 0..1 Specific data for the UPF (S-NSSAI, DNN, SMF serving area, interface…) upfInfoList map(UpfInfo) O 1..N Multiple entries of UpfInfo. This attribute provides additional information to the upfInfo. upfInfoList may be present even if the upfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. pcfInfo PcfInfo O 0..1 Specific data for the PCF. pcfInfoList map(PcfInfo) O 1..N Multiple entries of PcfInfo. This attribute provides additional information to the pcfInfo. pcfInfoList may be present even if the pcfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. bsfInfo BsfInfo O 0..1 Specific data for the BSF. bsfInfoList map(BsfInfo) O 1..N Multiple entries of BsfInfo. This attribute provides additional information to the bsfInfo. bsfInfoList may be present even if the bsfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. chfInfo ChfInfo O 0..1 Specific data for the CHF.chfInfoList map(ChfInfo) O 1..N Multiple entries of ChfInfo. This attribute provides additional information to the chfInfo. chfInfoList may be present even if the chfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. nefInfo NefInfo O 0..1 Specific data for the NEF. nrfInfo NrfInfo O 0..1 Specific data for the NRF. udsfInfo UdsfInfo O 0..1 Specific data for the UDSF. udsfInfoList map(UdsfInfo) O 1..N Multiple entries of udsfInfo. This attribute provides additional information to the udsfInfo. udsfInfoList may be present even if the udsfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. nwdafInfo NwdafInfo O 0..1 Specific data for the NWDAF. nwdafInfoList map(NwdafInfo) O 1..N Multiple entries of nwdafInfo. This attribute provides additional information to the nwdafInfo. nwdafInfoList may be present even if the nwdafInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. pcscfInfoList map(PcscfInfo) O 1..N Specific data for the P-CSCF. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. (NOTE 11) hssInfoList map(HssInfo) O 1..N Specific data for the HSS. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. customInfo object O 0..1 Specific data for custom Network Functions recoveryTime DateTime O 0..1 Timestamp when the NF was (re)started (NOTE 5) (NOTE 6)nfServicePersistence boolean O 0..1 - true: If present, and set to true, it indicates that the different service instances of a same NF Service in this NF instance, supporting a same API version, are capable to persist their resource state in shared storage and therefore these resources are available after a new NF service instance supporting the same API version is selected by a NF Service Consumer (see 3GPP TS 23.527

[0027] ). - false (default): Otherwise, it indicates that the NF Service Instances of a same NF Service are not capable to share resource state inside the NF Instance. nfServices array(NFService) O 1..N List of NF Service Instances. It shall include the services produced by the NF that can be discovered by other NFs, if any. (NOTE 15) This attribute is deprecated; the attribute "nfServiceList" should be used instead. nfServiceList map(NFService) O 1..N Map of NF Service Instances, where the "serviceInstanceId" attribute of the NFService object shall be used as the key of the map. (NOTE 15) It shall include the services produced by the NF that can be discovered by other NFs, if any. nfProfileChangesSuppo boolean O 0..1 NF Profile Changes Support Indicator. rtInd See Annex B. This IE may be present in the NFRegister or NFUpdate (NF Profile Complete Replacement) request and shall be absent in the response. true: the NF Service Consumer supports receiving NF Profile Changes in the response. false (default): the NF Service Consumer does not support receiving NF Profile Changes in the response. Write-Only: truenfProfileChangesInd boolean O 0..1 NF Profile Changes Indicator. See Annex B. This IE shall be absent in the request to the NRF and may be included by the NRF in NFRegister or NFUpdate (NF Profile Complete Replacement) response. true: the NF Profile contains NF Profile changes. false (default): complete NF Profile. Read-Only: true defaultNotificationSubsc array(DefaultNotif O 1..N Notification endpoints for different notification types. riptions icationSubscriptio (NOTE 10) n) lmfInfo LmfInfo O 0..1 Specific data for the LMF. gmlcInfo GmlcInfo O 0..1 Specific data for the GMLC. nfSetIdList array(NfSetId) C 1..N NF Set ID defined in clause 28.12 of 3GPP TS 23.003

[0012] . At most one NF Set ID shall be indicated per PLMN- ID or SNPN of the NF. At most one combination of an AMF region and an AMF Set ID shall be indicated per PLMN-ID or SNPN in an AMF profile. This information shall be present if available. (NOTE 22) (NOTE 23) servingScope array(string) O 1..N The served area(s) of the NF instance. The absence of this attribute does not imply that the NF instance can serve every area in the PLMN. (NOTE 13) lcHSupportInd boolean O 0..1 This IE indicates whether the NF supports Load Control based on LCI Header (see clause 6.3 of 3GPP TS 29.500 [4]). - true: the NF supports the feature. - false (default): the NF does not support the feature. olcHSupportInd boolean O 0..1 This IE indicates whether the NF supports Overload Control based on OCI Header (see clause 6.4 of 3GPP TS 29.500 [4]). - true: the NF supports the feature. - false (default): the NF does not support the feature.nfSetRecoveryTimeList map(DateTime) O 1..N Map of recovery time, where the key of the map is the NfSetId of NF Set(s) that the NF instance belongs to. When present, the value of each entry of the map shall be the recovery time of the NF Set indicated by the key. serviceSetRecoveryTim map(DateTime) O 1..N Map of recovery time, where the key of the map is eList the NfServiceSetId of the NF Service Set(s) configured in the NF instance. When present, the value of each entry of the map shall be the recovery time of the NF Service Set indicated by the key. scpDomains array(string) O 1..N When present, this IE shall carry the list of SCP domains the SCP belongs to, or the SCP domain the NF (other than SCP) or the SEPP belongs to. (NOTE 14) scpInfo ScpInfo O 0..1 Specific data for the SCP. seppInfo SeppInfo O 0..1 Specific data for the SEPP. vendorId VendorId O 0..1 Vendor ID of the NF instance, according to the IANA-assigned "SMI Network Management Private Enterprise Codes"

[0038] . supportedVendorSpecifi map(array(Vendo O 1..N(1..M) Map of Vendor-Specific features, where the key of cFeatures rSpecificFeature) the map is the IANA-assigned "SMI Network ) Management Private Enterprise Codes"

[0038] . The string used as key of the map shall contain 6 decimal digits; if the SMI code has less than 6 digits, it shall be padded with leading digits "0" to complete a 6- digit string value. The value of each entry of the map shall be a list (array) of VendorSpecificFeature objects. (NOTE 19) aanfInfoList map(AanfInfo) O 1..N Multiple entries of AanfInfo. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. 5gDdnmfInfo 5GDdnmfInfo O 0..1 Specific data for the 5G DDNMF (5G DDNMF ID, …) mfafInfo MfafInfo O 0..1 Specific data for the MFAFeasdfInfoList map(EasdfInfo) O 1..N EASDF specific data. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. (NOTE 20) dccfInfo DccfInfo O 0..1 Specific data for the DCCF. nsacfInfoList map(NsacfInfo) O 1..N Specific data for the NSACF. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. mbSmfInfoList map(MbSmfInfo) O 1..N MB-SMF specific data. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. tsctsfInfoList map(TsctsfInfo) O 1..N Specific data for the TSCTSF. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. mbUpfInfoList map(MbUpfInfo) O 1..N MB-UPF specific data. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. trustAfInfo TrustAfInfo O 0..1 Specific data for the trusted AF. nssaafInfo NssaafInfo O 0..1 Specific data for the NSSAAF. hniList arrary(Fqdn) C 1..N Identifications of Credentials Holder or Default Credentials Server. This IE shall be present if the NFs are available for the case of access to an SNPN using credentials owned by a Credentials Holder or for the case of SNPN Onboarding using a DCS. iwmscInfo IwmscInfo O 0..1 Specific data for the SMS-IWMSC. mnpfInfo MnpfInfo O 0..1 Specific data for the MNPF. smsfInfo SmsfInfo O 0..1 Specific data for the SMSF.TABLE 3 (query parameters) (TS 29.5106.2.3.2.3.1-1: URI query parameters)Name Data type P Cardinality Description target-nf- NFType M 1 This IE shall contain the NF type of the target NF being type discovered. requester- NFType M 1 This IE shall contain the NF type of the Requester NF nf-type that is invoking the Nnrf_NFDiscovery service. preferred- array(Collocate O 1..N The IE may be present to indicate desired collocated collocated- dNfType) NF type(s) when the NF service consumer wants to nf-types discover candidate NFs matching the target NF Type that are preferentially collocated with other NF types. (NOTE 19) requester- NfInstanceId O 0..1 If included, this IE shall contain the NF instance id of nf-instance- the Requester NF. idservice- array(ServiceN O 1..N If included, this IE shall contain an array of service names ame) names for which the NRF is queried to provide the list of NF profiles. The NRF shall return the NF profiles that have at least one NF service matching the NF service names in this list. The NF services returned by the NRF (inside the nfServices or nfServiceList attributes) in each matching NFProfile shall be those services whose service name matches one of the service names included in this list. If not included, the NRF shall not filter based on service name. This array shall contain unique items. Example: NF1 supports services: A, B, C NF2 supports services: C, D, E NF3 supports services: A, C, E NF4 supports services: B, C, D Consumer asks for service-names = [A, E] NRF returns: NF1 containing service A NF2 containing service E NF3 containing services A, E NF4 is not returnedrequester- Fqdn O 0..1 This IE may be present for an NF discovery request nf-instance- within the same PLMN as the NRF. fqdn If included, this IE shall contain the FQDN of the Requester NF that is invoking the Nnrf_NFDiscovery service. The NRF shall use this to return only those NF profiles that include at least one NF service containing an entry in the "allowedNfDomains" list (see clause 6.1.6.2.3) that matches the domain of the requester NF. This IE shall be ignored by the NRF if it is received from a requester NF belonging to a different PLMN. (NOTE 12) target- array(PlmnId) C 1..N This IE shall be included when NF services in a plmn-list different PLMN, or NF services of specific PLMN ID(s) in a same PLMN comprising multiple PLMN IDs, need to be discovered. When included, this IE shall contain the PLMN ID of the target NF. If more than one PLMN ID is included, NFs from any PLMN ID present in the list matches the query parameter. This IE shall also be included in SNPN scenarios, when the entity owning the subscription, the Credentials Holder (see clause 5.30.2.9 in 3GPP TS 23.501 [2]) is a PLMN. For inter-PLMN service discovery, at most 1 PLMN ID shall be included in the list; it shall be included in the service discovery from the NF in the source PLMN sent to the NRF in the same PLMN, while it may be absent in the service discovery request sent from the source NRF to the target NRF. In such case, if the NRF receives more than 1 PLMN ID, it shall only consider the first element of the array, and ignore the rest. requester- array(PlmnId) C 1..N This IE shall be included when NF services in a plmn-list different PLMN need to be discovered. It may be present when NF services in the same PLMN need to be discovered. When included, this IE shall contain the PLMN ID(s) of the requester NF. (NOTE 12)requester- array(PlmnIdNi C 1..N This IE shall be included when the Requester NF snpn-list d) belongs to one or several SNPNs, and NF services of a specific SNPN or PLMN need to be discovered. The SNPN scenarios include use cases when CH / DCS is using AAA-S or when CH / DCS is using AUSF / UDM, see clauses 5.30.2.9.2, 5.30.2.9.3 and 5.30.2.10.2.2 in 3GPP TS 23.501 [2]). It may be present when NF services from the same SNPN need to be discovered. When present, this IE shall contain the SNPN ID(s) of the requester NF. The NRF shall use this to return only those NF profiles of NF Instances allowing to be discovered from the SNPNs identified by this IE, according to the "allowedSnpns" list in the NF Profile and NF Service (see clauses 6.1.6.2.2 and 6.1.6.2.3). target-nf- NfInstanceId O 0..1 Identity of the NF instance being discovered. instance-id target-nf- array(NfInstanc O 2..N Identities of the NF instances being discovered. instance-id- eId) (NOTE 26) list If included, the NRF shall return the NF profile of each NF instance indicated in this query parameter that is available at the NRF. target-nf- Fqdn O 0..1 FQDN of the target NF instance being discovered. fqdn hnrf-uri Uri C 0..1 If included, this IE shall contain the API URI of the NFDiscovery Service (see clause 6.2.1) of the home NRF. It shall be included if the Requester NF has previously received such API URI to be used for service discovery (e.g., from the NSSF in the home PLMN as specified in clause 6.1.6.2.11 of 3GPP TS 29.531

[0042] ).snssais array(Snssai) O 1..N If included, this IE shall contain the list of S-NSSAIs that are served by the NF (Service) Instances being discovered. The NRF shall return those NF profiles / NF services of NF (Service) Instances that have at least one of the S-NSSAIs in this list. The S-NSSAIs included in the NF profiles / NF services of NF (Service) Instances returned by the NRF shall be an interclause of the S-NSSAIs requested and the S- NSSAIs supported by those NF (Service) Instances. (NOTE 10) When the NF Profile of the NF Instances being discovered has defined the list of supported S-NSSAIs in the "perPlmnSnssaiList", the discovered NF Instances shall be those having any of the S-NSSAIs included in this "snssais" parameter in any of the PLMNs included in the "target-plmn-list" attribute, if present; if the "target-plmn-list" is not included, the NRF shall assume that the discovery request is for any of the PLMNs it supports. requester- array(ExtSnssa O 1..N If included, this IE shall contain the list of S-NSSAI of snssais i) the requester NF. If this IE is included in a service discovery in a different PLMN, the requester NF shall provide S-NSSAI values of the target PLMN, that correspond to the S-NSSAI values of the requester NF. The NRF shall use this to return only those NF profiles of NF Instances allowing to be discovered from at least one network slice identified by this IE, according to the "allowedNssais" list in the NF Profile and NF Service (see clause 6.1.6.2.2 and 6.1.6.2.3). (NOTE 12) plmn- array(PlmnSns O 1..N If included, this IE shall contain the list of S-NSSAI that specific- sai) are served by the NF service being discovered for the snssai-list corresponding PLMN provided. The NRF shall use this to identify the NF services that have registered their support for the S-NSSAIs for the corresponding PLMN given. The NRF shall return the NF profiles that have at least one S-NSSAI supported in any of the PLMNs provided in this list. The per PLMN list of S-NSSAIs included in the NF profile returned by the NRF shall be an interclause of the list requested and the list registered in the NF profile. (NOTE 10).requester- array(PlmnSns O 1..N If included, this IE shall contain the list of S-NSSAI of plmn- sai) the requester NF, for each of the PLMNs it supports. specific- The NRF shall use this to return only those NF profiles snssai-list of NF Instances allowing to be discovered from at least one network slice identified by this IE, according to the "allowedNssais" and "allowedPlmns" attributes in the NF Profile and NF Service (see clause 6.1.6.2.2 and 6.1.6.2.3). (NOTE 12) nsi-list array(string) O 1..N If included, this IE shall contain the list of NSI IDs that are served by the services being discovered. dnn Dnn O 0..1 If included, this IE shall contain the DNN for which NF services serving that DNN is discovered. DNN may be included if the target NF type is e.g. "BSF", "SMF", "PCF", "PCSCF", "UPF", "EASDF", "TSCTSF", "MB- UPF" or "MB-SMF". The DNN shall contain the Network Identifier and it may additionally contain an Operator Identifier. (NOTE 11). If the Snssai(s) are also included, the NF services serving the DNN shall be available in the network slice(s) identified by the Snssai(s). ipv4-index IpIndex O 0..1 This IE may be included if the target NF type is "UPF" and the dnn IE is included. When included, this IE shall indicate the IPv4 index that is supported by the candidate UPF. ipv6-index IpIndex O 0..1 This IE may be included if the target NF type is "UPF" and the dnn IE is included. When included, this IE shall indicate the IPv6 index that is supported by the candidate UPF. smf- string O 0..1 If included, this IE shall contain the serving area of the serving- SMF. It may be included if the target NF type is "UPF". area mbsmf- string O 0..1 If included, this IE shall contain the serving area of the serving- MB-SMF. It may be included if the target NF type is area "MB-UPF". tai Tai O 0..1 Tracking Area Identity. (NOTE 22).amf-region- AmfRegionId O 0..1 AMF Region Identity. id amf-set-id AmfSetId O 0..1 AMF Set Identity. guami Guami O 0..1 Guami used to search for an appropriate AMF. (NOTE 1) supi Supi O 0..1 If included, this IE shall contain the SUPI of the requester UE to search for an appropriate NF. SUPI may be included if the target NF type is e.g. "PCF", "CHF", "AUSF", "BSF", "UDM", "TSCTSF", "NSSAAF" or "UDR". ue-ipv4- Ipv4Addr O 0..1 The IPv4 address of the UE for which a BSF or P- address CSCF or UPF needs to be discovered. (NOTE 27) ip-domain string O 0..1 The IPv4 address domain of the UE for which a BSF needs to be discovered. ue-ipv6- Ipv6Prefix O 0..1 The IPv6 prefix of the UE for which a BSF or P-CSCF prefix or UPF needs to be discovered. (NOTE 27) pgw-ind boolean O 0..1 When present, this IE indicates whether a combined SMF / PGW-C or a standalone SMF needs to be discovered. true: A combined SMF / PGW-C is requested to be discovered; false: A standalone SMF is requested to be discovered. (See NOTE 2, NOTE 21) preferred- boolean O 0..1 When present, this IE indicates whether combined pgw-ind PGW-C+SMF(s) or standalone SMF(s) are preferred. true: Combined PGW-C+SMF(s) are preferred to be discovered; false: Standalone SMF(s) are preferred to be discovered. (See NOTE 2, NOTE 20, NOTE 21) pgw Fqdn O 0..1 If included, this IE shall contain the PGW FQDN which is used by the AMF to find the combined SMF / PGW-C. pgw-ip IpAddr O 0..1 If included, this IE shall contain the PGW IP Address used by the AMF to find the combined SMF / PGW-C. gpsi Gpsi O 0..1 If included, this IE shall contain the GPSI of the requester UE to search for an appropriate NF. GPSI may be included if the target NF type is "CHF", "PCF", "BSF", "UDM", "TSCTSF" or "UDR".external- ExtGroupId O 0..1 If included, this IE shall contain the external group group- identifier of the requester UE to search for an identity appropriate NF. This may be included if the target NF type is "UDM", "UDR", "HSS" or "TSCTSF". pfd-data PfdData O 0..1 When present, this IE shall contain the application identifiers and / or application function identifiers in PFD management. This may be included if the target NF type is "NEF". The NRF shall return those NEF instances which can provide the PFDs for at least one of the provided application identifiers, or for at least one of the provided application function identifiers. data-set DataSetId O 0..1 Indicates the data set to be supported by the NF to be discovered. May be included if the target NF type is "UDR". routing- string O 0..1 Routing Indicator information that allows to route indicator network signalling with SUCI (see 3GPP TS 23.003

[0012] ) to an AUSF, AAnF and UDM instance capable to serve the subscriber. May be included if the target NF type is "AUSF", "AANF" or "UDM". Pattern: "^[0-9]{1,4}$" group-id-list array(NfGroupI O 1..N Identity of the group(s) of the NFs of the target NF type d) to be discovered. May be included if the target NF type is "UDR", "UDM", "HSS", "PCF", "AUSF", "BSF" or "CHF". dnai-list array(Dnai) O 1..N If included, this IE shall contain the Data network access identifiers. It may be included if the target NF type is "UPF", "SMF", "EASDF" or "NEF". upf-iwk- boolean O 0..1 When present, this IE indicates whether a UPF eps-ind supporting interworking with EPS needs to be discovered. true: A UPF supporting interworking with EPS is requested to be discovered; false: A UPF not supporting interworking with EPS is requested to be discovered. (NOTE 3)chf- PlmnId O 0..1 If included, this IE shall contain the PLMN ID that a supported- CHF supports (i.e., in the PlmnRange of ChfInfo plmn attribute in the NFProfile). This IE may be included when the target NF type is "CHF". When an SMF discovers CHF(s) for a PDU session, the SMF shall set the value of this IE as specified in clause 5.1.9.2 of 3GPP TS 32.255

[0046] . preferred- string O 0..1 Preferred target NF location (e.g. geographic location, locality data center). When present, the NRF shall prefer NF profiles with a locality attribute that matches the preferred-locality. The NRF may return additional NFs in the response not matching the preferred target NF location, e.g. if no NF profile is found matching the preferred target NF location. The NRF should set a lower priority for any additional NFs on the response not matching the preferred target NF location than those matching the preferred target NF location. In addition, based on operator's policy, the NRF may set different priorities based on the localities of the NFs. (NOTE 6, NOTE 25)ext- map(array(Loc O 1..N(1..M) Preferred target NF location (e.g. geographic location, preferred- alityDescription data center). locality )) The key of the map shall represent the relative priority, for the requester, of each locality description among the list of locality descriptions in this query parameter, encoded as "1" (highest priority"), "2", "3", …, "n" (lowest priority). When present, the NRF shall prefer NF profiles with an extLocality attribute that matches at least one LocalityDescription of the ext-preferred-locality, with the highest possible priority. The NRF may return additional NFs in the response not matching the preferred target NF location, e.g. if no NF profile is found matching the preferred target NF location. The NRF should set the priority of each NF profile returned in the response based on the priority associated with the matching locality description of the ext-preferred-locality. The NRF should set a lower priority for any additional NFs in the response not matching the preferred target NF location than those matching the preferred target NF location. In addition, based on operator's policy, the NRF may set different priorities based on the localities of the NFs. (NOTE 6) Example 1 indicating a preference to discover an NFp in the data center "dc-123" as a first choice, otherwise in the city of Los Angeles or San Diego as a second choice, otherwise in the state of California as a third choice. { "1": [{localityType: DATA_CENTER, localityValue: "dc- 123"}], "2": [{localityType: CITY, localityValue: "Los Angeles"}, {localityType: CITY, localityValue: "San Diego"}], "3": [{localityType: STATE, localityValue: "California"}]} Example 2 indicating a preference to discover an NFp in the data center "dc-123" as a first choice, otherwise in the data center "dc-456" or "dc-789" as a second choice. { "1": [{localityType: DATA_CENTER, localityValue: "dc- 123"}], "2": [{localityType: DATA_CENTER, localityValue: "dc- 456"}, {localityType: {DATA_CENTER, localityValue: "dc-789"}] } Example 3 indicating a preference to discover an NFp in the city of Bath and in the state of Virginia as a first choice, otherwise in the state of Virginia as a second choice. { "1": [{localityType: CITY, localityValue: "Bath", addlLocDescrItems: [{localityType: STATE, localityValue: "Virginia"}]], "2": [{localityType: STATE, localityValue: "Virginia"} } (NOTE 25) access-type AccessType C 0..1 If included, this IE shall contain the Access type which is required to be supported by the target Network Function (i.e. SMF). supported- SupportedFeat O 0..1 List of features required to be supported by the target features ures Network Function. This IE may be present only if the service-names attribute is present and if it contains a single service- name. It shall be ignored by the NRF otherwise. (NOTE 4)required- array(Supporte O 1..N List of features required to be supported by the target features dFeatures) Network Function, as defined by the supportedFeatures attribute in NFService (see clauses 6.1.6.2.3 and 6.2.6.2.4). This IE may be present only if the service-names attribute is present. When present, the required-features attribute shall contain as many entries as the number of entries in the service-names attribute. The nthentry in the required- features attribute shall correspond to the nthentry in the service-names attribute. An entry corresponding to a service for which no specific feature is required shall be encoded as "0". (NOTE 24) complex- ComplexQuery O 0..1 This query parameter is used to override the default query logical relationship of query parameters. limit integer O 0..1 Maximum number of NFProfiles to be returned in the response. Minimum: 1 max- integer O 0..1 Maximum payload size (before compression, if any) of payload- the response, expressed in kilo octets. size When present, the NRF shall limit the number of NF profiles returned in the response such as to not exceed the maximum payload size indicated in the request. Default: 124. Maximum: 2000 (i.e.2 Mo). max- integer O 0..1 Maximum payload size (before compression, if any) of payload- the response, expressed in kilo octets. size-ext When present, the NRF shall limit the number of NF profiles returned in the response such as to not exceed the maximum payload size indicated in the request. This query parameter is used when the consumer supports payload size bigger than 2 million octets. Default: 124 pdu- array(PduSessi O 1..N List of the PDU session type (s) requested to be session- onType) supported by the target Network Function (i.e UPF). types event-id-list array(EventId) O 1..N If present, this attribute shall contain the list of events requested to be supported by the Nnwdaf AnalyticsInfo Service, the NRF shall return NF which support all the requested events.nwdaf- array(NwdafEv O 1..N If present, this attribute shall contain the list of events event-list ent) requested to be supported by the Nnwdaf_EventsSubscription service, the NRF shall return NF which support all the requested events. upf-event- array(EventTyp O 1..N If present, this attribute shall contain the list of events list e) requested to be supported by the Nupf_EventExposure service. The NRF shall return UPFs which support all the requested events. atsss- AtsssCapability O 0..1 When present, this IE indicates the ATSSS capability capability of the target UPF needs to be supported. upf-ue-ip- boolean O 0..1 When present, this IE indicates whether a UPF addr-ind supporting allocating UE IP addresses / prefixes needs to be discovered. true: a UPF supporting UE IP addresses / prefixes allocation is requested to be discovered; false: a UPF not supporting UE IP addresses / prefixes allocation is requested to be discovered. client-type ExternalClientT O 0..1 When present, this IE indicates that NF(s) dedicatedly ype serving the specified Client Type needs to be discovered. This IE may be included when target NF Type is "LMF" and "GMLC". If no NF profile is found dedicately serving the requested client type, the NRF may return NF(s) not dedicatedly serving the request client type in the response. lmf-id LMFIdentificati O 0..1 When present, this IE shall contain LMF identification on to be discovered.This may be included if the target NF type is "LMF". an-node- AnNodeType O 0..1 If included, this IE shall contain the AN Node type type which is required to be supported by the target Network Function (i.e. LMF). rat-type RatType O 0..1 If included, this IE shall contain the RAT type which is required to be supported by the target Network Function (i.e. LMF).target-snpn PlmnIdNid C 0..1 This IE shall be included when NF services of a specific SNPN need to be discovered. When included, this IE shall contain the PLMN ID and NID of the target NF. This IE shall also be included in SNPN scenarios, when the entity owning the subscription, the Credentials Holder (see clause 5.30.2.9 in 3GPP TS 23.501 [2]) is an SNPN. af-ee-data AfEventExposu O 0..1 When present, this shall contain the application reData events, and optionally application function identifiers, application identifiers of the AF(s). This may be included if the target NF type is "NEF". w-agf-info WAgfInfo O 0..1 If included, this IE shall contain the W-AGF identifiers of N3 terminations which is received by the SMF to find the combined W-AGF / UPF. tngf-info TngfInfo O 0..1 If included, this IE shall contain the TNGF identifiers of N3 terminations which is received by the SMF to find the combined TNGF / UPF. twif-info TwifInfo O 0..1 If included, this IE shall contain the TWIF identifiers of N3 terminations which is received by the SMF to find the combined TWIF / UPF. target-nf- NfSetId O 0..1 When present, this IE shall contain the target NF Set set-id ID (as defined in clause 28.12 of 3GPP TS 23.003

[0012] ) of the NF instances being discovered. target-nf- NfServiceSetId O 0..1 When present, this IE shall contain the target NF service-set- Service Set ID (as defined in clause 28.13 of id 3GPP TS 23.003

[0012] ) of the NF service instances being discovered. If this IE is provided together with the target-nf-set-id IE, the NRF shall return service instances of the NF Service Set indicated in the request and should additionally return equivalent ones, if any. preferred- Tai O 0..1 When present, the NRF shall prefer NF profiles that tai can serve the TAI, or the NRF shall return NF profiles not matching the TAI if no NF profile is found matching the TAI. (NOTE 5)nef-id NefId O 0..1 When present, this IE shall contain the NEF ID of the NEF to be discovered. This may be included if the target NF type is "NEF". (NOTE 7) preferred- array(NfInstanc O 1..N When present, this IE shall contain a list of preferred nf- eId) candidate NF instance IDs. (NOTE 8) instances notification- NotificationTyp O 0..1 If included, this IE shall contain the notification type of type e default notification subscriptions that shall be registered in the NFProfile or NFService of the NF Instances being discovered. The NF profiles returned by the NRF shall contain all the registered default notification subscriptions, including the one corresponding to the notification-type parameter. (NOTE 9) n1-msg- N1MessageCla O 0..1 This IE may be included when "notification-type" IE is class ss present with value "N1_MESSAGES". When included, this IE shall contain the N1 message class of default notification subscriptions that shall be registered in the NFProfile or NFService of the NF Instances being discovered. The NF profiles returned by the NRF shall contain all the registered default notification subscriptions, including the one corresponding to the n1-msg-class parameter. (NOTE 9) n2-info- N2Information O 0..1 This IE may be included when "notification-type" IE is class Class present with value "N2_INFORMATION". If included, this IE shall contain the notification type of default notification subscriptions that shall be registered in the NFProfile or NFService of the NF Instances being discovered. The NF profiles returned by the NRF shall contain all the registered default notification subscriptions, including the one corresponding to the n2-info-class parameter. (NOTE 9)serving- array(string) O 1..N If present, this attribute shall contain the list of areas scope that can be served by the NF instances to be discovered. The NRF shall return NF profiles of NFs which can serve all the areas requested in this query parameter. (NOTE 18) imsi string O 0..1 If included, this IE shall contain the IMSI of the requester UE to search for an appropriate NF. IMSI may be included if the target NF type is "HSS". pattern: "^[0-9]{5,15}$" ims-private- string O 0..1 If included, this IE shall contain the IMS Private Identity identity of the requester UE to search for an appropriate NF. IMS Private Identity may be included if the target NF type is "HSS". ims-public- string O 0..1 If included, this IE shall contain the IMS Public Identity identity of the requester UE to search for an appropriate NF. IMS Public Identity may be included if the target NF type is "HSS". msisdn string O 0..1 If included, this IE shall contain the MSISDN of the requester UE to search for an appropriate NF. IMS Public Identity may be included if the target NF type is "HSS". internal- GroupId O 0..1 If included, this IE shall contain the internal group group- identifier of the UE to search for an appropriate NF. identity This may be included if the target NF type is "UDM", "NSSAAF" or "TSCTSF".preferred- map(string) O 1..N When present, this IE indicates the preferred API api- version of the services that are supported by the target versions NF instances. The key of the map is the ServiceName (see clause 6.1.6.3.11) for which the preferred API version is indicated. Each element carries the API Version Indication for the service indicated by the key. The NRF may return additional NFs in the response not matching the preferred API versions, e.g. if no NF profile is found matching the preferred-api-versions. An API Version Indication is a string formatted as {operator}+{API Version}. The following operators shall be supported: "=" match a version equals to the version value indicated. ">" match any version greater than the version value indicated ">=" match any version greater than or equal to the version value indicated "<" match any version less than the version value indicated "<=" match any version less than or equal to the version value indicated "^" match any version compatible with the version indicated, i.e. any version with the same major version as the version indicated. Precedence between versions is identified by comparing the Major, Minor, and Patch version fields numerically, from left to right. If no operator or an unknown operator is provided in API Version Indication, "=" operator is applied. Example of API Version Indication: Case1: "=1.2.4.operator-ext" or "1.2.4.operator-ext" means matching the service with API version "1.2.4.operator-ext"Case2: ">1.2.4" means matching the service with API versions greater than "1.2.4" Case3: "^2.3.0" or "^2" means matching the service with all API versions with major version "2". v2x- boolean O 0..1 When present, this IE indicates whether a PCF support-ind supporting V2X Policy / Parameter provisioning needs to be discovered. true: a PCF supporting V2X Policy / Parameter provisioning is requested to be discovered; false: a PCF not supporting V2X Policy / Parameter provisioning is requested to be discovered. redundant- boolean O 0..1 When present, this IE indicates whether a UPF gtpu supporting redundant GTP-U path needs to be discovered. true: a UPF supporting redundant GTP-U path is requested to be discovered; false: a UPF not supporting redundant GTP-U path is requested to be discovered. redundant- boolean O 0..1 When present, this IE indicates whether a UPF transport supporting redundant transport path on the transport layer in the corresponding network slice needs to be discovered. true: a UPF supporting redundant transport path on the transport layer is requested to be discovered; false: a UPF not supporting redundant transport path on the transport layer is requested to be discovered. If the Snssai(s) are also included, the UPF supporting redundant transport path on the transport layer shall be available in the network slice(s) identified by the Snssai(s). ipups boolean O 0..1 When present, this IE indicates whether a UPF which is configured for IPUPS is requested to be discovered. true: a UPF which is configured for IPUPS is requested to be discovered; false: a UPF which is not configured for IPUPS is requested to be discovered.sxa-ind boolean O 0..1 When present, this IE indicates whether a UPF which is configured to support Sxa interface is requested to be discovered. true: a UPF which is configured to support Sxa interface is requested to be discovered; false: a UPF which is not configured to support Sxa interface is requested to be discovered. scp- array(string) O 1..N When present, this IE shall contain the SCP domain(s) domain-list the target NF, SCP or SEPP belongs to. The NRF shall return NF, SCP or SEPP profiles that belong to all the SCP domains provided in this list. address- Fqdn O 0..1 If included, this IE shall contain the address domain domain that shall be reachable through the SCP. This IE may be included when the target NF type is "SCP". ipv4-addr Ipv4Addr O 0..1 If included, this IE shall contain the IPv4 address that shall be reachable through the SCP. This IE may be included when the target NF type is "SCP". ipv6-prefix Ipv6Prefix O 0..1 If included, this IE shall contain the IPv6 prefix that shall be reachable through the SCP. This IE may be included when the target NF type is "SCP". served-nf- NfSetId O 0..1 When present, this IE shall contain the NF Set ID that set-id shall be reachable through the SCP. This IE may be included when the target NF type is "SCP". remote- PlmnId O 0..1 If included, this IE shall contain the remote PLMN ID plmn-id that shall be reachable through the SCP or SEPP. This IE may be included when the target NF type is "SCP" or "SEPP". remote- PlmnIdNid O 0..1 If included, this IE shall contain the remote SNPN ID snpn-id that shall be reachable through the SCP or SEPP. This IE may be included when the target NF type is "SCP" or "SEPP".data- boolean O 0..1 This may be included if the target NF type is "UPF". forwarding (NOTE 13) When present, the IE indicates whether UPF(s) configured for data forwarding needs to be discovered. true: UPF(s) configured for data forwarding is requested to be discovered; false: UPF(s) not configured for data forwarding is requested to be discovered. preferred- boolean O 0..1 When present, the NRF shall prefer NF profile(s) that full-plmn can serve the full PLMN (i.e. can serve any TAI in the PLMN), or the NRF shall return other NF profiles if no NF profile serving the full PLMN is found: - true: NF instance(s) serving the full PLMN is preferred; - false: NF instance(s) serving the full PLMN is not preferred. (NOTE 14) requester- SupportedFeat C 0..1 Nnrf_NFDiscovery features supported by the features ures Requester NF that is invoking the Nnrf_NFDiscovery service. This IE shall be included if at least one of the following features is supported by the Requester NF: - Service-Map - Enh-NF-Discovery This IE may be included otherwise. realm-id string O 0..1 May be included if the target NF type is "UDSF". If included, this IE shall contain the realm-id for which a UDSF shall be discovered. storage-id string O 0..1 May be included if the target NF type is "UDSF" and realm-id is included. If included, this IE shall contain the storage-id for the realm-id indicated in the realm-id IE for which a UDSF shall be discovered.vsmf- boolean O 0..1 This IE may be included when the target NF type is support-ind "SMF". - true: Target SMF(s) supporting V-SMF are preferred to be discovered; - false: Shall be handled the same way as when this optional query parameter is not received. (NOTE 15) ismf- boolean O 0..1 This IE may be included when the target NF type is support-ind "SMF". - true: Target SMF(s) supporting I-SMF are preferred to be discovered; - false: Shall be handled the same way as when this optional query parameter is not received. (NOTE 15) nrf-disc-uri Uri C 0..1 If included, this IE shall contain the API URI of the NFDiscovery Service (see clause 6.2.1) of the NRF holding the NF Profile. It shall be included if: - the target-nf-instance-id or target-nf-instance- id-list is present; - the NF Service Consumer has previously received such API URI in an earlier NF service discovery, i.e. if the target NF instance was provided in the nfInstanceList attribute in SearchResult (see clause 6.2.6.2.2) and the nrfDiscApiUri attribute was present in the NfInstanceInfo (see clause 6.2.6.2.7); and - the service discovery request is addressed to a different NRF than the NRF holding the NF profile.preferred- map(map(array O 1..N(1..M(1.. When present, this IE indicates the list of preferred vendor- (VendorSpecifi L)) vendor-specific features supported by the target specific- cFeature))) Network Function, as defined by the features supportedVendorSpecificFeatures attribute in NFService (see clauses 6.1.6.2.3 and 6.2.6.2.4). NF profiles that support all the preferred features, or by default, NF profiles that contain at least one service supporting the preferred features, should be preferentially returned in the response; NF profiles in the response may not support the preferred features. The key of the external map is the ServiceName (see clause 6.1.6.3.11) for which the preferred vendor- specific features is indicated. Each element carries the preferred vendor-specific features for the service indicated by the key. The key of the internal map is the IANA-assigned "SMI Network Management Private Enterprise Codes"

[0038] . The string used as key of the internal map shall contain 6 decimal digits; if the SMI code has less than 6 digits, it shall be padded with leading digits "0" to complete a 6-digit string value. The value of each entry of the map shall be a list (array) of VendorSpecificFeature objects. The NF profiles returned by the NRF shall include the full list of vendor-specific-features and not just the interclause of supported and preferred vendor-specific features.preferred- map(array(Ven O 1..N(1..M) When present, this IE indicates the list of preferred vendor- dorSpecificFea vendor-specific features supported by the target specific-nf- ture)) Network Function, as defined by the features supportedVendorSpecificFeatures attribute in NF profile (see clause 6.1.6.2.2 and 6.2.6.2.3). NF profiles that support all the preferred features should be preferentially returned in the response. NF profiles in the response may not support the preferred features. The key of the map is the IANA-assigned "SMI Network Management Private Enterprise Codes"

[0038] . The value of each entry of the map shall be a list (array) of VendorSpecificFeature objects. The NF profiles returned by the NRF shall include the full list of vendor-specific features and not just the interclause of supported and preferred vendor-specific features. required- string O 0..1 List of features required to be supported by the target pfcp- UPF or MB-UPF (when selecting a UPF or a MB-UPF), features encoded as defined for the supportedPfcpFeatures attribute in UpfInfo (see clause 6.1.6.2.13). (NOTE 16) home-pub- integer O 0..1 When present, this IE shall indicate the Home Network key-id Public Key ID which shall be able to be served by the NF instance. May be included if the target NF type is "AUSF" or "UDM". This query parameter may only be present if the routing-indicator query parameter is also present. (NOTE 17) prose- boolean O 0..1 When present, this IE indicates whether supporting support-ind ProSe capability by PCF needs to be discovered. - true: a PCF supporting ProSe capability is requested to be discovered; - false: a PCF not supporting ProSe capability is requested to be discovered.analytics- boolean O 0..1 This IE may be included when the target NF type is aggregation "NWDAF". -ind - true: An NF supporting analytics aggregation capability is requested to be discovered; - false: Shall be handled the same way as when this optional query parameter is not received. analytics- boolean O 0..1 This IE may be included when the target NF type is metadata- "NWDAF". prov-ind - true: An NF supporting analytics metadata provisioning capability is requested to be discovered; - false: Shall be handled the same way as when this optional query parameter is not received. serving-nf- NfSetId O 0..1 When present, this IE shall contain the NF Set ID that set-id is served by the DCCF, NWDAF or MFAF. This IE may be included when the target NF type is "DCCF" or "NWDAF" or "MFAF". serving-nf- NFType O 0..1 When present, this IE shall contain the NF type that is type served by the DCCF, NWDAF or MFAF. This IE may be included when the target NF type is "DCCF" or "NWDAF" or "MFAF". ml- array(MlAnalyti O 1..N If present, this attribute shall contain the list of ML analytics- csInfo) Analytics Filter information per Analytics ID(s) info-list requested to be supported by the Nnwdaf_MLModelProvision Service. The NRF shall return NWDAF profiles that support at least one of the MlAnalyticsInfo in this list. nsacf- NsacfCapabilit O 0..1 When present, this IE indicates the service capability capability y that the target NSACF needs to support.mbs- array(MbsSess O 0..1 This IE may be present if the target NF type is "MB- session-id- ionId) SMF". list When present, it shall contain the list of MBS Session ID(s) for which MB-SMF(s) are to be discovered. When present, for each mbs-session-id in the list, the NRF shall determine whether an MB-SMF supporting the mbs-session-id and complying with the other query parameters (if any) exists. An MB-SMF shall be considered to support the mbs-session-id if: - the mbs-session-id contains a TMGI that is part of a TMGI range (see tmgiRangeList attribute in clause 6.1.6.2.85) registered by the MB-SMF and, if the tai query parameter is present: - if the TAI indicated in the tai query parameter can be served by the MB-SMF (see taiList and taiRangeList attributes in clause 6.1.6.2.85); or - the mbs-session-id contains a TMGI or an SSM address, that is part of the list of MBS sessions currently served by the MB-SMF (see mbsSessionList attribute in clause 6.1.6.2.85) and, if the tai query parameter is present and the MBS session is registered with an MBS Service Area (see mbsServiceArea in clause 6.1.6.2.90): - if the TAI indicated in the tai query parameter is supported by the MBS Service Area of the MBS session. If so, the NRF shall return the profile of this MB-SMF. If no MB-SMF supporting the mbs-session-id and complying with the other query parameters exists, the NRF shall return an empty response. See clause 7.1.2 of 3GPP TS 23.247

[0043] .area- AreaSessionId O 0..1 This IE may be present if the target NF type is "MB- session-id SMF", the mbs-session-id-list IE is present and contains only one MBS Session ID. When present, the IE shall contain the Area Session ID, for the MBS session indicated in the mbs-session- id-list IE, for which an MB-SMF is to be discovered. When this IE is present, the NRF shall return an MB- SMF profile that currently serves the MBS Session ID and Area Session ID (see mbsSessionList attribute in clause 6.1.6.2.85). If no MB-SMF supports the MBS Session ID and Area Session ID, the NRF shall return an empty response. See clause 7.1.2 of 3GPP TS 23.247

[0043] . gmlc- string O 0..1 If included, this IE shall contain the GMLC Number of number which should supported by the target GMLC. It may be included if the target NF type is "GMLC". Pattern: "^[0-9]{5,15}$" upf-n6-ip IpAddr O 0..1 If included, this IE shall contain the N6 IP address of PSA UPF. It may be included if the target NF type is "EASDF". tai-list array(Tai) O 1..N If included, this IE shall contain the Tracking Area Identities requested to be supported by the NFs being discovered. The NRF shall return NFs which support all the TAIs in the list. It may be included if the target NF type is "NEF" or "MB-SMF".preferences array(string) O 2..N This IE may be present when multiple query - parameters expressing a preference are included in precedence the discovery request. When present, this IE shall indicate the relative precedence of these query parameters (from higher precedence to lower precedence). The NRF shall use the indicated precedence to prioritize the candidate NFs in the search result, among the candidate NFs partially matching the different preference query parameters, candidate matching the higher precedence preference query parameter should have higher priority. This IE may include any query parameter named "preferred-xxx" or "ext-preferred-xxx" (e.g. preferred- locality, preferred-tai). Example: preferences-precedence=[preferred-tai, preferred- vendor-specific-features] The above value indicates that the "preferred-tai" parameter has higher precedence than the "preferred- vendor-specific-features" parameter. support- boolean O 0..1 If present, this attribute indicates the target AMF or onboarding- SMF instances support SNPN Onboarding. If the capability target is an SMF, this indicates the SMF also supports User Plane Remote Provisioning. This is used for the case of Onboarding of UEs for SNPNs (see 3GPP TS 23.501 [2], clauses 5.30.2.10 and 6.2.6.2). - true: An NF supporting SNPN Onboarding is requested to be discovered; - false: Shall be handled the same way as when this optional query parameter is not received.uas-nf- boolean O 0..1 This IE may be included when the target NF type is functionality "NEF". -ind - true: An NF supporting UAS NF functionality is requested to be discovered; - false: Shall be handled the same way as when this optional query parameter is not received. v2x- V2xCapability O 0..1 When present, this IE indicates the V2X capability that capability the target PCF needs to support. When the v2x-capability is provided as the query parameter, NRF shall return the PCF instances which support all the V2X capabilities requested. prose- ProSeCapabilit O 0..1 When present, this IE indicates the ProSe capability capability y that the target PCF needs to support. When the prose-capability is provided as the query parameter, NRF shall return the PCF instances which support all the ProSe capabilities requested. shared- SharedDataId O 0..1 Identifies the shared data that is stored in the NF data-id (UDR) to be discovered. May be included if the target NF type is "UDR" target-hni Fqdn O 0..1 If included, this IE shall contain the Home Network Identifier. If CH / DCS is using AAA Server or AUSF and UDM for primary authentication and authorization (see clauses 5.30.2.9.2, 5.30.2.9.3 and 5.30.2.10.2.2 in 3GPP TS 23.501 [2]), the sender (AMF or AUSF) populates this IE with CH / DCS ID. See also clauses 4.17.4a and 4.17.5a in TS 23.502 [3]. If the target NF is AUSF or NSSAAF and the HNI belongs to a CH / DCS with AAA Server in another domain, i.e. not in this SNPN, the NRF returns back the AUSF or NSSAAF in the same SNPN, based on the NF profile as specified in clause 6.2.6.2 in 3GPP TS 23.501 [2].target-nw- boolean O 0..1 If included and set to true, the NRF shall determine the resolution identity of the target PLMN to which the NFDiscovery request shall be directed, based on the MSISDN of the UE included in the "gpsi" query parameter, as described in 3GPP TS 23.540

[0048] . If included and set to false, this IE shall be ignored. exclude- array(NfInstanc O 1..N If included, this IE shall indicate the list of NF instances nfinst-list eId) that should not be returned in the NF Discovery response. (NOTE 23) exclude- array(NfServic O 1..N If included, this IE shall indicate the list of NF service nfservinst- eInstance) instances that should not be returned in the NF list Discovery response. (NOTE 23) exclude- array(NfServic O 1..N If included, this IE shall indicate the list of NF service nfserviceset eSetId) sets of NF service instances that should not be -list returned in the NF Discovery response. (NOTE 23) exclude- array(NfSetId) O 1..N If included, this IE shall indicate the list of NF sets of nfset-list NF instances that should not be returned in the NF Discovery response. (NOTE 23) preferred- map(DurationS O 1..N If included, this IE shall contain the preferred Analytics analytics- ec) Delay. The key of the map is the EventId or delays NwdafEvent (as defined in 3GPP TS 29.520

[0033] ) for which the preferred Analytics Delay is related to. Each element carries the preferred Analytics Delay for the Analytics ID indicated by the key. The NRF shall return the NWDAFs supports the Analytics ID with a supported Analytics Delay that is less than or equal to the preferred Analytics Delay, as described in clause 6.3.13 of 3GPP TS 23.501 [2]. The NRF may return NWDAFs in the response not matching the preferred Analytics Delay, e.g. if no NWDAF profile is found matching the preferred Analytics Delay.high- boolean O 0..1 If present and set to true, this attribute indicates target latency- AMF(s) instances supporting High Latency com communication (e.g. for NR RedCap UE) are required. This is used by CP NF to discover AMF supporting High Latency communication (see 3GPP TS 23.501 [2], clause 6.3.5). Presence of this IE with false value shall be prohibited. complete- boolean O 0..1 This IE may be included by an SCP with the value true profile to request to discover the complete profile of NF Instances (including authorization attributes such as the "allowedXXX" attributes of NFProfile and NFService data types) matching the query parameters. See clause 5.3.2.2.2. Presence of this IE with false value shall be prohibited. n32- array(N32Purp O 1..N This IE may be included when the target NF type is purposes ose) "SEPP". When present, this IE shall indicate the requested N32 purposes to be supported by the SEPP. The NRF shall return SEPP profiles that support at least one requested N32 purpose. preferred- map(Supported O 1..N List of features preferred to be supported by the target features Features) Network Function, as defined by the supportedFeatures attribute in NFService (see clauses 6.1.6.2.3 and 6.2.6.2.4). The key of the map is the Service Name as specified in clause 6.1.6.3.11. Each element carries the preferred feature(s) to be supported by the target Network Function for the indicated service. The NRF shall priorize the NF candidates supporting the preferred features in the search result. (NOTE 24)remote- PlmnId O 0..1 If included, this IE shall indicate the remote PLMN that plmn-id- the target NF service producer can serve, i.e. the NF roaming service producer can serve the roaming UEs which belong to the indicated remote PLMN. This IE may be included when the target NF type is "SMSF". The NRF shall return the candidate NF service producer(s) in discovery result with the following order of preference: - NF profiles explicitly indicated the support of roaming UE for the requested remote PLMN; then - NF profiles indicated the support of roaming UE for any remote PLMN; then - if none of above are available, NF profiles without indication of roaming UE support.TABLE 4 (TS 29.5106.2.6.2.3-1: Definition of type NFProfile) (profile in response message / search result)Attribute name Data type P Cardinality Description nfInstanceId NfInstanceId M 1 Unique identity of the NF Instance. nfType NFType M 1 Type of Network Function nfStatus NFStatus M 1 Status of the NF Instance collocatedNfInstances array(Collocated O 1..N Information related collocated NF type(s) and NfInstance) corresponding NF Instance(s) when the NF is collocated with NFs supporting other NF types nfInstanceName string O 0..1 Human readable name of the NF Instance plmnList array(PlmnId) C 1..N PLMN(s) of the Network Function (NOTE 5). This IE shall be present if this information is available for the NF. If neither the plmnList IE nor the snpnList IE were provided by the NF during registration, the NRF should return the list of PLMN ID(s) of the PLMN of the NRF. If both the plmnList IE and the snpnList IE are absent in the response, PLMN ID(s) of the PLMN of the NRF are assumed for the NF. sNssais array(ExtSnssai) O 1..N S-NSSAIs of the Network Function. If not provided, and if the perPlmnSnssaiList attribute is not present, the NF can serve any S-NSSAI. If the sNSSAIs attribute is provided in at least one NF Service, the sNssais attribute in the NF Profile shall be present and be the set or a superset of the sNSSAIs of the NFService(s). perPlmnSnssaiList array(PlmnSnssai O 1..N The per-PLMN list of S-NSSAI(s) supported by the ) Network Function. If the perPlmnSnssaiList attribute is provided in at least one NF Service, the perPlmnSnssaiList attribute in the NF Profile shall be present and be the set or a superset of the perPlmnSnssaiList of the NFService(s). nsiList array(string) O 1..N List of NSIs of the Network Function. If not provided, the NF can serve any NSI. fqdn Fqdn C 0..1 FQDN of the Network Function (NOTE 1, NOTE 3, NOTE 11)interPlmnFqdn Fqdn C 0..1 If the requester-plmn-list query parameter is absent in the NF Discovery request, or if is present and the requester's PLMN is the same as the PLMN of the discovered NF, then this attribute shall be included by the NRF and it shall contain the interPlmnFqdn value registered by the NF during NF registration (see clause 6.1.6.2.2), if the interPlmnFqdn attribute was registered in the NF profile. This attribute shall be absent if the requester-plmn in the query parameter is different from the PLMN of the discovered NF. (NOTE 3, NOTE 14) ipv4Addresses array(Ipv4Addr) C 1..N IPv4 address(es) of the Network Function (NOTE 1, NOTE 11) ipv6Addresses array(Ipv6Addr) C 1..N IPv6 address(es) of the Network Function (NOTE 1, NOTE 11) allowedPlmns array(PlmnId) C 1..N PLMNs allowed to access the NF instance. This attribute may be present in a complete NF profile (i.e. in the completeNfInstances IE in the SearchResult or StoredSearchResult data types). It shall not be present otherwise. If not provided, any PLMN is allowed to access the NF.allowedSnpns array(PlmnIdNid) C 1..N SNPNs allowed to access the NF instance. This attribute may be present in a complete NF profile (i.e. in the completeNfInstances IE in the SearchResult or StoredSearchResult data types). It shall not be present otherwise. If this attribute is present in the NFService and in the NF profile, the attribute from the NFService shall prevail. The absence of this attribute in both the NFService and in the NF profile indicates that no SNPN, other than the SNPN(s) registered in the snpnList attribute of the NF Profile (if the NF pertains to an SNPN), is allowed to access the service instance. allowedNfTypes array(NFType) C 1..N Type of the NFs allowed to access the NF instance. This attribute may be present in a complete NF profile (i.e. in the completeNfInstances IE in the SearchResult or StoredSearchResult data types). It shall not be present otherwise. If not provided, any NF type is allowed to access the NF. allowedNfDomains array(string) C 1..N Pattern (regular expression according to the ECMA- 262 dialect [8]) representing the NF domain names within the PLMN of the NRF allowed to access the NF instance. This attribute may be present in a complete NF profile (i.e. in the completeNfInstances IE in the SearchResult or StoredSearchResult data types). It shall not be present otherwise. If not provided, any NF domain is allowed to access the NF.allowedNssais array(ExtSnssai) C 1..N S-NSSAI of the allowed slices to access the NF instance. This attribute may be present in a complete NF profile (i.e. in the completeNfInstances IE in the SearchResult or StoredSearchResult data types). It shall not be present otherwise. If not provided, any slice is allowed to access the NF. capacity integer O 0..1 Static capacity information within the range 0 to 65535, expressed as a weight relative to other NF instances of the same type; if capacity is also present in the nfServiceList parameters, those will have precedence over this value. (See NOTE 2) load integer O 0..1 Latest known load information of the NF within the range 0 to 100 in percentage (See NOTE 4) loadTimeStamp DateTime O 0..1 It indicates the point in time in which the latest load information of the NF Instance was sent from the NF to the NRF. locality string O 0..1 Operator defined information about the location of the NF instance (e.g. geographic location, data center) extLocality map(string) O 1..N Operator defined information about the location of the NF instance. (NOTE 3) The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters, representing a type of locality as defined in clause 6.1.6.3.x. Example: { "DATA_CENTER": "dc-123", "CITY": "Los Angeles", "STATE": "California" }priority integer O 0..1 Priority (relative to other NFs of the same type) within the range 0 to 65535, to be used for NF selection; lower values indicate a higher priority. Priority may or may not be present in the nfServiceList parameters, xxxInfo parameters and in this attribute. Priority in the nfServiceList has precedence over the priority in this attribute. (NOTE 2) Priority in xxxInfo parameter shall only be used to determine the relative priority among NF instances with the same priority at NFProfile / NFService. udrInfo UdrInfo O 0..1 Specific data for the UDR (ranges of SUPI, …) udrInfoList map(UdrInfo) O 1..N Multiple entries of UdrInfo. This attribute provides additional information to the udrInfo. udrInfoList may be present even if the udrInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. udmInfo UdmInfo O 0..1 Specific data for the UDM udmInfoList map(UdmInfo) O 1..N Multiple entries of UdmInfo. This attribute provides additional information to the udmInfo. udmInfoList may be present even if the udmInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. ausfInfo AusfInfo O 0..1 Specific data for the AUSF ausfInfoList map(AusfInfo) O 1..N Multiple entries of AusfInfo. This attribute provides additional information to the ausfInfo. ausfInfoList may be present even if the ausfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. amfInfo AmfInfo O 0..1 Specific data for the AMF (AMF Set ID, …) amfInfoList map(AmfInfo) O 1..N Multiple entries of AmfInfo. This attribute provides additional information to the amfInfo. amfInfoList may be present even if the amfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters.smfInfo SmfInfo O 0..1 Specific data for the SMF (DNN's, …). (NOTE 8) smfInfoList map(SmfInfo) O 1..N Multiple entries of SmfInfo. This attribute provides additional information to the smfInfo. smfInfoList may be present even if the smfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. (NOTE 8) upfInfo UpfInfo O 0..1 Specific data for the UPF (S-NSSAI, DNN, SMF serving area, …) upfInfoList map(UpfInfo) O 1..N Multiple entries of UpfInfo. This attribute provides additional information to the upfInfo. upfInfoList may be present even if the upfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. pcfInfo PcfInfo O 0..1 Specific data for the PCF pcfInfoList map(PcfInfo) O 1..N Multiple entries of PcfInfo. This attribute provides additional information to the pcfInfo. pcfInfoList may be present even if the pcfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. bsfInfo BsfInfo O 0..1 Specific data for the BSF bsfInfoList map(BsfInfo) O 1..N Multiple entries of BsfInfo. This attribute provides additional information to the bsfInfo. bsfInfoList may be present even if the bsfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. chfInfo ChfInfo O 0..1 Specific data for the CHF chfInfoList map(ChfInfo) O 1..N Multiple entries of ChfInfo. This attribute provides additional information to the chfInfo. chfInfoList may be present even if the chfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. udsfInfo UdsfInfo O 0..1 Specific data for the UDSFudsfInfoList map(UdsfInfo) O 1..N Multiple entries of udsfInfo. This attribute provides additional information to the udsfInfo. udsfInfoList may be present even if the udsfInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. nefInfo NefInfo O 0..1 Specific data for the NEF nwdafInfo NwdafInfo O 0..1 Specific data for the NWDAF nwdafInfoList map(NwdafInfo) O 1..N Multiple entries of nwdafInfo. This attribute provides additional information to the nwdafInfo. nwdafInfoList may be present even if the nwdafInfo is absent. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. pcscfInfoList map(PcscfInfo) O 1..N Specific data for the P-CSCF. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. (NOTE 7) hssInfoList map(HssInfo) O 1..N Specific data for the HSS. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. customInfo object O 0..1 Specific data for custom Network Functions recoveryTime DateTime O 0..1 Timestamp when the NF was (re)started nfServicePersistence boolean O 0..1 - true: If present, and set to true, it indicates that the different service instances of a same NF Service in the NF instance, supporting a same API version, are capable to persist their resource state in shared storage and therefore these resources are available after a new NF service instance supporting the same API version is selected by a NF Service Consumer (see 3GPP TS 23.527

[0027] ). - false (default): Otherwise, it indicates that the NF Service Instances of a same NF Service are not capable to share resource state inside the NF Instance.nfServices array(NFService) O 1..N List of NF Service Instances. (NOTE 10) This attribute is deprecated; the attribute "nfServiceList" should be used instead. nfServiceList map(NFService) O 1..N Map of NF Service Instances, where the "serviceInstanceId" attribute of the NFService object shall be used as the key of the map. (NOTE 10) defaultNotificationSubsc array(DefaultNotif O 1..N Notification endpoints for different notification types. riptions icationSubscriptio (NOTE 6) n) (See also NOTE 10 in clause 6.1.6.2.2) lmfInfo LmfInfo O 0..1 Specific data for the LMF gmlcInfo GmlcInfo O 0..1 Specific data for the GMLC snpnList array(PlmnIdNid) C 1..N SNPN(s) of the Network Function. This IE shall be present if the NF pertains to one or more SNPNs. nfSetIdList array(NfSetId) C 1..N NF Set ID defined in clause 28.12 of 3GPP TS 23.003

[0012] . At most one NF Set ID shall be indicated per PLMN- ID or SNPN of the NF. At most one combination of an AMF region and an AMF Set ID shall be indicated per PLMN-ID or SNPN in an AMF profile. This information shall be present if available. servingScope array(string) O 1..N The served area(s) of the NF instance. The absence of this attribute does not imply the NF instance can serve every area. lcHSupportInd boolean O 0..1 This IE indicates whether the NF supports Load Control based on LCI Header (see clause 6.3 of 3GPP TS 29.500 [4]). - true: the NF supports the feature. - false (default): the NF does not support the feature. olcHSupportInd boolean O 0..1 This IE indicates whether the NF supports Overload Control based on OCI Header (see clause 6.4 of 3GPP TS 29.500 [4]). - true: the NF supports the feature. - false (default): the NF does not support the feature.nfSetRecoveryTimeList map(DateTime) O 1..N Map of recovery time, where the key of the map is the NfSetId of NF Set(s) that the NF instance belongs to. When present, the value of each entry of the map shall be the recovery time of the NF Set indicated by the key. serviceSetRecoveryTim map(DateTime) O 1..N Map of recovery time, where the key of the map is eList the NfServiceSetId of the NF Service Set(s) configured in the NF instance. When present, the value of each entry of the map shall be the recovery time of the NF Service Set indicated by the key. scpDomains array(string) O 1..N When present, this IE shall carry the list of SCP domains the SCP belongs to, or the SCP domain the NF (other than SCP) or the SEPP belongs to. (NOTE 9) scpInfo ScpInfo O 0..1 Specific data for the SCP. seppInfo SeppInfo O 0..1 Specific data for the SEPP. vendorId VendorId O 0..1 Vendor ID of the NF instance, according to the IANA-assigned "SMI Network Management Private Enterprise Codes"

[0038] . supportedVendorSpecifi map(array(Vendo O 1..N(1..M) Map of Vendor-Specific features, where the key of cFeatures rSpecificFeature) the map is the IANA-assigned "SMI Network ) Management Private Enterprise Codes"

[0038] . The string used as key of the map shall contain 6 decimal digits; if the SMI code has less than 6 digits, it shall be padded with leading digits "0" to complete a 6- digit string value. The value of each entry of the map shall be a list (array) of VendorSpecificFeature objects. (NOTE 12) aanfInfoList map(AanfInfo) O 1..N Specific data for the AAnF. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. mfafInfo MfafInfo O 0..1 Specific data for the MFAF.easdfInfoList map(EasdfInfo) O 1..N Specific data for the EASDF. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. (NOTE 13) dccfInfo DccfInfo O 0..1 Specific data for the DCCF. nsacfInfoList map(NsacfInfo) O 1..N Specific data for the NSACF. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. mbSmfInfoList map(MbSmfInfo) O 1..N MB-SMF specific data. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. tsctsfInfoList map(TsctsfInfo) O 1..N Specific data for the TSCTSF. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. mbUpfInfoList map(MbUpfInfo) O 1..N MB-UPF specific data. The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259

[0022] , with a maximum of 32 characters. trustAfInfo TrustAfInfo O 0..1 Specific data for the trusted AF. nssaafInfo NssaafInfo O 0..1 Specific data for the NSSAAF. hniList arrary(Fqdn) C 1..N Identifications of Credentials Holder or Default Credentials Server. This IE shall be present if the NFs are available for the case of access to an SNPN using credentials owned by a Credentials Holder or for the case of SNPN Onboarding using a DCS. iwmscInfo IwmscInfo O 0..1 Specific data for the SMS-IWMSC. mnpfInfo MnpfInfo O 0..1 Specific data for the MNPF. smsfInfo SmsfInfo O 0..1 Specific data for the SMSF.NOTE 1: At least one of the addressing parameters (fqdn, ipv4address or ipv6adress) shall be included in the NF Profile. See NOTE 1 of Table 6.2.6.2.4-1 for the use of these parameters. If multiple ipv4 addresses and / or ipv6 addresses are included in the NF Profile, the NF Service Consumer shall select one of these addresses randomly, unless operator defined local policy of IP address selection, in order to avoid overload for a specific ipv4 address and / or ipv6 address. NOTE 2: The capacity and priority parameters, if present, are used for NF selection and load balancing. The priority and capacity attributes shall be used for NF selection in the same way that priority and weight are used for server selection as defined in IETF RFC 2782

[0023] . NOTE 3: If the requester-plmn in the query parameter is different from the PLMN of the discovered NF, then the fqdn attribute value shall contain the interPlmnFqdn value registered by the NF during NF registration (see clause 6.1.6.2.2). The requester-plmn is different from the PLMN of the discovered NF if it belongs to none of the PLMN ID(s) configured for the PLMN of the NRF. NOTE 4: The usage of the load parameter by the NF service consumer is implementation specific, e.g. be used for NF selection and load balancing, together with other parameters. NOTE 5: An NF may register multiple PLMN IDs in its profile within a PLMN comprising multiple PLMN IDs. If so, all the attributes of the NF Profile shall apply to each PLMN ID registered in the plmnList. As an exception, attributes including a PLMN ID, e.g. IMSI-based SUPI ranges, TAIs and GUAMIs, are specific to one PLMN ID and the NF may register in its profile multiple occurrences of such attributes for different PLMN IDs (e.g. the UDM may register in its profile SUPI ranges for different PLMN IDs). NOTE 6: For notification types that may be associated with a specifc service of the NF Instance receiving the notification (see clause 6.1.6.3.4), if notification endpoints are present both in the profile of the NF instance (NFProfile) and in some of its NF Services (NFService) for a same notification type, the notification endpoint(s) of the NF Services shall be used for this notification type. NOTE 7: The absence of the pcscfInfoList attribute in a P-CSCF profile indicates that the P-CSCF can be selected for any DNN and Access Type, and that the P-CSCF Gm addressing information is the same as the addressing information registered in the fqdn, ipv4Addresses and ipv4Addresses attributes of the NF profile. NOTE 8: The absence of both the smfInfo and smfInfoList attributes in an SMF profile indicates that the SMF can be selected for any S-NSSAI listed in the sNssais and perPlmnSnssaiList IEs, or for any S-NSSAI if neither the sNssais IE nor the perPlmnSnssaiList IE are present, and for any DNN, TAI and access type. NOTE 9: If an NF (other than a SCP or SEPP) includes this information in its profile, this indicates that the services produced by this NF should be accessed preferably via an SCP from the SCP domain the NF belongs to. NOTE 10: If the NF Service Consumer that issued the discovery request indicated support for the "Service-Map" feature, the NRF shall return in the discovery response the list of NF Service Instances in the "nfServiceList" map attribute. Otherwise, the NRF shall return the list of NF Service Instances in the "nfServices" array attribute. NOTE 11: For API URIs constructed with an FQDN, the NF Service Consumer may use the FQDN of the target URI to do a DNS query and obtain the IP address(es) to setup the TCP connection, and ignore the IP addresses that may be present in the NFProfile; alternatively, the NF Service Consumer may use those IP addresses to setup the TCP connection, if no service-specific FQDN or IP address is provided in the NFService dataand if the NF Service Consumer supports to indicate specific IP address(es) to establish an HTTP / 2 connection with an FQDN in the target URI. NOTE 12: When present, this attribute allows an NF requesting NF Discovery (e.g. an NF Service Consumer) to determine which vendor-specific extensions are supported in a given NF (e.g. an NF Service Producer), so as to select an appropriate NF with specific capability, or to include or not the vendor-specific attributes (see 3GPP TS 29.500 [4] clause 6.6.3) required for a given feature in subsequent messages towards a certain NF. One given vendor-specific feature shall not appear in both NF Profile and NF Service Profile. If one vendor-specific feature is service related, it shall only be included in the NF Service Profile. NOTE 13: The absence of the easdfnfoList attributes in an EASDF profile indicates that the EASDF can be selected for any S-NSSAI, DNN, DNAI or PSA UPF N6 IP address. NOTE 14: This attribute may be used by the requester NF or SCP e.g. to build the authority of the Location header in 3xx response or to set the 3gpp-Sbi-apiRoot header in a response message (see clause 6.10.4 of 3GPP TS 29.500 [4]), when the NF redirects a request issued by a consumer from a different PLMN towards the discovered NF, or when the SCP has reselected the discovered NF for such a request.TABLE 5 (TS 29.503 - 6.1.6.2.4-1: Definition of type AccessAndMobilitySubscriptionData)Attribute name Data type P Cardinality Description supportedFeatures SupportedFeatur O 0..1 See clause 6.1.8 es gpsis array(Gpsi) O 0..N List of Generic Public Subscription Identifier; see 3GPP TS 29.571 [7] internalGroupIds array(GroupId) O 1..N List of internal group identifier; see 3GPP TS 23.501 [2] clause 5.9.7 sharedVnGroupDataId map(SharedDataI O 1..N A map of identifiers of shared 5G VN group data (list s d) of key-value pairs whereGroupId serves as key; see clause 6.1.6.1). This attribute is only applicable to the Nudm interface and shall not be included over the Nudr interface. hssGroupId NfGroupId O 0..1 Identity of the HSS group associated with the subscription, which may be used by the UDM in discovering the HSS; see 3GPP TS 29.510

[0019] . This attribute may be included if the coreNetworkTypeRestrictions does not indicate a value of "EPC". This attribute is only applicable to the Nudr interface and shall not be included over the Nudm interface. subscribedUeAmbr AmbrRm O 0..1 nssai Nssai O 0..1 Network Slice Selection Assistance Information ratRestrictions array(RatType) O 0..N List of RAT Types that are restricted in 5GC and EPC; see 3GPP TS 29.571 [7] (NOTE 2) Contains unique items forbiddenAreas array(Area) O 0..N List of forbidden areas in 5GS (NOTE 6, NOTE 7) serviceAreaRestriction ServiceAreaRestr O 0..1 Subscribed Service Area Restriction (NOTE 7) iction coreNetworkTypeRestr array(CoreNetwo O 0..N List of Core Network Types that are restricted. ictions rkType) The use of the value "5GC" is deprecated on Nudm and shall be discarded by the receiving AMF. accessTypeRestriction array(AccessTyp O 0..2 List of Access Types that are restricted. s e) If non-3GPP access is restricted, then the UDM shall reject / deregister the AMF non-3GPP registration. If 3GPP access is restricted, then the UDM shall reject / deregister the AMF 3GPP registration. Otherwise, the UDM shall pass the IE to the AMF. rfspIndex RfspIndexRm O 0..1 Index to RAT / Frequency Selection Priority;subsRegTimer DurationSecRm O 0..1 Subscribed periodic registration timer; (see clause 5.20 of 3GPP TS 23.501 [2], clause 4.15.3.2.3b and 4.15.6.3a of 3GPP TS 23.502 [3] and 3GPP TS 29.571 [7]) ueUsageType UeUsageType O 0..1 mpsPriority MpsPriorityIndica O 0..1 tor mcsPriority McsPriorityIndicat O 0..1 or activeTime DurationSecRm O 0..1 subscribed active time for PSM UEs (see clause 5.20 of 3GPP TS 23.501 [2] and clause 4.15.3.2.3b and 4.15.6.3a of 3GPP TS 23.502 [3]). sorInfo SorInfo O 0..1 On Nudm, this IE shall be present if the UDM shall send the information for Steering of Roaming during registration or the subscription data update to the UE. The UDM may detect the need to send sorInfo by retrieving context information from the UDR. (NOTE 4)sorInfoExpectInd Boolean C 0..1 Contains the indication on whether or not the UE is expecting to receive SoR information at initial registration. - When set to true; it indicates that the UE is expecting to receive SoR information at initial registration in a VPLMN, i.e. the UDM shall send SoR information to the AMF on Nudm even when nothing was received from UDR or SOR-AF. In case the UDM was not able to obtain SoR information, SoR information sent on Nudm shall contain the indication that "no change" is needed. - When set to false: it indicates that the UE is not expecting to receive SoR information at initial registration, i.e. the UDM shall send SoR information to the AMF based on operator policy. This attribute may be present on Nudr interface and shall be absent on UDM interface. The UDM shall ignore this attribute if the UE is not roaming out of its HPLMN. sorafRetrieval boolean C 0..1 Contains the indication on whether or not SoR information shall be retrieved from the SOR-AF. - When set to true: it indicates that the UDM shall retrieve SoR information from the SOR-AF. - When set to false or absent: it indicates that the retrieval of SorInfo from the SOR-AF is not required. This attribute may be present on Nudr interface and shall be absent on Nudm interface. The UDM shall ignore this attribute if it is received in Nudr but the UE is not roaming out of its HPLMN.sorUpdateIndicatorList array(SorUpdateI C 1..N When present, it contains the list of SoR Update ndicator) Indicators; - It shall indicate that the AMF shall retrieve SoR information when the UE performs Registration with NAS Registration Type "Initial Registration" if the value "INITIAL_REGISTRATION" is included; - And / or it shall indicate that the AMF shall retrieve SoR information when the UE performs Registration with NAS Registration Type "Emergency Registration" if the value "EMERGENCY_REGISTRATION" is included. When absent on Nudm interface, it indicates that the AMF is not requested to retrieve SoR information when the UE performs Registration with either NAS Registration Type "Initial Registration" or NAS Registration Type "Emergency Registration". The UDM shall ignore this attribute if the UE is not roaming out of its HPLMN. upuInfo UpuInfo O 0..1 This IE shall be present if the UDM shall send the information for UE Parameters Update after the UE has been successfully authenticated and registered to the 5G system. routingIndicator string O 0..1 This IE may be sent in Nudm_SDM notification as defined in 3GPP TS 23.502 Clause 4.20.2, if UE Parameter Update was sent for Routing Indicator Update, but without requesting the UE to re-register. micoAllowed MicoAllowed O 0..1 Indicates whether the UE subscription allows MICO mode. sharedAmDataIds array(SharedDat O 0..N Identifier of shared Access And Mobility Subscription aId) data odbPacketServices OdbPacketServic O 0..1 Operator Determined Barring for Packet Oriented es Services (NOTE 3).subscribedDnnList array(Dnn) O 0..N List of the subscribed DNNs for the UE (including optionally the Wildcard DNN). Used to determine the list of LADN available to the UE as defined in clause 5.6.5 of TS 23.501 [2]. When present, this IE shall contain the Network Identifier only. serviceGapTime DurationSec O 0..1 Used to set the Service Gap timer for Service Gap Control (see TS 23.501 [2] clause 5.26.16 and TS 23.502 [3] clause 4.2.2.2.2). mdtUserConsent MdtUserConsent O 0..1 When present, this IE shall indicate whether the user has given his consent for MDT activation or not (see clause 4.9 of 3GPP TS 32.422

[0048] ). When absent, "CONSENT_NOT_GIVEN" is the default value. mdtConfiguration MdtConfiguration C 0..1 This IE shall be present if the MDT task is activated. When present, this IE shall contain MDT configuration data for UE (see clause 4.1.2.17 of 3GPP TS 32.422

[0048] ). traceData TraceData O 0..1 Trace requirements about the UE, only sent to AMF in the HPLMN or one of its equivalent PLMN(s) cagData CagData O 0..1 Closed Access Group Data. Shall be absent if both - no CAG is subscribed for the serving PLMN and - an acknowledgement from the UE is not pending. stnSr StnSr O 0..1 This IE shall be present if the UE is subscribed to 5G SRVCC. When present, it indicates the STN-SR (Session Transfer Number for SRVCC) of the UE. cMsisdn CMsisdn O 0..1 This IE shall be present if the UE is subscribed to 5G SRVCC. When present, it indicates the C-MSISDN (Correlation MSISDN) of the UE. nbIoTUePriority NbIoTUePriority O 0..1 Indicates NB IoT UE priority which is used by the NG-RAN to prioritise resource allocation between UEs accessing via NB-IoT(see clause 5.31.17 of 3GPP TS 23.501 [2]).nssaiInclusionAllowed boolean O 0..1 Indicates that the UE is allowed to include NSSAI in the RRC connection establishment in clear text for 3GPP access, as specified in clause 5.15.9 of 3GPP TS 23.501 [2] and clause 4.2.2.2.2 of 3GPP TS 23.502 [3]. true: indicates that NSSAI can be included in RRC connection establishment by the UE. false or absent: indicates that NSSAI cannot be included. rgWirelineCharacteristi RgWirelineChara O 0..1 Indicates the RG Level Wireline Access cs cteristics Characteristics as specified in 3GPP TS 23.316

[0037] . ecRestrictionDataWb EcRestrictionDat O 0..1 Indicates Enhanced Coverage Restriction Data for aWb WB-N1 mode. If absent, indicates Enhanced Coverage is not restricted for WB-N1 mode. ecRestrictionDataNb boolean O 0..1 If present, this IE shall indicate whether Enhanced Coverage for NB-N1 mode is restricted or not. true: Enhanced Coverage for NB-N1 mode is restricted. false or absent: Enhanced Coverage for NB-N1 mode is allowed. expectedUeBehaviour ExpectedUeBeha O 0..1 Indicates Expected UE Behaviour parameters List viourData associated with AMF(see clause 5.20 of 3GPP TS 23.501 [2] and clause 4.15.6.3 of 3GPP TS 23.502 [3]). This attribute is only applicable to the Nudm interface and shall not be included over the Nudr interface. primaryRatRestrictions array(RatType) O 0..N List of RAT Types that are restricted for use as primary RAT in 5GC and EPC; see 3GPP TS 29.571 [7] (NOTE 2) Contains unique items secondaryRatRestricti array(RatType) O 0..N List of RAT Types that are restricted for use as ons secondary RAT in 5GC and EPC; see 3GPP TS 29.571 [7] (NOTE 2) Contains unique items edrxParametersList array(EdrxParam O 1..N List of subscribed the extended idle mode DRX eters) parameters (see clause 5.31.7.2.1 of 3GPP TS 23.501 [2]).ptwParametersList array(PtwParame O 1..N List of subscribed the Paging Time Window ters) parameters (see clause 5.31.7.2.1 of 3GPP TS 23.501 [2]). iabOperationAllowed boolean O 0..1 Indicates that the UE is allowed for IAB operation as specified in 3GPP TS 23.501 [2]. true: indicates that the UE is allowed for IAB operation. false or absent: indicates that the UE is not allowed for IAB operation. adjacentPlmnRestrictio map(PlmnRestric O 1..N A map (list of key-value pairs where PlmnId ns tion) converted to string serves as key; see 3GPP TS 29.571 [7]) of PlmnRestrictions for adjacent PLMNs wirelineForbiddenArea array(WirelineAre O 0..N List of forbidden areas for 5G-BRG / 5G-CRG / FN- s a) CRG (NOTE 6, NOTE 7) wirelineServiceAreaRe WirelineServiceA O 0..1 Subscribed Service Area Restriction for 5G-BRG / 5G- striction reaRestriction CRG / FN-CRG (NOTE 7) pcfSelectionAssistanc array(PcfSelectio C 1..N List of combination of DNN and S-NSSAI that eInfos nAssistanceInfo) indicates that the same PCF needs to be selected by the AMF. (NOTE 5) aerialUeSubInfo AerialUeSubscrip O 0..1 This IE shall contain the subscribed Aerial UE tionInfo Subscription Information when present. roamingRestrictions RoamingRestricti O 0..1 This IE is used by Nudr_DataRepository API starting ons with 3GPP Rel-17 and onwards (see Table 5.2.3.3.1- 3 in 3GPP TS 29.505

[0010] ). If present, this IE contains information on the roaming restrictions. If this IE is absent e.g. if the UDR is not provisioned with the serving PLMN ID, then the UDM may use the UE's home subscribed profile as the default profile to handle the roaming and SNPN scenarios.remoteProvInd boolean O 0..1 Indicates whether the UE is allowed only for Remote Provisioning as specified in clause 5.30.2.10.3.2 of 3GPP TS 23.501 [2]. UE subscription either allows, or does not allow the UE to access the PLMN as the Onboarding Network using PLMN credentials. - false (default), or the attribute is absent: indicates that the UE is not restricted to the Onboarding only; - true: indicates that the UE is allowed only for the Onboarding. 3gppChargingCharact 3GppChargingCh O 0..1 Subscribed charging characteristics data associated eristics aracteristics to the subscription. timeSyncData TimeSyncData O 0..1 Contains subscription data for Access Stratum Time Synchronization (see 3GPP TS 23.502 [3] clause 4.28.2.1 and 3GPP TS 23.501 [2] clause 5.27.1.11).TABLE 6 (TS 29.503 - 6.1.6.2.8-1: Definition of type SessionManagementSubscriptionData)Attribute name Data type P Cardinality Description singleNssai Snssai M 1 A single Network Slice Selection Assistance Information dnnConfigurations map(DnnConfigurati O 0..N Additional DNN configurations for the network on) slice; A map (list of key-value pairs where DNN, or optionally the Wildcard DNN, serves as key; see clause 6.1.6.1) of DnnConfigurations. (NOTE 1) internalGroupIds array(GroupId) O 1..N List of internal group identifier; see 3GPP TS 23.501 [2] clause 5.9.7 sharedVnGroupDataIds map(SharedDataId) O 1..N A map of identifiers of shared 5G VN group data (list of key-value pairs where GroupId serves as key; see clause 6.1.6.1). This attribute is only applicable to the Nudm interface and shall not be included over the Nudr interface. traceData TraceData O 0..1 Trace requirements about the UE, only sent to SMF in the HPLMN or one of its equivalent PLMN(s) sharedDnnConfiguration SharedDataId O 0..1 Identifier of shared data for DNN configuration. sId sharedTraceDataId SharedDataId O 0..1 Identifier of shared data for trace requirements odbPacketServices OdbPacketServices O 0..1 Operator Determined Barring for Packet Oriented Services (NOTE 2). expectedUeBehaviours map(ExpectedUeBe O 1..N A map of ExpectedUeBehaviourDatas List haviourData) associated with SMF (DNN serves as key; see clause 6.1.6.1), see clause 5.20 of 3GPP TS 23.501 [2] and clause 4.15.6.3 of 3GPP TS 23.502 [3]. This attribute is only applicable to the Nudm interface and shall not be included over the Nudr interface.suggestedPacketNumDl map(SuggestedPack O 1..N A map (list of key-value pairs where dnn serves List etNumDl) as key; see clause 6.1.6.1) of SuggestedPacketNumDls which are associated with SMF (see clause 5.20 of 3GPP TS 23.501 [2] and clause 4.15.6.3 of 3GPP TS 23.502 [3]). This attribute is only applicable to the Nudm interface and shall not be included over the Nudr interface. 3gppChargingCharacter 3GppChargingChara O 0..1 Subscribed charging characteristics data istics cteristics associated to the subscription. supportedFeatures SupportedFeatures O 0..1 See clause 6.1.8

Claims

CLAIMS 1. A method (600) performed by a first network function, NF, instance (402, 502, 504), the method comprising: obtaining (s602) subscription information for a subscriber, wherein the subscription information comprises energy preference information and the energy preference information comprises energy source preference information identifying at least a first preferred energy source type and / or energy efficiency preference information indicating whether or not the subscriber has a preference to be served by energy efficient NF instances; and using (s604) the energy preference information as selection criteria for selecting a second NF instance (304, 504, 590).

2. The method of claim 1, wherein using the energy preference information as selection criteria for selecting a second NF instance comprises: after obtaining the subscription information, transmitting to a repository function, RF (306), a query for discovering NF instance profiles; receiving from the RF a set of one or more NF instance profiles selected by the RF based on the query, wherein each NF instance profile included in the set of NF instance profiles identifies an NF instance; and using the energy preference information as selection criteria for selecting one of the identified NF instances.

3. The method of claim 2, wherein the energy preference information comprises the energy source preference information, the set of NF instance profiles includes at least a first NF instance profile, and using the energy preference information as selection criteria for selecting one of the identified NF instances comprises determining whether the first NF instance profile indicates that the NF instance identified by the first NF instance profile receives energy from an energy source of the first preferred energy source type.

4. The method of claim 2 or 3, wherein the energy preference information comprises the energy efficiency preference information, the set of NF instance profiles includes at least a first NF instance profile and a second NF instance profile, and as a result of the energy efficiency preference information indicating that the subscriber has a preference to be served by energy efficient NF instances, comparing the energy efficiency of the NF instance identified by the first NF instance profile with the energy efficiency of the NF instance identified by the second NF instance profile.

5. The method of claim 2, wherein the energy preference information comprises the energy source preference information and the energy efficiency preference information, the set of NF instance profiles includes at least a first NF instance profile and a second NF instance profile, and using the energy preference information as selection criteria for selecting one of the identified NF instances comprises: determining whether the first NF instance profile indicates that the NF instance identified by the first NF instance profile receives energy from an energy source of the first preferred energy source type; determining whether the second NF instance profile indicates that the NF instance identified by the second NF instance profile receives energy from an energy source of the first preferred energy source type; and as a result of the energy efficiency preference information indicating that the subscriber has a preference to be served by energy efficient NF instances and determining that both the first and second NF instance profiles identify an NF instance that receives energy from an energy source of the first preferred energy source type, comparing the energy efficiency of the NF instance identified by the first NF instance profile with the energy efficiency of the NF instance identified by the second NF instance profile.

6. The method of claim 2, wherein the energy preference information comprises the energy source preference information, and the query comprises energy source type information identifying the first preferred energy source type.

7. The method of claim 6, wherein the energy preference information comprises the energy efficiency preference information, the set of NF instance profiles includes at least a first NF instance profile and a second NF instance profile, and as a result of the energy efficiency preference information indicating that the subscriber has a preference to be served by energy efficient NF instances, comparing the energy efficiency of the NF instance identified by the first NF instance profile with the energy efficiency of the NF instance identified by the second NF instance profile.

8. The method of any one of claims 1-7, further comprising, after obtaining the subscription information and prior transmitting the query to the RF: determining whether the energy preference information comprises the energy source preference information; andafter determining that the energy preference information comprises the energy source preference information, constructing the query so that the query comprises an energy source query parameter identifying the first preferred energy source type.

9. The method of any one of claims 1-8, wherein the first NF instance is an instance of an access management function (502), and the method further comprises, prior to obtaining the subscription information for the subscriber, receiving a registration request message (m403) comprising a subscriber identifier for identifying the subscriber, and using the energy preference information as selection criteria for selecting a second NF instance comprises using the energy preference information as selection criteria for selecting an instance of a session management function.

10. The method of any one of claims 1-8, wherein the first NF instance is an instance of an access management function (502), and the method further comprises, prior to obtaining the subscription information for the subscriber, receiving a request message (m403, m501) comprising a subscriber identifier for identifying the subscriber, and using the energy preference information as selection criteria for selecting a second NF instance comprises using the energy preference information as selection criteria for selecting an instance of a policy function or an instance of a session management function.

11. The method of claim 1-8, wherein the first NF instance is an instance of a session management function (504), and the method further comprises, prior to obtaining the subscription information for the subscriber, receiving a request message (m507) comprising a subscriber identifier for identifying the subscriber, and using the energy preference information as selection criteria for selecting a second NF instance comprises using the energy preference information as selection criteria for selecting an instance of a user plane function (590).

12. A method (610) performed by a first network function, NF, instance (304, 402, 502, 504, 590) for registering with a repository function, RF (306), the method comprising: receiving (s612) from a management server (302) energy source type information identifying at least a first energy source type, wherein the first NF instance receives at least some of its energy from an energy source of the first energy source type; andtransmitting (s614) to the RF (306) a registration message (m303) comprising an NF profile for the first NF instance, wherein the NF profile for the first NF instance comprises information identifying the first energy source type.

13. The method of claim 12, further comprising receiving from the management server an energy efficiency value indicating an energy efficiency of the first NF instance, wherein the NF profile for the first NF instance further comprises the energy efficiency value.

14. A computer program (743) comprising instructions (744) which when executed by processing circuitry (702) of a network node (700) causes the network node to perform the method of any one of claims 1-13.

15. A carrier containing the computer program of claim 14, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium (742).

16. A network node (700) implementing a first network function, NF (304, 402, 502, 504), instance, the network node being configured to perform a method comprising: obtaining subscription information for a subscriber, wherein the subscription information comprises energy preference information and the energy preference information comprises energy source preference information identifying at least a first preferred energy source type and / or energy efficiency preference information indicating whether or not the subscriber has a preference to be served by energy efficient NF instances; and using the energy preference information as selection criteria for selecting a second NF instance.

17. The network node of claim 16, wherein the network node is further configured to perform the method of any one of claims 2-11.

18. A network node (700) implementing a first network function, NF, instance (304, 402, 502, 504), the network node being configured to perform a method comprising: receiving from a management server (302) energy source type information identifying at least a first energy source type, wherein the network node receives at least some of its energy from an energy source of the first energy source type; and transmitting to a repository function (306) a registration message (m303) comprising an NF profile for the first NF instance, wherein the NF profile for the first NF instance comprises information identifying the first energy source type.

19. The network node of claim 18, wherein the method further comprises receiving from the management server an energy efficiency value indicating an energy efficiency of the first NF instance, wherein the NF profile for the first NF instance further comprises the energy efficiency value.

Images