The Network Slice Admission Control Function (NSACF) monitors and controls the number of registered UEs per network slice and/or the number of PDU Sessions per network slice for the network slices that are subject to Network Slice Admission Control (NSAC). The NSACF is configured with the maximum number of UEs and/or the maximum number of PDU Sessions allowed to be served per S-NSSAI subject to NSAC. The NSACF is also configured with information indicating applicable access type(s) for the S-NSSAI (i.e. 3GPP Access Type, Non-3GPP Access Type, or both).
The NSACF also provides event-based Network Slice status notifications and reports to the consumer NFs (e.g. AF).
The NSACF may be responsible for one or more S-NSSAIs. For one S-NSSAI there may be one or multiple NSACFs deployed in a network (a PLMN or a SNPN) as follows:
If the network is configured with a single NSAC service area, there is a single NSACF configured with the maximum number of UEs per network slice and/or the maximum number of PDU Sessions per network slice, which are valid in the network.
If the network is configured with multiple NSAC service areas, an NSACF may be deployed on a NSAC service area basis, which can be one NSACF instance or one NSACF Set. There are three multiple NSAC architecture options:
Option 1: non-Hierarchal NSAC architecture. In this architecture, independent NSACFs are deployed in every NSAC service area. There is no interaction between the NSACFs deployed in different NSAC service areas. Each NSACF is configured with the maximum number of UEs per network slice and/or the maximum number of PDU Sessions which are valid in the NSAC service area (see clause 5.15.11.1 for more details).
Option 2: Centralized NSAC architecture. In this architecture, a single centralized NSACF is deployed in the network to handle admissions in all NSAC service areas. The centralized NSACF is configured with the total number of UEs per network slice and the maximum number of PDU Sessions for the entire PLMN. NSAC Requests from AMF or SMF to the single centralized NSCAF in this case includes the NSAC service area of the NF consumer if multiple NSAC service areas are deployed in PLMN.
Option 3: Hierarchical NSAC architecture is deployed in the network. There are two roles of NSACF and interaction between them may be required (see clause 5.15.11.1a for more details):
Primary NSACF, controls and distributes of the maximum number of UEs and/or the maximum number of PDU Sessions for other NSACF(s) deployed in different NSAC service Area. The Primary NSACF handles overall NSAC for an S-NSSAI at the global level (i.e. it is ultimately responsible for the NSAC for an S-NSSAI).
NSACF is responsible for one or multiple NSAC service Area. And one NSAC service area is only associated with one NSACF instance or one NSACF Set.
Subject to operator policy and national/regional regulations, the AMF may exempt UEs and the SMF may exempt PDU sessions from NSAC when the UE and/or PDU Session is used for Emergency service or for Critical and Priority services (e.g. MCX, MPS).
When the AMF receives a Registration Request for an Emergency Registration, or with a Registration Request with an Establishment Cause indicating a priority service (e.g. MCX, MPS) or when the AMF determines that there is a priority subscription (e.g. MPS, MCX) in the UDM, the AMF may accept the registration request without applying NSAC, i.e. the AMF triggers the NSAC procedure, but the response from the NSACF is ignored at the AMF.
When the SMF receives a PDU Session Establishment Request for an emergency PDU Session or a PDU Session Establishment Request with a priority header, the SMF may accept the PDU Session Establishment Request without applying NSAC, i.e. the SMF triggers the NSAC procedure, but the response from the NSACF is ignored at the SMF.
Alternatively, when NSAC is exempted for the UE and/or PDU Session, the AMF and the SMF skip the corresponding NSAC procedure, i.e. this UE (respectively PDU Session) is not counted towards the maximum number of UEs (respectively PDU Sessions).
The support of NSAC for the S-NSSAI used for onboarding as described in clause 5.30.2.10 is optional and subject to Onboarding Network operator policies. However, NSAC for S-NSSAI used for onboarding is not applicable to UEs that registered in ON-SNPN with Registration Type "SNPN Onboarding".
In the case of NSAC for maximum number of PDU Sessions, if the UE receives from the SMF a back-off timer associated with the reject cause set to 'Maximum number of PDU Sessions per S-NSSAI reached' for an Access Type, the UE shall not request the establishment of a PDU Session for this S-NSSAI on the indicated Access Type until the back-off timer expires.
The NSACF keeps track of the current number of UEs registered for a network slice so that it can ensure it does not exceed the maximum number of UEs allowed to register with the network slice. The NSACF also maintains a list of UE IDs registered with a network slice that is subject to NSAC. When an event related to a UE causes the current number of UEs registered with a network slice to increase, the NSACF first checks whether the UE Identity is already in the list of UEs registered with that network slice. If not, the NSACF checks whether the maximum number of UEs per network slice for that network slice has already been reached and if it has, the NSACF applies admission control policies.
The AMF triggers a request to NSACF for NSAC for maximum number of UEs when the UE's registration status for a network slice subject to NSAC is changing, i.e. during the UE Registration procedure in clause 4.2.2.2.2 of TS 23.502, UE Deregistration procedure in clause 4.2.2.3 of TS 23.502, Network Slice-Specific Authentication and Authorisation procedure in clause 4.2.9.2 of TS 23.502, AAA Server triggered Network Slice-Specific Re-authentication and Re-authorization procedure in clause 4.2.9.3 of TS 23.502, AAA Server triggered Slice-Specific Authorization Revocation in clause 4.2.9.4 of TS 23.502 and UE Configuration Update procedure in clause 4.2.4.2 of TS 23.502.
Since the UE may register or deregister for an S-NSSAI via 3GPP access and/or non-3GPP access as described in clause 5.15.5.2.1. The Allowed NSSAI for the access type may change while the UE is registering to a network. The AMF provides the Access Type to the NSACF when triggering a request to increase or decrease the current number of UEs registered with a S-NSSAI. The NSACF may take the Access Type into account for increasing and decreasing the number of UEs per network slice by storing the UE ID with the associated one or more Access Type(s), i.e. the NSACF is able to add or remove a registration for the UE ID for each Access Type and trigger the increase or decrease of the current number of UEs registered with a S-NSSAI based on a policy that takes the access type into account. If the Access Type provided by the AMF is not configured for NSAC in the NSACF, the NSACF always accepts the request from the AMF without increasing or decreasing the number of UEs. If the Access Type provided by the AMF is configured for NSAC in the NSACF and the maximum number is reached, the NSACF sends a reject response to the AMF including the access type.
In the hierarchal NSAC architecture, the NSACFs deployed in the service areas interacts with the primary NSACF when needed, and as explained below.
The main differences between the NSACFs deployed in a non-hierarchal architecture and NSACFs deployed in a hierarchal architecture is as follows:
When the AMF triggers an NSAC request to the NSACF, the AMF includes the UE already Registered indication if it can determine that the registered S-NSSAI has been registered in one service area before. The AMF determines the indication based on the received the Allowed NSSAI information from source AMF (in case of inter AMF handover) or from SMF+PGW-C (in case of mobility from EPS to 5GS)
There are two types of UE admission control: quota-based control or threshold-based control. A PLMN is configured to deploy only one type of UE admission control. Based on the type of UE admission control configured for the PLMN, the NSACF handles the NSAC request as described below:
For NSACFs supporting quota-based control, if upon receiving a request to increase the number of UEs and the local maximum number of UEs registered for a network slice has been reached, or upon receiving a request to decrease the number of UEs and no UE entry is in the NSACF, the NSACF interacts with the Primary NSACF for the handling of the NSAC request for the UE. The Primary NSACF may return in the response an updated local maximum number of registered UEs value to the NSACF based on the status of registered UEs for the network slice and which enables the NSACF to handle locally the request. Alternatively, and if the request includes the UE already Registered indication, the Primary NSACF may handle and store the UE entry to enable UE admission and allow for service continuity. The Primary NSACF may also reject the request.
For NSACF supporting threshold-based control, the NSACF is initially configured with the maximum number of Registered UEs to be admitted. If upon a receiving a request to increase the number of UEs and no UE already Registered indication and if UE admission threshold is at or above the threshold level configured at the NSACF, NSACF immediately rejects the NSAC request. If the received request includes the UE already Registered indication and if UE admission is at or above the threshold level configured at the NSACF, NSACF accepts the request to enable UE admission and allow for service continuity as long as the maximum number of Registered UEs have not been reached. If the local maximum number of registered UEs value have been reached, the NSACF interacts with the Primary NSACF for the handling of the NSAC request for the UE. The NSACF does not include the UE already Registered Indication in this case. The Primary NSACF may return an updated UE admission threshold value to the NSACF in the response which enables the NSACF to handle the request locally. Alternatively, the Primary NSACF may handle and store the UE entry. The Primary NSACF may also reject the request.
For both options, the Primary NSACF supports the following capabilities depending on the NSACF configuration:
Returning a new updated local maximum number of Registered UEs for the NSACF to admit if the NSACF is configured to support that feature; or
Returning a new updated UE admission threshold for the NSACF to apply if the NSACF is configured to support that feature;
The primary NSACF handles, stores entries only related to UEs which the NSAC request includes the UE already Registered indication, that are already admitted in an existing service area but cannot be admitted in the new service area due to no remaining local maximum number of Registered UEs, as long as the overall PLMN number of registered UEs at the Primary NSACF is not exhausted. The primary NSACF informs the NSACF in its response;
Based on the response from primary NSACF, the NSACF determines whether to accept or reject the NSAC request for UE registration. In addition, the NSACF may also update the local maximum number of Registered UEs or admission threshold respectively if the related updated value is received;
At any time, the Primary NSACF can update the NSACFs local maximum number of Registered UEs or admission threshold through the request/response XYZ service operation.
The Primary NSACF subscribes to all the NACFs to obtain the number of registered UEs at all NSACFs.
The main differences between the NSACFs deployed in a non-Hierarchical Single tier architecture and NSACFs deployed in a centralized architecture is as follows:
If multiple NSAC service areas are deployed in PLMN, the AMF provides the NSAC service area information to the centralized NSACF. The centralized NSACF also stores the NSAC service area of the AMF the UE is registered with.
The NSACF keeps track of the current number of PDU Sessions per network slice so that it can ensure it does not exceed the maximum number of PDU session allowed to be served by the network slice. When an event related to a UE causes the current number of PDU sessions established within the network slice is to increase, the NSACF checks whether the maximum number of PDU sessions per network slice for that network slice has already been reached and if it has, the NSACF applies admission control policies.
The anchor SMF triggers a request to NSACF for maximum number of PDU sessions per network slice control during PDU session establishment/release procedures in clauses 4.3.2 and 4.3.4 of TS 23.502.
The SMF provides the Access Type to the NSACF when triggering a request to increase or decrease the number of PDU Sessions. The NSACF takes Access Type into account for increasing and decreasing the current number of PDU Sessions depending on the applicability of the Access Type for the NSAC for maximum number of PDU Sessions for the S-NSSAI.
The main differences between the NSACFs deployed in a non-hierarchal architecture and NSACFs deployed in a hierarchal architecture is as follows:
The NSCAF is enhanced to support PDU session admission quota-based control.
When the local maximum number of PDU sessions is reached, the NSACF interacts with the primary NSACF to handle the request. The Primary NSACF either return an increased local maximum number to the NSACF, or reject the local maximum number value update request if all the global maximum number are consumed based on the status of established PDU sessions to the network slice.
Based on the response from primary NSACF, the NSACF updates the local maximum number if updated value is received from the primary NSACF. The NSACF updates local maximum number value (if received) and determines whether to accept or reject the NSAC request for PDU session establishment based on the local maximum number value.
The update of local maximum number value by the Primary NSACF can also happen at any time through the request/response service XYZ operation.
The Primary NSACF subscribes to all the NACFs to obtain the number of established PDU sessions at all NSACFs.
The main differences between the NSACFs deployed in a non-Hierarchical architecture and NSACFs deployed in a centralized architecture is as follows
If multiple NSAC service areas are deployed in PLMN, the SMF provides the NSAC service area information to the centralized NSACF. The centralized NSACF also stores the NSAC service area of the SMF the PDU session is established on.
In the case of roaming, depending on operator's policy, a roaming agreement or an SLA between the VPLMN and the HPLMN, NSAC of roaming UEs is performed by one of the following modes of NSAC admission:
VPLMN NSAC Admission; or
VPLMN with HPLMN assistance NSAC Admission; or
HPLMN NSAC Admission.
The VPLMN (AMF and SMF) identifies the mode to apply from the AMF subscription data at UE registration, and from the SMF subscription data at PDU session establishment.
For all the above modes, for NSAC of roaming UEs for maximum number of UEs per network slice and/or maximum number of PDU Sessions per network slice managed by the VPLMN, each S-NSSAI of the HPLMN that is subject to NSAC is mapped to a corresponding S-NSSAI of the VPLMN subject to NSAC.
For both VPLMN NSAC Admission and VPLMN with HPLMN assistance NSAC Admission modes, each configured S-NSSAI that is subject to NSAC and that is mapped from the HPLMN S-NSSAI, the SMF performs NSAC for home routed PDU sessions according to the principles described in clause 5.15.11.2.
For NSAC of roaming UEs for maximum number of UEs per network slice and/or maximum number of PDU Sessions per network slice managed by the VPLMN, the following principles shall be used:
For NSAC for the maximum number of UEs for S-NSSAI of the HPLMN, a NSACF in the VPLMN can be configured with the maximum number of allowed roaming UEs per mapped S-NSSAI of the HPLMN for a S-NSSAI of the HPLMN that is subject to NSAC. In such a case, the AMFs trigger a request to a NSACF of the VPLMN.
For NSAC for the maximum number of PDU Sessions for S-NSSAI of the HPLMN, a NSACF in the VPLMN can be configured with the maximum number of allowed PDU Sessions in LBO mode per mapped S-NSSAI of the HPLMN for a S-NSSAI of the HPLMN that is subject to NSAC. In such a case, the anchor SMF in the VPLMN triggers a request to a NSACF of the VPLMN.
For NSAC for the maximum number of UEs for S-NSSAI of the VPLMN, AMFs trigger a request to a NSACF of the VPLMN to perform NSAC based on the S-NSSAI of the VPLMN subject to NSAC. The NSACF of the HPLMN is not involved.
For NSAC for the maximum number of PDU Sessions for S-NSSAI of the VPLMN in the LBO roaming case, the SMF triggers a request to a NSACF of the VPLMN to perform NSAC based on the S-NSSAI of the VPLMN subject to NSAC. The NSACF of the HPLMN is not involved.
The AMF or SMF (in LBO roaming case) in the VPLMN provides both the S-NSSAI in the VPLMN and the corresponding mapped S-NSSAI in the HPLMN to the NSACF in the VPLMN. The NSACF in the VPLMN performs NSAC for both S-NSSAI of the VPLMN and the corresponding mapped S-NSSAI of the HPLMN based on the SLA between the VPLMN and the HPLMN.
In addition to configuring the VPLMN NFs with the maximum number of allowed roaming UEs per mapped S-NSSAI of the HPLMN subject to NSAC, and the maximum number of allowed PDU Sessions in LBO mode per mapped S-NSSAI of the HPLMN subject to NSAC, the VPLMN can optionally fetch this information from the HPLMN primary NSACF in a hierarchal architecture or centralized NSACF in a centralized architecture. If the NSACF in VPLMN does not have quota configured but can receive quota from the HPLMN, the NSACF in VPLMN may interact with the HPLMN for retrieving the quota before processing any incoming request. The VPLMN is either configured or discovers the NSACF in the HPLMN for quota retrieval. However, in this case, the VPLMN rejects any additional requests exceeding the received information.
In this admission mode HPLMN delegates NSAC for S-NSSAIs subject to NSAC to the VPLMN, both for number of registered UEs and the number of LBO PDU sessions.
Every NSACF performing admission in the VPLMN for each S-NSSAI of the HPLMN that is subject to NSAC and mapped to a corresponding S-NSSAI of the VPLMN, fetches from the VPLMN primary NSACF in a hierarchal architecture the maximum number of registered UEs to be admitted and/or the maximum number of LBO PDU sessions to be allowed. The VPLMN primary or central NSACF, in turn, acquires the information from the HPLMN central or primary NSACF depending on the deployed architecture. The VPLMN is either configured or discovers the NSACF in the HPLMN for quota retrieval.
If re-distribution of quota is required in the VPLMN in a hierarchal architecture, amongst multiple NSACFs than this is handled by the primary NSACF in VPLMN with no involvement from the HPLMN. The VPLMN NSACF discovers the HPLMN primary or central NSACF or be configured with the needed information.
For any request(s) received in any NSACF in the VPLMN exceeding the received maximum number information, the NSACF interacts with the VPLMN primary NSACF which in turn interacts with HPLMN primary or central NSACF to receive an updated roaming quota for the corresponding mapped S-NSSAI, which is used to determine whether admission request is accepted or rejected, unless forbidden by the SLA. If an admission request is accepted, the UE entry is stored in the NSACF performing admission in the VPLMN. This applies to the number of registered UEs as well as the number of LBO PDU sessions. The primary NSACF in VPLMN may re-distribute the received updated roaming quota to the NSACFs in VPLMN to perform NSAC for Roaming UEs according to the principles described in clauses 5.15.11.1 and 5.15.11.2.
In this admission mode the AMF or SMF in VPLMN interacts with HPLMN for admission, both for number of registered UEs or the number of LBO PDU sessions respectively.
For each S-NSSAI of the HPLMN that is subject to NSAC and mapped to a corresponding S-NSSAI of the VPLMN, AMF performs NSAC admission for the number of registered UEs with the HPLMN central or primary NSACF for all inbound roamers from that HPLMN when they register in this VPLMN. The AMF discovers the HPLMN primary or central NSACF or be configured with the needed information.
For each S-NSSAI of the HPLMN that is subject to NSAC and mapped to a corresponding S-NSSAI of the VPLMN, every SMF in this VPLMN performs NSAC admission for the number of LBO PDU sessions with the HPLMN central or primary NSACF for all inbound roamers from that HPLMN when they initiate an LBO PDU session. The SMFs discover the HPLMN primary or central NSACF or be configured with the needed information. For each S-NSSAI of the HPLMN that is subject to NSAC, the SMF performs NSAC according to the principles described in clause 5.15.11.2 for home routed PDU sessions.
In the HPLMN NSAC admission mode, the primary NSACF or central NSACF in HPLMN determines whether the NSAC admission request for a roaming UE is accepted or rejected.
A consumer NF (e.g. AF, Primary NSACF) can subscribe with the NSACF for Network Slice status notifications and reports. Upon such subscription, the corresponding NSACF in different NSAC architecture as defined in clause 5.15.11.0 can provide event based notifications and reports to the consumer NF (e.g. to AF via NEF) related to the current number of UEs registered for a network slice or the current number of UEs with at least one PDU Session/PDN Connection in the case of EPC interworking or the current number of PDU Sessions established on a network slice.
This clause describes the NSAC for maximum number of registered UEs and for maximum number of PDU Sessions for network slice subjected to EPS interworking. The NSAC for maximum number of UE with at least one PDU Session/PDN Connection is described in clause 5.15.11.5a. A network slice subject to both NSAC and EPS counting shall be configured with only one of the options:
Maximum number of registered UEs and/or maximum number of PDU Session; or
Maximum number of UEs with at least one PDU Session/PDN Connection and/or maximum number of PDU Session.
If EPS counting is required for a network slice, the NSAC for maximum number of UEs and/or for maximum number of PDU Sessions per network slice is performed at the time of PDN connection establishment in case of EPC interworking. To support the NSAC for maximum number of UEs and/or for maximum number of PDU Sessions per network slice in EPC, the SMF+PGW-C is configured with the information indicating which network slice is subject to NSAC. During PDN connection establishment in EPC, the SMF+PGW-C selects an S-NSSAI associated with the PDN connection as described in clause 5.15.7.1. If the selected S-NSSAI by the SMF+PGW-C is subject to the NSAC, the SMF+PGW-C triggers interaction with NSACF to check the availability of the network slice by invoking separate NSAC procedures for number of UE and number of PDU Session (as described in clause 4.11.5.9 of TS 23.502), before the SMF+PGW-C provides the selected S-NSSAI to the UE. If the network slice is available, the SMF+PGW-C continues to proceed with the PDN connection establishment procedure.
The NSACF performs the following for checking network slice availability prior to returning a response to the SMF+PGW-C:
For NSAC for number of UEs, if the UE identity is already included in the list of UE IDs registered with a network slice, or the UE identity is not included in the list of UE IDs registered with a network slice and the current number of UE registration did not reach the maximum number, the NSACF responds to the SMF+PGW-C with the information that the network slice is available. The NSACF includes the UE identity in the list of UE IDs if not already on the list and increases the current number of UE registration. Otherwise, the NSACF returns a response indicating that the maximum number with the network slice has been reached.
If hierarchical NSAC architecture is deployed, when the local maximum number or local threshold is reached the NSAC may interact with the Primary NSACF before it returns the response back to the SMF+PGW-C. For more details on handling at the NSACF and Primary NSACF see clause 5.15.11.1.2.
For NSAC for number of PDU Sessions, if the current number of PDU sessions is below the maximum number, the NSACF responds to the SMF+PGW-C with the information that the network slice is available. The NSACF increases the current number of PDU sessions. Otherwise, the NSACF returns the response indicating that the maximum number with the network slice has been reached.
If hierarchical NSAC architecture is deployed, when the local maximum number is reached the NSAC may interact with the Primary NSACF before it returns the response back to the SMF+PGW-C. For more details on handling at the NSACF and Primary NSACF see clause 5.15.11.2.2.
If the maximum number of UEs and/or the maximum number of PDU sessions has already been reached, unless operator policy implements a different action, the SMF+PGW-C rejects the PDN connection.
If the establishment of a new PDN Connections is with a different SMF+PGW-C from the SMF+PGW-C used for already existing PDN connection associated with the same S-NSSAI, each SMF+PGW-C will send a request for update (e.g. increase or decrease) to the NSACF. The NSACF may maintain a registration entry per SMF+PGW-C for the same UE ID.
The SMF+PGW-C provides the Access Type to the NSACF when triggering a request to increase or decrease the number of UEs and/or the number of PDU Sessions for an S-NSSAI.
When the UE with ongoing PDN connection(s) moves from EPC to 5GC, the SMF+PGW-C triggers a request to decrease the number of the UE registration in NSACF and the AMF triggers a request to increase the number of the UE registration in NSACF when the UE is registered in the new AMF. If there are more than one PDN connections associated with the S-NSSAI, the NSACF may receive multiple requests for the same S-NSSAI from different SMF+PGW-Cs. When the UE with ongoing PDU session(s) moves from 5GC to EPC, the SMF+PGW-C triggers a request to increase the number of the UE registration in NSACF and the old AMF triggers a request to decrease the number of the UE registration in NSACF when the UE is deregistered in old AMF. If there are more than one PDU sessions associated with the S-NSSAI, the NSACF may receive multiple requests for the same S-NSSAI from different SMF+PGW-Cs. The NSACF maintains a list of UE IDs based on the requests from SMF+PGW-C(s) and AMF, and adjusts the current number of registrations accordingly.
When EPS counting is performed for a network slice, and the UE with ongoing PDN connection(s) moves from EPC to 5GC, session continuity is guaranteed from NSAC standpoint, as the admission was granted at the time of PDN connection establishment, i.e. the number of PDU session is not counted again in 5GC. Similarly, when the UE with ongoing PDU session(s) moves from 5GC to EPC, session continuity is guaranteed from NSAC standpoint as the admission of the PDN Connection(s) to the network slice was already granted at the time of PDU Session establishment in 5GC.
If the PDN connection associated with S-NSSAI is released in EPC, the SMF+PGW-C triggers a request (i.e. decrease) to NSACF for maximum number of UEs and/or maximum number of PDU sessions per network slice control. The NSACF decreases the current number of registrations and removes the UE identity from the list of UE IDs if the PDN connection(s) associated with the S-NSSAI are all released in EPC.
If EPS counting is not required for a network slice, the NSAC for maximum number of UEs and/or for maximum number of PDU Sessions per network slice is performed when the UE moves from EPC to 5GC, i.e. when the UE performs mobility Registration procedure from EPC to 5GC (NSAC for maximum number of UEs per network slice) and/or when the PDN connections are handed over from EPC to 5GC (NSAC for maximum number of PDU Sessions per network slice). The SMF+PGW-C is configured with the information indicating the network slice is subject to NSAC only in 5GS. The PDN connection interworking procedure is performed as described in clause 5.15.7.1. Mobility from EPC to 5GC does not guarantee all active PDU Session(s) can be transferred to the 5GC in certain circumstances when either the current number of UE registration or the current number of PDU sessions would exceed the maximum number when the UE moves from EPC to 5GC. When the UE with ongoing PDU session(s) moves from 5GC to EPC, the SMF+PGW-C triggers a request to decrease the number of PDU Session to NSACF. If there are more than one PDU sessions associated with the S-NSSAI, the NSACF may receive multiple requests for the same S-NSSAI from different SMF+PGW-Cs and NSACF removes the PDU Session ID(s) while decreasing the number of PDU Session(s).
When EPS counting is required for a network slice and NSACF is configured with maximum number of UEs with at least one PDU Session/PDN Connection, the NSACF keeps track of the current number of UEs with at least one PDU session/PDN connection established on a network slice to ensure it does not exceed the maximum configured number.
To support the NSAC for maximum number of UEs with at least one PDU Session/PDN Connection, the SMF+PGW-C may be configured with one of the following options:
Option 1: Triggering an Nnsacf_NSAC_NumOfUEsUpdate_Request to NSACF for NSAC for maximum number of UEs when the UE establishes first PDU Session/PDN connection associated with the network slice in the SMF+PGW-C, or when the last PDU Session/PDN connection associated with the network slice is released. The NSACF performs admission control as described in clause 5.15.11.5 and the number of registered UE is replaced with number of UE with at least one PDU session/PDN connection. The AMF is not configured for this S-NSSAI to be subject to NSAC; or
Option 2: Triggering an Nnsacf_NSAC_NumOfPDUsUpdate_Request as described in clause 5.15.11.5 to NSACF and the NSACF performs admission control for the number of UEs with at least one PDU Session/PDN connection as follows:
The NSACF supports handling both for the number of UEs with at least one PDU Session/PDN Connection and number of PDU session for the S-NSSAI that is subject to EPC interworking and NSAC. In this case the AMF is not configured for this S-NSSAI to be subject to NSAC. As an optimization option, the SMF+PGW-C can be configured not to trigger the Nnsacf_NSAC_NumOfUEsUpdate_Request to NSACF.
When the NSACF receives request to increase the current number of PDU Session/PDN Connection established for the network slice, the NSACF checks whether this is the first PDU Session/PDN Connection associated with the network slice. If this is the first PDU Session/PDN Connection associated with the network slice the NSACF checks whether the maximum number of UEs with at least one PDU Session/PDN Connection has been reached. If the maximum number has not been reached then the NSACF increases the number of UE with at least one PDU session/PDN connection and add an entry for UE ID. If the maximum number of UEs has already been reached, unless operator policy implements a different action, the SMF+PGW-C rejects the PDU Session/PDN connection indicating the cause being the number of UEs in the network slice has been exceeded.
When the NSACF receives request to decrease the current number of PDU Session/PDN Connection established for the network slice, the NSACF locates the UE entry, checks whether this is the last PDU Session/PDN Connection associated with the network slice for the UE. If it is the last PDU Session/PDN Connection the NSACF decreases the number of UE with at least one PDU session/PDN connection and remove the associated UE entry.
NSACF is configured with the information of whether the NSAC for number of UEs with at least one PDU session/PDN connection is based on Option1 or Option 2.
In both options, the SMF+PGW-C provides the Access Type to the NSACF when triggering a request to increase or decrease or update the number of UEs with at least one PDU Session/PDN Connection and/or the number of PDU Sessions for an S-NSSAI.
In the case of roaming, same mechanisms in clause 5.15.11.3 are used and number of registered UE is replaced with number of UE with at least one PDU Session/PDN Connection. For home routed PDU Session/PDN Connection only HPLMN admission mode can be used in this case.
If hierarchical NSAC architecture is deployed, when the local maximum number or local threshold is reached the NSAC may interact with the Primary NSACF before it returns the response back to the SMF+PGW-C. For more details on handling at the NSACF and Primary NSACF see clause 5.15.11.1.2.
The subscription information for a UE may include for each S-NSSAI Network Slice Simultaneous Registration Group (NSSRG) information constraining which S-NSSAIs can be simultaneously provided to the UE in the Allowed NSSAI.
When S-NSSAIs have associated NSSRG information, then the S-NSSAIs in the Allowed NSSAI shall share at least one NSSRG.
The NSSRG information, defining the association of S-NSSAIs to NSSRG, is provided as an additional and separate information.
If the optional NSSRG information is not present for the S-NSSAIs of a subscription, and other restrictions do not apply e.g. availability at a specific location, then it is assumed that all the S-NSSAIs in the subscription information can be simultaneously provided to the UE in the Allowed NSSAI. However, if NSSRG information is present in the subscription information, at least one NSSRG shall be associated with each of the S-NSSAIs in the subscription information. At any time, if the AMF has received subscription information for a UE that includes NSSRG information, the Allowed NSSAI for the UE can only include S-NSSAIs which share a common NSSRG.
The default S-NSSAIs, if more than one is present, are associated with the same NSSRGs, i.e. the UE is always allowed to be registered with all the default S-NSSAIs simultaneously. The HPLMN only sends S-NSSAIs sharing all the NSSRGs of the Default S-NSSAIs to a non-supporting VPLMN as part of the subscription information, i.e. in addition to the default S-NSSAI(s), the HPLMN may send any other subscribed S-NSSAI which shares at least all the NSSRG defined for the default S-NSSAI(s), and the HPLMN sends no NSSRG information to the VPLMN. A subscription information that includes NSSRG information shall include at least one default S-NSSAI.
A supporting AMF/NSSF, when it receives a Requested NSSAI, evaluates the S-NSSAIs of the HPLMN (in the mapping information of the Requested NSSAI, when a mapping information is applicable) based on any received NSSRG information for these S-NSSAIs, to determines whether they can be provided together in the Allowed NSSAI.
A UE may support the subscription-based restrictions to simultaneous registration of network slices feature. In this case, the UE indicates its support in the Registration Request message in the Initial Registration and the Mobility Registration Update as part of the UE 5GMM Core Network Capability.
When the serving AMF provides the Configured NSSAI to the UE, and the UE has indicated it supports the subscription-based restrictions to simultaneous registration of network slices feature, the AMF also provides the UE with the NSSRG information related to the S-NSSAIs of the HPLMN which are in the mapping information of the Configured NSSAI. A UE which receives the NSSRG values in the network slicing configuration information shall only include in the Requested NSSAI S-NSSAIs that share a common NSSRG as per the received information. If the UE has stored Pending NSSAI and the UE is still interested in the Pending NSSAI then all the S-NSSAIs in the Requested NSSAI and the Pending S-NSSAI shall share a common NSSRG. If the HPLMN changes NSSRG information in the subscription information for a UE, the UDM updates the supporting AMF serving the UE with the new NSSRG information and the AMF, possibly after interaction with the NSSF (see clause 5.2.16.2.1 of TS 23.502), updates the UE as necessary with network slicing configuration by means of the UE Configuration Update procedure (this may include changes in the Configured NSSAI (and related mapping information) and changes in the Allowed NSSAI as applicable). The UE acknowledges this UE Configuration Update according to clause 4.2.4.2 of TS 23.502.
At any time, a UE supporting subscription-based restrictions to simultaneous registration of network slices feature and that has received NSSRG information together with the Configured NSSAI shall only request S-NSSAIs, across all Access Type(s) regardless of whether the same PLMN or different PLMNs are used, that share one or more common NSSRG.
An AMF which supports the subscription-based restrictions to simultaneous registration of network slice feature configures a non-supporting UE with a Configured NSSAI including only the S-NSSAIs sharing all the NSSRG values of the default S-NSSAI(s), except if it has been instructed otherwise by the UDM. In addition to the default S-NSSAI(s), the AMF sends to the UE in the Configured NSSAI any other subscribed S-NSSAI whose NSSRG match at least those defined for the default S-NSSAI(s).
The UDM in a supporting HPLMN may optionally keep a record of the PEIs or Type Allocation Codes values regarding UE ability to handle network slices that cannot be provided simultaneously in Allowed NSSAI.
The UDM may, based on configuration or the optional PEI records, indicate the AMF to provide the non-supporting UEs with the full set of subscribed S-NSSAIs even if they do not share a common NSSRG. The UDM instructs the supporting AMFs of a PLMN to do so by indicating that the UE can be given a Configured NSSAI with all the S-NSSAIs in the subscription information. If this indication is received from the UDM by the AMF, this is included in the UE context.
Based on its policy (including configuration or optionally checking the specific PEI or Type Allocation Code used by the UE, and subject to roaming agreement) the UDM may also provide the serving AMF in a non-supporting VPLMN with all the S-NSSAI in the subscription information. In this case the AMF provides the UE with a Configured NSSAI including all the S-NSSAIs in the subscription information the AMF receives.
The AMF provides no NSSRG information to a non-supporting UE.
When an AMF which supports the subscription-based restrictions to simultaneous registration of network slice feature, receives from a UE a Requested NSSAI including S-NSSAIs that are supported in the Tracking Area but do not share a common NSSRG, or the AMF has pending NSSAI stored for the UE, and the S-NSSAI(s) of the requested NSSAI and the pending NSSAI do not share a common NSSRG, the AMF assumes the UE configuration is not up-to-date, and provides the following:
a supporting UE with an updated configuration including the up-to-date NSSRG information for the S-NSSAIs in the Configured NSSAI as described above.
a non-supporting UE with an updated Configured NSSAI including only the S-NSSAIs sharing all the NSSRG values of the default S-NSSAI(s), only for the case where the UE context does not include an indication to provide all the subscribed S-NSSAIs in the subscription information in the Configured NSSAI for the UE.
A UE subscription information may include an optional Slice Maximum Bit Rate for the UE (Subscribed UE-Slice-MBR) for an S-NSSAI, which applies for 3GPP access type only. The Subscribed UE-Slice-MBR includes a UL and a DL value. If a Subscribed UE-Slice-MBR is associated to an S-NSSAI in the subscription information, it is provided by the AMF to the NG-RAN when the AMF provides the Allowed NSSAI for the UE to the NG-RAN as UE-Slice-MBR QoS parameter. The UE-Slice-MBR QoS parameter is defined in clause 5.7.2.6. If the Subscribed UE-Slice-MBR for a UE changes, the AMF updates UE-Slice-MBR in the NG-RAN accordingly.
In roaming case, the UE-Slice-MBR is provided for the S-NSSAI of the VPLMN which maps to the S-NSSAI of the HPLMN and the AMF may first interact with the PCF for authorization of the Subscribed UE-Slice-MBR. If the AMF interacts with the PCF, the PCF may provide the Authorized UE-Slice-MBR that is used as UE-Slice-MBR by the AMF as described in clause 6.1.2.1 of TS 23.503.
For a roaming UE, the S-NSSAI of the VPLMN maps to only one S-NSSAI of the HPLMN for which an UE-Slice-MBR is applied.
The enforcement of the UE-Slice-MBR value, if present in the UE context in the NG-RAN for an S-NSSAI, is described in clause 5.7.1.10.
The NG-RAN may support Network Slice AS Groups (NSAGs) which are used as specified in TS 38.300, TS 38.331, TS 38.321 and TS 38.304. A Network Slice AS Group is an identifier of a group of network slices which are associated with it. A Network Slice AS Group association with a group of network slices may be valid in one or more Tracking Areas. An S-NSSAI can be associated with at most one NSAG values for Random Access and at most one NSAG value for Cell Reselection within a Tracking Area. An S-NSSAI can be associated with different NSAG values in different Tracking Areas.
The NG-RAN provides (and updates) the AMF with the values of the NSAG(s) an S-NSSAI is associated with in a TA using the NG Set Up and RAN Configuration Update procedures (see TS 38.413). The AMF in turn provides this information to the NSSF. In deployments where the total number of groups does not exceed the number of groups associated with the NSAG size limit defined in TS 38.331), all the NSAGs configured in the NG-RAN may be unique per PLMN or SNPN. If the UE has indicated that the UE supports NSAG in the 5GMM Core Network Capability (see clause 5.4.4a), the AMF may, with or without NSSF assistance, configure the UE with NSAG Information for one or more S-NSSAIs in the Configured NSSAI, by including this NSAG Information in the Registration Accept message or the UE Configuration Command message. The UE uses the NSAG Information as defined in clause 5.3.4.3.1. The AMF shall indicate in the NSAG Information in which TA a specific NSAG association to S-NSSAI(s) is valid if the AMF provides in the UE configuration a NSAG value which is used in different TAs with a different association with NSSAIs. The configuration the AMF provides includes at least the NSAGs for the UE for the TAs of the Registration Area. If the AMF does not include the list of TAIs in association with an NSAG in the NSAG Information, the NSAG is valid in the Registered PLMN and equivalent PLMNs, or SNPN.
The UE shall store and consider the received NSAG Information, valid for the Registered PLMN and equivalent PLMNs, or SNPN until:
the UE receives new NSAG information in a Registration Accept message or UE Configuration Command message in this PLMN or SNPN; or
the UE receives a Configured NSSAI without any NSAG information in this PLMN or SNPN.
The UE shall store the currently valid NSAG information received in the Registered PLMN or SNPN when registered in this PLMN or SNPN and:
The UE should be able to store the NSAG information for at least the Registered-PLMN and equivalent PLMNs, or the Registered-SNPN and equivalent SNPNs.
The Registered-PLMN can provide NSAG information to the UE for the PLMN and the equivalent PLMNs, and the Registered-SNPN can provide NSAG information to the UE for the SNPN.
There can be at most 32 NSAGs configured in the UE at a time for a PLMN or SNPN.
At most 4 NSAGs can have an optional TAI associated with it.
The NSAG information is not required to be stored after power off or after the UE becomes Deregistered as it is not used for cell selection.
The UE during the Registration procedure may indicate in UE MM Core Network Capability that it supports UE configuration of network-controlled Slice Usage Policy. If so, the AMF determines Slice Usage Policy for a Network Slice for the UE and may configure the UE with this information together with Configured NSSAI to control the usage of this Network Slice. The AMF may be locally configured with network Slice Usage Policy, or receive the policy from the (AM-)PCF, or per the information received from UDM for AF managed timer values (see clause 5.15.15.3 for more details).
The network-controlled Slice Usage Policy is provided to the UE in the Registration Accept or the UE Configuration Update Command and may include:
An indication, for one or more of S-NSSAI(s) of the HPLMN in the Configured NSSAI, whether the UE only registers with the Network Slice with the network when applications in the UE require data transmission in the Network Slice (i.e. the UE can only register the Network Slice only on demand and consider the Network Slice as on demand S-NSSAI).
For all on demand S-NSSAI(s) of the HPLMN in the Configured NSSAI, a deregistration inactivity timer that causes the UE to deregister the Network Slice after the last PDU Session associated with the S-NSSAI is released. This deregistration inactivity timer is started at the UE and AMF per access type when the last PDU Session associated with the S-NSSAI is released, or the Network Slice is included in the Allowed NSSAI and no PDU session is established. The deregistration inactivity timer is stopped and reset when the first PDU session is established or the S-NSSAI is removed from the Allowed NSSAI. The AMF and UE may locally remove the S-NSSAI from the Allowed NSSAI when the timer expires. The AMF may also send a UE Configuration Update Command to remove the slice from the Allowed NSSAI.
If the UE and network state became misaligned, the UE may, for example, request connectivity in a Network Slice which is no longer allowed. In this case, the AMF shall provide the updated Allowed NSSAI in a UE Configuration Update Command after rejecting the PDU Session establishment. The UE may then re-register with the Network Slice if needed.
The AMF receives deregistration inactivity timer values as described in clause 5.15.15.3.
The 5GC performs Network Slice usage monitoring to be able to enforce the release of inactive PDU Sessions, and deregistering of UEs from Network Slices with no PDU Sessions on them according to its own policies. In order to support usage monitoring for a Network Slice:
the AMF runs a slice deregistration inactivity timer per S-NSSAI and access type to deregister the Network Slice which is started when the Network Slice is not used by any PDU Session over the corresponding access type. The slice deregistration inactivity timer is stopped and reset when at least a PDU Session associated with the Network Slice is successfully established or the Network Slice is removed form the Allowed NSSAI. When the slice deregistration inactivity timer for a Network Slice over an access type expires, the AMF removes the Network Slice from the Allowed NSSAI over the access type by sending the UE Configuration Update Command to impacted UE(s).
the SMFs provide to UPFs that handle the PDU sessions in the Network Slice a PDU Session inactivity timer. The PDU Session inactivity timer is started after no data packet is transmitted or received and runs until the next data packet is transmitted or received which restarts the timer again. If the PDU Session inactivity timer expires before any packet is received or transmitted, the UPF reports this PDU Session inactivity event to the SMF to cause the SMF to release the PDU Session. While releasing the PDU session the SMF may indicate the release cause because of slice inactivity. When the AMF receives the notification of PDU Session release and it includes the release cause of slice inactivity and if the Network Slice of the released PDU Session is not used by other PDU Sessions (i.e. the last PDU Session using the Network Slice is released) over the corresponding access type, the AMF may trigger the UE Configuration Update procedure to remove the Network Slice from the Allowed NSSAI over that corresponding access type or start slice deregistration inactivity timer for the Network Slice.
If an S-NSSAI is dedicated for a single AF, and if authorized by operator policy to provide deregistration inactivity/PDU Session inactivity timer values for the S-NSSAI, the AF uses external parameter provisioning procedure to provide deregistration inactivity and PDU session inactivity timer values as described in clause 4.15.6.2 of TS 23.502. In this case, the AF provided timer values are stored in the UDM and provided to the AMF/SMF as part of subscription data for the corresponding S-NSSAI. If no AF is authorized to provide deregistration inactivity/PDU Session inactivity timer values for the S-NSSAI, the slice deregistration inactivity timer value and PDU Session inactivity timer value are either pre-configured in the AMF/SMF or received by the AMF/SMF during the AM Policy Association / SM Policy Association procedure respectively.
To enable a serving network to direct UEs to a preferred Network Slice, the AMF may request the UE to transfer a PDU Session from one S-NSSAI to another S-NSSAI as described in clause 5.15.19.
A network slice may be available for all UEs or a limited number of UEs only for a limited time that is known at the network in advance e.g. by OAM or subscription. The limited time duration may be due to, for example, the fact that network slice is only temporarily or periodically active in the deployment (e.g. for a limited time to serve an event or a UE may be only authorized to access the network slice for a limited time known in advance), or the network slice is being decommissioned at a known future time. This feature is enabled by S-NSSAI validity time that the network and the UE can handle to reduce the signalling load associated to the transitions in RM and SM states for the network slice.
The UE may indicate its support for temporarily available network slices in the UE MM Core Network Capability (see clause 5.4.4a) in the Registration Request. The AMF, based on OAM configuration or information received from the UDM or NSSF, may indicate to a supporting UE the validity time for one or more S-NSSAIs in the Configured NSSAI in the Registration Accept message or via the UE Configuration Update procedure. In roaming case, the AMF my include the validity time for an S-NSSAI in the Configured NSSAI either because of limited availability of the VPLMN S-NSSAI or the mapped S-NSSAI of the HPLMN.
If a supporting UE is configured with validity time for an S-NSSAI:
If the validity time indicates the S-NSSAI is available, the UE may request the S-NSSAI in a Requested NSSAI in a Registration request and, if the S-NSSAI is included in the Allowed NSSAI or in the Partially Allowed NSSAI, the UE may establish PDU sessions associated with the S-NSSAI.
If the validity time indicates the S-NSSAI is not available
The UE shall not include the S-NSSAI in the Requested NSSAI;
If the S-NSSAI is already part of the Allowed NSSAI or Partially Allowed NSSAI, the UE shall remove the S-NSSAI from the locally stored Allowed NSSAI or Partially Allowed NSSAI and the UE shall also locally release any PDU sessions associated with the S-NSSAI.
If the validity time indicates the S-NSSAI will not be available again, the UE shall remove the S-NSSAI from the locally stored Configured NSSAI.
For a supporting UE, if validity time applies to an S-NSSAI, an AMF supporting temporarily available network slices shall:
If the S-NSSAI is provided in a Requested NSSAI in a Registration Request by the UE and the validity time indicates the S-NSSAI is not available, but it is going to become available again (i.e. the UE is detected as not having up to date validity time), then the AMF sends the Configured NSSAI to the UE including the validity time for the S-NSSAI in the Registration Accept message. If the validity time indicates the S-NSSAI is not available and will not become available again, then the AMF sends the Configured NSSAI to the UE, excluding the S-NSSAI from the Configured NSSAI.
If the S-NSSAI is in the Allowed NSSAI or the Partially Allowed NSSAI for the UE and the validity time indicates that the S-NSSAI is not available, then locally remove (i.e. without sending any signalling to the UE) the S-NSSAI from the Allowed NSSAI or Partially Allowed NSSAI. If there is any PDU session established for the S-NSSAI, the AMF requests the SMF to release the PDU session:
If the UE is in CM-CONNECTED state, the AMF releases the PDU session for the S-NSSAI by sending to the SMF, as per step 1f in clause 4.3.4.2 of TS 23.502, a Nsmf_PDUSession_UpdateSMContext Request with a release indication to request the release of the PDU Session and then the AMF forwards the N2 SM request to release the AN resources associated with the PDU session
If the UE is in CM-IDLE state, the AMF locally releases the PDU session without paging the UE and causes the SMF to locally release the SM context for the UE by a Nsmf_PDUSession_ReleaseSMContext, as in step 1c in clause 4.3.4.2 of TS 23.502. The PDU Session status is synchronized at next time when the UE connects to the network.
For a non-supporting UE, if validity time applies to an S-NSSAI, an AMF supporting temporarily available network slices shall:
If the validity time indicates the S-NSSAI is available, allow or partially allow the network slice when requested, establish PDU sessions when requested.
If the S-NSSAI is provided in a Requested NSSAI in a Registration Request by the UE and the validity time indicates the S-NSSAI is not available, reject the registration and remove the S-NSSAI from the Configured NSSAI by providing an updated Configured NSSAI in the Registration Accept message.
If the S-NSSAI is in the UE in the Allowed NSSAI or Partially Allowed NSSAI and the validity time indicates the S-NSSAI is not available, remove the S-NSSAI from the Configured NSSAI and the Allowed NSSAI or Partially Allowed NSSAI by a UE Configuration Update procedure. If there is any PDU session established for the S-NSSAI, the AMF requests the SMF to release the PDU session in the network:
If the UE is in CM-CONNECTED state, the AMF releases the PDU session for the S-NSSAI by sending to the SMF, as in step 1f in clause 4.3.4.2 of TS 23.502, a Nsmf_PDUSession_UpdateSMContext Request with a release indication to request the release of the PDU Session and then the AMF forwards the N2 SM request to release the AN resources associated with the PDU session
If the UE is in CM-IDLE, the AMF locally releases the PDU session without paging the UE and causes the SMF to locally release the SM context for the UE by a Nsmf_PDUSession_ReleaseSMContext, as in step 1c in clause 4.3.4.2 of TS 23.502. The PDU Session status is synchronized at next time when the UE connects to the network
If the AMF detects from the validity time of a S-NSSAI that it is available again, then update the Configured NSSAI to include the S-NSSAI via a UE Configuration Update procedure.
A Network Slice may be supported in one or more TAs in a PLMN/SNPN. The Partial Network Slice support in a Registration Area for a UE includes configuring the UE with a Partially Allowed NSSAI and/or S-NSSAI(s) rejected partially in the RA.
When creating a Registration Area for UEs registering over the 3GPP access and supporting the Partial Network Slice support in a Registration Area, the AMF may consider the trade-off between signalling for paging in TAs where the S-NSSAI is not supported versus the signalling for Mobility Registration Updates to register with the S-NSSAI in the TA(s) where the S-NSSAI is supported, so that the AMF may create a Registration Area including the TA(s) where a requested S-NSSAI is not supported. For supporting UEs, whether the AMF uses the Partially Allowed NSSAI or rejects the S-NSSAIs partially in the RA, or whether the AMF rejects the S-NSSAI for the current RA, is a per S-NSSAI decision which is based on AMF local policy. If supported and allowed by local policy, the Partially Allowed NSSAI and S-NSSAIs rejected partially in the RA may be applied simultaneously for one UE for different S-NSSAIs.
For such S-NSSAI:
If requested by the UE from a TA where the S-NSSAI is not supported,
the S-NSSAI is included either in the Partially Allowed NSSAI or the AMF rejects the S-NSSAI partially in the RA; or
if the S-NSSAI is subject to NSAC for maximum number of UEs, then the AMF should send this S-NSSAI as rejected partially in the RA, in the Registration Accept message.
If the S-NSSAI is subject to NSSAA and successful NSSAA status for the S-NSSAI is not present in the AMF, then the AMF either sends this S-NSSAI as rejected partially in the RA in the Registration Accept message, or the AMF starts executing NSSAA and includes the S-NSSAI in the Pending NSSAI in the Registration Accept message. If the S-NSSAI is subject to NSSAA and successful NSSAA status for the S-NSSAI is present, then the AMF may include the S-NSSAI either in the Partially Allowed NSSAI or the AMF rejects the S-NSSAI partially in the RA.
if the slice deregistration inactivity timer is configured for the S-NSSAI (see clause 5.15.15.3), then AMF should send this S-NSSAI as rejected partially in the RA.
If requested by the UE from a TA where the S-NSSAI is supported,
the S-NSSAI is included in the Partially Allowed NSSAI; or
if the S-NSSAI is subjected to NSAC for maximum number of UEs, then the AMF should restrict the RA so that the S-NSSAI is supported in all the TAs of the RA and includes the S-NSSAI in the Allowed NSSAI.
If the S-NSSAI is subject to NSSAA, then the AMF starts executing NSSAA and sends this S-NSSAI in the Pending NSSAI in the Registration Accept message, unless successful NSSAA status is present in the AMF for this S-NSSAI (in which case it can be sent in the Partially Allowed NSSAI).
if the S-NSSAI is included in neither the Partially Allowed NSSAI nor the Allowed NSSAI, the AMF may reject the S-NSSAI as described in clause 5.15.4.1.1.
While the S-NSSAIs of the Allowed NSSAI are supported in all the TAs of the Registration Area, the S-NSSAIs of the Partially Allowed NSSAI are supported only in the TAs corresponding to the list of TAs (which are subset of the list of TAIs forming the Registration Area) associated with the S-NSSAI.
If the UE supports Partial Network Slice support in a Registration Area, the AMF may create a Registration Area for the UE considering the support of the S-NSSAIs of the Requested NSSAI in the current TA and in the neighbouring TAs and provides to the UE in the Registration Accept message or in the UE Configuration Update Command message the Partially Allowed NSSAI or the S-NSSAIs rejected partially in the RA as follows:
If one or more of the requested S-NSSAI(s) are supported in a subset of the TAs of the (potential) Registration Area, the AMF may include such S-NSSAI(s) in the Partially Allowed NSSAI and corresponding mapping information of the S-NSSAI(s) of the Partially Allowed NSSAI to the HPLMN S-NSSAI(s). For each S-NSSAI of the Partially Allowed NSSAI the AMF provides a list of TAs where the S-NSSAI is supported. The UE is considered registered with the S-NSSAI in the whole Registration area. The AMF also provides the Partially Allowed NSSAI (without indication of the TA list where the partially allowed S-NSSAIs are supported) to the NG-RAN together with the UE's context.
Alternatively, the AMF may reject the S-NSSAI(s) with reject cause indicating "partially in the RA". For each S-NSSAI of the S-NSSAIs rejected partially in the RA the AMF provides a list of TAs for which the S-NSSAI is supported or not supported.
When the UE stores Partially Allowed NSSAI the following applies:
the UE is considered registered with an S-NSSAI of the Partially Allowed NSSAI in the whole Registration area. The UE does not trigger registration when moving between the TAs of support and non-support for the S-NSSAI within the RA.
The UE is allowed to initiate PDU Session establishment for the S-NSSAI only when the UE is in a TA where the S-NSSAI is supported.
If the AMF determines a PDU Session is associated with S-NSSAI present in the Partially Allowed NSSAI, the AMF indicates to the SMF that the PDU Session is subject to area restrictions for the S-NSSAI. As a result, the SMF subscribes to "UE mobility event notification" for reporting UE presence in Area of Interest by providing S-NSSAI to the AMF as described in clauses 5.6.11 and 5.3.4.4.
When the UE has already established a PDU Session with an S-NSSAI part of the Partially Allowed NSSAI, the UE is allowed to activate the User Plane Resources of the PDU Session only when the UE is in a TA part of the list of TAs associated with each S-NSSAI.
When the User Plane Resources are activated for a PDU Session of an S-NSSAI part of the Partially Allowed NSSAI and the UE moves to a TA which is not part of the list of TAs associated with the S-NSSAI, the User Plane Resources for the PDU Session shall be deactivated, but the PDU Session context in UE and SMF is not released. The User Plane Resources for the PDU Session shall not be activated as long as the UE is located in a TA which is not part of the list of TAs associated with the S-NSSAI of the Partially Allowed NSSAI. The UE shall not send user data as payload of a NAS message (see clause 5.31.4.1) in uplink directions. When the SMF is notified by the AMF that the UE location is outside of the Area of Interest, the SMF shall not send user data as payload of NAS message (see clause 5.31.4.1) in downlink directions and disable data notification.
When the UE stores a S-NSSAI rejected partially in the RA with the associated list of TAs, the UE is allowed to initiate a Mobility Registration Update procedure to request registration with the S-NSSAI only when the UE is in a TA supporting this S-NSSAI.
For a UE in CM-CONNECTED state, when a PDU Session is established on an S-NSSAI included in the Partially Allowed NSSAI, the User Plane resources are activated and the UE moves to a TA where the S-NSSAI is not supported, the NG-RAN deactivates the User Plane resources as described in the AN initiated modification of a PDU Session in clause 4.3.3.2 of TS 23.502.
The network support for a Network Slice is defined on a per Tracking Area granularity. It may be beneficial to deploy some Network Slices such that the Network Slice have a limited geographical availability that is not matching existing Tracking Area boundaries.
The operator can in this case decide to change the topology of the Tracking Areas so they match the boundaries of the Network Slice, or the operator may configure resources for the Network Slices in the cells of TAs where the Network Slices are to be available, and in areas of the TAs where the network slice is defined to be not available the cells are configured with zero resources.
The AMF receives from the OAM the information on availability of a network slice when the granularity is smaller than TA, i.e. if the NS-AoS includes TAs where the network slice is not available in some cells of the TA.
In order to optimize the end-to-end behaviour, the AMF can, based on NS-AoS information received from OAM, configure supporting UEs with S-NSSAI location availability information, and the network may need to monitor the S-NSSAI usage and enforce the NS-AoS e.g. if the UE does not support the S-NSSAI location availability information.
S-NSSAI location availability information defines additional restrictions to the usage of an S-NSSAI in TAs where the Network Slice availability does not match the TA boundaries. The AMF is configured per S-NSSAI whether to send the S-NSSAI location availability information to supporting UEs.
The S-NSSAI location availability information sent to the UE includes, for each applicable S-NSSAI of the Configured NSSAI, Location information indicating the cells of TAs in the RA where the related S-NSSAI is available if the S-NSSAI is not available in all the cells of the TA.
If the UE has indicated that the UE supports S-NSSAI location availability information in the 5GMM Core Network Capability (see clause 5.4.4a), the AMF may, based on OAM configuration, configure the UE with S-NSSAI location availability information for one or more S-NSSAIs when the AMF allocates an RA where the Network Slice availability does not match whole TAs, by including the S-NSSAI location availability information in the Registration Accept message or the UE Configuration Command message. A UE that receives S-NSSAI location availability information applies the information as follows.
If the S-NSSAI is rejected in the RA or rejected partially in the RA or rejected with a cause code that allows attempting to register the S-NSSAI again, the UE can request the S-NSSAI only if the S-NSSAI location availability information indicates that the S-NSSAI is available at the cell where the UE is camping.
If the S-NSSAI is in the Partially Allowed NSSAI or in the Allowed NSSAI, the UE shall not activate User Plane for any already established PDU Session with that S-NSSAI if the UE is in a cell within the RA but outside the Location information of the S-NSSAI. The UE shall not send user data as payload of a NAS message (see clause 5.31.4.1) in uplink directions.
If the S-NSSAI is in the Partially Allowed NSSAI or in the Allowed NSSAI, and the UE in CM-CONNECTED state moves from a cell inside the NS-AoS to a cell outside the NS-AoS and the User Plane resources are active for a PDU Session on that S-NSSAI, the NG-RAN deactivates the User Plane resources as described in the AN initiated modification of a PDU Session in clause 4.3.3.2 of TS 23.502.
OAM may configure RRM policies for S-NSSAIs on a per cell basis as defined in TS 28.541, i.e. cells outside the Network Slice Area of Service while in a TA supporting the S-NSSAI are allocated with no RRM resources for the S-NSSAI.
The network may enforce the NS-AoS for an S-NSSAI as follows:
The network may monitor the validity of the S-NSSAI for UE in CM-CONNECTED state, i.e. the AMF subscribes to the AoI using the Location information of the S-NSSAI location availability information as described in TS 38.413.
If the non-supporting UE makes a PDU Session establishment request with an S-NSSAI that is not valid as per the S-NSSAI location availability information, the AMF may reject the NAS Transport message with a back-off timer using S-NSSAI based congestion control as described in clause 5.19.7.4.
If the AMF determines that the UE in CM-CONNECTED has moved outside the NS-AoS, the AMF performs the following logic:
If the non-supporting UE has other S-NSSAI(s) in the Allowed NSSAI, then the AMF may update the UE with a UE Configuration Update by removing the S-NSSAI from the Allowed NSSAI (which causes the UE to locally release the PDU Sessions) and optionally removing the S-NSSAI from the Configured NSSAI and then, the AMF requests the SMF to locally release in the network any PDU Sessions with that S-NSSAI as per step 1f in clause 4.2.3.4 in TS 23.502. Alternatively, the AMF requests the SMF to release PDU Sessions with that S-NSSAI.
If the non-supporting UE does not have any other S-NSSAI in the Allowed NSSAI, then the AMF may update the UE with a UE Configuration Update by removing the S-NSSAI from the Allowed NSSAI (which causes the UE to locally release the PDU Sessions) and optionally removing the S-NSSAI from the Configured NSSAI, and adding a default S-NSSAI to the Allowed NSSAI and then, the AMF requests the SMF to locally release in the network any PDU Sessions with the removed S-NSSAI as per step 1f in clause 4.2.3.4 in TS 23.502. Alternatively, the AMF requests the SMF to release PDU Sessions with that S-NSSAI.
For a non-supporting UE that does not have any other S-NSSAI in the Allowed NSSAI nor in the Configured NSSAI, then the AMF indicates to the SMF to release the PDU Session.
If the AMF determines that the S-NSSAI becomes valid e.g. the UE has moved into the NS-AoS, the AMF may update the UE with a UCU e.g. including the S-NSSAI in the Configured NSSAI.
When the AMF determines that the S-NSSAI of a PDU Session is restricted to an NS-AoS in the PDU session, the AMF indicates to the SMF that the PDU Session is subject to area restriction for the S-NSSAI. As a result, the SMF subscribes to "UE mobility event notification" for reporting UE presence in Area of Interest by providing S-NSSAI to the AMF as described in clauses 5.6.11 and 5.3.4.4. When SMF is notified that the UE location is outside of Area of Interest, SMF shall not send user data as payload of NAS message (see clause 5.31.4.1) in downlink directions and disable data notification.
The Network Slice Replacement feature is used to replace an S-NSSAI with an Alternative S-NSSAI when an S-NSSAI becomes unavailable or congested. The Network Slice Replacement may be triggered in the following cases:
If the NSSF detects that an S-NSSAI becomes unavailable or congested (e.g. based on OAM or NWDAF analytics output), it sends network slice availability notification for the S-NSSAI to the AMF. The notification may include an Alternative S-NSSAI which can be used by the AMF to replace the S-NSSAI. The NSSF notifies the AMF when the S-NSSAI is available again.
If the PCF detects that an S-NSSAI becomes unavailable or congested for a UE (e.g. based on OAM or NWDAF analytics output), it sends access and mobility related policy notification to the AMF. The notification may include an Alternative S-NSSAI which can be used by the AMF to replace the S-NSSAI. The PCF notifies the AMF when the S-NSSAI is available again for the UE.
The OAM sends notification to AMF when an S-NSSAI becomes unavailable or congested (and also when this S-NSSAI becomes available again) and provides the Alternative S-NSSAI to AMF.
The network slice associated with the Alternative S-NSSAI is assumed in this specification to have NS-AoS to be covering at least the NS-AoS of the replaced network slice.
Based on the notification above from NSSF or PCF or OAM, the AMF may determine that an S-NSSAI is to be replaced with Alternative S-NSSAI. For roaming case, the AMF may receive network slice availability notification of the HPLMN S-NSSAI from NSSF in the HPLMN via NSSF in VPLMN, to trigger the Network Slice Replacement of the HPLMN S-NSSAI as described in clause 5.15.6.
The AMF determines the Alternative S-NSSAI for a UE registered with the S-NSSAI based on the notification from NSSF or PCF, or based on local configuration if the NSSF or PCF do not provide an alternative S-NSSAI. The Alternative S-NSSAI shall be supported in the UE Registration Area. If AMF cannot determine the Alternative S-NSSAI for the S-NSSAI, e.g. PCF or NSSF doesn't provide Alternative S-NSSAI, the AMF may further interact with the PCF to determine the Alternative S-NSSAI. The event trigger in AMF for interacting with PCF is described in clause 6.1.2.5 of TS 23.503.
The UE indicates the support of Network Slice Replacement feature during the UE Registration procedure. For supporting UE in CM-CONNECTED state and if there is a PDU Sessions in the UE context associated with the S-NSSAI that needs to be replaced, the AMF provides the Alternative S-NSSAI for this S-NSSAI in the Allowed NSSAI and in the Configured NSSAI, if not included yet, and the mapping between S-NSSAI(s) to Alternative S-NSSAI(s) to the UE in UE Configuration Update message as follows:
for non-roaming UEs, the AMF provides the mapping of the S-NSSAI to the Alternative S-NSSAI to the UE.
for roaming UEs when the VPLMN S-NSSAI has to be replaced by a VPLMN Alternative S-NSSAI, the AMF provides the mapping of the VPLMN S-NSSAI to the Alternative VPLMN S-NSSAI to the UE.
for roaming UEs when the HPLMN S-NSSAI has to be replaced by an Alternative HPLMN S-NSSAI, the AMF provides the mapping of the HPLMN S-NSSAI to the Alternative HPLMN S-NSSAI to the UE.
For the supporting UE when the UE has a NAS signalling connection, i.e. it is CM-CONNECTED or it has become CM-CONNECTED, e.g. through a Service Request procedure or through a UE registration procedure, if the AMF determines that the S-NSSAI is to be replaced and there is a PDU Session associated with the S-NSSAI in the UE context (see also NOTE 3), the AMF sends the mapping of the S-NSSAI to the Alternative S-NSSAI to the UE in the UE Configuration Update message or in the Registration Accept message.
During a new PDU Session establishment procedure for a S-NSSAI,
if the UE has received together with the Allowed NSSAI a mapping of the S-NSSAI to an Alternative S-NSSAI, the UE shall provide both the Alternative S-NSSAI and the S-NSSAI in the PDU Session Establishment message. When the AMF receives the Alternative S-NSSAI and the S-NSSAI in the PDU Session Establishment message, the AMF includes both the Alternative S-NSSAI and the S-NSSAI to the SMF in Nsmf_PDUSession_CreateSMContext service operation.
if the UE has not yet received with the Allowed NSSAI a mapping of the S-NSSAI to the Alternative S-NSSAI, the UE provides only the S-NSSAI in the PDU Session Establishment message. If the AMF determines that the requested S-NSSAI is to be replaced with the Alternative S-NSSAI and if the UE supports Network Slice Replacement, the AMF performs UE Configuration Update procedure to reconfigure the UE with the Alternative S-NSSAI. The AMF continues the PDU Session establishment procedure with the Alternative S-NSSAI and provides both the Alternative S-NSSAI and the S-NSSAI to the SMF in Nsmf_PDUSession_CreateSMContext service operation.
The SMF proceeds with the PDU Session establishment using the Alternative S-NSSAI. The SMF sends the Alternative S-NSSAI to NG-RAN in N2 SM information and to UE in PDU Session Establishment Accept message.
For existing PDU Session associated with an S-NSSAI that is replaced with the Alternative S-NSSAI, after the AMF sends mapping of the S-NSSAI to the Alternative S-NSSAI to the supporting UE in UE Configuration Update message, the AMF sends updates to the SMF of the PDU Session, e.g. triggering Nsmf_PDUSession_UpdateSMContext service operation, that the PDU Session is to be transferred to Alternative S-NSSAI and includes the Alternative S-NSSAI as follows (see details in clause 4.3.3 of TS 23.502):
If the SMF determines that the PDU Session is to be retained (e.g. if the anchor UPF can be reused with the alternative S-NSSAI and SSC mode 1), the SMF sends the Alternative S-NSSAI to the UPF in the N4 message, to the NG-RAN in N2 message and to the supporting UE in PDU Session Modification Command message. The S-NSSAI provided to the (R)AN and to the UPF is the Alternative S-NSSAI.
If the SMF determines that the PDU Session is to be re-established, the SMF sends the Alternative S-NSSAI to the supporting UE either in PDU Session Modification Command if the PDU Session is of SSC mode 3, or in PDU Session Release if the PDU Session is of SSC mode 2 or SSC mode 1, to trigger the re-establishment of the PDU Session. The UE includes both, the S-NSSAI and the Alternative S-NSSAI in the PDU Session Establishment message.
When the AMF is notified that the S-NSSAI is available again (e.g. the congestion of the S-NSSAI has been mitigated), if the AMF has configured the supporting UE with the Alternative S-NSSAI, and the AMF determines for the UE to use the replaced S-NSSAI again, the AMF reconfigures the supporting UE (e.g. by using UE Configuration Update procedure or in the next registration procedure) to use the replaced S-NSSAI again by removing the mapping of the replaced S-NSSAI to Alternative S-NSSAI.
If there is an existing PDU Session associated with the Alternative S-NSSAI, the AMF updates the SMF(s) of the PDU Session(s), by Nsmf_PDUSession_UpdateSMContext service operation, causing the PDU Session to be transferred to the S-NSSAI.
During a handover procedure, if an S-NSSAI has to be replaced with an Alternative S-NSSAI, the handover procedure (including any PDU session associated with the S-NSSAI to be replaced) shall continue unaffected by the Network Slice Replacement. Any Network Slice Replacement for the S-NSSAI shall not take place during the handover.
The Network Slice Instance Replacement is used when a PDU Session for a given S-NSSAI is established using a selected Network Slice instance and the S-NSSAI corresponding to this Network Slice instance is associated with multiple Network Slice instances. In this case, the network may change the Network Slice instance for the S-NSSAI if the selected Network Slice instance is no longer available (e.g. due to overload). The AMF may subscribe with the NSSF for notifications when any of the Network Slice instances served by the AMF is congested or no longer available. In case of roaming, the NSSF of VPLMN subscribes with the NSSF of the HPLMN for notifications. When the NSSF notifies the AMF that a Network Slice instance is congested or no longer available, for some of PDU Sessions associated with the Network Slice instance that is no longer available, the AMF may delete old NSI ID corresponding to the Network Slice instance that is no longer available and the SMF of the PDU Session(s) selected by using such old NSI ID is informed by the AMF to release the PDU Session(s). Subsequently, the SMF triggers the impacted UE(s) to establish new PDU session(s) associated with the same S-NSSAI as described in clause 5.6.9.2 for PDU Session(s) of SSC Mode 2 and SSC Mode 3. The AMF selects a new Network Slice instance for the given S-NSSAI during PDU Session Establishment.