Content for  TS 23.501  Word version:  18.5.0

The NF consumer or the SCP performs UDM discovery to discover a UDM instance that manages the user subscriptions. If the NF consumer performs discovery and selection, the NF consumers shall utilize the NRF to discover the UDM instance(s) unless UDM information is available by other means, e.g. locally configured on NF consumers. The UDM selection function in NF consumers selects a UDM instance based on the available UDM instances (obtained from the NRF or locally configured). The UDM selection functionality is applicable to both 3GPP access and non-3GPP access. The UDM selection functionality in NF consumer or in SCP should consider one of the following factors:

1. Home Network Identifier (e.g. MNC and MCC, realm) of SUCI/SUPI, along with the selected NID (provided by the NG-RAN) in the case of SNPN, UE's Routing Indicator and optionally Home Network Public Key identifier (e.g. in the case that Routing Indicator is not enough to provide SUPI range granularity).
   When the UE's Routing Indicator is set to its default value as defined in TS 23.003, the UDM NF consumer can select any UDM instance within the home network of the SUCI/SUPI.
2. UDM Group ID of the UE's SUPI.
3. SUPI or Internal Group ID; the UDM NF consumer selects a UDM instance based on the SUPI range the UE's SUPI belongs to or based on the results of a discovery procedure with NRF using the UE's SUPI or Internal Group ID as input for UDM discovery.
4. GPSI or External Group ID; UDM NF consumers which manage network signalling not based on SUPI/SUCI (e.g. the NEF) select a UDM instance based on the GPSI or External Group ID range the UE's GPSI or External Group ID belongs to or based on the results of a discovery procedure with NRF using the UE's GPSI or External Group ID as input for UDM discovery.

In the case of delegated discovery and selection in SCP, NF consumer shall include one of these factors in the request towards SCP.

Multiple instances of UDR may be deployed, each one storing specific data or providing service to a specific set of NF consumers as described in clause 4.2.5. In segmented UDR deployment, different instances of UDR store the data for different Data Sets and Data Subsets or for different users. A UDR instance can also store application data that applies on any UE, i.e. all subscribers of the PLMN. If the NF service consumer performs discovery and selection, the NF consumer shall utilize the NRF to discover the appropriate UDR instance(s) unless UDR instance information is available by other means, e.g. locally configured on NF consumer. The UDR selection function in NF consumers is applicable to both 3GPP access and non-3GPP access. The NF consumer or the SCP shall select a UDR instance that contains relevant information for the NF consumer, e.g. UDM/SCP selects a UDR instance that contains subscription data, while NEF/SCP (when used to access data for exposure) selects a UDR that contains data for exposure; or PCF/SCP selects a UDR that contains Policy Data and/or Application Data. The UDR selection function in UDR NF consumers considers the Data Set Identifier of the data to be managed in UDR (see UDR service definition in clause 5.2.12 of TS 23.502). Additionally, the UDR selection function in UDR NF consumers should consider one of the following factors when available to the UDR NF consumer when selecting a UDR that stores the required Data Set(s) and Data Subset(s):

1. UDR Group ID the UE's SUPI belongs to.
2. SUPI; e.g. the UDR NF consumer selects a UDR instance based on the SUPI range the UE's SUPI belongs to or based on the results of a discovery procedure with NRF using the UE's SUPI as input for UDR discovery.
3. GPSI or External Group ID; e.g. UDR NF consumers select a UDR instance based on the GPSI or External Group ID range the UE's GPSI or External Group ID belongs to or based on the results of a discovery procedure with NRF using the UE's GPSI or External Group ID as input for UDR discovery.
4. UDR capability to store application data that is applicable on any UE (i.e. all subscribers of the PLMN).

In the case of delegated discovery and selection, the NF consumer shall include the available factors in the request towards SCP.

The SMSF selection function is supported by the AMF and is used to allocate an SMSF instance that shall manage the SMS. If the "SMS supported" indication is included in the Registration Request by the UE, the AMF checks SMS subscription from the UDM for the UE on whether the SMS is allowed for the UE. If the SMS is allowed and the UE Context stored in AMF includes an SMSF address, the AMF uses the SMSF address included in UE Context (according to Table 5.2.2.2.2-1 of TS 23.502). If the SMS is allowed and the UE Context stored in AMF does not include an SMSF address, the AMF discovers and selects an SMSF to serve the UE. The SMSF selection may be based on the following methods:

• SMSF instance(s) address(es) preconfigured in the AMF (i.e. SMSF FQDN or IP addresses); or
• SMSF information available in the serving PLMN if received from an old AMF or the UDM; or
• The AMF invokes Nnrf_NFDiscovery service operation from NRF to discover SMSF instance as described in clause 5.2.7.3.2 of TS 23.502.

For roaming scenario, the AMF discovers and selects an SMSF in VPLMN. If the NF consumer performs discovery and selection via NRF, the SMSF selection function in the NF consumer selects a SMSF instance based on the available SMSF instances obtained from the NRF. In the case of delegated discovery and selection in SCP, the NF consumer shall include all available factors in the request towards SCP.

The CHF discovery and selection function is supported by the SMF, the AMF, the SMSF and the PCF. It is used by the SMF to select a CHF that manages the online charging or offline charging for a PDU Session of a subscriber. It is used by the AMF to select a CHF that manages the online charging or offline charging for 5G connection and mobility of a subscriber. It is used by the SMSF to select a CHF that manages the online charging or offline charging for the SMS over NAS transactions of a subscriber. It is used by the PCF to select a CHF that manages the spending limits for a subscriber and/or a PDU Session of a subscriber. For the PCF to select the CHF, the address(es) of the CHF, including the Primary CHF address and the Secondary CHF address, may be:

• stored in the UDR as part of the PDU Session policy control subscription information as defined in clause 6.2.1.3 of TS 23.503.
• stored in the UDR as part of the UE context policy control subscription information as defined in clause 6.2.1.3 of TS 23.503.
• locally configured in the PCF based on operator policies.
• discovered using NRF as described in in clause 6.1 of TS 32.290.

The address(es) of the CHF shall be applicable for all services provided by the CHF. The CHF address(es) that a stored in the UDR or configured in the PCF may be complemented by the associated CHF instance ID(s) and CHF set ID(s) (see clause 6.3.1.0) stored or configured in the same location. The CHF address(es) retrieved from the UDR and possible associated CHF instance ID(s) and CHF set ID(s) take precendence over the locally configured CHF address(es) and possible associated CHF instance ID(s) and CHF set ID(s), and over the CHF address(es) discoverred by the NRF. If no CHF address(es) is received from the UDR, the PCF selects, based on operator policies, either the CHF addresse(es) provided by NRF, or the locally configured CHF address(es) and possible associated CHF instance ID(s) and CHF set ID(s). If the PCF has a CHF set ID but no CHF instance ID associated to the CHF address(es) in the same location, the CHF instance within the CHF set may change. If the PCF is not able to reach the CHF address(es), it should query the NRF for other CHF instances within the CHF set. If the PCF received a CHF set ID and a CHF instance ID associated to the CHF address(es) in the same location, the CHF service instance within the CHF may change. If an PCF is not able to reach the CHF address(es), it should query the NRF for other CHF service instances within the CHF. To enable the SMF to select the same CHF that is selected by the PCF for a PDU Session, the PCF provides the selected CHF address(es) and, if available, the associated CHF instance ID(s) and/or CHF set ID(s) in the PDU Session related policy information to the SMF as described in Table 6.4-1 of TS 23.503 and the SMF applies the CHF address and if available, the associated CHF instance ID(s) and/or CHF set ID(s) passed from the PCF as defined in clause 5.1.8 of TS 32.255. Otherwise, the SMF selection of the CHF as defined in clause 5.1.8 of TS 32.255 applies. If operator policies indicates the AMF should select the same CHF that is selected by the PCF for a UE, the PCF provides the selected CHF address(es) and, if available, the associated CHF instance ID(s) and/or CHF set ID(s) in the Access and mobility related policy information and/or in the UE Policy Association supplementary information to the AMF as described in Table 6.5-1 and Table 6.6.7-1 of TS 23.503 respectively and the AMF may apply the CHF address and, if available, the associated CHF instance ID(s) and/or CHF set ID(s) passed from the PCF as defined in clause 5.1.3 of TS 32.256. Otherwise, the AMF selection of the CHF as defined in clause 5.1.3 of TS 32.256 applies. How the CHF is selected by the SMSF is defined in clause 5.4 of TS 32.274. If the NF consumer performs discovery and selection via NRF, the CHF selection function in NF consumers selects a CHF instance based on the available CHF instances obtained from the NRF. The CHF selection functionality in NF consumer or in SCP should consider one of the following factors:

1. CHF Group ID of the UE's SUPI.
2. SUPI; the NF consumer selects a CHF instance based on the SUPI range the UE's SUPI belongs to or based on the results of a discovery procedure with NRF using the UE's SUPI as input for CHF discovery.

In the case of delegated discovery and selection in SCP, the NF consumer shall include all available factors in the request towards SCP.

In addition to the PLMN lists specified in clause 6.3.12 and in clause 6.3.12a, a WLAN access network may also advertise the following PLMN list:

• A PLMN List-5, which includes candidate PLMNs with which "AAA connectivity to 5GC" is supported. A WLAN access network supports "AAA connectivity to 5GC" in a candidate PLMN when it deploys an AAA function that can connect with a NSWOF in this PLMN or can connect with a NSWOF in another PLMN (i.e. HPLMN in roaming case) via AAA proxy. The NSWOF supports "WLAN connection using 5G credentials without 5GS registration", as defined in clause 4.2.15.

If the UE selects a PLMN that is neither UE's HPLMN nor EHPLMN through which the NSWO request should be sent towards the HPLMN, the UE shall use the decorated NAI format as specified in clause 4.2.15 and in TS 23.003. For access to SNPN or CH , a WLAN access network may also advertise the following SNPN list:

• A SNPN List-5, which includes SNPNs with which "AAA connectivity to 5GC" is supported. The SNPNs are the candidate serving SNPNs that the WLAN access network can connect with. A WLAN access network supports "AAA connectivity to 5GC" in a SNPN when it deploys an AAA function that can connect with a NSWOF in this SNPN or can connect with a NSWOF or AAA server in a CH via AAA Proxy. The SNPN or CH supports "WLAN connection using 5G credentials without 5GS registration", as defined in clause 4.2.15.

When the UE wants to connect to a WLAN access network using the 5G NSWO procedure defined in TS 33.501, Annex S, the UE may retrieve the PLMN List-5 or SNPN List-5 advertised by each discovered WLAN access network and may consider this list for selecting the WLAN access network to connect to. For example, if the UE identifies that the HPLMN or CH is included in the PLMN List-5 or SNPN List-5 advertised by a WLAN access network, the UE may select this WLAN access network to connect to using the 5G NSWO procedure. When the UE is configured by HPLMN or CH to use 5G NSWO for connecting to WLAN access networks using its 5G credentials (as defined in TS 33.501), the UE shall attempt to select a WLAN that supports 5G NSWO and shall only use the 5G NSWO procedure for connecting to the selected WLAN. A WLAN access network may also advertise a list of SNPNs which includes SNPNs with which "AAA connectivity to 5GC" is supported. A WLAN access network supports "AAA connectivity to 5GC" in an SNPN when it deploys an AAA function that can connect with a SNPN or CH using any of the architectures defined in clause 4.2.15. When the UE operating in SNPN access mode wants to connect to a WLAN access network using the 5G NSWO procedure defined in Annex S of TS 33.501, the UE may retrieve the SNPNs with which "AAA connectivity to 5GC" is supported that are advertised by each discovered WLAN access network and may consider this information for selecting the WLAN access network to which it attempts to connect.

Multiple instances of NWDAF may be deployed in a network. The NF consumers shall utilize the NRF to discover NWDAF instance(s) unless NWDAF information is available by other means, e.g. locally configured on NF consumers. NF consumers may make an additional query to UDM, when supported, as detailed below. The NWDAF selection function in NF consumers selects an NWDAF instance based on the available NWDAF instances. The NRF may return one or more candidate NWDAF instance(s) and each candidate NWDAF instance (based on its registered profile) supports the Analytics ID with a time that is less than or equal to the Supported Analytics Delay. The following factors may be considered by the NF consumer for NWDAF selection:

• S-NSSAI.
• Analytics ID(s).
• Supported service(s), possibly with their associated Analytics IDs.
• NWDAF Serving Area information, i.e. list of TAIs, for which the NWDAF can provide analytics, train ML models and provide trained ML models and/or data; for each item of this list, a weight may be defined in the NWDAF NF profile to indicate the priority of the NWDAF to cover the TA.
• (only when DCCF is hosted by NWDAF):
  • NF type of the data source.
• NF Set ID of the data source.
• Supported Analytics Delay of the requested Analytics ID(s) (see clause 6.2.6.2).

In the case of multiple instances of NWDAFs deployment, following factors may also be considered:

• NWDAF Capabilities:
  • Analytics aggregation capability.
  • Analytics metadata provisioning capability.
  • Accuracy checking capability (i.e. analytics accuracy checking capability for the AnLF and/or ML Model accuracy checking capability for the MTLF as defined in clause 5C.1 of TS 23.288).

Applicable when NF consumer cannot determine a suitable NWDAF instance based on NRF discovery response, and when NWDAF registration in UDM is supported, as defined in clause 5.2 of TS 23.288: NF consumers may query UDM (Nudm_UECM_Get service operation) for determining the ID of the NWDAF serving the UE. The following factors may be considered by NF consumers to select an NWDAF instance already serving a UE for an Analytics ID:

• SUPI.
• Analytics ID(s).

When selecting an NWDAF for ML model provisioning, the following additional factors may be considered by the NWDAF:

• The ML model Filter information parameters S-NSSAI(s) and Area(s) of Interest (see clause 5.2, TS 23.288) for the trained ML model(s) per Analytics ID(s) and ML Model Interoperability indicator per Analytics ID, if available.

When selecting an NWDAF that supports Federated Learning, the following additional factors may be considered by the NWDAF:

• Time Period of Interest: time interval [start…end], during which the Federated Learning will be performed.
• when selecting FL client NWDAF:
  • FL capability type as FL client NWDAF per Analytics ID.
  • NF type(s) of the data source(s) where data can be collected as input for local model training.
  • NF Set ID(s) of the data source(s) where data can be collected as input for local model training.
  • ML Model Interoperability indicator.
• when selecting FL server NWDAF:
  • FL capability type as FL server NWDAF per Analytics ID.
  • The ML model Filter information parameters S-NSSAI(s) and Area(s) of Interest (see clause 5.2 of TS 23.288) for the trained ML model(s) per Analytics ID(s), if available.

When selecting a NWDAF for roaming case, the detailed mechanism is defined in clause 5.2 of TS 23.288.

The NF consumers may utilize the NRF to discover NEF instance(s) unless NEF information is available by other means, e.g. locally configured in NF consumers. The NRF provides NF profile(s) of NEF instance(s) to the NF consumers. The IP address(es)/port(s) of the NEF or L-NEF may be locally configured in the AF, or the AF may discover the FQDN or IP address(es)/port(s) of the NEF/L-NEF by performing a DNS query using the External Identifier of an individual UE or using the External Group Identifier of a group of UEs or using EDNS Client Subnet, or, if the AF is trusted by the operator, the AF may utilize the NRF to discover the FQDN or IP address(es)/port(s) of the NEF or L-NEF. The following factors may be considered for NEF selection:

• S-NSSAI(s);
• S-NSSAI and DNN corresponding to an untrusted AF;
• Event ID(s) supported by an AF (see clause 6.2.6, clause 6.2.2.3 of TS 23.288 and clause 5.2.19 of TS 23.502);
• AF Instance ID, Application Identifier;
• External Identifier, External Group Identifier, or domain name;
• A request for local NEF selection;
• Location (see locality in clause 6.1.6.2.2 of TS 29.510);
• (for local NEF selection) List of supported TAI;
• (for local NEF selection) List of supported DNAI;
• Capability of NEF to support UAS NF functionality for UUAA procedures;
• Capability of NEF to support Multi-member AF session with required QoS for a set of UEs identified by a list of UE addresses;
• Capability of NEF to support member UE selection assistance functionality.

Local NEF instance(s) can be deployed close to UE access. For local NEF selection, the location of the local NEF instance (e.g. geographical location, data centre) may be used in conjunction with the location of L-PSA UPF or AF.

The AMF, MME, NEF, AF, SCEF, SCS/AS may utilize the NRF to discover UCMF instance(s) unless UCMF information is available by other means, e.g. locally configured in UCMF services consumers. In the case of delegated discovery and selection in SCP, the NF consumer shall forward the request towards SCP.

An NF is configured with its serving SCP(s). In a deployment where several SCPs are deployed, a message may traverse several SCP instances until reaching its final destination. A SCP may discover and select a next hop SCP by querying the Nnrf_NFDiscovery Service of the NRF or it may be configured with next SCP in the message path. An SCP may use the SCP profile parameters in clause 6.2.6.3 as discovery parameters in Nnrf_NFDiscovery. The parameter(s) to be used depend(s) on network deployment. The NRF returns a list SCP Profiles as per the provided discovery parameters. If an SCP receives a Routing Binding Indication within a service or notification request and decides to forward that request to a next-hop SCP, it shall include the Routing Binding Indication in the forwarded request. Based on SCP configuration, an SCP deciding to address a next-hop SCP for a service request may then delegate the NF (instance) and/or service (instance) selection to subsequent SCPs and provide discovery and selection parameters to the next-hop SCP.

In the case of NF consumer based discovery and selection, the following applies:

• The NF consumer (e.g. AMF, AUSF) performs NSSAAF selection to select an NSSAAF Instance that supports authentication between the UE and the AAA-S associated with the HPLMN or in the Credentials Holder in the case of SNPN or in the DCS domain in the case of ON-SNPN. The NF consumer shall utilize the NRF to discover the NSSAAF instance(s) unless NSSAAF information is available by other means, e.g. locally configured on the NF consumer. The NSSAAF selection function in the NF consumer selects an NSSAAF instance based on the available NSSAAF instances (obtained from the NRF or locally configured in the NF consumer).

NSSAAF selection is applicable to both 3GPP access and non-3GPP access. The NSSAAF selection function in NSSAAF NF consumers or in SCP should consider the following factor when it is available:

1. Home Network Identifier (e.g. MNC and MCC, realm) of SUPI (by an NF consumer in the Serving network).
2. S-NSSAI of the HPLMN.
3. SUPI or Internal Group ID; the NSSAAF NF consumer selects a NSSAAF instance based on the SUPI range the UE's SUPI belongs to or based on the results of a discovery procedure with NRF using the UE's SUPI or Internal Group ID as input for NSSAAF discovery.

An HPLMN deploying NSSAAF instances supporting specific S-NSSAIs and/or sets of SUPIs (according to factors 2-3) shall also deploy NSSAAF instance(s) that can be selected using factor 1 if they need to interoperate with VPLMNs using only factor 1 for NSSAAF selection. In the case of delegated discovery and selection in SCP, the NSSAAF NF consumer shall send all available factors to the SCP.

A consumer NF of the 5G-EIR performs discovery of 5G-EIR using either configuration or NRF as specified in clause 6.3.1. The network is configured with the 5G-EIR to serve the PLMN of the NF consumer requesting the 5G-EIR service, i.e. no roaming interface is defined. The 5G-EIR selection function in NF consumers is independent of Access Type.

Multiple instances of DCCF may be deployed in a network. The NF consumers shall utilize the NRF to discover DCCF instance(s) unless DCCF information is available by other means, e.g. locally configured on NF consumers. The DCCF selection function in NF consumers selects a DCCF instance based on the available DCCF instances. The following factors may be considered by the NF consumer for DCCF selection:

• DCCF Serving Area information, i.e. list of TAIs for which the DCCF coordinates Data Sources.
• S-NSSAI.
• NF type of the data source.
• NF Set ID of the data source.
• DCCF relocation capability: Support for relocating the data collection subscription among DCCFs.

Multiple instances of ADRF may be deployed in a network. The NF consumers shall utilize the NRF to discover ADRF instance(s) unless ADRF information is available by other means, e.g. locally configured on NF consumers. The ADRF selection function in NF consumers selects an ADRF instance based on the available ADRF instances. The following factors may be considered by the NF consumer for ADRF selection:

• S-NSSAI.
• ML model storage capability.

Multiple instances of MFAF may be deployed in a network. The MFAF selection function is supported by the DCCF. The DCCF shall utilize the NRF to discover MFAF instance(s) unless MFAF information is available by other means, e.g. locally configured on the DCCF. The MFAF selection function in the DCCF selects a MFAF instance based on the available MFAF instances. The following factors may be considered by the DCCF for MFAF selection:

• S-NSSAI;
• NF Types of the Data Sources handled by the MFAF;
• NF Set IDs of the Data Sources handled by the MFAF;
• MFAF Serving Area information, i.e. list of TAIs for which the MFAF may receive data from Data Sources.

The NF consumers shall utilise the NRF to discover NSACF instance(s), including the NSACF acting as Primary NSACF role, unless NSACF information is available by other means, e.g. locally configured in NF consumers. The NSACF selection function in the NSACF NF consumer selects an NSACF instance based on the available NSACF instances, which are obtained from the NRF or locally configured in the NSACF NF consumer. The following factors may be considered by the NF consumer for NSACF discovery and selection:

• S-NSSAI(s).
• NSAC Service Area Identifier, or a reserved value "Entire PLMN" for discovering the NSACF acting as Primary NSACF or centralized NSAC role. The NSAC Service Area Identifier is configured at the consumer NF and NSACF (see clause 5.15.11.0). Each Service Area Identifier is a unique and unambiguous identifier and a NSACF registers with the NRF the NSAC Service Area Identifier(s) of the NSAC Service Area(s) it serves. "Entire PLMN" is indicated in roaming case to the NRF of HPLMN by the VPLMN NF consumer when the VPLMN NF consumer needs to discover the HPLMN NSACF, or in non roaming case to select a Primary NSACF.
• NSACF service capabilities:
  • Support monitoring and controlling the number of registered UEs per network slice for the network slice that is subject to NSAC.
  • Support, for network slices that are subject to NSAC and configured to support EPS counting, monitoring and controlling the number of registered UEs with at least one PDU session per network slice, as defined in clause 5.15.11.5a.
  • Support monitoring and controlling the number of established PDU Sessions per network slice for the network slice that is subject to NSAC.
• PLMN ID information in the case of roaming to contact the HPLMN NSACF for inbound roamers.

In the case of delegated discovery and selection in SCP, the NSACF NF consumer shall send all available and applicable factors to the SCP.

Multiple instances of EASDF may be deployed in a network. NF consumers mentioned in this clause are SMF(s). The NF consumers shall utilize the NRF to discover EASDF instance(s) unless EASDF information is available by other means, e.g. locally configured on the NF consumer. The EASDF selection function in NF consumers or SCP selects an EASDF instance based on the available EASDF instances. The following factors may be considered by the NF consumer or SCP for EASDF selection:

• S-NSSAI.
• DNN.
• the N6 IP address of the EASDF.
• The N6 IP address of the PSA UPF.
• Location as per NF profile.
• DNAI (if exist).

The NFs (e.g. NEF, AF and PCF) may utilize the NRF to discover TSCTSF instance(s) unless TSCTSF information is available by other means, e.g. locally configured in the requested NF. The following factors may be considered for TSCTSF discovery and selection:

• DNN and S-NSSAI. When the NF discovers the TSCTSF for a DNN/S-NSSAI, the NRF provides the NF with NF profile(s) of TSCTSF instance(s) belonging to single TSCTSF Set for a given DNN/S-NSSAI. For example, the same TSCTSF Set shall be selected by the PCF serving PDU Sessions for this DNN and S-NSSAI to notify the TSCTSF for a PDU Session that is potentially impacted by the (g)PTP time synchronization service.
• GPSI or External Group Identifier. TSCTSF NF consumers (which manage network signalling not based on SUPI/SUCI (e.g. the NEF)) select a TSCTSF instance based on the GPSI or External Group ID range the UE's GPSI or External Group ID belongs to or based on the results of a discovery procedure with NRF using the UE's GPSI or External Group ID as input for TSCTSF discovery.
• SUPI or Internal Group ID. TSCTSF NF consumers select a TSCTSF instance based on the SUPI range the UE's SUPI belongs to or based on the results of a discovery procedure with NRF using the UE's SUPI or Internal Group ID as input for TSCTSF discovery.

If the TSCTSF is locally configured in NFs, it shall be ensured that the same TSCTSF Set is configured in all NFs (e.g. NEF, AF and PCF) for the given DNN and S-NSSAI.

The NF consumers (e.g. NWDAF) may utilize the NRF to discover AF instance(s) in the MNO domain, i.e. trusted AF(s), unless AF information is available by other means, e.g. locally configured in NF consumers. The NRF provides NF profile(s) of AF instance(s) to the NF consumers. The following factors may be considered for AF discovery and selection:

• One or multiple combination(s) of the S-NSSAI and DNN corresponding to an AF.
• Supported Application Id(s).
• Event ID(s) Supported by an AF.
• Internal-Group Identifier.

The NF consumer (e.g. NWDAF) may select an AF instance, in the MNO domain, considering one or multiple combination(s) of the S-NSSAI and DNN corresponding to an AF and the EventID(s) supported by an AF to provide the input data required for generation of analytics. The NF consumer (e.g. NWDAF) may consider the supported Application Id(s), if the input data is required only for those applications. The NF consumer (e.g. NWDAF) may consider the Internal-Group Identifier supported by the AF if the input data is required for a particular group of UEs.

The following mechanisms may be used for discovery of NRF service instances and their endpoint addresses:

• NF consumers or SCP may have all the NRF services instances and their endpoint addresses locally configured.
• NF consumers or SCP may have the endpoint address of a NRF discovery service locally configured and utilize it to discover the NRF(s) and get the NF profile(s) of the NRF(s).
• NF consumers (e.g. v-NRF) or SCP may have endpoint addresses of the NRF bootstrapping service and utilize it to discover the NRF service instances and their endpoint addresses. The NRF bootstrapping service is a version independent API, which may be especially useful over roaming interfaces.
• The NF consumer, e.g. AMF, may use the Nnssf_NSSelection service to get the endpoint address of a NRF discovery service for a certain slice.