Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.501  Word version:   16.4.0

Top   Up   Prev   Next
1…   3…   4…   4.2.4   4.2.5…   4.2.8…   4.2.8.2.2   4.2.8.2.3…   4.2.8.4…   4.2.9…   4.3…   4.3.3   4.3.4   4.3.5   4.4…   4.4.6…   4.4.8   5…   5.3…   5.3.3…   5.4…   5.5…   5.6…   5.6.7…   5.7…   5.7.2…   5.7.3…   5.7.4   5.7.5…   5.8…   5.8.2.11…   5.9…   5.10…   5.11…   5.15…   5.16…   5.17…   5.18…   5.19…   5.21…   5.22…   5.27…   5.28…   5.29…   5.30…   5.31…   5.32…   5.33…   5.34…   5.35…   6…   6.3…   7…   7.2…   8…   8.2.4   8.2.5…   8.3…   A…   D…   E…   F   G…   G.3   G.4…   J…

 

5.15  Network slicing
5.15.1  General
A Network Slice instance is defined within a PLMN 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;
  • 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 and TS 23.503.
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.
Up
5.15.2  Identification and selection of a Network Slice: the S-NSSAI and the NSSAIWord-p. 193
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 TS 23.503, clause 6.6.2) 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 (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.
Up
5.15.2.2  Standardised SST valuesWord-p. 194
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.
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.

NOTE:
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.
Up
5.15.3  Subscription aspects
The Subscription Information shall contain one or more S-NSSAIs i.e. Subscribed S-NSSAIs. Based on operator's policy, one or more Subscribed S-NSSAIs can be marked as a 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 associated AAA Server Address.
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 capable UEs to minimize overhead for signalling a large number of S-NSSAIs in Requested NSSAI in RRC and NAS via NB-IoT.
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.
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.
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.
Up
5.15.4  UE NSSAI configuration and NSSAI storage aspectsWord-p. 195
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.
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. 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 of TS 23.502.
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 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.
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, 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 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) 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.
Up
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 HPLMNWord-p. 197
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 and to the corresponding S-NSSAI from the Allowed NSSAI.
In roaming case, the UE may need to provide the mapping of S-NSSAIs values in the Requested NSSAI to the corresponding S-NSSAI values used in the HPLMN. 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.
Up
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 TS 23.502, clause 4.2.4 UE Configuration Update procedure.
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)), this results in updates to the Configured NSSAI for the HPLMN. 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), 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. 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 of TS 23.502.
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.
Up
5.15.5  Detailed Operation OverviewWord-p. 198
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 slice(s) to which the UE wishes to register.
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, 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.
NOTE 2:
In this release of the specifications the support of the continuation of PDU sessions upon mobility to a target 5GS PLMN or from EPS to the 5GS when neither the Configured NSSAI nor the Allowed NSSAI are available for the target PLMN, is not guaranteed.
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 PGW-C+SMF in 5GC:
  • As part of the Registration procedure described in TS 23.502, clause 4.2.2.2.2, or as part of the EPS to 5GS handover using N26 interface procedure described in clause 4.11.1.2.2 in TS 23.502, 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 PGW-C+SMF 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 3:
    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).
  • NOTE 4:
    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 PGW-C+SMF (in CM-CONNECTED state). 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 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. It 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), 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.
    • 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 5:
      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.
    • 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.
    • 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.
  • 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.
    • 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 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 6:
As there is a single distinct Registration Area for Non-3GPP access in a PLMN, the S-NSSAIs in the Allowed NSSAI for this Registration Area (i.e. for Non-3GPP access) are available homogeneously in the PLMN.
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 or, based on the UE Context in AMF, those S-NSSAIs for which Network Slice-Specific Authentication and Authorization 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.
The S-NSSAIs for which Network Slice-Specific Authentication and Authorization needs to be performed shall be included in the list of Pending S-NSSAIs. The UE shall not attempt re-registration with those S-NSSAIs included in the list of Pending S-NSSAIs, regardless of Access Type, until the Network Slice-Specific Authentication and Authorization procedure has been completed.
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 an empty Allowed NSSAI to the UE in the Registration Accept message. Upon receiving an empty Allowed NSSAI, 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 except emergency services (the AMF assigns the Tracking Areas of the Registration Area as a Non-Allowed Area).
Editor's note: Mechanisms to prevent the UE from waiting indefinitely for the completion of Slice-Specific Authentication and Authorization are defined in Stage 3 specifications.
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. 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. The AMF shall remove the mobility restriction if the Tracking Areas of the Registration Area were previously assigned as a Non-Allowed Area due to pending Network Slice-Specific Authentication and Authorization.
Once completed the Network Slice-Specific Authentication and 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 TS 23.502, clause 4.2.2.3.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.
Up
5.15.5.2.2  Modification of the Set of Network Slice(s) for a UEWord-p. 202
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, operational reasons (e.g. a Network Slice instance is no longer available or load level information for a 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 TS 23.502, clause 4.2.4. 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 Network Slices (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 Network Slices:
    • 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 TS 23.502 step 4 of clause 4.2.4.2. 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 are established PDU Session(s) 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(s) 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 in TS 23.502.
  • 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. 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 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. 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.
Up
5.15.5.2.3  AMF Re-allocation due to Network Slice(s) SupportWord-p. 204
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.
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 in TS 23.502.
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.
Up
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, 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, 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 TS 23.503, clause 6.6.2. 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. 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 TS 23.503, clause 6.6.2.
  • 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 TS 23.503, clause 6.6.2.
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 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 in TS 23.502.
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.
Up
5.15.6  Network Slicing Support for RoamingWord-p. 205
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 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.
  • In PDU Session Establishment procedure, the UE includes both:
    1. 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; the value of this S NSSAI is used in the HPLMN; and
    2. 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).
  • 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 and, for SMF in clause 4.3.2.2.3.3 of TS 23.502.
Up
5.15.7  Network slicing and Interworking with EPSWord-p. 206
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).
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 PGW-C+SMF via PCO. An S-NSSAI associated with the PDN connection is determined based on the operator policy by the PGW-C+SMF, e.g. based on a combination of PGW-C+SMF 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 PGW-C+SMF. If the PGW-C+SMF supports more than one S-NSSAI and the APN is valid for more than one S-NSSAI, the PGW-C+SMF should only select an S-NSSAI that is mapped to the subscribed S-NSSAIs of the UE. 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.
Up
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 PGW-C+SMF 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 TS 23.502, clause 4.23.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).
Up
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. 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. The PGW-C+SMF 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 TS 23.502, clause 4.23.2. 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.
Up
5.15.8  Configuration of Network Slice availability in a PLMNWord-p. 207
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) and TS 38.300). 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 and TS 38.300).
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.
Up
5.15.9  Operator-controlled inclusion of NSSAI in Access Stratum Connection Establishment [R16]
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) according to one of these modes:
  1. 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;
  2. 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;
  3. 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
  4. 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-AGF 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).
Up
5.15.10  Network Slice-Specific Authentication and Authorization [R16]Word-p. 208
A serving PLMN shall perform Network Slice-Specific Authentication and Authorization for the S-NSSAIs of the HPLMN 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. 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, 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:
The credentials for Network Slice-Specific Authentication and Authorization and how to provision them in the UE 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 TS 23.502, clause 4.2.9 (see also TS 33.501) 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, 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:
  1. The UE registers with the AMF and one of the S-NSSAIs of the HPLMN 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 can be added to the Allowed NSSAI by the AMF once the Network Slice-Specific Authentication and Authorization for the S-NSSAI succeeds; or
  2. The Network Slice-Specific AAA Server triggers a UE re-authentication and re-authorization for an S-NSSAI; or
  3. 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 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 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 in the Allowed NSSAI, the AMF shall execute the Network-initiated Deregistration procedure described in TS 23.502, clause 4.2.2.3.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 while the UE remains RM-REGISTERED in the PLMN, 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.
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 is 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.
Up

Up   Top   ToC