3GPP 23.501 v20.2.0 — the document's own text
5.15.17 Partial Network Slice support in a Registration Area
Taught in 17. One network, many networks (The 5G system architecture, in depth), 6. One network behaving like several (The 5G system architecture, overview).
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 (including the case when the S-NSSAI is provided as a rejected S-NSSAI for the TA from the NSSF):
- 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.
NOTE 1: In roaming case the NSSAA requirement is based on the mapped S-NSSAI of the HPLMN.
- 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 (including the case when the S-NSSAI is provided in the Allowed NSSAI from the NSSF):
- 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).
NOTE 2: In roaming case the NSSAA requirement is based on the mapped S-NSSAI of the HPLMN.
- 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 where the S-NSSAI is not supported.
NOTE 3: If the UE requests an S-NSSAI in a cell of a TA where the NS-AoS of the S-NSSAI does not match deployed Tracking Areas (see clause 5.15.18), the AMF includes the S-NSSAI in the Allowed NSSAI or Partially Allowed NSSAI.
For 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 UE has overlapping areas between non-allowed area, area where the S-NSSAI is supported, then the non-allowed area restriction applies.
- 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" event 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 if this event has not been subscribed before. The supporting AMF shall provide this indication in all the subsequent PDU Session update message to the SMF as long as the S-NSSAI of the PDU Session is subject to area restriction. When the AMF does not indicate to the SMF that the PDU Session is subject to area restriction for the S-NSSAI, the SMF may unsubscribe "UE mobility event notification" event in the AMF and if this event has been subscribed before.
- 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 the S-NSSAI. The UE shall not request User Plane resources when the UE is in a TAI where the S-NSSAI of the PDU Session is not supported based on the Partially Allowed NSSAI as a result the always-on PDU Session is also not re-activated during the Service Request or registration procedure.
- 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 NG-RAN releases the User Plane resources for the PDU Session as described in step 1d in clause 4.3.4.2 of TS 23.502 [3] and the SMF deactivates the PDU Session as described in step 3a in clause 4.3.4.2 of TS 23.502 [3], 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. The AMF determines the UE presence in Area of Interest as described in Annex D, clauses D.1 and D.2 of TS 23.502 [3] and notifies the result to the SMF. 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 SMF is notified by the AMF that the UE location is UNKNOWN as defined in Annex D, clauses D.1 and D.2 of TS 23.502 [3], then based on operator policy SMF may enable downlink data notification and trigger the Network triggered Service Request procedure to active the UP connection or send user data as payload of a NAS message (see clause 5.31.4.1) when the SMF receives downlink data or Data Notification from UPF.
NOTE 4: When I-SMF/V-SMF is inserted for the PDU session it is the I-SMF/V-SMF to handle the area restrictions for the S-NSSAI. The SMF/H-SMF is not involved in this procedure.
For an already established PDU Session associated with an S-NSSAI included in the Partially Allowed NSSAI, even when the supporting UE is in a TA where the S-NSSAI is not supported, the supporting UE may initiate a PDU Session release procedure or PDU Session modification procedure (i.e. for PS data off status change reporting).
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 which is not part of the list of TAs associated with 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 releases the User Plane resources of the PDU sessions associated with the S-NSSAIs, as described in step 1d of clause 4.3.4.2 of TS 23.502 [3] and the SMF deactivates the PDU session as described in step 3a of clause 4.3.4.2 of TS 23.502 [3].