Section: 5.15.4.1.1 UE Network Slice configuration
Content: The Network Slice configuration information contains one or more Configured NSSAI(s). A Configured NSSAI may either be configured by a Serving PLMN and apply to the Serving PLMN, or may be a Default Configured NSSAI configured by the HPLMN and that applies to any PLMNs for which no specific Configured NSSAI has been provided to the UE. There is at most one Configured NSSAI per PLMN. NOTE 1: The value(s) used in the Default Configured NSSAI are expected to be commonly decided by all roaming partners, e.g. by the use of values standardized by 3GPP or other bodies. The Default Configured NSSAI, if it is configured in the UE, is used by the UE in a Serving PLMN only if the UE has no Configured NSSAI for the Serving PLMN. The Configured NSSAI of a PLMN may include S-NSSAIs that have standard values or PLMN-specific values. The Configured NSSAI for the Serving PLMN includes the S-NSSAI values which can be used in the Serving PLMN and may be associated with mapping of each S-NSSAI of the Configured NSSAI to one or more corresponding HPLMN S-NSSAI values. In the non-roaming case, the network shall not provide any mapped S-NSSAI to the UE with the Configured NSSAI. In the roaming case, the AMF shall provide to the UE the mapping of each S-NSSAI of the Configured NSSAI for the Serving PLMN to the corresponding S-NSSAI values of the HPLMN when providing NSSAI information, as described in TS 24.501[ Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3 ]  [47]. A UE subscription may contain Network Slice Simultaneous Registration Group (NSSRG) information. If so, the UE configuration is performed as described in clause 5.15.12.2. The UE may be pre-configured with the Default Configured NSSAI. The UE may be provisioned/updated with the Default Configured NSSAI, determined by the UDM in the HPLMN, using the UE Parameters Update via UDM Control Plane procedure defined in clause 4.20 of TS 23.502[ Procedures for the 5G System (5GS) ]  [3]. Each S-NSSAI in the Default Configured NSSAI may have a corresponding S-NSSAI as part of the Subscribed S-NSSAI(s). Consequently, if the Subscribed S-NSSAI(s) which are also present in the Default Configured NSSAI are updated the UDM should update the Default Configured NSSAI in the UE. In the HPLMN, the S-NSSAIs in the Configured NSSAI provided as described in clause 5.15.4.2, at the time when they are provided to the UE, shall match the Subscribed S-NSSAIs for the UE. When the Subscribed S-NSSAI(s) are updated (i.e. some existing S-NSSAIs are removed and/or some new S-NSSAIs are added) and one or more are applicable to the Serving PLMN the UE is registered in, as described in clause 5.15.3, or when the associated mapping is updated the AMF shall update the UE with the Configured NSSAI for the Serving PLMN and/or Allowed NSSAI and Partially Allowed NSSAI and/or the associated mapping to HPLMN S-NSSAIs (see clause 5.15.4.2). When there is the need to update the Allowed NSSAI or Partially Allowed NSSAI, the AMF shall provide the UE with the new Allowed NSSAI or Partially Allowed NSSAI and the associated mapping to HPLMN S-NSSAIs, unless the AMF cannot determine the new Allowed NSSAI (e.g. all S-NSSAIs in the old Allowed NSSAI have been removed from the Subscribed S-NSSAIs), in which case the AMF shall not send any Allowed NSSAI to the UE but indicate to the UE to perform a Registration procedure. If the UE is in a CM-IDLE state, the AMF may trigger Network Triggered Service Request or wait until the UE is in a CM-CONNECTED state as described in clause 4.2.4.2, TS 23.502[ Procedures for the 5G System (5GS) ]  [3]. When providing a Requested NSSAI to the network upon registration, the UE in a given PLMN only includes and uses S-NSSAIs applying to this PLMN. The mapping of S-NSSAIs of the Requested NSSAI to HPLMN S-NSSAIs may also be provided (see clause 5.15.4.1.2 for when this is needed). The S-NSSAIs in the Requested NSSAI are part of the Configured and/or Allowed NSSAIs applicable for this PLMN, when they are available. If the UE has received NSSRG information together with the Configured NSSAI, it only includes in the Requested NSSAI S-NSSAIs that all share a common NSSRG. 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. If no Configured NSSAI and Allowed NSSAI for the PLMN are available, the S-NSSAIs in the Requested NSSAI correspond to the Default Configured NSSAI, if configured in the UE. Upon successful completion of a UE's Registration procedure over an Access Type, the UE obtains from the AMF an Allowed NSSAI or Partially Allowed NSSAI for this Access Type, which includes one or more S-NSSAIs and, if needed (see clause 5.15.4.1.2 for when this is needed), their mapping to the HPLMN S-NSSAIs. These S-NSSAIs are valid for the current Registration Area and Access Type provided by the AMF the UE has registered with and can be used simultaneously by the UE (up to the maximum number of simultaneous Network Slice instances or PDU Sessions). The UE might also obtain from the AMF, one or more rejected S-NSSAIs with cause and validity of rejection. An S-NSSAI may be rejected: - for the entire PLMN; - for the current Registration Area; or - partially in the current Registration Area. Such S-NSSAI rejected partially in the current Registration area is associated with a list of TAs where the S-NSSAI is not supported. The AMF may also reject the use of an S-NSSAI due to congestion as described in clause 5.19.7.4. While the UE remains RM-REGISTERED in the PLMN and regardless of the Access Type, the UE shall not re-attempt to register to an S-NSSAI rejected for the entire PLMN until this rejected S-NSSAI is deleted as specified below. While the UE remains RM-REGISTERED in the PLMN, the UE shall not re-attempt to register to an S-NSSAI rejected in the current Registration Area until it moves out of the current Registration Area. While the UE remains RM-REGISTERED in the PLMN, the UE shall not re-attempt to register to an S-NSSAI rejected partially in the RA until the UE moves into a TA which is not part of the list of TAs associated with the S-NSSAI. NOTE 2: The details and more cases of S-NSSAI rejection are described in TS 24.501[ Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3 ]  [47]. The S-NSSAIs that the UE provides in the Requested NSSAI which are neither in the Allowed NSSAI nor in the Partially Allowed NSSAI, nor provided as a rejected S-NSSAI, shall, by the UE, not be regarded as rejected, i.e. the UE may request to register these S-NSSAIs again next time the UE sends a Requested NSSAI. The UE stores (S-)NSSAIs as follows: - When provisioned with a Configured NSSAI for a PLMN and/or a mapping of Configured NSSAI to HPLMN S-NSSAIs and possibly NSSRG information for each S-NSSAI in the Configured NSSAI (if applicable and supported by the UE), or when requested to remove the configuration due to network slicing subscription change, the UE shall: - replace any stored (old) Configured NSSAI for this PLMN with the new Configured NSSAI for this PLMN (if applicable); and - delete any stored associated mapping of this old Configured NSSAI for this PLMN to HPLMN S-NSSAIs and, if present and applicable, store the mapping of Configured NSSAI to HPLMN S-NSSAIs; and - delete any stored associated NSSRG information for each S-NSSAI of the Configured NSSAI and, if present, store the associated NSSRG information for each S-NSSAI of the Configured NSSAI; and - delete any stored rejected S-NSSAI for this PLMN; - keep the received Configured NSSAI for a PLMN (if applicable) and associated mapping to HPLMN S-NSSAIs (if applicable) and associated NSSRG information for each S-NSSAI of the Configured NSSAI (if applicable and supported by the UE) stored in the UE, even when registering in another PLMN, until a new Configured NSSAI for this PLMN and/or associated mapping are provisioned in the UE, or until the network slicing subscription changes, as described in clause 5.15.4.2. The number of Configured NSSAIs and associated mapping to be kept stored in the UE for PLMNs other than the HPLMN is up to UE implementation. A UE shall at least be capable of storing a Configured NSSAI for the serving PLMN including any necessary mapping of the Configured NSSAI for the Serving PLMN to HPLMN S-NSSAIs and the Default Configured NSSAI. - The Allowed NSSAI received in a Registration Accept message or a UE Configuration Update Command applies to a PLMN when at least a TAI of this PLMN is included in the RA/TAI list included in this Registration Accept message or UE Configuration Update Command. If the UE Configuration Update Command contains an Allowed NSSAI but not a TAI List, then the last received RA/TAI list applies for the decision on which PLMN(s) the Allowed NSSAI is applicable. If received, the Allowed NSSAI for a PLMN and Access Type and any associated mapping of this Allowed NSSAI to HPLMN S-NSSAIs shall be stored in the UE. The UE should store this Allowed NSSAI and any associated mapping of this Allowed NSSAI to HPLMN S-NSSAIs also when the UE is turned off, or until the network slicing subscription changes, as described in clause 5.15.4.2: NOTE 3: Whether the UE stores the Allowed NSSAI and any associated mapping of the Allowed NSSAI to HPLMN S-NSSAIs also when the UE is turned off is left to UE implementation. - When a new Allowed NSSAI for a PLMN and any associated mapping of the Allowed NSSAI to HPLMN S-NSSAIs are received over an Access Type, the UE shall: - replace any stored (old) Allowed NSSAI and any associated mapping for these PLMN and Access Type with this new Allowed NSSAI; and - delete any stored associated mapping of this old Allowed NSSAI for this PLMN to HPLMN S-NSSAIs and, if present, store the associated mapping of this new Allowed NSSAI to HPLMN S-NSSAIs; - If received, a Partially Allowed NSSAI received in a Registration Accept message or a UE Configuration Update Command message applies to the current Registration Area. The UE stores the Partially Allowed NSSAI in the same way as described for the Allowed NSSAI (see also clause 5.15.17). - If received, an S-NSSAI rejected for the entire PLMN shall be stored in the UE while RM-REGISTERED in this PLMN regardless of the Access Type or until it is deleted. - If received, an S-NSSAI rejected for the current Registration Area shall be stored in the UE while RM-REGISTERED until the UE moves out of the current Registration Area or until the S-NSSAI is deleted. - If received, an S-NSSAI rejected partially in the RA shall be stored in the UE while RM-REGISTERED until the UE moves out of the current Registration Area or until the S-NSSAI is deleted (see also clause 5.15.17). NOTE 4: The storage aspects of rejected S-NSSAIs are described in TS 24.501[ Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3 ]  [47]. - If received, the Pending NSSAI shall be stored in the UE as described in TS 24.501[ Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3 ]  [47]. - If received, the S-NSSAI validity time information shall be stored in the UE in the UE as described in TS 24.501[ Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3 ]  [47]. - If received, the S-NSSAI location availability information shall be stored in the UE as described in TS 24.501[ Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3 ]  [47]. - If received, the mapping of old S-NSSAI to the Alternative S-NSSAI shall be stored in the UE as described in TS 24.501[ Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3 ]  [47]. UE configuration to guide UE selection of a N3IWF/TNGF that supports the S-NSSAIs needed by the UE is defined in clause 6.3.6 and clause 6.3.12 respectively.