Content for  TS 23.501  Word version:  19.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. If the NRF in the local PLMN indicated support, for the local PLMN, of indirect communication with delegated discovery with NF (re)selection at target PLMN (Model D in Annex E with SCP in target PLMN doing NF (re)selection) and/or of indirect communication without delegated discovery with NF (re)selection at target PLMN (Model C in Annex E with SCP in target PLMN doing NF (re)selection), based on operator's policy and the capabilities of the local PLMN, the NRF in the remote PLMN may also return an indication that indirect communication with delegated discovery with NF (re)selection at target PLMN is requested or that indirect communication without delegated discovery with NF (re)selection at target PLMN is requested and, for delegated discovery in target PLMN, omit NF profiles. The NRF in the local PLMN reaches the NRF in the remote PLMN by forming a remote PLMN specific query using the PLMN ID provided by the requester NF. The remote PLMN NRF may further interact with a target PLMN NRF as specified in clause 6.2.6.1. Based on operator's policy and configuration, the NRF in the local PLMN may also determine without interaction with the NRF in the remote PLMN that indirect communication with delegated discovery with NF (re)selection at target PLMN is requested for communication for that remote PLMN. The NF/NF service discovery procedure across PLMNs is specified in clauses 4.17.5, 4.17.10 and 4.17.10a 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). The formulation of the DNN considers the information provided in f) below. 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.
   • per (S-NSSAI, DNN) associated with 5G VN group: Service Area (LADN service area) for the 5G VN group. In the case of SMF selection for a PDU Session targeting 5G VN group, the AMF may prefer candidate SMF(s) that have an intersection with the LADN service area of the 5G VN group.
   • per (S-NSSAI, subscribed DNN): Additional Parameters for SMF selection in target PLMN as defined in TS 23.502 and may include the target network identifier (i.e. PLMN ID preferred by the operator).
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 or serving scope/preferred locality (which may be formulated by AMF, as specified in TS 29.510, based on UE location) 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. In the case of Indirect Network Sharing, the SMF selection of the anchor SMF in the participating operator's network reuses the procedure of H-SMF selection for home-routed roaming but may furthermore take into account the location information based on current UE location. If the HR-SBO roaming is allowed for the PDU Session, the DNN is also considered for V-SMF selection. 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 5G-AN signalling by the UE;
• Mobile IAB-indication.

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 5G-AN 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.