Section: 5.15.16 Optimized handling of temporarily available network slices
Content: A network slice may be available for all UEs or a limited number of UEs only for a limited time that is known at the network in advance e.g. by OAM or subscription. The limited time duration may be due to, for example, the fact that network slice is only temporarily or periodically active in the deployment (e.g. for a limited time to serve an event or a UE may be only authorized to access the network slice for a limited time known in advance), or the network slice is being decommissioned at a known future time. This feature is enabled by S-NSSAI validity time that the network and the UE can handle to reduce the signalling load associated to the transitions in RM and SM states for the network slice. The UE may indicate its support for temporarily available network slices in the UE MM Core Network Capability (see clause 5.4.4a) in the Registration Request. The AMF, based on OAM configuration or information received from the UDM or NSSF, may indicate to a supporting UE the validity time for one or more S-NSSAIs in the Configured NSSAI in the Registration Accept message or via the UE Configuration Update procedure. In roaming case, the AMF my include the validity time for an S-NSSAI in the Configured NSSAI either because of limited availability of the VPLMN S-NSSAI or the mapped S-NSSAI of the HPLMN. NOTE 1: When the validity time changes or a validity time is determined for a S-NSSAI in the configured NSSAI, the PLMN provides the new validity time for the S-NSSAIs in the Configured NSSAI to a supporting UE. If a supporting UE is configured with validity time for an S-NSSAI: a) If the validity time indicates the S-NSSAI is available, the UE may request the S-NSSAI in a Requested NSSAI in a Registration request and, if the S-NSSAI is included in the Allowed NSSAI or in the Partially Allowed NSSAI, the UE may establish PDU sessions associated with the S-NSSAI. b) If the validity time indicates the S-NSSAI is not available - The UE shall not include the S-NSSAI in the Requested NSSAI for any Access Types regardless of the validity time information was received; - If the S-NSSAI is already part of the Allowed NSSAI or Partially Allowed NSSAI, the UE shall remove the S-NSSAI from the locally stored Allowed NSSAI or Partially Allowed NSSAI and the UE shall also locally release any PDU sessions associated with the S-NSSAI. - If the validity time indicates the S-NSSAI will not be available again, the UE shall remove the S-NSSAI from the locally stored Configured NSSAI. NOTE 2: Subject to implementation decisions outside 3GPP scope, the UE may also use the validity time information to e.g. attempt to use another PDU sessions to continue supporting the connectivity with another connectivity option if possible according to the URSP rules, or, if not possible, e.g. provide implementation-dependent information on the availability of connectivity for specific applications affected by an impending connectivity loss, so the UE can let the end user prepare for the loss of connectivity. For a supporting UE, if validity time applies to an S-NSSAI, an AMF supporting temporarily available network slices shall: - If the S-NSSAI is provided in a Requested NSSAI in a Registration Request by the UE and the validity time indicates the S-NSSAI is not available, but it is going to become available again (i.e. the UE is detected as not having up to date validity time), then the AMF sends the Configured NSSAI to the UE including the validity time for the S-NSSAI in the Registration Accept message. If the validity time indicates the S-NSSAI is not available and will not become available again, then the AMF sends the Configured NSSAI to the UE, excluding the S-NSSAI from the Configured NSSAI. - If the S-NSSAI is in the Allowed NSSAI or the Partially Allowed NSSAI for the UE and the validity time indicates that the S-NSSAI is not available, then locally remove (i.e. without sending any signalling to the UE) the S-NSSAI from the Allowed NSSAI or Partially Allowed NSSAI. If there is any PDU session established for the S-NSSAI, the AMF requests the SMF to release the PDU session: - If the UE is in CM-CONNECTED state, the AMF releases the PDU session for the S-NSSAI by sending to the SMF, as per step 1f in clause 4.3.4.2 of TS 23.502[ Procedures for the 5G System (5GS) ]  [3], a Nsmf_PDUSession_UpdateSMContext Request with a release indication to request the release of the PDU Session and then the AMF forwards the N2 SM request to release the AN resources associated with the PDU session - If the UE is in CM-IDLE state, the AMF locally releases the PDU session without paging the UE and causes the SMF to locally release the SM context for the UE by a Nsmf_PDUSession_ReleaseSMContext, as in step 1c in clause 4.3.4.2 of TS 23.502[ Procedures for the 5G System (5GS) ]  [3]. The PDU Session status is synchronized at next time when the UE connects to the network. For a non-supporting UE, if validity time applies to an S-NSSAI, an AMF supporting temporarily available network slices shall: - If the validity time indicates the S-NSSAI is available, allow or partially allow the network slice when requested, establish PDU sessions when requested. - If the S-NSSAI is provided in a Requested NSSAI in a Registration Request by the UE and the validity time indicates the S-NSSAI is not available, reject the S-NSSAI and remove the S-NSSAI from the Configured NSSAI by providing an updated Configured NSSAI in the Registration Accept message. - If the S-NSSAI is in the UE in the Allowed NSSAI or Partially Allowed NSSAI and the validity time indicates the S-NSSAI is not available, remove the S-NSSAI from the Configured NSSAI and the Allowed NSSAI or Partially Allowed NSSAI by a UE Configuration Update procedure. If there is any PDU session established for the S-NSSAI, the AMF requests the SMF to release the PDU session in the network: - If the UE is in CM-CONNECTED state, the AMF releases the PDU session for the S-NSSAI by sending to the SMF, as in step 1f in clause 4.3.4.2 of TS 23.502[ Procedures for the 5G System (5GS) ]  [3], a Nsmf_PDUSession_UpdateSMContext Request with a release indication to request the release of the PDU Session and then the AMF forwards the N2 SM request to release the AN resources associated with the PDU session - If the UE is in CM-IDLE, the AMF locally releases the PDU session without paging the UE and causes the SMF to locally release the SM context for the UE by a Nsmf_PDUSession_ReleaseSMContext, as in step 1c in clause 4.3.4.2 of TS 23.502[ Procedures for the 5G System (5GS) ]  [3]. The PDU Session status is synchronized at next time when the UE connects to the network NOTE 3: If the network slice becomes unavailable, and a large number of UEs are impacted, the AMF can send the updates to the non-supporting UEs in a manner that avoids surge in signalling (e.g. next time the UE becomes connected). - If the AMF detects from the validity time of a S-NSSAI that it is available again, then update the Configured NSSAI to include the S-NSSAI via a UE Configuration Update procedure. NOTE 4: The AMF, for the case of UE not performing any actions despite the validity timing information provided by the network, can terminate PDU Session(s) associated with S-NSSAI subject to be terminated according to the validity time by explicitly releasing the PDU Sessions associated with the S-NSSAI.