Content for  TS 23.501  Word version:  19.3.0

When the UE is outside of the SMF Service Area, or current SMF cannot serve the target DNAI for the traffic routing for local access to the DN or when the UE is within the SMF service area as well as Local Offloading Management service area and Local Offloading Management (see clause 6.10 of TS 23.548 and clause 5.34.11) is allowed, an I-SMF is inserted between the SMF and the AMF. The I-SMF has a N11 interface with the AMF and a N16a interface with the SMF and is responsible of controlling the UPF(s) that the SMF cannot directly control. The exchange of the SM context and forwarding of tunnel information if needed are done between two SMFs directly without involvement of AMF. Depending on scenario, a PDU Session in non-roaming case or local breakout is either served by a single SMF or served by an SMF and an I-SMF. When a PDU Session is served by both an SMF and an I-SMF, the SMF is the NF instance that has the interfaces towards the PCF and CHF. In this Release of the specification, deployments topologies with specific SMF Service Areas apply only for 3GPP access. The SMF shall release or reject the PDU Session if the DNN of the PDU Session corresponds to a LADN and the I-SMF is inserted to the PDU Session. Independent of whether deployments topologies with specific SMF Service Areas apply, the SMF may trigger the PDU Session re-establishment to the same DN, if the PDU Session is associated with the SSC mode 2 or SSC mode 3. In this Release, how TSC (as defined in clauses 5.27 and 5.28) is supported for PDU Sessions involving an I-SMF is not specified. In this Release, Redundant User Plane Paths as defined in clause 5.33.2.2 is not supported for PDU Sessions involving an I-SMF. Redundant PDU sessions support as defined in clause 5.33.2.1 is supported for PDU Sessions involving an I-SMF, when different S-NSSAIs are used for the redundant PDU sessions. Redundant User Plane Paths as defined in clause 5.33.2.3 is supported for PDU Sessions involving an I-SMF only if this PDU session is established for a S-NSSAI referring to network instances requiring redundant transmission at transport layer. QoS monitoring (as defined in clause 5.33.3) is supported as long as SMF and not I-SMF initiates the QoS monitoring function. Dynamic CN PDB provisioning (as defined in clause 5.7.3.4) is supported for PDU Sessions involving an I-SMF. In this Release, no dedicated functionality is specified for I-SMF and N16a in order to support NPN.

The AMF is responsible of detecting when to add or to remove an I-SMF or a V-SMF for a PDU Session. For this purpose, the AMF gets from NRF information about the Service Area, supported DNAI(s) of SMF(s) and SMF(s) supporting Local Offloading Management. Local Offloading Management described in clause 5.34.11 and in clause 6.10 of TS 23.548. During mobility events such as Hand-Over or AMF change, if the service area of the SMF does not include the new UE location, then the AMF selects and inserts an I-SMF which can serve the UE location and the S-NSSAI. If I-SMF is inserted for Local Offloading Management for a case when the UE is within or outside the anchor SMF service area and within Local Offloading Management service area, the AMF selects and inserts an I-SMF which can serve the UE location, the S-NSSAI and support Local Offloading Management. Conversely if the AMF detects that an I-SMF is no more needed (as the service area of the SMF includes the new UE location and if the I-SMF was not inserted for Local Offloading Management or the UE is outside the Local Offloading Management service area) it removes the I-SMF and interfaces directly with the SMF of the PDU Session. If the AMF detects that the SMF cannot serve the UE location (e.g. due to mobility), then the AMF selects a new I-SMF serving the UE location. If the existing I-SMF (or V-SMF) cannot serve the UE location (e.g. due to mobility) and the service area of the SMF does not include the new UE location (or the PDU Session is Home Routed), then the AMF initiates an I-SMF (or V-SMF) change. A V-SMF change may take place either at intra-PLMN or inter-PLMN mobility. According to the PCC rules related with AF influence traffic mechanism regarding DNAI(s), the SMF determines the target DNAI which is applicable to the current UE location and which can be based on the common DNAI (if applicable) as described in TS 23.548. If current (I-)SMF cannot serve the target DNAI or if the SMF can serve the target DNAI and existing I-SMF is not needed, the SMF may send the target DNAI information to the AMF for triggering I-SMF (re)selection or removal, e.g. the AMF performs I-SMF (re)selection or removal based on the target DNAI and supported DNAI(s) of (I-)SMF. If the SMF determines that target DNAI currently served by I-SMF should not be used for the PDU Session hence the existing I-SMF is not needed (e.g. due to the updated PCC rules removes DNAI(s) that was provided in the previous PCC rules), the SMF sends the target DNAI information without including target DNAI to AMF, which may trigger the I-SMF removal. At PDU Session Establishment in non-roaming and roaming with LBO scenarios, if the AMF or SCP cannot select an SMF with a Service Area supporting the current UE location for the selected (DNN, S-NSSAI) and required SMF capabilities, the AMF selects an SMF for the selected (DNN, S-NSSAI) and required capabilities and in addition selects an I-SMF serving the UE location and the S-NSSAI. Compared to the SMF selection function defined in clause 6.3.2, the following parameters are not applicable for I-SMF/V-SMF selection:

• Data Network Name (DNN).
• Subscription information from UDM.

If HR-SBO roaming is allowed for a PDU Session, the DNN is also considered for V-SMF selection. If delegated SMF discovery is used at PDU Session establishment:

1. The AMF sends Nsmf_PDUSession_CreateSMContext Request to SCP and includes the parameters as defined in clause 6.3.2 (e.g. the DNN, required SMF capabilities, UE location) as discovery and selection parameters. If the SCP successfully selects an SMF matching all discovery and selection parameters, the SCP forwards the Nsmf_PDUSessionCreateSMContext Request to the selected SMF.
2. If the SCP cannot select an SMF matching all discovery and selection parameters, the SCP returns a dedicated error to AMF. In this case the I-SMF also need be discovered.
3. Upon reception of the error from the SCP that an SMF matching all discovery and selection parameters cannot be found, the AMF performs the discovery and selection of the SMF from NRF (thus not providing the UE location as a discovery parameter). The AMF may indicate the maximum number of SMF instances to be returned from NRF, i.e. SMF selection at NRF.
4. The AMF sends Nsmf_PDUSession_CreateSMContext Request to SCP, which includes the endpoint (e.g. URI) of the selected SMF and the discovery and selection parameters as defined in clause 6.3.2 except the DNN and the required SMF capabilities, i.e. parameter for I-SMF selection. The SCP performs discovery and selection of the I-SMF and forwards the Nsmf_PDUSession_CreateSMContext Request to the selected I-SMF.
5. The I-SMF sends the Nsmf_PDUSession_Create Request towards the SMF via the SCP; the I-SMF uses the received endpoint (e.g. URI) of the selected SMF to construct the target destination to be addressed. The SCP forwards the Nsmf_PDUSession_Create Request to the SMF.
6. The SMF answers to the I-SMF that answers to the AMF; in this answer the AMF receives the I-SMF ID.
7. Upon reception of a response from I-SMF, based on the received I-SMF ID, the AMF may obtain the SMF Service Area of the I-SMF from NRF. The AMF uses the SMF Service Area of the I-SMF to determine the need for I-SMF relocation upon subsequent UE mobility.

If delegated I-SMF discovery is used once the PDU Session establishment has been established, the procedure starts at step 4 above and is further detailed in the messages flows in clause 23 of TS 23.502 clause 4.23 of TS 23.502. If delegated V-SMF discovery is used for V-SMF reselection, clause 6.3.2 applies, but there is no need for discovery and selection of the H-SMF. This is further detailed in the messages flows in clause 23 of TS 23.502 clause 4.23 of TS 23.502.

This clause applies only in the case of non-roaming or LBO roaming as control of UL CL/BP in VPLMN is not supported in HR case. When I-SMF is involved for a PDU Session, it is possible that the UL CL controlled by I-SMF is inserted into the data path of the PDU Session. The usage of an ULCL controlled by I-SMF in the data path of a PDU Session is depicted in Figure 5.34.4-1.

The I-SMF determines whether UL CL will be inserted based on information received from SMF and the I-SMF selects the UPFs acting as UL CL and/or PDU Session Anchor providing local access to the Data Network.

This clause applies only in the case of non-roaming or LBO roaming as control of UL CL/BP in VPLMN is not supported in HR case. When I-SMF is involved for a PDU Session, it is possible that the BP controlled by I-SMF is inserted into the data path of the PDU Session. The usage of a BP controlled by I-SMF in the data path of a PDU Session is depicted in Figure 5.34.5-1.

The I-SMF determines whether BP will be inserted based on information received from SMF and the I-SMF selects the UPFs acting as BP and/or PDU Session Anchor providing local access to the Data Network.

This clause defines the specific impacts of deployments topologies with specific SMF Service Areas on how 5GS supports Cellular IoT as defined in clause 5.31. For a PDU Session supporting Control Plane CIoT 5GS Optimisation as defined in clause 5.31.4:

• For a PDU Session towards a DNN/S-NSSAI for which the SMF Selection Subscription data includes an Invoke NEF Indication (i.e. for a PDU Session which will be anchored in NEF), the AMF never inserts an I-SMF.

When an I-SMF is inserted to serve a PDU Session, the I-SMF supports the features that, as specified in clause 5.31, apply to the V-SMF in the case of Home Routed.

When Deployments Topologies with specific SMF Service Areas need to be used in a PLMN for a S-NSSAI, all AMF serving this S-NSSAI are configured to support Deployments Topologies with specific SMF Service Areas. For HR roaming, the AMF discovers at PDU Session establishment whether a H-SMF supports V-SMF change based on feature support indication received from the NRF, possibly via the SCP. When the V-PLMN requires Deployments Topologies with specific SMF Service Areas but no H-SMF can be selected that supports V-SMF change, a H-SMF not supporting V-SMF change may be selected by the VPLMN. In that case and if a V-SMF serving the full VPLMN is available, AMF should prefer to select such V-SMF. In this release of the specifications, when an AMF detects the need to change the V-SMF while the H-SMF does not support V-SMF change, the AMF shall not trigger V-SMF change but shall trigger the release of the PDU Session.

This clause defines how 5GS supports 5G LAN-type service as defined in clause 5.29 in the case of deployments topologies with specific SMF Service Areas. The UE may be connected with the PSA via an I-UPF which is controlled by the I-SMF. In this case, traffic switching (e.g. UPF local traffic switching) is controlled by the SMF as described in clause 5.29.4 without any specific knowledge or involvement of the I-SMF to support the 5G LAN-type service.

When the Local Offloading Management is allowed based on SMF selection subscription data and the UE is within the local offloading management service area, an I-SMF supporting the Local Offloading Management is inserted between the SMF and the AMF, even if the UE is within the SMF service area. The local offloading management service area may be locally configured in AMF per S-NSSAI and DNN, or generated in the AMF based on the received I-SMF profile received from the NRF. When an I-SMF is inserted to support Local Offloading Management to manage edge computing information locally, EAS deployment information management, EASDF selection, configuration and DNS message handling are performed by I-SMF as described in TS 23.548. The local offloading policy indicates IP range(s) and/or FQDN(s) allowed to be routed to the local part of a DN as specified in clause 6.4 of TS 23.503. The detailed procedures on I-SMF insertion during and after PDU session establishment and on EAS discovery are described in clause 6.10 of TS 23.548. The UL CL and UPF(s) may be inserted, changed, or removed by the I-SMF for the traffic offloaded for Local Offloading Management. For more detail handling (e.g. the interaction between I-SMF and SMF), refer to clause 6.10 of TS 23.548.