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

Content for  TS 23.501  Word version:  19.2.0

Top   Top   Up   Prev   Next
1…   3…   4.2.3   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.2.15…   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.15.11…   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.32.6…   5.33…   5.34…   5.35…   5.38…   5.43…   5.49…   6…   6.3…   6.3.8…   7…   7.2…   8…   8.2.4   8.2.5…   8.3…   A…   D…   E…   F   G…   G.3   G.4…   H…   J   K…   M…   N…   O…   P…   S…   T… 
5.15 Network slicing  5.15.1 General  5.15.2 Identification and selection of a Network Slice: the S-NSSAI and the NSSAI  5.15.3 Subscription aspects  5.15.4 UE NSSAI configuration and NSSAI storage aspects  5.15.5 Detailed Operation Overview  5.15.6 Network Slicing Support for Roaming  5.15.7 Network slicing and Interworking with EPS  5.15.8 Configuration of Network Slice support and availability in a PLMN  5.15.9 Operator-controlled inclusion of NSSAI in Access Stratum Connection Establishment  5.15.10 Network Slice-Specific Authentication and Authorization 
...

 

5.15  Network slicing  p. 264

5.15.1  General  p. 264

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;
  • 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.
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, the number of UEs with at least one PDU Session/PDN Connection per network slice in the case of EPC interworking 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/TNGF supporting a set of slice(s) is described in clause 6.3.6 and clause 6.3.12 respectively.
The support of Network Slice usage control is described in clause 5.15.15.
Support of Optimized handling of temporarily available network slices is described in clause 5.15.16. It also covers aspects related to graceful release of network slices connectivity during slice decommissioning.
The Partial Network Slice support in a Registration Area is described in clause 5.15.17.
Support for Network Slices with Network Slice Area of Service not matching deployed Tracking Areas is described in clause 5.15.18.
Support of Network Slice Replacement is described in clause 5.15.19.
Up

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

5.15.2.1  General  p. 266

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) 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). Further information for slice replacement is described in clause 5.15.19.
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, Allowed NSSAI or a Partially Allowed NSSAI. There can be at most eight S-NSSAIs in Allowed NSSAI and Requested NSSAI sent in signalling messages between the UE and the Network. There can be at most seven S-NSSAIs in the Partially Allowed NSSAI and at most seven S-NSSAIs rejected partially in the RA and the sum of S-NSSAIs in the Allowed NSSAI and the Partially Allowed NSSAI shall be at most eight. 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.
Up

5.15.2.2  Standardised SST values  p. 267

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
eMBB1Slice suitable for the handling of 5G enhanced Mobile Broadband.
URLLC2Slice suitable for the handling of ultra- reliable low latency communications.
MIoT3Slice suitable for the handling of massive IoT.
V2X4Slice suitable for the handling of V2X services.
HMTC5Slice suitable for the handling of High-Performance Machine-Type Communications.
HDLLC6Slice suitable for the handling of High Data rate and Low Latency Communications.
Up

5.15.3  Subscription aspects  p. 267

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.
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.
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 aspects  p. 268

5.15.4.1  General  p. 268

5.15.4.1.1  UE Network Slice configuration  p. 268
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.
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 following applies:
  • In the non-roaming case and if the Serving PLMN ID is the same as the PLMN ID of the SUPI, the network shall not provide any mapped S-NSSAI to the UE with the Configured NSSAI.
  • In the non-roaming case and if the Serving PLMN ID is not the same as the PLMN ID of the SUPI, when the Configured NSSAI of Serving PLMN is provided to the UE the network shall provide the mapped S-NSSAI(s) of the HPLMN to the UE if different values are used for S-NSSAI in Serving PLMN and mapped S-NSSAI in HPLMN.
  • In the roaming case, the AMF shall provide to the UE the mapping of each S-NSSAI of the Configured NSSAI for the Serving PLMN to the corresponding S-NSSAI values of the HPLMN when providing NSSAI information, as described in TS 24.501.
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 a Default Configured NSSAI associated with the SUPI. The UE may be provisioned/updated by the HPLMN with a Default Configured NSSAI, determined by the UDM in the HPLMN, by using the UE Parameters Update via UDM Control Plane procedure defined in clause 4.20 of TS 23.502. If the HPLMN configures a UE with the Default Configured NSSAI, each S-NSSAI in the Default Configured NSSAI shall also be one of the Subscribed S-NSSAI(s). If the Subscribed S-NSSAI(s) which are also present in the Default Configured NSSAI are updated (i.e. a Subscribed S-NSSAI is added or removed from the UE subscription or a Subscribed S-NSSAI is added to (or removed from) the Default Configured NSSAI), 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 except a case when Alternative S-NSSAI(s) that are not subscribed S-NSSAI(s) are temporarily used and provided to the UE in the Configured NSSAI as described in clause 5.15.19.
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 Partially 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 or Partially Allowed NSSAI, the AMF shall provide the UE with the new Allowed NSSAI or Partially 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 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 or Partially 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 from the AMF, one or more rejected S-NSSAIs with cause and validity of rejection. An S-NSSAI may be rejected:
  • for the entire PLMN;
  • for the current Registration Area; or
  • partially in the current Registration Area. Such S-NSSAI rejected partially in the current Registration area is associated with a list of TAs where the S-NSSAI is not supported.
The AMF may also reject the use of an S-NSSAI due to congestion as described in clause 5.19.7.4.
While the UE 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 the UE 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.
While the UE remains RM-REGISTERED in the PLMN, the UE shall not re-attempt to register to an S-NSSAI rejected partially in the RA until the UE moves into a TA which is not part of the list of TAs associated with the S-NSSAI.
The S-NSSAIs that the UE provides in the Requested NSSAI which are neither in the Allowed NSSAI nor in the Partially 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:
    • 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, a Partially Allowed NSSAI received in a Registration Accept message or a UE Configuration Update Command message applies to the current Registration Area. The UE stores the Partially Allowed NSSAI in the same way as described for the Allowed NSSAI (see also clause 5.15.17).
  • 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.
  • If received, an S-NSSAI rejected partially in the RA 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 (see also clause 5.15.17).
  • If received, the Pending NSSAI shall be stored in the UE as described in TS 24.501.
  • If received, the S-NSSAI validity time information shall be stored in the UE in the UE as described in TS 24.501.
  • If received, the S-NSSAI location availability information shall be stored in the UE as described in TS 24.501.
  • If received, the mapping of old S-NSSAI to the Alternative S-NSSAI and associated Access Type shall be stored in the UE as described in TS 24.501.
UE configuration to guide UE selection of a N3IWF/TNGF that supports the S-NSSAIs needed by the UE is defined in clause 6.3.6 and clause 6.3.12 respectively.
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 HPLMN  p. 271
For the roaming case, 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, as defined in clause 6.1.2.2.1 of TS 23.503 and to the corresponding S-NSSAI from the Allowed NSSAI.
In the non-roaming case and if the Serving PLMN ID is the same as the PLMN ID of the SUPI, the network shall not provide any mapped S-NSSAI to the UE with the Allowed NSSAI. In the non-roaming case and if the Serving PLMN ID is not the same as the PLMN ID of the SUPI, the network shall provide the mapped S-NSSAI of the HPLMN to the UE with the Allowed NSSAI if different values are used for S-NSSAI in Serving PLMN and mapped S-NSSAI in HPLMN.
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.
If the AMF provides Partially Allowed NSSAI to the UE, in roaming case the AMF may provide the mapping information of each S-NSSAI of the Partially Allowed NSSAI to the corresponding HPLMN S-NSSAI as described in clause 5.15.17.
Up

5.15.4.2  Update of UE Network Slice configuration  p. 271

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, UE Configuration Update procedure.
If an S-NSSAI is to be stopped to be used, e.g. due to the network slice is to be deleted as described in TS 28.541, the AMFs may reject UE requests for the S-NSSAI based on the OAM state before the network slice becomes unavailable. The AMF may based on operator policies (e.g. when there is no timing information related to the termination or the AMF or UE does not support the timing information as described in in clause 5.15.16), release PDU Sessions associated with the S-NSSAI and remove the S-NSSAI from e.g. the Allowed NSSAI and the Configured NSSAI before the Network Slice becomes unavailable. The AMF may use the timing information as described in clause 5.15.16 if it supports this feature and set validity time of the S-NSSAI accordingly.
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.
The AMF may provide the UE with the mapping of old S-NSSAI to the Alternative S-NSSAI if the UE has indicated support for the feature as part of the registration request, see clause 5.15.19.
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 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 Overview  p. 272

5.15.5.1  General  p. 272

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  p. 272

5.15.5.2.1  Registration to a set of Network Slices  p. 272
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.
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 the UE is roaming, 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, 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, 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 discovery and selection of the NSSF is defined in clause 6.3.28.
  • 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).
(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 (see clause 5.15.3) or not available at the current UE's Tracking Area (see clause 5.15.8). If the AMF is configured with a local policy to include in the Allowed NSSAI subscribed S-NSSAIs that are not in the Requested NSSAI and some of the Subscribed S-NSSAIs are not supported by the AMF, the AMF queries the NSSF (see (B) below).
    • 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 and any additional S-NSSAI added due to local policy as described below, the AMF remains the serving AMF for the UE. The Allowed NSSAI is then determined by taking into account 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. The AMF based on local policy may determine to include in the Allowed NSSAI additional Subscribed S-NSSAIs e.g. Subscribed S-NSSAIs not marked as default and/or Subscribed S-NSSAIs that were not provided in the Requested NSSAI (See NOTE 4). 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. If the AMF has pending NSSAI for the UE then the AMF includes pending NSSAI in the Requested NSSAI.
  • 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.
    • It determines the Allowed NSSAI(s) for the applicable Access Type, by taking into account 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 and taking also into account local policy in the NSSF that may determine to include in the Allowed NSSAI additional Subscribed S-NSSAIs e.g. Subscribed S-NSSAIs not marked as default and/or Subscribed S-NSSAIs that were not provided in the Requested NSSAI (see NOTE 7). 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, 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 shall return a Configured NSSAI when receiving Default Configured NSSAI Indication from the AMF.
    • 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.
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), 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 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 UE  p. 278
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. 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. 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 the AMF determines that the S-NSSAI in the Allowed NSSAI is replaced with Alternative S-NSSAI over an Access Type, the AMF provides the mapping of old S-NSSAI to the Alternative S-NSSAI to the UE over the same Access Type (as described in clause 5.15.19).
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 and the Network Slice Replacement is not used (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. If the Network Slice Replacement is used, the AMF performs Network Slice Replacement as described in clause 5.15.19.
  • 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.
If the AMF supports the Network Slice Replacement feature and is configured to use the NSSF to trigger the Network Slice Replacement, the AMF subscribes with the NSSF for notifications when any of the S-NSSAIs served by the AMF (e.g. the S-NSSAI in the Serving PLMN and the HPLMN S-NSSAI in roaming case) has to be replaced as described in clause 5.15.19.
If the AMF supports the Network Slice Instance Replacement and configured to use Network Slice Instance Replacement, the AMF subscribes with the NSSF for notifications when a Network Slice instances served by the AMF is congested or no longer available as described in clause 5.15.20.
The AMF may perform Network Slice Replacement for the PDU Session as described in clause 5.15.19.
Up
5.15.5.2.2a  AF Requested modification of the Set of Network Slice(s) for a UE |R19|  p. 280
In non-roaming cases, an authorized AF or an AF subject to authorization via the NEF, may request to replace a certain S-NSSAI (Replaced S-NSSAI) for a UE with another S-NSSAI (Alternative S-NSSAI) which is part of the UE subscription. The request in either case is sent to the PCF for the UE handling the impacted subscriber. Similarly, an authorized AF or an AF subject to authorization via the NEF, may request to terminate the replacement then request to use the Replaced S-NSSAI instead of the Alternative S-NSSAI for a UE again. The AF may subscribe to Notification on the outcome of the Network Slice Replacement.
Only a single AF can request the modification of the Set of Network Slice(s) for one replaced S-NSSAI.
The PCF for the UE based on operator policies considers the AF request. Consequently the PCF for the UE triggers the Network Slice Replacement at the AMF as defined in TS 23.503.The PCF sends Slice replacement management in the access and mobility management policies to the AMF per implicitly subscription, as described in TS 23.503. The Slice replacement management includes the Replaced S-NSSAI and the corresponding Alternative S-NSSAI as provided in the AF request, PCRT to request Notification on outcome of Network Slice Replacement request, together with a Network Slice Replacement Type. The Network Slice Replacement Type indicates that the Network Slice Replacement is requested by AF. The AMF handles the procedure as following:
  • The AMF shall not handle the Network Slice Replacement procedure as described in clause 5.15.19.
  • If the Alternative S-NSSAI is not within the UE subscription, or is not supported in the UE Registration Area, the AMF shall notify the PCF that the Network Slice Replacement is not triggered with a cause value. The PCF further notify the AF.
  • If the Alternative S-NSSAI is within the UE subscription and is supported in the UE Registration Area, the AMF includes the Alternative S-NSSAI in the Allowed NSSAI (if not present).
  • The AMF removes the Replaced S-NSSAI from the Allowed NSSAI and add the Replaced S-NSSAI into the Rejected S-NSSAI by a UE Configuration Update procedure.
  • The AMF releases the PDU sessions that were using the Replaced S-NSSAI.
  • The AMF stores in the UE context the access and mobility management policy information as received from PCF and transfer to new AMF during inter AMF mobility.
The trusted AF or a NEF may send request to PCF for the UE to stop the Network Slice Replacement. In this case the PCF for the UE sends access and mobility management policies to the AMF, as described in TS 23.503. The AMF remove the Replaced S-NSSAI from the Rejected S-NSSAI by a UE Configuration Update procedure. The UE may request to register the Replaced S-NSSAIs again next time the UE sends a Requested NSSAI.
Up
5.15.5.2.3  AMF Re-allocation due to Network Slice(s) Support  p. 280
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.
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  p. 281

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 clause 6.6.2 of TS 23.503. 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 clause 6.6.2 of TS 23.503.
  • 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.
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 an S-NSSAI (if the UE does not provide an S-NSSAI for the PDU session establishment) and a Network Slice instance, based on load level and/or Observe Service Experience and/or Dispersion analytics from NWDAF, as described in TS 23.288.
The discovery and selection of the NSSF is defined in clause 6.3.28.
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 AMF may select the SMF among the set of the SMF instance(s) returned by the NRF or locally configured in the AMF, based on network data analytics (NF load, etc.) from the NWDAF as described in TS 23.288. 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.
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.
In non-roaming case, if the Serving PLMN ID is not the same as the PLMN ID of the SUPI and a mapped S-NSSAI value of the HPLMN is present in the Allowed NSSAI, the procedures as defined in clause 4.23.5 of TS 23.502 is used for PDU Session Management, with the following differences:
  • In PDU Session Establishment procedure the AMF selects the SMF according to the S-NSSAI of the mapped S-NSSAI value of the HPLMN and selects I-SMF according to the S-NSSAI of the S-NSSAI value of the Serving PLMN and provides the S-NSSAI of the Serving PLMN and the mapped S-NSSAI of the HPLMN as received from the UE to the selected (I-)SMF.
Up

5.15.6  Network Slicing Support for Roaming  p. 282

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.
    For the home routed case, the AMF or NSSF may select an S-NSSAI (if the UE does not provide an S-NSSAI for the PDU session establishment) and a Network Slice instance, based on load level and/or Observe Service Experience and/or Dispersion analytics of the VPLMN and/or that of the HPLMN from NWDAF as described in TS 23.288.
  • 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:
    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 AMF may select the V-SMF and the H-SMF based on network data analytics (NF load, etc.) of the VPLMN and that of the HPLMN from the NWDAF as described in TS 23.288. 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 and, for SMF in clause 4.3.2.2.3.3 of TS 23.502.
  • If the serving AMF supports the Network Slice Replacement feature and is configured to use the NSSF for Network Slice Replacement triggering, the AMF subscribes with the NSSF of the VPLMN for notifications when an HPLMN S-NSSAI needs to be replaced with an Alternative S-NSSAI, in addition to notifications for the Serving PLMN S-NSSAIs. The NSSF of the VPLMN shall subscribe with the NSSF of the HPLMN for notifications when an HPLMN S-NSSAI needs to be replaced with an Alternative S-NSSAI.
  • If the serving AMF support the Network Slice Instance Replacement and configured to use Network Slice Instance Replacement, the AMF subscribes with the NSSF of the VPLMN for notifications when a Network Slice instance is congested or no longer available as described in clause 5.15.20. The NSSF of the VPLMN shall subscribe with the NSSF of the HPLMN for notifications when the Network Slice instance is congested or no longer available.
Up

5.15.7  Network slicing and Interworking with EPS  p. 283

5.15.7.1  General  p. 283

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 . A UE that supports selecting S-NSSAI based on URSP rules while in EPS and that is provisioned with URSP rules may select, if available, an S-NSSAI for the APN based on evaluation of the Traffic descriptor as defined in clause 4.4.2 of TS 24.526. The selected S-NSSAI and PDU Session ID are sent to the SMF+PGW-C via PCO. As described in clause 4.11.0a.5 of TS 23.502, 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, whether interworking with EPS is supported for the DNN and S-NSSAI in the Session Management Subscription data and the operator policy by the SMF+PGW-C, (e.g. based on a combination of SMF+PGW-C address and APN and taking into account the S-NSSAI provided by the UE if any) 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 take into account the S-NSSAI provided by the UE and 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.
If the PCO received by the SMF+PGW-C contains an S-NSSAI that is not supported by the SMF+PGW-C, then the SMF+PGW-C may determine another SMF+PGW-C that supports the DNN and the S-NSSAI received in the PCO, based on operator policies and follows the PGW selection in case of PGW mismatch with network slice subscribed by the UE as specified in clause 7.2.1 and clause 7.2.2 of TS 29.274.
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.
Up

5.15.7.2  Idle mode aspects  p. 284

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.
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  p. 284

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 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. 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.7.4  Support of Network Slice usage control and Interworking with EPC |R18|  p. 285

As described in clause 5.15.15, if Network Slice usage control is required for a PDN Connection, the SMF+PGW-C configures PDU Session inactivity timer to the UPF+PGW-U. When the SMF+PGW-C receives inactivity report of the PDN Connection from the UPF+PGW-U, the SMF+PGW-C releases the PDN Connection.

5.15.8  Configuration of Network Slice support and availability in a PLMN  p. 285

A Network Slice may be supported in the whole PLMN or in one or more Tracking Areas of the PLMN. A Network Slice is supported within a TA if the 5G-AN has been configured to support the S-NSSAI in the TA.
Network Slices are defined to be available within an NS-AoS when the Network Slice is supported in the set of TAs which the NS-AoS comprises and more than zero resources are allocated to the Network Slice in the NG-RAN cells of the NS-AoS. An NS-AoS can be defined on a per cell level granularity when the NS-AoS is not matching deployed Tracking Areas as defined in clause 5.15.18.
The availability of a Network Slice S-NSSAI in an NS-AoS requires the support of the S-NSSAI in the involved NFs and in the NG-RAN in the TAs which the NS-AoS comprises. Hence, the cells of a TA need to be configured to support a S-NSSAI if the S-NSSAI needs to be available in at least a cell of the TA. A Network Slice is considered available in a TA if the Network Slice is supported within the TA and available in all cells of the TA. 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 UE can receive, for a Network Slice where the NS-AoS does not match the whole set of cells in one or more TAs, S-NSSAI location availability information as described in clause 5.15.18.
The support 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|  p. 285

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-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).
Up

5.15.10  Network Slice-Specific Authentication and Authorization |R16|  p. 286

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.
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.
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 (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 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:
  1. 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
  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 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 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.
Up

Up   Top   ToC