Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.501  Word version:   16.4.0

Top   Up   Prev   Next
1…   3…   4…   4.2.4   4.2.5…   4.2.8…   4.2.8.2.2   4.2.8.2.3…   4.2.8.4…   4.2.9…   4.3…   4.3.3   4.3.4   4.3.5   4.4…   4.4.6…   4.4.8   5…   5.3…   5.3.3…   5.4…   5.5…   5.6…   5.6.7…   5.7…   5.7.2…   5.7.3…   5.7.4   5.7.5…   5.8…   5.8.2.11…   5.9…   5.10…   5.11…   5.15…   5.16…   5.17…   5.18…   5.19…   5.21…   5.22…   5.27…   5.28…   5.29…   5.30…   5.31…   5.32…   5.33…   5.34…   5.35…   6…   6.3…   7…   7.2…   8…   8.2.4   8.2.5…   8.3…   A…   D…   E…   F   G…   G.3   G.4…   J…

 

6.3  Principles for Network Function and Network Function Service discovery and selection
6.3.1  General
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 TS 23.502, clauses 4.17.4, 4.17.5, 4.17.9 and 4.17.10.
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.
NOTE 1:
NRF can be colocated together with SCP e.g. for communication option D, depicted in Annex E.
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 TS 23.502, clause 4.17.1.
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.
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.
NOTE 2:
For delegated discovery of the HSS or the UDM, the SCP can rely on the NRF to discover the group of HSS/UDM instance(s) serving the provided user identity, or in some deployments the SCP can first query the UDR for the HSS/UDM Group ID for the provided user identity. It is expected that the stage 3 defines a single encoding for the user identity provided by the service consumer that can be used for both variants of delegated discovery to avoid that the service consumer needs to be aware of the SCP behaviour.
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.
NOTE 3:
Refer to TS 29.510 for details on using the validity period.
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).
NOTE 4:
In a given PLMN, Direct Communication, Indirect Communication, or both may apply.
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 TS 23.502, clauses 4.17.7 and 4.17.8.
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.
NOTE 5:
See TS 29.510 for details on using the target PLMN ID specific query to reach the NRF in the remote PLMN.
For topology hiding, see clause 6.2.17.
Up
6.3.1.0  Principles for Binding, Selection and Reselection [R16]Word-p. 342
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 can 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.
NOTE 1:
Subscription request messages can contain both a Binding Indication and a Routing Binding Indication.
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.
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.
NOTE 2:
The NF service can either be a standardised service as per this specification or a custom service. The custom service can be used for the sole purpose of registering endpoint address(es) to receive notifications at the NRF.
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 of the NF registered in the NRF at NF Profile level 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 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 in the 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 of the NF registered in the NRF at NF Profile level 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 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).
NOTE 3:
Such a request message can be used for implicit subscription.
NOTE 4:
Request messages can contain both the Binding Indications for services and for notifications, and in addition, the Routing Binding Indication in the case of indirect communication.
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
Level of Binding Indication
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 (NOTE 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) (Note 2)
NF Service Set ID, NF Instance ID, NF Set ID, Service name (NOTE 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 (NOTE 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 (NOTE 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.

Up
6.3.1.1  NF Discovery and Selection aspects relevant with indirect communication [R16]Word-p. 344
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.
Up
6.3.1.2  Location information [R16]
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.
NOTE:
The location information in TS 29.510 specifies the granularity of location information. It is up to each deployment to determine the granularity of location information to be used.
6.3.2  SMF discovery and selectionWord-p. 345
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.
NOTE 1:
Protocol aspects of the access to NRF are specified in TS 29.510.
The SMF selection functionality is applicable to both 3GPP access and non-3GPP access.
The SMF selection for Emergency services is described in clause 5.16.4.5.
The following factors may be considered during the SMF selection:
  1. Selected Data Network Name (DNN). In the case of the home routed roaming, the DNN is not applied for the V-SMF selection.
  2. S-NSSAI of the HPLMN (for non-roaming and home-routed roaming scenarios), and S-NSSAI of the VPLMN (for roaming with local breakout and home-routed roaming scenarios).
  3. NSI-ID.
    NOTE 2:
    The use of NSI -ID in the network is optional and depends on the deployment choices of the operator. If used, the NSI ID is associated with S-NSSAI.
  4. Access technology being used by the UE.
  5. Support for Control Plane CIoT 5GS Optimisation.
  6. Subscription information from UDM, e.g.
    • per DNN: whether LBO roaming is allowed.
    • per S-NSSAI: the subscribed DNN(s).
    • per (S-NSSAI, subscribed DNN): whether LBO roaming is allowed.
    • per (S-NSSAI, subscribed DNN): whether EPC interworking is supported.
    • per (S-NSSAI, subscribed DNN): whether selecting the same SMF for all PDU sessions to the same S-NSSAI and DNN is required.
  7. Void.
  8. Local operator policies.
    NOTE 3:
    These policies can take into account whether the SMF to be selected is an I-SMF or a V-SMF or a SMF.
  9. Load conditions of the candidate SMFs.
  10. Analytics (i.e. statistics or predictions) for candidate SMFs' load as received from NWDAF (see TS 23.288), if NWDAF is deployed.
  11. UE location (i.e. TA).
  12. Service Area of the candidate SMFs.
  13. Capability of the SMF to support a MA PDU Session.
  14. If interworking with EPS is required.
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).
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.
Up
6.3.3  User Plane Function SelectionWord-p. 347
6.3.3.1  Overview
The selection and reselection of the UPF 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.
For 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 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.
Up
6.3.3.2  SMF Provisioning of available UPF(s)
SMF may be locally configured with the information about the available UPFs, e.g. by OA&M system when UPF is instantiated or removed.
NOTE 1:
UPF information can be updated e.g. by OA&M system any time after the initial provisioning, or UPF itself updates its information to the SMF any time after the node level interaction is established.
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 TS 23.502, clause 4.17.
Up
6.3.3.3  Selection of an UPF for a particular PDU Session
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 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. FQDN or IP address) of N3 terminations provided by a W-AGF or a TNGF;
  • 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 (ATSSS-LL capability, MPTCP capability, or both).
  • 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).
NOTE:
How the SMF determines information about the user plane network topology from information listed above, and what information is considered by the SMF, is based on operator configuration.
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.
Up
6.3.4  AUSF discovery and selectionWord-p. 349
In the case of NF consumer based discovery and selection, the following applies:
  • The AMF performs AUSF selection to allocate an AUSF Instance that performs authentication between the UE and 5G CN in the HPLMN. The AMF shall utilize the NRF to discover the AUSF instance(s) unless AUSF information is available by other means, e.g. locally configured on AMF. The AUSF selection function in the AMF selects an AUSF instance based on the available AUSF instances (obtained from the NRF or locally configured in the AMF).
  • The UDM shall utilize the NRF to discover the AUSF instance(s) unless AUSF information is available by other means, e.g. locally configured on UDM. The UDM selects an AUSF instance based on the available AUSF instance(s) obtained from the NRF or based on locally configured information, and information stored (by the UDM) from a previously successful authentication.
AUSF selection is applicable to both 3GPP access and non-3GPP access.
The AUSF selection function in AUSF NF consumers or in SCP should consider one of the following factors when available:
  1. Home Network Identifier (e.g., MNC and MCC) of SUCI/SUPI (by an NF consumer in the Serving network) along with NID in the case of SNPN and Routing Indicator.
  2. NOTE 1:
    The UE provides the Routing Indicator to the AMF as part of the SUCI as defined in TS 23.003 during initial registration. The AMF can provide the UE's Routing Indicator to other AMFs as described in TS 23.502.
    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.
  3. AUSF Group ID the UE's SUPI belongs to.
  4. NOTE 2:
    The AMF can infer the AUSF Group ID the UE's SUPI belongs to, based on the results of AUSF discovery procedures with NRF. The AMF provides the AUSF Group ID the SUPI belongs to other AMFs as described in TS 23.502.
  5. 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.
  6. In the case of delegated discovery and selection in SCP, the AUSF NF consumer shall send all available factors to the SCP.
Up
6.3.5  AMF discovery and selection
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.
5G-AN selects an AMF Set and an AMF from the AMF Set under the following circumstances:
  1. When the UE provides no 5G-S-TMSI nor the GUAMI to the 5G-AN.
  2. When the UE provides 5G-S-TMSI or GUAMI but the routing information (i.e. AMF identified based on AMF Set ID, AMF pointer) present in the 5G-S-TMSI or GUAMI is not sufficient and/or not usable (e.g. UE provides GUAMI with an AMF region ID from a different region).
  3. AMF has instructed AN that the AMF (identified by GUAMI(s)) is unavailable and no target AMF is identified and/or AN has detected that the AMF has failed.
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.
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; and
  • Category M Indication.
AMF selection functionality in the 5G-AN or CP NFs or SCP considers the following factors for selecting an AMF from AMF Set:
  • Availability of candidate AMF(s).
  • Load balancing across candidate AMF(s) (e.g. considering weight factors of candidate AMFs in the AMF Set).
  • In 5G-AN, 5G CIoT features indicated in RRC signalling by the UE.
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 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 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 in 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 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 provides the source AMF Set ID, source 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 belonging to the target AMF set in target AMF Region which can be the mapping of the source AMF set in source AMF region.
  • 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.
Up
6.3.6  N3IWF selectionWord-p. 351
6.3.6.1  General
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:
  1. ePDG identifier configuration: It contains the FQDN or IP address of the ePDG in the HPLMN, as specified in TS 23.402, clause 4.5.4.3. This is used only when the UE supports connectivity with ePDG and attempts to select an ePDG. It is ignored in all other cases.
  2. N3IWF identifier configuration: It contains the FQDN or IP address of the N3IWF in the HPLMN.
  3. 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 TS 23.402, clause 4.5.4.4) 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.
The ePDG identifier configuration and the N3IWF identifier 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 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 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.
Up
6.3.6.2  Stand-alone N3IWF selectionWord-p. 352
The UE performs N3IWF selection based on the ePDG selection procedure as specified in the TS 23.402, clause 4.5.4 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.
  • The ePDG identifier configuration and the ePDG selection information are substituted by the N3IWF identifier configuration and the Non-3GPP access node selection information respectively. The UE shall give preference to the N3IWF in all PLMNs in the Non-3GPP access node selection information independent of the "Preference" parameter.
Network slice information cannot be used for N3IWF selection in this Release of the specification.
Accessing a standalone non-public network service via a PLMN, the UE uses a configured N3IWF FQDN to select an N3IWF deployed in the NPN.
Up
6.3.6.3  Combined N3IWF/ePDG 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 first select a PLMN in which the non-3GPP access node should be selected by using the procedure specified in TS 23.402, clause 4.5.4.4 with the following modifications:
  • Instead of using the ePDG selection information the UE uses the Non-3GPP access node selection information.
In the selected PLMN the UE shall attempt to select a non-3GPP access node as follows:
  1. 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.
  2. 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.
  3. 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 in TS 23.402, clause 4.5.4.5.
  4. 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 TS 23.402, clause 4.5.4.4, 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 TS 23.402, clause 4.5.4.5.
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.
NOTE:
A UE performing both a selection for an IMS service and a selection for a non-IMS service could get simultaneously attached to a N3IWF and to an ePDG in the same PLMN or in different PLMNs.
Up
6.3.6.4  PLMN Selection for emergency servicesWord-p. 353
UE initiates PLMN 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.
Unless the UE is attached to 5GC via an N3IWF or to EPC via an ePDG that has indicated support for the emergency services and is located in the same country the UE is currently located in, the UE deregisters from the 5G Core non-3GPP access or terminates the existing ePDG connection, if any, and performs PLMN selection for emergency services. Otherwise, the UE should reuse the existing N3IWF or ePDG connection.
PLMN selection for emergency services is performed as follows:
  • The UE determines whether it is located in the home country or a visited country;
  • If the UE is located in the home country, and the UE is equipped with a UICC, then the UE selects the PLMN for emergency services based on the configured Operator Identifier Emergency FQDN;
  • If the UE is located in a visited country, the UE performs a DNS query using the Visited Country Emergency FQDN, as specified in TS 23.003 to discover the regulatory requirements and to determine which PLMNs in the visited country support emergency services in non-3GPP access.
    • If the DNS response contains 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 response shall contain the identity of a PLMN in the visited country supporting emergency services in non-3GPP access.
    • 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, it shall attempt to select any PLMN in the list of PLMNs returned in the DNS response.
    • 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.
When a PLMN has been selected, the UE determines whether to proceed with N3IWF selection or with ePDG selection in that PLMN according to the Non-3GPP Access Node Selection Information for that PLMN. For ePDG selection, the UE shall use the Operator Identifier Emergency FQDN and the Tracking/Location Area Identity Emergency FQDN as specified in TS 23.401 clause 4.5.4a.2.
If the UE is not equipped with a UICC, the UE shall perform the emergency ePDG/N3IWF selection procedure without using the Non-3GPP Access Node Selection Information, i.e., the UE may construct the Operator Identifier FQDN format 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.
Up
6.3.7  PCF discovery and selectionWord-p. 354
6.3.7.0  General principles
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).
Up
6.3.7.1  PCF discovery and selection for a UE or a PDU Session
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.
  • NOTE 1:
    The AMF can infer the PCF Group ID the UE's SUPI belongs to, based on the results of PCF discovery procedures with NRF. The AMF provides the PCF Group ID the SUPI belongs to to other PCF NF consumers as described in TS 23.502.
  • DNN replacement capability of the PCF.
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:
    1. Local operator policies.
    2. Selected Data Network Name (DNN).
    3. 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.
    4. 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.
    5. PCF selected by the AMF for the UE.
    6. MA PDU Session capability of the PCF, for an MA PDU session.
    7. The PCF Group ID provided by the AMF to the SMF.
    8. PCF Set ID.
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 and if available PCF Group ID may be forwarded to another NF. If the NF service consumer performs discovery and selection, this NF may use this PCF instance. In the case of delegated discovery and selection, this NF may include PCF ID and if available PCF Group ID 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 and if available the PCF Group ID 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.
  • 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 Group ID in the response to the AMF.
  • NOTE 2:
    The selected (V-)PCF instance can include the binding indication, including the (V-)PCF ID and possibly PCF Set ID in the response to the AMF as described in clause 6.3.1.0.
  • 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 and if available a PCF Group ID 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, and if available the PCF Group ID 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 and if available the PCF Group ID 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.
Up
6.3.7.2  Providing policy requirements that apply to multiple UE and hence to multiple PCFWord-p. 356
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).
NOTE:
Application Function influence on traffic routing described in clause 5.6.7 is an example of such requirement.
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 AF transaction identifier in the AF request.
Up
6.3.7.3  Binding an AF request targeting a UE address to the relevant PCFWord-p. 357
Binding an AF request to the relevant PCF instance is described in TS 23.503.
6.3.8  UDM discovery and selection
The NF consumer or the SCP performs UDM discovery to discover a UDM instance that manages the user subscriptions.
If the NF consumer performs discovery and selection, the NF consumers shall utilize the NRF to discover the UDM instance(s) unless UDM information is available by other means, e.g. locally configured on NF consumers. The UDM selection function in NF consumers selects a UDM instance based on the available UDM instances (obtained from the NRF or locally configured).
The UDM selection functionality is applicable to both 3GPP access and non-3GPP access.
The UDM selection functionality in NF consumer or in SCP should consider one of the following factors:
  1. Home Network Identifier (e.g. MNC and MCC) of SUCI/SUPI, along with NID in the case of SNPN, and UE's Routing Indicator.
  2. NOTE 1:
    The UE provides the Routing Indicator to the AMF as part of the SUCI as defined in TS 23.003 during initial registration. The AMF provides the UE's Routing Indicator to other NF consumers (of UDM) as described in TS 23.502.
    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.
  3. UDM Group ID of the UE's SUPI.
  4. NOTE 2:
    The AMF can infer the UDM Group ID the UE's SUPI belongs to, based on the results of UDM discovery procedures with NRF. The AMF provides the UDM Group ID the SUPI belongs to other UDM NF consumers as described in TS 23.502.
  5. 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.
  6. 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.
Up
6.3.9  UDR discovery and selection
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.
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 TS 23.502, clause 5.2.12). Additionally, the UDR selection function in UDR NF consumers should consider one of the following factors when available to the UDR NF consumer:
  1. UDR Group ID the UE's SUPI belongs to.
  2. SUPI; e.g. the UDR NF consumer selects a UDR instance based on the SUPI range the UE's SUPI belongs to or based on the results of a discovery procedure with NRF using the UE's SUPI as input for UDR discovery.
  3. GPSI or External Group ID; e.g. UDR NF consumers select a UDR instance based on the GPSI or External Group ID range the UE's GPSI or External Group ID belongs to or based on the results of a discovery procedure with NRF using the UE's GPSI or External Group ID as input for UDR discovery.
In the case of delegated discovery and selection, the NF consumer shall include the available factors in the request towards SCP.
Up
6.3.10  SMSF discovery and selectionWord-p. 358
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.
Up
6.3.11  CHF discovery and selection
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 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:
The address(es) of the CHF shall be applicable for all services provided by the CHF.
The CHF address(es) that a stored in the UDR or configured in the PCF may be complemented by the associated CHF instance ID(s) and CHF set ID(s) (see clause 6.3.1.0) stored or configured in the same location.
The CHF address(es) retrieved from the UDR and possible associated CHF instance ID(s) and CHF set ID(s) take precendence over the locally configured CHF address(es) and possible associated CHF instance ID(s) and CHF set ID(s), and over the CHF address(es) discoverred by the NRF. If no CHF address(es) is received from the UDR, the PCF selects, based on operator policies, either the CHF addresse(es) provided by NRF, or the locally configured CHF address(es) and possible associated CHF instance ID(s) and CHF set ID(s).
If the PCF has a CHF set ID but no CHF instance ID associated to the CHF address(es) in the same location, the CHF instance within the CHF set may change. If the PCF is not able to reach the CHF address(es), it should query the NRF for other CHF instances within the CHF set.
If the PCF received a CHF set ID and a CHF instance ID associated to the CHF address(es) in the same location, the CHF service instance within the CHF may change. If an PCF is not able to reach the CHF address(es), it should query the NRF for other CHF service instances within the CHF.
To enable the SMF to select the same CHF that is selected by the PCF for a PDU Session, the PCF provides the selected CHF address(es) and, if available, the associated CHF instance ID(s) and/or CHF set ID(s) in the PDU Session related policy information to the SMF as described in Table 6.4-1 of TS 23.503 and the SMF applies them as defined in clause 5.1.8 of TS 32.255. Otherwise, the SMF selection of the CHF as defined in clause 5.1.8 of TS 32.255 applies.
How the CHF is selected by the AMF is defined in clause 5.1.3 of TS 32.256.
How the CHF is selected by the SMSF is defined in clause 5.4 of TS 32.274.
If the NF consumer performs discovery and selection via NRF, the CHF selection function in NF consumers selects a CHF instance based on the available CHF instances obtained from the NRF.
The CHF selection functionality in NF consumer or in SCP should consider one of the following factors:
  1. CHF Group ID of the UE's SUPI.
  2. NOTE:
    The NF Consumer can infer the CHF Group ID the UE's SUPI belongs to, based on the results of CHF discovery procedures with NRF.
  3. 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.
Up
6.3.12  Trusted Non-3GPP Access Network selection [R16]Word-p. 359
6.3.12.1  General
Clause 6.3.12 specifies how a UE, which wants to establish connectivity via trusted non-3GPP access, 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:
  1. 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.
  2. 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 TS 23.402, clause 16.
  3. 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").
Up
6.3.12.2  Access Network Selection ProcedureWord-p. 361
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.
Step 1.
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.
  1. In the example shown in Figure 6.3.12.1-1, the list of available PLMNs includes:
    • PLMN-a: "S2a connectivity", "5G connectivity"
    • PLMN-b: "5G connectivity"
    • PLMN-c: "S2a connectivity", "5G connectivity"
    • PLMN-d: "S2a connectivity"
Step 2.
The UE selects a PLMN that is included in the list of available PLMNs, as follows:
  1. 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.
  2. 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.
    1. 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).
    2. 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.
    c. 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.
Step 3.
The UE selects the type of trusted connectivity ("S2a connectivity" or "5G connectivity") for connecting to the selected PLMN, as follows:
  1. 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.
  2. 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.
  3. 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.
Step 4.
Finally, the UE selects a non-3GPP access network to connect to, as follows:
  1. The UE puts the available non-3GPP access networks in priority order. For WLAN access, the UE constructs this prioritized list by using the WLANSP rules (if provided). For other types of non-3GPP access, the UE may use access specific information to construct this prioritized list.
  2. 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.
  3. 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.
  4. Over the selected non-3GPP access network, the UE starts the 5GC registration procedure specified in TS 23.502, clause 4.12a.2.2.
Up
6.3.12a  Access Network selection for devices that do not support 5GC NAS over WLAN [R16]Word-p. 363
6.3.12a.1  General
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 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.
Up
6.3.12a.2  Access Network Selection Procedure
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.
Step 1.
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.
  1. 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.
Step 2.
The N5CW device selects a PLMN that is included in the list of available PLMNs as follows.
  1. 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.
  2. 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):
    1. 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.
    2. 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.
Step 3.
Finally, the N5CW device selects a WLAN access network (e.g. an SSID) to connect to, as follows:
  1. The N5CW device puts the available WLAN access networks in priority order. The N5CW device constructs this prioritized list by using the WLANSP rules (if they have been received via 3GPP access), or any other implementation specific means.
  2. From the prioritized list of WLAN access networks, the N5CW device selects the highest priority WLAN access network that supports "5G connectivity-without-NAS" to the PLMN selected in step 2.
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 TS 23.502, clause 4.12b.2.
Up
6.3.13  NWDAF discovery and selection [R16]Word-p. 364
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. The NWDAF selection function in NF consumers selects an NWDAF instance based on the available NWDAF instances.
The following factors may be considered by the NF consumer for NWDAF selection:
  • S-NSSAI.
  • Analytics ID(s).
  • NWDAF Serving Area information, i.e. list of TAIs for which the NWDAF can provide analytics.
Up
6.3.14  NEF Discovery [R16]Word-p. 365
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.
NOTE:
The NEF discovery and selection procedures described in this clause are intended to be applied by NF consumers deployed within the operator's domain.
The following factors may be considered for NEF selection:
Up
6.3.15  UCMF Discovery and Selection [R16]
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.

Up   Top   ToC