Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 24.501  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.4…   4.4.3…   4.5…   4.5.3…   4.6…   4.7…   4.9…   4.15…   5…   5.2…   5.3…   5.3.2…   5.3.7…   5.3.19…   5.4…   5.4.1.3…   5.4.2…   5.4.4…   5.4.5…   5.4.6…   5.5…   5.5.1.2.4   5.5.1.2.5…   5.5.1.3…   5.5.1.3.4   5.5.1.3.5…   5.5.2…   5.6…   5.6.2…   6…   6.1.4…   6.2…   6.3…   6.3.2…   6.3.3…   6.4…   6.4.1.4…   6.4.2…   6.5…   7…   8…   8.2.9…   8.3…   9…   9.11.2…   9.11.2.10…   9.11.3…   9.11.3.4…   9.11.3.8…   9.11.3.14…   9.11.3.18C…   9.11.3.29…   9.11.3.33…   9.11.3.39…   9.11.3.45…   9.11.3.50…   9.11.3.53A…   9.11.3.68…   9.11.3.75…   9.11.4…   9.11.4.10…   9.11.4.13…   9.11.4.16…   9.11.4.30…   9.12   10…   A…   B…   C…   D…   D.6…   D.6.3…   D.6.8   D.7… 
4.6 Network slicing  4.6.1 General  4.6.2 Mobility management aspects  4.6.2.1 General  4.6.2.2 NSSAI storage  4.6.2.3 Provision of NSSAI to lower layers in 5GMM-IDLE mode  4.6.2.4 Network slice-specific authentication and authorization  4.6.2.5 Mobility management based network slice admission control  4.6.2.6 Provision of NSAG information to lower layers  4.6.2.7 Mobility management based network slice replacement  4.6.2.8 Mobility management for optimised handling of temporarily available network slices  4.6.2.9 Mobility management based network slice usage control  4.6.2.10 Mobility management aspects of handling network slices with NS-AoS not matching deployed tracking areas  4.6.2.11 Mobility management for partial network slice  4.6.3 Session management aspects  4.6.3.0 General  4.6.3.1 Session management based network slice admission control  4.6.3.2 Support of network slice admission control and interworking with EPC  4.6.3.3 Session management based network slice data rate limitation control  4.6.3.4 Session management based network slice replacement  4.6.3.5 Session management for optimized handling of temporarily available network slices  4.6.3.6 Session management for partial network slice  4.6.3.7 Session management aspect of handling network slices with NS-AoS not matching deployed tracking areas 
...

 

4.6  Network slicing  p. 97

4.6.1  General  p. 97

The 5GS supports network slicing as described in TS 23.501. Within a PLMN or SNPN, a network slice is identified by an S-NSSAI, which is comprised of a slice/service type (SST) and a slice differentiator (SD). Inclusion of an SD in an S-NSSAI is optional. A set of one or more S-NSSAIs is called the NSSAI. The following S-NSSAIs and NSSAIs are defined in TS 23.501:
  1. configured NSSAI;
  2. requested NSSAI;
  3. allowed NSSAI;
  4. subscribed S-NSSAIs;
  5. pending NSSAI;
  6. alternative S-NSSAIs; and
  7. partially allowed NSSAI.
The following S-NSSAIs and NSSAIs are defined in the present document:
  1. rejected NSSAI for the current PLMN or SNPN;
  2. rejected NSSAI for the current registration area;
  3. rejected NSSAI for the failed or revoked NSSAA;
  4. rejected NSSAI for the maximum number of UEs reached;
  5. alternative NSSAI;
  6. partially rejected NSSAI;
  7. on-demand S-NSSAIs; and
  8. on-demand NSSAI.
In roaming scenarios, rejected NSSAI for the current PLMN or SNPN, rejected NSSAI for the current registration area, rejected NSSAI for the maximum number of UEs reached, or partially rejected NSSAI includes one or more S-NSSAIs for the current PLMN and also contains a set of mapped S-NSSAI(s). An S-NSSAI included in the rejected NSSAI for the failed or revoked NSSAA is an HPLMN S-NSSAI.
In case of a PLMN, a serving PLMN may configure a UE with:
  1. the configured NSSAI per PLMN;
  2. NSSRG information if the UE has indicated that it supports the subscription-based restrictions to simultaneous registration of network slices feature;
  3. on-demand NSSAI if the UE has indicated it supports the network slice usage control feature;
  4. S-NSSAI time validity information if the UE has indicated that it supports S-NSSAI time validity information; and
  5. S-NSSAI location validity information if the UE has indicated that it supports S-NSSAI location validity information.
In addition, the HPLMN may configure a UE with a single default configured NSSAI and consider the default configured NSSAI as valid in a PLMN for which the UE has neither a configured NSSAI nor an allowed NSSAI. The support for NSSRG information by the UE and the network, respectively, is optional.
In case of an SNPN, the SNPN may configure a UE which is neither registering nor registered for onboarding services in SNPN with:
  1. a configured NSSAI applicable to the SNPN;
  2. NSSRG information if the UE has indicated that it supports the subscription-based restrictions to simultaneous registration of network slices feature;
  3. S-NSSAI time validity information if the UE has indicated that it supports S-NSSAI time validity information;
  4. on-demand NSSAI if the UE has indicated it supports the network slice usage control feature; and
  5. S-NSSAI location validity information if the UE has indicated that it supports S-NSSAI location validity information.
In addition, the credential holder may configure a single default configured NSSAI associated with the selected entry of the "list of subscriber data" or the PLMN subscription and consider the default configured NSSAI as valid in a SNPN for which the UE has neither a configured NSSAI nor an allowed NSSAI. If the UE is registering or registered for onboarding services in SNPN, the serving SNPN shall not provide a configured NSSAI to the UE. The support for NSSRG information by the UE and the network, respectively, is optional.
The allowed NSSAI and the rejected NSSAI for the current registration area are managed per access type independently, i.e. 3GPP access or non-3GPP access, and is applicable for the registration area. If the UE does not have a valid registration area, the rejected NSSAI for the current registration area is applicable to the tracking area on which it was received. If the registration area contains TAIs belonging to different PLMNs, which are equivalent PLMNs, the allowed NSSAI, the rejected NSSAI for the current registration area, rejected NSSAI for the failed or revoked NSSAA and rejected NSSAI for the maximum number of UEs reached are applicable to these PLMNs in this registration area.
The allowed NSSAI that is associated with a registration area containing TAIs belonging to different PLMNs, which are equivalent PLMNs, can be used to form the requested NSSAI for any of the equivalent PLMNs when the UE is outside of the registration area where the allowed NSSAI was received.
When the network slice-specific authentication and authorization procedure is to be initiated for one or more S-NSSAIs in the requested NSSAI or the network slice-specific authentication and authorization procedure is ongoing for one or more S-NSSAIs, these S-NSSAI(s) will be included in the pending NSSAI. When the network slice-specific authentication and authorization procedure is completed for an NSSAI that has been in the pending NSSAI, the S-NSSAI will be moved to the allowed NSSAI or rejected NSSAI depending on the outcome of the procedure. The AMF sends the updated allowed NSSAI to the UE over the same access of the requested S-NSSAI. The AMF sends the updated partially allowed NSSAI to the UE only over the 3GPP access. The AMF sends the updated rejected NSSAI over either 3GPP access or non-3GPP access. The pending NSSAI is managed regardless of access type i.e. the pending NSSAI is applicable to both 3GPP access and non-3GPP access for the current PLMN even if sent over only one of the accesses. If the registration area contains TAIs belonging to different PLMNs, which are equivalent PLMNs, the pending NSSAI is applicable to these PLMNs in this registration area.
The rejected NSSAI for the current PLMN or SNPN is applicable for the whole registered PLMN or SNPN regardless of the access type. The AMF shall only send a rejected NSSAI for the current PLMN when the registration area consists of TAIs that only belong to the registered PLMN. If the UE receives a rejected NSSAI for the current PLMN, and the registration area also contains TAIs belonging to different PLMNs, the UE shall treat the received rejected NSSAI for the current PLMN as applicable to the whole registered PLMN.
The rejected NSSAI for the failed or revoked NSSAA includes one or more S-NSSAIs that have failed the network slice-specific authentication and authorization or for which the authorization have been revoked, and are applicable for the whole registered PLMN or SNPN regardless of the access type.
The rejected NSSAI for the maximum number of UEs reached is applicable for the whole registered PLMN or SNPN, and the access type over which the rejected NSSAI was sent. The AMF shall send a rejected NSSAI including S-NSSAI(s) with the rejection cause "S-NSSAI not available due to maximum number of UEs reached", when one or more S-NSSAIs are indicated that the maximum number of UEs has been reached. If the timer T3526 associated with the S-NSSAI(s) was started upon reception of the rejected NSSAI for the maximum number of UEs reached, the UE may remove the S-NSSAI(s) from the rejected NSSAI including S-NSSAI(s) with the rejection cause "S-NSSAI not available due to maximum number of UEs reached", if the timer T3526 associated with the S-NSSAI(s) expires. If one or more S-NSSAIs are removed from the rejected NSSAI for the maximum number of UEs reached, the timer T3526 associated with the removed S-NSSAI(s) shall be stopped, if running. The UE shall not stop the timer T3526 if the UE selects an E-UTRA cell connected to EPC.
If the UE receives a rejected NSSAI for the maximum number of UEs reached, the registration area contains TAIs belonging to different PLMNs, which are equivalent PLMNs, the UE shall treat the received rejected NSSAI for the maximum number of UEs reached as applicable to these equivalent PLMNs when the UE is in this registration area.
If the UE has indicated that the UE supports network slice replacement feature and the AMF determines to provide the mapping information between the S-NSSAI to be replaced and the alternative S-NSSAI to the UE, the network shall provide the UE with the alternative NSSAI. The alternative NSSAI is managed per access type independently, i.e. 3GPP access or non-3GPP access, and is applicable for the registration area.
If the UE has indicated that the UE supports the partial network slice feature and includes the S-NSSAI(s) in the requested NSSAI, the AMF determines the S-NSSAI(s) to be included in the partially allowed NSSAI or the partially rejected NSSAI as specified in subclause 4.6.2.11. When the AMF provides both the partially allowed NSSAI and the partially rejected NSSAI to the UE, each S-NSSAI shall be either in the partially allowed NSSAI or in the partially rejected NSSAI but not both. The number of S-NSSAIs included in the partially allowed NSSAI or the partially rejected NSSAI shall not exceed 7. The sum of the number of S-NSSAI(s) stored in the partially allowed NSSAI and the allowed NSSAI shall not exceed 8. The partially allowed NSSAI is only applicable to 3GPP access and is applicable for the registration area. The partially rejected NSSAI is only applicable to 3GPP access and is applicable for the registration area.
Up

4.6.2  Mobility management aspects  p. 100

4.6.2.1  General  p. 100

Upon registration to a PLMN or SNPN (except for the registration procedure for periodic registration update, the initial registration for onboarding services in SNPN, and the registration procedure for mobility registration update when registered for onboarding services in SNPN), the UE shall send to the AMF the requested NSSAI which includes one or more S-NSSAIs of the allowed NSSAI for the PLMN or SNPN or the configured NSSAI for the PLMN or SNPN and corresponds to the network slice(s) to which the UE intends to register with, if:
  1. the UE has a configured NSSAI for the current PLMN or SNPN;
  2. the UE has an allowed NSSAI for the current PLMN or SNPN; or
  3. the UE has neither allowed NSSAI for the current PLMN or SNPN nor configured NSSAI for the current PLMN or SNPN and has a default configured NSSAI. In this case, the UE indicates to the AMF that the requested NSSAI is created from the default configured NSSAI.
In roaming scenarios, if the mapped S-NSSAI(s) associated to the allowed NSSAI or the configured NSSAI are missing, the UE shall locally set the mapped S-NSSAI to the same value as the received S-NSSAI. Additionally, if the UE receives a Rejected NSSAI IE or an Extended rejected NSSAI IE without associated mapped S-NSSAI(s), and the rejected NSSAI is different from the rejected NSSAI for the failed or revoked NSSAA, the UE shall locally set the mapped S-NSSAI(s) to the same value as the received S-NSSAI.
Other than S-NSSAIs contained in the NSSAIs described above, the requested NSSAI can be formed based on the S-NSSAI(s) available in the UE (see subclause 5.5.1.3.2 for further details). In roaming scenarios, the UE shall also provide the mapped S-NSSAI(s) for the requested NSSAI.
The AMF verifies if the requested NSSAI is permitted based on the subscribed S-NSSAIs in the UE subscription and, in roaming scenarios the mapped S-NSSAI(s) provided by the UE, and if so then the AMF shall provide the UE with the allowed NSSAI for the PLMN or SNPN, and shall also provide the UE with the mapped S-NSSAI(s) for the allowed NSSAI for the PLMN or SNPN. Additionally, if the AMF allows one or more subscribed S-NSSAIs for the UE, the AMF may include the allowed subscribed S-NSSAI(s) in the allowed NSSAI in the REGISTRATION ACCEPT message. The AMF shall ensure that there are not two or more S-NSSAIs of the allowed NSSAI which are mapped to the same S-NSSAI of the HPLMN or the subscribed SNPN. If
  1. all the S-NSSAIs included in the requested NSSAI are rejected, or the requested NSSAI was not included by the UE;
  2. all default S-NSSAIs are not allowed; and
  3. the UE is neither registering nor registered for onboarding services in SNPN and the UE is neither registering nor registered for emergency services;
then the AMF may reject the registration request (see subclauses 5.5.1.2.5 and 5.5.1.3.5 for further details).
In roaming scenarios, if the mapped S-NSSAI(s) associated to requested NSSAI are missing, the AMF shall locally set the mapped S-NSSAI to the same value as the received S-NSSAI.
The set of network slice(s) for a UE can be changed at any time while the UE is registered to a PLMN or SNPN, and the change may be initiated by the network or the UE. In this case, the allowed NSSAI and associated registration area may be changed during the registration procedure or the generic UE configuration update procedure. The configured NSSAI and the rejected NSSAI may be changed during the registration procedure or the generic UE configuration update procedure. The default configured NSSAI may be changed by sending a UE parameters update transparent container to the UE during the NAS transport procedure. The pending NSSAI may be changed during the registration procedure. In addition, using the generic UE configuration update procedure, the network may trigger the registration procedure in order to update the allowed NSSAI.
The UE in NB-N1 mode does not include the requested NSSAI during the registration procedure if the 5GS registration type IE indicates "mobility registration updating", procedure is not initiated to change the slice(s) that the UE is currently registered to, and the UE is still in the current registration area.
The AMF does not include the allowed NSSAI during a registration procedure with the 5GS registration type IE indicating "mobility registration updating" for the UE in NB-N1 mode, except if the allowed NSSAI has changed for the UE.
The UE does not include the requested NSSAI during the registration procedure if the 5GS registration type IE indicates "SNPN onboarding registration" or the UE is registered for onboarding services in SNPN. The AMF does not include the allowed NSSAI during a registration procedure with the 5GS registration type IE indicating "SNPN onboarding registration" or during a registration procedure when the UE is registered for onboarding services in SNPN.
The UE considers the last received allowed NSSAI as valid until the UE receives a new allowed NSSAI.
Up

4.6.2.2  NSSAI storage  p. 101

If available, the configured NSSAI(s) shall be stored in a non-volatile memory in the ME as specified in Annex C. For a configured NSSAI, if there is:
  1. associated NSSRG information, the NSSRG information shall also be stored in a non-volatile memory in the ME as specified in Annex C;
  2. associated NSAG information, the NSAG information shall be stored in the ME;
  3. associated S-NSSAI time validity information, the S-NSSAI time validity information shall also be stored in a non-volatile memory in the ME as specified in Annex C;
  4. associated S-NSSAI location validity information, the S-NSSAI location validity information shall also be stored in a non-volatile memory in the ME as specified in Annex C; and
  5. associated on-demand NSSAI, the on-demand NSSAI shall also be stored in a non-volatile memory in the ME as specified in Annex C.
Each of the configured NSSAI stored in the UE, including the default configured NSSAI, is a set composed of at most 16 S-NSSAIs. Each of the configured NSSAI, except the default configured NSSAI, is associated with a PLMN identity or SNPN identity and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, the selected entry of the "list of subscriber data" or the selected PLMN subscription.
The allowed NSSAI(s) should be stored in a non-volatile memory in the ME as specified in Annex C. The partially allowed NSSAI(s) should be stored in a non-volatile memory in the ME as specified in Annex C. For an allowed NSSAI, if there is associated alternative NSSAI, the alternative NSSAI should also be stored in a non-volatile memory in the ME as specified in Annex C.
Each of the allowed NSSAI stored in the UE is a set composed of at most 8 S-NSSAIs and is associated with a PLMN identity or SNPN identity, an access type and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, the selected entry of the "list of subscriber data" or the selected PLMN subscription. Each of the alternative NSSAI stored in the UE is a set composed of at most 8 pairs of S-NSSAI to be replaced and alternative S-NSSAI, and is associated with a PLMN identity or SNPN identity, an access type and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, the selected entry of the "list of subscriber data" or the selected PLMN subscription. Each of the partially allowed NSSAI stored in the UE is a set composed of at most 7 S-NSSAIs and a list of TAs for which S-NSSAI is supported, and is associated with a PLMN identity or SNPN identity, 3GPP access type and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, the selected entry of the "list of subscriber data" or the selected PLMN subscription. The sum of number of S-NSSAI(s) stored in the partially allowed NSSAI and the allowed NSSAI shall not exceed 8.
Each of the pending NSSAI stored in the UE is a set composed of at most 16 S-NSSAIs and is associated with a PLMN identity or SNPN identity and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, the selected entry of the "list of subscriber data" or the selected PLMN subscription.
Each of the rejected NSSAI is associated with a PLMN identity or SNPN identity and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, the selected entry of the "list of subscriber data" or the selected PLMN subscription. The S-NSSAI(s) in the rejected NSSAI for the current registration area are further associated with one or more tracking areas where the rejected S-NSSAI(s) is not available. The S-NSSAI(s) in the rejected NSSAI for the maximum number of UEs reached are further associated with the access type over which the rejected NSSAI was received. The S-NSSAI(s) in the partially rejected NSSAI are further associated with 3GPP access.
There shall be no duplicated PLMN identities or SNPN identities associated with each of the list of configured NSSAI(s), pending NSSAI(s), rejected NSSAI(s) for the current PLMN or SNPN, rejected NSSAI(s) for the current registration area, rejected NSSAI(s) for the failed or revoked NSSAA, and rejected NSSAI for the maximum number of UEs reached.
The UE stores NSSAIs as follows:
a.
The configured NSSAI shall be stored until a new configured NSSAI is received for a given PLMN or SNPN. The network may provide to the UE the mapped S-NSSAI(s) for the new configured NSSAI which shall also be stored in the UE. When the UE is provisioned with a new configured NSSAI for a PLMN or SNPN, the UE shall:
1.
replace any stored configured NSSAI for this PLMN or SNPN with the new configured NSSAI for this PLMN or SNPN;
2.
delete any stored mapped S-NSSAI(s) for the configured NSSAI and, if available, store the mapped S-NSSAI(s) for the new configured NSSAI;
3.
delete any stored allowed NSSAI and partially allowed NSSAI for this PLMN or SNPN and, if available, the stored mapped S-NSSAI(s) for the allowed NSSAI, if the UE received the new configured NSSAI for this PLMN or SNPN and the Configuration update indication IE with the Registration requested bit set to "registration requested", in the same CONFIGURATION UPDATE COMMAND message but without any new allowed NSSAI for this PLMN or SNPN included;
4.
delete any stored rejected NSSAI and partially rejected NSSAI, and stop any timer T3526 associated with a deleted S-NSSAI in the rejected NSSAI for the maximum number of UEs reached if running;
4A.
delete any stored mapped S-NSSAI(s) for the rejected NSSAI; and
5.
delete any S-NSSAI(s) stored in the pending NSSAI that are not included in the new configured NSSAI for the current PLMN or SNPN or any mapped S-NSSAI(s), if any, stored in the pending NSSAI that are not included in the mapped S-NSSAI(s) for the configured NSSAI (if the UE is roaming or is in a non-subscribed SNPN);
If the UE having a stored configured NSSAI for a PLMN ID, receives an S-NSSAI associated with a PLMN ID from the network during the PDN connection establishment procedure in EPS as specified in TS 24.301 or via ePDG as specified in TS 24.302, the UE may store the received S-NSSAI in the configured NSSAI for the PLMN identified by the PLMN ID associated with the S-NSSAI, if not already included in the configured NSSAI and if the number of S-NSSAIs in the configured NSSAI is less than 16;
The UE may continue storing a received configured NSSAI for a PLMN and associated mapped S-NSSAI(s), if available, when the UE registers in another PLMN.
aa.
The NSAG information shall be stored until:
  1. a new NSAG information for the registered PLMN or the registered SNPN is received over 3GPP access; or
  2. a new configured NSSAI without any associated NSAG information for the registered PLMN or the registered SNPN is received over 3GPP access.
The UE shall remove any S-NSSAI from the NSAG information which is not part of the configured NSSAI, if any.
When a new NSAG information for the registered PLMN or the registered SNPN is received over 3GPP access, the UE shall replace any stored NSAG information for the registered PLMN and its equivalent PLMN(s) or the registered SNPN and its equivalent SNPN(s) with the new NSAG information for the registered PLMN or the registered SNPN.
When a new configured NSSAI without any associated NSAG information for the registered PLMN or the registered SNPN is received over 3GPP access, the UE shall delete any stored NSAG information for the registered PLMN and its equivalent PLMN(s) or the registered SNPN and its equivalent SNPN(s).
The UE shall be able to store 32 NSAG entries in the NSAG information stored for the registered PLMN or the registered SNPN.
The UE shall be able to store TAI lists for up to 4 NSAG entries in the NSAG information stored for the registered PLMN or the registered SNPN.
The UE needs not to store the NSAG information when the UE is switched off or when the UE is deregistered from the registered PLMN or the registered SNPN.
b.
The allowed NSSAI shall be stored and the mapped S-NSSAI(s) for the allowed NSSAI (if available) shall be stored for a given PLMN and its equivalent PLMN(s) in the registration area or SNPN until:
  1. a new allowed NSSAI for the same access type (i.e. 3GPP access or non-3GPP access) is received for a given PLMN or SNPN;
  2. the CONFIGURATION UPDATE COMMAND message with the Registration requested bit of the Configuration update indication IE set to "registration requested" is received and contains no other parameters (see subclauses 5.4.4.2 and 5.4.4.3);
  3. the REGISTRATION ACCEPT message is received with the "NSSAA to be performed" indicator of the 5GS registration result IE set to "Network slice-specific authentication and authorization is to be performed", and the REGISTRATION ACCEPT message contains a pending NSSAI and no new allowed NSSAI as described in subclause 5.5.1.2.4 and subclause 5.5.1.3.4; or
  4. a new partially allowed NSSAI via 3GPP access is received for a given PLMN or SNPN.
b1.
The UE shall delete the stored partially allowed NSSAI and stored mapped S-NSSAI(s) for partially allowed NSSAI over 3GPP access when:
  1. new partially allowed NSSAI for a PLMN or SNPN is received and the new partially allowed NSSAI does not include any S-NSSAI(s);
  2. the CONFIGURATION UPDATE COMMAND message with the Registration requested bit of the Configuration update indication IE set to "registration requested" is received and contains no other parameters (see subclauses 5.4.4.2 and 5.4.4.3); or
  3. the REGISTRATION ACCEPT message is received with the "NSSAA to be performed" indicator of the 5GS registration result IE set to "Network slice-specific authentication and authorization is to be performed", and the REGISTRATION ACCEPT message contains a pending NSSAI and no new partially allowed NSSAI.
The network may provide to the UE the mapped S-NSSAI(s) for the new allowed NSSAI (see subclauses 5.5.1.2 and 5.5.1.3) which shall also be stored in the UE. When a new allowed NSSAI for a PLMN or SNPN is received, the UE shall:
  1. replace any stored allowed NSSAI for this PLMN and its equivalent PLMN(s) in the registration area or this SNPN for the same access type with the new allowed NSSAI for this PLMN or SNPN;
  2. delete any stored mapped S-NSSAI(s) for the allowed NSSAI for this PLMN and its equivalent PLMN(s) in the registration area or this SNPN for the same access type and, if available, store the mapped S-NSSAI(s) for the new allowed NSSAI;
  3. remove from the stored rejected NSSAI for the current PLMN or SNPN, the rejected NSSAI for the current registration area, rejected NSSAI for the maximum number of UEs reached and the partially rejected NSSAI, the S-NSSAI(s), if any, included in the new allowed NSSAI for the current PLMN or SNPN, unless the S-NSSAI in the rejected NSSAI or the partially rejected NSSAI is associated with one or more S-NSSAI(s) in the stored mapped rejected NSSAI or the stored mapped partially rejected NSSAI, and at least one of these mapped S-NSSAI(s) is not included in the mapped S-NSSAI(s) for the new allowed NSSAI, and stop any timer T3526 associated with a deleted S-NSSAI in the rejected NSSAI for the maximum number of UEs reached if running;
  4. remove from the stored rejected NSSAI for the failed or revoked NSSAA, the S-NSSAI(s), if any, included in the new allowed NSSAI for the current PLMN (if the UE is not roaming) or the current SNPN (if the SNPN is the subscribed SNPN) or the mapped S-NSSAI(s) for the new allowed NSSAI for the current PLMN (if the UE is roaming) or the current SNPN (if the SNPN is a non-subscribed SNPN);
  5. remove from the stored mapped S-NSSAI(s) for the rejected NSSAI for the current PLMN or SNPN, the stored mapped S-NSSAI(s) for the rejected NSSAI for the current registration area, the stored mapped S-NSSAI(s) for the partially rejected NSSAI and the mapped S-NSSAI(s) for the rejected NSSAI for the maximum number of UEs reached, the S-NSSAI(s), if any, included in the mapped S-NSSAI(s) for the new allowed NSSAI for the current PLMN (if the UE is roaming) or the current SNPN (if the SNPN is a non-subscribed SNPN), and stop any timer T3526 associated with a deleted S-NSSAI in the rejected NSSAI for the maximum number of UEs reached if running; and
  6. remove from the stored pending NSSAI for this PLMN and its equivalent PLMN(s) in the registration area or this SNPN, one or more S-NSSAIs, if any, included in the new allowed NSSAI for the current PLMN and these equivalent PLMN(s) (if the UE is not roaming) or the current SNPN (if the SNPN is the subscribed SNPN) or the mapped S-NSSAI(s) for the new allowed NSSAI for the current PLMN and these equivalent PLMN(s) (if the UE is roaming) or the current SNPN (if the SNPN is a non-subscribed SNPN).
The network may provide to the UE the partially allowed NSSAI. When a new partially allowed NSSAI for a PLMN or SNPN is received and the new partially allowed NSSAI includes one or more S-NSSAI(s), the UE shall:
  1. replace any stored partially allowed NSSAI for this PLMN and its equivalent PLMN(s) in the registration area or this SNPN via the 3GPP access with the new partially allowed NSSAI for this PLMN or SNPN;
  2. delete any stored mapped S-NSSAI(s) for the partially allowed NSSAI for this PLMN and its equivalent PLMN(s) in the registration area or this SNPN for the 3GPP access type and, if available, store the mapped S-NSSAI(s) for the new partially allowed NSSAI;
  3. remove from the stored rejected NSSAI for the current PLMN or SNPN, the rejected NSSAI for the current registration area, rejected NSSAI for the maximum number of UEs reached and the partially rejected NSSAI, the S-NSSAI(s), if any, included in the new partially allowed NSSAI for the current PLMN or SNPN, unless the S-NSSAI in the rejected NSSAI or the partially rejected NSSAI is associated with one or more S-NSSAI(s) in the stored mapped rejected NSSAI or the stored mapped partially rejected NSSAI, and at least one of these mapped S-NSSAI(s) is not included in the mapped S-NSSAI(s) for the new partially allowed NSSAI, and stop any timer T3526 associated with a deleted S-NSSAI in the rejected NSSAI for the maximum number of UEs reached if running;
  4. remove from the stored rejected NSSAI for the failed or revoked NSSAA, the S-NSSAI(s), if any, included in the new partially allowed NSSAI for the current PLMN (if the UE is not roaming) or the current SNPN (if the SNPN is the subscribed SNPN) or the mapped S-NSSAI(s) for the new partially allowed NSSAI for the current PLMN (if the UE is roaming) or the current SNPN (if the SNPN is a non-subscribed SNPN);
  5. remove from the stored mapped S-NSSAI(s) for the rejected NSSAI for the current PLMN or SNPN, the stored mapped S-NSSAI(s) for the rejected NSSAI for the current registration area, the stored mapped S-NSSAI(s) for the partially rejected NSSAI and the mapped S-NSSAI(s) for the rejected NSSAI for the maximum number of UEs reached, the S-NSSAI(s), if any, included in the mapped S-NSSAI(s) for the new partially allowed NSSAI for the current PLMN (if the UE is roaming) or the current SNPN (if the SNPN is a non-subscribed SNPN), and stop any timer T3526 associated with a deleted S-NSSAI in the rejected NSSAI for the maximum number of UEs reached if running; and
  6. remove from the stored pending NSSAI for this PLMN and its equivalent PLMN(s) in the registration area or this SNPN, one or more S-NSSAIs, if any, included in the new partially allowed NSSAI for the current PLMN and these equivalent PLMN(s) (if the UE is not roaming) or the current SNPN (if the SNPN is the subscribed SNPN) or the mapped S-NSSAI(s) for the new partially allowed NSSAI for the current PLMN and these equivalent PLMN(s) (if the UE is roaming) or the current SNPN (if the SNPN is a non-subscribed SNPN).
ba.
The alternative NSSAI and the mapped S-NSSAI(s) for the alternative NSSAI (if the UE is roaming) shall be stored for a given PLMN and its equivalent PLMN(s) or SNPN until a new alternative NSSAI for the same access type (i.e. 3GPP access or non-3GPP access) is received for a given PLMN or SNPN.
When a new alternative NSSAI for a given PLMN or SNPN is received and the new alternative NSSAI includes a list of mapping information between the S-NSSAI to be replaced and the alternative S-NSSAI, the UE shall:
  1. replace any stored alternative NSSAI for this PLMN and its equivalent PLMN(s) or this SNPN for the same access type with the new alternative NSSAI for this PLMN or SNPN; and
  2. delete any stored mapped S-NSSAI(s) for the alternative NSSAI for this PLMN and its equivalent PLMN(s) or this SNPN for the same access type and, if available, store the mapped S-NSSAI(s) for the new alternative NSSAI.
When a new alternative NSSAI for a given PLMN or SNPN is received and the new alternative NSSAI does not include any mapping information between the S-NSSAI to be replaced and the alternative S-NSSAI, the UE shall delete any stored alternative NSSAI for this PLMN and its equivalent PLMN(s) or this SNPN for the same access type.
When the UE locally removes either the replaced S-NSSAI or the alternative S-NSSAI in the allowed NSSAI upon expiry of the associated slice deregistration inactivity timer, the UE shall delete the entry including the replaced S-NSSAI or the alternative S-NSSAI stored in the alternative NSSAI.
c.
When the UE receives the S-NSSAI(s) included in the rejected NSSAI in the REGISTRATION ACCEPT message, the REGISTRATION REJECT message, the DEREGISTRATION REQUEST message or in the CONFIGURATION UPDATE COMMAND message, or the partially rejected NSSAI in the REGISTRATION ACCEPT message or the CONFIGURATION UPDATE COMMAND message, the UE shall:
  1. store the S-NSSAI(s) into the rejected NSSAI and the mapped S-NSSAI(s) for the rejected NSSAI based on the associated rejection cause(s);
  2. if the UE receives the S-NSSAI(s) included in the Rejected NSSAI IE, or if the UE receives the S-NSSAI(s) included in the Extended rejected NSSAI IE, or if the UE receives the S-NSSAI(s) included in the Partially rejected NSSAI IE in non-roaming case when not in SNPN access operation mode or in the subscribed SNPN, remove from the stored allowed NSSAI or partially allowed NSSAI for the current PLMN and its equivalent PLMN(s) in the registration area or the current SNPN, the S-NSSAI(s), if any, included in the:
    1. rejected NSSAI for the failed or revoked NSSAA, for each and every access type;
    2. rejected NSSAI for the current PLMN or SNPN, for each and every access type;
    3. rejected NSSAI for the current registration area, associated with the same access type;
    4. rejected NSSAI for the maximum number of UEs reached, associated with the same access type; or
    5. partially rejected NSSAI, associated with 3GPP access;
  3. if the UE receives the S-NSSAI(s) included in the Extended rejected NSSAI IE or if the UE receives the S-NSSAI(s) included in the Partially rejected NSSAI IE in roaming case or in a non-subscribed SNPN, remove from the stored allowed NSSAI or partially allowed NSSAI for the current PLMN and its equivalent PLMN(s) in the registration area or the current SNPN, the S-NSSAI(s), if any, included in the:
    1. rejected NSSAI for the current PLMN or SNPN, for each and every access type;
    2. rejected NSSAI for the current registration area, associated with the same access type;
    3. rejected NSSAI for the maximum number of UEs reached, associated with the same access type; or
    4. partially rejected NSSAI, associated with 3GPP access;
    if the mapped S-NSSAI(s) for the S-NSSAI in the stored allowed NSSAI or partially allowed NSSAI for the current PLMN or SNPN are stored in the UE, and all of the mapped S-NSSAI(s) are included in the Extended rejected NSSAI IE or Partially rejected NSSAI IE;
  4. remove from the stored mapped S-NSSAI(s) for the allowed NSSAI or partially allowed NSSAI (if available and if the UE is roaming or is a non-subscribed SNPN), the S-NSSAI(s), if any, included in the:
    1. rejected NSSAI for the failed or revoked NSSAA, for each and every access type;
    2. mapped S-NSSAI(s) for the rejected NSSAI for the current PLMN or SNPN, for each and every access type;
    3. mapped S-NSSAI(s) for the rejected NSSAI for the current registration area, associated with the same access type;
    4. mapped S-NSSAI(s) for the rejected NSSAI for the maximum number of UEs reached, associated with the same access type; or
    5. partially rejected NSSAI, associated with 3GPP access;
  5. if the UE receives the S-NSSAI(s) included in the Rejected NSSAI IE, or if the UE receives the S-NSSAI(s) included in the Extended rejected NSSAI IE in non-roaming case when not in SNPN access operation mode or in the subscribed SNPN, remove from the stored pending NSSAI for the current PLMN and its equivalent PLMN(s) in the registration area or the current SNPN, the S-NSSAI(s), if any, included in the:
    1. rejected NSSAI for the failed or revoked NSSAA, for each and every access type;
    2. rejected NSSAI for the current PLMN or SNPN, for each and every access type;
    3. rejected NSSAI for the current registration area, associated with the same access type; or
    4. rejected NSSAI for the maximum number of UEs reached, associated with the same access type;
  6. if the UE receives the S-NSSAI(s) included in the Extended rejected NSSAI IE in roaming case or in a non-subscribed SNPN, remove from the stored pending NSSAI for the current PLMN and its equivalent PLMN(s) in the registration area or the current SNPN, the S-NSSAI(s), if any, included in the:
    1. rejected NSSAI for the current PLMN or SNPN, for each and every access type;
    2. rejected NSSAI for the current registration area, associated with the same access type; or
    3. rejected NSSAI for the maximum number of UEs reached, associated with the same access type,
    if the mapped S-NSSAI(s) for the S-NSSAI in the stored pending NSSAI are stored in the UE, and all of the mapped S-NSSAI(s) are included in the Extended rejected NSSAI IE; and
  7. remove from the stored mapped S-NSSAI(s) for the pending NSSAI (if available and if the UE is roaming or is in a non-subscribed SNPN), the S-NSSAI(s), if any, included in the:
    1. rejected NSSAI for the failed or revoked NSSAA, for each and every access type;
    2. mapped S-NSSAI(s) for the rejected NSSAI for the current PLMN or SNPN, for each and every access type;
    3. mapped S-NSSAI(s) for the rejected NSSAI for the current registration area, associated with the same access type; or
    4. mapped S-NSSAI(s) for the rejected NSSAI for the maximum number of UEs reached, associated with the same access type;
If the UE receives the CONFIGURATION UPDATE COMMAND message with the Registration requested bit of the Configuration update indication IE set to "registration requested" and contains no other parameters (see subclauses 5.4.4.2 and 5.4.4.3), the UE shall delete any stored rejected NSSAI and partially rejected NSSAI.
When the UE:
  1. enters state 5GMM-DEREGISTERED following an unsuccessful registration for 5GMM causes other than #62 "No network slices available" for the current PLMN or SNPN;
  2. successfully registers with a new PLMN or a new SNPN;
  3. enters state 5GMM-DEREGISTERED following an unsuccessful registration with a new PLMN or a new SNPN; or
  4. performs inter-system change from N1 mode to S1 mode and the UE successfully completes tracking area update procedure;
and the UE is not registered with the PLMN or SNPN, which provided the rejected NSSAI, over another access, the rejected NSSAI for the current PLMN or SNPN and the rejected NSSAI for the failed or revoked NSSAA shall be deleted.
When the UE receives ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message provided with S-NSSAI and the PLMN ID in the Protocol configuration options IE or Extended protocol configuration options IE (see subclause 6.5.1.3 of TS 24.301), the UE shall remove the S-NSSAI associated with the PLMN ID from the rejected NSSAI for the current PLMN. When the UE receives ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message provided with S-NSSAI and the PLMN ID in the Protocol configuration options IE or Extended protocol configuration options IE (see subclause 6.5.1.3 of TS 24.301), the UE may remove the S-NSSAI from the rejected NSSAI for the maximum number of UEs reached for each and every access type, if any, and stop the timer T3526 associated with the S-NSSAI if running.
When the UE:
  1. deregisters over an access type;
  2. successfully registers in a new registration area over an access type;
  3. enters state 5GMM-DEREGISTERED or 5GMM-REGISTERED following an unsuccessful registration in a new registration area over an access type; or
  4. performs inter-system change from N1 mode to S1 mode and the UE successfully completes tracking area update procedure;
the rejected NSSAI for the current registration area corresponding to the access type and the partially rejected NSSAI shall be deleted. When a new partially rejected NSSAI is received without any S-NSSAI(s), the UE shall delete any stored partially rejected NSSAI for the current registration area;
d.
When the UE receives the pending NSSAI in the REGISTRATION ACCEPT message, the UE shall replace any stored pending NSSAI for this PLMN or SNPN with the new pending NSSAI received in the REGISTRATION ACCEPT message for this PLMN or SNPN. If the UE does not receive the pending NSSAI in the REGISTRATION ACCEPT message and the "NSSAA to be performed" indicator is not set to "Network slice-specific authentication and authorization is to be performed" in the 5GS registration result IE of the REGISTRATION ACCEPT message, the UE shall delete the stored pending NSSAI, if any, for this PLMN and its equivalent PLMN(s) in the registration area or this SNPN.
If the registration area contains TAIs belonging to different PLMNs, which are equivalent PLMNs, then for each of the equivalent PLMNs, the UE shall replace any stored pending NSSAI with the pending NSSAI received in the registered PLMN.
When the UE:
  1. deregisters with the current PLMN or SNPN using explicit signalling or enters state 5GMM-DEREGISTERED for the current PLMN or SNPN;
  2. successfully registers with a new PLMN not in the list of equivalent PLMNs or a new SNPN;
  3. enters state 5GMM-DEREGISTERED following an unsuccessful registration with a new PLMN or SNPN; or
  4. successfully initiates an attach or tracking area update procedure in S1 mode and the UE is operating in single-registration mode;
and the UE is not registered with the PLMN or SNPN, which provided pending NSSAI, over another access, the pending NSSAI for the current PLMN and its equivalent PLMN(s) in the registration area or the current SNPN shall be deleted;
e.
When the UE receives the Network slicing indication IE with the Network slicing subscription change indication set to "Network slicing subscription changed" in the REGISTRATION ACCEPT message or in the CONFIGURATION UPDATE COMMAND message, the UE shall delete the network slicing information for each of the PLMNs or SNPNs that the UE has slicing information stored for (excluding the current PLMN or SNPN). The UE shall delete any stored rejected NSSAI and stop any timer T3526 associated with a deleted S-NSSAI in the rejected NSSAI for the maximum number of UEs reached if running. The UE shall not delete the default configured NSSAI. Additionally, the UE shall update the network slicing information for the current PLMN or SNPN (if received) as specified above in bullets a), b), c) and d);
f.
When the UE receives the new default configured NSSAI included in the default configured NSSAI update data in the Payload container IE of DL NAS TRANSPORT message, the UE shall replace any stored default configured NSSAI with the new default configured NSSAI. In case of SNPN, the UE shall replace the stored default configured NSSAI associated with the selected entry of the "list of subscriber data" or the PLMN subscription with the new default configured NSSAI; and
g.
When the UE receives the on-demand NSSAI in the REGISTRATION ACCEPT message or CONFIGURATION UPDATE COMMAND message, the UE shall replace any stored on-demand NSSAI for the serving PLMN with the new on-demand NSSAI.
Up

4.6.2.3  Provision of NSSAI to lower layers in 5GMM-IDLE mode  p. 108

The UE NAS layer may provide the lower layers with an NSSAI (either requested NSSAI or allowed NSSAI) when the UE in 5GMM-IDLE mode sends an initial NAS message.
The AMF may indicate, via the NSSAI inclusion mode IE of a REGISTRATION ACCEPT message, an NSSAI inclusion mode in which the UE shall operate over the current access within the current PLMN or SNPN, if any (see subclauses 5.5.1.2.4 and 5.5.1.3.4), where the NSSAI inclusion mode is chosen among the following NSSAI inclusion modes described in Table 4.6.2.3.1.
Initial NAS message NSSAI inclusion mode A NSSAI inclusion mode B NSSAI inclusion mode C NSSAI inclusion mode D
REGISTRATION REQUEST message:
  1. including the 5GS registration type IE set to "initial registration"
Requested NSSAI, if anyRequested NSSAI, if anyRequested NSSAI, if anyNo NSSAI
REGISTRATION REQUEST message:
  1. including the 5GS registration type IE set to "mobility registration updating"; and
  2. initiated by case other than case g) or n) in subclause 5.5.1.3.2
Requested NSSAI, if anyRequested NSSAI, if anyRequested NSSAI, if anyNo NSSAI
REGISTRATION REQUEST message:
  1. including the 5GS registration type IE set to "mobility registration updating"; and
  2. initiated by case g) or n) in subclause 5.5.1.3.2
Allowed NSSAI, and partially allowed NSSAI, if anyAllowed NSSAI, and partially allowed NSSAI, if anyNo NSSAINo NSSAI
REGISTRATION REQUEST message:
  1. including the 5GS registration type IE set to "periodic registration updating"
Allowed NSSAI, and partially allowed NSSAI, if anyAllowed NSSAI, and partially allowed NSSAI, if anyNo NSSAINo NSSAI
SERVICE REQUEST messageAllowed NSSAI, and partially allowed NSSAI, if anySee NOTE 1No NSSAINo NSSAI
NOTE 1:
All the S-NSSAIs of the PDU sessions that have the user-plane resources requested to be re-established by the service request procedure or the S-NSSAIs of a control plane interaction triggering the service request is related to (see TS 23.501)
NOTE 2:
For a REGISTRATION REQUEST message which is triggered by emergency services, a DEREGISTRATION REQUEST message, and a SERVICE REQUEST message which is triggered by emergency services (e.g. a SERVICE REQUEST message includes the service type IE set to "emergency services" or "emergency services fallback", a SERVICE REQUEST message triggered for emergency services includes the service type IE set to "high priority access" as specified in subclause 5.6.1.2.1), no NSSAI is provided to the lower layers. If the UE performs initial registration for onboarding services in SNPN or is registered for onboarding services in SNPN, the UE NAS layer shall not provide the lower layers with an NSSAI.
NOTE 3:
The mapped configured S-NSSAI(s) from the S-NSSAI(s) of the HPLMN are not included as part of the S-NSSAIs in the requested NSSAI or the allowed NSSAI when it is provided to the lower layers.
The UE shall store the NSSAI inclusion mode:
  1. indicated by the AMF, if the AMF included the NSSAI inclusion mode IE in the REGISTRATION ACCEPT message; or
  2. if the AMF did not include the NSSAI inclusion mode IE in the REGISTRATION ACCEPT message:
    1. if the UE is pre-configured by operator to operate by default to according to mode C in the HPLMN (if the EHPLMN list is not present or is empty) or EHPLMN (if the EHPLMN list is present), (see the DefaultNSSAIInclusionMode leaf of the NAS configuration MO in TS 24.368 or the USIM file EFNASCONFIG in TS 31.102), then mode C;
    2. otherwise:
      1. mode D for 3GPP access and trusted non-3GPP access; or
      2. mode B for untrusted non-3GPP access and wireline access.
together with the identity of the current PLMN or SNPN and access type in a non-volatile memory in the ME as specified in Annex C.
The UE shall apply the NSSAI inclusion mode received in the REGISTRATION ACCEPT message over the current access within the current PLMN and its equivalent PLMN(s), if any, or the current SNPN in the current registration area.
When a UE performs a registration procedure to a PLMN which is not a PLMN in the current registration area or an SNPN, if the UE has no NSSAI inclusion mode for the PLMN or the SNPN stored in a non-volatile memory in the ME, the UE shall provide the lower layers with:
  1. no NSSAI if the UE is performing the registration procedure over 3GPP access; or
  2. requested NSSAI if the UE is performing the registration procedure over non-3GPP access.
When a UE performs a registration procedure after an inter-system change from S1 mode to N1 mode, if the UE has no NSSAI inclusion mode for the PLMN stored in a non-volatile memory in the ME and the registration procedure is performed over 3GPP access, the UE shall not provide the lower layers with any NSSAI over the 3GPP access.
Up

4.6.2.4  Network slice-specific authentication and authorization |R16|  p. 110

The UE and network may support network slice-specific authentication and authorization.
A serving PLMN or SNPN shall perform network slice-specific authentication and authorization for the S-NSSAI(s) of the HPLMN or the subscribed SNPN which are subject to it based on subscription information. The UE shall indicate whether it supports network slice-specific authentication and authorization in the 5GMM Capability IE in the REGISTRATION REQUEST message as specified in subclauses 5.5.1.2.2 and 5.5.1.3.2.
The upper layer stores an association between each S-NSSAI and its corresponding credentials for the network slice-specific authentication and authorization.
The network slice-specific authentication and authorization procedure shall not be performed unless the primary authentication and key agreement procedure as specified in the subclause 5.4.1 has successfully been completed.
The AMF informs the UE about S-NSSAI(s) for which network slice-specific authentication and authorization (except for re-NSSAA) will be performed or is ongoing in the pending NSSAI. The AMF informs the UE about S-NSSAI(s) for which NSSAA procedure is completed as success in the allowed NSSAI or in the partially allowed NSSAI. The AMF informs the UE about S-NSSAI(s) for which NSSAA procedure is completed as failure in the rejected NSSAI for the failed or revoked NSSAA. The AMF stores and handles allowed NSSAI, partially allowed NSSAI, pending NSSAI, rejected NSSAI, and 5GS registration result in the REGISTRATION ACCEPT message according to subclauses 5.5.1.2.4 and 5.5.1.3.4.
To perform network slice-specific authentication and authorization for an S-NSSAI, the AMF invokes an EAP-based network slice-specific authentication and authorization procedure for the S-NSSAI, see subclause 5.4.7 and TS 23.502 using the EAP framework as described in TS 33.501.
The AMF updates the allowed NSSAI, the partially allowed NSSAI and the rejected NSSAI using the generic UE configuration update procedure as specified in the subclause 5.4.4 after the network slice-specific authentication and authorization procedure is completed.
The AMF shall send the pending NSSAI containing all S-NSSAIs for which the network slice-specific authentication and authorization procedure (except for re-NSSAA) will be performed or is ongoing in the REGISTRATION ACCEPT message. The AMF shall also include in the REGISTRATION ACCEPT message the allowed NSSAI containing one or more S-NSSAIs from the requested NSSAI which are allowed by the AMF and for which network slice-specific authentication and authorization is not required, if any. The AMF shall also include in the REGISTRATION ACCEPT message the partially allowed NSSAI containing one or more S-NSSAIs from the requested NSSAI which are allowed by the AMF in a list of TAs within the current registration area and for which network slice-specific authentication and authorization is not required, if any.
The network slice-specific re-authentication and re-authorization procedure or the network slice-specific authorization revocation procedure can be invoked by the network for a UE supporting NSSAA at any time. After the network performs the network slice-specific re-authentication and re-authorization procedure or network slice-specific authorization revocation procedure:
  1. if network slice-specific re-authentication and re-authorization fails or network slice-specific authorization is revoked for some but not all S-NSSAIs in the allowed NSSAI or the partially allowed NSSAI,, the AMF updates the allowed NSSAI or the partially allowed NSSAI and the rejected NSSAI accordingly using the generic UE configuration update procedure as specified in the subclause 5.4.4 and inform the SMF to release all PDU sessions associated with the S-NSSAI for which network slice-specific re-authentication and re-authorization fails or network slice-specific authorization is revoked;
  2. if network slice-specific re-authentication and re-authorization fails or network slice-specific authorization is revoked for all S-NSSAIs in the allowed NSSAI or the partially allowed NSSAI but there are one or more default S-NSSAIs which are not subject to network slice-specific authentication and authorization or for which the network slice-specific authentication and authorization has been successfully performed, the AMF updates the allowed NSSAI or the partially allowed NSSAI containing these default S-NSSAIs and the rejected NSSAI accordingly using the generic UE configuration update procedure as specified in the subclause 5.4.4. The AMF shall also inform the SMF to release all PDU sessions associated with the S-NSSAI for which network slice-specific re-authentication and re-authorization fails or network slice-specific authorization is revoked; or
  3. if network slice-specific re-authentication and re-authorization fails or network slice-specific authorization is revoked for all S-NSSAIs in the allowed NSSAI or the partially allowed NSSAI and all default S-NSSAIs are subject to network slice-specific authentication and authorization, and the network slice-specific authentication and authorization has not been successfully performed for any of these default S-NSSAIs, then AMF performs the network-initiated de-registration procedure and includes the rejected NSSAI in the DEREGISTRATION REQUEST message as specified in the subclause 5.5.2.3 except when the UE has an emergency PDU session established or the UE is establishing an emergency PDU session. In this case the AMF shall send the CONFIGURATION UPDATE COMMAND message containing rejected NSSAI and inform the SMF to release all PDU sessions associated with the S-NSSAI for which network slice-specific re-authentication and re-authorization fails or network slice-specific authorization is revoked. After the emergency PDU session is released, the AMF performs the network-initiated de-registration procedure as specified in the subclause 5.5.2.3.
The UE does not include in the requested NSSAI any of the S-NSSAIs from the pending NSSAI that the UE stores, regardless of the access type. When the UE storing a pending NSSAI intends to register to one or more additional S-NSSAIs not included in the pending NSSAI, the UE initiates the registration procedure with a requested NSSAI containing these S-NSSAIs as described in subclause 5.5.1.3.2. In this case, the requested NSSAI shall also include one or more S-NSSAIs from the allowed NSSAI or the partially allowed NSSAI, if the UE still wants to use the S-NSSAI(s) from the allowed NSSAI or the partially allowed NSSAI.
During the registration procedure, when the AMF receives a requested NSSAI from a UE over an access type, for which there is a pending NSSAI including one or more S-NSSAIs that were previously requested over the same access type, the AMF considers S-NSSAIs included in the requested NSSAI and S-NSSAIs in the pending NSSAI that were previously requested over the same access type as requested S-NSSAIs by the UE. The AMF handles the requested S-NSSAIs as described in subclause 5.5.1.3.4.
When performing the network slice-specific re-authentication and re-authorization procedure if the S-NSSAI is included in the allowed NSSAI for both 3GPP and non-3GPP accesses, and the UE is registered to both 3GPP and non-3GPP accesses in the same PLMN, then the AMF selects an access type to perform network slice-specific re-authentication and re-authorization based upon operator policy.
If network slice-specific authorization is revoked for an S-NSSAI that is in the current allowed NSSAI for an access type or for an S-NSSAI that is in the current partially allowed NSSAI for 3GPP access type, the AMF shall:
  1. provide a new allowed NSSAI or a new partially allowed NSSAI, excluding the S-NSSAI for which the network slice-specific authorization is revoked; and
  2. provide a new rejected NSSAI for the failed or revoked NSSAA, including the S-NSSAI for which the network slice-specific authorization is revoked, with the rejection cause "S-NSSAI not available due to the failed or revoked network slice-specific authentication and authorization",
to the UE using the generic UE configuration update procedure as specified in the subclause 5.4.4 and inform the SMF to release all PDU sessions associated with the S-NSSAI for which the network slice-specific authorization is revoked for this access type.
If the UE requests the establishment of a new PDU session or the modification of a PDU session for an S-NSSAI for which the AMF is performing network slice-specific re-authentication and re-authorization procedure, the AMF may determine to not forward the 5GSM message to the SMF as described in subclause 5.4.5.2.4.
Up

4.6.2.5  Mobility management based network slice admission control |R17|  p. 112

A serving PLMN or SNPN can perform network slice admission control for the S-NSSAI(s) subject to NSAC to monitor and control the number of registered UEs per network slice. The timing of the network slice admission control is managed by the EAC mode per network slice, which can be either activated or deactivated for the network performing network slice admission control. The EAC mode is activated when the number of UEs associated with the S-NSSAI reaches a certain threshold (see TS 23.502)
If the EAC mode is activated for an S-NSSAI, the AMF performs network slice admission control before the S-NSSAI subject to NSAC is included in the allowed NSSAI or the partially allowed NSSAI sent to the UE. During a registration procedure (including initial registration or mobility registration updating from another AMF), if the AMF determines that the maximum number of UEs has been reached for:
  1. one or more S-NSSAIs but not all S-NSSAIs in the requested NSSAI, then the AMF includes the allowed NSSAI or the partially allowed NSSAI and the rejected NSSAI accordingly in the REGISTRATION ACCEPT message as specified in the subclauses 5.5.1.2.4 and 5.5.1.3.4;
  2. all S-NSSAIs in the requested NSSAI but there are one or more default S-NSSAIs which can be allowed to the UE, then the AMF includes the allowed NSSAI or the partially allowed NSSAI containing these default S-NSSAIs and the rejected NSSAI accordingly in the REGISTRATION ACCEPT message as specified in the subclauses 5.5.1.2.4 and 5.5.1.3.4; or
  3. all S-NSSAIs in the requested NSSAI and there are no default S-NSSAIs which can be allowed to the UE, then the AMF includes the rejected NSSAI accordingly in the REGISTRATION REJECT message as specified in the subclauses 5.5.1.2.5 and 5.5.1.3.5.
If the EAC mode is deactivated for an S-NSSAI, the AMF performs network slice admission control after the S-NSSAI subject to NSAC is included in the allowed NSSAI or the partially allowed NSSAI sent to the UE. While the AMF is waiting for response from the NSACF for the S-NSSAI, the AMF processes the NAS signalling message related to the S-NSSAI as usual i.e. like S-NSSAI in the allowed NSSAI or the partially allowed NSSAI. After the network performs the network slice admission control, if the AMF determines that the maximum number of UEs has been reached for:
  1. one or more S-NSSAIs but not all S-NSSAIs in the allowed NSSAI or the partially allowed NSSAI, then the AMF updates the allowed NSSAI or the partially allowed NSSAI and the rejected NSSAI accordingly using the generic UE configuration update procedure as specified in the subclause 5.4.4;
  2. for all S-NSSAIs in the allowed NSSAI or the partially allowed NSSAI but there are one or more default S-NSSAIs which can be allowed to the UE, then the AMF updates the allowed NSSAI or the partially allowed NSSAI containing these default S-NSSAIs and the rejected NSSAI accordingly using the generic UE configuration update procedure as specified in the subclause 5.4.4; or
  3. for all S-NSSAIs in the allowed NSSAI or the partially allowed NSSAI and there are no default S-NSSAIs which can be allowed to the UE, then the AMF performs the network-initiated de-registration procedure and includes the rejected NSSAI in the DEREGISTRATION REQUEST message as specified in the subclause 5.5.2.3 except when the UE has an emergency PDU session established or the UE is establishing an emergency PDU session.
    When the UE has an emergency PDU session established or the UE is establishing an emergency PDU session, the AMF updates the rejected NSSAI using the generic UE configuration update procedure as specified in the subclause 5.4.4 and informs the SMF to release all PDU sessions associated with the S-NSSAI. During the generic UE configuration update procedure, the AMF includes the 5GS registration result IE in the CONFIGURATION UPDATE COMMAND message and sets the Emergency registered bit of the 5GS registration result IE to "Registered for emergency services". After the emergency PDU session is released, the AMF performs the network-initiated de-registration procedure as specified in the subclause 5.5.2.3.
Based on operator policy, the mobility management based network slice admission control is not applicable for the S-NSSAI used for emergency services, or the mobility management based network slice admission control result is ignored for the S-NSSAI used for emergency services.
Based on operator policy, the mobility management based network slice admission control is not applicable for the UEs configured for priority services, or the mobility management based network slice admission control result is ignored for the UEs configured for priority services.
The mobility management based network slice admission control is not applicable to a UE that is registering or registered for onboarding services in SNPN.
Up

4.6.2.6  Provision of NSAG information to lower layers |R17|  p. 113

The support for NSAG information by the UE and the network, respectively, is optional. The NSAG information provided by the network and stored in the UE includes a list of NSAGs each of which contains:
  1. an NSAG ID;
  2. a list of S-NSSAI(s), which are associated with the NSAG and shall be part of the configured NSSAI;
  3. a priority value that is associated with the NSAG; and
  4. optionally a list of TAIs in which the NSAG is valid. If it is not provided by the network, the NSAG is valid in the PLMN or SNPN which has sent the NSAG information and its equivalent PLMN(s).
The UE NAS layer shall provide the lower layers with:
  1. the most recent NSAG information stored in the UE (see subclause 4.6.2.2);
  2. the allowed NSSAI and the partially allowed NSSAI (if any) or the requested NSSAI for the purpose of network slice-based cell reselection (see TS 23.501); and
  3. zero or more S-NSSAIs related to an access attempt for the purpose of network slice-based random access, when the access attempt is made by the UE in 5GMM-IDLE mode or 5GMM-CONNECTED mode with RRC inactive indication, determined as follows:
    1. requested NSSAI (if any), if an access attempt occurred due to the REGISTRATION REQUEST message;
    2. NSSAI(s) associated with all the PDU sessions included in the Uplink data status IE (if any), PDU session status IE (if any), or Allowed PDU session status IE (if any), if an access attempt occurred due to the SERVICE REQUEST message or CONTROL PLANE SERVICE REQUEST message;
    3. the S-NSSAI associated with the PDU session, if an access attempt occurred due to:
    4. the S-NSSAI associated with the PDU session, if an access attempt occurred due to:
      • an uplink user data packet to be sent for a PDU session with suspended user-plane resources;
      • an UL NAS TRANSPORT which carries a 5GSM message for a PDU session associated with an S-NSSAI (if any); or
      • CIoT user data to be sent in a CONTROL PLANE SERVICE REQUEST message or an UL NAS TRANSPORT message;
    5. no S-NSSAI, if an access attempt occurred due to:
      • the deregistration procedure;
      • a PDU session establishment request not associated with an S-NSSAI;
      • the service request procedure for the UE-initiated NAS transport procedure for sending SMS, LPP message, UPP-CMI container, SLPP message, SOR transparent container, UE policy container, UE parameters update transparent container, or a location services message; or
      • emergency services; or
    6. the allowed NSSAI (if any) and the partially allowed NSSAI (if any), if an access attempt occurred for other reason than those specified in bullets i) - iv).
Up

4.6.2.7  Mobility management based network slice replacement |R18|  p. 114

The support for network slice replacement by a UE or network is optional. If the UE and network support network slice replacement, and the AMF determines that an S-NSSAI included in the allowed NSSAI needs to be replaced with an alternative S-NSSAI, the AMF provides:
  1. the alternative S-NSSAI in the allowed NSSAI, if not included yet;
  2. the alternative S-NSSAI in the configured NSSAI, if not included yet;
  3. the alternative S-NSSAI in the NSAG information, if not included yet and the UE supports NSAG; and
  4. the alternative NSSAI including the mapping information between the S-NSSAI to be replaced and the corresponding alternative S-NSSAI,
to the UE, during the generic UE configuration update procedure or during the registration procedure as follows:
  1. for non-roaming UE, the AMF provides the mapping information between the S-NSSAI included in the allowed NSSAI and the alternative S-NSSAI to the UE; or
  2. for roaming UE:
    1. if the S-NSSAI included in the allowed NSSAI needs to be replaced (i.e., the S-NSSAI to be replaced is part of the VPLMN S-NSSAIs), the AMF provides the mapping information between the S-NSSAI included in the allowed NSSAI and the alternative S-NSSAI to the UE; and
    2. if the S-NSSAI included in the mapped S-NSSAI(s) for the allowed NSSAI needs to be replaced (i.e., the S-NSSAI to be replaced is part of the HPLMN S-NSSAIs), the AMF provides the mapping information between the S-NSSAI to be replaced and the alternative S-NSSAI to the UE.
If the requested NSSAI contains alternative S-NSSAI(s) that are not subscribed S-NSSAI(s), the AMF shall verify the alternative S-NSSAI(s) based on the stored alternative NSSAI.
If the alternative S-NSSAI is subject to NSSAA, the alternative S-NSSAI provided by AMF shall be part of the subscribed S-NSSAI(s) in the UE subscription. The AMF shall perform NSSAA procedure for such alternative S-NSSAI and perform network slice replacement as specified above after the NSSAA procedure for the alternative S-NSSAI is completed as success.
If re-NSSAA procedure is ongoing for the S-NSSAI to be replaced, the AMF shall continue with the re-NSSAA procedure and perform network slice replacement as specified above after the re-NSSAA procedure for the S-NSSAI to be replaced is completed as success.
If the AMF determines that the replaced S-NSSAI is available again, the AMF provides the updated alternative NSSAI excluding the replaced S-NSSAI and the corresponding alternative S-NSSAI to the UE during the UE configuration update procedure or during the registration procedure.
If all the replaced S-NSSAI(s) in alternative NSSAI are available again, the AMF provides the alternative NSSAI with Length of Alternative NSSAI contents set to 0 in the UE configuration update procedure or registration procedure.
If the UE is in a cell outside the NS-AoS of the replaced S-NSSAI but within the NS-AoS of the alternative S-NSSAI, the AMF provides the updated allowed NSSAI and partially allowed NSSAI excluding the replaced S-NSSAI, if included, in the allowed NSSAI or partially allowed NSSAI during the UE configuration update procedure or during the registration procedure.
If the alternative S-NSSAI is not part of the subscribed S-NSSAI(s), and:
  1. the replaced S-NSSAI is removed from the allowed NSSAI or the partially allowed NSSAI; or
  2. the replaced S-NSSAI is available again,
then the AMF shall provide updated allowed NSSAI or partially allowed NSSAI excluding the alternative S-NSSAI to the UE during the UE configuration update procedure or during the registration procedure. For case a), the AMF may also provide updated configured NSSAI excluding the alternative S-NSSAI to the UE during the UE configuration update procedure or during the registration procedure. For case b), the AMF shall also provide updated configured NSSAI excluding the alternative S-NSSAI to the UE during the UE configuration update procedure or during the registration procedure.
Based on SMF local configuration, if the replaced S-NSSAI is subject to NSAC or the alternative S-NSSAI is subject to NSAC or both, the SMF may perform NSAC for the replaced S-NSSAI or the alternative S-NSSAI or both.
Up

4.6.2.8  Mobility management for optimised handling of temporarily available network slices |R18|  p. 116

The UE and the network may support optimised handling of temporarily available network slices. The support for S-NSSAI time validity information by the UE and the network, respectively, is optional.
If the UE has indicated that it supports S-NSSAI time validity information, then the AMF may include the S-NSSAI time validity information for one or more S-NSSAIs included in the configured NSSAI in the REGISTRATION ACCEPT message or the CONFIGURATION UPDATE COMMAND message. If the AMF determines that the S-NSSAI time validity information for an S-NSSAI in the configured NSSAI is changed, the AMF may provide the UE with a new S-NSSAI time validity information for that S-NSSAI via the CONFIGURATION UPDATE COMMAND message.
If the UE supporting S-NSSAI time validity information, is configured with S-NSSAI time validity information for an S-NSSAI and:
  1. the S-NSSAI time validity information indicates that the S-NSSAI is available, then the UE may request the S-NSSAI in the requested NSSAI in the REGISTRATION REQUEST message;
  2. the S-NSSAI time validity information indicates that the S-NSSAI is not available, then:
    1. the UE shall not include the S-NSSAI in the requested NSSAI in the REGISTRATION REQUEST message;
    2. the UE shall remove the S-NSSAI from the stored allowed NSSAI (if any) and the stored partially allowed NSSAI (if any) in the non-volatile memory in the ME, as specified in annex C; and
    3. the S-NSSAI time validity information indicates that the S-NSSAI will not become available again, then the UE shall remove the S-NSSAI from the stored configured NSSAI in the non-volatile memory in the ME, as specified in annex C.
When the S-NSSAI time validity information of an S-NSSAI indicates that the S-NSSAI is not available, then:
  1. if the AMF receives a requested NSSAI in the REGISTRATION REQUEST message with the S-NSSAI identifying the network slice, the AMF shall:
    1. to a UE which has indicated that it supports S-NSSAI time validity information, provide:
      1. a configured NSSAI including the S-NSSAI together with the S-NSSAI time validity information in the REGISTRATION ACCEPT message if the S-NSSAI will become available again; or
      2. a configured NSSAI not including the S-NSSAI in the REGISTRATION ACCEPT message if the S-NSSAI will not become available again; or
    2. to a UE which has not indicated that it supports S-NSSAI time validity information, reject the S-NSSAI for the current PLMN or SNPN. If the registration request is accepted, the AMF shall include a configured NSSAI not including the S-NSSAI;
  2. if the AMF detects that the S-NSSAI is included in the allowed NSSAI or the partially allowed NSSAI of a UE which has:
    1. indicated that it supports S-NSSAI time validity information, the AMF shall locally remove the S-NSSAI from the allowed NSSAI (if any) and the partially allowed NSSAI (if any); or
    2. not indicated that it supports S-NSSAI time validity information, the AMF shall remove the S-NSSAI from the stored configured NSSAI (if any), allowed NSSAI (if any), and partially allowed NSSAI (if any) by sending the CONFIGURATION UPDATE COMMAND message.
When the S-NSSAI time validity information of an S-NSSAI indicates that the S-NSSAI becomes available again, the AMF shall update the configured NSSAI including the S-NSSAI to a UE which has not indicated that it supports S-NSSAI time validity information by sending CONFIGURATION UPDATE COMMAND message if the UE is subscribed to the S-NSSAI.
The S-NSSAI time validity information is applicable for the current PLMN or SNPN regardless of the access type.
Up

4.6.2.9  Mobility management based network slice usage control |R18|  p. 117

If the network supports network slice usage control, the AMF monitors network slice usage by running a slice deregistration inactivity timer per S-NSSAI and access type. If the UE supports network slice usage control, the AMF may also provide on-demand NSSAI to the UE in the REGISTRATION ACCEPT message or in the CONFIGURATION UPDATE COMMAND message. The on-demand NSSAI consists of one or more on-demand S-NSSAIs and, optionally, the slice deregistration inactivity timer per on-demand S-NSSAI.
The slice deregistration inactivity timer is started using the stored slice deregistration inactivity timer value as follows:
  1. for a PDU session which is released using 5GSM signalling, after a PDU session is released and there is no established PDU session, including any MA PDU session, associated with the S-NSSAI over the corresponding access type;
  2. for a PDU session which is released locally:
    1. when the UE or AMF indicates via the PDU session status IE that a PDU session is now in 5GSM state PDU SESSION INACTIVE and there is no established PDU session, including any MA PDU session, associated with the S-NSSAI over the corresponding access type; or
    2. when the UE or AMF receives the the PDU session status IE for which a PDU session that was previously in 5GSM state PDU SESSION ACTIVE is now indicated as being in 5GSM state PDU SESSION INACTIVE and there is no established PDU session, including any MA PDU session, associated with the S-NSSAI over the corresponding access type; or
    3. successful completion of handover of PDU session to other access and there is no established PDU session, including any MA PDU session, associated with the S-NSSAI over the corresponding access type.
The slice deregistration inactivity timer is stopped and reset:
  1. when at least a PDU session, including any MA PDU session, associated with the S-NSSAI is successfully established over the corresponding access type(s) or the S-NSSAI is removed from the allowed NSSAI or partially allowed NSSAI; or
  2. when the UE enters the state 5GMM-DEREGISTERED.
If the slice deregistration inactivity timer value is updated, the AMF updates the stored timer value and may provide the updated timer value to the UE in the REGISTRATION ACCEPT message, in a current or the next registration procedure for mobility and periodic registration update, or the CONFIGURATION UPDATE COMMAND message.
When the UE receives an updated slice deregistration inactivity timer value in the REGISTRATION ACCEPT message or the CONFIGURATION UPDATE COMMAND message from the AMF, the UE shall update the stored timer value.
Upon expiry of the slice deregistration inactivity timer, the AMF:
  1. for UE supporting network slice usage control, shall locally remove the S-NSSAI from the allowed NSSAI over the corresponding access type. In addition, the AMF may send the CONFIGURATION UPDATE COMMAND message to the UE with the new allowed NSSAI; and
  2. for UE not supporting network slice usage control, shall provide the updated allowed NSSAI excluding the S-NSSAI in the CONFIGURATION UPDATE COMMAND message to the UE.
If the AMF locally removes either the replaced S-NSSAI or the alternative S-NSSAI in the allowed NSSAI upon expiry of the associated slice deregistration inactivity timer, the AMF shall delete the entry including the replaced S-NSSAI or the alternative S-NSSAI stored in the alternative NSSAI.
The UE includes the on-demand S-NSSAI which the UE requests in the requested NSSAI during the registration procedure. Upon expiry of the slice deregistration inactivity timer, the UE shall locally remove the S-NSSAI from the allowed NSSAI over the corresponding access type. If the locally removed on-demand S-NSSAI is included in the entry of the stored alternative NSSAI, the UE shall delete the entry as specified in subclause 4.6.2.2.
On-demand NSSAI is associated with the configured NSSAI. The on-demand S-NSSAI(s) is deleted by the UE from the stored on-demand NSSAI, when the associated configured S-NSSAI(s) is deleted by the UE from the stored configured NSSAI.
Up

4.6.2.10  Mobility management aspects of handling network slices with NS-AoS not matching deployed tracking areas |R18|  p. 118

An operator can choose to let the NS-AoS of an S-NSSAI not match the existing tracking area boundaries (see subclause 5.15.18 of TS 23.501). In order to support this deployment option, the operator has to ensure that an AMF covering the NS-AoS operates as described below.
The support for S-NSSAI location validity information by the UE and the network, respectively, is optional. If a UE supports S-NSSAI location validity information, the UE indicates that it supports S-NSSAI location validity information during the registration procedure (see subclause 5.5.1). The AMF can provide a UE which has indicated that it supports S-NSSAI location validity information with S-NSSAI location validity information (see subclauses 5.4.4 and 5.5.1). The S-NSSAI location validity information consists of, for each of the applicable S-NSSAI(s) in the configured NSSAI:
  1. an S-NSSAI; and
  2. a list of cell identities of TA(s) belonging to the registration area where the related S-NSSAI(s) is available in some cells but not all cells of one or more TAs, which represents the NS-AoS of the S-NSSAI.
The UE shall consider itself to be inside the NS-AoS if the cell identity of the current serving cell matches any of the identities in the S-NSSAI location validity information. Otherwise, the UE shall consider itself to be outside the NS-AoS of an S-NSSAI.
For an S-NSSAI in the S-NSSAI location validity information, even if the S-NSSAI is included in the rejected NSSAI with a rejection cause value set to "S-NSSAI not available in the current registration area" or is included in the partially rejected NSSAI, the UE is allowed to request the S-NSSAI if the UE determines that it is inside the NS-AoS of the S-NSSAI.
For an S-NSSAI limited by NS-AoS, if the UE in 5GMM-CONNECTED mode does not support S-NSSAI location validity information and the AMF determines that:
  1. the UE is outside the NS-AoS, then the AMF may:
    1. provide the UE with an allowed NSSAI or a partially allowed NSSAI excluding the S-NSSAI, and optionally a configured NSSAI excluding the S-NSSAI; and
    2. indicate to the SMF to release all PDU sessions associated with the S-NSSAI; or
  2. the UE is in the NS-AoS, then the AMF may update the configured NSSAI to include the S-NSSAI in the configured NSSAI.
If the UE that does not support S-NSSAI location validity information requests a PDU session establishment for an S-NSSAI limited by NS-AoS and the AMF determines that the UE is outside the NS-AoS of an S-NSSAI, the AMF may perform S-NSSAI based congestion control for the S-NSSAI as specified in subclauses 5.3.11 and 5.4.5.
The S-NSSAI location validity information is only applicable to 3GPP access.
Up

4.6.2.11  Mobility management for partial network slice |R18|  p. 119

A serving PLMN or SNPN can indicate the S-NSSAI(s) is allowed or rejected in some TA(s) but not all TAs of the registration area to the UE during the registration procedure as specified in subclause 5.5.1 and the generic UE configuration update procedure as specified in subclause 5.4.4. The support for the partial network slice by a UE or an AMF is optional.
If the UE supports the partial network slice and includes the S-NSSAI(s) in the requested NSSAI and:
  1. if the S-NSSAI(s) is allowed in the current TA but not all TAs of the registration area, and
    1. if the S-NSSAI(s) is subject to NSAC for the maximum number of UEs, the AMF should include the S-NSSAI(s) in the allowed NSSAI to the UE and limit the registration area so that the S-NSSAI(s) is allowed in all the TAs of the registration area;
    2. if the S-NSSAI(s) is subject to NSSAA, the AMF shall include the S-NSSAI(s) in:
      1. the pending NSSAI to the UE when the AMF is going to perform the network slice-specific authentication and authorization for the S-NSSAI(s); or
      2. the partially allowed NSSAI to the UE after the network slice-specific authentication and authorization for the S-NSSAI(s) has been successfully performed; and
    3. otherwise, the AMF shall include the S-NSSAI(s) in the partially allowed NSSAI to the UE; or
  2. if the S-NSSAI(s) is rejected in the current TA but not all TAs of the registration area; and
    1. if the S-NSSAI is subject to NSAC for the maximum number of UEs, the AMF should include the S-NSSAI(s) in the partially rejected NSSAI to the UE;
    2. if the S-NSSAI(s) is subject to NSSAA, the AMF shall include the S-NSSAI(s) in:
      1. the partially rejected NSSAI to the UE when the AMF determines not to perform the network slice-specific authentication and authorization for the S-NSSAI(s);
      2. the pending NSSAI to the UE when the AMF is going to perform the network slice-specific authentication and authorization for the S-NSSAI(s); or
      3. either the partially allowed NSSAI or the partially rejected NSSAI to the UE after the network slice-specific authentication and authorization for the S-NSSAI(s) has been successfully performed;
    3. if the S-NSSAI(s) is associated with a slice deregistration inactivity timer on the AMF side as specified in subclause 4.6.2.9, the AMF shall include the S-NSSAI(s) in the partially rejected NSSAI to the UE; and
    4. otherwise, the AMF shall include the S-NSSAI(s) in either the partially allowed NSSAI or the partially rejected NSSAI to the UE; or
  3. if the partially allowed NSSAI, the partially rejected NSSAI, or both are changed, the AMF shall provide the new partially allowed NSSAI, the new partially rejected NSSAI, or both to the UE.
    Upon receiving the partially allowed NSSAI, the UE shall regard the S-NSSAI(s) included in partially allowed NSSAI, if any, as the allowed S-NSSAI(s) for the current registration area and store the received partially allowed NSSAI as specified in subclause 4.6.2.2.
    Upon receiving the partially rejected NSSAI, the UE shall store the received partially rejected NSSAI as specified in subclause 4.6.2.2. The UE shall not attempt to include the S-NSSAI, if any, in the requested NSSAI if the current TAI is in the list of TAs for which S-NSSAI is rejected.
The AMF shall ensure that there is also at least one S-NSSAI in the allowed NSSAI allocated to the UE as specified in subclause 5.15.2.1 of TS 23.501.
The mobility management for partial network slice is only applicable to 3GPP access.
The mobility management for partial network slice is not applicable to a UE that is registering or registered for onboarding services in SNPN.
Up

4.6.3  Session management aspects  p. 120

4.6.3.0  General |R17|  p. 120

In order to enable PDU transmission in a network slice, the UE may request establishment of a PDU session in a network slice towards a data network (DN) which is associated with an S-NSSAI and a data network name (DNN) if there is no established PDU session adequate for the PDU transmission. The S-NSSAI included is part of allowed NSSAI of the serving PLMN or SNPN, which is an S-NSSAI value valid in the serving PLMN or SNPN, and in roaming scenarios the mapped S-NSSAI is also included for the PDU session if available. See subclause 6.4.1 for further details. The UE determines whether to establish a new PDU session or use one of the established PDU session(s) based on the URSP rules which include S-NSSAIs, if any (see subclause 6.2.9), or based on UE local configuration, as described in subclause 4.2.2 of TS 24.526.
Up

4.6.3.1  Session management based network slice admission control |R17|  p. 120

A serving PLMN or the HPLMN, or SNPN can perform network slice admission control for the S-NSSAI(s) subject to NSAC to monitor and control the total number of established PDU sessions per network slice. The SMF performs network slice admission control on the S-NSSAI during the PDU session establishment procedure. If the maximum number of PDU sessions on a network slice associated with an S-NSSAI has been already reached, the SMF rejects the PDU session establishment request using S-NSSAI based congestion control as specifed in subclause 6.2.8 and 6.4.1.4.2.
The SMF performs network slice admission control on the S-NSSAI for a PDU session that is associated with the non-3GPP access, when the UE requests to transfer a session from the non-3GPP access to the 3GPP access with the Allowed PDU session status IE as described in subclause 5.6.1.4. If the maximum number of PDU sessions on a network slice associated with an S-NSSAI has been already reached, the SMF rejects the request to establish the user-plane resources (see TS 29.502).
Based on operator policy, the session management based network slice admission control is not applicable for the PDU session for emergency services, or the session management based network slice admission control result is ignored for the PDU session for emergency services.
Based on operator policy, the session management based network slice admission control is not applicable for the PDU session for priority services, or the session management based network slice admission control result is ignored for the PDU session for priority services.
The session management based network slice admission control is not applicable to PDU session established for onboarding services in SNPN.
Up

4.6.3.2  Support of network slice admission control and interworking with EPC |R17|  p. 121

If EPS counting is required for a network slice, the network performs network slice admission control for the S-NSSAI(s) subject to NSAC to monitor and control the number of UEs per network slice and number of PDU sessions per network slice during the PDN connection establishment procedure. If the maximum number of UEs on a network slice associated with an S-NSSAI or the maximum number of PDU sessions on a network slice associated with an S-NSSAI have already been reached, the network rejects the PDN connectivity request using ESM cause #26 "insufficient resources" as specifed in TS 24.301.
Up

4.6.3.3  Session management based network slice data rate limitation control |R17|  p. 121

A serving PLMN or the HPLMN can perform network slice data rate limitation control for the S-NSSAI(s) subject to network slice data rate limitation control to monitor and control the total data rate of established PDU sessions per network slice as specified in TS 23.503. If the maximum data rate of PDU sessions on a network slice associated with an S-NSSAI has been exceeded during the PDU session establishment procedure, the SMF may reject the PDU session establishment request using S-NSSAI based congestion control as specified in subclause 6.2.8 and 6.4.1.4.2.
A serving PLMN or the HPLMN can perform management of Slice-Maximum Bit Rate per UE (UE-Slice-MBR) as specified in TS 23.503. When the UE-Slice-MBR for the UE and S-NSSAI to which the PDU session is allocated is exceeded during the PDU session establishment procedure, the SMF may reject the PDU session establishment request using S-NSSAI based congestion control as specified in subclause 6.2.8 and 6.4.1.4.2.
Up

4.6.3.4  Session management based network slice replacement |R18|  p. 121

If:
  1. the UE and network support network slice replacement;
  2. the UE is provided with the mapping information between the S-NSSAI to be replaced and the alternative S-NSSAI; and
  3. the UE decides to establish a new PDU session with the S-NSSAI to be replaced,
the UE provides both the S-NSSAI to be replaced and the alternative S-NSSAI during PDU session establishment procedure. If the timer T3584 or timer T3585 is running for the S-NSSAI to be replaced, the UE should not stop the timer during PDU session establishment procedure. If the SMF receives both the S-NSSAI to be replaced and the alternative S-NSSAI during PDU session establishment procedure, the SMF proceeds with the PDU session establishment procedure with the alternative S-NSSAI. If the PDU session establishment request is accepted, the SMF includes the alternative S-NSSAI in the PDU SESSION ESTABLISHMENT ACCEPT message. The S-NSSAI for the established PDU session is the S-NSSAI to be replaced and the alternative S-NSSAI on the UE side.
If the UE is provided with the mapping of the VPLMN S-NSSAI to a VPLMN alternative S-NSSAI, the UE provides both the VPLMN alternative S-NSSAI and the VPLMN S-NSSAI during PDU session establishment procedure. The AMF sends both VPLMN alternative S-NSSAI and VPLMN S-NSSAI to the SMF. If the UE is provided with the mapping of the HPLMN S-NSSAI to an HPLMN Alternative S-NSSAI, the UE provides both the HPLMN alternative S-NSSAI and the HPLMN S-NSSAI during PDU session establishment procedure. The AMF sends both HPLMN alternative S-NSSAI and HPLMN S-NSSAI to the SMF.
If the SMF receives from the AMF an alternative S-NSSAI for the existing PDU session and:
  1. if the SMF decides to retain the existing PDU session (i.e. the SMF can serve both the alternative S-NSSAI and the S-NSSAI to be replaced), the SMF sends the alternative S-NSSAI to the UE during network-requested PDU session modification procedure; or
  2. if the SMF decides to re-activate the existing PDU session and:
    1. if the SSC mode of the PDU session is SSC mode 3, the SMF initiates PDU session modification procedure to trigger PDU session reactivation by the UE; or
    2. if the SSC mode of the PDU session is SSC mode 1 or SSC mode 2, the SMF initiates PDU session release procedure to trigger PDU session reactivation by the UE, and the UE provides both the S-NSSAI to be replaced and the alternative S-NSSAI during PDU session establishment procedure.
When the replaced S-NSSAI becomes available again, if the SMF receives from the AMF the replaced S-NSSAI for the existing PDU session and:
  1. if the SMF decides to retain the existing PDU session (i.e. the SMF can serve the replaced S-NSSAI), the SMF sends the replaced S-NSSAI to the UE during network-requested PDU session modification procedure; or
  2. if the SMF decides to re-activate the existing PDU session and:
    1. if the SSC mode of PDU session is SSC mode 3, the SMF sends the replaced S-NSSAI to the UE during PDU session modification procedure to trigger PDU session reactivation by the UE; or
    2. if the SSC mode of the PDU session is SSC mode 1 or SSC mode 2, the SMF sends the replaced S-NSSAI to the UE during PDU session release procedure to trigger PDU session reactivation by the UE; and the UE provides the replaced S-NSSAI during PDU establishment procedure.
If the timer T3584 or timer T3585 is running for the replaced S-NSSAI and the replaced S-NSSAI in alternative NSSAI is available and the AMF provides the updated allowed NSSAI and configured NSSAI to the UE, the UE should stop the timer.
Up

4.6.3.5  Session management for optimized handling of temporarily available network slices |R18|  p. 122

A network slice can be available temporarily. Subclause 4.6.2.8 addresses how the allowed NSSAI and partially allowed NSSAI are managed based on the S-NSSAI time validity information.
If the S-NSSAI time validity information indicates that the S-NSSAI is available, the UE may initiate a UE-requested PDU session establishment procedure to establish a PDU session associated with the S-NSSAI.
If the S-NSSAI time validity information indicates that the S-NSSAI is not available, then the UE shall:
  1. initiate UE-requested PDU session release procedure to release any PDU session associated with the S-NSSAI, if the UE is in 5GMM-CONNECTED mode or in 5GMM-CONNECTED mode with RRC inactive indication; or
  2. locally release any PDU session associated with the S-NSSAI, if the UE is in 5GMM-IDLE mode.
When the S-NSSAI time validity information in the AMF indicates that the S-NSSAI is not available, independent of whether the UE is in 5GMM-CONNECTED mode, 5GMM-CONNECTED mode with RRC inactive indication or in 5GMM-IDLE mode, the AMF shall request the SMF to release any PDU session associated with the S-NSSAI.
Up

4.6.3.6  Session management for partial network slice |R18|  p. 122

If the S-NSSAI is included in the partially allowed NSSAI and:
  1. if the current TAI is in the list of TAs for which the S-NSSAI is allowed, the UE may initiate the UE-requested PDU session establishment procedure for the S-NSSAI; or
  2. if the current TAI is not in the list of TAs for which the S-NSSAI is allowed, the UE shall not initiate the UE-requested PDU session establishment procedure for the S-NSSAI.
If an existing PDU session is established for the S-NSSAI included in the partially allowed NSSAI and the current TAI is in the list of TAs for which this S-NSSAI is allowed:
  1. the UE:
    1. may initiate the service request procedure to re-establish the user plane resources for the established PDU session; or
    2. may initiate for the established PDU session either the UE-initiated NAS transport procedure to send CIoT user data to the SMF (see subclause 5.4.5.2.1 case h) or the service request procedure to send CIoT user data to the SMF (see subclause 5.6.1.1 case d); and
  2. the SMF may initiate the network-initiated NAS transport procedure to send CIoT user data to the UE for the established PDU session (see subclause 5.4.5.3.1 case l).
If an existing PDU session is established for the S-NSSAI included in the partially allowed NSSAI and the current TAI is not in the list of TAs for which this S-NSSAI is allowed:
  1. the UE:
    1. shall maintain the 5GSM contexts for the established PDU session;
    2. shall not initiate for the established PDU session, the UE-initiated NAS transport procedure to send CIoT user data to the SMF (see subclause 5.4.5.2.1 case h) nor the service request procedure to send CIoT user data to the SMF (see subclause 5.6.1.1 case d);
    3. shall not attempt to request the establishment of user plane resources for the established PDU session associated with this S-NSSAI; and
    4. shall not initiate any UE-requested 5GSM procedure for the established PDU session except:
      1. the UE-requested PDU session release procedure; or
      2. the UE-requested PDU session modification procedure to set the 3GPP PS data off status to "deactivated" as specified in TS 24.008; and
  2. the SMF:
    1. shall maintain the 5GSM contexts for the established PDU session;
    2. shall not initiate the network-initiated NAS transport procedure to send CIoT user data to the UE for the established PDU session (see subclause 5.4.5.3.1 case l); and
    3. may initiate the network-requested PDU session release procedure for the established PDU session.
If the SMF cannot determine that the UE is located in a TA within the list of TAs associated with the S-NSSAI of an existing PDU session established for this S-NSSAI, the SMF may according to operator's policy:
  1. attempt to establish the user plane resources for the PDU session; or
  2. initiate the network-initiated NAS transport procedure to send CIoT user data to the UE (see subclause 5.4.5.3.1 case l).
Up

4.6.3.7  Session management aspect of handling network slices with NS-AoS not matching deployed tracking areas |R18|  p. 124

If a UE is outside the NS-AoS of an S-NSSAI for which a PDU session is established (see subclause 4.6.2.10), the UE shall not:
  1. attempt to request the establishment of user plane resources of any PDU session associated with this S-NSSAI; and
  2. initiate the UE-initiated NAS transport procedure to send CIoT user data to the SMF (see subclause 5.4.5.2.1 case h) nor the service request procedure to send CIoT user data to the SMF (see subclause 5.6.1.1 case d) for the established PDU session.
If a UE is outside the NS-AoS of an S-NSSAI for which a PDU session is established (see subclause 4.6.2.10), the SMF shall not:
  1. attempt to establish user plane resources of any PDU session associated with this S-NSSAI; and
  2. initiate the network-initiated NAS transport procedure to send CIoT user data to the UE (see subclause 5.4.5.3.1 case l).
If a UE is outside the NS-AoS of an S-NSSAI for which a PDU session is established (see subclause 4.6.2.10), the UE shall not initiate for this PDU session any UE-requested 5GSM procedure except:
  1. the UE-requested PDU session release procedure; or
  2. the UE-requested PDU session modification procedure to set the 3GPP PS data off status to "deactivated" as specified in TS 24.008.
If a UE is outside the NS-AoS of an S-NSSAI (see subclause 4.6.2.10), the UE shall not initiate the UE-requested PDU session establishment procedure for this S-NSSAI.
If the SMF cannot determine that the UE is located inside the NS-AoS of the S-NSSAI of an existing PDU session established for this S-NSSAI, the SMF may according to operator's policy:
  1. attempt to establish the user plane resources for this PDU session; or
  2. initiate the network-initiated NAS transport procedure to send CIoT user data to the UE for this PDU session (see subclause 5.4.5.3.1 case l).
Up

Up   Top   ToC