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.
Binding can be used to indicate suitable target NF producer instance(s) for NF service instance selection, reselection and routing of subsequent requests associated with a specific NF producer resource (context) and NF service. This allows the NF producer to indicate that the NF consumer, for a particular context, should be bound to an NF service instance, NF instance, NF service set or NF set depending on local policies and other criteria (e.g. at what point it is in the middle of a certain procedure, considering performance aspects etc).
Binding can also be used by the NF consumer to indicate suitable NF consumer instance(s) for notification target instance reselection and routing of subsequent notification requests associated with a specific notification subscription and for providing Binding Indication for service(s) that the NF consumer produces for the same data context and the NF service producer is subsequently likely to invoke.
The Binding Indication contains the information in Table 6.3.1.0-1.
The Routing Binding Indication may be included in Request, Subscribe or Notification messages (see clause 7.1.2). It may be used in the case of indirect communication by the SCP to route the message. The Routing Binding Indication is a copy of the information in the Binding Indication and also contains the information in Table 6.3.1.0-1.
The NF service producer may provide a Binding Indication to the NF service consumer as part of the Direct or Indirect Communication procedures, to be used in subsequent related service requests. The level of Binding Indication provided by the NF service producer to the NF consumer indicates if the resource in the NF service producer is either bound to NF service instance, NF instance, NF Service Set or NF set as specified in Table 6.3.1.0-1. The Binding Indication may include NF Service Set ID, NF Set ID, NF instance ID, or NF service instance ID, for use by the NF consumer or SCP for NF Service Producer (re-)selection. If the resource is created in the NF Service Producer, the NF Service Producer provides resource information which includes the endpoint address of the NF service producer. For indirect communication, the NF service consumer copies the Binding Indication into the Routing Binding Indication in Request or Subscribe message, unless the NF service consumer performs a reselection for indirect communication without delegated discovery.
During explicit or implicit notification subscription, a Binding Indication may be provided by the NF service consumer to NF service producer; the NF service consumer will also provide a Notification Endpoint. The NF service consumer may also provide a Binding Indication in response to notification requests. The level of Binding Indication provided by the NF service consumer to the NF service provider indicates if the Notification Endpoint is either bound to NF service instance, NF instance, NF Service Set or NF set as specified in Table 6.3.1.0-1. The Binding Indication shall include at least one of NF Set ID, NF instance ID, NF Service Set ID and/or NF service instance ID, and may also include the service name. The NF Service Set ID, NF service instance ID, and service name relate to the service of the NF service consumer that will handle the notification.
The Binding Indication is used by the NF service producer as notification sender to reselect an endpoint address and construct the Notification Endpoint, i.e. the URI where the notification is to be sent, e.g. if the provided Notification Endpoint of the NF service consumer included in the subscription cannot be reached, according to the following:
If the service name in the Binding Indication is omitted and the binding for notification is on NF Set or NF Instance level, the endpoint address registered in the NRF at NF Profile level of the NF(s) selected according to the Binding Indication shall be used to construct a new Notification Endpoint.
If the service name is included in the Binding Indication, an endpoint address registered in the NRF for that service in the NF profile(s) selected according to the Binding Indication shall be used to construct a new Notification Endpoint.
For indirect communication, the NF service producer copies the Binding Indication into the Routing Binding Indication that is included in the Notification request, to be used by the SCP to discover an alternative endpoint address and construct a Notification Endpoint e.g. if the Notification Endpoint that the request targets cannot be reached, according to the following:
If the service name in the Routing Binding Indication is omitted and the binding for notification is on NF Set or NF Instance level, the endpoint address registered in the NRF at NF Profile level of the NF(s) selected according to the Binding Indication shall be used to construct a new Notification Endpoint.
If the service name is included in the Routing Binding Indication, an endpoint address registered in the NRF for that service in the NF profile(s) selected according to the Binding Indication shall be used to construct a new Notification Endpoint.
For subscription to notifications via another network function, a separate Binding Indication for subscription related events may be provided by the NF service consumer (see clause 4.17.12.4 of TS 23.502) and if provided shall be associated with an applicability indicating notification for subscription related events.
If the NF as an NF consumer provides a Binding Indication for services that the NF produces in service requests, the Binding Indication shall be associated with an applicability indicating other service and may contain the related service name(s), in addition to the other parameters listed in Table 6.3.1.0-1. If no service name(s) are provided, the Binding Indication relates to all services that the NF produces.
For NF Set or NF Instance level of binding, a Binding Indication for notifications and other services may be combined if it relates to the same service, and that combined Binding Indication shall then be associated with an applicability indicating all scenarios that the Binding Indication relates to (For this purpose, the applicability can indicate a combination of values).
If no applicability is indicated in a request or subscribe messages, a Binding Indication in that messages is applicable for notification to all events except for the subscription related event (see clause 4.17.12.4 of TS 23.502).
A Binding Indication may be shared by a group of resources (e.g. contexts) identified by a group identifier. This enables a NF Service consumer or producer to update the binding indication for this group of resources in a single request or notification towards a given peer NF service instance, e.g. when a group of resources need to be taken over by a different NF within an NF set. See clause 6.12.1 of TS 29.500.
Table 6.3.1.0-1 defines the selection and reselection behaviour of NF services consumers and SCPs depending on the Binding Indication provided by an NF service producer. The detailed procedures refer to clause 4.17.11 and 4.17.12 of TS 23.502.
The NF Consumer / Notification sender / SCP selects
The NF Consumer / Notification sender / SCP can reselect e.g. when selected producer is not available
Binding information for selection and re-selection
NF Service Instance
The indicated NF Service Instance
An equivalent NF Service instance:
within the NF Service Set (if applicable)
within the NF instance
within the NF Set (if applicable)
NF Service Instance ID, NF Service Set ID, NF Instance ID, NF Set ID, Service name (4)
NF Service Set
Any NF Service instance within the indicated NF Service Set
Any NF Service instance within an equivalent NF Service Set within the NF Set (if applicable) (2)
NF Service Set ID, NF Instance ID, NF Set ID, Service name (4)
NF Instance
Any equivalent NF Service instance within the NF instance.
Any equivalent NF Service instance within a different NF instance within the NF Set (if applicable)
NF Instance ID, NF Set ID, Service name (4)
NF Set
Any equivalent NF Service instance within the indicated NF Set
Any equivalent NF Service instance within the NF Set
NF Set ID, Service name (4)
NOTE 1:
if the Binding Indication is not available, the NF Consumer routes the service request to the target based on routing information available.
NOTE 2:
NF Service Sets in different NFs are considered equivalent if they include same type and variant (e.g. identical NF Service Set ID) of NF Services.
NOTE 3:
If a Routing Binding Indication is not available, the SCP routes the service request to the target based on available routing information.
NOTE 4:
The service name is only applicable if the Binding Indication relates to a notification target or If the NF as a NF consumer provides a Binding Indication for services that the NF produces.
For indirect communication shown in Annex E, the SCP performs the following functionalities regarding Network Function and Network Function Service discovery and selection:
If the request includes a Routing Binding Indication, the SCP shall route the service request to the requested target as specified in Table 6.3.1.0-1. If the Routing Binding Indication does not exist, the SCP may get the NF Set ID from the NRF or local configuration (if available).
If the request recipient had previously provided a Binding Indication, then the request sender shall include a Routing Binding Indication with the same contents in subsequent related requests.
The location information describes the network location of the NF instance. It can consist of one or more levels. Each level describes one location aspect, such as geographic location, data centre, cluster, etc. An NF instance has only one location.
The location information may be used to select the NF service instance or NF instance from a particular network location based on local configuration.
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:
Selected Data Network Name (DNN). In the case of the home routed roaming, the DNN is not applied for the V-SMF selection.
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).
NSI-ID.
Access technology being used by the UE.
Support for Control Plane CIoT 5GS Optimisation.
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.
Void.
Local operator policies.
Load conditions of the candidate SMFs.
Analytics (i.e. statistics or predictions) for candidate SMFs' load as received from NWDAF (see TS 23.288), if NWDAF is deployed.
UE location (i.e. TA).
Service Area of the candidate SMFs.
Capability of the SMF to support a MA PDU Session.
If interworking with EPS is required.
Preference of V-SMF support. This is applicable only for V-SMF selection in the case of home routed roaming.
Target DNAI.
Capability of the SMF to support User Plane Remote Provisioning (see clause 5.30.2.10.4.3).
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.
The selection and reselection of the UPF for PDU session establishment, UE mobility or UE traffic offloading are performed by the SMF by considering UPF deployment scenarios such as centrally located UPF and distributed UPF located close to or at the Access Network site. The selection of the UPF shall also enable deployment of UPF with different capabilities, e.g. UPFs supporting no or a subset of optional functionalities.
The UPF selection for PDU session establishment in home routed roaming case, the UPF(s) in home PLMN is selected by SMF(s) in HPLMN, and the UPF(s) in the VPLMN is selected by SMF(s) in VPLMN. The exact set of parameters used for the selection mechanism is deployment specific and controlled by the operator configuration.
The UPF selection for PDU session establishment, UE mobility or UE traffic offloading involves:
a step of SMF Provisioning of available UPF(s). This step may take place while there is no PDU Session to establish and may be followed by N4 Node Level procedures defined in clause 4.4.3 of TS 23.502 where the UPF and the SMF may exchange information such as the support of optional functionalities and capabilities.
A step of selection of an UPF for a particular PDU Session; it is followed by N4 session management procedures defined in clause 4.4.1 of TS 23.502.
To collect the data from the UPF as defined in clause 5.8.2.17, the related dedicated UPF is discovered and selected as following:
When the NF consumer or SCP directly subscribes to the UPF, the NF consumer or SCP queries the NRF including the related discovery parameter. The NRF returns the UPF(s) which meet(s) the discovery request.
When the NF consumer or SCP shall subscribe via the SMF, the NF consumer gets the serving SMF information from the UDM per SUPI, DNN and S-NSSAI. After that, the NF consumer sends a subscription to the indicated SMF and the SMF identifies the related UPF(s) using the parameters of the subscription (e.g. target flow description, AoI, etc.) and transfers the related event subscription information to the identified UPF(s). If the NF consumer does not know the SUPI but only the UE IP address, it may need to invoke the BSF to get the SUPI corresponding to the triplet (IP address, DNN and S-NSSAI).
SMF may be locally configured with the information about the available UPFs, e.g. by OA&M system when UPF is instantiated or removed.
The UPF selection functionality in the SMF may optionally utilize the NRF to discover UPF instance(s). In this case, the SMF issues a request to the NRF that may include following parameters: DNN, S-NSSAI, SMF Area Identity, ATSSS steering capabilities. In its answer, the NRF provides the NF profile(s) that include(s) the IP address(es) or the FQDN of the N4 interface of corresponding UPF instance(s) to the SMF.
UPFs may be associated with an SMF Area Identity in the NRF. This allows limiting the SMF provisioning of UPF(s) using NRF to those UPF(s) associated with a certain SMF Area Identity. This can e.g. be used in the case that an SMF is only allowed to control UPF(s) configured in NRF as belonging to a certain SMF Area Identity.
The NRF may be configured by OAM with information on the available UPF(s) or the UPF instance(s) may register its/their NF profile(s) in the NRF. This is further defined in clause 4.17 of TS 23.502.
If there is an existing PDU Session, and the SMF receives another PDU Session request to the same DNN and S-NSSAI, and if the SMF determines that interworking with EPC is supported for this PDU Session as specified in clause 4.11.5 of TS 23.502, the SMF should select the same UPF, otherwise, if the SMF determines that interworking with EPC is not supported for the new PDU Session, a different UPF may be selected.
For the same DNN and S-NSSAI if different UPF are selected at 5GC, when the UE is moved to EPC network, there is no requirement to enforce APN-AMBR. Whether and how to apply APN-AMBR for the PDN Connection associated with this DNN/APN is implementation dependent, e.g. possibly only AMBR enforcement per PDU Session applies.
The following parameter(s) and information may be considered by the SMF for UPF selection and re-selection:
UPF's dynamic load.
Analytics (i.e. statistics or predictions) for UPF load, Service Experience analytics and/or DN Performance analytics per UP path (including UPF and/or DNAI and/or AS instance) and UE related analytics (UE mobility, UE communication, and expected UE behavioural parameters) as received from NWDAF (see TS 23.288), if NWDAF is deployed.
UPF's relative static capacity among UPFs supporting the same DNN.
UPF location available at the SMF.
UE location information.
Capability of the UPF and the functionality required for the particular UE session: An appropriate UPF can be selected by matching the functionality and features required for an UE.
Data Network Name (DNN).
PDU Session Type (i.e. IPv4, IPv6, IPv4v6, Ethernet Type or Unstructured Type) and if applicable, the static IP address/prefix.
SSC mode selected for the PDU Session.
UE subscription profile in UDM.
DNAI as included in the PCC Rules and described in clause 5.6.7.
Local operator policies.
S-NSSAI.
Access technology being used by the UE.
Information related to user plane topology and user plane terminations, that may be deduced from:
5G-AN-provided identities (e.g. CellID, TAI), available UPF(s) and DNAI(s);
Identifiers (i.e. a FQDN and/or IP address(es)) of N3 terminations provided by a W-AGF or a TNGF or a TWIF;
Information regarding the user plane interfaces of UPF(s). This information may be acquired by the SMF using N4;
Information regarding the N3 User Plane termination(s) of the AN serving the UE. This may be deduced from 5G-AN-provided identities (e.g. CellID, TAI);
Information regarding the N9 User Plane termination(s) of UPF(s) if needed;
Information regarding the User plane termination(s) corresponding to DNAI(s).
RSN, support for redundant GTP-U path or support for redundant transport path in the transport layer (as in clause 5.33.2) when redundant UP handling is applicable.
Information regarding the ATSSS Steering Capability of the UE session (e.g. any combination of ATSSS-LL capability, MPTCP capability, MPQUIC capability) and information on the UPF support of RTT measurements without PMF.
Support for UPF allocation of IP address/prefix.
Support of the IPUPS functionality, specified in clause 5.8.2.14.
Support for High latency communication (see clause 5.31.8).
A W-AGF or a TNGF may provide Identifiers of its N3 terminations when forwarding over N2 uplink NAS signalling to the 5GC. The AMF may relay this information to the SMF, as part of session management signalling for a new PDU Session.
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:
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.
AUSF Group ID the UE's SUPI belongs to.
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:
When the UE provides no 5G-S-TMSI nor the GUAMI to the 5G-AN.
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).
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.
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.
When the UE supports connectivity with N3IWF but does not support connectivity with ePDG, as specified in TS 23.402, the UE shall perform the procedure in clause 6.3.6.2 for selecting an N3IWF.
When the UE supports connectivity with N3IWF, as well as with ePDG, as specified in TS 23.402, the UE shall perform the procedure in clause 6.3.6.3 for selecting either an N3IWF or an ePDG, i.e. for selecting a non-3GPP access node.
In both cases above the UE can be configured by the HPLMN with the same information that includes:
ePDG identifier configuration: It contains the FQDN or IP address of the ePDG in the HPLMN, as specified in clause 4.5.4.3 of TS 23.402. This is used only when the UE supports connectivity with ePDG and attempts to select an ePDG. It is ignored in all other cases.
N3IWF identifier configuration: It contains the FQDN or IP address of the N3IWF in the HPLMN.
Extended Home N3IWF identifier configuration: It contains one or multiple tuples of FQDN/IP address of the N3IWF in the HPLMN and the S-NSSAIs supported by this N3IWF.
Non-3GPP access node selection information: It contains a prioritized list of PLMNs and for each PLMN it includes (i) a "Preference" parameter which indicates if ePDG or N3IWF is preferred in this PLMN and (ii) an FQDN parameter which indicates if the Tracking/Location Area Identity FQDN or the Operator Identifier FQDN (as specified in clause 4.5.4.4 of TS 23.402) should be used when discovering the address of an ePDG or N3IWF in this PLMN. The list of PLMNs shall include the HPLMN and shall include an "any PLMN" entry, which matches any PLMN the UE is connected to except the HPLMN.
Slice-specific N3IWF prefix configuration: It contains one or multiple tuples consisting of:
List of supported S-NSSAIs;
Prefix for the Prefixed N3IWF OI or TA FQDNs.
The ePDG identifier configuration, the N3IWF identifier configuration, the Extended Home N3IWF identifier configuration and the Slice-specific N3IWF Prefix Configuration are optional parameters, while the Non-3GPP access node selection information is required and shall include at least the HPLMN and the "any PLMN" entry.
If the ePDG identifier configuration is configured in the UE, then, when the UE decides to select an ePDG in the HPLMN (according to the procedure in clause 6.3.6.3), the UE shall use the ePDG identifier configuration to find the IP address of the ePDG in the HPLMN and shall ignore the FQDN parameter of the HPLMN in the Non-3GPP access node selection information.
If the N3IWF identifier configuration or the Extended Home N3IWF identifier configuration is configured in the UE, then, when the UE decides to select an N3IWF in the HPLMN (according to the procedure in clause 6.3.6.3 for combined N3IWF/ePDG selection and the procedure in clause 6.3.6.2 for Stand-alone N3IWF selection), the UE shall use the Extended Home N3IWF identifier configuration, if available, and otherwise the N3IWF identifier configuration to find the IP address of the N3IWF in the HPLMN and shall ignore the FQDN parameter of the HPLMN in the Non-3GPP access node selection information.
The HPLMN's PCF takes the UE's subscribed S-NSSAIs into account when providing Extended Home N3IWF identifier configuration and/or Slice-specific N3IWF Prefix Configuration to the UE.
If a UE does not support the Extended Home N3IWF identifier configuration and the Slice-specific N3IWF Prefix Configuration, then the HPLMN provides to the UE the Non-3GPP access node selection information and the N3IWF identifier configuration by taking into account the UE's subscribed S-NSSAIs.
The UE can be configured by the VPLMN with the following information applicable for the V-PLMN:
Slice-specific N3IWF prefix configuration: It contains one or multiple tuples consisting of:
List of supported S-NSSAIs;
Prefix for the Prefixed N3IWF OI or TA FQDNs.
To enable the V-PCF to provide the UE with Slice-specific N3IWF prefix configuration, the AMF provides the V-PCF with the Configured NSSAI for the serving PLMN during the UE Policy Association Establishment/Modification procedure.
During the registration procedure the AMF may determine if the N3IWF selected by the UE is suitable for the S-NSSAI(s) requested by the UE considering the UE subscription. If the AMF determines that a different N3IWF should be selected, the AMF:
may, if the UE supports slice-based N3IWF selection, trigger the UE Policy Association Establishment or UE Policy Association Update procedure to provide the UE with updated N3IWF selection information as described in clause 6.15.2.1; when the AMF is informed that the update of N3IWF selection information is completed, the AMF may release UE Policy Association if it is not needed before proceeding to the Registration Reject;
shall send a Registration Reject message to the UE. The AMF may include target N3IWF information (FQDN and/or IP address) in the Registration Reject so that the UE can, if supported by the UE, use the target N3IWF information to select the N3IWF to register to 5GC. The target N3IWF information only applies to the one N3IWF selection performed by the UE just after receiving the Registration Reject.
The AMF may determine the N3IWF based on the list of supported TAs and the corresponding list of supported slices for each TA obtained as defined in clause 5.15.8.
The UE performs N3IWF selection based on the ePDG selection procedure as specified in clause 4.5.4 of TS 23.402 except for the following differences:
The Tracking/Location Area Identifier FQDN shall be constructed by the UE based only on the Tracking Area wherein the UE is located. The N3IWF Tracking/Location Area Identifier FQDN may use the 5GS TAI when the UE is registered to the 5GS, or the EPS TAI when the UE is registered to EPS. The Location Area is not applicable on the 3GPP access.
The ePDG Operator Identifier (OI) FQDN format is substituted by with N3IWF OI FQDN format as specified in TS 23.003.
If the UE is configured with Slice-specific N3IWF prefix configuration, then the UE shall construct the Prefixed N3IWF OI FQDN or the Prefixed N3IWF TA FQDN as specified in TS 23.003 instead of the N3IWF OI FQDN and the N3IWF TA FQDN, respectively. To determine the prefix, the UE selects the Slice-specific N3IWF prefix configuration for the selected PLMN that contains S-NSSAIs that match all (or most, in case there is no full match) of the S-NSSAIs that the UE is going to include in the Requested NSSAI in the subsequent Registration procedure.
The ePDG identifier configuration is substituted by the N3IWF identifier configuration and the Extended Home N3IWF identifier configuration. The Extended Home N3IWF identifier configuration takes precedence over the N3IWF identifier configuration. If the UE is located in the home country and the UE is configured with Extended Home N3IWF identifier configuration, then the UE uses the Extended Home N3IWF identifier configuration to select an N3IWF:
The UE uses the FQDN or IP address from the Extended Home N3IWF identifier configuration that matches all (or most, if there is no full match) of the S-NSSAIs that the UE is going to request in the subsequent Registration.
The ePDG selection information is substituted by the Non-3GPP access node selection information and slice-specific N3IWF prefix information. The UE shall give preference to the N3IWF in all PLMNs in the Non-3GPP access node selection information independent of the "Preference" parameter.
If the UE determines to be located in a country other than its home country (called the visited country), then instead of clause 4.5.4.4, bullet 3 of TS 23.402, the following applies:
If the UE is registered via 3GPP access to a PLMN and this PLMN is included in the Non-3GPP access node selection information, then the UE shall select an N3IWF in this PLMN. If the UE fails to connect to an N3IWF in this PLMN, the UE shall select an N3IWF by performing the DNS procedure specified in clause 4.5.4.5 of TS 23.402.
In all other cases, (e.g. when the UE is not configured with the Non-3GPP access node selection information, or the UE is registered via 3GPP access to a PLMN but this PLMN is not included in the Non-3GPP access node selection information, or the UE is not registered via 3GPP access to any PLMN), the UE shall select an N3IWF by performing the DNS procedure specified in clause 4.5.4.5 of TS 23.402 with the difference that the UE shall construct the Prefixed N3IWF OI FQDN if the UE is configured with Slice-specific N3IWF prefix configuration for the selected PLMN.
If the UE is accessing PLMN services via SNPN, the UE uses the procedure defined in this clause to select an N3IWF deployed in the PLMN. If the UE is accessing standalone non-public network service via a PLMN (see supported cases in clause 5.30.2.0), the UE uses the procedure defined in clause 6.3.6.2a.
This procedure applies when the UE is accessing the SNPN N3IWF in its subscribed SNPN via a PLMN or directly via untrusted non-3GPP access.
The UE shall first determine the country in which it is located. If the UE cannot determine the country in which the UE is located, the UE shall stop N3IWF selection and abort the attempt to access the SNPN via PLMN.
The UE is configured with one N3IWF address and the MCC of the country where the configured N3IWF is located as defined in TS 24.502.
If the UE determines that it is located in the country where the configured N3IWF is located, then the UE uses the configured N3IWF FQDN to select an N3IWF deployed in the SNPN.
If the UE determines that it is located in a country (called the visited country) different from the country where the configured N3IWF is located, then:
The UE shall construct an FQDN consisting of the SNPN ID of the subscribed SNPN and the Visited Country FQDN and indicating the query is for SNPN, as specified in TS 23.003 and perform a DNS query for the resulting FQDN.
If the DNS response contains no records, then the UE determines that the visited country does not mandate the selection of an N3IWF in this country for the SNPN identified by the SNPN ID provided by the UE. In this case the UE uses the configured N3IWF FQDN to select an N3IWF deployed in the SNPN.
If no DNS response is received, the UE shall stop the N3IWF selection.
If the DNS response contains one or more records, then the UE determines that the visited country mandates the selection of an N3IWF in this country. Each record in the DNS response shall contain the identity of an N3IWF of the UE's subscribed SNPN in the visited country which may be used for N3IWF selection. In this case:
The UE shall select an N3IWF included in the DNS response based on its own implementation means.
If the UE cannot select any N3IWF included in the DNS response, then the UE shall stop the N3IWF selection.
When the UE wants to select a non-3GPP access node (either an N3IWF or an ePDG), the UE shall perform the following procedure:
The UE shall attempt to determine the country it is located in. This is determined by implementation-specific methods not defined in this specification. If the UE cannot determine the country it is located in, the UE shall stop the non-3GPP access node selection.
If the UE determines to be located in its home country, then:
The UE shall select the HPLMN. If the UE fails to connect to an ePDG/N3IWF in the HPLMN, then the UE shall stop the non-3GPP access node selection.
If the UE determines to be located in a country other than its home country (called the visited country), then:
If the UE is registered via 3GPP access to a PLMN and this PLMN is included in the Non-3GPP access node selection information, then the UE shall select this PLMN. If the UE fails to connect to an ePDG/N3IWF in this PLMN, the UE shall select another PLMN by performing the DNS procedure specified in bullet 3c) below.
In all other cases, (e.g. when the UE is not configured with the Non-3GPP access node selection information, or the UE is registered via 3GPP access to a PLMN but this PLMN is not included in the Non-3GPP access node selection information, or the UE is not registered via 3GPP access to any PLMN), the UE shall select a PLMN by performing the DNS procedure specified in bullet 3c) below.
The UE shall select a PLMN as follows:
The UE shall determine if the non-3GPP access node selection is required for an IMS service or for a non-IMS service. The means of that determination are implementation specific.
If the UE determines that the non-3GPP access node selection is required for a non-IMS service, the UE shall select a PLMN as specified in clause 6.3.6.2. As defined below, if the UE fails to connect to an N3IWF in any PLMN, the UE may attempt to select an ePDG according to the procedure specified in clause 4.5.4.5 of TS 23.402.
If the UE determines that the non-3GPP access node selection is required for an IMS service, the UE shall select a PLMN as follows:
First, the UE shall perform a DNS query using the Visited Country FQDN for N3IWF, as specified in TS 23.003 to determine if the visited country mandates the selection of N3IWF in this country. The DNS response received by the UE may be empty or may contain the identities of one or more PLMNs in the visited country, which may be used for N3IWF selection, if the UE decides to select an N3IWF, as specified below. For example, the DNS response may contain the identity of PLMN-1 and the identity of PLMN-2.
Then, the UE shall perform a DNS query using the Visited Country FQDN for ePDG, as specified in TS 23.003 to determine if the visited country mandates the selection of ePDG in this country. The DNS response received by the UE may be empty or may contain the identities of one or more PLMNs in the visited country, which may be used for ePDG selection, if the UE decides to select an ePDG, as specified below. For example, the DNS response may contain the identity of PLMN-1 and the identity of PLMN-3.
If the UE does not receive a DNS response in none of the above two DNS queries, then the UE shall stop the non-3GPP access node selection. Otherwise, the next steps are executed.
The UE shall consolidate the PLMN identities received in the above two DNS responses and shall construct a candidate list of PLMNs. For example, the candidate list of PLMNs may contain the identities of PLMN-1, PLMN-2, PLMN-3.
If the candidate list of PLMNs is empty, then:
If the Non-3GPP access node selection information contains one or more PLMNs in the visited country, the UE shall select one of these PLMNs based on their priorities in the Non-3GPP access node selection information. If the UE fails to connect to a non-3GPP access node in any of these PLMNs, the UE shall select the HPLMN.
Otherwise, the UE shall select the HPLMN.
If the candidate list of PLMNs is not empty, then:
If the UE is registered via 3GPP access to a PLMN which is included in the candidate list of PLMNs, then the UE shall select this PLMN. If the UE fails to connect to a non-3GPP access node in this PLMN, then the UE shall select a different PLMN included in the candidate list of PLMNs as specified in the next bullet.
If the UE is registered via 3GPP access to a PLMN which is not included in the candidate list of PLMNs, or the UE is not registered via 3GPP access to any PLMN, or the UE fails to connect to a non-3GPP access node according to the previous bullet, then the UE shall select one of the PLMNs included in the candidate list of PLMNs based on the prioritized list of PLMNs in the Non-3GPP access node selection information (i.e. the UE shall select first the highest priority PLMN in the Non-3GPP access node selection information that is contained in the candidate list of PLMNs). If the Non-3GPP access node selection information does not contain any of the PLMNs in the candidate list of PLMNs, or the UE is not configured with the Non-3GPP access node selection information, or the UE was not able to connect to a non-3GPP access node in any of the PLMNs included in the Non-3GPP access node selection information and in the candidate list of PLMN, then the UE shall select a PLMN included in the candidate list of PLMNs based on its own implementation means.
If the UE cannot select a non-3GPP access node in any of the PLMNs included in the candidate list of PLMNs, then the UE shall stop the non-3GPP access node selection.
In the selected PLMN the UE shall attempt to select a non-3GPP access node as follows:
The UE shall determine if the non-3GPP access node selection is required for an IMS service or for a non-IMS service. The means of that determination are implementation-specific.
When the selection is required for an IMS service, the UE shall choose a non-3GPP access node type (i.e. ePDG or N3IWF) based on the "Preference" parameter specified in clause 6.3.6.1, unless the UE has its 5GS capability disabled in which case it shall choose an ePDG independent of the "Preference" parameter setting.
If the "Preference" parameter for the selected PLMN indicates that ePDG is preferred, the UE shall attempt to select an ePDG. If the "Preference" parameter for the selected PLMN indicates that N3IWF is preferred, the UE shall attempt to select an N3IWF.
If the selection fails, including the case when, during the registration performed over either 3GPP or non-3GPP access, the UE receives the IMS Voice over PS session Not Supported over Non-3GPP Access indication (specified in clause 5.16.3.2a), the UE shall attempt selecting the other non-3GPP access node type in the selected PLMN, if any. If that selection fails too, or it is not possible, then the UE shall select another PLMN, according to the procedure specified bullet 3c) above.
When the selection is required for a non-IMS service, the UE shall perform the selection by giving preference to the N3IWF independent of the "Preference" parameter setting. If the N3IWF selection fails, or it is not possible, the UE should select another PLMN based on the procedure specified in clause 4.5.4.4 of TS 23.402, and shall attempt to select an N3IWF in this PLMN. If the UE fails to select an N3IWF in any PLMN, the UE may attempt to select an ePDG according to the procedure specified in clause 4.5.4.5 of TS 23.402.
In the above procedure, when the UE attempts to construct a Tracking/Location Area Identifier FQDN either for ePDG selection or for N3IWF selection, the UE shall use the Tracking Area wherein the UE is located and shall construct either:
an ePDG or N3IWF TAI FQDN based on the 5GS TAI, when the UE is registered to the 5GS; or
an ePDG or N3IWF TAI FQDN based on the EPS TAI, when the UE is registered to EPS.
If the UE is configured with Slice-specific N3IWF prefix configuration, then the UE shall construct the Prefixed N3IWF OI FQDN or the Prefixed N3IWF TA FQDN as specified in TS 23.003 instead of the N3IWF OI FQDN and the N3IWF TA FQDN, respectively. Further details on constructing the Prefixed N3IWF OI and TA FQDN are described in clause 6.3.6.2.
UE initiates PLMN and non-3GPP access node selection for emergency services when it detects a user request for emergency session and determines that untrusted non-3GPP access shall be used for the emergency access.
When the UE supports connectivity with N3IWF but does not support connectivity with ePDG, as specified in TS 23.402, the UE shall perform the procedure in clause 6.3.6.4.2 for selecting an N3IWF.
When the UE supports connectivity with N3IWF, as well as with ePDG, as specified in TS 23.402, the UE shall perform the procedure in clause 6.3.6.4.3 for selecting either an N3IWF or an ePDG, i.e. for selecting a non-3GPP access node.
If the UE is attached to 5GC via an N3IWF that is located in the same country as the country in which the UE is currently located and the AMF has previously indicated support for emergency services over non-3GPP access as defined in clause 5.16.4.1, the UE reuses the existing N3IWF connection for emergency services. Otherwise, the UE terminates any existing N3IWF connection and continues as follows:
If the UE is equipped with a UICC:
The UE determines whether it is located in the home country or a visited country;
If the UE is located in the home country, then the UE selects the Home PLMN for emergency services and selects an N3IWF based on the procedure defined in clause 6.3.6.2.
If the UE is located in a visited country, the UE performs a DNS query using the Visited Country Emergency N3IWF FQDN, as specified in TS 23.003 to determine which PLMNs in the visited country support emergency services in non-3GPP access via N3IWF; and:
If the DNS response contains one or more records, the UE selects a PLMN that supports emergency services in non-3GPP access via N3IWF. Each record in the DNS response shall contain the identity of a PLMN in the visited country supporting emergency services in non-3GPP access via N3IWF.
The UE shall consider these PLMNs based on their priorities in the Non-3GPP Access Node Selection Information (if available). If the UE cannot select a PLMN in the Non-3GPP Access Node Selection Information or if non-3GPP Access Node Selection Information is not available, the UE shall attempt to select any PLMN in the list of PLMNs returned in the DNS response.
Once the UE has selected a PLMN the UE shall select an N3IWF for the selected PLMN as follows:
If non-3GPP Access Node Selection Information is available for the selected PLMN the UE constructs the Tracking Area Identity based N3IWF FQDN or the Operator Identifier based N3IWF FQDN as indicated in the non-3GPP Access Node Selection Information for the selected PLMN.
If non-3GPP Access Node Selection Information is not available for the selected PLMN the UE constructs the Operator Identifier based N3IWF FQDN for the selected PLMN.
If the DNS response does not contain any record, or if the DNS response contains one or more records but the UE fails to select a PLMN that supports emergency services in non-3GPP access, or if the Emergency Registration procedure has failed for all PLMNs supporting emergency services in non-3GPP access, the UE notifies the user that an emergency session cannot be established.
If the UE is not equipped with a UICC, the UE shall perform the emergency N3IWF selection procedure above as if always in a visited country and without using the Non-3GPP Access Node Selection Information, i.e. the UE may construct the Operator Identifier based N3IWF FQDN format based on a PLMN ID obtained via implementation specific means.
When an N3IWF has been selected, the UE initiates an Emergency Registration. If the Emergency Registration fails, the UE shall select another PLMN supporting emergency services in non-3GPP access.
If the UE is attached to 5GC via an N3IWF that is located in the same country as the country in which the UE is currently located and the AMF has previously indicated support for emergency services over non-3GPP access as defined in clause 5.16.4.1, the UE reuses the existing N3IWF connection for emergency services. Otherwise, the UE terminates any existing N3IWF connection and performs PLMN and N3IWF or ePDG selection for emergency services.
If the UE is attached to EPC via an ePDG that has indicated support for the emergency services and is located in the same country as the country in which the UE is currently located, the UE reuses the existing ePDG connection for emergency services. Otherwise, the UE terminates the existing ePDG connection, if any, and performs PLMN and N3IWF or ePDG selection for emergency services.
PLMN and N3IWF or ePDG selection for emergency services is performed as follows:
If the UE is equipped with a UICC:
The UE determines whether it is located in the home country or a visited country;
If the UE is located in the home country the UE selects the Home PLMN for emergency services and selects an N3IWF or ePDG as follows:
If the Non-3GPP Access Node Selection Information for the HPLMN is available the UE selects first an N3IWF or ePDG based on the Non-3GPP Access Node type preference in the Non-3GPP Access Node Selection Information for the HPLMN. To select an N3IWF the UE uses the N3IWF identifier configuration (if available). If the N3IWF identifier configuration is not available, the UE constructs the FQDN format as indicated by the FQDN format in the Non-3GPP Access Node Selection Information for the HPLMN. To select an ePDG the UE selects the ePDG identified by the configured Emergency ePDG FQDN (if available). If the configured Emergency ePDG FQDN is not available, the UE constructs either the Tracking/Location Area Identity based Emergency ePDG FQDN or the Operator Identifier based Emergency ePDG FQDN as indicated by the FQDN format in the Non-3GPP Access Node Selection Information for the HPLMN.
If the Non-3GPP Access Node Selection Information is not available, the UE shall first attempt to select an N3IWF following the procedure defined in clause 6.3.6.2 before attempting to select an ePDG. To select an ePDG the UE selects the ePDG identified by the configured Emergency ePDG FQDN (if available). If the configured Emergency ePDG FQDN is not available, the UE constructs the Operator Identifier based Emergency ePDG FQDN.
If the UE is located in a visited country, the UE performs a DNS query using the Visited Country Emergency FQDN for N3IWF and using the Visited Country Emergency FQDN for ePDG, as specified in TS 23.003 to determine which PLMNs in the visited country support emergency services in non-3GPP access.
If the DNS responses contain one or more records, the UE selects a PLMN that supports emergency services in non-3GPP access for the UE. Each record in the DNS responses shall contain the identity of a PLMN in the visited country supporting emergency services in non-3GPP access via ePDG or N3IWF.
The UE shall consider these PLMNs based on their priorities in the Non-3GPP Access Node Selection Information. If the UE cannot select a PLMN in the Non-3GPP Access Node Selection Information or if non-3GPP Access Node Selection Information is not available, the UE shall attempt to select any PLMN in the list of PLMNs returned in the DNS response.
Once the UE has selected a PLMN the UE shall select an N3IWF or ePDG for the selected PLMN as follows:
If the Non-3GPP Access Node Selection Information for the PLMN is available the UE selects first an N3IWF or ePDG based on the Non-3GPP Access Node type preference in the Non-3GPP Access Node Selection Information for the PLMN. To select an N3IWF the UE constructs the FQDN format as indicated by the FQDN format in the Non-3GPP Access Node Selection Information for the PLMN. To select an ePDG the UE constructs either the Tracking/Location Area Identity based Emergency ePDG FQDN or the Operator Identifier based Emergency ePDG FQDN as indicated by the FQDN format in the Non-3GPP Access Node Selection Information for the PLMN.
If the Non-3GPP Access Node Selection Information is not available, the UE shall first attempt to select an N3IWF following the procedure defined in clause 6.3.6.2 before attempting to select an ePDG. To select an ePDG the UE constructs the Operator Identifier based Emergency ePDG FQDN.
If the DNS response does not contain any record, or if the DNS response contains one or more records but the UE fails to select a PLMN that supports emergency services in non-3GPP access, or if the Emergency Registration procedure has failed for all PLMNs supporting emergency services in non-3GPP access, the UE notifies the user that emergency session cannot be established.
If the UE is not equipped with a UICC, the UE shall perform the emergency ePDG/N3IWF selection procedure above as if always in a visited country and without using the Non-3GPP Access Node Selection Information, i.e. the UE may construct the Operator Identifier FQDN for N3IWF or ePDG based on a PLMN ID obtained via implementation specific means.
When a N3IWF has been selected, the UE initiates an Emergency Registration. If the Emergency Registration fails, the UE shall attempt to select an ePDG before selecting another PLMN supporting emergency services in non-3GPP access. When an ePDG has been selected, the UE initiates an Emergency Registration. If the Emergency Registration fails, the UE shall attempt to select a N3IWF before selecting another PLMN supporting emergency services in non-3GPP access.
Clause 6.3.7.0 describes the underlying principles for PCF selection and discovery:
There may be multiple and separately addressable PCFs in a PLMN.
The PCF must be able to correlate the AF service session established over N5 or Rx with the associated PDU Session (Session binding) handled over N7.
It shall be possible to deploy a network so that the PCF may serve only specific DN(s). For example, Policy Control may be enabled on a per DNN basis.
Unique identification of a PDU Session in the PCF shall be possible based on the (UE ID, DNN)-tuple, the (UE (IP or MAC) Address(es), DNN)-tuple and the (UE ID, UE (IP or MAC) Address(es), DNN).
PCF discovery and selection functionality is implemented in AMF, SMF and SCP, and follows the principles in clause 6.3.1. The AMF uses the PCF services for a UE and the SMF uses the PCF services for a PDU Session.
When the NF service consumer performs discovery and selection for a UE, the following applies:
The AMF may utilize the NRF to discover the candidate PCF instance(s) for a UE. In addition, PCF information may also be locally configured in the AMF. The AMF selects a PCF instance based on the available PCF instances obtained from the NRF or locally configured information in the AMF, depending on operator's policies.
In the non roaming case, the AMF selects a PCF instance for AM policy association and selects the same PCF instance for UE policy association. In the roaming case, the AMF selects a V-PCF instance for AM policy association and selects the same V-PCF instance for UE policy association. The following factors may be considered at PCF discovery and selection for Access and Mobility policies and UE policies:
SUPI; the AMF selects a PCF 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 PCF discovery.
S-NSSAI(s). In the roaming case, the AMF selects the V-PCF instance based on the S-NSSAI(s) of the VPLMN and selects the H-PCF instance based on the S-NSSAI(s) of the HPLMN.
PCF Set ID.
PCF Group ID of the UE's SUPI.
DNN replacement capability of the PCF.
Slice replacement capability of the PCF.
PCF Selection Assistance Info and PCF ID(s) serving the established PDU Sessions/PDN Connections received from UDM. In case PCF Selection Assistance Info and PCF ID(s) are received from the UDM, the AMF selects the same PCF instance serving the combination of DNN and S-NSSAI as indicated by the PCF Selection Assistance Info, if multiple DNN, S-NSSAI combinations are provided, the AMF selects the DNN,S-NSSAI using local configuration. In case PCF ID(s) are not received, e.g. EPS interworking is not supported, the AMF selects the PCF instance by considering other above factors.
When the NF service consumer performs discovery and selection for a PDU Session, the following applies:
The SMF may utilize the NRF to discover the candidate PCF instance(s) for a PDU Session. In addition, PCF information may also be locally configured in the SMF. The SMF selects a PCF instance based on the available PCF instances obtained from the NRF or locally configured information in the SMF, depending on operator's policies.
The following factors may be considered at PCF discovery and selection for a PDU session:
Local operator policies.
Selected Data Network Name (DNN).
S-NSSAI of the PDU Session. In the LBO roaming case, the SMF selects the PCF instance based on the S-NSSAI of the VPLMN. In the home routed roaming case, the H-SMF selects the H-PCF instance based on the S-NSSAI of the HPLMN.
SUPI; the SMF selects a PCF 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 PCF discovery.
PCF selected by the AMF for the UE.
MA PDU Session capability of the PCF, for an MA PDU session.
The PCF Group ID provided by the AMF to the SMF.
PCF Set ID.
Same PCF Selection Indication.
In the case of delegated discovery and selection in SCP, the SMF includes the factors b) - h), if available, in the first request.
The selected PCF instance for serving the UE and the selected PCF instance for serving a PDU session of this UE may be the same or may be different.
In the following scenarios, information about the PCF instance that has been selected (i.e. the PCF ID, PCF Set Id and, if PCF Set Id is not available, the PCF Group ID (if available)) may be forwarded to another NF. If the NF service consumer performs discovery and selection, this NF may use this PCF instance. If the NF service consumer performs delegated discovery and selection, this NF may include PCF ID, PCF Set Id and, if PCF Set Id is not available, the PCF Group ID (if available) in the request and the SCP may use this information to select the PCF instance (discovery may still be needed depending on what level of information is sent by the AMF, e.g. the address of the PCF instance may not be present):
When NF service consumer performs discovery and selection, the following applies:
During AMF relocation, the target AMF may receive a PCF ID, PCF Set Id and, if PCF Set Id is not available, the PCF Group ID (if available) from the source AMF to enable the usage of the same PCF by the target AMF, and the target AMF may decide based on operator policy either to use the same PCF or select a new PCF.
The AMF may, based on operator policies, forward the selected PCF to SMF instance(s) during the PDU Session Establishment procedure(s) to enable the usage of the same PCF for the AMF and the SMF instance(s). The SMF may decide based on operator policy either to use the same PCF or select a new PCF. If combination of the DNN and S-NSSAI of the PDU session matches one of the combination of the DNN and S-NSSAI included in the PCF Selection Assistance info received from UDM, the AMF shall forward Same PCF Selection Indication together with the selected PCF to SMF instance during the PDU Session Establishment procedure. In case that the Same PCF Selection Indication is received together with the PCF ID, the SMF shall select the same PCF instance for SM Policy Control.
In the roaming case, the AMF may, based on operator policies, e.g. roaming agreement, select the H-PCF in addition to the V-PCF for a UE by performing the PCF discovery and selection as described above. The AMF sends the H-PCF ID of the selected H-PCF instance to the V-PCF during the policy association establishment procedure.
When the SMF receives a a redirection indication with PCF ID from the PCF for the PDU session, the SMF shall terminate the current SM Policy Control association and reselects a PCF based on the received PCF ID. The SMF shall then establish an SM Policy Control association with the reselected PCF.
In the case of delegated discovery and selection in the SCP, the following applies:
The selected PCF instance may include the PCF Id, PCF Set Id and, if PCF Set Id is not available, the PCF Group ID (if available) in the response to the AMF.
The AMF first establishes an AM policy association; when forwarding the related request message the SCP discovers and selects a PCF instance. Unless binding information is provided in the response to that request the SCP adds the NF function producer ID it selected, i.e. PCF ID, into the response and the AMF uses the received PCF ID and available binding information as discovery and selection parameters for the request to establish the UE policy association towards the SCP. The SCP selects the (V-)PCF instance for UE policy association based on the received discovery and selection parameters.
During AMF relocation, the AMF may receive a PCF ID, PCF Set Id and, if PCF Set Id is not available, the PCF Group ID (if available) from the source AMF to enable the usage of the same PCF instance by the AMF. The AMF may decide based on operator policy either to use the old PCF instance or select another PCF instance. If the AMF decides to use the old PCF, the AMF includes the PCF ID PCF Set Id, and if PCF Set Id is not available, the PCF Group ID (if available) as received from the source AMF in the AM policy update request to the SCP.
The AMF may, based on operator policies, forward the selected PCF ID, PCF Set Id and, if PCF Set Id is not available, the PCF Group ID (if available) to the SMF during the PDU Session Establishment procedure to enable the usage of the same PCF for the AMF and the SMF. The SMF may include that information in the request in discovery and selection parameters to the SCP. The SCP may decide based on operator policy either to use the indicated PCF instance or select another PCF instance.
In the roaming case, the AMF performs discovery and selection of the H-PCF from NRF as described in this clause. The AMF may indicate the maximum number of H-PCF instances to be returned from NRF, i.e. H-PCF selection at NRF. The AMF uses the received V-PCF ID and available binding information received during the AM policy association procedure to send the UE policy association establishment request, which also includes the H-PCF ID, to the SCP. The SCP discovers and selects the V-PCF. The V-PCF sends an UE policy association establishment request towards the HPLMN, which includes the H-PCF ID as a discovery and selection parameter to SCP.
An authorized Application Function may, via the NEF, provide policy requirements that apply to multiple UE(s) (which, for example, belong to group of UE(s) defined by subscription or to any UE). Such policy requirements shall apply to any existing or future PDU Sessions that match the parameters in the AF request, and they may apply to multiple PCF instance(s).
After relevant validation of the AF request (and possible parameter mapping), the NEF stores this request received from the AF into the selected UDR instance as the Data Subset of the Application data. The possible parameter mapping includes mapping UE (group) identifiers provided by the AF to identifiers used within the 5GC, e.g. from GPSI to SUPI and/or from External Group Identifier to Internal-Group Identifier. Parameter mapping may also include mapping from the identifier of the Application Function towards internal identifiers such as the DNN and/or the S-NSSAI.
PCF(s) that need to receive AF requests that targets a DNN (and slice), and/or a group of UEs subscribe to receive notifications from the UDR about such AF request information. The PCF(s) can be configured (e.g. by OAM) to subscribe to receive notification of such AF request information from the UDR(s). The PCF(s) take(s) the received AF request information into account when making policy decisions for existing and future relevant PDU Sessions. In the case of existing PDU Sessions, the policy decision of the PCF instance(s) may trigger a PCC rule(s) change from the PCF to the SMF.
The PCF subscription to notifications of AF requests described above may take place during PDU Session Establishment or PDU Session Modification, when the PCF(s) receive request(s) from the SMF for policy information related to the DNN (and slice), and/or the Internal-Group Identifier of UEs. For the PCF(s) that have subscribed to such notifications, the UDR(s) notify the PCF(s) of any AF request update.
The NEF associates the AF request with information allowing to later modify or delete the AF request in the UDR; it associates the AF request with:
When the AF request targets PDU Sessions established by "any UE": the DNN, the slicing information target of the AF request,
When the request targets PDU Sessions established by UE(s) belonging to an Internal-Group: the DNN, the slicing information and the Internal-Group Identifier target of the application request.
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:
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.
UDM Group ID of the UE's SUPI.
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.
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):
UDR Group ID the UE's SUPI belongs to.
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.
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.
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.
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:
CHF Group ID of the UE's SUPI.
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.
Clause 6.3.12 specifies how a UE, which wants to establish connectivity via trusted non-3GPP access and is not operating in SNPN access mode, selects a PLMN and a trusted non-3GPP access network (TNAN) to connect to.
How the UE decides to use trusted non-3GPP access is not specified in this document. As an example, a UE may decide to use trusted non-3GPP access for connecting to 5GC in a specific PLMN based on:
the UE implementation-specific criteria; or
the UE configuration, e.g. the UE may be configured to try first the trusted non-3GPP access procedures; or
the UE capabilities, e.g. the UE may support only the trusted non-3GPP access procedures; or
the advertised capabilities of the discovered non-3GPP access networks, e.g. one or more available non-3GPP access networks advertise support of trusted connectivity to 5GC in a specific PLMN.
An example deployment scenario is schematically illustrated in Figure 6.3.12.1-1 below. In this scenario, the UE has discovered five non-3GPP access networks, which are WLAN access networks. These WLANs advertise information about the PLMNs they interwork with, e.g. by using the ANQP protocol, as defined in the HS2.0 specification [85]. Each WLAN may support "S2a connectivity" and/or "5G connectivity" to one or more PLMNs. Before establishing connectivity via trusted non-3GPP access, the UE needs to select (a) a PLMN, (b) a non-3GPP access network that provide trusted connectivity this this PLMN, and (c) a connectivity type, i.e. either "5G connectivity" or "S2a connectivity".
Each non-3GPP access network may advertise one or more of the following PLMN lists:
A PLMN List-1, which includes PLMNs with which "AAA connectivity" is supported. A non-3GPP access network supports "AAA connectivity" with a PLMN when it deploys an AAA function that can connect with a 3GPP AAA Server/Proxy in this PLMN, via an STa interface (trusted WLAN to EPC), or via an SWa interface (untrusted WLAN to EPC); see TS 23.402.
A PLMN List-2, which includes PLMNs with which "S2a connectivity" is supported. A non-3GPP access network supports "S2a connectivity" with a PLMN when it deploys a TWAG function that can connect with a PGW in this PLMN, via an S2a interface; see clause 16 of TS 23.402.
A PLMN List-3, which includes PLMNs with which "5G connectivity" is supported. A non-3GPP access network supports "5G connectivity" with a PLMN when it deploys a TNGF function that can connect with an AMF function and an UPF function in this PLMN via N2 and N3 interfaces, respectively; see clause 4.2.8.
When the UE wants to discover the PLMN List(s) supported by a non-3GPP access network and the non-3GPP access network supports ANQP, the UE shall send an ANQP query to the non-3GPP access network requesting "3GPP Cellular Network" information. If the non-3GPP access network supports interworking with one or more PLMNs, the response received by the UE includes a "3GPP Cellular Network" information element containing one or more of the above three PLMN Lists. The PLMN List-1 and the PLMN List-2 are specified in TS 23.402 and indicate support of interworking with EPC in one or more PLMNs. The PLMN List-3 is a list used to indicate support of interworking with 5GC in one or more PLMNs. When the non-3GPP access network does not support ANQP, how the UE discovers the PLMN List(s) supported by the non-3GPP access network is not defined in the present specification.
The UE determines if a non-3GPP access network supports "trusted connectivity" to a specific PLMN by receiving the PLMN List-2 and the PLMN List-3 advertised by this access network. If this PLMN is not included in any of these lists, then the non-3GPP access network can only support connectivity to an ePDG or N3IWF in the PLMN (i.e. "untrusted connectivity").
The steps below specify the steps executed by the UE when the UE wants to select and connect to a PLMN over trusted non-3GPP access. Note that the UE executes these steps before connecting to a trusted non-3GPP access network. This is different from the untrusted non-3GPP access (see clause 6.3.6, "N3IWF selection"), where the UE first connects to a non-3GPP access network, it obtains IP configuration and then proceeds to PLMN selection and ePDG/N3IWF selection. In the case of trusted non-3GPP access, the UE uses 3GPP-based authentication for connecting to a non-3GPP access, so it must first select a PLMN and then attempt to connect to a non-3GPP access.
The UE constructs a list of available PLMNs, with which trusted connectivity is supported. This list contains the PLMNs included in the PLMN List-2 and PLMN List-3, advertised by all discovered non-3GPP access networks. For each PLMN the supported type(s) of trusted connectivity is also included.
In the example shown in Figure 6.3.12.1-1, the list of available PLMNs includes:
The UE selects a PLMN that is included in the list of available PLMNs, as follows:
If the UE is connected to a PLMN via 3GPP access and this PLMN is included in the list of available PLMNs, the UE selects this PLMN. If this PLMN is not included in the list of available PLMNs, but it is included in the "Non-3GPP access node selection information" in the UE (see clause 6.3.6.1), the UE selects this PLMN and executes the combined ePDG/N3IWF selection procedure specified in clause 6.3.6.3.
Otherwise (the UE is not connected to a PLMN via 3GPP access, or the UE is connected to a PLMN via 3GPP access but this PLMN is neither in the list of available PLMNs nor in the "Non-3GPP access node selection information"), the UE determines the country it is located in by using implementation specific means.
If the UE determines to be located in its home country, then:
The UE selects the HPLMN, if included in the list of available PLMNs. Otherwise, the UE selects an E-HPLMN (Equivalent HPLMN), if an E-HPLMN is included in the list of available PLMNs. If the list of available PLMNs does not include the HPLMN and does not include an E-HPLMN, the UE stops the procedure and may attempt to connect via untrusted non-3GPP access (i.e. it may execute the N3IWF selection procedure specified in clause 6.3.6).
If the UE determines to be located in a visited country, then:
The UE determines if it is mandatory to select a PLMN in the visited country, as follows:
If the UE has IP connectivity (e.g. the UE is connected via 3GPP access), the UE sends a DNS query and receives a DNS response that indicates if a PLMN must be selected in the visited country. The DNS response includes also a lifetime that denotes how long the DNS response can be cached for. The FQDN in the DNS query shall be different from the Visited Country FQDN (see TS 23.003) that is used for ePDG/N3IWF selection. The DNS response shall not include a list of PLMNs that support trusted connectivity in the visited country, but shall only include an indication of whether a PLMN must be selected in the visited country or not.
If the UE has no IP connectivity (e.g. the UE is not connected via 3GPP access), then the UE may use a cached DNS response that was received in the past, or may use local configuration that indicates which visited countries mandate a PLMN selection in the visited country.
If the UE determines that it is not mandatory to select a PLMN in the visited country, and the HPLMN or an E-HPLMN is included in the list of available PLMNs, then the UE selects the HPLMN or an E-HPLMN, whichever is included in the list of available PLMNs.
Otherwise, the UE selects a PLMN in the visited country by considering, in priority order, the PLMNs, first, in the User Controlled PLMN Selector list and, next, in the Operator Controlled PLMN Selector list (see TS 23.122). The UE selects the highest priority PLMN in a PLMN Selector list that is also included in the list of available PLMNs;
If the list of available PLMNs does not include a PLMN that is also included in a PLMN Selector list, the UE stops the procedure and may attempt to connect via untrusted non-3GPP access.
In the example shown in Figure 6.3.12.1-1, the UE may select PLMN-c, for which "S2a connectivity" and "5G connectivity" is supported.
The UE selects the type of trusted connectivity ("S2a connectivity" or "5G connectivity") for connecting to the selected PLMN, as follows:
If the list of available PLMNs indicates that both "S2a connectivity" and "5G connectivity" is supported for the selected PLMN, then the UE shall select "5G connectivity" because it is the preferred type of trusted access.
Otherwise, if the list of available PLMNs indicates that only one type of trusted connectivity (either "S2a connectivity" or "5G connectivity") is supported for the selected PLMN, the UE selects this type of trusted connectivity.
In the example shown in Figure 6.3.12.1-1, the UE may select PLMN-c and "5G connectivity". There are two non-3GPP access networks that support "5G connectivity" to PLMN-c: the WLAN access network 2 and the WLAN access network 4.
Finally, the UE selects a non-3GPP access network to connect to, as follows:
The UE puts the available non-3GPP access networks in priority order. For WLAN access, the UE constructs a prioritized list of WLAN access networks by using the WLANSP rules (if provided) and the procedure specified in clause 6.6.1.3 of TS 23.503. When the UE supports the selection of Trusted access supporting the network slices it desires to use and has received extended WLANSP rule as specified in clause 6.6.1.1 of TS 23.503, the UE selects the non-3GPP access network with the SSID(s) which can access to the TNGF supporting the S-NSSAI needed by the UE. If the UE is not provided with WLANSP rules, the UE constructs the prioritized list of WLAN access networks by using an implementation specific procedure. For other types of non-3GPP access, the UE may use access specific information to construct this prioritized list.
From the prioritized list of non-3GPP access networks, the UE selects the highest priority non-3GPP access network that supports the selected type of trusted connectivity to the selected PLMN.
In the example shown in Figure 6.3.12.1-1, the UE selects either the WLAN access network 2 or the WLAN access network 4, whichever has the highest priority in the prioritized list of non-3GPP access networks.
Over the selected non-3GPP access network, the UE starts the 5GC registration procedure specified in clause 4.12a.2.2 of TS 23.502.
If the AMF detects the UE is using a wrong TNGF, the AMF may trigger a UE policy update and reject the UE registration
During the registration procedure the AMF may determine if the TNGF selected by the UE is suitable for the S-NSSAI(s) requested by the UE considering the UE subscription. If the AMF determines that a different TNGF should be selected, the AMF:
may, if the UE supports slice-based TNGF selection, trigger the UE Policy Association Establishment or UE Policy Association Update procedure to provide the UE with updated TNGF selection information as described in clause 6.15.2.1; when the AMF is informed by the PCF that the update of TNGF selection information on the UE is completed, the AMF may release UE Policy Association if it is not needed before proceeding to the Registration Reject;
shall send a Registration Reject message to the UE. The AMF may include target TNAN information (SSID, TNGF ID) in the Registration Reject so that the UE can, if supported by the UE, use the target TNAN information to try again to register to 5GC. The target TNAN information only applies to the one TNAN selection performed by the UE just after receiving the Registration Reject.
The AMF may determine the target TNAN based on the list of supported TAs and the corresponding list of supported slices for each TA obtained as defined in clause 5.15.8, and considering UE location.
As specified in clause 4.2.8.5, devices that do not support 5GC NAS signalling over WLAN access (referred to as "Non-5G-Capable over WLAN" devices, or N5CW devices for short), may access 5GC in a PLMN or an SNPN via a trusted WLAN access network that supports a TWIF function. The following clause specifies (a) how a N5CW device selects a PLMN and (b) how it selects a trusted WLAN access network that can provide "5G connectivity-without-NAS" to the selected PLMN. This selection procedure is called access network selection.
Each WLAN access network that provides "5G connectivity-without-NAS" advertises with ANQP a list of PLMNs with which "5G connectivity-without-NAS" is supported. This list is called PLMN List-4, and is different from the PLMN List-1, PLMN List-2 and PLMN List-3 defined in clause 6.3.12. A WLAN advertises the PLMN List-4, when the WLAN supports a TWIF function.
The steps executed by a N5CW device for access network selection are specified below and are very similar with the corresponding steps executed by a UE that supports NAS; see clause 6.3.12.2.
The N5CW device constructs a list of available PLMNs. This list contains the PLMNs included in the PLMN List-4 advertised by all discovered WLAN access networks.
The N5CW device discovers the PLMN List-4 advertised by all discovered WLAN access networks by sending an ANQP query to each discovered WLAN access network. The ANQP query shall request "3GPP Cellular Network" information. If a WLAN access network supports interworking with one or more PLMNs, the ANQP response received by the N5CW device includes a "3GPP Cellular Network" information element containing one or more of the following lists: PLMN List-1, PLMN List-2, PLMN List-3 and PLMN List-4. The PLMN List-1, PLMN List-2 and PLMN List-3 are defined in clause 6.3.12. The PLMN List-4 includes the PLMNs with which "5G connectivity-without-NAS" is supported.
The N5CW device selects a PLMN that is included in the list of available PLMNs as follows.
If the N5CW device is connected to a PLMN via 3GPP access and this PLMN is included in the list of available PLMNs, then the N5CW device selects this PLMN.
Otherwise (the N5CW device is not connected to a PLMN via 3GPP access, or the N5CW device is connected to a PLMN via 3GPP access but this PLMN is not in the list of available PLMNs):
If the N5CW device determines to be located in its home country, then:
The N5CW device selects the HPLMN if the N5CW device has a USIM or is pre-configured with an HPLMN, if the HPLMN is included in the list of available PLMNs. Otherwise, the N5CW device selects an E-HPLMN (Equivalent HPLMN), if an E-HPLMN is included in the list of available PLMNs. If the list of available PLMNs does not include the HPLMN and does not include an E-HPLMN, the N5CW device stops the access network selection procedure.
If the N5CW device determines to be located in its visited country, then:
The N5CW device determines if it is mandatory to select a PLMN in the visited country, as follows:
If the N5CW device has IP connectivity (e.g. it is connected via 3GPP access), the N5CW device sends a DNS query and receives a DNS response that indicates if a PLMN must be selected in the visited country. The DNS response includes a lifetime that denotes how long the DNS response can be cached.
If the N5CW device has no IP connectivity (e.g. it is not connected via 3GPP access), then the N5CW device may use a cached DNS response that was received in the past, or may use local configuration that indicates which visited countries mandate a PLMN selection in the visited country.
If the N5CW device determines that it is not mandatory to select a PLMN in the visited country, and the HPLMN or an E-HPLMN is included in the list of available PLMNs, then the N5CW device selects the HPLMN or an E-HPLMN, whichever is included in the list of available PLMNs.
Otherwise, the N5CW device selects a PLMN in the visited country as follows:
If the N5CW device has a USIM, the UE selects a PLMN in the visited country by considering, in priority order, the PLMNs, first, in the User Controlled PLMN Selector list and, next, in the Operator Controlled PLMN Selector list (see TS 23.122).
If the N5CW device does not have a USIM, the N5CW device selects the highest priority PLMN in a pre-configured list, which is also included in the list of available PLMNs.
If the list of available PLMNs does not include a PLMN that is also included in the pre-configured list(s), the N5CW device either stops the access network selection procedure, or may select a PLMN based on its own implementation.
Finally, the N5CW device selects a WLAN access network (e.g. an SSID) to connect to, following the procedure specified in clause 6.6.1.3 of TS 23.503, "UE procedure for selecting a WLAN access based on WLANSP rules", or any other implementation specific means.
After the N5CW device completes the above access network selection procedure, the N5CW device initiates the "Initial Registration and PDU Session Establishment" procedure specified in clause 4.12b.2 of TS 23.502.
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:
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:
Home Network Identifier (e.g. MNC and MCC, realm) of SUPI (by an NF consumer in the Serving network).
S-NSSAI of the HPLMN.
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.
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:
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:
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.