5.15.5.2.1 Registration to a set of Network Slices

When a UE registers over an Access Type with a PLMN, if the UE has either or both of:

• a Configured NSSAI for this PLMN;
• an Allowed NSSAI for this PLMN and Access Type;

the UE shall provide to the network, in AS layer under the conditions described in clause 5.15.9 and in NAS layer, a Requested NSSAI containing the S-NSSAI(s) corresponding to the Network Slice(s) to which the UE wishes to register, unless they are stored in the UE in the Pending NSSAI.

The Requested NSSAI shall be one of:

• the Default Configured NSSAI, i.e. if the UE has no Configured NSSAI nor an Allowed NSSAI for the serving PLMN;
• the Configured-NSSAI, or a subset thereof as described below, e.g. if the UE has no Allowed NSSAI for the Access Type for the serving PLMN;
• the Allowed-NSSAI for the Access Type over which the Requested NSSAI is sent, or a subset thereof; or
• the Allowed-NSSAI for the Access Type over which the Requested NSSAI is sent, or a subset thereof, plus one or more S-NSSAIs from the Configured-NSSAI not yet in the Allowed NSSAI for the Access Type as described below.

NOTE 1: If the UE wishes to register only a subset of the S-NSSAIs from the Configured NSSAI or the Allowed NSSAI, to be able to register with some Network Slices e.g. to establish PDU Sessions for some application(s) and the UE uses the URSP rules (which includes the NSSP) or the UE Local Configuration as defined in clause 6.1.2.2.1 of TS 23.503 [45], then the UE uses applicable the URSP rules or the UE Local Configuration to ensure that the S-NSSAIs included in the Requested NSSAI are not in conflict with the URSP rules or with the UE Local Configuration.

The subset of S-NSSAIs in the Configured-NSSAI provided in the Requested NSSAI consists of one or more S-NSSAI(s) in the Configured NSSAI applicable to this PLMN, if one is present and for which no corresponding S-NSSAI is already present in the Allowed NSSAI for the access type for this PLMN. The UE shall not include in the Requested NSSAI any S-NSSAI that is currently rejected by the network (i.e. rejected in the current registration area or rejected in the PLMN). For the registration to a PLMN for which neither a Configured NSSAI applicable to this PLMN or an Allowed NSSAI are present, the S-NSSAIs provided in the Requested NSSAI correspond to the S-NSSAI(s) in the Default Configured NSSAI unless the UE has HPLMN S-NSSAI for established PDU Session(s) in which case the HPLMN S-NSSAI(s) shall be provided in the mapping of Requested NSSAI in the NAS Registration Request message, with no corresponding VPLMN S-NSSAI in the Requested NSSAI. If the UE has been provided with NSSRG information together with the Configured NSSAI, the UE only includes in the Requested NSSAI S-NSSAIs that share a common NSSRG, see clause 5.15.12.2. If the UE has stored Pending NSSAI and the UE is still interested in the Pending NSSAI then all the S-NSSAIs in the Requested NSSAI and the Pending S-NSSAI shall share a common NSSRG.

When a UE registers over an Access Type with a PLMN, the UE shall also indicate in the Registration Request message when the Requested NSSAI is based on the Default Configured NSSAI.

The UE shall include the Requested NSSAI in the RRC Connection Establishment and in the establishment of the connection to the N3IWF/TNGF (as applicable) and in the NAS Registration procedure messages subject to conditions set out in clause 5.15.9. However, the UE shall not indicate any NSSAI in RRC Connection Establishment or Initial NAS message unless it has either a Configured NSSAI for the corresponding PLMN, an Allowed NSSAI for the corresponding PLMN and Access Type, or the Default Configured NSSAI. If the UE has HPLMN S-NSSAI(s) for established PDU Session(s), the HPLMN S-NSSAI(s) shall be provided in the mapping of Requested NSSAI in the NAS Registration Request message, independent of whether the UE has the corresponding VPLMN S-NSSAI. The (R)AN shall route the NAS signalling between this UE and an AMF selected using the Requested NSSAI obtained during RRC Connection Establishment or connection to N3IWF/TNGF respectively. If the (R)AN is unable to select an AMF based on the Requested NSSAI, it routes the NAS signalling to an AMF from a set of default AMFs. In the NAS signalling, if the UE is roaming, the UE provides the mapping of each S-NSSAI of the Requested NSSAI to a corresponding HPLMN S-NSSAI.

When a UE registers with a PLMN, if for this PLMN the UE has not included a Requested NSSAI nor a GUAMI while establishing the connection to the (R)AN, the (R)AN shall route all NAS signalling from/to this UE to/from a default AMF. When receiving from the UE a Requested NSSAI and a 5G-S-TMSI or a GUAMI in RRC Connection Establishment or in the establishment of connection to N3IWF/TNGF, if the 5G-AN can reach an AMF corresponding to the 5G-S-TMSI or GUAMI, then 5G-AN forwards the request to this AMF. Otherwise, the 5G-AN selects a suitable AMF based on the Requested NSSAI provided by the UE and forwards the request to the selected AMF. If the 5G-AN is not able to select an AMF based on the Requested NSSAI, then the request is sent to a default AMF.

When the AMF selected by the AN during Registration Procedure receives the UE Registration request, or after an AMF selection by MME (i.e. during EPS to 5GS handover) the AMF receives S-NSSAI(s) from SMF+PGW-C in 5GC:

• As part of the Registration procedure described in clause 4.2.2.2.2 of TS 23.502 [3], or as part of the EPS to 5GS handover using N26 interface procedure described in clause 4.11.1.2.2 of TS 23.502 [3], the AMF may query the UDM to retrieve UE subscription information including the Subscribed S-NSSAIs.
• The AMF verifies whether the S-NSSAI(s) in the Requested NSSAI or the S-NSSAI(s) received from SMF+PGW-C are permitted based on the Subscribed S-NSSAIs (to identify the Subscribed S-NSSAIs the AMF may use the mapping to HPLMN S-NSSAIs provided by the UE, in the NAS message, for each S-NSSAI of the Requested NSSAI).
• When the UE context in the AMF does not yet include an Allowed NSSAI for the corresponding Access Type, the AMF queries the NSSF (see (B) below for subsequent handling), except in the case when, based on configuration in this AMF, the AMF is allowed to determine whether it can serve the UE (see (A) below for subsequent handling). The discovery and selection of the NSSF is defined in clause 6.3.28.

NOTE 2: The configuration in the AMF depends on operator's policy.

• When the UE context in the AMF already includes an Allowed NSSAI for the corresponding Access Type, based on the configuration for this AMF, the AMF may be allowed to determine whether it can serve the UE (see (A) below for subsequent handling).
• AMF or NSSF may have previously subscribed to slice load level and/or Observed Service Experience and/or Dispersion Analytics related network data analytics for a Network Slice from NWDAF, optionally for an Area of Interest composed of one or several TAIs. If AMF subscribes to analytics, AMF may determine that it cannot serve the UE based on received analytics (see (A) below). If AMF subscribes to notifications on changes on the Network Slice or Network Slice instance availability information from NSSF optionally indicating a list of supported TAIs, it may determine that it cannot serve the UE after the restriction notification is received (see (A) below). If AMF does not subscribe to notifications on changes on the availability information from NSSF, NSSF may take the analytics information into account when AMF queries NSSF (see (B) below).

NOTE 3: The configuration in the AMF depends on the operator's policy.

(A) Depending on fulfilling the configuration as described above, the AMF may be allowed to determine whether it can serve the UE and the following is performed:

• For the mobility from EPS to 5GS, the AMF first derives the serving PLMN value(s) of S-NSSAI(s) based on the HPLMN S-NSSAI(s) in the mapping of Requested NSSAI (in CM-IDLE state) or the HPLMN S-NSSAI(s) received from SMF+PGW-C (in CM-CONNECTED state). After that the AMF regards the derived value(s) as the Requested NSSAI.
• For the inter PLMN within 5GC mobility, the new AMF derives the serving PLMN value(s) of S-NSSAI(s) based on the HPLMN S-NSSAI(s) in the mapping of Requested NSSAI. After that the AMF regards the derived value(s) as the Requested NSSAI.
• AMF checks whether it can serve all the S-NSSAI(s) from the Requested NSSAI present in the Subscribed S-NSSAIs (potentially using configuration for mapping S-NSSAI values between HPLMN and Serving PLMN), or all the S-NSSAI(s) marked as default in the Subscribed S-NSSAIs in the case that no Requested NSSAI was provided or none of the S-NSSAIs in the Requested NSSAI are permitted, i.e. do not match any of the Subscribed S-NSSAIs (see clause 5.15.3) or not available at the current UE's Tracking Area (see clause 5.15.8). If the AMF is configured with a local policy to include in the Allowed NSSAI subscribed S-NSSAIs that are not in the Requested NSSAI and some of the Subscribed S-NSSAIs are not supported by the AMF, the AMF queries the NSSF (see (B) below).
• If AMF has subscribed to slice load level and/or Observed Service Experience and/or Dispersion Analytics related network data analytics for a Network Slice from NWDAF, or if AMF had received a Network Slice restriction from NSSF that applies to the list of TAIs supported by the AMF, it may use that information to determine whether the AMF can serve the UE on the S-NSSAI(s) in the Requested NSSAI.
• If the AMF can serve the S-NSSAIs in the Requested NSSAI and any additional S-NSSAI added due to local policy as described below, the AMF remains the serving AMF for the UE. The Allowed NSSAI is then determined by taking into account the list of S-NSSAI(s) in the Requested NSSAI permitted based on the Subscribed S-NSSAIs and/or the list of S-NSSAI(s) for the Serving PLMN which are mapped to the HPLMN S-NSSAI(s) provided in the mapping of Requested NSSAI permitted based on the Subscribed S-NSSAIs, or, if neither Requested NSSAI nor the mapping of Requested NSSAI was provided or none of the S-NSSAIs in the Requested NSSAI are permitted, all the S-NSSAI(s) marked as default in the Subscribed S-NSSAIs and taking also into account the availability of the Network Slice instances as described in clause 5.15.8 that are able to serve the S-NSSAI(s) in the Allowed NSSAI in the current UE's Tracking Areas in addition to any Network Slice instance restriction for the S-NSSAI(s) in the Allowed NSSAI provided by the NSSF. The AMF based on local policy may determine to include in the Allowed NSSAI additional Subscribed S-NSSAIs e.g. Subscribed S-NSSAIs not marked as default and/or Subscribed S-NSSAIs that were not provided in the Requested NSSAI (See NOTE 4). If the AMF has received NSSRG Information for the Subscribed S-NSSAIs as part of the UE subscription information, it shall only include in the Allowed NSSAI S-NSSAIs that all share a common NSSRG (see clause 5.15.12). If at least one S-NSSAI in the Requested NSSAI is not available in the current UE's Tracking Area, then either the AMF may determine a Target NSSAI or step (B) is executed. The AMF also determines the mapping if the S-NSSAI(s) included in the Allowed NSSAI needs to be mapped to Subscribed S-NSSAI(s) values. If no Requested NSSAI is provided, or the mapping of the S-NSSAIs in Requested NSSAI to HPLMN S-NSSAIs is incorrect, or the Requested NSSAI includes an S-NSSAI that is not valid in the Serving PLMN, or the UE indicated that the Requested NSSAI is based on the Default Configured NSSAI, the AMF, based on the Subscribed S-NSSAI(s) and operator's configuration, may also determine the Configured NSSAI for the Serving PLMN and, if applicable, the associated mapping of the Configured NSSAI to HPLMN S-NSSAIs, so these can be configured in the UE. Then Step (C) is executed.

NOTE 4: The ability for the AMF to construct the Allowed NSSAI with values not contained in Requested NSSAI but permitted by subscribed NSSAI can be used to allow the UE to use newly-added S-NSSAI(s) in the case of Network Slicing Subscription Change (see clause 4.2.2.2.2 of TS 23.502 [3]).

• Else, the AMF queries the NSSF (see (B) below).

(B) When required as described above, the AMF needs to query the NSSF and the following is performed:

• The AMF queries the NSSF, with Requested NSSAI, Default Configured NSSAI Indication, mapping of Requested NSSAI to HPLMN S-NSSAIs, the Subscribed S-NSSAIs (with an indication if marked as default S-NSSAI), NSSRG Information (if provided by the UDM, see clause 5.15.12), any Allowed NSSAI it might have for the other Access Type (including its mapping to HPLMN S-NSSAIs), PLMN ID of the SUPI and UE's current Tracking Area. If the AMF has pending NSSAI for the UE then the AMF includes pending NSSAI in the Requested NSSAI.

NOTE 5: The Default Configured NSSAI Indication is provided when received from the UE or when the AMF indicates to the NSSF to return Configured NSSAI in case of the Network Slicing Subscription Change Indication is received from UDM.

• Based on this information, local configuration and other locally available information including RAN capabilities in the current Tracking Area for the UE or load level information for a Network Slice instance provided by the NWDAF, the NSSF does the following:
• It verifies which S-NSSAI(s) in the Requested NSSAI are permitted based on comparing the Subscribed S-NSSAIs with the S-NSSAIs in the mapping of Requested NSSAI to HPLMN S-NSSAIs. It considers the S-NSSAI(s) marked as default in the Subscribed S-NSSAIs in the case that no Requested NSSAI was provided or no S-NSSAI from the Requested NSSAI are permitted i.e. are not present in the Subscribed S-NSSAIs or not available e.g. at the current UE's Tracking Area. If NSSRG information is provided, the NSSF only selects S-NSSAIs that share a common NSSRG (see clause 5.15.12).
• If AMF has not subscribed to notifications on changes on the Network Slice or Network Slice instance availability information from NSSF and NSSF has subscribed to slice load level and/or Observed Service Experience and/or Dispersion Analytics related network data analytics for a Network Slice from NWDAF, NSSF may use the analytics information for the determination of the (Network Slice instance(s) and the) list of S-NSSAI(s) in the Allowed NSSAI(s) to serve the UE.
• It selects the Network Slice instance(s) to serve the UE. When multiple Network Slice instances in the UE's Tracking Area are able to serve a given S-NSSAI, based on operator's configuration, the NSSF may select one of them to serve the UE, or the NSSF may defer the selection of the Network Slice instance until a NF/service within the Network Slice instance needs to be selected.
• It determines the target AMF Set to be used to serve the UE, or, based on configuration, the list of candidate AMF(s), possibly after querying the NRF.

NOTE 6: If the target AMF(s) returned from the NSSF is the list of candidate AMF(s), the Registration Request message can only be redirected via the direct signalling between the initial AMF and the selected target AMF as described in clause 5.15.5.2.3. The NSSF does not provide the target AMF(s), when it provides a Target NSSAI in order to redirect or handover the UE to a cell of another TA as described in clause 5.3.4.3.3.

• It determines the Allowed NSSAI(s) for the applicable Access Type, by taking into account the list of S-NSSAI(s) in the Requested NSSAI permitted based on the Subscribed S-NSSAIs and/or the list of S-NSSAI(s) for the Serving PLMN which are mapped to the HPLMN S-NSSAIs provided in the mapping of Requested NSSAI permitted based on the Subscribed S-NSSAIs, or, if neither Requested NSSAI nor the mapping of Requested NSSAI was provided or none of the S-NSSAIs in the Requested NSSAI are permitted, all the S-NSSAI(s) marked as default in the Subscribed S-NSSAIs and taking also into account the availability of the Network Slice instances as described in clause 5.15.8 that are able to serve the S-NSSAI(s) in the Allowed NSSAI in the current UE's Tracking Areas and taking also into account local policy in the NSSF that may determine to include in the Allowed NSSAI additional Subscribed S-NSSAIs e.g. Subscribed S-NSSAIs not marked as default and/or Subscribed S-NSSAIs that were not provided in the Requested NSSAI (see NOTE 7). If NSSRG information applies, the NSSF only selects S-NSSAIs that share a common NSSRG (see clause 5.15.12).

NOTE 7: The ability for the NSSF to construct the Allowed NSSAI with values not contained in Requested NSSAI but permitted by Subscribed NSSAIs can be used to allow the UE to use newly-added S-NSSAI(s) in the case of Network Slicing Subscription Change (see clause 4.2.2.2.2 of TS 23.502 [3]).

• It also determines the mapping of each S-NSSAI of the Allowed NSSAI(s) to the Subscribed S-NSSAIs if necessary.
• Based on operator configuration, the NSSF may determine the NRF(s) to be used to select NFs/services within the selected Network Slice instance(s).
• Additional processing to determine the Allowed NSSAI(s) in roaming scenarios and the mapping to the Subscribed S-NSSAIs, as described in clause 5.15.6.
• If no Requested NSSAI is provided or the Requested NSSAI includes an S-NSSAI that is not valid in the Serving PLMN, or the mapping of the S-NSSAIs in Requested NSSAI to HPLMN S-NSSAIs is incorrect, the NSSF based on the Subscribed S-NSSAI(s) and operator configuration may also determine the Configured NSSAI for the Serving PLMN and, if applicable, the associated mapping of the Configured NSSAI to HPLMN S-NSSAIs, so these can be configured in the UE. The NSSF shall return a Configured NSSAI when receiving Default Configured NSSAI Indication from the AMF.
• If at least one S-NSSAI in the Requested NSSAI is not available in the current UE's Tracking Area, the NSSF may provide a Target NSSAI for the purpose of allowing the NG-RAN to redirect the UE to a cell of a TA in another frequency band supporting network slices not available in the current TA as described in clause 5.3.4.3.3.
• The NSSF returns to the current AMF the Allowed NSSAI for the applicable Access Type, the mapping of each S-NSSAI of the Allowed NSSAI to the Subscribed S-NSSAIs if determined and the target AMF Set, or, based on configuration, the list of candidate AMF(s). The NSSF may return the NRF(s) to be used to select NFs/services within the selected Network Slice instance(s) and the NRF to be used to determine the list of candidate AMF(s) from the AMF Set. The NSSF may return NSI ID(s) to be associated to the Network Slice instance(s) corresponding to certain S-NSSAIs. NSSF may return the rejected S-NSSAI(s) as described in clause 5.15.4.1. The NSSF may return the Configured NSSAI for the Serving PLMN and the associated mapping of the Configured NSSAI to HPLMN S-NSSAIs. The NSSF may return Target NSSAI as described in clause 5.3.4.3.3.
• Depending on the available information and based on configuration, the AMF may query the appropriate NRF (e.g. locally pre-configured or provided by the NSSF) with the target AMF Set. The NRF returns a list of candidate AMFs.
• If AMF Re-allocation is necessary, the current AMF reroutes the Registration Request or forwards the UE context to a target serving AMF as described in clause 5.15.5.2.3.
• Step (C) is executed.

(C) The serving AMF shall determine a Registration Area such that all S-NSSAIs of the Allowed NSSAI for this Registration Area are available in all Tracking Areas of the Registration Area (and also considering other aspects as described in clause 5.3.2.3 and clause 5.3.4.3.3) and then return to the UE this Allowed NSSAI and the mapping of the Allowed NSSAI to the Subscribed S-NSSAIs if provided. The AMF may return the rejected S-NSSAI(s) as described in clause 5.15.4.1.

NOTE 8: The S-NSSAIs in the Allowed NSSAI for Non-3GPP access are available homogeneously "in the PLMN" for the N3IWF case since a N3IWF providing access to a 5GC can be reached from any IP location. For other types of Non-3GPP access the S-NSSAIs in the Allowed NSSAI for Non-3GPP access can be not available homogeneously, for example different W-AGFs/TNGF(s) can be deployed in different locations and support different TAIs that support different network slices.

When either no Requested NSSAI was included, or the mapping of the S-NSSAIs in Requested NSSAI to HPLMN S-NSSAIs is incorrect, or a Requested NSSAI is not considered valid in the PLMN and as such at least one S-NSSAI in the Requested NSSAI was rejected as not usable by the UE in the PLMN, or the UE indicated that the Requested NSSAI is based on the Default Configured NSSAI, the AMF may update the UE slice configuration information for the PLMN as described in clause 5.15.4.2.

If the Requested NSSAI does not include S-NSSAIs which map to S-NSSAIs of the HPLMN subject to Network Slice-Specific Authentication and Authorization and the AMF determines that no S-NSSAI can be provided in the Allowed NSSAI for the UE in the current UE's Tracking Area and if no default S-NSSAI(s) could be added as described in step (A), the AMF shall reject the UE Registration and shall include in the rejection message the list of Rejected S-NSSAIs, each of them with the appropriate rejection cause value.

If the Requested NSSAI includes S-NSSAIs which map to S-NSSAIs of the HPLMN subject to Network Slice-Specific Authentication and Authorization, the AMF shall include in the Registration Accept message an Allowed NSSAI containing only those S-NSSAIs that are not to be subject to Network Slice-Specific Authentication and Authorization and, based on the UE Context in AMF, those S-NSSAIs for which Network Slice-Specific Authentication and Authorization for at least one of the corresponding HPLMN S-NSSAIs succeeded previously regardless the Access Type, if any.

The AMF shall also provide the list of Rejected S-NSSAIs, each of them with the appropriate rejection cause value.

If the AMF determined the Target NSSAI or received a Target NSSAI from the NSSF, the AMF should provide the Target NSSAI to the PCF for retrieving a corresponding RFSP as described in clause 5.3.4.3.1 or, if the PCF is not deployed, the AMF should determine a corresponding RFSP based on local configuration. Then the AMF provides the Target NSSAI and the corresponding RFSP to the NG-RAN as described in clause 5.3.4.3.3. The S-NSSAIs which map to S-NSSAIs of the HPLMN subject to an ongoing Network Slice-Specific Authentication and Authorization shall be included in the Pending NSSAI and removed from Allowed NSSAI. The Pending NSSAI may contain a mapping of the S-NSSAI(s) for the Serving PLMN to the HPLMN S-NSSAIs, if applicable. The UE shall not include in the Requested NSSAI any of the S-NSSAIs from the Pending NSSAI the UE stores, regardless of the Access Type.

If:

• all the S-NSSAI(s) in the Requested NSSAI are still to be subject to Network Slice-Specific Authentication and Authorization; or
• no Requested NSSAI was provided or none of the S-NSSAIs in the Requested NSSAI matches any of the Subscribed S-NSSAIs and all the S-NSSAI(s) marked as default in the Subscribed S-NSSAIs are to be subject to Network Slice-Specific Authentication and Authorization;

the AMF shall provide a "NSSAA to be performed" indicator and no Allowed NSSAI to the UE in the Registration Accept message. Upon receiving the Registration Accept message, the UE is registered in the PLMN but shall wait for the completion of the Network Slice-Specific Authentication and Authorization without attempting to use any service provided by the PLMN on any access, except e.g. emergency services (see TS 24.501 [47]), until the UE receives an allowed NSSAI.

Then, the AMF shall initiate the Network Slice-Specific Authentication and Authorization procedure as described in clause 5.15.10 for each S-NSSAI that requires it, except, based on Network policies, for those S-NSSAIs for which Network Slice-Specific Authentication and Authorization have been already initiated on another Access Type for the same S-NSSAI(s). At the end of the Network Slice-Specific Authentication and Authorization steps, the AMF by means of the UE Configuration Update procedure shall provide a new Allowed NSSAI to the UE which also contains the S-NSSAIs subject to Network Slice-Specific Authentication and Authorization for which the authentication and authorization is successful. The AMF may perform AMF selection when NSSAA completes for the S-NSSAIs subject to NSSAA. If an AMF change is required, this shall be triggered by the AMF using the UE Configuration Update procedure indicating a UE re-registration is required. The S-NSSAIs which were not successfully authenticated and authorized are not included in the Allowed NSSAI and are included in the list of Rejected S-NSSAIs with a rejection cause value indicating Network Slice-Specific Authentication and Authorization failure.

Once completed the Network Slice-Specific (re-)Authentication and (re-)Authorization procedure, if the AMF determines that no S-NSSAI can be provided in the Allowed NSSAI for the UE, which is already authenticated and authorized successfully by a PLMN and if no default S-NSSAI(s) could be added as described in step (A), the AMF shall execute the Network-initiated Deregistration procedure described in clause 4.2.2.3.3 of TS 23.502 [3] and shall include in the explicit De-Registration Request message the list of Rejected S-NSSAIs, each of them with the appropriate rejection cause value.

If an S-NSSAI is rejected with a rejection cause value indicating Network Slice-Specific Authentication and Authorization failure or revocation, the UE can re-attempt to request the S-NSSAI based on policy, local in the UE.