5.34.3 I-SMF selection, V-SMF reselection

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 [130].

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 [130]. 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.

NOTE 1: All SMF(s) and I-SMF are assumed to be able to control the UPF mapping between EPC bearers and 5GC QoS Flows.

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 [3].

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 [3].