4.6 Network slicing
24.5013GPPNon-Access-Stratum (NAS) protocol for 5G System (5GS)Release 18Stage 3TS
4.6.1 General
The 5GS supports network slicing as described in 3GPP TS 23.501 [8]. 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 NSSAIs are defined in 3GPP TS 23.501 [8]:
a) configured NSSAI;
b) requested NSSAI;
c) allowed NSSAI;
d) subscribed S-NSSAIs; and
e) pending NSSAI.
The following NSSAIs are defined in the present document:
a) rejected NSSAI for the current PLMN or SNPN;
b) rejected NSSAI for the current registration area;
c) rejected NSSAI for the failed or revoked NSSAA; and
d) rejected NSSAI for the maximum number of UEs reached.
In roaming scenarios, rejected NSSAI for the current PLMN or SNPN, or rejected NSSAI for the current registration area, or rejected NSSAI for the maximum number of UEs reached includes one or more S-NSSAI 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 the configured NSSAI per PLMN, and NSSRG information if the UE has indicated it support the subscription-based restrictions to simultaneous registration of network slices feature. 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.
NOTE 1: The value(s) used in the default configured NSSAI are expected to be commonly decided by all roaming partners, e.g., values standardized by 3GPP or other bodies.
In case of an SNPN, the SNPN may configure a UE with a configured NSSAI applicable to the SNPN, and NSSRG information if the UE has indicated it support the subscription-based restrictions to simultaneous registration of network slices feature, if the UE is neither registering nor registered for onboarding services in SNPN. 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 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 and the rejected NSSAI for the current registration area 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 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. 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.
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.
NOTE 2: Based on local policies, the UE can remove an S-NSSAI from the rejected NSSAI for the failed or revoked NSSAA when the UE wants to register to the slice identified by this S-NSSAI.
NOTE 3: Based on network local policy, network slice-specific authentication and authorization procedure can be initiated by the AMF for an S-NSSAI in rejected NSSAI for the failed or revoked NSSAA when the S-NSSAI is requested by the UE based on its local policy.
NOTE 4: At least one S-NSSAI in the default configured NSSAI or at least one default S-NSSAI is recommended as not subject to network slice-specific authentication and authorization, in order to ensure that at least one PDU session can be established to access service, even when Network Slice-specific Authentication and Authorization fails.
NOTE 5: At least one S-NSSAI in the default configured NSSAI or at least one default S-NSSAI is recommended as not subject to network slice admission control, in order to ensure that at least one PDU session can be established to access service.
NOTE 6: The rejected NSSAI can be provided by the network via either Rejected NSSAI IE or the Extended rejected NSSAI IE.
4.6.2 Mobility management aspects
4.6.2.1 General
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:
a) the UE has a configured NSSAI for the current PLMN or SNPN;
b) the UE has an allowed NSSAI for the current PLMN or SNPN; or
c) 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.
NOTE 1: The above occurs only when the UE is roaming and the AMF compliant with earlier versions of the specification omits providing to the UE a mapped S-NSSAI for one or more S-NSSAIs in, e.g., the allowed NSSAI or configured 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. 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
a) all the S-NSSAIs included in the requested NSSAI are rejected, or the requested NSSAI was not included by the UE;
b) all default S-NSSAIs are not allowed; and
c) 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.
NOTE 2: When the UE compliant with earlier versions of the specification is roaming, the UE can omit a mapped S-NSSAI for one or more S-NSSAIs in requested 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.
4.6.2.2 NSSAI storage
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 associated NSSRG information, the NSSRG information shall also be stored in a non-volatile memory in the ME as specified in annex C. For a configured NSSAI, if there is associated NSAG information, the NSAG information shall be stored in the ME. The support for NSSRG information and NSAG information by a UE or an AMF is optional.
The allowed NSSAI(s) should 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 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, the selected entry of the "list of subscriber data" or the selected PLMN subscription. Each of the configured NSSAI, except the default configured NSSAI, and 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, the selected entry of the "list of subscriber data" or the selected PLMN subscription. 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, 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 current PLMN or SNPN shall be considered rejected for the current PLMN or SNPN regardless of the access type. The S-NSSAI(s) in the rejected NSSAI for the failed or revoked NSSAA shall be considered rejected for the current PLMN or SNPN regardless of the access type. 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. 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 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 stop any timer T3526 associated with a deleted S-NSSAI in the rejected NSSAI for the maximum number of UEs reached if running;
4A) remove from the stored mapped S-NSSAI(s) for the rejected NSSAI for the current PLMN or SNPN and the stored mapped S-NSSAI(s) for the rejected NSSAI for the current registration area and the stored 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 configured 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 the deleted S-NSSAI in the rejected NSSAI for the maximum number of UEs reached if running; 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 3GPP TS 24.301 [15] or via ePDG as specified in 3GPP TS 24.302 [16], 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.
NOTE 1: The maximum number of configured NSSAIs and associated mapped S-NSSAIs for PLMNs other than the HPLMN that need to be stored in the UE, and how to handle the stored entries, are up to UE implementation.
ab) 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) 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); 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 allowed NSSAI as described in subclause 5.5.1.2.4 and subclause 5.5.1.3.4.
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) 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) 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 and rejected NSSAI for the maximum number of UEs reached, 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 is associated with one or more S-NSSAI(s) in the stored mapped rejected NSSAI and these mapped S-NSSAI(s) are 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 and 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) or this SNPN, one or more S-NSSAIs, if any, included in the new allowed NSSAI for the current PLMN and its 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 its equivalent PLMN(s) (if the UE is roaming) or the current SNPN (if the SNPN is a non-subscribed SNPN).
NOTE 2: Whether the UE stores the allowed NSSAI and the mapped S-NSSAI(s) for the allowed NSSAI also when the UE is switched off is implementation specific.
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, 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 in non-roaming case when not in SNPN access operation mode or in the subscribed SNPN, remove from the stored allowed NSSAI for the current PLMN and its equivalent PLMN(s) or the current SNPN, the S-NSSAI(s), if any, included in the:
i) rejected NSSAI for the current PLMN or SNPN, for each and every access type;
ii) rejected NSSAI for the current registration area, associated with the same access type; or
iii) rejected NSSAI for the maximum number of UEs reached, associated with the same access type;
3) 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 allowed NSSAI for the current PLMN and its equivalent PLMN(s) or the current SNPN, the S-NSSAI(s), if any, included in the:
i) rejected NSSAI for the current PLMN or SNPN, for each and every access type;
ii) rejected NSSAI for the current registration area, associated with the same access type; or
iii) 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 allowed NSSAI for the current PLMN or SNPN are stored in the UE, and the all of the mapped S-NSSAI are included in the Extended rejected NSSAI IE;
4) remove from the stored allowed NSSAI for the current PLMN and its equivalent PLMN(s) (if the UE is not roaming) or the current SNPN (if the SNPN is the subscribed SNPN) or the stored mapped S-NSSAI(s) for the 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:
i) rejected NSSAI for the failed or revoked NSSAA, for each and every access type;
ii) mapped S-NSSAI(s) for the rejected NSSAI for the current PLMN or SNPN, for each and every access type;
iii) mapped S-NSSAI(s) for the rejected NSSAI for the current registration area, associated with the same access type; or
iv) mapped S-NSSAI(s) for the rejected NSSAI for the maximum number of UEs reached, associated with the same access type;
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) or the current SNPN, the S-NSSAI(s), if any, included in the:
i) rejected NSSAI for the current PLMN or SNPN, for each and every access type;
ii) rejected NSSAI for the current registration area, associated with the same access type; or
iii) 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) or the current SNPN, the S-NSSAI(s), if any, included in the:
i) rejected NSSAI for the current PLMN or SNPN, for each and every access type;
ii) rejected NSSAI for the current registration area, associated with the same access type; or
iii) 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 pending NSSAI for the current PLMN and its equivalent PLMN(s) (if the UE is not roaming) or the current SNPN (if the SNPN is the subscribed SNPN) or 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) included in the:
i) rejected NSSAI for the failed or revoked NSSAA, for each and every access type;
ii) mapped S-NSSAI(s) for the rejected NSSAI for the current PLMN or SNPN, for each and every access type;
iii) mapped S-NSSAI(s) for the rejected NSSAI for the current registration area, associated with the same access type; or
iv) 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.
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 SNPN;
3) enters state 5GMM-DEREGISTERED following an unsuccessful registration with a new PLMN; 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 current PLMN or SNPN 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.2.2 of 3GPP TS 24.301 [15]), 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.2.2 of 3GPP TS 24.301 [15]), 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 shall be deleted;
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) 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 the 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 current PLMN or SNPN over another access, the pending NSSAI for the current PLMN and its equivalent PLMN(s) 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); and
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.
4.6.2.3 Provision of NSSAI to lower layers in 5GMM-IDLE mode
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.
Table 4.6.2.3.1: NSSAI inclusion modes and NSSAI which shall be provided to the lower layers
|
Initial NAS message |
NSSAI inclusion mode A |
NSSAI inclusion mode B |
NSSAI inclusion mode C |
NSSAI inclusion mode D |
|
REGISTRATION REQUEST message: |
Requested NSSAI, if any |
Requested NSSAI, if any |
Requested NSSAI, if any |
No NSSAI |
|
REGISTRATION REQUEST message: |
Requested NSSAI, if any |
Requested NSSAI, if any |
Requested NSSAI, if any |
No NSSAI |
|
REGISTRATION REQUEST message: |
Allowed NSSAI, if any |
Allowed NSSAI, if any |
No NSSAI |
No NSSAI |
|
REGISTRATION REQUEST message: |
Allowed NSSAI, if any |
Allowed NSSAI, if any |
No NSSAI |
No NSSAI |
|
SERVICE REQUEST message |
Allowed NSSAI, if any |
See NOTE 1 |
No NSSAI |
No 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 3GPP TS 23.501 [8]) 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:
a) indicated by the AMF, if the AMF included the NSSAI inclusion mode IE in the REGISTRATION ACCEPT message; or
b) 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, then mode C;
2) otherwise:
i) mode D for 3GPP access and trusted non-3GPP access; or
ii) 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:
a) no NSSAI if the UE is performing the registration procedure over 3GPP access; or
b) 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.
4.6.2.4 Network slice-specific authentication and authorization
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.
NOTE 1: The credentials for network slice-specific authentication and authorization and how to provision them in the upper layer are out of the scope of 3GPP.
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. 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, 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.
NOTE 2: The AMF maintains the NSSAA procedure status for each S-NSSAI, as specified in 3GPP TS 29.518 [20B] and the NSSAA procedure status for each S-NSSAI is not impacted by NSAC as specified in subclauses 4.6.2.5 and 4.6.3.1.
NOTE 3: Upon completion of NSSAA procedures, it can happen that the total number of S-NSSAIs which need to be included in the allowed NSSAI exceeds eight. In this case, it is up to the AMF implementation on how to pick up the S-NSSAIs included in the allowed NSSAI.
NOTE 4: It can happen that one or more S-NSSAIs included in the received allowed NSSAI, are not the S-NSSAIs that the UE intends to register to. In this case, it is up to the UE implementation on how to use these S-NSSAIs.
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 3GPP TS 23.502 [9] using the EAP framework as described in 3GPP TS 33.501 [24].
The AMF updates the 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 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:
a) 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, the AMF updates the 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;
b) 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 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 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
c) 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 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, if the UE still wants to use the S-NSSAI(s) from the 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, the AMF shall:
a) provide a new allowed NSSAI, excluding the S-NSSAI for which the network slice-specific authorization is revoked; and
b) 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.
NOTE 5: If the AMF receives the HTTP code set to "4xx" or "5xx" as specified in 3GPP TS 29.500 [20AA] or the AMF detects that the NSSAAF failure as specified in 3GPP TS 29.526 [21A] during the NSSAA procedure for an S-NSSAI, then the AMF considers the NSSAA procedure has failed for this S-NSSAI.
Editor’s note: It is FFS how to address the case when the UE is not interested in the S-NSSAI(s) in the pending NSSAI.
4.6.2.5 Mobility management based network slice admission control
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 3GPP TS 23.502 [9])
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 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:
a) one or more S-NSSAIs but not all S-NSSAIs in the requested NSSAI, then the AMF includes the 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;
b) 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 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
c) 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 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. After the network performs the network slice admission control, if the AMF determines that the maximum number of UEs has been reached for:
a) one or more S-NSSAIs but not all S-NSSAIs in the allowed NSSAI, then the AMF updates the allowed NSSAI and the rejected NSSAI accordingly using the generic UE configuration update procedure as specified in the subclause 5.4.4;
b) for all S-NSSAIs in the 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 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
c) for all S-NSSAIs in the 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.
NOTE: A UE configured for priority services can be identified based on the RRC establishment cause received from the NG-RAN or based on the MPS priority information in the user’s subscription context obtained from the UDM.
The mobility management based network slice admission control is not applicable to a UE that is registering or registered for onboarding services in SNPN.
4.6.2.6 Provision of NSAG information to lower layers
The NSAG information provided by the network and stored in the UE includes a list of NSAGs each of which contains:
a) an NSAG ID;
b) a list of S-NSSAI(s), which are associated with the NSAG and shall be part of the configured NSSAI;
c) a priority value that is associated with the NSAG; and
d) 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 which has sent the NSAG information.
The UE NAS layer shall provide the lower layers with.
a) the most recent NSAG information stored in the UE (see subclause 4.6.2.2);
b) the allowed NSSAI or the requested NSSAI for the purpose of network slice-based cell reselection (see 3GPP TS 23.501 [8]); and
c) one 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:
i) S-NSSAI(s) triggering the initial NAS message (requested NSSAI (if any) in case of the REGISTRATION REQUEST message and S-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) in case of the (CONTROL PLANE) SERVICE REQUEST message), if an access attempt occurred due to an initial NAS message;
ii) 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 or an UL NAS TRANSPORT which carries a 5GSM message for a PDU session associated with an S-NSSAI (if any); or
iii) the allowed NSSAI (if any), if an access attempt occurred for other reason than those specified in bullets i) and ii).
Editor’s note: It is FFS how a UE operates in terms of NSAG if the UE has an emergency PDU session or attempts to establish an emergency PDU session.
NOTE: The AMF can take local configuration, UE 5GMM capabilities, subscribed S-NSSAIs, HPLMN, etc. to determine the NSAG priority information for the associated NSAG to a UE.
4.6.3 Session management aspects
4.6.3.0 General
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 3GPP TS 24.526 [19].
4.6.3.1 Session management based network slice admission control
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 3GPP TS 29.502 [20A]).
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.
NOTE: How the SMF determines that the PDU session is used for priority services is outside the scope of this release of the present document.
The session management based network slice admission control is not applicable to PDU session established for onboarding services in SNPN.
NOTE 1: For the MA PDU session during the PDU session establishment procedure, the SMF performs network slice admission control only when it is newly established over the associated access type.
NOTE 2: For a set of redundant PDU sessions, the SMF performs network slice admission control for each PDU session independently.
4.6.3.2 Support of network slice admission control and interworking with EPC
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 3GPP TS 24.301 [15].
NOTE: If there are more than one S-NSSAI associated with the APN used in the PDN connectivity request and some of but not all associated S-NSSAIs are not available due to either maximum number of UEs reached or maximum number of PDU sessions reached, the network can use the associated S-NSSAI for which maximum number of UEs and maximum number of PDU sessions have not reached to avoid PDN connectivity request rejection.
4.6.3.3 Session management based network slice data rate limitation control
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 3GPP TS 23.503 [10]. 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 clause 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 3GPP TS 23.503 [10]. 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 clause 6.2.8 and 6.4.1.4.2.
NOTE 1: Based on operator policy, the network slice data rate limitation control can be not applicable for the S-NSSAI(s) used for emergency services or priority services.
NOTE 2: The network slice data rate limitation control and UE-Slice-MBR management are performed by the PCF.