5.15 Network slicing

23.5013GPPRelease 18System architecture for the 5G System (5GS)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.15.1 General

A Network Slice instance is defined within a PLMN or within an SNPN and shall include:

– the Core Network Control Plane and User Plane Network Functions, as described in clause 4.2,

and, in the serving PLMN, at least one of the following:

– the NG-RAN described in TS 38.300 [27];

– the N3IWF or TNGF functions to the non-3GPP Access Network described in clause 4.2.8.2 or the TWIF functions to the trusted WLAN in the case of support of N5CW devices described in clause 4.2.8.5;

– the W-AGF function to the Wireline Access Network described in clause 4.2.8.4.

The 5G System deployed in a PLMN shall always support the procedures, information and configurations specified to support Network Slice instance selection in the present document, TS 23.502 [3] and TS 23.503 [45].

Network slicing support for roaming is described in clause 5.15.6.

Network slices may differ for supported features and network functions optimisations, in which case such Network Slices may have e.g. different S-NSSAIs with different Slice/Service Types (see clause 5.15.2.1). The operator can deploy multiple Network Slices delivering exactly the same features but for different groups of UEs, e.g. as they deliver a different committed service and/or because they are dedicated to a customer, in which case such Network Slices may have e.g. different S-NSSAIs with the same Slice/Service Type but different Slice Differentiators (see clause 5.15.2.1).

The network may serve a single UE with one or more Network Slice instances simultaneously via a 5G-AN regardless of the access type(s) over which the UE is registered (i.e. 3GPP Access and/or N3GPP Access). The AMF instance serving the UE logically belongs to each of the Network Slice instances serving the UE, i.e. this AMF instance is common to the Network Slice instances serving a UE.

NOTE 1: Number of simultaneous connection of Network Slice instances per UE is limited by the number of S-NSSAIs in the Requested/Allowed NSSAI as described in clause 5.15.2.1.

NOTE 2: In this Release of the specification it is assumed that in any (home or visited) PLMN it is always possible to select an AMF that can serve any combination of S-NSSAIs that will be provided as an Allowed NSSAI.

The selection of the set of Network Slice instances for a UE is triggered by the first contacted AMF in a Registration procedure normally by interacting with the NSSF, and can lead to a change of AMF. This is further described in clause 5.15.5.

A PDU Session belongs to one and only one specific Network Slice instance per PLMN. Different Network Slice instances do not share a PDU Session, though different Network Slice instances may have slice-specific PDU Sessions using the same DNN.

During the Handover procedure the source AMF selects a target AMF by interacting with the NRF as specified in clause 6.3.5.

Network Slice-Specific Authentication and Authorization (NSSAA) enables Network Slice specific authentication as described in clause 5.15.10.

Network Slice Admission Control (NSAC) controls the number of registered UEs per network slice and the number of PDU Sessions per network slice as described in clause 5.15.11.

Support of subscription-based restrictions to simultaneous registration of network slices uses Network Slice Simultaneous Registration Group (NSSRG) information to enable control of which Network Slices that can be registered simultaneously by a UE as described in clause 5.15.12.

Support of data rate limitation per Network Slice for a UE enables enforcement of Maximum Bit Rate per Network Slice for a UE as described in clause 5.15.13.

The selection of N3IWF supporting a set of slice(s) is described in clause 6.3.6.

5.15.2 Identification and selection of a Network Slice: the S-NSSAI and the NSSAI

5.15.2.1 General

An S-NSSAI identifies a Network Slice.

An S-NSSAI is comprised of:

– A Slice/Service type (SST), which refers to the expected Network Slice behaviour in terms of features and services;

– A Slice Differentiator (SD), which is optional information that complements the Slice/Service type(s) to differentiate amongst multiple Network Slices of the same Slice/Service type.

An S-NSSAI can have standard values (i.e. such S-NSSAI is only comprised of an SST with a standardised SST value, see clause 5.15.2.2, and no SD) or non-standard values (i.e. such S-NSSAI is comprised of either both an SST and an SD or only an SST without a standardised SST value and no SD). An S-NSSAI with a non-standard value identifies a single Network Slice within the PLMN with which it is associated. An S-NSSAI with a non-standard value shall not be used by the UE in access stratum procedures in any PLMN other than the one to which the S-NSSAI is associated.

The S-NSSAIs in the NSSP of the URSP rules (see clause 6.6.2 of TS 23.503 [45]) and in the Subscribed S-NSSAIs (see clause 5.15.3) contain only HPLMN S-NSSAI values.

The S-NSSAIs in the Configured NSSAI, the Allowed NSSAI (see clause 5.15.4.1), the Requested NSSAI (see clause 5.15.5.2.1), the Rejected S-NSSAIs contain only values from the Serving PLMN. The Serving PLMN can be the HPLMN or a VPLMN.

The S-NSSAI(s) in the PDU Session Establishment contain one Serving PLMN S-NSSAI value and in addition may contain a corresponding HPLMN S-NSSAI value to which this first value is mapped (see clause 5.15.5.3).

The optional mapping of Serving PLMN S-NSSAIs to HPLMN S-NSSAIs contains Serving PLMN S-NSSAI values and corresponding mapped HPLMN S-NSSAI values.

The NSSAI is a collection of S-NSSAIs. An NSSAI may be a Configured NSSAI, a Requested NSSAI or an Allowed NSSAI. There can be at most eight S-NSSAIs in Allowed and Requested NSSAIs sent in signalling messages between the UE and the Network. The Requested NSSAI signalled by the UE to the network allows the network to select the Serving AMF, Network Slice(s) and Network Slice instance(s) for this UE, as specified in clause 5.15.5.

Based on the operator’s operational or deployment needs, a Network Slice instance can be associated with one or more S-NSSAIs, and an S-NSSAI can be associated with one or more Network Slice instances. Multiple Network Slice instances associated with the same S-NSSAI may be deployed in the same or in different Tracking Areas. When multiple Network Slice instances associated with the same S-NSSAI are deployed in the same Tracking Areas, the AMF instance serving the UE may logically belong to (i.e. be common to) more than one Network Slice instance associated with this S-NSSAI.

In a PLMN, when an S-NSSAI is associated with more than one Network Slice instance, one of these Network Slice instances, as a result of the Network Slice instance selection procedure defined in clause 5.15.5, serves a UE that is allowed to use this S-NSSAI. For any S-NSSAI, the network may at any one time serve the UE with only one Network Slice instance associated with this S-NSSAI until cases occur where e.g. this Network Slice instance is no longer valid in a given Registration Area, or a change in UE’s Allowed NSSAI occurs, etc. In such cases, procedures mentioned in clause 5.15.5.2.2 or clause 5.15.5.2.3 apply.

Based on the Requested NSSAI (if any) and the Subscription Information, the 5GC is responsible for selection of a Network Slice instance(s) to serve a UE including the 5GC Control Plane and User Plane Network Functions corresponding to this Network Slice instance(s). The Subscription Information may contain restrictions to the simultaneous registration of network slices. This is provided to the serving AMF as part of the UE subscription, in the form of Network Slice Simultaneous Registration Group (NSSRG) information (see clause 5.15.12).

The (R)AN may use Requested NSSAI in access stratum signalling to handle the UE Control Plane connection before the 5GC informs the (R)AN of the Allowed NSSAI. The Requested NSSAI is used by the RAN for AMF selection, as described in clause 6.3.5. The UE shall not include the Requested NSSAI in the RRC Resume when the UE asks to resume the RRC connection and is CM-CONNECTED with RRC Inactive state.

When a UE is successfully registered over an Access Type, the CN informs the (R)AN by providing the Allowed NSSAI for the corresponding Access Type.

NOTE: The details of how the RAN uses NSSAI information are described in TS 38.300 [27].

5.15.2.2 Standardised SST values

Standardized SST values provide a way for establishing global interoperability for slicing so that PLMNs can support the roaming use case more efficiently for the most commonly used Slice/Service Types.

The SSTs which are standardised are in the following Table 5.15.2.2-1.

Table 5.15.2.2-1: Standardised SST values

Slice/Service type	SST value	Characteristics
eMBB	1	Slice suitable for the handling of 5G enhanced Mobile Broadband.
URLLC	2	Slice suitable for the handling of ultra- reliable low latency communications.
MIoT	3	Slice suitable for the handling of massive IoT.
V2X	4	Slice suitable for the handling of V2X services.
HMTC	5	Slice suitable for the handling of High-Performance Machine-Type Communications.

NOTE 1: The support of all standardised SST values is not required in a PLMN. Services indicated in this table for each SST value can also be supported by means of other SSTs.

NOTE 2: A mapping of GSMA defined Network Slice Types (NEST) to standard SST values is defined in GSMA NG.116 [137].

5.15.3 Subscription aspects

The Subscription Information shall contain one or more S-NSSAIs i.e. Subscribed S-NSSAIs. The subscription information shall include at least one default S-NSSAI. The UDM sends at the most 16 Subscribed S-NSSAIs to AMF, i.e. the number that can fit in a Configured NSSAI. The subscription information the UDM sends to the AMF shall include at least one default S-NSSAI.

If an S-NSSAI is marked as default, then the network is expected to serve the UE with a related applicable Network Slice instance when the UE does not send any permitted S-NSSAI to the network in a Registration Request message as part of the Requested NSSAI.

The Subscription Information for each S-NSSAI may contain:

– a Subscribed DNN list and one default DNN; and

– the indication whether the S-NSSAI is marked as default Subscribed S-NSSAI; and

– the indication whether the S-NSSAI is subject to Network Slice-Specific Authentication and Authorization; and

– Network Slice Simultaneous Usage Group (NSSRG) information (see clause 5.15.12).

The network verifies the Requested NSSAI the UE provides in the Registration Request against the Subscription Information. For the S-NSSAIs subject to Network Slice-Specific Authentication and Authorization the clause 5.15.10 applies.

NOTE 1: It is recommended that at least one of the Subscribed S-NSSAIs marked as default S-NSSAI is not subject to Network Slice-specific Authentication and Authorization, in order to ensure access to services even when Network Slice-specific Authentication and Authorization fails.

NOTE 2: It is recommended to minimize the number of Subscribed S-NSSAIs in subscriptions for NB-IoT or NR RedCap capable UEs to minimize overhead for signalling a large number of S-NSSAIs in Requested NSSAI in RRC and NAS via NB-IoT or NR RedCap.

In roaming case, the UDM shall provide to the VPLMN only the S-NSSAIs from the Subscribed S-NSSAIs the HPLMN allows for the UE in the VPLMN. If the UE is subject to restrictions of simultaneous registration of network slices (i.e. if the Subscription Information for the S-NSSAIs contains NSSRG information), the UDM provides to the VPLMN a subscribed S-NSSAIs and, if applicable, NSSRG information, as described in clause 5.15.12.

NOTE 3: Network slice instances supporting an S-NSSAI subject to Network Slice-Specific Authentication and Authorization need to be deployed with AMFs supporting Network Slice-Specific Authentication and Authorization, otherwise S-NSSAIs requiring Network Slice-Specific Authentication and Authorization would be incorrectly allowed without execution of Network Slice-Specific Authentication and Authorization.

NOTE 4: Network slice instances supporting an S-NSSAI subject to Network Slice Admission Control (NSAC) need to be deployed with AMFs supporting NSAC, otherwise S-NSSAIs requiring NSAC would be incorrectly allowed without execution of NSAC.

When the UDM updates the Subscribed S-NSSAI(s) to the serving AMF, based on configuration in this AMF, the AMF itself or the NSSF determines the mapping of the Configured NSSAI for the Serving PLMN and/or Allowed NSSAI to the Subscribed S-NSSAI(s). The serving AMF then updates the UE with the above information as described in clause 5.15.4.

5.15.4 UE NSSAI configuration and NSSAI storage aspects

5.15.4.1 General

5.15.4.1.1 UE Network Slice configuration

The Network Slice configuration information contains one or more Configured NSSAI(s). A Configured NSSAI may either be configured by a Serving PLMN and apply to the Serving PLMN, or may be a Default Configured NSSAI configured by the HPLMN and that applies to any PLMNs for which no specific Configured NSSAI has been provided to the UE. There is at most one Configured NSSAI per PLMN.

NOTE 1: 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 Default Configured NSSAI, if it is configured in the UE, is used by the UE in a Serving PLMN only if the UE has no Configured NSSAI for the Serving PLMN.

The Configured NSSAI of a PLMN may include S-NSSAIs that have standard values or PLMN-specific values.

The Configured NSSAI for the Serving PLMN includes the S-NSSAI values which can be used in the Serving PLMN and may be associated with mapping of each S-NSSAI of the Configured NSSAI to one or more corresponding HPLMN S-NSSAI values. In the non-roaming case, the network shall not provide any mapped S-NSSAI to the UE with the Configured NSSAI.

A UE subscription may contain Network Slice Simultaneous Registration Group (NSSRG) information. If so, the UE configuration is performed as described in clause 5.15.12.2.

The UE may be pre-configured with the Default Configured NSSAI. The UE may be provisioned/updated with the Default Configured NSSAI, determined by the UDM in the HPLMN, using the UE Parameters Update via UDM Control Plane procedure defined in clause 4.20 of TS 23.502 [3]. Each S-NSSAI in the Default Configured NSSAI may have a corresponding S-NSSAI as part of the Subscribed S-NSSAI(s). Consequently, if the Subscribed S-NSSAI(s) which are also present in the Default Configured NSSAI are updated the UDM should update the Default Configured NSSAI in the UE.

In the HPLMN, the S-NSSAIs in the Configured NSSAI provided as described in clause 5.15.4.2, at the time when they are provided to the UE, shall match the Subscribed S-NSSAIs for the UE. When the Subscribed S-NSSAI(s) are updated (i.e. some existing S-NSSAIs are removed and/or some new S-NSSAIs are added) and one or more are applicable to the Serving PLMN the UE is registered in, as described in clause 5.15.3, or when the associated mapping is updated the AMF shall update the UE with the Configured NSSAI for the Serving PLMN and/or Allowed NSSAI and/or the associated mapping to HPLMN S-NSSAIs (see clause 5.15.4.2). When there is the need to update the Allowed NSSAI, the AMF shall provide the UE with the new Allowed NSSAI and the associated mapping to HPLMN S-NSSAIs, unless the AMF cannot determine the new Allowed NSSAI (e.g. all S-NSSAIs in the old Allowed NSSAI have been removed from the Subscribed S-NSSAIs), in which case the AMF shall not send any Allowed NSSAI to the UE but indicate to the UE to perform a Registration procedure. If the UE is in a CM-IDLE state, the AMF may trigger Network Triggered Service Request or wait until the UE is in a CM-CONNECTED state as described in clause 4.2.4.2, TS 23.502 [3].

When providing a Requested NSSAI to the network upon registration, the UE in a given PLMN only includes and uses S-NSSAIs applying to this PLMN. The mapping of S-NSSAIs of the Requested NSSAI to HPLMN S-NSSAIs may also be provided (see clause 5.15.4.1.2 for when this is needed). The S-NSSAIs in the Requested NSSAI are part of the Configured and/or Allowed NSSAIs applicable for this PLMN, when they are available. If the UE has received NSSRG information together with the Configured NSSAI, it only includes in the Requested NSSAI S-NSSAIs that all share a common NSSRG. If the UE has stored Pending NSSAI and the UE is still interested in the Pending NSSAI then all the S-NSSAIs in the Requested NSSAI and the Pending S-NSSAI shall share a common NSSRG. If no Configured NSSAI and Allowed NSSAI for the PLMN are available, the S-NSSAIs in the Requested NSSAI correspond to the Default Configured NSSAI, if configured in the UE. Upon successful completion of a UE’s Registration procedure over an Access Type, the UE obtains from the AMF an Allowed NSSAI for this Access Type, which includes one or more S-NSSAIs and, if needed (see clause 5.15.4.1.2 for when this is needed), their mapping to the HPLMN S-NSSAIs. These S-NSSAIs are valid for the current Registration Area and Access Type provided by the AMF the UE has registered with and can be used simultaneously by the UE (up to the maximum number of simultaneous Network Slice instances or PDU Sessions).

The UE might also obtain one or more rejected S-NSSAIs with cause and validity of rejection from the AMF. An S-NSSAI may be rejected:

– for the entire PLMN; or

– for the current Registration Area.

While it remains RM-REGISTERED in the PLMN and regardless of the Access Type, the UE shall not re-attempt to register to an S-NSSAI rejected for the entire PLMN until this rejected S-NSSAI is deleted as specified below.

While it remains RM-REGISTERED in the PLMN, the UE shall not re-attempt to register to an S-NSSAI rejected in the current Registration Area until it moves out of the current Registration Area.

NOTE 2: The details and more cases of S-NSSAI rejection are described in TS 24.501 [47].

S-NSSAIs that the UE provides in the Requested NSSAI which are neither in the Allowed NSSAI nor provided as a rejected S-NSSAI, shall, by the UE, not be regarded as rejected, i.e. the UE may request to register these S-NSSAIs again next time the UE sends a Requested NSSAI.

The UE stores (S-)NSSAIs as follows:

– When provisioned with a Configured NSSAI for a PLMN and/or a mapping of Configured NSSAI to HPLMN S-NSSAIs and possibly NSSRG information for each S-NSSAI in the Configured NSSAI (if applicable and supported by the UE), or when requested to remove the configuration due to network slicing subscription change, the UE shall:

– replace any stored (old) Configured NSSAI for this PLMN with the new Configured NSSAI for this PLMN (if applicable); and

– delete any stored associated mapping of this old Configured NSSAI for this PLMN to HPLMN S-NSSAIs and, if present and applicable, store the mapping of Configured NSSAI to HPLMN S-NSSAIs; and

– delete any stored associated NSSRG information for each S-NSSAI of the Configured NSSAI and, if present, store the associated NSSRG information for each S-NSSAI of the Configured NSSAI; and

– delete any stored rejected S-NSSAI for this PLMN;

– keep the received Configured NSSAI for a PLMN (if applicable) and associated mapping to HPLMN S-NSSAIs (if applicable) and associated NSSRG information for each S-NSSAI of the Configured NSSAI (if applicable and supported by the UE) stored in the UE, even when registering in another PLMN, until a new Configured NSSAI for this PLMN and/or associated mapping are provisioned in the UE, or until the network slicing subscription changes, as described in clause 5.15.4.2. The number of Configured NSSAIs and associated mapping to be kept stored in the UE for PLMNs other than the HPLMN is up to UE implementation. A UE shall at least be capable of storing a Configured NSSAI for the serving PLMN including any necessary mapping of the Configured NSSAI for the Serving PLMN to HPLMN S-NSSAIs and the Default Configured NSSAI.

– The Allowed NSSAI received in a Registration Accept message or a UE Configuration Update Command applies to a PLMN when at least a TAI of this PLMN is included in the RA/TAI list included in this Registration Accept message or UE Configuration Update Command. If the UE Configuration Update Command contains an Allowed NSSAI but not a TAI List, then the last received RA/TAI list applies for the decision on which PLMN(s) the Allowed NSSAI is applicable. If received, the Allowed NSSAI for a PLMN and Access Type and any associated mapping of this Allowed NSSAI to HPLMN S-NSSAIs shall be stored in the UE. The UE should store this Allowed NSSAI and any associated mapping of this Allowed NSSAI to HPLMN S-NSSAIs also when the UE is turned off, or until the network slicing subscription changes, as described in clause 5.15.4.2:

NOTE 3: Whether the UE stores the Allowed NSSAI and any associated mapping of the Allowed NSSAI to HPLMN S-NSSAIs also when the UE is turned off is left to UE implementation.

– When a new Allowed NSSAI for a PLMN and any associated mapping of the Allowed NSSAI to HPLMN S-NSSAIs are received over an Access Type, the UE shall:

– replace any stored (old) Allowed NSSAI and any associated mapping for these PLMN and Access Type with this new Allowed NSSAI; and

– delete any stored associated mapping of this old Allowed NSSAI for this PLMN to HPLMN S-NSSAIs and, if present, store the associated mapping of this new Allowed NSSAI to HPLMN S-NSSAIs;

– If received, an S-NSSAI rejected for the entire PLMN shall be stored in the UE while RM-REGISTERED in this PLMN regardless of the Access Type or until it is deleted.

– If received, an S-NSSAI rejected for the current Registration Area shall be stored in the UE while RM-REGISTERED until the UE moves out of the current Registration Area or until the S-NSSAI is deleted.

NOTE 4: The storage aspects of rejected S-NSSAIs are described in TS 24.501 [47].

– If received, the Pending NSSAI shall be stored in the UE as described in TS 24.501 [47].

UE configuration to guide UE selection of a N3IWF that supports the S-NSSAIs needed by the UE is defined in clause 6.3.6.

5.15.4.1.2 Mapping of S-NSSAIs values in the Allowed NSSAI and in the Requested NSSAI to the S-NSSAIs values used in the HPLMN

One or more S-NSSAIs in an Allowed NSSAI provided to the UE can have values which are not part of the UE’s current Network Slice configuration information for the Serving PLMN. In this case, the network provides the Allowed NSSAI together with the mapping of each S-NSSAI of the Allowed NSSAI to the corresponding S-NSSAI of the HPLMN. This mapping information allows the UE to associate Applications to S-NSSAIs of the HPLMN as per NSSP of the URSP rules or as per the UE Local Configuration (if available), as defined in clause 6.1.2.2.1 of TS 23.503 [45] and to the corresponding S-NSSAI from the Allowed NSSAI.

In the non-roaming case, the network shall not provide any mapped S-NSSAI to the UE with the Allowed NSSAI.

In roaming case, the UE shall provide in the Requested NSSAI the mapping of S-NSSAIs of the Serving PLMN values to the corresponding S-NSSAI values of the HPLMN, for each S-NSSAI in the Requested NSSAI for which a mapping is available. These values are found in the mapping previously received from the Serving PLMN of the S-NSSAIs of the Configured NSSAI for the Serving PLMN or of the S-NSSAIs of the Allowed NSSAI for the Serving PLMN and Access Type to the corresponding S-NSSAIs values used in the HPLMN.

5.15.4.2 Update of UE Network Slice configuration

At any time, the AMF may provide the UE with a new Configured NSSAI for the Serving PLMN, associated with mapping of the Configured NSSAI to HPLMN S-NSSAIs as specified in clause 5.15.4.1. The Configured NSSAI for the Serving PLMN and the mapping information is either determined in the AMF (if based on configuration, the AMF is allowed to determine the Network Slice configuration for the whole PLMN) or by the NSSF. The AMF provides an updated Configured NSSAI as specified in clause 4.2.4 of TS 23.502 [3], UE Configuration Update procedure.

The AMF shall provide the UE with NSSRG information alongside the Configured NSSAI if NSSRG information is included in the subscription information received from the UDM and if the UE has indicated support for the feature as part of the registration request, see clause 5.15.12.

If the HPLMN performs the configuration update of a UE registered in the HPLMN (e.g. due to a change in the Subscribed S-NSSAI(s) or due to a change of NSSRG information), this results in updates to the Configured NSSAI for the HPLMN and, if applicable, NSSRG information for each S-NSSAI of the Configured NSSAI. Updates to the Allowed NSSAI and/or, if present, to the associated mapping of the Allowed NSSAI to HPLMN S-NSSAIs are also possible if the configuration update affects S-NSSAI(s) in the current Allowed NSSAI.

If the VPLMN performs the configuration update of a UE registered in the VPLMN (e.g. due to a change in the Subscribed S-NSSAI(s), the associated mapping is updated, or due to a change of NSSRG information), this results in updates to the Configured NSSAI for the Serving PLMN and/or to the associated mapping of the Configured NSSAI for the Serving PLMN to HPLMN S-NSSAIs and, if applicable, NSSRG information for each S-NSSAI of the Configured NSSAI. Updates to the Allowed NSSAI and/or to the associated mapping of the Allowed NSSAI to HPLMN S-NSSAIs are also possible if the configuration update affects S-NSSAI(s) in the current Allowed NSSAI.

A UE for which the Configured NSSAI for the Serving PLMN has been updated as described in clause 5.15.4.1 and has been requested to perform a Registration procedure, shall initiate a Registration procedure to receive a new valid Allowed NSSAI (see clause 5.15.5.2.2).

When the subscribed S-NSSAIs change, a UDR flag is set in the HPLMN to make sure the current PLMN (or, if the UE was not reachable, the next serving PLMN) is informed by the UDM that the subscription data for network slicing has changed. The AMF, when it receives the indication from the UDM subscription has changed, indicates the UE that subscription has changed and uses any updated subscription information from the UDM to update the UE. Once the AMF updates the UE and obtains an acknowledgment from the UE, the AMF informs the UDM that the configuration update was successful and the UDM clears the flag in the UDR. If the UE is in a CM-IDLE state, the AMF may trigger Network Triggered Service Request or wait until the UE is in a CM-CONNECTED state as described in clause 4.2.4.2, TS 23.502 [3].

If the UE receives indication from the AMF that Network Slicing subscription has changed, the UE locally deletes the network slicing information it has for all PLMNs, except the Default Configured NSSAI (if present). It also updates the current PLMN network slicing configuration information with any received values from the AMF.

The update of URSP rules (which include the NSSP), if necessary at any time, is described in TS 23.503 [45].

5.15.5 Detailed Operation Overview

5.15.5.1 General

The establishment of User Plane connectivity to a Data Network via a Network Slice instance(s) comprises two steps:

– performing a RM procedure to select an AMF that supports the required Network Slices.

– establishing one or more PDU Session to the required Data network via the Network Slice instance(s).

5.15.5.2 Selection of a Serving AMF supporting the Network Slices

5.15.5.2.1 Registration to a set of Network Slices

When a UE registers over an Access Type with a PLMN, if the UE has either or both of:

– a Configured NSSAI for this PLMN;

– an Allowed NSSAI for this PLMN and Access Type;

the UE shall provide to the network, in AS layer under the conditions described in clause 5.15.9 and in NAS layer, a Requested NSSAI containing the S-NSSAI(s) corresponding to the Network Slice(s) to which the UE wishes to register, unless they are stored in the UE in the Pending NSSAI.

The Requested NSSAI shall be one of:

– the Default Configured NSSAI, i.e. if the UE has no Configured NSSAI nor an Allowed NSSAI for the serving PLMN;

– the Configured-NSSAI, or a subset thereof as described below, e.g. if the UE has no Allowed NSSAI for the Access Type for the serving PLMN;

– the Allowed-NSSAI for the Access Type over which the Requested NSSAI is sent, or a subset thereof; or

– the Allowed-NSSAI for the Access Type over which the Requested NSSAI is sent, or a subset thereof, plus one or more S-NSSAIs from the Configured-NSSAI not yet in the Allowed NSSAI for the Access Type as described below.

NOTE 1: If the UE wishes to register only a subset of the S-NSSAIs from the Configured NSSAI or the Allowed NSSAI, to be able to register with some Network Slices e.g. to establish PDU Sessions for some application(s), and the UE uses the URSP rules (which includes the NSSP) or the UE Local Configuration as defined in clause 6.1.2.2.1 of TS 23.503 [45], then the UE uses applicable the URSP rules or the UE Local Configuration to ensure that the S-NSSAIs included in the Requested NSSAI are not in conflict with the URSP rules or with the UE Local Configuration.

The subset of S-NSSAIs in the Configured-NSSAI provided in the Requested NSSAI consists of one or more S-NSSAI(s) in the Configured NSSAI applicable to this PLMN, if one is present, and for which no corresponding S-NSSAI is already present in the Allowed NSSAI for the access type for this PLMN. The UE shall not include in the Requested NSSAI any S-NSSAI that is currently rejected by the network (i.e. rejected in the current registration area or rejected in the PLMN). For the registration to a PLMN for which neither a Configured NSSAI applicable to this PLMN or an Allowed NSSAI are present, the S-NSSAIs provided in the Requested NSSAI correspond to the S-NSSAI(s) in the Default Configured NSSAI unless the UE has HPLMN S-NSSAI for established PDU Session(s) in which case the HPLMN S-NSSAI(s) shall be provided in the mapping of Requested NSSAI in the NAS Registration Request message, with no corresponding VPLMN S-NSSAI in the Requested NSSAI. If the UE has been provided with NSSRG information together with the Configured NSSAI, the UE only includes in the Requested NSSAI S-NSSAIs that share a common NSSRG, see clause 5.15.12.2. If the UE has stored Pending NSSAI and the UE is still interested in the Pending NSSAI then all the S-NSSAIs in the Requested NSSAI and the Pending S-NSSAI shall share a common NSSRG.

When a UE registers over an Access Type with a PLMN, the UE shall also indicate in the Registration Request message when the Requested NSSAI is based on the Default Configured NSSAI.

The UE shall include the Requested NSSAI in the RRC Connection Establishment and in the establishment of the connection to the N3IWF/TNGF (as applicable) and in the NAS Registration procedure messages subject to conditions set out in clause 5.15.9. However, the UE shall not indicate any NSSAI in RRC Connection Establishment or Initial NAS message unless it has either a Configured NSSAI for the corresponding PLMN, an Allowed NSSAI for the corresponding PLMN and Access Type, or the Default Configured NSSAI. If the UE has HPLMN S-NSSAI(s) for established PDU Session(s), the HPLMN S-NSSAI(s) shall be provided in the mapping of Requested NSSAI in the NAS Registration Request message, independent of whether the UE has the corresponding VPLMN S-NSSAI. The (R)AN shall route the NAS signalling between this UE and an AMF selected using the Requested NSSAI obtained during RRC Connection Establishment or connection to N3IWF/TNGF respectively. If the (R)AN is unable to select an AMF based on the Requested NSSAI, it routes the NAS signalling to an AMF from a set of default AMFs. In the NAS signalling, if available, the UE provides the mapping of each S-NSSAI of the Requested NSSAI to a corresponding HPLMN S-NSSAI.

When a UE registers with a PLMN, if for this PLMN the UE has not included a Requested NSSAI nor a GUAMI while establishing the connection to the (R)AN, the (R)AN shall route all NAS signalling from/to this UE to/from a default AMF. When receiving from the UE a Requested NSSAI and a 5G-S-TMSI or a GUAMI in RRC Connection Establishment or in the establishment of connection to N3IWF/TNGF, if the 5G-AN can reach an AMF corresponding to the 5G-S-TMSI or GUAMI, then 5G-AN forwards the request to this AMF. Otherwise, the 5G-AN selects a suitable AMF based on the Requested NSSAI provided by the UE and forwards the request to the selected AMF. If the 5G-AN is not able to select an AMF based on the Requested NSSAI, then the request is sent to a default AMF.

When the AMF selected by the AN during Registration Procedure receives the UE Registration request, or after an AMF selection by MME (i.e. during EPS to 5GS handover) the AMF receives S-NSSAI(s) from SMF+PGW-C in 5GC:

– As part of the Registration procedure described in clause 4.2.2.2.2 of TS 23.502 [3], or as part of the EPS to 5GS handover using N26 interface procedure described in clause 4.11.1.2.2 of TS 23.502 [3], the AMF may query the UDM to retrieve UE subscription information including the Subscribed S-NSSAIs.

– The AMF verifies whether the S-NSSAI(s) in the Requested NSSAI or the S-NSSAI(s) received from SMF+PGW-C are permitted based on the Subscribed S-NSSAIs (to identify the Subscribed S-NSSAIs the AMF may use the mapping to HPLMN S-NSSAIs provided by the UE, in the NAS message, for each S-NSSAI of the Requested NSSAI).

– When the UE context in the AMF does not yet include an Allowed NSSAI for the corresponding Access Type, the AMF queries the NSSF (see (B) below for subsequent handling), except in the case when, based on configuration in this AMF, the AMF is allowed to determine whether it can serve the UE (see (A) below for subsequent handling). The IP address or FQDN of the NSSF is locally configured in the AMF.

NOTE 2: The configuration in the AMF depends on operator’s policy.

– When the UE context in the AMF already includes an Allowed NSSAI for the corresponding Access Type, based on the configuration for this AMF, the AMF may be allowed to determine whether it can serve the UE (see (A) below for subsequent handling).

– AMF or NSSF may have previously subscribed to slice load level and/or Observed Service Experience and/or Dispersion Analytics related network data analytics for a Network Slice from NWDAF, optionally for an Area of Interest composed of one or several TAIs. If AMF subscribes to analytics, AMF may determine that it cannot serve the UE based on received analytics (see (A) below). If AMF subscribes to notifications on changes on the Network Slice or Network Slice instance availability information from NSSF optionally indicating a list of supported TAIs, it may determine that it cannot serve the UE after the restriction notification is received (see (A) below). If AMF does not subscribe to notifications on changes on the availability information from NSSF, NSSF may take the analytics information into account when AMF queries NSSF (see (B) below).

NOTE 3: The configuration in the AMF depends on the operator’s policy.

(A) Depending on fulfilling the configuration as described above, the AMF may be allowed to determine whether it can serve the UE, and the following is performed:

– For the mobility from EPS to 5GS, the AMF first derives the serving PLMN value(s) of S-NSSAI(s) based on the HPLMN S-NSSAI(s) in the mapping of Requested NSSAI (in CM-IDLE state) or the HPLMN S-NSSAI(s) received from SMF+PGW-C (in CM-CONNECTED state). After that the AMF regards the derived value(s) as the Requested NSSAI.

– For the inter PLMN within 5GC mobility, the new AMF derives the serving PLMN value(s) of S-NSSAI(s) based on the HPLMN S-NSSAI(s) in the mapping of Requested NSSAI. After that the AMF regards the derived value(s) as the Requested NSSAI.

– AMF checks whether it can serve all the S-NSSAI(s) from the Requested NSSAI present in the Subscribed S-NSSAIs (potentially using configuration for mapping S-NSSAI values between HPLMN and Serving PLMN), or all the S-NSSAI(s) marked as default in the Subscribed S-NSSAIs in the case that no Requested NSSAI was provided or none of the S-NSSAIs in the Requested NSSAI are permitted, i.e. do not match any of the Subscribed S-NSSAIs or not available at the current UE’s Tracking Area (see clause 5.15.3).

– If AMF has subscribed to slice load level and/or Observed Service Experience and/or Dispersion Analytics related network data analytics for a Network Slice from NWDAF, or if AMF had received a Network Slice restriction from NSSF that applies to the list of TAIs supported by the AMF, it may use that information to determine whether the AMF can serve the UE on the S-NSSAI(s) in the Requested NSSAI.

– If the AMF can serve the S-NSSAIs in the Requested NSSAI, the AMF remains the serving AMF for the UE. The Allowed NSSAI is then composed of the list of S-NSSAI(s) in the Requested NSSAI permitted based on the Subscribed S-NSSAIs and/or the list of S-NSSAI(s) for the Serving PLMN which are mapped to the HPLMN S-NSSAI(s) provided in the mapping of Requested NSSAI permitted based on the Subscribed S-NSSAIs, or, if neither Requested NSSAI nor the mapping of Requested NSSAI was provided or none of the S-NSSAIs in the Requested NSSAI are permitted, all the S-NSSAI(s) marked as default in the Subscribed S-NSSAIs and taking also into account the availability of the Network Slice instances as described in clause 5.15.8 that are able to serve the S-NSSAI(s) in the Allowed NSSAI in the current UE’s Tracking Areas in addition to any Network Slice instance restriction for the S-NSSAI(s) in the Allowed NSSAI provided by the NSSF. If the AMF has received NSSRG Information for the Subscribed S-NSSAIs as part of the UE subscription information, it shall only include in the Allowed NSSAI S-NSSAIs that all share a common NSSRG (see clause 5.15.12). If at least one S-NSSAI in the Requested NSSAI is not available in the current UE’s Tracking Area, then either the AMF may determine a Target NSSAI or step (B) is executed. The AMF also determines the mapping if the S-NSSAI(s) included in the Allowed NSSAI needs to be mapped to Subscribed S-NSSAI(s) values. If no Requested NSSAI is provided, or the mapping of the S-NSSAIs in Requested NSSAI to HPLMN S-NSSAIs is incorrect, or the Requested NSSAI includes an S-NSSAI that is not valid in the Serving PLMN, or the UE indicated that the Requested NSSAI is based on the Default Configured NSSAI, the AMF, based on the Subscribed S-NSSAI(s) and operator’s configuration, may also determine the Configured NSSAI for the Serving PLMN and, if applicable, the associated mapping of the Configured NSSAI to HPLMN S-NSSAIs, so these can be configured in the UE. Then Step (C) is executed.

– Else, the AMF queries the NSSF (see (B) below).

(B) When required as described above, the AMF needs to query the NSSF, and the following is performed:

– The AMF queries the NSSF, with Requested NSSAI, Default Configured NSSAI Indication, mapping of Requested NSSAI to HPLMN S-NSSAIs, the Subscribed S-NSSAIs (with an indication if marked as default S-NSSAI), NSSRG Information (if provided by the UDM, see clause 5.15.12), any Allowed NSSAI it might have for the other Access Type (including its mapping to HPLMN S-NSSAIs), PLMN ID of the SUPI and UE’s current Tracking Area.

– Based on this information, local configuration, and other locally available information including RAN capabilities in the current Tracking Area for the UE or load level information for a Network Slice instance provided by the NWDAF, the NSSF does the following:

– It verifies which S-NSSAI(s) in the Requested NSSAI are permitted based on comparing the Subscribed S-NSSAIs with the S-NSSAIs in the mapping of Requested NSSAI to HPLMN S-NSSAIs. It considers the S-NSSAI(s) marked as default in the Subscribed S-NSSAIs in the case that no Requested NSSAI was provided or no S-NSSAI from the Requested NSSAI are permitted i.e. are not present in the Subscribed S-NSSAIs or not available e.g. at the current UE’s Tracking Area. If NSSRG information is provided, the NSSF only selects S-NSSAIs that share a common NSSRG (see clause 5.15.12).

– If AMF has not subscribed to notifications on changes on the Network Slice or Network Slice instance availability information from NSSF and NSSF has subscribed to slice load level and/or Observed Service Experience and/or Dispersion Analytics related network data analytics for a Network Slice from NWDAF, NSSF may use the analytics information for the determination of the (Network Slice instance(s) and the) list of S-NSSAI(s) in the Allowed NSSAI(s) to serve the UE.

– It selects the Network Slice instance(s) to serve the UE. When multiple Network Slice instances in the UE’s Tracking Area are able to serve a given S-NSSAI, based on operator’s configuration, the NSSF may select one of them to serve the UE, or the NSSF may defer the selection of the Network Slice instance until a NF/service within the Network Slice instance needs to be selected.

– It determines the target AMF Set to be used to serve the UE, or, based on configuration, the list of candidate AMF(s), possibly after querying the NRF.

NOTE 4: If the target AMF(s) returned from the NSSF is the list of candidate AMF(s), the Registration Request message can only be redirected via the direct signalling between the initial AMF and the selected target AMF as described in clause 5.15.5.2.3. The NSSF does not provide the target AMF(s), when it provides a Target NSSAI in order to redirect or handover the UE to a cell of another TA as described in clause 5.3.4.3.3.

– It determines the Allowed NSSAI(s) for the applicable Access Type, composed of the list of S-NSSAI(s) in the Requested NSSAI permitted based on the Subscribed S-NSSAIs and/or the list of S-NSSAI(s) for the Serving PLMN which are mapped to the HPLMN S-NSSAIs provided in the mapping of Requested NSSAI permitted based on the Subscribed S-NSSAIs, or, if neither Requested NSSAI nor the mapping of Requested NSSAI was provided or none of the S-NSSAIs in the Requested NSSAI are permitted, all the S-NSSAI(s) marked as default in the Subscribed S-NSSAIs, and taking also into account the availability of the Network Slice instances as described in clause 5.15.8 that are able to serve the S-NSSAI(s) in the Allowed NSSAI in the current UE’s Tracking Areas. If NSSRG information applies, the NSSF only selects S-NSSAIs that share a common NSSRG (see clause 5.15.12).

– It also determines the mapping of each S-NSSAI of the Allowed NSSAI(s) to the Subscribed S-NSSAIs if necessary.

– Based on operator configuration, the NSSF may determine the NRF(s) to be used to select NFs/services within the selected Network Slice instance(s).

– Additional processing to determine the Allowed NSSAI(s) in roaming scenarios and the mapping to the Subscribed S-NSSAIs, as described in clause 5.15.6.

– If no Requested NSSAI is provided or the Requested NSSAI includes an S-NSSAI that is not valid in the Serving PLMN, or the mapping of the S-NSSAIs in Requested NSSAI to HPLMN S-NSSAIs is incorrect, or the Default Configured NSSAI Indication is received from AMF, the NSSF based on the Subscribed S-NSSAI(s) and operator configuration may also determine the Configured NSSAI for the Serving PLMN and, if applicable, the associated mapping of the Configured NSSAI to HPLMN S-NSSAIs, so these can be configured in the UE.

– If at least one S-NSSAI in the Requested NSSAI is not available in the current UE’s Tracking Area, the NSSF may provide a Target NSSAI for the purpose of allowing the NG-RAN to redirect the UE to a cell of a TA in another frequency band supporting network slices not available in the current TA as described in clause 5.3.4.3.3.

– The NSSF returns to the current AMF the Allowed NSSAI for the applicable Access Type, the mapping of each S-NSSAI of the Allowed NSSAI to the Subscribed S-NSSAIs if determined and the target AMF Set, or, based on configuration, the list of candidate AMF(s). The NSSF may return the NRF(s) to be used to select NFs/services within the selected Network Slice instance(s), and the NRF to be used to determine the list of candidate AMF(s) from the AMF Set. The NSSF may return NSI ID(s) to be associated to the Network Slice instance(s) corresponding to certain S-NSSAIs. NSSF may return the rejected S-NSSAI(s) as described in clause 5.15.4.1. The NSSF may return the Configured NSSAI for the Serving PLMN and the associated mapping of the Configured NSSAI to HPLMN S-NSSAIs. The NSSF may return Target NSSAI as described in clause 5.3.4.3.3.

– Depending on the available information and based on configuration, the AMF may query the appropriate NRF (e.g. locally pre-configured or provided by the NSSF) with the target AMF Set. The NRF returns a list of candidate AMFs.

– If AMF Re-allocation is necessary, the current AMF reroutes the Registration Request or forwards the UE context to a target serving AMF as described in clause 5.15.5.2.3.

– Step (C) is executed.

(C) The serving AMF shall determine a Registration Area such that all S-NSSAIs of the Allowed NSSAI for this Registration Area are available in all Tracking Areas of the Registration Area (and also considering other aspects as described in clause 5.3.2.3 and clause 5.3.4.3.3) and then return to the UE this Allowed NSSAI and the mapping of the Allowed NSSAI to the Subscribed S-NSSAIs if provided. The AMF may return the rejected S-NSSAI(s) as described in clause 5.15.4.1.

NOTE 5: The S-NSSAIs in the Allowed NSSAI for Non-3GPP access are available homogeneously "in the PLMN" for the N3IWF case since a N3IWF providing access to a 5GC can be reached from any IP location. For other types of Non-3GPP access the S-NSSAIs in the Allowed NSSAI for Non-3GPP access can be not available homogeneously, for example different W-AGFs/TNGF(s) can be deployed in different locations and support different TAIs that support different network slices.

When either no Requested NSSAI was included, or the mapping of the S-NSSAIs in Requested NSSAI to HPLMN S-NSSAIs is incorrect, or a Requested NSSAI is not considered valid in the PLMN and as such at least one S-NSSAI in the Requested NSSAI was rejected as not usable by the UE in the PLMN, or the UE indicated that the Requested NSSAI is based on the Default Configured NSSAI, the AMF may update the UE slice configuration information for the PLMN as described in clause 5.15.4.2.

If the Requested NSSAI does not include S-NSSAIs which map to S-NSSAIs of the HPLMN subject to Network Slice-Specific Authentication and Authorization and the AMF determines that no S-NSSAI can be provided in the Allowed NSSAI for the UE in the current UE’s Tracking Area and if no default S-NSSAI(s) could be added as described in step (A), the AMF shall reject the UE Registration and shall include in the rejection message the list of Rejected S-NSSAIs, each of them with the appropriate rejection cause value.

If the Requested NSSAI includes S-NSSAIs which map to S-NSSAIs of the HPLMN subject to Network Slice-Specific Authentication and Authorization, the AMF shall include in the Registration Accept message an Allowed NSSAI containing only those S-NSSAIs that are not to be subject to Network Slice-Specific Authentication and Authorization and, based on the UE Context in AMF, those S-NSSAIs for which Network Slice-Specific Authentication and Authorization for at least one of the corresponding HPLMN S-NSSAIs succeeded previously regardless the Access Type, if any.

The AMF shall also provide the list of Rejected S-NSSAIs, each of them with the appropriate rejection cause value.

If the AMF determined the Target NSSAI or received a Target NSSAI from the NSSF, the AMF should provide the Target NSSAI to the PCF for retrieving a corresponding RFSP as described in clause 5.3.4.3.1 or, if the PCF is not deployed, the AMF should determine a corresponding RFSP based on local configuration. Then the AMF provides the Target NSSAI and the corresponding RFSP to the NG-RAN as described in clause 5.3.4.3.3. The S-NSSAIs which map to S-NSSAIs of the HPLMN subject to an ongoing Network Slice-Specific Authentication and Authorization shall be included in the Pending NSSAI and removed from Allowed NSSAI. The Pending NSSAI may contain a mapping of the S-NSSAI(s) for the Serving PLMN to the HPLMN S-NSSAIs, if applicable. The UE shall not include in the Requested NSSAI any of the S-NSSAIs from the Pending NSSAI the UE stores, regardless of the Access Type.

If:

– all the S-NSSAI(s) in the Requested NSSAI are still to be subject to Network Slice-Specific Authentication and Authorization; or

– no Requested NSSAI was provided or none of the S-NSSAIs in the Requested NSSAI matches any of the Subscribed S-NSSAIs, and all the S-NSSAI(s) marked as default in the Subscribed S-NSSAIs are to be subject to Network Slice-Specific Authentication and Authorization;

the AMF shall provide a "NSSAA to be performed" indicator and no Allowed NSSAI to the UE in the Registration Accept message. Upon receiving the Registration Accept message, the UE is registered in the PLMN but shall wait for the completion of the Network Slice-Specific Authentication and Authorization without attempting to use any service provided by the PLMN on any access, except e.g. emergency services (see TS 24.501 [47]), until the UE receives an allowed NSSAI.

Then, the AMF shall initiate the Network Slice-Specific Authentication and Authorization procedure as described in clause 5.15.10 for each S-NSSAI that requires it, except, based on Network policies, for those S-NSSAIs for which Network Slice-Specific Authentication and Authorization have been already initiated on another Access Type for the same S-NSSAI(s). At the end of the Network Slice-Specific Authentication and Authorization steps, the AMF by means of the UE Configuration Update procedure shall provide a new Allowed NSSAI to the UE which also contains the S-NSSAIs subject to Network Slice-Specific Authentication and Authorization for which the authentication and authorization is successful. The AMF may perform AMF selection when NSSAA completes for the S-NSSAIs subject to NSSAA. If an AMF change is required, this shall be triggered by the AMF using the UE Configuration Update procedure indicating a UE re-registration is required. The S-NSSAIs which were not successfully authenticated and authorized are not included in the Allowed NSSAI and are included in the list of Rejected S-NSSAIs with a rejection cause value indicating Network Slice-Specific Authentication and Authorization failure.

Once completed the Network Slice-Specific (re-)Authentication and (re-)Authorization procedure, if the AMF determines that no S-NSSAI can be provided in the Allowed NSSAI for the UE, which is already authenticated and authorized successfully by a PLMN, and if no default S-NSSAI(s) could be added as described in step (A), the AMF shall execute the Network-initiated Deregistration procedure described in clause 4.2.2.3.3 of TS 23.502 [3] and shall include in the explicit De-Registration Request message the list of Rejected S-NSSAIs, each of them with the appropriate rejection cause value.

If an S-NSSAI is rejected with a rejection cause value indicating Network Slice-Specific Authentication and Authorization failure or revocation, the UE can re-attempt to request the S-NSSAI based on policy, local in the UE.

5.15.5.2.2 Modification of the Set of Network Slice(s) for a UE

The set of Network Slices for a UE can be changed at any time while the UE is registered with a network, and may be initiated by the network, or by the UE, under certain conditions as described below.

The network, based on local policies, subscription changes and/or UE mobility and/or UE Dispersion data classification, operational reasons (e.g. a Network Slice instance is no longer available or load level information or service experience for a Network Slice or network slice instance provided by the NWDAF), may change the set of Network Slice(s) to which the UE is registered and provide the UE with a new Registration Area and/or Allowed NSSAI and the mapping of this Allowed NSSAI to HPLMN S-NSSAIs, for each Access Type over which the UE is registered. In addition, the network may provide the Configured NSSAI for the Serving PLMN, the associated mapping information, and the rejected S-NSSAIs. The network may perform such a change over each Access Type during a Registration procedure or trigger a notification towards the UE of the change of the Network Slices using a UE Configuration Update procedure as specified in clause 4.2.4 of TS 23.502 [3]. The new Allowed NSSAI(s) and the mapping to HPLMN S-NSSAIs are determined as described in clause 5.15.5.2.1 (an AMF Re-allocation may be needed). The AMF provides the UE with:

– an indication that the acknowledgement from UE is required;

– Configured NSSAI for the Serving PLMN (if required), rejected S-NSSAI(s) (if required) and TAI list, and

– the new Allowed NSSAI with the associated mapping of Allowed NSSAI for each Access Type (as applicable) unless the AMF cannot determine the new Allowed NSSAI (e.g. all S-NSSAIs in the old Allowed NSSAI have been removed from the Subscribed S-NSSAIs).

Furthermore:

– If the changes to the Allowed NSSAI require the UE to perform immediately a Registration procedure because they affect the existing connectivity to AMF (e.g. the new S-NSSAIs require a separate AMF that cannot be determined by the current serving AMF, or the AMF cannot determine the Allowed NSSAI) or due to AMF local policies also when the changes does not affect the existing connectivity to AMF:

– The serving AMF indicates to the UE the need for the UE to perform a Registration procedure without including the GUAMI or 5G-S-TMSI in the access stratum signalling after entering CM-IDLE state. The AMF shall release the NAS signalling connection to the UE to allow to enter CM-IDLE after receiving the acknowledgement from UE.

– When the UE receives indications to perform a Registration procedure without including the GUAMI or 5G-S-TMSI in the access stratum signalling after entering CM-IDLE state, then:

– The UE deletes any stored (old) Allowed NSSAI and associated mapping as well as any (old) rejected S-NSSAI.

– The UE shall initiate a Registration procedure with the registration type Mobility Registration Update after the UE enters CM-IDLE state as specified in as described in step 4 of clause 4.2.4.2 of TS 23.502 [3]. The UE shall include a Requested NSSAI (as described in clause 5.15.5.2.1) with the associated mapping of Requested NSSAI in the Registration Request message. Also, the UE shall include, subject to the conditions set out in clause 5.15.9, a Requested NSSAI in access stratum signalling but no GUAMI.

If there is an established PDU Session associated with emergency services, then the serving AMF indicates to the UE the need for the UE to perform a Registration procedure but does not release the NAS signalling connection to the UE. The UE performs the Registration procedure only after the release of the PDU Session used for the emergency services.

In addition to sending the new Allowed NSSAI to the UE, when a Network Slice used for a one or multiple PDU Sessions is no longer available for a UE, the following applies:

– If the Network Slice becomes no longer available under the same AMF (e.g. due to UE subscription change), the AMF indicates to the SMF(s) which PDU Session ID(s) corresponding to the relevant S-NSSAI shall be released. SMF releases the PDU Session according to clause 4.3.4.2 of TS 23.502 [3].

– If the Network Slice becomes no longer available upon a change of AMF (e.g. due to Registration Area change), the new AMF indicates to the old AMF that the PDU Session(s) corresponding to the relevant S-NSSAI shall be released. The old AMF informs the corresponding SMF(s) to release the indicated PDU Session(s). The SMF(s) release the PDU Session(s) as described in clause 4.3.4 of TS 23.502 [3]. Then the new AMF modifies the PDU Session Status correspondingly. The PDU Session(s) context is locally released in the UE after receiving the PDU Session Status in the Registration Accept message.

The UE uses either the URSP rules (which includes the NSSP) or the UE Local Configuration as defined in clause 6.1.2.2.1 of TS 23.503 [45] to determine whether ongoing traffic can be routed over existing PDU Sessions belonging to other Network Slices or establish new PDU Session(s) associated with same/other Network Slice.

In order to change the set of S-NSSAIs the UE is registered to over an Access Type, the UE shall initiate a Registration procedure over this Access Type as specified in clause 5.15.5.2.1.

If, for an established PDU Session:

– none of the values of the S-NSSAIs of the HPLMN in the mapping of the Requested NSSAI to S-NSSAIs of the HPLMN included in the Registration Request matches the S-NSSAI of the HPLMN associated with the PDU Session; or

– none of the values of the S-NSSAIs in the Requested NSSAI matches the value of the S-NSSAI of HPLMN associated with the PDU Session and the mapping of the Requested NSSAI to S-NSSAIs of the HPLMN is not included in the Registration Request,

the network shall release this PDU Session as follows.

– the AMF informs the corresponding SMF(s) to release the indicated PDU Session(s). The SMF(s) release the PDU Session(s) as described in clause 4.3.4 of TS 23.502 [3]. Then the AMF modifies the PDU Session Status correspondingly. The PDU Session(s) context is locally released in the UE after receiving the PDU Session Status from the AMF.

A change of the set of S-NSSAIs (whether UE or Network initiated) to which the UE is registered may, subject to operator policy, lead to AMF change, as described in clause 5.15.5.2.1.

5.15.5.2.3 AMF Re-allocation due to Network Slice(s) Support

During a Registration procedure in a PLMN, if the network decides that the UE should be served by a different AMF based on Network Slice(s) aspects, then the AMF that first received the Registration Request shall redirect the Registration request to target AMF via the 5G-AN or via direct signalling between the initial AMF and the target AMF. If the target AMF(s) are returned from the NSSF and identified by a list of candidate AMF(s), the redirection message shall only be sent via the direct signalling between the initial AMF and the target AMF. If the redirection message is sent by the AMF via the 5G-AN, the message shall include information for selection of a new AMF to serve the UE.

When during a Registration procedure the UE requests a new S-NSSAI which is not supported in the UE’s current Tracking Area, the serving AMF itself or by interacting with the NSSF as described in clause 5.15.5.2.1 may determine a Target NSSAI. The AMF provides the Target NSSAI to the NG-RAN and the NG-RAN may apply redirection or handover of the UE to a cell in another TA supporting the Target NSSAI as described in clause 5.3.4.3.3.

During a EPS to 5GS handover using N26 interface procedure, if the network decides that the UE should be served by a different AMF based on Network Slice(s) aspects, then the AMF, which received the Forward Relocation Request from MME, shall forward the UE context to target AMF via direct signalling between the initial AMF and the target AMF as described in clause 4.11.1.2.2 of TS 23.502 [3].

For a UE that is already registered, the system shall support a redirection initiated by the network of a UE from its serving AMF to a target AMF due to Network Slice(s) considerations (e.g. the operator has changed the mapping between the Network Slice instances and their respective serving AMF(s)). Operator policy determines whether redirection between AMFs is allowed.

5.15.5.3 Establishing a PDU Session in a Network Slice

The PDU Session Establishment in a Network Slice instance to a DN allows data transmission in a Network Slice instance. A PDU Session is associated to an S-NSSAI and a DNN. A UE that is registered in a PLMN over an Access Type and has obtained a corresponding Allowed NSSAI, shall indicate in the PDU Session Establishment procedure the S-NSSAI according to the NSSP in the URSP rules or according to the UE Local Configuration as defined in clause 6.1.2.2.1 of TS 23.503 [45], and, if available, the DNN the PDU Session is related to. The UE includes the appropriate S-NSSAI from this Allowed NSSAI and, if mapping of the Allowed NSSAI to HPLMN S-NSSAIs was provided, an S-NSSAI with the corresponding value from this mapping.

If the UE cannot determine any S-NSSAI after performing the association of the application to a PDU Session according to clause 6.1.2.2.1 of TS 23.503 [45], the UE shall not indicate any S-NSSAI in the PDU Session Establishment procedure.

The network (HPLMN) may provision the UE with Network Slice selection policy (NSSP) as part of the URSP rules, see clause 6.6.2 of TS 23.503 [45]. When the Subscription Information contains more than one S-NSSAI and the network wants to control/modify the UE usage of those S-NSSAIs, then the network provisions/updates the UE with NSSP as part of the URSP rules. When the Subscription Information contains only one S-NSSAI, the network needs not provision the UE with NSSP as part of the URSP rules. The NSSP rules associate an application with one or more HPLMN S-NSSAIs. A default rule which matches all applications to a HPLMN S-NSSAI may also be included.

The UE shall store and use the URSP rules, including the NSSP, as described in TS 23.503 [45]. When a UE application associated with a specific S-NSSAI requests data transmission:

– if the UE has one or more PDU Sessions established corresponding to the specific S-NSSAI, the UE routes the user data of this application in one of these PDU Sessions, unless other conditions in the UE prohibit the use of these PDU Sessions. If the application provides a DNN, then the UE considers also this DNN to determine which PDU Session to use. This is further described in clause 6.6.2 of TS 23.503 [45].

– If the UE does not have a PDU Session established with this specific S-NSSAI, the UE requests a new PDU Session corresponding to this S-NSSAI and with the DNN that may be provided by the application. In order for the RAN to select a proper resource for supporting network slicing in the RAN, RAN needs to be aware of the Network Slices used by the UE. This is further described in clause 6.6.2 of TS 23.503 [45].

If the AMF is not able to determine the appropriate NRF to query for the S-NSSAI provided by the UE, the AMF may query the NSSF with this specific S-NSSAI, location information, PLMN ID of the SUPI. The NSSF determines and returns the appropriate NRF to be used to select NFs/services within the selected Network Slice instance. The NSSF may also return an NSI ID to be used to select NFs within the selected Network Slice instance to use for this S-NSSAI.

The AMF or NSSF may select a Network Slice instance based on load level and/or Observe Service Experience and/or Dispersion analytics from NWDAF.

The IP address or FQDN of the NSSF is locally configured in the AMF.

SMF discovery and selection within the selected Network Slice instance is initiated by the AMF when a SM message to establish a PDU Session is received from the UE. The appropriate NRF is used to assist the discovery and selection tasks of the required network functions for the selected Network Slice instance.

The AMF queries the appropriate NRF to select an SMF in a Network Slice instance based on S-NSSAI, DNN, NSI-ID (if available) and other information e.g. UE subscription and local operator policies, when the UE triggers PDU Session Establishment. The selected SMF establishes a PDU Session based on S-NSSAI and DNN.

When the AMF belongs to multiple Network Slice instances, based on configuration, the AMF may use an NRF at the appropriate level for the SMF selection.

For further details on the SMF selection, refer to clause 4.3.2.2.3 of TS 23.502 [3].

When a PDU Session for a given S-NSSAI is established using a specific Network Slice instance, the CN provides to the (R)AN the S-NSSAI corresponding to this Network Slice instance to enable the RAN to perform access specific functions.

The UE shall not perform PDU Session handover from one Access Type to another if the S-NSSAI of the PDU Session is not included in the Allowed NSSAI of the target Access Type.

5.15.6 Network Slicing Support for Roaming

For roaming scenarios:

– If the UE only uses standard S-NSSAI values, then the same S-NSSAI values can be used in VPLMN as in the HPLMN.

– If the VPLMN and HPLMN have an SLA to support non-standard S-NSSAI values in the VPLMN, the NSSF of the VPLMN maps the Subscribed S-NSSAIs values to the respective S-NSSAI values to be used in the VPLMN. The S-NSSAI values to be used in the VPLMN are determined by the NSSF of the VPLMN based on the SLA. The NSSF of the VPLMN need not inform the HPLMN of which values are used in the VPLMN.

Depending on operator’s policy and the configuration in the AMF, the AMF may decide the S-NSSAI values to be used in the VPLMN and the mapping to the Subscribed S-NSSAIs.

– The UE constructs Requested NSSAI and provides the mapping of S-NSSAIs of the Requested NSSAI to HPLMN S-NSSAIs if the mapping is stored in the UE, as described in clause 5.15.5.2.1.

– The NSSF in the VPLMN determines the Allowed NSSAI without interacting with the HPLMN.

– the HPLMN may provide NSSRG Information as part of the Subscription information as described in clause 5.15.12.

– The Allowed NSSAI in the Registration Accept includes S-NSSAI values used in the VPLMN. The mapping information described above is also provided to the UE with the Allowed NSSAI as described in clause 5.15.4.

– If the S-NSSAI values are subject to NSAC, depending on operator’s policy, a roaming agreement or an SLA between VPLMN and HPLMN, the AMF or SMF in VPLMN triggers a request for NSAC for these S-NSSAI values as described in clause 5.15.11.3.

– In PDU Session Establishment procedure, the UE includes both:

(a) the S-NSSAI that matches the application (that is triggering the PDU Session Request) within the NSSP in the URSP rules or within the UE Local Configuration as defined in clause 6.1.2.2.1 of TS 23.503 [45]; the value of this S NSSAI is used in the HPLMN; and

(b) an S-NSSAI belonging to the Allowed NSSAI that maps to (a) using the mapping of the Allowed NSSAI to HPLMN S-NSSAIs; the value of this S-NSSAI is used in the VPLMN.

For the home routed case, the V-SMF sends the PDU Session Establishment Request message to the H-SMF along with the S-NSSAI with the value used in the HPLMN (a). If the S-NSSAI values are subject to NSAC, the V-SMF or H-SMF triggers a request for NSAC for these S-NSSAI values as described in clause 5.15.11.3.

– When a PDU Session is established, the CN provides to the AN the S-NSSAI with the value from the VPLMN corresponding to this PDU Session, as described in clause 5.15.5.3.

– The Network Slice instance specific network functions in the VPLMN are selected by the VPLMN by using the S-NSSAI with the value used in the VPLMN and querying an NRF that has either been pre-configured, or provided by the NSSF in the VPLMN. The Network Slice specific functions of the HPLMN (if applicable) are selected by the VPLMN by using the related S-NSSAI with the value used in the HPLMN via the support from an appropriate NRF in the HPLMN, identified as specified in clause 4.17.5 of TS 23.502 [3] and, for SMF in clause 4.3.2.2.3.3 of TS 23.502 [3].

5.15.7 Network slicing and Interworking with EPS

5.15.7.1 General

A 5GS supports Network Slicing and might need to interwork with the EPS in its PLMN or in other PLMNs as specified in clause 5.17.2. The EPC may support the Dedicated Core Networks (DCN). In some deployments, the MME selection may be assisted by a DCN-ID provided by the UE to the RAN (see TS 23.401 [26]).

Mobility between 5GC to EPC does not guarantee all active PDU Session(s) can be transferred to the EPC.

During PDN connection establishment in the EPC, the UE allocates the PDU Session ID and sends it to the SMF+PGW-C via PCO. As described in clause 4.11.0a.5 of TS 23.502 [3], an S-NSSAI associated with the PDN connection is determined based on the S-NSSAI(s) supported by the SMF+PGW-C, the Subscribed S-NSSAI from UDM and the operator policy by the SMF+PGW-C, e.g. based on a combination of SMF+PGW-C address and APN, and is sent to the UE in PCO together with a PLMN ID that the S-NSSAI relates to. In Home Routed roaming case, the UE receives a HPLMN S-NSSAI value from the SMF+PGW-C. If the SMF+PGW-C supports more than one S-NSSAI and the APN is valid for more than one S-NSSAI, the SMF+PGW-C should only select an S-NSSAI that is mapped to the subscribed S-NSSAI of the UE and this subscribed S-NSSAI is not subject to Network Slice-Specific Authentication and Authorization. The UE stores this S-NSSAI and the PLMN ID associated with the PDN connection. The UE derives Requested NSSAI by taking into account of the received PLMN ID. The Requested NSSAI is included in the NAS Registration Request message and, subject to the conditions in clause 5.15.9, the RRC message carrying this Registration Request when the UE registers in 5GC if the UE is non-roaming or the UE has Configured NSSAI for the VPLMN in roaming case. If the UE has no Configured NSSAI of the VPLMN, the UE includes the HPLMN S-NSSAIs in the NAS Registration Request message as described in clause 5.15.5.2.1.

When UE moves from EPS to 5GS, AMF reallocation may happen as described in clause 5.15.7.2 and clause 5.15.7.3.

NOTE: It is assumed that if a MME is configured with a N26 interface towards an AMF, the MME has N26 interfaces with all AMFs serving the same area than the initial AMF and that can serve UE subject to EPS to 5GS mobility.

5.15.7.2 Idle mode aspects

In addition to the interworking principles documented in clause 5.17.2 the following applies for interworking with N26:

– When UE moves from 5GS to EPS, the UE context information sent by AMF to MME includes the UE Usage type, which is retrieved from UDM by AMF as part of subscription data.

– When UE moves from EPS to 5GS, then the UE includes the S-NSSAIs (with values for the Serving PLMN of the target 5GS, if available) associated with the established PDN connections in the Requested NSSAI in RRC Connection Establishment (subject to the conditions set out in clause 5.15.9) and NAS. The UE also provides to the AMF in the Registration Request message the mapping information as described in clause 5.15.6. The UE derives the S-NSSAIs values for the Serving PLMN by using the latest available information from EPS (if received in PCO) and from 5GS (e.g. based on URSP, Configured NSSAI, Allowed NSSAI). In the home-routed roaming case, the AMF selects default V-SMFs. The SMF+PGW-C sends PDU Session IDs and related S-NSSAIs to AMF. The AMF derives S-NSSAI values for the Serving PLMN as described in clause 5.15.5.2.1 and determines whether the AMF is the appropriate AMF to serve the UE. If not, the AMF reallocation may need be triggered. For each PDU Session the AMF determines whether the V-SMF need be reselected based on the associated S-NSSAI value for the Serving PLMN. If the V-SMF need be reallocated, i.e. change from the default V-SMF to another V-SMF, the AMF trigger the V-SMF reallocation as described in clause 4.23.3 of TS 23.502 [3].

In addition to the interworking principles documented in clause 5.17.2 the following applies for interworking without N26:

– When the UE initiates the Registration procedure, and subject to the conditions set out in clause 5.15.9, the UE includes the S-NSSAI (with values for the Serving PLMN of the target 5GS) associated with the established PDN connections in the Requested NSSAI in the RRC Connection Establishment.

– The UE includes the S-NSSAIs (with values for the Serving PLMN of the target 5GS, if available) and the HPLMN S-NSSAI received in the PCO for the PDN connections as mapping information when moving PDN connections to 5GC using PDU Session Establishment Request message. The UE derives the S-NSSAIs values for the Serving PLMN by using, the latest available information from EPS (if received in PCO) and from 5GS (e.g. based on URSP, Configured NSSAI, Allowed NSSAI).

5.15.7.3 Connected mode aspects

In addition to the interworking principles documented in clause 5.17.2 the following applies for interworking with N26:

– When a UE is CM-CONNECTED in 5GC and a handover to EPS occur, the AMF selects the target MME based on the source AMF Region ID, AMF Set ID and target location information. The AMF forwards the UE context to the selected MME over the N26 Interface. In the UE context, the AMF also includes the UE Usage type, if it is received as part of subscription data. The Handover procedure is executed as documented in TS 23.502 [3]. When the Handover procedure completes successfully the UE performs a Tracking Area Update. This completes the UE registration in the target EPS. As part of this the UE obtains a DCN-ID if the target EPS uses it.

– When a UE is ECM-CONNECTED in EPC, and performs a handover to 5GS, the MME selects the target AMF based on target location information, e.g. TAI and any other available local information (including the UE Usage Type if one is available for the UE in the subscription data) and forwards the UE context to the selected AMF over the N26 interface. In the home-routed roaming case, the AMF selects default V-SMFs. The Handover procedure is executed as documented in TS 23.502 [3]. The SMF+PGW-C sends PDU Session IDs and related S-NSSAIs to AMF. Based on the received S-NSSAIs values the target AMF derives the S-NSSAI values for the Serving PLMN, the target AMF reselects a final target AMF if necessary as described in clause 5.15.5.2.1, the AMF reallocation procedure is triggered. For each PDU Session based on the associated derived S-NSSAI values if the V-SMF need be reallocated, the final target AMF triggers the V-SMF reallocation as described in clause 4.23.2 of TS 23.502 [3]. When the Handover procedure completes successfully the UE performs a Registration procedure. This completes the UE registration in the target 5GS and as part of this the UE obtains an Allowed NSSAI.

5.15.8 Configuration of Network Slice availability in a PLMN

A Network Slice may be available in the whole PLMN or in one or more Tracking Areas of the PLMN.

The availability of a Network Slice refers to the support of the S-NSSAI in the involved NFs. In addition, policies in the NSSF may further restrict from using certain Network Slices in a particular TA, e.g. depending on the HPLMN of the UE.

The availability of a Network Slice in a TA is established end-to-end using a combination of OAM and signalling among network functions. It is derived by using the S-NSSAIs supported per TA in 5G-AN, the S-NSSAIs supported in the AMF and operator policies per TA in the NSSF.

The AMF learns the S-NSSAIs supported per TA by the 5G-AN when the 5G-AN nodes establish or update the N2 connection with the AMF (see TS 38.413 [34]) and TS 38.300 [27]). One or all AMF per AMF Set provides and updates the NSSF with the S-NSSAIs support per TA. The 5G-AN learns the S-NSSAIs per PLMN ID the AMFs it connects to support when the 5G-AN nodes establishes the N2 connection with the AMF or when the AMF updates the N2 connection with the 5G-AN (see TS 38.413 [34] and TS 38.300 [27]).

The NSSF may be configured with operator policies specifying under what conditions the S-NSSAIs can be restricted per TA and per HPLMN of the UE.

The per TA restricted S-NSSAIs may be provided to the AMFs of the AMF Sets at setup of the network and whenever changed.

The AMF may be configured for the S-NSSAIs it supports with operator policies specifying any restriction per TA and per HPLMN of the UE.

5.15.9 Operator-controlled inclusion of NSSAI in Access Stratum Connection Establishment

The Serving PLMN can control per Access Type which (if any) NSSAI the UE includes in the Access Stratum when establishing a connection caused by Service Request, Periodic Registration Update or Registration procedure used to update the UE capabilities. In addition, the Home and Visited PLMNs can also instruct the UE to never include NSSAI in the Access Stratum, regardless of the procedure that causes a RRC Connection to be established, i.e. to always enable privacy for the NSSAI).

During the Registration procedure, the AMF may provide to the UE in the Registration Accept message, an Access Stratum Connection Establishment NSSAI Inclusion Mode parameter, indicating whether and when the UE shall include NSSAI information in the Access Stratum Connection Establishment (e.g. an RRC connection Establishment defined in TS 38.331 [28]) according to one of these modes:

a) The UE shall include an NSSAI set to the Allowed NSSAI, if available, in the Access Stratum Connection Establishment caused by a Service Request, Periodic Registration Update or Registration procedure used to update the UE capabilities;

b) The UE shall include a NSSAI with the following content:

– for the case of Access Stratum Connection Establishment caused by a Service Request: an NSSAI including the S-NSSAI(s) of the Network Slice(s) that trigger the Access Stratum Connection Establishment; i.e. all the S-NSSAIs of the PDU sessions that have the User Plane reactivated by the Service Request, or the S-NSSAIs of the Network Slices a Control Plane interaction triggering the Service Request is related to, e.g. for SM it would be the S-NSSAI of the PDU Session the SM message is about;

– for the case of Access Stratum Connection Establishment caused by a Periodic Registration Update or Registration procedure used to update the UE capabilities, an NSSAI set to the Allowed NSSAI;

c) The UE shall not include any NSSAI in the Access Stratum Connection Establishment caused by Service Request, Periodic Registration Update or Registration procedure used to update the UE capabilities; or

d) The UE shall not provide NSSAI in the Access stratum.

For the case of Access Stratum Connection Establishment caused by Mobility Registration Update or Initial Registration in modes a), b) or c) the UE shall include the Requested NSSAI provided by the NAS layer and defined in clause 5.15.5.2.1.

For all UEs that are allowed to use modes a), b) or c), the Access Stratum Connection Establishment NSSAI Inclusion Mode should be the same over the same Registration Areas.The UE shall store and comply to the required behaviour for a PLMN per Access Type as part of the network slicing configuration. The Serving PLMN AMF shall not instruct the UE to operate in any other mode than mode d) in 3GPP Access Type unless the HPLMN provides an indication that it is allowed to do so (i.e. if a PLMN allows behaviours a,b,c, then its UDM sends to the serving AMF an explicit indication that the NSSAI can be included in RRC as part of the subscription data).

The UE default mode of operation is the following:

– For 3GPP access the UE shall by default operate in mode d) unless it has been provided with an indication to operate in mode a), b) or c).

– For untrusted non-3GPP access the UE shall operate by default in mode b) unless it has been provided with an indication to operate in mode a), c) or d).

– For trusted non-3GPP access the UE shall operate by default in mode d) unless it has been provided with an indication to operate in mode a), b) or c).

– For W-5GAN access the 5G-RG shall operate by default in mode b) unless it has been provided with an indication to operate in mode a), c) or d).

An operator may pre-configure the UE to operate by default according to mode c) in the HPLMN (i.e. the UE by default includes NSSAI in the access stratum when it performs an Initial Registration and Mobility Registration Update with the HPLMN until the HPLMN changes the mode as described above).

5.15.10 Network Slice-Specific Authentication and Authorization

A serving PLMN or SNPN shall perform Network Slice-Specific Authentication and Authorization for the S-NSSAIs of the HPLMN or SNPN which are subject to it based on subscription information. The UE shall indicate in the Registration Request message in the UE 5GMM Core Network Capability whether it supports NSSAA feature. If the UE does not support NSSAA feature and if the UE requests any of these S-NSSAIs that are subject to Network Slice-Specific Authentication and Authorization, the AMF shall not trigger this procedure for the UE and they are rejected for the PLMN or SNPN. If the UE supports NSSAA feature and if the UE requests any of these S-NSSAIs that are subject to Network Slice-Specific Authentication and Authorization, they are included in the list of Pending NSSAI for the PLMN or SNPN, as described in clause 5.15.5.2.1.

If a UE is configured with S-NSSAIs, which are subject to Network Slice-Specific Authentication and Authorization, the UE stores an association between the S-NSSAI and corresponding credentials for the Network Slice-Specific Authentication and Authorization.

NOTE 1: How the UE is aware that an S-NSSAI is subject to Network Slice-Specific Authentication and Authorization (e.g., based on local configuration) is out of scope of this specification.

The UE may support remote provisioning of credentials for NSSAA, specified in clause 5.39.

A UE that supports to be provisioned with the credentials used for NSSAA over UP remote provisioning shall use connectivity over an S-NSSAI/DNN which can access the provisioning server to establish a PDU session for remote provisioning as defined in clause 5.39.

NOTE 2: The credentials for Network Slice-Specific Authentication and Authorization are not specified.

To perform the Network Slice-Specific Authentication and Authorization for an S-NSSAI, the AMF invokes an EAP- based Network Slice-Specific authorization procedure documented in clause 4.2.9 of TS 23.502 [3] (see also TS 33.501 [29]) for the S-NSSAI. When an NSSAA procedure is started and is ongoing for an S-NSSAI, the AMF stores the NSSAA status of the S-NSSAI as pending and when the NSSAA is completed the S-NSSAI becomes either part of the Allowed NSSAI or a Rejected S-NSSAI. The NSSAA status of each S-NSSAI, if any is stored, is transferred when the AMF changes.

This procedure can be invoked for a supporting UE by an AMF at any time, e.g. when:

a. The UE registers with the AMF and one of the S-NSSAIs of the HPLMN or SNPN which maps to an S-NSSAI in the Requested NSSAI is requiring Network Slice-Specific Authentication and Authorization (see clause 5.15.5.2.1 for details), and the S-NSSAI in the Requested NSSAI can be added to the Allowed NSSAI by the AMF once the Network Slice-Specific Authentication and Authorization for the HPLMN or SNPN S-NSSAI succeeds; or

b. The Network Slice-Specific AAA Server triggers a UE re-authentication and re-authorization for an S-NSSAI; or

c. The AMF, based on operator policy or a subscription change, decides to initiate the Network Slice-Specific Authentication and Authorization procedure for a certain S-NSSAI which was previously authorized.

In the case of re-authentication and re-authorization (b. and c. above) the following applies:

– If S-NSSAIs that are requiring Network Slice-Specific Authentication and Authorization map to S-NSSAIs that are included in the Allowed NSSAI for each Access Type, AMF selects an Access Type to be used to perform the Network Slice Specific Authentication and Authorization procedure based on network policies.

– If the Network Slice-Specific Authentication and Authorization for some S-NSSAIs mapped to some S-NSSAIs in the Allowed NSSAI is unsuccessful, the AMF shall update the Allowed NSSAI for each Access Type to the UE via UE Configuration Update procedure.

– If the Network Slice-Specific Authentication and Authorization fails for all S-NSSAIs mapped to all S-NSSAIs in the Allowed NSSAI, the AMF determines a new Allowed NSSAI including default S-NSSAI(s). If no default S-NSSAI(s) could be added, the AMF shall execute the Network-initiated Deregistration procedure described in clause 4.2.2.3.3 of TS 23.502 [3] and shall include in the explicit De-Registration Request message the list of Rejected S-NSSAIs, each of them with the appropriate rejection cause value.

After a successful or unsuccessful UE Network Slice-Specific Authentication and Authorization, the UE context in the AMF shall retain the authentication and authorization status for the UE for the related specific S-NSSAI of the HPLMN or SNPN while the UE remains RM-REGISTERED in the PLMN or SNPN, so that the AMF is not required to execute a Network Slice-Specific Authentication and Authorization for a UE at every Periodic Registration Update or Mobility Registration procedure with the PLMN or SNPN.

A Network Slice-Specific AAA server may revoke the authorization or challenge the authentication and authorization of a UE at any time. When authorization is revoked for an S-NSSAI that maps to an S-NSSAI in the current Allowed NSSAI for an Access Type, the AMF shall provide a new Allowed NSSAI to the UE and trigger the release of all PDU sessions associated with the S-NSSAI, for this Access Type.

The AMF provides the GPSI of the UE related to the S-NSSAI to the AAA Server to allow the AAA server to initiate the Network Slice-Specific Authentication and Authorization, or the Authorization revocation procedure, where the current AMF serving the UE needs to be identified by the system, so the UE authorization status can be challenged or revoked.

The Network Slice-Specific Authentication and Authorization requires that the UE Primary Authentication and Authorization of the SUPI has successfully completed. If the SUPI authorization is revoked, then also the Network Slice-Specific authorization is revoked.

5.15.11 Network Slice Admission Control

5.15.11.0 General

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

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

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

– If the network is configured with a single service area, there is a single NSACF configured with the maximum number of UEs per network slice and/or the maximum number of PDU Sessions per network slice, which are valid in the network.

– If the network is configured with multiple service areas, an NSACF may be deployed on a service area basis, which can be one NSACF instance or one NSACF Set. There are multiple NSACF architecture options:

– – Option 1: non-Centralized Single tier NSACF architecture. In this architecture, independent NSACFs are deployed in every service area. There is no interaction between the NSACFs deployed in different service area. Each NSACF is configured with the maximum number of UEs per network slice and/or the maximum number of PDU Sessions which are valid in the service area (see clause 5.15.11.1 for more details).

– Option 2: Centralized architecture. In this architecture, a single centralized NSACF is deployed in the network to handle admissions in all service areas. The centralized NSACF is configured with the total number of UEs per network slice and the maximum number of PDU Sessions for the entire PLMN. NSAC Requests from AMF or SMF to the single centralized NSCAF in this case includes the service area of the NF consumer.

NOTE 1: It is possible to configure in the centralized architecture the maximum number of registered UEs and/or the number of PDU sessions per service area if required by the operator.

– Option 3: Hierarchical NSACF architecture is deployed in the network. There are two roles of NSACF and interaction between them may be required (see clause 5.15.11.1a for more details):

– Primary NSACF, controls and distributes of the maximum number of UEs and/or the maximum number of PDU Sessions for other NSACF(s) deployed in different service Area. The Primary NSACF handles overall NSAC for an S-NSSAI at the global level (i.e. it is ultimately responsible for the NSAC for an S-NSSAI).

‐ NSACF is responsible for one or multiple Service Area. And one Service area is only associated with one NSACF instance or one NSACF Set.

NOTE 2: When multiple NSACFs are deployed, how the maximum number of UEs per network slice and the maximum number of PDU Sessions per network slice is distributed (by OAM for Option 1 and by the primary NSAF for Option 3) among multiple NSACFs, is implementation specific.

NOTE 3: When multiple NSACFs are deployed based on option 1, the UE moves to new service area with a different NSACF, and if the number of UE or PDU Sessions in the target NSACF has reached the maximum number, whether the session continuity can be guaranteed is left to implementation.

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

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

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

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

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

5.15.11.1 Network Slice Admission Control for maximum number of UEs

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

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

NOTE 1: Early Admission Control (EAC) mode is applicable for Number of UEs per network slice admission control. The use of EAC in relation to the number of registered UEs is described in clauses 4.2.11.2 and 4.2.11.3 of TS 23.502 [3].

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

NOTE 2: For example, if the NSACF is configured to apply NSAC for 3GPP Access Type only, the NSACF counts registration via 3GPP access type only. If the NSACF is configured to apply NSAC for both Access Types, and the UE newly registers via 3GPP access while the UE is already registered via non-3GPP access (or vice versa), the NSACF updates the UE ID entry with both 3GPP Access Type and non-3GPP Access Type and the NSACF may count the UE once or twice based on its policy.

5.15.11.2 Network Slice Admission Control for maximum number of PDU sessions

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

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

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

NOTE 1: For MA PDU Session, the SMF provides the Access Type to NSACF when the user plane connection is about to be established or released in the corresponding access network. With this, the SMF provides one or two Access Types for the MA PDU Session in the same request message to the NSACF. The NSACF can reject a single or both Access Types depending on the applicability of the Access Type for the NSAC.

NOTE 2: I-SMF does not interact with NSCAF.

5.15.11.3 Network Slice Admission Control for Roaming

In the case of roaming, depending on operator’s policy, a roaming agreement or an SLA between the VPLMN and the HPLMN, NSAC of roaming UEs is performed by the VPLMN or HPLMN. The following principles apply:

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

– Each S-NSSAI of the HPLMN that is subject to NSAC is mapped to a corresponding S-NSSAI of the VPLMN subject to NSAC, depending on VPLMN operator’s policy and the configuration.

– For NSAC for the maximum number of UEs for S-NSSAI of the HPLMN, a NSACF in the VPLMN can be configured with the maximum number of allowed roaming UEs per mapped S-NSSAI of the HPLMN for a S-NSSAI of the HPLMN that is subject to NSAC. In such a case, the AMFs trigger a request to a NSACF of the VPLMN.

– For NSAC for the maximum number of PDU Sessions for S-NSSAI of the HPLMN, a NSACF in the VPLMN can be configured with the maximum number of allowed PDU Sessions in LBO mode per mapped S-NSSAI of the HPLMN for a S-NSSAI of the HPLMN that is subject to NSAC. In such a case, the anchor SMF in the VPLMN triggers a request to a NSACF of the VPLMN.

– For NSAC for the maximum number of UEs for S-NSSAI of the VPLMN, AMFs trigger a request to a NSACF of the VPLMN to perform NSAC based on the S-NSSAI of the VPLMN subject to NSAC. The NSACF of the HPLMN is not involved.

– For NSAC for the maximum number of PDU Sessions for S-NSSAI of the VPLMN in the LBO roaming case, the SMF triggers a request to a NSACF of the VPLMN to perform NSAC based on the S-NSSAI of the VPLMN subject to NSAC. The NSACF of the HPLMN is not involved.

‐ The AMF or SMF (in LBO roaming case) in the VPLMN provides both the S-NSSAI in the VPLMN and the corresponding mapped S-NSSAI in the HPLMN to the NSACF in the VPLMN. The NSACF in the VPLMN performs NSAC for both S-NSSAI of the VPLMN and the corresponding mapped S-NSSAI of the HPLMN based on the SLA between the VPLMN and the HPLMN.

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

– For PDU sessions in the home-routed roaming case, the SMF in the HPLMN performs NSAC for the S-NSSAI(s) subject to NSAC.

NOTE: The NSAC for maximum number PDU session in LBO mode and maximum number of roaming UEs when the NSAC is managed by a NSACF in the HPLMN is not supported in this Release of the specification.

5.15.11.4 Network Slice status notifications and reports to a consumer NF

A consumer NF (e.g. AF) can subscribe with the NSACF for Network Slice status notifications and reports. Upon such subscription, the NSACF can provide event based notifications and reports to the consumer NF (e.g. to AF via NEF) related to the current number of UEs registered for a network slice or the current number of PDU Sessions established on a network slice.

5.15.11.5 Support of Network Slice Admission Control and Interworking with EPC

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

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

– For NSAC for number of UEs, if the UE identity is already included in the list of UE IDs registered with a network slice, or the UE identity is not included in the list of UE IDs registered with a network slice and the current number of UE registration did not reach the maximum number, the NSACF responds to the SMF+PGW-C with the information that the network slice is available. The NSACF includes the UE identity in the list of UE IDs if not already on the list and increases the current number of UE registration. Otherwise, the NSACF returns a response indicating that the maximum number with the network slice has been reached.

– For NSAC for number of PDU Sessions, if the current number of PDU sessions is below the maximum number, the NSACF responds to the SMF+PGW-C with the information that the network slice is available. The NSACF increases the current number of PDU sessions. Otherwise, the NSACF returns the response indicating that the maximum number with the network slice has been reached.

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

NOTE 1: As an implementation option, if the APN is mapped to more than one S-NSSAI and the first selected S-NSSAI is not available (e.g. either current number of UE registration reached maximum or current number of PDU sessions reached maximum), then based on the operator policy the PGW-C+SMF can try another mapped S-NSSAI for the PDN connection establishment procedure.

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

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

NOTE 2: The SMF+PGW-C determines the Access Type based on the RAT type parameter in the PMIP or GTP message received from the ePDG; or alternatively it can internally determine the Access Type based on the source node (e.g. SGW) sending the request for the PDN Connection establishment.

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

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

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

NOTE 3: NSAC in EPC is not performed for the attachment without PDN connectivity.

If EPS counting is not required for a network slice, the NSAC for maximum number of UEs and/or for maximum number of PDU Sessions per network slice is performed when the UE moves from EPC to 5GC, i.e. when the UE performs mobility Registration procedure from EPC to 5GC (NSAC for maximum number of UEs per network slice) and/or when the PDN connections are handed over from EPC to 5GC (NSAC for maximum number of PDU Sessions per network slice). The SMF+PGW-C is configured with the information indicating the network slice is subject to NSAC only in 5GS. The PDN connection interworking procedure is performed as described in clause 5.15.7.1. Mobility from EPC to 5GC does not guarantee all active PDU Session(s) can be transferred to the 5GC in certain circumstances when either the current number of UE registration or the current number of PDU sessions would exceed the maximum number when the UE moves from EPC to 5GC.

NOTE 4: Given that session continuity is not guaranteed when EPS counting is not required, it is recommended for services which require the session continuity to support EPS counting.

NOTE 5: When multiple NSACFs are deployed and if the number of UE in target NSACF has reached the maximum number, whether session continuity can be guaranteed is left to implementation.

5.15.12 Support of subscription-based restrictions to simultaneous registration of network slices

5.15.12.1 General

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

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

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

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

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

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

NOTE : An HPLMN enabling support of subscription-based restrictions to simultaneous registration of network slices for a Subscriber, can set the subscribed S-NSSAI(s) already in the subscription information before the NSSRG information was added to the subscription information, to have the same NSSRGs defined for the default S-NSSAI(s) if it has to continue to support the same service behaviour for these S-NSSAIs.

5.15.12.2 UE and UE configuration aspects

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

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

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

NOTE: In Requested NSSAI across all Access Type(s), the UE needs to include S-NSSAIs that share at least one common NSSRG.

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

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

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

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

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

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

– a supporting UE with an updated configuration including the up-to-date NSSRG information for the S-NSSAIs in the Configured NSSAI as described above.

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

5.15.13 Support of data rate limitation per Network Slice for a UE

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

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

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

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

NOTE: The PCF for the PDU Session may in addition be configured to monitor the data rate per Network Slice for a UE and to strengthen or relax the traffic restrictions for individual PDU Sessions or PCC rules accordingly, as described in TS 23.503 [45] clause 6.2.1.9.

5.15.14 Network Slice AS Groups support

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

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

NOTE: If the NSAGs for the PLMN and equivalent PLMNs have different associations to S-NSSAIs, then the AMF includes the list of TAIs in the NSAG information.

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

– the UE receives new NSAG information in a Registration Accept message or UE Configuration Command message in this PLMN or SNPN; or

– the UE receives a Configured NSSAI without any NSAG information in this PLMN or SNPN.

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

– The UE should be able to store the NSAG information for at least the Registered-PLMN and equivalent PLMNs, or the Registered-SNPN and equivalent SNPNs.

– The Registered-PLMN can provide NSAG information to the UE for the PLMN and the equivalent PLMNs, and the Registered-SNPN can provide NSAG information to the UE for the SNPN.

– There can be at most 32 NSAGs configured in the UE at a time for a PLMN or SNPN.

– At most 4 NSAGs can have an optional TAI associated with it.

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