Non-3GPP Untrusted Wi-Fi to 5GS Handover with EPS Fallback Call Flow
This section describes the non-3GPP untrusted Wi-Fi to 5GS handover with EPS fallback call flow.

Step |
Description |
||
---|---|---|---|
1 |
The UE and the ePDG interact with each other through untrusted non-3GPP access to establish one or more PDU sessions. With the 5G NAS capability of UE, ePDG selects a combined PGW-C and SMF. The UE sends the PDU session ID to the combined PGW-C and SMF. |
||
1a |
The SMF installs the PccRule-1, PccRule-2, PccRule-3 for the WiFi session. |
||
2 |
The AMF sends the PDU Session Establishment request through 3GPP access to the SMF. This request includes details on the following:
The request type with an existing PDU session indicates switching between 3GPP access and non-3GPP access or to a PDU session handover from an existing PDN connection in EPC. |
||
3 |
If the request type is “Existing PDU Session”, the AMF selects the SMF based on SMF-ID that is received from the UDM. An error occurs for this request type on meeting any of the following conditions:
Then, the AMF updates the Access Type stored for the PDU session. If the request type with an existing PDU session refers to a PDU session that moved between 3GPP access and non-3GPP access and if the S-NSSAI of the PDU session is available in the Allowed NSSAI of the target access type, the PDU Session Establishment procedure begins when the SMF ID corresponding to the PDU Session ID and the AMF are part of the same PLMN. The AMF sends the NSMF PDU Session Create SM Context request with the request type “Existing PDU Session” to the SMF. This request includes information on the following:
The SMF analyzes the existing PDU session from the PDU Session Establishment request using SUPI+PDU-Session-ID. The SMF also compares the IPv4 or IPv6 addresses of the received UE against the retrieved PDU session IPv4 or IPv6 addresses. The SMF rejects the request if the session is not retrieved or the IPv4 or IPv6 addresses do not match. |
||
4 |
The SMF does not perform UDM registration as it has already been registered with UDM during the WiFi session establishment. |
||
4a |
The SMF detects the Charging triggers with the information available in Step 3 against the chrgTriggers received during the WiFi session. |
||
4b |
The SMF detects the PCF triggers with the information available in Step 3 against the Request Policy Control triggers that are received in the earlier communication with PCF during the Wi-Fi session. |
||
5 |
The SMF sends the NSMF PDU Session Create SM Context response to the AMF. This response includes the cause, SM Context ID, or N1 SM container with PDU session rejection cause. |
||
6 |
Based on the detected armed Policy Control Triggers that are received in Step 4a, the SMF sends the SM Policy Control Update request with the detected access parameters in Step 3 to the PCF. |
||
7 |
The PCF sends the SM policy decision through the SM Policy Control Update response by including new or updated PCC rules. |
||
8 |
Based on the information received in Step 7 and the existing policy data of Wi-Fi session, the SMF prepares the ModPolData. |
||
9 |
If the SMF receives new PCC rules in Step 7, the SMF sends the Charging Update request to the CHF with new rating-group for quota information. This request includes the PDU session information with the new access parameters. |
||
10 |
The CHF sends the multi-unit information in the Charging Update response to the SMF. The multi-unit information includes quota information for the rating-groups received in Step 9 and for the existing rating-group of Wi-Fi session. |
||
11 |
The SMF processes the ModChargingData that is received in the Charging Update response from the CHF. |
||
12 |
The SMF sends the N4 session modification request to the UPF for gNB tunnel. This request includes details on the following:
|
||
13 |
The UPF sends the UL tunnel information in the created PDR as the N4 Session Modification response to the SMF. |
||
14 |
The SMF sends the EBI assignment request to the AMF. This request includes the ARP list for the PDU session ID. |
||
15 |
The AMF sends the list of EBIs as the EBI Assignment response to the SMF. |
||
16 |
The SMF sends the N1 N2 Transfer Request to the AMF. This request includes the N2 message as “PDU Session Resource Setup Request Transfer” with supported QFI list and UL Tunnel Information of gNB tunnel. This request also includes the N1 message as “PDU Session Establishment Accept” with authorized QoS rule, authorized QoS flow description, EPCO, PDN addresses, and session AMBR values. |
||
17 |
The AMF sends the N1 N2 Transfer acknowledgment to the SMF. |
||
18 |
The AMF sends the SM Context Update request to the SMF with one of the following:
|
||
19 |
With the assumption that the pccRule-1 and pccRule-4 are successful, the SMF prepares the rule report for pccRule-2 and installs the pccRule-3 and pccRule-5 as part of the EPS fallback. |
||
19a |
The SMF deletes the resources from 5G session of failed QFI, and the VoWiFi resources. Further, the SMF performs the data path switching from WiFi to 5G. |
||
20 |
The SMF sends the N4 Session Modification request to the UPF by performing the following operations:
|
||
21 |
The UPF sends the N4 Session Modification response along with Usage Report for WiFi session to the SMF. |
||
22 |
The SMF sends the SM Context Update response to the AMF. |
||
|
|||
23 |
The SMF initiates the N1 N2 Transfer request with N1Msg: PDU Session Modification Command{QoS of FailedQfi}. The SMF receives the N1 N2 Transfer response from the AMF. |
||
24 |
The SMF receives the SM Context Update request with N1Msg: PDU Session Modification Complete from the AMF. |
||
25 |
The SMF sends the 204 OK in the SM Context Update response to the AMF. |
||
26 |
The SMF initiates the EPS fallback timer by retaining the "smPolicyDecision" and ruleReport which are processed after the EPS fallback procedure. Also, the SMF suspends the WiFi to NR handover procedure until the EPS fallback procedure is executed or the EPS fallback timer is expired. |
||
27 |
The SMF performs 5G to 4G handover (EPS fallback) for the existing default and dedicated flows. The SMF posts the internal transaction to resume the WiFi to NR procedure. |
||
28 |
The WiFi to NR procedure starts handling the internal transaction. |
||
28a |
The SMF starts the dedicated bearer creation procedure for pccRule-5 (for flows which are rejected by NR as part of the EPS fallback). |
||
29 |
The SMF initiates the N4 Modification request with Create UlPDRs, QERs, URRs (if any) for pccRules which are rejected as part of WiFi to NR handover with EPS fallback reason. |
||
30 |
The SMF receives the N4 Modification response with CreatedUlPDR which contains the uplink tunnel information for the dedicated bearers. |
||
31 |
The SMF initiates the GTPv2 Context Bearer request (bearer context list for dedicated bearers with uplink tunnel information). |
||
32 |
The SMF receives the GTPv2 Context Bearer response (accepted EBIs with downlink tunnel information). |
||
33 |
The SMF initiates the N4 Modification Session request (Create DlPdrs/DlFars of Dedicated Bearers for 4G tunnel) towards the UPF. |
||
34 |
The SMF receives the N4 Modification Session response from the UPF. |
||
35 |
The SMF prepares the ruleReport for PCCRule-2,3 InActive and pccRule-4,5 for Active based on the request Policy Control Triggers. |
||
36 |
The SMF sends the SM Policy Control Update request with ratType:"E-URTAN", userLocationInfo, ueTimeZone, servingNetwork, plmn, ruleReport, and so on. |
||
37 |
The SMF receives 200 OK with SM Policy Decision in the SM Policy Control Update response. |
||
|
|||
38 |
The SMF prepares the ruleReport for PCCRule-2,3 InActive and pccRule-4,5 InActive with FailureCode based on the request Policy Control Triggers. |
||
39 |
The SMF sends the SM Policy Control Update with ratType:"NR", userLocationInfo, ueTimeZone, servingNetwork, PLMN, ruleReport, and so on. |
||
40 |
The PCF sends the SM Policy Decision in the SM Policy Control Update response. The SMF processes the SM Policy Decision and handles it as PCF-initiated Modification procedure as defined in 3GPP TS 23.502, section 4.3.3.2. |