4.6 Network slicing

24.5013GPPNon-Access-Stratum (NAS) protocol for 5G System (5GS)Release 17Stage 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) if available. 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. 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.

In case of an SNPN, the SNPN may configure a UE with a configured NSSAI applicable to the SNPN 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 S-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. 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.

NOTE 1: 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 2: 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 3: At least one S-NSSAI in the default configured NSSAI or in the subscribed S-NSSAIs marked as 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 4: 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 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) c) the UE has neither allowed NSSAI for the current PLMN 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.

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, if available. The AMF verifies if the requested NSSAI is permitted based on the subscribed S-NSSAIs in the UE subscription and optionally 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 if available. 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 SNPN. In case all the S-NSSAIs included in the requested NSSAI are either rejected for the current PLMN or rejected for the current registration area or rejected for the failed or revoked NSSAA or rejected for the maximum number of UEs reached, or the requested NSSAI was not included by the UE, there is no subscribed S-NSSAI(s) marked as default and the UE is neither registering nor registered for onboarding services in SNPN, the AMF may reject the registration request (see subclauses 5.5.1.2.5 and 5.5.1.3.5 for further details).

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 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 "mobility registration updating" except if the allowed NSSAI has changed for the UE. The UE considers the last received allowed NSSAI as valid until the UE receives a new allowed NSSAI. 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.

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. The support for NSSRG 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 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 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;

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 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 or SNPN (if the UE is roaming); 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);

If the UE 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;

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.

b) The allowed NSSAI shall be stored until:

1) a new allowed NSSAI 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 or SNPN and its equivalent PLMN(s) 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 or SNPN and its equivalent PLMN(s) 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;

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 or SNPN (if the UE is not roaming) or the mapped S-NSSAI(s) for the new allowed NSSAI for the current PLMN or SNPN (if the UE is roaming);

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 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 or SNPN (if the UE is roaming); and

6) remove from the stored pending NSSAI for this PLMN or SNPN and its equivalent PLMN(s), one or more S-NSSAIs, if any, included in the new allowed NSSAI for the current PLMN or SNPN and its equivalent PLMN(s) (if the UE is not roaming) or the mapped S-NSSAI(s) for the new allowed NSSAI for the current PLMN or SNPN and its equivalent PLMN(s) (if the UE is roaming).

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 allowed NSSAI for this PLMN or SNPN, and delete any stored mapped S-NSSAI(s) for the allowed NSSAI, if available;

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, remove from the stored allowed NSSAI for the current PLMN or SNPN and its equivalent PLMN(s), 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, remove from the stored allowed NSSAI for the current PLMN or SNPN and its equivalent PLMN(s), the S-NSSAI(s), if any, included in the:

i) rejected NSSAI for the current PLMN or SNPN, for each and every access type; or

ii) rejected NSSAI for the current registration area, associated with the same access type; and

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 or SNPN and its equivalent PLMN(s) (if the UE is not roaming) or the stored mapped S-NSSAI(s) for the allowed NSSAI (if available and if the UE is roaming), 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, for each and every access type; or

iii) mapped S-NSSAI(s) for the rejected NSSAI for the current registration area, associated with the same access type; and

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, remove from the stored pending NSSAI for the current PLMN or SNPN and its equivalent PLMN(s), 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, remove from the stored pending NSSAI for the current PLMN or SNPN and its equivalent PLMN(s), the S-NSSAI(s), if any, included in the:

i) rejected NSSAI for the current PLMN or SNPN, for each and every access type; or

ii) rejected NSSAI for the current registration area, 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 the 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) or SNPN (if the UE is not roaming) or the stored mapped S-NSSAI(s) for the pending NSSAI, the S-NSSAI(s) (if available and if the UE is roaming) 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, for each and every access type; or

iii) mapped S-NSSAI(s) for the rejected NSSAI for the current registration area, associated with the same access type.

8) 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;

2) successfully registers with a new PLMN;

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 over another access, the rejected NSSAI for the current PLMN and the rejected NSSAI for the failed or revoked NSSAA shall be deleted.

When the UE receive 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 from the rejected NSSAI for the current PLMN. When the UE receive 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 or SNPN and its equivalent PLMN(s).

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 using explicit signalling or enters state 5GMM-DEREGISTERED for the current PLMN;

2) successfully registers with a new PLMN;

3) enters state 5GMM-DEREGISTERED following an unsuccessful registration with a new PLMN; 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 over another access, the pending NSSAI for the current PLMN and its equivalent PLMN(s) 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. 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.

NOTE: The value(s) used in the default configured NSSAI are expected to be commonly decided by all roaming partners, e.g. by the use of values standardized by 3GPP or other bodies.

The 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:
i) including the 5GS registration type IE set to "initial registration"

Requested NSSAI, if any

Requested NSSAI, if any

Requested NSSAI, if any

No NSSAI

REGISTRATION REQUEST message:
i) including the 5GS registration type IE set to "mobility registration updating"; and
ii) initiated by case other than case g) or n) in subclause 5.5.1.3.2

Requested NSSAI, if any

Requested NSSAI, if any

Requested NSSAI, if any

No NSSAI

REGISTRATION REQUEST message:
i) including the 5GS registration type IE set to "mobility registration updating"; and
ii) initiated by case g) or n) in subclause 5.5.1.3.2

Allowed NSSAI, if any

Allowed NSSAI, if any

No NSSAI, if any

No NSSAI

REGISTRATION REQUEST message:
i) including the 5GS registration type IE set to "periodic registration updating"

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 includes the service type IE set to "emergency services" or "emergency services fallback", no NSSAI is provided to the lower layers.

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) decided by the UE, if the AMF did not include the NSSAI inclusion mode IE in the REGISTRATION ACCEPT message;

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) or the current SNPN, if any, 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 shall perform network slice-specific authentication and authorization for the S-NSSAI(s) of the HPLMN 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].

NOTE 3: Upon completion of NSSAA procdures, 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 authentication and 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 authentication and 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 authentication and authorization fails or network slice-specific authorization is revoked for all S-NSSAIs in the allowed NSSAI but there are one or more subscribed S-NSSAIs marked as default 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 subscribed S-NSSAIs marked as default 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 authentication and authorization fails or network slice-specific authorization is revoked for all S-NSSAIs in the allowed NSSAI and all subscribed S-NSSAIs marked as default are subject to network slice-specific authentication and authorization, 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 authentication and 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.

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, which can be either activated or deactivated for the network performing network slice admission control.

If the EAC mode is activated, 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 subscribed S-NSSAIs marked as default which can be allowed to the UE, then the AMF includes the allowed NSSAI containing these subscribed S-NSSAIs marked as default 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 subscribed S-NSSAIs marked as default 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, 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 NSCAF 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 subscribed S-NSSAIs marked as default which can be allowed to the UE, then the AMF updates the allowed NSSAI containing these subscribed S-NSSAIs marked as default 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 subscribed S-NSSAIs marked as default 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.

Editor’s note [WI: eNS-Ph2, CR#3417]: Whether NSAC is applicable in an SNPN is FFS.

Based on operator policy, the mobility management based network slice admission control is not applicable for the S-NSSAI included in the AMF emergency configuration data.

4.6.3 Session management aspects

4.6.3.1 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 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.

Based on operator policy, the session management based network slice admission control is not applicable for the S-NSSAI included in the SMF emergency configuration data.

NOTE: 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.

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.