Content for TS 23.501 Word version: 18.5.0

1… 3… 4.2.3 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.2.15… 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.15.11… 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.32.6… 5.33… 5.34… 5.35… 5.38… 5.43… 6… 6.3… 6.3.8… 7… 7.2… 8… 8.2.4 8.2.5… 8.3… A… D… E… F G… G.3 G.4… H… J K… M… N… O… P…

5.15.11 Network Slice Admission Control 5.15.12 Support of subscription-based restrictions to simultaneous registration of network slices 5.15.13 Support of data rate limitation per Network Slice for a UE 5.15.14 Network Slice AS Groups support 5.15.15 Support of Network Slice usage control 5.15.16 Optimized handling of temporarily available network slices 5.15.17 Partial Network Slice support in a Registration Area 5.15.18 Support for Network Slices with Network Slice Area of Service not matching deployed Tracking Areas 5.15.19 Support of Network Slice Replacement 5.15.20 Support of Network Slice Instance Replacement
...

5.15.11 Network Slice Admission Control |R17| p. 272

5.15.11.0 General p. 272

The Network Slice Admission Control Function (NSACF) monitors and controls the number of registered UEs per network slice and/or the number of PDU Sessions per network slice for the network slices that are subject to Network Slice Admission Control (NSAC). The NSACF is configured with the maximum number of UEs and/or the maximum number of PDU Sessions allowed to be served per S-NSSAI subject to NSAC. The NSACF is also configured with information indicating applicable access type(s) for the S-NSSAI (i.e. 3GPP Access Type, Non-3GPP Access Type, or both).

The NSACF also provides event-based Network Slice status notifications and reports to the consumer NFs (e.g. AF).

A NSACF can be configured with the NSAC Service Area(s) it serves. The NSAC Service Area Identifier is a unique identifier in a PLMN or SNPN. The consumer NFs which use the NSAC services are configured with a single and network slice independent value of the NSAC Service Area Identifier so they can discover the correct NSACF (see clause 6.3.22).

The NSACF may be responsible for one or more S-NSSAIs. For one S-NSSAI there may be one or multiple NSACFs deployed in a network (a PLMN or a SNPN) as follows:

If a PLMN or SNPN is configured with a single NSAC service area, there is a single NSACF configured with the maximum number of UEs per network slice and/or the maximum number of PDU Sessions per network slice, which are valid in the network. In this case there is no need to provision any NSAC Service Area Identifier value in the PLMN or SNPN.
If a PLMN or SNPN is configured with multiple NSAC service areas, an NSACF may be deployed on a NSAC service area basis, which can be one NSACF instance or one NSACF Set. There are three NSAC architecture options:
- Option 1: non-Hierarchical NSAC architecture. In this architecture, independent NSACFs are deployed in every NSAC service area. There is no interaction between the NSACFs deployed in different NSAC service areas. Each NSACF is configured with the maximum number of UEs per network slice and/or the maximum number of PDU Sessions which are valid in the NSAC service area (see clauses 5.15.11.1.1 and 5.15.11.2.1 for more details).
- Option 2: Centralized NSAC architecture. In this architecture, a single centralized NSACF is deployed in the network to handle admissions in all NSAC service areas. The centralized NSACF is configured with the total number of UEs per network slice and the maximum number of PDU Sessions for the entire PLMN. NSAC Requests from AMF or SMF to the single centralized NSCAF in this case includes the NSAC service area of the NF consumer if multiple NSAC service areas are deployed in PLMN.
  
  NOTE 1:
  It is possible to configure in the centralized architecture the maximum number of registered UEs and/or the maximum number of PDU sessions per NSAC service area if required by the operator. In this case, NSAC can be performed on a per NSAC service area.
- Option 3: Hierarchical NSAC architecture is deployed in the network. There are two roles of NSACF and interaction between them may be required (see clauses 5.15.11.1.2 and 5.15.11.2.2 for more details):
  - Primary NSACF, controls and distributes of the maximum number of UEs and/or the maximum number of PDU Sessions for other NSACF(s) deployed in different NSAC service Area. The Primary NSACF handles overall NSAC for an S-NSSAI at the global level (i.e. it is ultimately responsible for the NSAC for an S-NSSAI).
  - NSACF is responsible for one or multiple NSAC service Area. And one NSAC service area is only associated with one NSACF instance or one NSACF Set.

Subject to operator policy and national/regional regulations, the AMF may exempt UEs and the SMF may exempt PDU sessions from NSAC when the UE and/or PDU Session is used for Emergency service or for Critical and Priority services (e.g. MCX, MPS).

When the AMF receives a Registration Request for an Emergency Registration, or with a Registration Request with an Establishment Cause indicating a priority service (e.g. MCX, MPS) or when the AMF determines that there is a priority subscription (e.g. MPS, MCX) in the UDM, the AMF may accept the registration request without applying NSAC, i.e. the AMF triggers the NSAC procedure, but the response from the NSACF is ignored at the AMF.

When the SMF receives a PDU Session Establishment Request for an emergency PDU Session or a PDU Session Establishment Request with a priority header, the SMF may accept the PDU Session Establishment Request without applying NSAC, i.e. the SMF triggers the NSAC procedure, but the response from the NSACF is ignored at the SMF.

Alternatively, when NSAC is exempted for the UE and/or PDU Session, the AMF and the SMF skip the corresponding NSAC procedure, i.e. this UE (respectively PDU Session) is not counted towards the maximum number of UEs (respectively PDU Sessions).

The support of NSAC for the S-NSSAI used for onboarding as described in clause 5.30.2.10 is optional and subject to Onboarding Network operator policies. However, NSAC for S-NSSAI used for onboarding is not applicable to UEs that registered in ON-SNPN with Registration Type "SNPN Onboarding".

In the case of NSAC for maximum number of PDU Sessions, when the NSACF rejects the request from the SMF to increase the number of PDU Sessions, the SMF may provide to the UE a back-off timer associated with reject cause set to 'Maximum number of PDU Sessions per S-NSSAI reached' for an Access Type as described in clause 4.2.11.4 of TS 23.502. If the UE receives from the SMF a back-off timer associated with the reject cause set to 'Maximum number of PDU Sessions per S-NSSAI reached' for an Access Type, the UE shall not request the establishment of a PDU Session for this S-NSSAI on the indicated Access Type until the back-off timer expires.

5.15.11.1 Network Slice Admission Control for maximum number of UEs p. 273

5.15.11.1.1 Non-Hierarchical NSAC architecture |R18| p. 273

The NSACF keeps track of the current number of UEs registered for a network slice so that it can ensure it does not exceed the maximum number of UEs allowed to register with the network slice. The NSACF also maintains a list of UE IDs registered with a network slice that is subject to NSAC. When an event related to a UE causes the current number of UEs registered with a network slice to increase, the NSACF first checks whether the UE Identity is already in the list of UEs registered with that network slice. If not, the NSACF checks whether the maximum number of UEs per network slice for that network slice has already been reached and if it has, the NSACF applies admission control policies.

The AMF triggers a request to NSACF for NSAC for maximum number of UEs when the UE's registration status for a network slice subject to NSAC is changing, i.e. during the UE Registration procedure in clause 4.2.2.2.2 of TS 23.502, UE Deregistration procedure in clause 4.2.2.3 of TS 23.502, Network Slice-Specific Authentication and Authorisation procedure in clause 4.2.9.2 of TS 23.502, AAA Server triggered Network Slice-Specific Re-authentication and Re-authorization procedure in clause 4.2.9.3 of TS 23.502, AAA Server triggered Slice-Specific Authorization Revocation in clause 4.2.9.4 of TS 23.502 and UE Configuration Update procedure in clause 4.2.4.2 of TS 23.502.

Since the UE may register or deregister for an S-NSSAI via 3GPP access and/or non-3GPP access as described in clause 5.15.5.2.1. The Allowed NSSAI for the access type may change while the UE is registering to a network. The AMF provides the Access Type to the NSACF when triggering a request to increase or decrease the current number of UEs registered with a S-NSSAI. The NSACF may take the Access Type into account for increasing and decreasing the number of UEs per network slice by storing the UE ID with the associated one or more Access Type(s), i.e. the NSACF is able to add or remove a registration for the UE ID for each Access Type and trigger the increase or decrease of the current number of UEs registered with a S-NSSAI based on a policy that takes the access type into account. If the Access Type provided by the AMF is not configured for NSAC in the NSACF, the NSACF always accepts the request from the AMF without increasing or decreasing the number of UEs. If the Access Type provided by the AMF is configured for NSAC in the NSACF and the maximum number is reached, the NSACF sends a reject response to the AMF including the access type.

5.15.11.1.2 Hierarchical NSAC architecture |R18| p. 274

In the Hierarchical NSAC architecture, the NSACFs deployed in the NSAC service areas interacts with the Primary NSACF when needed, and as explained below.

The main differences between the non-Hierarchical architecture and the Hierarchical architecture is that the AMFs and the NSACFs deployed in the Hierarchical architecture support the following:

When the AMF triggers an NSAC request to the NSACF, the AMF includes the UE already Registered indication if the AMF can determine that the UE has been registered with the S-NSSAI in one NSAC service area before. If the AMF does not include the UE already Registered indication, the registration request to the indicated S-NSSAI is determined as initial registration, i.e. the UE has not been registered in any service area before. The AMF determines the UE already Registered indication based on the received Allowed NSSAI information from the source AMF (in case of inter AMF handover) or from SMF+PGW-C (in case of mobility from EPS to 5GS).
There are two types of UE admission control: quota-based control or threshold-based control. A PLMN is configured to deploy only one type of UE admission control. Based on the type of UE admission control configured for the PLMN, the NSACF handles the NSAC request as described below:
- For NSACFs supporting quota-based control, if the NSACF receives a request to increase the number of UEs and the number of UEs registered for a network slice has reached the local maximum number of UEs provisioned in the NSACF, or upon receiving a request to decrease the number of UEs and no UE entry is present in the NSACF, the NSACF interacts with the Primary NSACF for the handling of the NSAC request for the UE. The Primary NSACF may return in the response an updated local maximum number of registered UEs value to the NSACF based on the status of registered UEs for the Network Slice and which enables the NSACF to handle locally the request. Alternatively, and if the request to increase the number of UEs includes the UE already Registered indication, the Primary NSACF may admit the UE request and store the UE entry which allows for service continuity. The Primary NSACF may also reject the request. If the NSACF receives a request to increase the number of UEs and the local maximum number of UEs is not reached, the NSACF handles the request locally and sends a response to the AMF without interaction with the Primary NSACF.
- For NSACF supporting threshold-based control, the NSACF is initially configured with a UE admission threshold and a local maximum number of Registered UEs to be admitted. Threshold-based control refers to an admission threshold, defined in percentage, against provisioned local maximum number in NSACF (e.g. an admission threshold of 80% refers to the case when 80% of the provisioned local maximum number should be used). If upon a receiving a request to increase the number of UEs without a UE already Registered indication and if UE admission threshold is at or above the threshold level configured at the NSACF, the NSACF immediately rejects the NSAC request. If the received request includes the UE already Registered indication and if UE admission is at or above the threshold level configured at the NSACF, the NSACF accepts the request to enable UE admission and allow for service continuity as long as the local maximum number of Registered UEs have not been reached. If the local maximum number of registered UEs value have been reached, the NSACF interacts with the Primary NSACF for the handling of the NSAC request for the UE. The NSACF does not include the UE already Registered indication in this case. The Primary NSACF may return an updated UE admission threshold value to the NSACF in the response which enables the NSACF to handle the request locally. Alternatively, the Primary NSACF may handle and store the UE entry. The Primary NSACF may also reject the request.
For both options, the Primary NSACF supports the following capabilities depending on the NSACF configuration:
- Returning a new updated local maximum number of Registered UEs for the NSACF to admit if the NSACF is configured to support the quota-based UE admission control; or
- Returning a new updated UE admission threshold for the NSACF to apply if the NSACF is configured to support the threshold-based UE admission control;
- The Primary NSACF handles, stores entries only related to UEs which the NSAC request includes the UE already Registered indication, that are already admitted in an existing NSAC service area but cannot be admitted in the new NSAC service area due to no remaining local maximum number of registered UEs, as long as the overall PLMN number of registered UEs at the Primary NSACF is not exhausted. The Primary NSACF informs the NSACF in its response;
- Based on the response from the Primary NSACF, the NSACF determines whether to accept or reject the NSAC request for UE registration. In addition, the NSACF may also update the local maximum number of Registered UEs or admission threshold respectively if the related updated value is received;
- At any time, the Primary NSACF can update the NSACFs local maximum number of Registered UEs or admission threshold through the Nnsacf_NSAC_LocalNumberUpdate operation as described in clause 4.2.11.6 of TS 23.502. The updated values provided from the Primary NSACF to the NSACFs may directly apply to current NSAC pending request in NSACF and are used for all future requests.
The Primary NSACF subscribes with all NSACFs to obtain the number of currently registered UEs at all NSACFs. Based on the obtained information, the Primary NSACF can update the NSACF with local maximum number of registered UEs.

5.15.11.1.3 Centralized NSAC architecture |R18| p. 275

The main differences between the NSACFs deployed in a non-Hierarchical architecture and NSACFs deployed in a Centralized NSAC architecture is as follows:

If multiple NSAC service areas are deployed in PLMN, the AMF provides the NSAC Service Area Identifier information to the centralized NSACF. The centralized NSACF also stores the NSAC Service Area Identifier of the AMF the UE is registered with.

5.15.11.2 Network Slice Admission Control for maximum number of PDU sessions p. 275

5.15.11.2.1 Non- Hierarchical NSAC architecture |R18| p. 275

The NSACF keeps track of the current number of PDU Sessions per network slice so that it can ensure it does not exceed the maximum number of PDU session allowed to be served by the network slice. When an event related to a UE causes the current number of PDU sessions established within the network slice is to increase, the NSACF checks whether the maximum number of PDU sessions per network slice for that network slice has already been reached and if it has, the NSACF applies admission control policies.

The anchor SMF triggers a request to NSACF for maximum number of PDU sessions per network slice control during PDU session establishment/release procedures in clauses 4.3.2 and 4.3.4 of TS 23.502.

The SMF provides the Access Type to the NSACF when triggering a request to increase or decrease the number of PDU Sessions. The NSACF takes Access Type into account for increasing and decreasing the current number of PDU Sessions depending on the applicability of the Access Type for the NSAC for maximum number of PDU Sessions for the S-NSSAI.

5.15.11.2.2 Hierarchical NSAC architecture |R18| p. 276

The main differences between the NSACFs deployed in a non-Hierarchical architecture and NSACFs deployed in a Hierarchical architecture is as follows:

The NSCAF is enhanced to support PDU session admission quota-based control.
When the local maximum number of PDU sessions is reached, the NSACF interacts with the Primary NSACF to handle the request. The Primary NSACF either return an increased local maximum number to the NSACF, or reject the local maximum number value update request if all the global maximum number are consumed based on the status of established PDU sessions to the network slice.
For Hierarchical NSAC architecture global maximum number used within this specification is synonymous with the maximum number of allowed registered UEs or established PDU Sessions for an S-NSSAI subject to Network Slice Admission Control (NSAC) for the entire PLMN and outbound roamers.
Based on the response from Primary NSACF, the NSACF updates the local maximum number if updated value is received from the Primary NSACF. The NSACF updates local maximum number value (if received) and determines whether to accept or reject the NSAC request for PDU session establishment based on the local maximum number value.
The update of local maximum number value by the Primary NSACF can also happen at any time through the Nnsacf_NSAC_LocalNumberUpdate service operation as described in clause 4.2.11.6 of TS 23.502. The updated values provided from the Primary NSACF to NSACFs may directly apply to current NSAC pending request in NSACF and are used for all future requests.
The Primary NSACF subscribes with all NSACFs to obtain the number of currently established PDU sessions at all NSACFs. Based on the obtained information, the Primary NSACF can update the NSACF with local maximum number of established PDU sessions.

5.15.11.2.3 Centralized NSAC architecture |R18| p. 276

The main differences between the NSACFs deployed in a non-Hierarchical NSAC architecture and NSACFs deployed in a Centralized NSAC architecture is as follows

If multiple NSAC service areas are deployed in a PLMN, the SMF provides the NSAC Service Area Identifier to the centralized NSACF. The centralized NSACF also stores the NSAC Service Area Identifier of the SMF the PDU session is established on.

5.15.11.3 Network Slice Admission Control for Roaming p. 276

5.15.11.3.0 General |R18| p. 276

In the case of roaming, depending on operator's policy, a roaming agreement or an SLA between the VPLMN and the HPLMN, NSAC of roaming UEs is performed by one of the following modes of NSAC admission:

VPLMN NSAC Admission; or
VPLMN with HPLMN assistance NSAC Admission; or
HPLMN NSAC Admission.

The VPLMN (AMF and SMF) identifies the mode to apply from the AMF subscription data at UE registration, and from the SMF subscription data at PDU session establishment.

For all the above modes, for NSAC of roaming UEs for maximum number of UEs per network slice and/or maximum number of PDU Sessions per network slice managed by the VPLMN, each S-NSSAI of the HPLMN that is subject to NSAC is mapped to a corresponding S-NSSAI of the VPLMN subject to NSAC.

For both VPLMN NSAC Admission and VPLMN with HPLMN assistance NSAC Admission modes, each configured S-NSSAI that is subject to NSAC and that is mapped from the HPLMN S-NSSAI, the SMF performs NSAC for home routed PDU sessions according to the principles described in clause 5.15.11.2.

5.15.11.3.1 VPLMN NSAC Admission Mode |R18| p. 277

For NSAC of roaming UEs for maximum number of UEs per network slice and/or maximum number of PDU Sessions per network slice managed by the VPLMN, the following principles shall be used:

For NSAC for the maximum number of UEs for S-NSSAI of the HPLMN, a NSACF in the VPLMN can be configured with the maximum number of allowed roaming UEs per mapped S-NSSAI of the HPLMN for a S-NSSAI of the HPLMN that is subject to NSAC. In such a case, the AMFs trigger a request to a NSACF of the VPLMN.
For NSAC for the maximum number of PDU Sessions for S-NSSAI of the HPLMN, a NSACF in the VPLMN can be configured with the maximum number of allowed PDU Sessions in LBO mode per mapped S-NSSAI of the HPLMN for a S-NSSAI of the HPLMN that is subject to NSAC. In such a case, the anchor SMF in the VPLMN triggers a request to a NSACF of the VPLMN.
For NSAC for the maximum number of UEs for S-NSSAI of the VPLMN, AMFs trigger a request to a NSACF of the VPLMN to perform NSAC based on the S-NSSAI of the VPLMN subject to NSAC. The NSACF of the HPLMN is not involved.
For NSAC for the maximum number of PDU Sessions for S-NSSAI of the VPLMN in the LBO roaming case, the SMF triggers a request to a NSACF of the VPLMN to perform NSAC based on the S-NSSAI of the VPLMN subject to NSAC. The NSACF of the HPLMN is not involved.
The AMF or SMF (in LBO roaming case) in the VPLMN provides both the S-NSSAI in the VPLMN and the corresponding mapped S-NSSAI in the HPLMN to the NSACF in the VPLMN. The NSACF in the VPLMN performs NSAC for both S-NSSAI of the VPLMN and the corresponding mapped S-NSSAI of the HPLMN based on the SLA between the VPLMN and the HPLMN.

In addition to configuring the VPLMN NFs with the maximum number of allowed roaming UEs per mapped S-NSSAI of the HPLMN subject to NSAC, and the maximum number of allowed PDU Sessions in LBO mode per mapped S-NSSAI of the HPLMN subject to NSAC, the VPLMN can optionally fetch this information from the HPLMN primary NSACF in a hierarchal architecture or centralized NSACF in a centralized architecture. If the NSACF in VPLMN does not have quota configured but can receive quota from the HPLMN, the NSACF in VPLMN may interact with the HPLMN for retrieving the quota before processing any incoming request. The VPLMN is either configured or discovers the NSACF in the HPLMN for quota retrieval. However, in this case, the VPLMN rejects any additional requests exceeding the received information.

5.15.11.3.2 VPLMN with HPLMN assistance NSAC Admission |R18| p. 277

In this admission mode HPLMN delegates NSAC for S-NSSAIs subject to NSAC to the VPLMN, both for number of registered UEs and the number of LBO PDU sessions.

Every NSACF performing admission in the VPLMN for each S-NSSAI of the HPLMN that is subject to NSAC and mapped to a corresponding S-NSSAI of the VPLMN, fetches from the VPLMN primary NSACF in a hierarchal architecture the maximum number of registered UEs to be admitted and/or the maximum number of LBO PDU sessions to be allowed. The VPLMN primary or central NSACF, in turn, acquires the information from the HPLMN central or primary NSACF depending on the deployed architecture. The VPLMN is either configured or discovers the NSACF in the HPLMN for quota retrieval.

If re-distribution of quota is required in the VPLMN in a hierarchal architecture, amongst multiple NSACFs than this is handled by the primary NSACF in VPLMN with no involvement from the HPLMN. The VPLMN NSACF discovers the HPLMN primary or central NSACF or be configured with the needed information.

For any request(s) received in any NSACF in the VPLMN exceeding the received maximum number information, the NSACF interacts with the VPLMN primary NSACF which in turn interacts with HPLMN primary or central NSACF to receive an updated roaming quota for the corresponding mapped S-NSSAI, which is used to determine whether admission request is accepted or rejected, unless forbidden by the SLA. If an admission request is accepted, the UE entry is stored in the NSACF performing admission in the VPLMN. This applies to the number of registered UEs as well as the number of LBO PDU sessions. The primary NSACF in VPLMN may re-distribute the received updated roaming quota to the NSACFs in VPLMN to perform NSAC for Roaming UEs according to the principles described in clauses 5.15.11.1 and 5.15.11.2.

5.15.11.3.3 HPLMN NSAC Admission Mode |R18| p. 278

In this admission mode the AMF or SMF in VPLMN interacts with HPLMN for admission, both for number of registered UEs or the number of LBO PDU sessions respectively.

For each S-NSSAI of the HPLMN that is subject to NSAC and mapped to a corresponding S-NSSAI of the VPLMN, AMF performs NSAC admission for the number of registered UEs with the HPLMN central or primary NSACF for all inbound roamers from that HPLMN when they register in this VPLMN. The AMF discovers the HPLMN primary or central NSACF or be configured with the needed information.

For each S-NSSAI of the HPLMN that is subject to NSAC and mapped to a corresponding S-NSSAI of the VPLMN, every SMF in this VPLMN performs NSAC admission for the number of LBO PDU sessions with the HPLMN central or primary NSACF for all inbound roamers from that HPLMN when they initiate an LBO PDU session. The SMFs discover the HPLMN primary or central NSACF or be configured with the needed information. For each S-NSSAI of the HPLMN that is subject to NSAC, the SMF performs NSAC according to the principles described in clause 5.15.11.2 for home routed PDU sessions.

In the HPLMN NSAC admission mode, the primary NSACF or central NSACF in HPLMN determines whether the NSAC admission request for a roaming UE is accepted or rejected.

5.15.11.4 Network Slice status notifications and reports to a consumer NF p. 278

A consumer NF (e.g. AF, Primary NSACF) can subscribe with the NSACF for Network Slice status notifications and reports. Upon such subscription, the corresponding NSACF in different NSAC architecture as defined in clause 5.15.11.0 can provide event based notifications and reports to the consumer NF (e.g. to AF via NEF) related to the current number of UEs registered for a network slice or the current number of UEs with at least one PDU Session/PDN Connection in the case of EPC interworking or the current number of PDU Sessions established on a network slice.

5.15.11.5 Support of Network Slice Admission Control and Interworking with EPC p. 278

This clause describes the NSAC for maximum number of registered UEs and for maximum number of PDU Sessions for network slice subjected to EPS interworking. The NSAC for maximum number of UE with at least one PDU Session/PDN Connection is described in clause 5.15.11.5a. A network slice subject to both NSAC and EPS counting shall be configured with only one of the options:

Maximum number of registered UEs and/or maximum number of PDU Session; or
Maximum number of UEs with at least one PDU Session/PDN Connection and/or maximum number of PDU Session.

If EPS counting is required for a network slice, the NSAC for maximum number of UEs and/or for maximum number of PDU Sessions per network slice is performed at the time of PDN connection establishment in case of EPC interworking. To support the NSAC for maximum number of UEs and/or for maximum number of PDU Sessions per network slice in EPC, the SMF+PGW-C is configured with the information indicating which network slice is subject to NSAC. During PDN connection establishment in EPC, the SMF+PGW-C selects an S-NSSAI associated with the PDN connection as described in clause 5.15.7.1. If the selected S-NSSAI by the SMF+PGW-C is subject to the NSAC, the SMF+PGW-C triggers interaction with NSACF to check the availability of the network slice by invoking separate NSAC procedures for number of UE and number of PDU Session (as described in clause 4.11.5.9 of TS 23.502), before the SMF+PGW-C provides the selected S-NSSAI to the UE. If the network slice is available, the SMF+PGW-C continues to proceed with the PDN connection establishment procedure.

The NSACF performs the following for checking network slice availability prior to returning a response to the SMF+PGW-C:

For NSAC for number of UEs, if the UE identity is already included in the list of UE IDs registered with a network slice, or the UE identity is not included in the list of UE IDs registered with a network slice and the current number of UE registration did not reach the maximum number, the NSACF responds to the SMF+PGW-C with the information that the network slice is available. The NSACF includes the UE identity in the list of UE IDs if not already on the list and increases the current number of UE registration. Otherwise, the NSACF returns a response indicating that the maximum number with the network slice has been reached.
If hierarchical NSAC architecture is deployed, when the local maximum number or local threshold is reached the NSACF may interact with the Primary NSACF before it returns the response back to the SMF+PGW-C. For more details on handling at the NSACF and Primary NSACF see clause 5.15.11.1.2.
For NSAC for number of PDU Sessions, if the current number of PDU sessions is below the maximum number, the NSACF responds to the SMF+PGW-C with the information that the network slice is available. The NSACF increases the current number of PDU sessions. Otherwise, the NSACF returns the response indicating that the maximum number with the network slice has been reached.
If hierarchical NSAC architecture is deployed, when the local maximum number is reached the NSACF may interact with the Primary NSACF before it returns the response back to the SMF+PGW-C. For more details on handling at the NSACF and Primary NSACF see clause 5.15.11.2.2.

If the maximum number of UEs and/or the maximum number of PDU sessions has already been reached, unless operator policy implements a different action, the SMF+PGW-C rejects the PDN connection.

If the establishment of a new PDN Connections is with a different SMF+PGW-C from the SMF+PGW-C used for already existing PDN connection associated with the same S-NSSAI, each SMF+PGW-C will send a request for update (e.g. increase or decrease) to the NSACF. The NSACF may maintain a registration entry per SMF+PGW-C for the same UE ID.

The SMF+PGW-C provides the Access Type to the NSACF when triggering a request to increase or decrease the number of UEs and/or the number of PDU Sessions for an S-NSSAI.

When the UE with ongoing PDN connection(s) moves from EPC to 5GC, the SMF+PGW-C triggers a request to decrease the number of the UE registration in NSACF and the AMF triggers a request to increase the number of the UE registration in NSACF when the UE is registered in the new AMF. If there are more than one PDN connections associated with the S-NSSAI, the NSACF may receive multiple requests for the same S-NSSAI from different SMF+PGW-Cs. When the UE with ongoing PDU session(s) moves from 5GC to EPC, the SMF+PGW-C triggers a request to increase the number of the UE registration in NSACF and the old AMF triggers a request to decrease the number of the UE registration in NSACF when the UE is deregistered in old AMF. If there are more than one PDU sessions associated with the S-NSSAI, the NSACF may receive multiple requests for the same S-NSSAI from different SMF+PGW-Cs. The NSACF maintains a list of UE IDs based on the requests from SMF+PGW-C(s) and AMF, and adjusts the current number of registrations accordingly.

When EPS counting is performed for a network slice, and the UE with ongoing PDN connection(s) moves from EPC to 5GC, session continuity is guaranteed from NSAC standpoint, as the admission was granted at the time of PDN connection establishment, i.e. the number of PDU session is not counted again in 5GC. Similarly, when the UE with ongoing PDU session(s) moves from 5GC to EPC, session continuity is guaranteed from NSAC standpoint as the admission of the PDN Connection(s) to the network slice was already granted at the time of PDU Session establishment in 5GC.

If the PDN connection associated with S-NSSAI is released in EPC, the SMF+PGW-C triggers a request (i.e. decrease) to NSACF for maximum number of UEs and/or maximum number of PDU sessions per network slice control. The NSACF decreases the current number of registrations and removes the UE identity from the list of UE IDs if the PDN connection(s) associated with the S-NSSAI are all released in EPC.

If EPS counting is not required for a network slice, the NSAC for maximum number of UEs and/or for maximum number of PDU Sessions per network slice is performed when the UE moves from EPC to 5GC, i.e. when the UE performs mobility Registration procedure from EPC to 5GC (NSAC for maximum number of UEs per network slice) and/or when the PDN connections are handed over from EPC to 5GC (NSAC for maximum number of PDU Sessions per network slice). The SMF+PGW-C is configured with the information indicating the network slice is subject to NSAC only in 5GS. The PDN connection interworking procedure is performed as described in clause 5.15.7.1. Mobility from EPC to 5GC does not guarantee all active PDU Session(s) can be transferred to the 5GC in certain circumstances when either the current number of UE registration or the current number of PDU sessions would exceed the maximum number when the UE moves from EPC to 5GC. When the UE with ongoing PDU session(s) moves from 5GC to EPC, the SMF+PGW-C triggers a request to decrease the number of PDU Session to NSACF. If there are more than one PDU sessions associated with the S-NSSAI, the NSACF may receive multiple requests for the same S-NSSAI from different SMF+PGW-Cs and NSACF removes the PDU Session ID(s) while decreasing the number of PDU Session(s).

5.15.11.5a Support of Network Slice Admission Control in 5GS for maximum number of UEs with at least one PDU Session/PDN Connection |R18| p. 280

When EPS counting is required for a network slice and NSACF is configured with maximum number of UEs with at least one PDU Session/PDN Connection, the NSACF keeps track of the current number of UEs with at least one PDU session/PDN connection established on a network slice to ensure it does not exceed the maximum configured number.

To support the NSAC for maximum number of UEs with at least one PDU Session/PDN Connection, the SMF+PGW-C may be configured with one of the following options:

Option 1: Triggering an Nnsacf_NSAC_NumOfUEsUpdate_Request to NSACF for NSAC for maximum number of UEs when the UE establishes first PDU Session/PDN connection associated with the network slice in the SMF+PGW-C, or when the last PDU Session/PDN connection associated with the network slice is released. The NSACF performs admission control as described in clause 5.15.11.5 and the number of registered UE is replaced with number of UE with at least one PDU session/PDN connection. Also, if the maximum number of UEs with at least one PDU Session/PDN connection has already been reached and SMF+PGW-C receives the rejection from NSACF, unless operator policy implements a different action, the SMF+PGW-C rejects the PDU Session/PDN connection indicating the cause being the number of UEs in the network slice has been exceeded. The AMF is not configured for this S-NSSAI to be subject to NSAC; or
Option 2: Triggering an Nnsacf_NSAC_NumOfPDUsUpdate_Request as described in clause 5.15.11.5 to NSACF and the NSACF performs admission control for the number of UEs with at least one PDU Session/PDN connection as follows:
- The NSACF supports handling both for the number of UEs with at least one PDU Session/PDN Connection and number of PDU session for the S-NSSAI that is subject to EPC interworking and NSAC. In this case the AMF is not configured for this S-NSSAI to be subject to NSAC. As an optimization option, the SMF+PGW-C can be configured not to trigger the Nnsacf_NSAC_NumOfUEsUpdate_Request to NSACF.
- When the NSACF receives request to increase the current number of PDU Session/PDN Connection established for the network slice, the NSACF checks whether this is the first PDU Session/PDN Connection associated with the network slice. If this is the first PDU Session/PDN Connection associated with the network slice the NSACF checks whether the maximum number of UEs with at least one PDU Session/PDN Connection has been reached. If the maximum number has not been reached then the NSACF increases the number of UE with at least one PDU session/PDN connection and add an entry for UE ID. If the maximum number of UEs has already been reached, unless operator policy implements a different action, the SMF+PGW-C rejects the PDU Session/PDN connection indicating the cause being the number of UEs in the network slice has been exceeded.
- When the NSACF receives request to decrease the current number of PDU Session/PDN Connection established for the network slice, the NSACF locates the UE entry, checks whether this is the last PDU Session/PDN Connection associated with the network slice for the UE. If it is the last PDU Session/PDN Connection the NSACF decreases the number of UE with at least one PDU session/PDN connection and remove the associated UE entry.

NSACF is configured with the information of whether the NSAC for number of UEs with at least one PDU session/PDN connection is based on Option1 or Option 2.

In both options, the SMF+PGW-C provides the Access Type to the NSACF when triggering a request to increase or decrease or update the number of UEs with at least one PDU Session/PDN Connection and/or the number of PDU Sessions for an S-NSSAI.

In the case of roaming, same mechanisms in clause 5.15.11.3 are used and number of registered UE is replaced with number of UE with at least one PDU Session/PDN Connection. For home routed PDU Session/PDN Connection only HPLMN admission mode can be used in this case.

If hierarchical NSAC architecture is deployed, when the local maximum number or local threshold is reached the NSAC may interact with the Primary NSACF before it returns the response back to the SMF+PGW-C. For more details on handling at the NSACF and Primary NSACF see clause 5.15.11.1.2.

5.15.12 Support of subscription-based restrictions to simultaneous registration of network slices |R17| p. 281

5.15.12.1 General p. 281

The subscription information for a UE may include for each S-NSSAI Network Slice Simultaneous Registration Group (NSSRG) information constraining which S-NSSAIs can be simultaneously provided to the UE in the Allowed NSSAI.

When S-NSSAIs have associated NSSRG information, then the S-NSSAIs in the Allowed NSSAI shall share at least one NSSRG.

The NSSRG information, defining the association of S-NSSAIs to NSSRG, is provided as an additional and separate information.

If the optional NSSRG information is not present for the S-NSSAIs of a subscription, and other restrictions do not apply e.g. availability at a specific location, then it is assumed that all the S-NSSAIs in the subscription information can be simultaneously provided to the UE in the Allowed NSSAI. However, if NSSRG information is present in the subscription information, at least one NSSRG shall be associated with each of the S-NSSAIs in the subscription information. At any time, if the AMF has received subscription information for a UE that includes NSSRG information, the Allowed NSSAI for the UE can only include S-NSSAIs which share a common NSSRG.

The default S-NSSAIs, if more than one is present, are associated with the same NSSRGs, i.e. the UE is always allowed to be registered with all the default S-NSSAIs simultaneously. The HPLMN only sends S-NSSAIs sharing all the NSSRGs of the Default S-NSSAIs to a non-supporting VPLMN as part of the subscription information, i.e. in addition to the default S-NSSAI(s), the HPLMN may send any other subscribed S-NSSAI which shares at least all the NSSRG defined for the default S-NSSAI(s), and the HPLMN sends no NSSRG information to the VPLMN. A subscription information that includes NSSRG information shall include at least one default S-NSSAI.

A supporting AMF/NSSF, when it receives a Requested NSSAI, evaluates the S-NSSAIs of the HPLMN (in the mapping information of the Requested NSSAI, when a mapping information is applicable) based on any received NSSRG information for these S-NSSAIs, to determines whether they can be provided together in the Allowed NSSAI.

5.15.12.2 UE and UE configuration aspects p. 282

A UE may support the subscription-based restrictions to simultaneous registration of network slices feature. In this case, the UE indicates its support in the Registration Request message in the Initial Registration and the Mobility Registration Update as part of the UE 5GMM Core Network Capability.

When the serving AMF provides the Configured NSSAI to the UE, and the UE has indicated it supports the subscription-based restrictions to simultaneous registration of network slices feature, the AMF also provides the UE with the NSSRG information related to the S-NSSAIs of the HPLMN which are in the mapping information of the Configured NSSAI. A UE which receives the NSSRG values in the network slicing configuration information shall only include in the Requested NSSAI S-NSSAIs that share a common NSSRG as per the received information. 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 the HPLMN changes NSSRG information in the subscription information for a UE, the UDM updates the supporting AMF serving the UE with the new NSSRG information and the AMF, possibly after interaction with the NSSF (see clause 5.2.16.2.1 of TS 23.502), updates the UE as necessary with network slicing configuration by means of the UE Configuration Update procedure (this may include changes in the Configured NSSAI (and related mapping information) and changes in the Allowed NSSAI as applicable). The UE acknowledges this UE Configuration Update according to clause 4.2.4.2 of TS 23.502.

At any time, a UE supporting subscription-based restrictions to simultaneous registration of network slices feature and that has received NSSRG information together with the Configured NSSAI shall only request S-NSSAIs, across all Access Type(s) regardless of whether the same PLMN or different PLMNs are used, that share one or more common NSSRG.

An AMF which supports the subscription-based restrictions to simultaneous registration of network slice feature configures a non-supporting UE with a Configured NSSAI including only the S-NSSAIs sharing all the NSSRG values of the default S-NSSAI(s), except if it has been instructed otherwise by the UDM. In addition to the default S-NSSAI(s), the AMF sends to the UE in the Configured NSSAI any other subscribed S-NSSAI whose NSSRG match at least those defined for the default S-NSSAI(s).

The UDM in a supporting HPLMN may optionally keep a record of the PEIs or Type Allocation Codes values regarding UE ability to handle network slices that cannot be provided simultaneously in Allowed NSSAI.

The UDM may, based on configuration or the optional PEI records, indicate the AMF to provide the non-supporting UEs with the full set of subscribed S-NSSAIs even if they do not share a common NSSRG. The UDM instructs the supporting AMFs of a PLMN to do so by indicating that the UE can be given a Configured NSSAI with all the S-NSSAIs in the subscription information. If this indication is received from the UDM by the AMF, this is included in the UE context.

Based on its policy (including configuration or optionally checking the specific PEI or Type Allocation Code used by the UE, and subject to roaming agreement) the UDM may also provide the serving AMF in a non-supporting VPLMN with all the S-NSSAI in the subscription information. In this case the AMF provides the UE with a Configured NSSAI including all the S-NSSAIs in the subscription information the AMF receives.

The AMF provides no NSSRG information to a non-supporting UE.

When an AMF which supports the subscription-based restrictions to simultaneous registration of network slice feature, receives from a UE a Requested NSSAI including S-NSSAIs that are supported in the Tracking Area but do not share a common NSSRG, or the AMF has pending NSSAI stored for the UE, and the S-NSSAI(s) of the requested NSSAI and the pending NSSAI do not share a common NSSRG, the AMF assumes the UE configuration is not up-to-date, and provides the following:

a supporting UE with an updated configuration including the up-to-date NSSRG information for the S-NSSAIs in the Configured NSSAI as described above.
a non-supporting UE with an updated Configured NSSAI including only the S-NSSAIs sharing all the NSSRG values of the default S-NSSAI(s), only for the case where the UE context does not include an indication to provide all the subscribed S-NSSAIs in the subscription information in the Configured NSSAI for the UE.

5.15.13 Support of data rate limitation per Network Slice for a UE |R17| p. 283

A UE subscription information may include an optional Slice Maximum Bit Rate for the UE (Subscribed UE-Slice-MBR) for an S-NSSAI, which applies for 3GPP access type only. The Subscribed UE-Slice-MBR includes a UL and a DL value. If a Subscribed UE-Slice-MBR is associated to an S-NSSAI in the subscription information, it is provided by the AMF to the NG-RAN when the AMF provides the Allowed NSSAI for the UE to the NG-RAN as UE-Slice-MBR QoS parameter. The UE-Slice-MBR QoS parameter is defined in clause 5.7.2.6. If the Subscribed UE-Slice-MBR for a UE changes, the AMF updates UE-Slice-MBR in the NG-RAN accordingly.

In roaming case, the UE-Slice-MBR is provided for the S-NSSAI of the VPLMN which maps to the S-NSSAI of the HPLMN and the AMF may first interact with the PCF for authorization of the Subscribed UE-Slice-MBR. If the AMF interacts with the PCF, the PCF may provide the Authorized UE-Slice-MBR that is used as UE-Slice-MBR by the AMF as described in clause 6.1.2.1 of TS 23.503.

For a roaming UE, the S-NSSAI of the VPLMN maps to only one S-NSSAI of the HPLMN for which an UE-Slice-MBR is applied.

The enforcement of the UE-Slice-MBR value, if present in the UE context in the NG-RAN for an S-NSSAI, is described in clause 5.7.1.10.

5.15.14 Network Slice AS Groups support |R17| p. 283

The NG-RAN may support Network Slice AS Groups (NSAGs) which are used as specified in TS 38.300, TS 38.331, TS 38.321 and TS 38.304. A Network Slice AS Group is an identifier of a group of network slices which are associated with it. A Network Slice AS Group association with a group of network slices may be valid in one or more Tracking Areas. An S-NSSAI can be associated with at most one NSAG values for Random Access and at most one NSAG value for Cell Reselection within a Tracking Area. An S-NSSAI can be associated with different NSAG values in different Tracking Areas.

The NG-RAN provides (and updates) the AMF with the values of the NSAG(s) an S-NSSAI is associated with in a TA using the NG Set Up and RAN Configuration Update procedures (see TS 38.413). The AMF in turn provides this information to the NSSF. In deployments where the total number of groups does not exceed the number of groups associated with the NSAG size limit defined in TS 38.331), all the NSAGs configured in the NG-RAN may be unique per PLMN or SNPN. If the UE has indicated that the UE supports NSAG in the 5GMM Core Network Capability (see clause 5.4.4a), the AMF may, with or without NSSF assistance, configure the UE with NSAG Information for one or more S-NSSAIs in the Configured NSSAI, by including this NSAG Information in the Registration Accept message or the UE Configuration Command message. The UE uses the NSAG Information as defined in clause 5.3.4.3.1. The AMF shall indicate in the NSAG Information in which TA a specific NSAG association to S-NSSAI(s) is valid if the AMF provides in the UE configuration a NSAG value which is used in different TAs with a different association with NSSAIs. The configuration the AMF provides includes at least the NSAGs for the UE for the TAs of the Registration Area. If the AMF does not include the list of TAIs in association with an NSAG in the NSAG Information, the NSAG is valid in the Registered PLMN and equivalent PLMNs, or SNPN.

The UE shall store and consider the received NSAG Information, valid for the Registered PLMN and equivalent PLMNs, or SNPN until:

the UE receives new NSAG information in a Registration Accept message or UE Configuration Command message in this PLMN or SNPN; or
the UE receives a Configured NSSAI without any NSAG information in this PLMN or SNPN.

The UE shall store the currently valid NSAG information received in the Registered PLMN or SNPN when registered in this PLMN or SNPN and:

The UE should be able to store the NSAG information for at least the Registered-PLMN and equivalent PLMNs, or the Registered-SNPN and equivalent SNPNs.
The Registered-PLMN can provide NSAG information to the UE for the PLMN and the equivalent PLMNs, and the Registered-SNPN can provide NSAG information to the UE for the SNPN.
There can be at most 32 NSAGs configured in the UE at a time for a PLMN or SNPN.
At most 4 NSAGs can have an optional TAI associated with it.

The NSAG information is not required to be stored after power off or after the UE becomes Deregistered as it is not used for cell selection.

5.15.15 Support of Network Slice usage control |R18| p. 284

5.15.15.1 General p. 284

Network Slice usage control is achieved as follows:

Configuring network-controlled Slice Usage Policy to supporting UEs (see clause 5.15.15.2).
Configuring PDU Sessions inactivity timers, and Network Slice deregistration inactivity timers (see clause 5.15.15.3).

Subject to operator policy and national/regional regulations, the AMF ensures that Network Slice usage control does not apply to a Network Slice used for Emergency services.

5.15.15.2 UE Configuration of network-controlled Slice Usage Policy p. 284

The UE during the Registration procedure may indicate in UE MM Core Network Capability that it supports UE configuration of network-controlled Slice Usage Policy. If so, the AMF determines Slice Usage Policy for one (or more) Network Slice(s) for the UE and configures the UE with this information together with Configured NSSAI to control the usage of this (or these) Network Slice(s). The AMF may be locally configured with network Slice Usage Policy, or receive the policy from the AM-PCF, or per the information received from UDM for AF managed timer values (see clause 5.15.15.3 for more details).

The network-controlled Slice Usage Policy is provided to the UE in the Registration Accept or the UE Configuration Update Command and may include:

An indication, for one or more of S-NSSAI(s) of the HPLMN in the Configured NSSAI, whether the UE only registers with the Network Slice with the network when applications in the UE require data transmission in the Network Slice (i.e. the UE can only register the Network Slice only on demand and consider the Network Slice as on demand S-NSSAI).

NOTE:
All Other Network Slices in the Configured NSSAI are handled by the UE using UE specific policies (e.g. they may be registered irrespective of applications need).
Optionally, for on demand S-NSSAI(s) of the HPLMN in the Configured NSSAI, a deregistration inactivity timer that causes the UE to deregister the Network Slice after the last PDU Session associated with the S-NSSAI is released. This deregistration inactivity timer is started at the UE and AMF per access type when the last PDU Session associated with the S-NSSAI is released, or the Network Slice is included in the Allowed NSSAI and no PDU session is established. The deregistration inactivity timer is stopped and reset when the first PDU session is established or the S-NSSAI is removed from the Allowed NSSAI. The AMF and UE may locally remove the S-NSSAI from the Allowed NSSAI when the timer expires. The AMF may also send a UE Configuration Update Command to remove the slice from the Allowed NSSAI.
If the UE and network state became misaligned, the UE may, for example, request connectivity in a Network Slice which is no longer allowed. In this case, the AMF shall provide the updated Allowed NSSAI in a UE Configuration Update Command after rejecting the PDU Session establishment. The UE may then re-register with the Network Slice if needed.

The UE stores the received Slice Usage Policy with the Configured NSSAI for the serving PLMN and this is kept stored for as long as a Configured NSSAI remains stored for the PLMN. When the Configured NSSAI is updated, the AMF may also provide a new Slice Usage Policy to the UE.

The AMF receives deregistration inactivity timer values as described in clause 5.15.15.3. If the slice deregistration inactivity timer value is updated and the AMF determines to provide the timer to the UE, the AMF provides the updated value to the UE, if the UE supports UE configuration of network-controlled Slice Usage Policy, during the registration procedure or any subsequent registration if there is no ongoing registration procedure. The AMF and the UE, if the update been provided to the UE successfully, use the updated slice deregistration inactivity timer value next time the slice deregistration inactivity timer starts.

5.15.15.3 Network-based per UE Network Slice usage behaviour control p. 285

The 5GC performs Network Slice usage monitoring to be able to enforce the release of inactive PDU Sessions, and deregistering of UEs from Network Slices with no PDU Sessions on them according to its own policies. In order to support usage monitoring for a Network Slice:

the AMF runs a slice deregistration inactivity timer per S-NSSAI and access type to deregister the Network Slice which is started when the Network Slice is not used by any PDU Session over the corresponding access type. The slice deregistration inactivity timer is stopped and reset when at least a PDU Session associated with the Network Slice is successfully established or the Network Slice is removed form the Allowed NSSAI. When the slice deregistration inactivity timer for a Network Slice over an access type expires, the AMF removes the Network Slice from the Allowed NSSAI over the access type by sending the UE Configuration Update Command to impacted UE(s).
the SMFs provide to UPFs that handle the PDU sessions in the Network Slice a PDU Session inactivity timer. The PDU Session inactivity timer is started after no data packet is transmitted or received and runs until the next data packet is transmitted or received which restarts the timer again. If the PDU Session inactivity timer expires before any packet is received or transmitted, the UPF reports this PDU Session inactivity event to the SMF to cause the SMF to release the PDU Session. While releasing the PDU session the SMF may indicate the release cause because of slice inactivity. When the AMF receives the notification of PDU Session release and it includes the release cause of slice inactivity and if the Network Slice of the released PDU Session is not used by other PDU Sessions (i.e. the last PDU Session using the Network Slice is released) over the corresponding access type, the AMF may trigger the UE Configuration Update procedure to remove the Network Slice from the Allowed NSSAI over that corresponding access type or start slice deregistration inactivity timer for the Network Slice.
If the PDU Session inactivity timer value is updated, the SMF provides the updated PDU Session inactivity timer value to the UPF. The UPF uses the updated PDU Session inactivity timer value immediately or next time the PDU Session inactivity timer starts.

NOTE:
For MA PDU Session, the PDU Session inactivity timer is independent of Access Type.

If an S-NSSAI is dedicated for a single AF, and if authorized by operator policy to provide deregistration inactivity/PDU Session inactivity timer values for the S-NSSAI, the AF uses external parameter provisioning procedure to provide deregistration inactivity and PDU session inactivity timer values as described in clause 4.15.6.3g of TS 23.502. In this case, the AF provided timer values are stored in the UDM and provided to the AMF/SMF as part of subscription data for the corresponding S-NSSAI. If no AF is authorized to provide deregistration inactivity/PDU Session inactivity timer values for the S-NSSAI, i.e. no timer value received from UDM, the slice deregistration inactivity timer value and PDU Session inactivity timer value are either pre-configured in the AMF/SMF or received by the AMF/SMF during the AM Policy Association / SM Policy Association procedure respectively.

To enable a serving network to direct UEs to a preferred Network Slice, the AMF may request the UE to transfer a PDU Session from one S-NSSAI to another S-NSSAI as described in clause 5.15.19.

5.15.16 Optimized handling of temporarily available network slices |R18| p. 286

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.

If a supporting UE is configured with validity time for an S-NSSAI:

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.
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.
  
  NOTE 3:
  The AMF will add an S-NSSAI to the Allowed NSSAI before an S-NSSAI validity time of a single S-NSSAI in the Allowed NSSAI expires.
- If a UE supporting temporary available network slices only got one S-NSSAI in the Allowed NSSAI with a validity time that is about to expire, and does not have any Pending NSSAI, then the UE may trigger a Mobility Registration Update to register with any other S-NSSAI in the Configured NSSAI which is still available, if any, and if UE does not receive an updated Allowed NSSAI from the AMF, then the UE shall enter RM-DEREGISTERED state.

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, 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. The PDU Session status is synchronized at next time when the UE connects to the network.
Add an S-NSSAI (e.g. a default S-NSSAI) to the Allowed NSSAI before an S-NSSAI validity time of a single S-NSSAI in the Allowed NSSAI expires. If there is no S-NSSAI present in the Allowed NSSAI or Partially Allowed NSSAI after AMF removes the S-NSSAI locally and the AMF cannot determine a new Allowed NSSAI then based on operator policy AMF shall either enter RM-DEREGISTERED state for the UE or execute the Network-initiated Deregistration procedure described in clause 4.2.2.3.3 of TS 23.502.

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, 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. The PDU Session status is synchronized at next time when the UE connects to the network
NOTE 4:
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 5:
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.

5.15.17 Partial Network Slice support in a Registration Area |R18| p. 287

A Network Slice may be supported in one or more TAs in a PLMN/SNPN. The Partial Network Slice support in a Registration Area for a UE includes configuring the UE with a Partially Allowed NSSAI and/or S-NSSAI(s) rejected partially in the RA.

When creating a Registration Area for UEs registering over the 3GPP access and supporting the Partial Network Slice support in a Registration Area, the AMF may consider the trade-off between signalling for paging in TAs where the S-NSSAI is not supported versus the signalling for Mobility Registration Updates to register with the S-NSSAI in the TA(s) where the S-NSSAI is supported, so that the AMF may create a Registration Area including the TA(s) where a requested S-NSSAI is not supported. For supporting UEs, whether the AMF uses the Partially Allowed NSSAI or rejects the S-NSSAIs partially in the RA, or whether the AMF rejects the S-NSSAI for the current RA, is a per S-NSSAI decision which is based on AMF local policy. If supported and allowed by local policy, the Partially Allowed NSSAI and S-NSSAIs rejected partially in the RA may be applied simultaneously for one UE for different S-NSSAIs.

For such S-NSSAI:

If requested by the UE from a TA where the S-NSSAI is not supported (including the case when the S-NSSAI is provided as a rejected S-NSSAI for the TA from the NSSF):
- the S-NSSAI is included either in the Partially Allowed NSSAI or the AMF rejects the S-NSSAI partially in the RA; or
- if the S-NSSAI is subject to NSAC for maximum number of UEs, then the AMF should send this S-NSSAI as rejected partially in the RA, in the Registration Accept message.
- If the S-NSSAI is subject to NSSAA and successful NSSAA status for the S-NSSAI is not present in the AMF, then the AMF either sends this S-NSSAI as rejected partially in the RA in the Registration Accept message, or the AMF starts executing NSSAA and includes the S-NSSAI in the Pending NSSAI in the Registration Accept message. If the S-NSSAI is subject to NSSAA and successful NSSAA status for the S-NSSAI is present, then the AMF may include the S-NSSAI either in the Partially Allowed NSSAI or the AMF rejects the S-NSSAI partially in the RA.
  
  NOTE 1:
  In roaming case the NSSAA requirement is based on the mapped S-NSSAI of the HPLMN.
- if the slice deregistration inactivity timer is configured for the S-NSSAI (see clause 5.15.15.3), then AMF should send this S-NSSAI as rejected partially in the RA.
If requested by the UE from a TA where the S-NSSAI is supported (including the case when the S-NSSAI is provided in the Allowed NSSAI from the NSSF):
- the S-NSSAI is included in the Partially Allowed NSSAI; or
- if the S-NSSAI is subjected to NSAC for maximum number of UEs, then the AMF should restrict the RA so that the S-NSSAI is supported in all the TAs of the RA and includes the S-NSSAI in the Allowed NSSAI.
- If the S-NSSAI is subject to NSSAA, then the AMF starts executing NSSAA and sends this S-NSSAI in the Pending NSSAI in the Registration Accept message, unless successful NSSAA status is present in the AMF for this S-NSSAI (in which case it can be sent in the Partially Allowed NSSAI).
  
  NOTE 2:
  In roaming case the NSSAA requirement is based on the mapped S-NSSAI of the HPLMN.
- if the S-NSSAI is included in neither the Partially Allowed NSSAI nor the Allowed NSSAI, the AMF may reject the S-NSSAI as described in clause 5.15.4.1.1.

While the S-NSSAIs of the Allowed NSSAI are supported in all the TAs of the Registration Area, the S-NSSAIs of the Partially Allowed NSSAI are supported only in the TAs corresponding to the list of TAs (which are subset of the list of TAIs forming the Registration Area) associated with the S-NSSAI.

If the UE supports Partial Network Slice support in a Registration Area, the AMF may create a Registration Area for the UE considering the support of the S-NSSAIs of the Requested NSSAI in the current TA and in the neighbouring TAs and provides to the UE in the Registration Accept message or in the UE Configuration Update Command message the Partially Allowed NSSAI or the S-NSSAIs rejected partially in the RA as follows:

If one or more of the requested S-NSSAI(s) are supported in a subset of the TAs of the (potential) Registration Area, the AMF may include such S-NSSAI(s) in the Partially Allowed NSSAI and corresponding mapping information of the S-NSSAI(s) of the Partially Allowed NSSAI to the HPLMN S-NSSAI(s). For each S-NSSAI of the Partially Allowed NSSAI the AMF provides a list of TAs where the S-NSSAI is supported. The UE is considered registered with the S-NSSAI in the whole Registration area. The AMF also provides the Partially Allowed NSSAI (without indication of the TA list where the partially allowed S-NSSAIs are supported) to the NG-RAN together with the UE's context.
Alternatively, the AMF may reject the S-NSSAI(s) with reject cause indicating "partially in the RA". For each S-NSSAI of the S-NSSAIs rejected partially in the RA the AMF provides a list of TAs where the S-NSSAI is not supported.

For Partially Allowed NSSAI the following applies:

the UE is considered registered with an S-NSSAI of the Partially Allowed NSSAI in the whole Registration area. The UE does not trigger registration when moving between the TAs of support and non-support for the S-NSSAI within the RA.
The UE is allowed to initiate PDU Session establishment for the S-NSSAI only when the UE is in a TA where the S-NSSAI is supported.
If the AMF determines a PDU Session is associated with S-NSSAI present in the Partially Allowed NSSAI, the AMF indicates to the SMF that the PDU Session is subject to area restrictions for the S-NSSAI. As a result, the SMF subscribes to "UE mobility event notification" event for reporting UE presence in Area of Interest by providing S-NSSAI to the AMF as described in clauses 5.6.11 and 5.3.4.4 if this event has not been subscribed before. When the AMF does not indicate to the SMF that the PDU Session is subject to area restriction for the S-NSSAI, the SMF may unsubscribe "UE mobility event notification" event in the AMF and if this event has been subscribed before.
When the UE has already established a PDU Session with an S-NSSAI part of the Partially Allowed NSSAI, the UE is allowed to activate the User Plane resources of the PDU Session only when the UE is in a TA part of the list of TAs associated with the S-NSSAI.
When the User Plane resources are activated for a PDU Session of an S-NSSAI part of the Partially Allowed NSSAI and the UE moves to a TA which is not part of the list of TAs associated with the S-NSSAI, the NG-RAN releases the User Plane resources for the PDU Session as described in step 1d in clause 4.3.4.2 of TS 23.502 and the SMF deactivates the PDU Session as described in step 3a in clause 4.3.4.2 of TS 23.502, but the PDU Session context in UE and SMF is not released. The User Plane resources for the PDU Session shall not be activated as long as the UE is located in a TA which is not part of the list of TAs associated with the S-NSSAI of the Partially Allowed NSSAI. The UE shall not send user data as payload of a NAS message (see clause 5.31.4.1) in uplink directions. The AMF determines the UE presence in Area of Interest as described in Annex D, clause D.1 and D.2 of TS 23.502 and notifies the result to the SMF. When the SMF is notified by the AMF that the UE location is outside of the Area of Interest, the SMF shall not send user data as payload of NAS message (see clause 5.31.4.1) in downlink directions and disable data notification. When the SMF is notified by the AMF that the UE location is UNKNOWN as defined in Annex D, clause D.1 and D.2 of TS 23.502, then based on operator policy SMF may enable downlink data notification and trigger the Network triggered Service Request procedure to active the UP connection or send user data as payload of a NAS message (see clause 5.31.4.1) when the SMF receives downlink data or Data Notification from UPF.

For an already established PDU Session associated with an S-NSSAI included in the Partially Allowed NSSAI, even when the supporting UE is in a TA where the S-NSSAI is not supported, the supporting UE may initiate a PDU Session release procedure or PDU Session modification procedure (i.e. for PS data off status change reporting).

When the UE stores a S-NSSAI rejected partially in the RA with the associated list of TAs, the UE is allowed to initiate a Mobility Registration Update procedure to request registration with the S-NSSAI only when the UE is in a TA which is not part of the list of TAs associated with this S-NSSAI.

For a UE in CM-CONNECTED state, when a PDU Session is established on an S-NSSAI included in the Partially Allowed NSSAI, the User Plane resources are activated and the UE moves to a TA where the S-NSSAI is not supported, the NG-RAN releases the User Plane resources of the PDU sessions associated with the S-NSSAIs, as described in step 1d of clause 4.3.4.2 of TS 23.502 and the SMF deactivates the PDU session as described in step 3a of clause 4.3.4.2 of TS 23.502.

5.15.18 Support for Network Slices with Network Slice Area of Service not matching deployed Tracking Areas |R18| p. 290

5.15.18.1 General p. 290

The network support for a Network Slice is defined on a per Tracking Area granularity. It may be beneficial to deploy some Network Slices such that the Network Slice have a limited geographical availability that is not matching existing Tracking Area boundaries.

The operator can in this case decide to change the topology of the Tracking Areas so they match the boundaries of the Network Slice, or the operator may configure resources for the Network Slices in the cells of TAs where the Network Slices are to be available, and in areas of the TAs where the network slice is defined to be not available the cells are configured with zero resources.

The AMF receives from the OAM the information on availability of a network slice when the granularity is smaller than TA, i.e. if the NS-AoS includes TAs where the network slice is not available in some cells of the TA.

In order to optimize the end-to-end behaviour, the AMF can, based on NS-AoS information received from OAM, configure supporting UEs with S-NSSAI location availability information, and the network may need to monitor the S-NSSAI usage and enforce the NS-AoS e.g. if the UE does not support the S-NSSAI location availability information.

5.15.18.2 S-NSSAI location availability information p. 290

S-NSSAI location availability information defines additional restrictions to the usage of an S-NSSAI in TAs where the Network Slice availability does not match the TA boundaries. The AMF is configured per S-NSSAI whether to send the S-NSSAI location availability information to supporting UEs.

The S-NSSAI location availability information sent to the UE includes, for each applicable S-NSSAI of the Configured NSSAI, Location information indicating the cells of TAs in the RA where the related S-NSSAI is available if the S-NSSAI is not available in all the cells of the TA.

If the UE has indicated that the UE supports S-NSSAI location availability information in the 5GMM Core Network Capability (see clause 5.4.4a), the AMF may, based on OAM configuration, configure the UE with S-NSSAI location availability information for one or more S-NSSAIs when the AMF allocates an RA where the Network Slice availability does not match whole TAs, by including the S-NSSAI location availability information in the Registration Accept message or the UE Configuration Command message. A UE that receives S-NSSAI location availability information applies the information as follows.

If the S-NSSAI is rejected in the RA or rejected partially in the RA or rejected with a cause code that allows attempting to register the S-NSSAI again, the UE can request the S-NSSAI only if the S-NSSAI location availability information indicates that the S-NSSAI is available at the cell where the UE is camping.
If the S-NSSAI is in the Partially Allowed NSSAI or in the Allowed NSSAI and the UE is in a cell within the RA but outside the NS-AoS of the S-NSSAI, the following applies:
1. The UE shall not activate User Plane resources for any already established PDU Session with that S-NSSAI.
2. The UE shall not send user data as payload of a NAS message (see clause 5.31.4.1) in uplink direction.
3. For an already established PDU Session, the supporting UE may initiate signalling for PDU Session release procedure or PDU Session modification procedure (i.e. for PS data off status change reporting).
If the S-NSSAI is in the Partially Allowed NSSAI or in the Allowed NSSAI, and the UE in CM-CONNECTED state moves from a cell inside the NS-AoS to a cell outside the NS-AoS and the User Plane resources are active for a PDU Session on that S-NSSAI, the NG-RAN releases the User Plane resources as described in step 1d of the AN initiated Release of a PDU Session in clause 4.3.4.2 of TS 23.502. The SMF also deactivates the PDU Session as described in step 3a in clause 4.3.4.2 of TS 23.502.

5.15.18.3 Network based monitoring and enforcement of Network Slice Area of Service not matching deployed Tracking Areas p. 291

OAM may configure RRM policies for S-NSSAIs on a per cell basis as defined in TS 28.541, i.e. cells outside the Network Slice Area of Service while in a TA supporting the S-NSSAI are allocated with no RRM resources for the S-NSSAI.

The network may enforce the NS-AoS for an S-NSSAI as follows:

The network may monitor the validity of the S-NSSAI for UE in CM-CONNECTED state, i.e. the AMF subscribes to the AoI using the Location information of the S-NSSAI location availability information as described in TS 38.413.
If the non-supporting UE makes a PDU Session establishment request with an S-NSSAI that is not valid as per the S-NSSAI location availability information, the AMF may reject the NAS Transport message with a back-off timer using S-NSSAI based congestion control as described in clause 5.19.7.4.
If the AMF determines that the UE in CM-CONNECTED has moved outside the NS-AoS, the AMF performs the following logic:
1. If the non-supporting UE has other S-NSSAI(s) in the Allowed NSSAI, then the AMF may update the UE with a UE Configuration Update by removing the S-NSSAI from the Allowed NSSAI and optionally removing the S-NSSAI from the Configured NSSAI and then, the AMF requests the SMF to release any PDU Sessions with that S-NSSAI as per step 1f in clause 4.2.3.4 in TS 23.502.
2. If the non-supporting UE does not have any other S-NSSAI in the Allowed NSSAI, then the AMF may update the UE with a UE Configuration Update by removing the S-NSSAI from the Allowed NSSAI and optionally removing the S-NSSAI from the Configured NSSAI, and adding a default S-NSSAI to the Allowed NSSAI and then, the AMF requests the SMF to release any PDU Sessions with the removed S-NSSAI as per step 1f in clause 4.3.4.2 in TS 23.502.
  
  NOTE:
  Whether the AMF removes the S-NSSAI only from Allowed NSSAI, or from both Allowed NSSAI and Configured NSSAI, or only releases the associated PDU Sessions when the AMF enforces the NS-AoS is up to AMF configuration.
3. For a non-supporting UE that does not have any other S-NSSAI in the Allowed NSSAI nor in the Configured NSSAI, then the AMF indicates to the SMF to release the PDU Session.
If the AMF determines that the S-NSSAI becomes valid e.g. the UE has moved into the NS-AoS, the AMF may update the UE with a UCU e.g. including the S-NSSAI in the Configured NSSAI.
When the AMF determines that the S-NSSAI of a PDU Session is restricted to an NS-AoS in the PDU session, the AMF indicates to the SMF that the PDU Session is subject to area restriction for the S-NSSAI. As a result, the SMF subscribes to "UE mobility event notification" event for reporting UE presence in Area of Interest by providing S-NSSAI to the AMF as described in clauses 5.6.11 and 5.3.4.4 if this event has not been subscribed before. The AMF determines the UE presence in Area of Interest as described in Annex D, clauses D.1 and D.2 of TS 23.502 and notifies the result to the SMF. When SMF is notified that the UE location is outside of Area of Interest, SMF shall not send user data as payload of NAS message (see clause 5.31.4.1) in downlink directions and disable data notification. When the AMF does not indicate to the SMF that the PDU Session is subject to area restriction for the S-NSSAI, based on local configuration, the SMF may unsubscribe the "UE mobility event notification" event in AMF if this event has been subscribed before.
When the SMF is notified by the AMF that the UE location is UNKNOWN as defined in Annex D, clauses D.1 and D.2 of TS 23.502, then based on operator policy SMF may enable downlink data notification and trigger the Network triggered Service Request procedure to active the UP connection or send user data as payload of a NAS message (see clause 5.31.4.1) when the SMF receives downlink data or Data Notification from UPF.

5.15.19 Support of Network Slice Replacement |R18| p. 292

The Network Slice Replacement feature is used to temporarily replace an S-NSSAI with an Alternative S-NSSAI when an S-NSSAI becomes unavailable or congested. The Network Slice Replacement may be triggered in the following cases:

If the NSSF detects that an S-NSSAI becomes unavailable or congested (e.g. based on OAM or NWDAF analytics output), the NSSF sends network slice availability notification for the S-NSSAI to the AMF. The notification may include an Alternative S-NSSAI which can be used by the AMF to replace the S-NSSAI and congestion mitigation information if the S-NSSAI is congested. The NSSF notifies the AMF when the S-NSSAI is available again.
If the PCF detects that an S-NSSAI becomes unavailable or congested for a UE (e.g. based on OAM or NWDAF analytics output), the PCF sends access and mobility related policy notification to the AMF. The notification may include an Alternative S-NSSAI which can be used by the AMF to replace the S-NSSAI. The PCF notifies the AMF when the S-NSSAI is available again for the UE.
The OAM sends notification to AMF when an S-NSSAI becomes unavailable or congested (and also when this S-NSSAI becomes available again) and provides the Alternative S-NSSAI to AMF and the OAM may provide congestion mitigation information if the S-NSSAI is congested.

The network slice associated with the Alternative S-NSSAI is assumed in this specification to have NS-AoS to be covering at least the NS-AoS of the replaced network slice. If the UE moves to a cell where the replaced S-NSSAI is not supported, but still within the NS-AoS of the Alternative S-NSSAI, the AMF removes the replaced S-NSSAI from the Allowed NSSAI (if the S-NSSAI was in the Allowed NSSAI) and from the Partially Allowed NSSAI (if the UE moves out of the RA also).

If the replaced S-NSSAI is subject to area restrictions, the AMF indicates to the SMF that the PDU Session is subject to area restrictions for the replaced S-NSSAI and the AMF and the SMF then apply the area restriction for the replaced S-NSSAI as described in clause 5.15.17 or clause 5.15.18 and the SMF additionally deactivates the PDU Session when the UE is OUT of AoI.

Based on the notification above from NSSF or PCF or OAM, the AMF may determine that an S-NSSAI is to be replaced with Alternative S-NSSAI. For roaming case, the AMF subscribes the network slice availability notification of the HPLMN S-NSSAI from the NSSF in VPLMN and the NSSF in VPLMN subscribes the notification from NSSF in the HPLMN as described in clause 5.15.6.

If the notification is from NSSF or OAM, and reason for the replacement is due to congestion, the notification includes additional congestion mitigation information. The details of the congestion mitigation information from NSSF and how the congestion mitigation information is used by the AMF is described in clause 5.2.16.3.3 of TS 23.502.

The AMF uses the Alternative S-NSSAI received in the notification from the NSSF, or from OAM or from the PCF. If the NSSF or PCF or OAM do not provide an Alternative S-NSSAI in the notification, the AMF uses an Alternative S-NSSAI based on local configuration. The Alternative S-NSSAI shall be supported in the UE Registration Area. If AMF cannot determine the Alternative S-NSSAI for the S-NSSAI, e.g. OAM or NSSF doesn't provide Alternative S-NSSAI and there is no Alternative S-NSSAI in the AMF local configuration, the AMF may further interact with the PCF to determine the Alternative S-NSSAI. The event trigger in AMF for interacting with PCF is described in clause 6.1.2.5 of TS 23.503.

If the Alternative S-NSSAI is subject to NSSAA, the Alternative S-NSSAI shall only be used for UEs for which the Alternative S-NSSAI is included in the Subscribed S-NSSAIs. In this case, the AMF performs the NSSAA procedure for the Alternative S-NSSAI as described in clause 5.15.10 before the AMF triggers Network Slice Replacement as specified below.

The UE indicates the support of Network Slice Replacement feature during the UE Registration procedure. For supporting UE in CM-CONNECTED state and if there is a PDU Sessions in the UE context associated with the S-NSSAI that needs to be replaced, the AMF additionally provides the Alternative S-NSSAI for this S-NSSAI in the Allowed NSSAI and in the Configured NSSAI, if not included yet, and the mapping between S-NSSAI(s) to Alternative S-NSSAI(s) to the UE in UE Configuration Update message as follows:

for non-roaming UEs, the AMF provides the mapping of the S-NSSAI to the Alternative S-NSSAI to the UE.

NOTE 4:
In the non-roaming case, the Alternative S-NSSAI does not have to be a Subscribed S-NSSAIs, as the replaced S-NSSAI is always a subscribed S-NSSAI.
for roaming UEs when the VPLMN S-NSSAI has to be replaced by a VPLMN Alternative S-NSSAI, the AMF provides the mapping of the VPLMN S-NSSAI to the Alternative VPLMN S-NSSAI to the UE.
for roaming UEs when the HPLMN S-NSSAI has to be replaced by an Alternative HPLMN S-NSSAI, the AMF provides the mapping of the HPLMN S-NSSAI to the Alternative HPLMN S-NSSAI to the UE.

If the replaced S-NSSAI cannot be kept in the Allowed NSSAI or Partially Allowed NSSAI, the AMF additionally removes the Alternative S-NSSAI from the Allowed NSSAI or Partially Allowed NSSAI if the Alternative S-NSSAI is only used for Network Slice Replacement.

At mobility between AMFs, the source AMF provides, to the new AMF, the Alternative S-NSSAI and the mapping of the replaced S-NSSAI to the Alternative S-NSSAI in the UE context. When an S-NSSAI is subject to Network Slice Replacement, the new AMF compares the Requested NSSAI with the received UE context and updates the UE which misses the mapping of the replaced S-NSSAI to the Alternative S-NSSAI.

For the supporting UE when the UE has a NAS signalling connection, i.e. it is CM-CONNECTED or it has become CM-CONNECTED, e.g. through a Service Request procedure or through a UE registration procedure, if the AMF determines that the S-NSSAI is to be replaced and there is a PDU Session associated with the S-NSSAI in the UE context (see also NOTE 3), the AMF sends the mapping of the S-NSSAI to the Alternative S-NSSAI to the UE in the UE Configuration Update message or in the Registration Accept message.

When the S-NSSAI is replaced by the Alternative S-NSSAI, the UE associates both of the replaced S-NSSAI and the Alternative S-NSSAI with the PDU session. The UE procedure for associating applications to PDU session based on URSP described in clause 6.6.2.3 of TS 23.503 and establishing a PDU session described in clause 5.15.5.3 is based on the replaced S-NSSAI (not based on Alternative S-NSSAI).

During a new PDU Session establishment procedure for a S-NSSAI,

if the UE has received together with the Allowed NSSAI a mapping of the S-NSSAI to an Alternative S-NSSAI, the UE shall provide both the Alternative S-NSSAI and the S-NSSAI in the PDU Session Establishment message. When the AMF receives the Alternative S-NSSAI and the S-NSSAI in the PDU Session Establishment message, the AMF uses SMF Selection Subscription data of the replaced S-NSSAI and selects a suitable SMF supporting Network Slice Replacement and the Alternative S-NSSAI and verifies the Alternative S-NSSAI and the S-NSSAI based on the UE context and includes both the Alternative S-NSSAI and the S-NSSAI to the SMF in Nsmf_PDUSession_CreateSMContext service operation.
if the UE has not yet received with the Allowed NSSAI a mapping of the S-NSSAI to the Alternative S-NSSAI, the UE provides only the S-NSSAI in the PDU Session Establishment message. If the AMF determines that the requested S-NSSAI is to be replaced with the Alternative S-NSSAI and if the UE supports Network Slice Replacement, the AMF performs UE Configuration Update procedure to reconfigure the UE with the Alternative S-NSSAI. The AMF continues the PDU Session establishment procedure with the Alternative S-NSSAI and uses SMF Selection Subscription data of the replaced S-NSSAI and selects a suitable SMF supporting Network Slice Replacement and the Alternative S-NSSAI. The AMF provides both the Alternative S-NSSAI and the S-NSSAI to the SMF in Nsmf_PDUSession_CreateSMContext service operation.

The SMF proceeds with the PDU Session establishment using the Alternative S-NSSAI and the received DNN. The SMF retrieves subscription data by using the replaced S-NSSAI and the DNN. The SMF uses replaced S-NSSAI value when the SMF registers the PDU Session to the UDM. The SMF sends the Alternative S-NSSAI to NG-RAN in N2 SM information and to UE in PDU Session Establishment Accept message.

For existing PDU Session associated with an S-NSSAI that is replaced with the Alternative S-NSSAI, after the AMF sends mapping of the S-NSSAI to the Alternative S-NSSAI to the supporting UE in UE Configuration Update message, the AMF sends updates to the SMF of the PDU Session, e.g. triggering Nsmf_PDUSession_UpdateSMContext service operation, that the PDU Session is to be transferred to Alternative S-NSSAI and includes the Alternative S-NSSAI as follows (see details in clause 4.3.3 of TS 23.502):

If the SMF determines that the PDU Session is to be retained (e.g. if the anchor UPF can be reused with the alternative S-NSSAI and SSC mode 1), the SMF sends the Alternative S-NSSAI to the UPF in the N4 message, to the NG-RAN in N2 message and to the supporting UE in PDU Session Modification Command message. The S-NSSAI provided to the (R)AN and to the UPF is the Alternative S-NSSAI.
If the SMF determines that the PDU Session is to be re-established, the SMF sends the Alternative S-NSSAI to the supporting UE either in PDU Session Modification Command if the PDU Session is of SSC mode 3, or in PDU Session Release if the PDU Session is of SSC mode 2 or SSC mode 1, to trigger the re-establishment of the PDU Session. The UE includes both, the S-NSSAI and the Alternative S-NSSAI in the PDU Session Establishment message.

During registration procedure, the Requested NSSAI may include Alternative S-NSSAI(s) that are not subscribed S-NSSAI(s). In addition to the behaviour described in clause 5.15.5.2.1, the AMF verifies if S-NSSAI(s) in the Requested NSSAI are either subscribed S-NSSAI(s) or Alternative S-NSSAI(s) in UE context and based on the verification, the AMF determines whether to update the UE configuration.

When the AMF is notified that the S-NSSAI is available again (e.g. the congestion of the S-NSSAI has been mitigated), if the AMF has configured the supporting UE with the Alternative S-NSSAI, and the AMF determines for the UE in CM-CONNECTED state to use the replaced S-NSSAI again, the AMF reconfigures the supporting UE (e.g. by using UE Configuration Update procedure or in the next registration procedure) to use the replaced S-NSSAI again by removing the mapping of the replaced S-NSSAI to Alternative S-NSSAI and removing the Alternative S-NSSAI from the Allowed NSSAI if the Alternative S-NSSAI is only used for the Network Slice Replacement. The AMF also removes the Alternative S-NSSAI from the Configured NSSAI if the Alternative S-NSSAI is not one of the Subscribed S-NSSAIs. If the UE is in CM-IDLE, the AMF can wait until the UE in CM-CONNECTED state as described in clause 5.23. When the UE establishes a NAS signalling connection, e.g. through a Service Request procedure or through a UE registration procedure, the AMF reconfigures the UE.

If there is an existing PDU Session associated with the Alternative S-NSSAI for the S-NSSAI being available again or not congested anymore, the AMF updates the SMF(s) of the PDU Session(s), by Nsmf_PDUSession_UpdateSMContext service operation, causing the PDU Session to be transferred to the replaced S-NSSAI. The event trigger in SMF for interacting with PCF is described in clause 6.1.3.5 of TS 23.503.

If the SMF determines that the PDU Session is to be retained (e.g. if the anchor UPF can be reused with the replaced S-NSSAI and SSC mode 1), the SMF sends the replaced S-NSSAI i.e. does not include Alternative S-NSSAI to the UPF in the N4 message, to the NG-RAN in N2 message and to the supporting UE in PDU Session Modification Command message. The S-NSSAI provided to the (R)AN and to the UPF is the replaced S-NSSAI.
If the SMF determines that the PDU Session is to be re-established, the SMF sends the replaced S-NSSAI (i.e. does not include Alternative S-NSSAI) to the supporting UE either in PDU Session Modification Command if the PDU Session is of SSC mode 3, or in PDU Session Release if the PDU Session is of SSC mode 2 or SSC mode 1, to trigger the re-establishment of the PDU Session. The UE includes the replaced S-NSSAI in the PDU Session Establishment message.

During a handover procedure, if an S-NSSAI has to be replaced with an Alternative S-NSSAI, the handover procedure (including any PDU session associated with the S-NSSAI to be replaced) shall continue unaffected by the Network Slice Replacement. Any Network Slice Replacement for the S-NSSAI shall not take place during the handover.

During NSSAA re-authentication procedure for an S-NSSAI, if the S-NSSAI has to be replaced with Alternative S-NSSAI, the AMF shall continue with the NSSAA procedure unaffected by the Network Slice Replacement and the AMF executes the Network Slice Replacement after the NSSAA procedure is completed.

If NSAC for maximum number of PDU sessions is configured for the replaced S-NSSAI and/or the Alternative S-NSSAI, the SMF performs NSAC by interacting with the NSACF of the replaced S-NSSAI and/or the NSACF of the Alternative S-NSSAI based on operator determined policies configured in the SMF (e.g. for the increase of Alternative S-NSSAI and the decrease of replaced S-NSSAI).

5.15.20 Support of Network Slice Instance Replacement |R18| p. 295

The Network Slice Instance Replacement is used when a PDU Session for a given S-NSSAI is established using a selected Network Slice instance and the S-NSSAI corresponding to this Network Slice instance is associated with multiple Network Slice instances. In this case, the network may change the Network Slice instance for the S-NSSAI if the selected Network Slice instance is no longer available (e.g. due to overload). The AMF may subscribe with the NSSF for notifications when any of the Network Slice instances served by the AMF is congested or no longer available. In case of roaming, the NSSF of VPLMN subscribes with the NSSF of the HPLMN for notifications. When the NSSF notifies the AMF that a Network Slice instance is congested or no longer available, for some of PDU Sessions associated with the Network Slice instance that is no longer available, the AMF may delete old NSI ID corresponding to the Network Slice instance that is no longer available and the SMF of the PDU Session(s) selected by using such old NSI ID is informed by the AMF to release the PDU Session(s). Subsequently, the SMF triggers the impacted UE(s) to establish new PDU session(s) associated with the same S-NSSAI as described in clause 5.6.9.2 for PDU Session(s) of SSC Mode 2 and SSC Mode 3. The AMF selects a new Network Slice instance for the given S-NSSAI during PDU Session Establishment.