Content for  TS 23.501  Word version:  18.1.0

The NF discovery and NF service discovery enable Core Network entities (NFs or Service Communication Proxy (SCP)) to discover a set of NF instance(s) and NF service instance(s) for a specific NF service or an NF type. NF service discovery is enabled via the NF discovery procedure, as specified in clauses 4.17.4, 4.17.5, 4.17.9 and 4.17.10 of TS 23.502. Unless the expected NF and NF service information is locally configured on the requester NF, e.g. when the expected NF service or NF is in the same PLMN as the requester NF, the NF and NF service discovery is implemented via the Network Repository Function (NRF). NRF is the logical function that is used to support the functionality of NF and NF service discovery and status notification as specified in clause 6.2.6. In order for the requested NF type or NF service to be discovered via the NRF, the NF instance need to be registered in the NRF. This is done by sending a Nnrf_NFManagement_NFRegister containing the NF profile. The NF profile contains information related to the NF instance, such as NF instance ID, supported NF service instances (see clause 6.2.6 for more details regarding the NF profile). The registration may take place e.g. when the producer NF instance and its NF service instance(s) become operative for the first time. The NF service registration procedure is specified in clause 4.17.1 of TS 23.502. In order for the requester NF or SCP to obtain information about the NF and/or NF service(s) registered or configured in a PLMN/slice, based on local configuration the requester NF or SCP may initiate a discovery procedure with the NRF by providing the type of the NF and optionally a list of the specific service(s) it is attempting to discover. The requester NF or SCP may also provide other service parameters e.g. slicing related information. For the detailed service parameter(s) used for specific NF and NF service discovery refer to clause 5.2.7.3.2 of TS 23.502. The requester NF may also provide NF Set related information to enable reselection of NF instances within the NF set. The requester NF may also provide the required supported features of the NF. For some Network Functions which have access to the subscription data (e.g. HSS, UDM) the NRF may need to resolve the NF Group ID corresponding to a subscriber identifier. If the NRF has no stored configuration mapping identity sets/ranges to NF Group ID locally, the NRF may retrieve the NF Group ID corresponding to a specific subscriber identifier from the UDR using the Nudr_GroupIDmap_Query service operation. In the case of Indirect Communication, a NF Service Consumer employs an SCP which routes the request to the intended target of the request. If the requester NF is configured to delegate discovery, the requester NF may omit the discovery procedure with the NRF and instead delegate the discovery to the SCP; the SCP will then act on behalf of the requester NF. In this case, the requester NF adds any necessary discovery and selection parameters to the request in order for the SCP to be able to do discovery and associated selection. The SCP may interact with the NRF to perform discovery and obtain discovery result and it may interact with the NRF or UDR to obtain NF Group ID corresponding to subscriber identifier. The NRF provides a list of NF instances and NF service instances relevant for the discovery criteria. The NRF may provide the IP address or the FQDN of NF instance(s) and/or the Endpoint Address(es) of relevant NF service instance(s) to the NF Consumer or SCP. The NRF may also provide NF Set ID and/or NF Service Set ID to the NF Consumer or SCP. The response contains a validity period during which the discovery result is considered valid and can be cached. The result of the NF and NF service discovery procedure is applicable to any subscriber that fulfils the same discovery criteria. The entity that does the discovery may cache the NF profile(s) received from the NF/NF service discovery procedure. During the validity period, the cached NF profile(s) may be used for NF selection for any subscriber matching the discovery criteria. In the case of Direct Communication, the requester NF uses the discovery result to select NF instance and a NF service instance that is able to provide a requested NF Service (e.g. a service instance of the PCF that can provide Policy Authorization). In the case of Indirect Communication without Delegated Discovery, the requester NF uses the discovery result to select a NF instance while the associated NF service instance selection may be done by the requester NF and/or an SCP on behalf of the requester NF. In both the cases above, the requester NF may use the information from a valid cached discovery result for subsequent selections (i.e. the requester NF does not need to trigger a new NF discovery procedure to perform the selection). In the case of Indirect Communication with Delegated Discovery, the SCP will discover and select a suitable NF instance and NF service instance based on discovery and selection parameters provided by the requester NF and optional interaction with the NRF. The NRF to be used may be provided by the NF consumer as part of the discovery parameters, e.g. as a result of a NSSF query. The SCP may use the information from a valid cached discovery result for subsequent selections (i.e. the SCP does not need to trigger a new NF discovery procedure to perform the selection). The requester NF or SCP may subscribe to receive notifications from the NRF of a newly updated NF profile of an NF (e.g. NF service instances taken in or out of service), or newly registered de-registered NF instances. The NF/NF service status subscribe/notify procedure is defined in clauses 4.17.7 and 4.17.8 of TS 23.502. For NF and NF service discovery across PLMNs, the NRF in the local PLMN interacts with the NRF in the remote PLMN to retrieve the NF profile(s) of the NF instance(s) in the remote PLMN that matches the discovery criteria. The NRF in the local PLMN reaches the NRF in the remote PLMN by forming a target PLMN specific query using the PLMN ID provided by the requester NF. The NF/NF service discovery procedure across PLMNs is specified in clause 4.17.5 of TS 23.502. For topology hiding, see clause 6.2.17.

The SMF selection functionality is supported by the AMF and SCP and is used to allocate an SMF that shall manage the PDU Session. The SMF selection procedures are described in clause 4.3.2.2.3 of TS 23.502. The SMF discovery and selection functionality follows the principles stated in clause 6.3.1. If the AMF does discovery, the AMF shall utilize the NRF to discover SMF instance(s) unless SMF information is available by other means, e.g. locally configured on AMF. The AMF provides UE location information to the NRF when trying to discover SMF instance(s). The NRF provides NF profile(s) of SMF instance(s) to the AMF. In addition, the NRF also provides the SMF service area of SMF instance(s) to the AMF. The SMF selection functionality in the AMF selects an SMF instance and an SMF service instance based on the available SMF instances obtained from NRF or on the configured SMF information in the AMF. The SMF selection functionality is applicable to both 3GPP access and non-3GPP access. The SMF selection for Emergency services is described in clause 5.16.4.5. The following factors may be considered during the SMF selection:

1. Selected Data Network Name (DNN). In the case of the home routed roaming, the DNN is not applied for the V-SMF selection.
2. S-NSSAI of the HPLMN (for non-roaming and home-routed roaming scenarios), and S-NSSAI of the VPLMN (for roaming with local breakout and home-routed roaming scenarios).
3. NSI-ID.
4. Access technology being used by the UE.
5. Support for Control Plane CIoT 5GS Optimisation.
6. Subscription information from UDM, e.g.
   • per DNN: whether LBO roaming is allowed.
   • per DNN: whether HR-SBO roaming is allowed.
   • per S-NSSAI: the subscribed DNN(s).
   • per (S-NSSAI, subscribed DNN): whether LBO roaming is allowed.
   • per (S-NSSAI, subscribed DNN): whether HR-SBO roaming is allowed.
   • per (S-NSSAI, subscribed DNN): whether EPC interworking is supported.
   • per (S-NSSAI, subscribed DNN): whether selecting the same SMF for all PDU sessions to the same S-NSSAI and DNN is required.
7. Void.
8. Local operator policies.
9. Load conditions of the candidate SMFs.
10. Analytics (i.e. statistics or predictions) for candidate SMFs' load as received from NWDAF (see TS 23.288), if NWDAF is deployed.
11. UE location (i.e. TA).
12. Service Area of the candidate SMFs.
13. Capability of the SMF to support a MA PDU Session.
14. If interworking with EPS is required.
15. Preference of V-SMF support. This is applicable only for V-SMF selection in the case of home routed roaming.
16. Target DNAI.
17. Capability of the SMF to support User Plane Remote Provisioning (see clause 5.30.2.10.4.3).
18. Supported DNAI list.
19. HR-SBO support (according to clause 6.7 of TS 23.548).
20. Capability of the SMF (V-SMF and H-SMF) to support non-3GPP access path switching.

To support the allocation of a static IPv4 address and/or a static IPv6 prefix as specified in clause 5.8.2.2.1, a dedicated SMF may be deployed for the indicated combination of DNN and S-NSSAI and registered to the NRF, or provided by the UDM as part of the subscription data. In the case of delegated discovery, the AMF, shall send all the available factors a)-d), k) and n) to the SCP. In addition, the AMF may indicate to the SCP which NRF to use (in the case of NRF dedicated to the target slice). If there is an existing PDU Session and the UE requests to establish another PDU Session to the same DNN and S-NSSAI of the HPLMN, and the UE subscription data indicates the support for interworking with EPS for this DNN and S-NSSAI of the HPLMN or UE subscription data indicates the same SMF shall be selected for all PDU sessions to the same S-NSSAI, DNN, the same SMF in non roaming and LBO case or the same H-SMF in home routed roaming case, shall be selected. In addition, if the UE Context in the AMF provides a SMF ID for an existing PDU session to the same DNN, S-NSSAI, the AMF uses the stored SMF ID for the additional PDU Session. In any such a case where the AMF can determine which SMF should be selected, if delegated discovery is used, the AMF shall indicate a desired NF Instance ID so that the SCP is able to route the message to the relevant SMF. Otherwise, if UE subscription data does not indicate the support for interworking with EPS for this DNN and S-NSSAI, a different SMF in non roaming and LBO case or a different H-SMF in home routed roaming case, may be selected. For example, to support a SMF load balancing or to support a graceful SMF shutdown (e.g. a SMF starts to no more take new PDU Sessions). In the home-routed roaming case, the SMF selection functionality selects an SMF in VPLMN based on the S-NSSAI of the VPLMN, as well as an SMF in HPLMN based on the S-NSSAI of the HPLMN. This is specified in clause 4.3.2.2.3.3 of TS 23.502. When the UE requests to establish a PDU Session to a DNN and an S-NSSAI of the HPLMN, if the UE MM Core Network Capability indicates the UE supports EPC NAS and optionally, if the UE subscription indicates the support for interworking with EPS for this DNN and S-NSSAI of the HPLMN, the selection functionality (in AMF or SCP) selects a combined SMF+PGW-C. Otherwise, a standalone SMF may be selected. If the UDM provides a subscription context that allows for handling the PDU Session in the VPLMN (i.e. using LBO) for this DNN and S-NSSAI of the HPLMN and, optionally, the AMF is configured to know that the VPLMN has a suitable roaming agreement with the HPLMN of the UE, the following applies:

• If the AMF does discovery, the SMF selection functionality in AMF selects an SMF from the VPLMN.
• If delegated discovery is used, the SCP selects an SMF from the VPLMN.

If an SMF in the VPLMN cannot be derived for the DNN and S-NSSAI of the VPLMN, or if the subscription does not allow for handling the PDU Session in the VPLMN using LBO, then the following applies:

• If the AMF does discovery, both an SMF in VPLMN and an SMF in HPLMN are selected, and the DNN and S-NSSAI of the HPLMN is used to derive an SMF identifier from the HPLMN.
• If delegated discovery is used:
  • The AMF performs discovery and selection of H-SMF from NRF. The AMF may indicate the maximum number of H-SMF instances to be returned from NRF, i.e. SMF selection at NRF.
  • The AMF sends Nsmf_PDUSession_CreateSMContext Request to SCP, which includes the endpoint (e.g. URI) of the selected H-SMF, and the discovery and selection parameters as defined in this clause, i.e. parameter for V-SMF selection. The SCP performs discovery and selection of the V-SMF and forwards the request to the selected V-SMF.
  • The V-SMF sends the Nsmf_PDUSession_Create Request towards the H-SMF via the SCP; the V-SMF uses the received endpoint (e.g. URI) of the selected H-SMF to construct the target destination to be addressed. The SCP forwards the request to the H-SMF.
  • Upon reception of a response from V-SMF, based on the received V-SMF ID the AMF obtains the Service Area of the V-SMF from NRF. The AMF uses the Service Area of the V-SMF to determine the need for V-SMF relocation upon subsequent UE mobility.

If the initially selected SMF in VPLMN (for roaming with LBO) detects it does not understand information in the UE request, it may reject the N11 message (related with a PDU Session Establishment Request message) with a proper N11 cause triggering the AMF to select both a new SMF in the VPLMN and a SMF in the HPLMN (for home routed roaming). The AMF selects SMF(s) considering support for CIoT 5GS optimisations (e.g. Control Plane CIoT 5GS Optimisation). In the case of onboarding of UEs for SNPNs, when the UE is registered for SNPN onboarding the AMF selects SMF(s) of Onboarding Network considering the Capability of SMF to support User Plane Remote Provisioning. Additional details of AMF selection of an I-SMF are described in clause 5.34. In the case of home routed scenario, the AMF selects a new V-SMF if it determines that the current V-SMF cannot serve the UE location. The selection/relocation is same as an I-SMF selection/relocation as described in clause 5.34.

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

• The AMF and the NSWOF perform AUSF selection to allocate an AUSF Instance that performs authentication between the UE and 5G CN in the HPLMN. The AMF and the NSWOF shall utilize the NRF to discover the AUSF instance(s) unless AUSF information is available by other means, e.g. locally configured on AMF and on NSWOF. The AUSF selection function in the AMF and in the NSWOF selects an AUSF instance based on the available AUSF instances (obtained from the NRF or locally configured in the AMF).
• The UDM shall utilize the NRF to discover the AUSF instance(s) unless AUSF information is available by other means, e.g. locally configured on UDM. The UDM selects an AUSF instance based on the available AUSF instance(s) obtained from the NRF or based on locally configured information, and information stored (by the UDM) from a previously successful authentication.

AUSF selection is applicable to both 3GPP access and non-3GPP access. The AUSF selection function in AUSF NF consumers or in SCP should consider one of the following factors when available:

1. Home Network Identifier (e.g. MNC and MCC, realm) of SUCI/SUPI (by an NF consumer in the Serving network) along with the selected NID (provided by the NG-RAN) in the case of SNPN, 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 AUSF NF consumer can select any AUSF instance within the home network for the UE.
2. AUSF Group ID the UE's SUPI belongs to.
3. SUPI; e.g. the AMF selects an AUSF 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 AUSF discovery.

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

The AMF discovery and selection functionality is applicable to both 3GPP access and non-3GPP access. The AMF selection functionality can be supported by the 5G-AN (e.g. RAN, N3IWF) and is used to select an AMF instance for a given UE. An AMF supports the AMF selection functionality to select an AMF for relocation or because the initially selected AMF was not an appropriate AMF to serve the UE (e.g. due to change of Allowed NSSAI). Other CP NF(s), e.g. SMF, supports the AMF selection functionality to select an AMF from the AMF set when the original AMF serving a UE is unavailable. The TSCTSF shall use the AMF discovery functionality to determine the AMFs serving the TAs in the spatial validity condition provided by the AF. 5G-AN selects an AMF Set and an AMF from the AMF Set under the following circumstances:

1. When the UE provides no 5G-S-TMSI nor the GUAMI to the 5G-AN.
2. When the UE provides 5G-S-TMSI or GUAMI but the routing information (i.e. AMF identified based on AMF Set ID, AMF pointer) present in the 5G-S-TMSI or GUAMI is not sufficient and/or not usable (e.g. UE provides GUAMI with an AMF region ID from a different region).
3. AMF has instructed AN that the AMF (identified by GUAMI(s)) is unavailable and no target AMF is identified and/or AN has detected that the AMF has failed.
4. When the UE attempts to establish a signalling connection, and the following conditions are met:
   • the 5G-AN knows in what country the UE is located; and
   • the 5G-AN is connected to AMFs serving different PLMNs of different countries; and
   • the UE provides a 5G-S-TMSI or GUAMI, which indicates an AMF serving a different country to where the UE is currently located; and
   • the 5G-AN is configured to enforce selection of the AMF based on the country the UE is currently located.
   Then the 5G-AN shall select an AMF serving a PLMN corresponding to the UE's current location. How 5G-AN selects the AMF in this case is defined in TS 38.410.

In the case of NF Service Consumer based discovery and selection, the CP NF selects an AMF from the AMF Set under the following circumstances:

• When the AMF has instructed CP NF that a certain AMF identified by GUAMI(s) is unavailable and the CP NF was not notified of target AMF; and/or
• CP NF has detected that the AMF has failed; and/or
• When the selected AMF does not support the UE's Preferred Network Behaviour; and/or
• When the selected AMF does not support the High Latency communication for NR RedCap UE.

In the case of delegated discovery and associated selection, the SCP selects an AMF from the corresponding AMF Set under the following circumstances:

• The SCP gets an indication "select new AMF within SET" from the CP NF; and/or
• SCP has detected that the AMF has failed.

The AMF selection functionality in the 5G-AN may consider the following factors for selecting the AMF Set:

• AMF Region ID and AMF Set ID derived from GUAMI;
• Requested NSSAI;
• Local operator policies;
• 5G CIoT features indicated in RRC signalling by the UE;
• IAB-indication;
• NB-IoT RAT Type;
• Category M Indication;
• NR RedCap Indication;
• SNPN Onboarding indication as indicated in RRC signalling by the UE.

AMF selection functionality in the 5G-AN or CP NFs or SCP considers the following factors for selecting an AMF from AMF Set:

• Availability of candidate AMF(s).
• Load balancing across candidate AMF(s) (e.g. considering weight factors of candidate AMFs in the AMF Set).
• In 5G-AN, 5G CIoT features indicated in RRC signalling by the UE.
• In 5G-AN, SNPN Onboarding indication as indicated in RRC signalling by the UE.

When the UE accesses the 5G-AN with a 5G-S-TMSI or GUAMI that identifies more than one AMF (as configured during N2 setup procedure), the 5G-AN selects the AMF considering the weight factors. When 5G-S-TMSI or GUAMI provided by the UE to the 5G-AN contains an AMF Set ID that is usable, and the AMF identified by AMF pointer that is not usable (e.g. AN detects that the AMF has failed) or the corresponding AMF indicates it is unavailable (e.g. out of operation) then the 5G-AN uses the AMF Set ID for selecting another AMF from the AMF set considering the factors above. The discovery and selection of AMF in the CP NFs or SCP follows the principle in clause 6.3.1 In the case of NF Service Consumer based discovery and selection, the AMF or other CP NFs shall utilize the NRF to discover the AMF instance(s) unless AMF information is available by other means, e.g. locally configured on AMF or other CP NFs. The NRF provides the NF profile(s) of AMF instance(s) to the AMF or other CP NFs. The AMF selection function in the AMF or other CP NFs selects an AMF instance as described below: When NF Service Consumer performs discovery and selection the following applies:

• In the case of AMF discovery and selection functionality in AMF or other CP NFs use GUAMI (in the SNPN case, along with NID of the SNPN that owns the AMF instances to be discovered and selected) or TAI to discover the AMF instance(s), the NRF provides the NF profile of the associated AMF instance(s). If an associated AMF is unavailable due to AMF planned removal, the NF profile of the backup AMF used for planned removal is provided by the NRF. If an associated AMF is unavailable due to AMF failure, the NF profile of the backup AMF used for failure is provided by the NRF. If AMF pointer value in the GUAMI is associated with more than one AMF, the NRF provides all the AMFs associated with this AMF pointer value. If no AMF instances related to the indicated GUAMI can be found, the NRF may provide a list of NF profiles of candidate AMF instances in the same AMF Set. The other CP NF or AMF may select any AMF instance from the list of candidate AMF instances. If no NF profiles of AMF is returned in the discovery result, the other CP NF or AMF may discover an AMF using the AMF Set as below.
• In the case of AMF discovery and selection functionality in AMF use AMF Set to discover AMF instance(s), the NRF provides a list of NF profiles of AMF instances in the same AMF Set.
• At intra-PLMN mobility, the AMF discovery and selection functionality in AMF may use AMF Set ID, AMF Region ID, the target location information, S-NSSAI(s) of Allowed NSSAI to discover target AMF instance(s). The NRF provides the target NF profiles matching the discovery.
• At intra-SNPN mobility, the AMF discovery and selection functionality in AMF may use AMF Set ID, AMF Region ID (along with NID of the SNPN that owns the AMF instances to be discovered and selected), the target location information, S-NSSAI(s) of Allowed NSSAI, AMF support of SNPN Onboarding (if the UE is registered for SNPN Onboarding) to discover target AMF instance(s). The NRF provides the target NF profiles matching the discovery.
• At inter PLMN mobility, the source AMF selects an AMF instance(s) in the target PLMN by querying target PLMN level NRF via the source PLMN level NRF with target PLMN ID. The target PLMN level NRF returns an AMF instance address based on the target operator configuration. After the Handover procedure the AMF may select a different AMF instance as specified in clause 4.2.2.2.3 of TS 23.502.

In the context of Network Slicing, the AMF selection is described in clause 5.15.5.2.1. When delegated discovery and associated selection is used, the following applies:

• If the CP NF includes GUAMI or TAI in the request, the SCP selects an AMF instance associated with the GUAMI or TAI and sends the request to a selected AMF service instance if it is available. The following also applies:
  • If none of the associated AMF service instances are available due to AMF planned removal, an AMF service instance from the backup AMF used for planned removal is selected by the SCP;
  • If none of the associated AMF service instances are available due to AMF failure, an AMF service instance from the backup AMF used for failure is selected by the SCP;
  • If no AMF service instances related to the indicated GUAMI (in the SNPN case, along with NID of the SNPN that owns the AMF instances to be discovered and selected) can be found the SCP selects an AMF instance from the AMF Set; or
  • AMF Pointer value used by more than one AMF, SCP selects one of the AMF instances associated with the AMF Pointer.
• If the CP NF includes AMF Set ID in the request, the SCP selects AMF/AMF service instances in the provided AMF Set.
• At intra-PLMN mobility, if a target AMF instance needs to be selected, the AMF may provide AMF Set ID, AMF Region ID, and the target location information, S-NSSAI(s) of Allowed NSSAI in the request, optionally NRF to use. The SCP will select a target AMF instance matching the discovery.
• At intra-SNPN mobility, if a target AMF instance needs to be selected, the AMF may provide AMF Set ID, AMF Region ID along with NID of the SNPN that owns the AMF instances to be discovered and selected, and the target location information, S-NSSAI(s) of Allowed NSSAI, AMF support of SNPN Onboarding in the request (if the UE is registered for SNPN Onboarding), optionally NRF to use. The SCP will select a target AMF instance matching the discovery.
• At inter PLMN mobility, the source AMF selects indicates "roaming" to the SCP. The SCP interacts with the NRF in source PLMN so that the NRF in source PLMN can discover an AMF in the target PLMN via target PLMN NRF.

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.
• 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 them 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. How the CHF is selected by the AMF is defined in clause& 5.1.3 of TS 32.256. 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 PLMNs with which "AAA connectivity to 5GC" is supported. A WLAN access network supports "AAA connectivity to 5GC" in a PLMN when it deploys an AAA function that can connect with a NSWOF in this PLMN. The NSWOF supports "WLAN connection using 5G credentials without 5GS registration", as defined in clause 4.2.15.

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. A WLAN access network supports "AAA connectivity to 5GC" in a SNPN when it deploys an AAA function that can connect with a NSWOF or AAA Server in this SNPN or CH. 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, trained ML models and/or data.
• (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.

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:
  • FL capability type as FL client per Analytics ID.
  • Data available by the FL client.
• when selecting FL server:
  • FL capability type as FL server 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.

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.

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).

In the case of SNPN, NSSAAF selection is only applicable to 3GPP access. Otherwise, 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.

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. If the NSACF NF consumer is the AMF, the NSACF selection function in the AMF selects an NSACF instance based on the available NSACF instances, which are obtained from the NRF or locally configured in the AMF. The following factors may be considered by the NF consumer for NSACF selection:

• S-NSSAI(s).
• NSACF Service Area information, or "Entire PLMN" for discovering the NSACF acting as Primary NSACF or central NSACF role.. The NSACF service area is related to the location of the NF consumer.
• 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 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 for inbound roamers.

In the case of delegated discovery and selection in SCP, the NSACF NF consumer shall send all available 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.