Handover Procedures

Feature Summary and Revision History

Summary Data

Table 1. Summary Data

Applicable Product(s) or Functional Area

SMF

Applicable Platform(s)

SMI

Feature Default Setting

Not Applicable

Related Changes in this Release

Not Applicable

Related Documentation

Not Applicable

Revision History

Table 2. Revision History
Revision Details Release

FB Call Continuity Cause Code Expansion

2021.02.2

Added support for:

  • Configuring calls with handover indication.

  • UE Local IP Address and UE UDP Port IEs in GTPC messages.

  • User Location Information (ULI) reporting.

2021.02.0

TFT Handling for Wi-Fi Handovers is supported.

2021.01.0

The Wi-Fi to 5GS Handover with EPS Fallback feature is fully qualified in this release.

2020.02.2

The Wi-Fi to 5GS Handover with EPS Fallback feature is not fully qualified in this release. For more information, contact your Cisco Account representative.

2020.02.1

First introduced.

Pre-2020.02.0

Feature Description

This chapter describes the different handover procedures performed by SMF compliant to the 3GPP specifications.

4G to 5G Data Session Handover

Feature Description


Important

The PGW-C term used in this chapter denote the EPS interworking functionality supported by SMF and must not be assumed as a standalone P-GW that is used in the LTE network.

For UEs, the SMF supports both 5G and 4G NAS to connect to E-UTRAN and 5G core network. The SMF includes the EPS interworking support and acts as PGW-C+SMF. The SMF uses the S5/S8 interface to receive the 4G Session Creation Request. Gx, Gy, or Gz interfaces, used for 4G session creation are replaced with the corresponding 5G core SBI interfaces, such as the NPCF and NCHF.

After a PDU session creation on PGW-C+SMF through E-UTRAN, MME, and S-GW, the SMF performs the 4G to 5G data session handover.

How it Works

To interwork with EPS, a UE that supports both 5GC and EPS NAS works in one of the following modes:

  • Single-registration Mode—In this mode, the UE has only one active MM state, which is either the RM state in 5GC or EMM state in EPS. In addition, this state is either in 5GC NAS mode or in EPS NAS mode when connected to 5GC or EPS, respectively.

  • Dual-registration Mode—In this mode, the UE handles independent registrations for 5GC and EPS using separate RRC connections. The UE may be registered to 5GC only, EPS only, or to both 5GC and EPS.

Architecture

This section describes the network architecture for the EPS-5G Core interworking.

Figure 1. Network Architecture for the EPS-5G Core Interworking

Call Flows

This section describes the following call flows.

EPS to 5G Handover with N26 Interface – Preparation Call Flow

This section describes the call flow of the preparation of the EPS to 5G Handover with the N26 interface.

Figure 2. Preparation Call Flow for the EPS to 5G Handover with the N26 Interface
Table 3. Preparation Call Flow Description for the EPS to 5G Handover with the N26 Interface
Step Description
1 Call handover initiation starts from UE and E-UTRAN toward each other, proceeds from E-UTRAN to the S-GW. Then for roaming calls, call handover initiation proceeds from S-GW to the UPF+PGW-C-U.
2 The E-UTRAN sends the Handover Call Request to the MME.
3 The MME forwards the Relocation Request to the AMF.
4 The AMF invokes the NsmfPDUSessionCreateSMContext service operation on SMF. The PGW-C+SMF address identifies this service operation. The service operations can be UE EPS PDN Connection, AMF ID, or Direct Forwarding Flag. The AMF then indicates the handover preparation to avoid switching the UP path. The SMF searches for the corresponding PDU session that is based on EPS Bearer Contexts. The AMF includes Direct Forwarding Flag to inform the SMF of the applicability of indirect data forwarding.
5

If you have deployed the dynamic PCC, the SMF+PGW-C initiates the SMF-initiated SM Policy Modification toward the PCF.

Important 

Cisco SMF does not support this step

6 The PGW-C+SMF sends the N4 Session Modification to PGW-U+UPF to establish the CN tunnel for a PDU Session. The PGW-U+UPF receives the uplink packets from NG-RAN. This step involves creating uplink PDRs and FARs for the 5G session along with the QFIs that are mapped from the existing 4G bearers.
7

The PGW-C+SMF sends a NsmfPDUSessionCreateSMContext Response to the AMF. This response includes PDU Session ID, S-NSSAI, and N2 SM Information.

The N2 SM Information includes PDU Session ID, S-NSSAI, QFIs, QoS Profiles, EPS Bearer Setup List, mapping between EBIs and QFIs, CN Tunnel information, and cause code details.

The SMF includes mapping between EBIs and QFIs as the N2 SM Information container. If the PGW-C-C+SMF determines that session continuity from EPS to 5GS is not supported for the PDU session, then the PGW-C-C+SMF does not provide the Session Manager information for the corresponding PDU session. However, the PGW-C-C+SMF includes the cause code details for rejecting the PDU session transfer in the N2 SM information.

8 The V-SMF and V-UPF establish an N4 session with each other.
9 The AMF sends the Handover Request to NG-RAN.
10 The NG-RAN sends an acknowledgment for the received Handover Request to the AMF.
11

The AMF sends a NsmfPDUSessionUpdateSMContext Request, T-RAN SM N3 forwarding information list message to the SMF for updating the N3 tunnel information.

The NsmfPDUSessionUpdateSMContext request includes a PDU Session ID, S-NSSAI, and N2 SM Information. The tunnel information exists in the NGAP IE DL Forwarding UP TNL Information of the Handoff Request Acknowledgment that is received from NG-RAN.

12 The SMF+PGW-C performs the N4 session modification toward UPF+PGW-U to create the indirect tunnel to forward the DL data from eNodeB to NG-RAN. This step includes creating UL PDRs for the redirected DL data and associating FARs with them to forward the FARs to NG-RAN. The mapping of these PDRs and FARs is based on QFI and the corresponding bearer ID.
13 The PGW-C+SMF sends the NsmfPDUSessionUpdateSMContext Response to the AMF. This response includes PDU Session ID, EPS Bearer Setup List, and CN tunnel information for data forwarding. At this point, the indirect tunnels are established for DL data forwarding.
14 The AMF sends the Forward Relocation Response to the MME.
15 The MME sends the creation request for the indirect data forwarding tunnel to the S-GW. The S-GW sends the response for the indirect data forwarding tunnel to the MME.
EPS to 5G Handover with N26 Interface – Execution Call Flow

This section describes the call flow of the execution of the EPS to 5G Handover with the N26 interface.

Figure 3. Execution Call Flow for the EPS to 5G Handover with the N26 Interface
Table 4. Execution Call Flow Description for the EPS to 5G Handover with the N26 Interface
Step Description
1

Call handover initiation starts from the UE and E-UTRAN toward each other, proceeds from E-UTRAN to S-GW. Then for roaming calls, call handover initiation proceeds from S-GW to the UPF+PGW-C-U.

The MME sends the handover command to E-UTRAN.
2 The E-UTRAN sends the handover command to the UE.
3 The UE sends the confirmation message to NG-RAN for the received handover to 5G-RAN.
4 The NG-RAN sends the Handover Notification message to the AMF.
5 The AMF sends the Forward Relocation Complete Notification to the MME.
6 The MME sends the Acknowledgment Response for the received Forward Relocation Complete Notification.
7 The AMF sends NsmfPDUSessionUpdateSMContext Request to SMF +PGW-C. This request includes Handover Complete Indication for PDU Session ID details. For indirect forwarding, a timer in SMF+PGW-C starts to check when resources in UPF are to be released.
8 The SMF performs N4 Modification Request with UPF+PGW-U to update the DL tunnel information for the FARs that are associated with DL PDRs of the 5G session. The DL data path is activated. At this point, the indirect tunnel also exists.
9 The SMF sends NsmfPDUSessionUpdateSMContext Response, with PDU Session ID, to AMF. The SMF confirms the reception of Handover Complete.
10 After the timer that started in Step 7 expires, the SMF sends N4 Modification Request to UPF. This request is to remove the PDRs and FARs that are associated with the indirect data tunnel.
11 The UE starts the EPS to 5GS mobility registration procedure and sends it to H-PCF.
12 The E-UTRAN performs the resource cleanup in EPC by MME.
UE Idle Mode Mobility from EPS to 5GS using N26 Interface

The SMF and PGW-C support EPS to 5GS Idle Mode Mobility procedure. For Idle Mode Mobility from EPS to 5GS, the UE performs Mobility Registration Update Procedure with AMF. The AMF and SMF retrieve MM and SM contexts from EPS and move UE context from EPS to 5GS by interacting with other core NFs.

This feature enables the EPS and 5GS core network elements to support the following use cases during EPS to 5GS Idle Mode Mobility procedure.

  • UE idle mode mobility from EPS to 5GS using N26 interface - PDU session in inactive state

  • UE idle mode mobility from EPS to 5GS using N26 interface - User Plane connection reactivation request

PDU Session is in Inactive State

The following call flows captures information on UE Idle Mode Mobility from EPS to 5GS using N26 Interface when PDU session is in inactive state.

Figure 4. PDU Session in Inactive State
Table 5. PDU Session in Inactive State

Step

Description

1

AMF sends a POST request towards SMF/PGW-C of each UE EPS PDN connection with following information:

  • UE EPS PDN connection, including the EPS bearer contexts, received from the MME, representing the individual SM context to be created.

  • EPS Bearer Context Status attribute, indicating the status of all the EPS bearer contexts in the UE, if corresponding information is received in the Registration Request from the UE.

2

Upon receipt of such a request, if:

  • a corresponding PDU session is found based on the EPS bearer contexts.

  • the default EPS bearer context of the corresponding PDU session is not reported as inactive by the UE in the EPS Bearer Connection Status attribute, if received; and

  • it is possible to proceed with moving the PDN connection to 5GS.

2a

SMF returns a 201 Created response including the following information:

  • PDU Session ID corresponding to the default EPS bearer ID of the EPS PDN connection.

  • Allocated EBI List, containing the EBI(s) allocated to the PDU session.

The Location header present in the POST response contains the URI of the created SM context resource.

AMF stores the association of the PDU Session ID and the SMF ID, and allocated EBI(s) associated to the PDU Session ID.

If the EPS Bearer Context Status attribute is received in the request, the SMF checks whether some EPS bearer(s) of the corresponding PDU session have been deleted by the UE but not notified to the EPS. If so, SMF releases these EPS bearers, corresponding QoS rules and QoS flow level parameters locally.

2b

SMF returns 4xx/5xx failure response if:

  • SMF determines that seamless session continuity from EPS to 5GS is not supported for the PDU session. SMF sets the cause attribute in the Problem Details structure to NO_EPS_5GS_CONTINUITY.

  • The default EPS Bearer Context of the PDU session is reported as inactive by the UE in the EPS Bearer Context Status attribute. SMF sets the cause attribute in the Problem Details structure to DEFAULT_EPS_BEARER_INACTIVE.

User Plane Connection Reactivation Request

The following call flows captures information on UE idle mode mobility from EPS to 5GS with UP (User Plane) connection reactivation using N26 interface.

Figure 5. User Plane Connection Reactivation Request
Table 6. User Plane Connection Reactivation Request

Step

Description

1

AMF sends a POST request towards SMF/PGW-C of each UE EPS PDN connection with following information:

  • UE EPS PDN connection, including the EPS bearer contexts, received from the MME, representing the individual SM context to be created.

  • the PDU Sessions Activate List attribute, including the PDU Session ID of all the PDU session(s) to be re-activated.

  • EPS Bearer Context Status attribute, indicating the status of all the EPS bearer contexts in the UE, if corresponding information is received in the Registration Request from the UE.

2

Upon receipt of such a request, if:

  • a corresponding PDU session is found based on the EPS bearer contexts.

  • the default EPS bearer context of the corresponding PDU session is not reported as inactive by the UE in the EPS Bearer Context attribute, if received; and

  • it is possible to proceed with moving the PDN connection to 5GS.

2a

SMF returns a 201 Created response including the following information:

  • PDU Session ID corresponding to the default EPS bearer ID of the EPS PDN connection.

  • Allocated EBI List, containing the EBI(s) allocated to the PDU session.

and, if the PDU session that is derived by the SMF based on the EPS bearer contexts was requested to be re-activated, i.e. if the PDU Session ID was present in the PDU Sessions Activate List,

  • the User Plane Connection State attribute is set to ACTIVATING.

  • N2 SM information to request the 5G-AN to assign resources to the PDU session (PDU Session Resource Setup Request Transfer), including the transport layer address and tunnel endpoint of the uplink termination point for the user plane data for this PDU session (i.e. UPF's GTP-U F-TEID for uplink traffic).

The Location header present in the POST response contains the URI of the created SM context resource.

AMF stores the association of the PDU Session ID and the SMF ID, and allocated EBI(s) associated to the PDU Session ID.

If the EPS Bearer Context Status attribute is received in the request, the SMF checks whether some EPS bearer(s) of the corresponding PDU session have been deleted by the UE but not notified to the EPS. If so, SMF releases these EPS bearers, corresponding QoS rules and QoS flow level parameters locally.

2b

SMF returns 4xx/5xx failure response if:

  • SMF determines that seamless session continuity from EPS to 5GS is not supported for the PDU session. SMF sets the cause attribute in the Problem Details structure to NO_EPS_5GS_CONTINUITY.

  • The default EPS Bearer Context of the PDU session is reported as inactive by the UE in the EPS Bearer Context Status attribute. SMF sets the cause attribute in the Problem Details structure to DEFAULT_EPS_BEARER_INACTIVE.

3

If the SMF returns a 200 OK response, the AMF subsequently updates the SM context in the SMF by sending POST request with the following information:

  • N2 SM information received from the 5G-AN (PDU Session Resource Setup Response Transfer IE), including the transport layer address and tunnel endpoint of one or two downlink termination point(s). It also includes the associated list of QoS flows for this PDU session (i.e. 5G-AN's GTP-U F-TEID(s) for downlink traffic), if the 5G-AN succeeded in establishing resources for the PDU sessions; or

  • N2 SM information received from the 5G-AN (PDU Session Resource Setup Unsuccessful Transfer IE), including the Cause of the failure, if resources failed to be established for the PDU session.

Upon receipt of this request, the SMF:

  • Updates the UPF with the 5G-AN's F-TEID(s) and sets the User Plane Connection State attribute to ACTIVATED, if the 5G-AN succeeds in establishing resources for the PDU sessions; or

  • Considers that the activation of the User Plane connection has failed and sets the User Plane Connection State attribute to DEACTIVATED.

4

SMF returns a 200 OK response including the User Plane Connection State attribute representing the final state of the user plane connection.

Message Flows

The following message flow describes the different scenarios of idle mode mobility procedure across 5GS network elements and subscriber.

Figure 6. Message Flow across 5GS NEs and Subscriber

Standards Compliance

The SMF Support for 4G to 5G Data Session Handover feature complies with 3GPP TS 23.502 V15.2.0 (2018-09) standard.

Limitations

The 4G to 5G Data Session Handover feature has the following limitation:

  • SMF supports N26 4G to 5G handoff with single UPF, which implies that UPF selection and UPF modification are not supported.

CHF and PCF Integration for Access and Mobility Procedures

Feature Description


Important

The PGW-C term used in this chapter denote the EPS interworking functionality supported by SMF and must not be assumed as a standalone P-GW that is used in the LTE network.

For the access and mobility procedures, SMF integrates Charging Function (CHF) and Policy Control Function (PCF) for the following procedures:

  • Intra-AMF and Inter-AMF N2-based Handovers—SMF supports this function when a UE moves from one NG-RAN to another NG-RAN for Data Forwarding Tunnel (DFT) and Indirect Data Forwarding Tunnel (IDFT) cases.

  • N26 4G to 5G Handover—SMF supports the EPS to 5GS procedures with the N26 interface. SMF establishes Uplink (UL) Packet Detection Rule (PDR) or Downlink (DL) PDR toward with the qualified EPS Bearer Identity (EBI) list in 5GS and replicates EBIs to the respective flows. SMF also creates IDFT to support the Downlink forwarding traffic between SGW-U to NR over UPF.

  • N26 5G to 4G Handover—SMF supports 5GS to EPS procedures with the N26 interface. PGW-C establishes UL PDRs or DL PDRs toward SGW-U with qualified flows in 5GS and replicates EBIs to respective flows. PGW-C also creates an IDFT tunnel to support Downlink forwarding traffic between NR to SGW-U over UPF. Session-Level or Rating-Group level Charging Triggers are received during PDU Session establishment or in response to SMF-initiated Charging Update Request or CHF-initiated Charging Update Notify response in EPS procedures.

  • Xn Handover—SMF supports the Xn-based inter NG-RAN handover with and without UPF reallocation. The SMF supports Xn handovers for intra-AMF mobility only. SMF processes the received SM context update request that includes the path switch request N2-based message and the access-side parameters. These parameters identify the CHF and PCF triggers that are received during PDU session establishment.

  • Service Request Procedures—SMF supports the service requests from both the UE and network-initiated procedures. Either a UE in CM-Idle state or the 5GC uses the Service Request procedure to request the establishment of a secure connection to an AMF. The UE in both the CM-Idle and in CM-Connected state use the Service Request procedure to activate a User Plane connection for an established PDU Session. The UE does not initiate a Service Request procedure if an ongoing Service Request procedure exists.

SMF saves the CHF and PCF triggers that it receives as part of session creation or PCF or UE-initiated modifications. When a UE triggers access and mobility procedures for the preceding functions, SMF identifies the triggers from CHF and PCF against the received access parameters. Then, SMF sends an update toward CHF and PCF.

How it Works

The SMF integrates the CHF and PCF functions based on the following information:

  • Policy control request triggers, which are received in the SM policy decision during PDU session establishment or PCF or UE-initiated modification.

  • Session-level or rating-group-level charging triggers, which are received during PDU session establishment or in response to SMF-initiated Charging Update Request or CHF-initiated Charging Update Notify Request.

The SMF supports the following access-side information to detect the PCF and CHF triggers. The SMF sends the trigger information to the CHF and PCF during the N2-based handover.

Table 7. Access-Side Information for PCF and CHF Triggers

Access Side Information

CHF Triggers

PCF Triggers

UserLocation

USER_LOCATION_CHANGE

SAREA_CH

UeTimeZone

UE_TIMEZONE_CHANGE

SAREA_CH

ServingNetwork

PLMN_CHANGE

PLMN_CH

TargetServingNfId

SERVING_NODE_CHANGE

For a change in the subscriber location, the SMF sends USER_LOCATION_CHANGE trigger towards CHF and SAREA_CH trigger towards PCF.

The SMF generates the usage report whenever a change in the subscriber location is detected in the following messages:

  • Delete Bearer Command

  • Delete Bearer Response

  • Modify Bearer Request

For example, when a Delete Bearer Command is received with a new ULI, a CDR event is triggered with new ULI. If PCF or CHF has armed notification for ULI modifications, the SMF sends a notification to the PCF and CHF respectively.

This feature is compliant with the 3GPP TS 32.291, version 15.4.0.

Call Flows

This section describes the following call flows:

  • CHF and PCF Integration for Intra-AMF and Inter-AMF N2-Based Handovers Call Flow

  • CHF and PCF Integration for N26 4G to 5G Handover Call Flow

  • CHF and PCF Integration for N26 5G to 4G Handover Call Flow

  • CHF and PCF Integration for Xn Handover Call Flow

  • CHF and PCF Integration for Service Request Procedures

Intra-AMF and Inter-AMF N2-Based Handovers Call Flow

This section describes the intra-AMF and inter-AMF N2-based handover call flow to support CHF and PCF integration.

Figure 7. Intra-AMF and Inter-AMF N2-Based Handovers Call Flow
Table 8. CHF and PCF Integration for Intra-AMF and Inter-AMF N2-Based Handovers Call Flow Description
Step Description
1

The PDU session establishes over S-AMF and SMF by communicating with UPF, PCF, or CHF for IPv4, IPv6, or dual-stack.

The PCF provides Policy Control Request trigger for SM policy decision as response to the request for creation of SM policy control.

The CHF sends session-level and rating-group-level triggers to SMF as the Charging Data Create Response.
2 The T-AMF sends SM Context Update Request by including handover state to the SMF. The handover state includes the information on preparation, UE location, UE time zone, target serving NFID, and serving network. The AMF includes target serving NFID information for inter-AMF handoff.
2a The SMF detects access-side changes that are received in the SM Context Update Request and the charging triggers with the information that is available in Step 2.
2b The SMF detects the PCF triggers with the information that is available in Step 2.
3 The N2-based Handover Preparation procedure starts from T-AMF towards the SMF and CHF and the opposite direction.
4 In the N2-based Handover Execution procedure, in case of inter-AMF handoff, the SMF receives SM Context Release Request from S-AMF and responds with the SM Context Release Response to the S-AMF.
5 In N2-based Handover Execution procedure, the UPF provides the usage report as part of N4 modification response. The SMF holds the final SM Context Release Response when the SMF detects the CHF or PCF triggers.
6 The SMF sends the Charging Data Update Request to the CHF. This request includes the information on session-level triggers, multi-unit-information (with rating-group-level triggers with usage report), customer identification, and PDU session charging information.
7 The CHF sends the Charging Data Update Response with optional multi-unit-information. The CHF also sends the new session or rating-group-level triggers to the SMF.
7a The SMF processes the Charging Data Update Response and updates the PDU session. The SMF does not send the N4 modification request to the UPF for the newly received information from the CHF.
8 The SMF posts the internal transaction to send the SM policy update information for PCF triggers.
9 The SMF sends the SM Context Update Response, for which the handover state is complete, to the T-AMF.
10 The SMF sends the SM Policy Control Update information to the PCF. The SM Policy Control Update information includes details, such as the user location information, UE time zone, and serving network.
11 The PCF sends the SM Policy Control Update Response, which is the SM policy decision, to the SMF.
12 The SMF processes the SM policy decision that is received as response and triggers the PCF-initiated modification procedure..
CHF and PCF Integration for N26 4G to 5G Handover Call Flow

This section describes the call flow for the CHF and PCF Integration for N26 4G to 5G handovers.

Figure 8. CHF and PCF Integration for N26 4G to 5G Handover Call Flow
Table 9. CHF and PCF Integration for N26 4G to 5G Handover Call Flow Description
Step Description
1

The PDU session is established over MME, SGW, and SMF by communicating with UPF, PCF, or CHF for IPv4, IPv6, or dual-stack.

The PCF provides Policy Control Request trigger for SM policy decision as response to the request for creation of SM policy control.

The CHF provides session-level and rating-group-level triggers to SMF as the Charging Data Create Response.
2

The T-AMF sends SM Context Create Request to the SMF. This request includes information on handover state as preparing, UE location, UE time zone, serving NFID, serving network, and RAT type.

2a The SMF detects access-side changes that are received in the SM Context Create Request and the charging triggers with the information that is available in Step 2.
2b The SMF detects the PCF triggers with the information that is available in Step 2.
3 The N26-based Handover Preparation procedure starts from T-AMF toward the SMF or PGW-C and UHF and the opposite way, as defined in 3GPP TS 23.502, section 4.1.9.3.
4 In the N26 Handover Execution procedure, the UPF sends the usage report as part of N4 modification response to SMF. The SMF holds the final SM Context Update Response when the SMF detects the CHF or PCF triggers.
5 The SMF sends the Charging Data Update Request to the CHF. This request includes the information on session-level triggers, multi-unit-Information (with rating-group-level triggers and usage report), customer identification, and PDU session charging information.
6 The CHF sends the Charging Data Update Response with optional multi-unit-information. The CHF also sends the new session or rating-group-level triggers to the SMF.
6a The SMF processes the Charging Data Update Response and updates the PDU session. The SMF does not send the N4 modification request to the UPF for the newly received information from the CHF.
7 The SMF posts the internal transaction to send the SM policy update information for PCF triggers.
8 The SMF sends the SM Context Update Response, for which the handover state is complete, to the AMF.
9 The SMF sends the SM Policy Control Update information to the PCF. The SM Policy Control Update includes details, such as the user location information, UE time zone, and serving network.
10 The PCF sends the SM Policy Control Update Response, which is the SM policy decision, to the SMF.
11 The SMF processes the SM policy decision that is received as response and handles the response as PCF Initiation Modify procedure, as defined in 3GPP TS 23.502, section 4.3.3.2.
CHF and PCF Integration for N26 5G to 4G Handover Call Flow

This section describes the call flow for the CHF and PCF Integration for N26 5G to 4G handovers.

Figure 9. CHF and PCF Integration for N26 5G to 4G Handover Call Flow
Table 10. CHF and PCF Integration for N26 5G to 4G Handover Call Flow Description
Step Description
1

The PDU session is established over S-AMF or SMF by communicating with UPF, PCF, or CHF for IPv4, IPv6, or dual-stack.

The PCF provides Policy Control Request trigger for SM policy decision as response to the request for creation of SM policy control.

The CHF provides session-level and rating-group-level triggers to SMF as the Charging Data Create Response.
2 The 5G to 4G Handover procedure starts from AMF toward the SMF or PGW-C and the opposite way. AMF initiates the SM Context Retrieve Request to establish the UL PDRs and send SM Context Update Response to start the IDFT tunnel, if necessary.
3 In the N26 5G to 4G Handover Execution procedure, the SGW sends the GTPv2 Modify Bearer Request to PGW-C. This request includes the information on UE location, UE time zone, RAT type, and Bearer Context List.
3a The SMF detects access-side changes that are received in the SM Context Update Request and the charging triggers with the information that is available in Step 3.
3b The SMF detects the PCF triggers with the information that is available in Step 3.
4 In the N26 Handover 5G to 4G Execution procedure, the PGW-C requests UPF to create a GTP-U tunnel for each flow. This tunnel is for the EBIs received in the Bearer Context List of GTPv2 Modify Bearer Request. After the DL PDRs are established, UPF sends the usage report as part of N4 modification response to SMF. The SMF holds the final GTPv2 Modify Bearer Response when the SMF detects the CHF or PCF triggers.
5 The SMF sends the Charging Data Update Request to the CHF. This request includes the information on session-level triggers, multi-unit-Information (with rating-group-level triggers and usage report), customer identification, and PDU session charging information.
6 The CHF sends the Charging Data Update Response with optional multi-unit-information. The CHF also sends the new session or rating-group-level triggers to the SMF.
6a The SMF or PGW-C processes the Charging Data Update Response and updates the PDU session. The SMF does not send the N4 modification request to the UPF for the newly received information from the CHF.
7 The SMF or PGW-C posts the internal transaction to send the SM policy update information for PCF triggers.
8 The SMF or PGW-C sends the SM Context Update Response, for which the handover state is complete, to the AMF.
9 The SMF or PGW-C sends the SM Policy Control Update information to the PCF. The SM Policy Control Update includes details, such as the user location information, UE time zone, and serving network.
10 The PCF sends the SM Policy Control Update Response, which is the SM policy decision, to the SMF.
11 The SMF processes the SM policy decision that is received as response and handles the response as PCF Initiation Modify procedure, as defined in 3GPP TS 23.502, section 4.3.3.2.
CHF and PCF Integration for Xn Handover Call Flow

This section describes the call flow for the CHF and PCF Integration for the Xn handover.

Figure 10. CHF and PCF Integration for Xn Handover Call Flow
Table 11. CHF and PCF Integration for Xn Handover Call Flow Description
Step Description
1

The PDU session is established over MME, SGW, and SMF by communicating with UPF, PCF, or CHF for IPv4, IPv6, or dual-stack.

The PCF provides Policy Control Request trigger for SM policy decision as response to the request for creation of SM policy control.

The CHF provides session-level and rating-group-level triggers to SMF as the Charging Data Create Response.
2 The AMF sends SM Context Update Request to the SMF. The SM Context Update Request includes the information on UE location, UE time zone, and path switch request N2 message.
2a The SMF detects access-side changes that are received in the SM Context Update Request and the charging triggers with the information that is available in Step 2.
2b The SMF detects the PCF triggers with the information that is available in Step 2.
3

The Xn Handover Preparation procedure starts from SMF toward UPF and the opposite way, as defined in 3GPP TS 23.502, section 4.9.1.2.

SMF sends the N4 Modification Request to UPF and updates the received DL tunnel information of T-gNB. After the tunnel information is updated, UPF provides the usage report as part of N4 modification response. The SMF holds the final SM Context Update Response when the SMF detects the CHF or PCF triggers.

4 The SMF sends the Charging Data Update Request to the CHF. This request includes the information on session-level triggers, multi-unit-Information (with rating-group-level triggers and usage report), customer identification, and PDU session charging information.
5 The CHF sends the Charging Data Update Response with optional multi-unit-information. The CHF also sends the new session or rating-group-level triggers to the SMF.
5a The SMF processes the Charging Data Update Response and updates the PDU session. The SMF does not send the N4 modification request to the UPF for the newly received information from the CHF.
6 The SMF posts the internal transaction to send the SM policy update information for PCF triggers.
7 The SMF sends the SM Context Update Response to the AMF. This response includes the path switch request acknowledgment N2 message.
8 The SMF sends the SM Policy Control Update information to the PCF. The SM Policy Control Update includes details, such as the user location information and UE time zone.
9 The PCF sends the SM Policy Control Update Response, which is the SM policy decision, to the SMF.
10 The SMF processes the SM policy decision that is received as response and handles the response as PCF Initiation Modify procedure, as defined in 3GPP TS 23.502, section 4.3.3.2.
CHF and PCF Integration for Service Request Procedures

This section describes the CHF and PCF integration for service request procedures.

SMF processes the received SM Context Update Request to update N3 tunnel path state from Idle to Active or Active to Idle. SMF performs the following steps:

  1. When UE is in CM-Idle state at AMF, which is Active to Idle mode—Based on the configuration, SMF updates UPF for N3 tunnel state to drop or buffer by sending the N4 session mode request. Based on charging configuration, SMF receives a usage report. Based on the Charging Triggers that qualify during session creation, SMF sends the N40 Charging Update request.

  2. When UE is in CM-Connected state at AMF, which implies SMF receives UE-requested Procedures to change the subscriber N3 Tunnel Path from Idle to Active State—SMF receives the updated user location and UE time zone in the SM Context Update Request. SMF sends the N4 Session Modification Request to UPF to update the DL tunnel details of gNB. Based on charging configuration, SMF receives a usage report. Based on the Charging Triggers that qualify during session creation, SMF sends the N40 Charging Update request.

  3. When the N3 Tunnel is unavailable for the Network Service Request Triggers, which implies that UE is in CM-Idle state at AMF—SMF initiates the Network Service Request Procedures for AMF to initiate Paging toward the end user. Then, AMF begins the UE Service Request Procedures to configure the N3 Tunnel as specified in Step 2.

Standards Compliance

The CHF and PCF integration for access and mobility procedures feature complies with the following standards:

  • 3GPP TS 23.502 version 15.4.0 Release 15 (sections 4.9.1.3, 4.11.1.2, 4.9.1.2, and 4.2.3)—5G; Procedures for the 5G System

Inter gNodeB Handover

Feature Description

The SMF supports the Xn-based and N2-based handover procedures to hand over a UE from a source NG-RAN node to a target NG-RAN node using the Xn or N2 reference points. Initiation of this procedure can be due to new radio conditions, load balancing or due to a specific service.

The SMF releases the QoS flows that failed to set up on the target NG-RAN during Xn and N2 handovers on the respective interfaces N4 (UPF) and N1 (UE). The SMF sends appropriate notification to N7 (PCF) based on the triggers if armed. The SMF also sends the usage report to N40 (CHF) for the released QoS flows.

How it Works

Call Flows

The following sections explain the execution of Xn-based and N2-based handover procedures.

Xn-based Inter NG-RAN Handover

This section provides details regarding the Xn-based inter NG-RAN handover without UPF reallocation.

The handover preparation and the execution stages are implemented as specified in 3GPP TS 38.300. When performing the handover in a shared network, the source NG-RAN determines a PLMN to be used in the target network as specified in 3GPP TS 23.501. If the serving PLMN changes during the Xn handover, the source NG-RAN node indicates the selected PLMN ID to the target NG-RAN node.

If the AMF generates the N2 downlink signalling and receives a rejection to an N2 interface procedure due to the ongoing Xn handover procedure, the AMF reattempts the same N2 interface procedure either when the handover is complete or the handover is deemed to have failed. The failure is known by expiry of the timer guarding the N2 interface procedure.

Upon reception of an SMF-initiated N1 and/or N2 request(s) with an indication that the request has been temporarily rejected due to the ongoing Xn handover procedure, the SMF starts a locally configured guard timer. The SMF holds signalling messages targeted towards the AMF during the handover preparation phase unless it detects that the handover is completed or the handover has failed or cancelled. The SMF reattempts, up to a pre-configured number of times, when either it detects that the handover is completed or has failed using message reception or at expiry of the guard timer.

The Xn-based inter NG-RAN handover is used to hand over a UE from a source NG-RAN to target NG-RAN using Xn when the AMF is unchanged and the SMF decides to keep the existing UPF.

The following figure depicts the call flow of the Xn-based inter NG-RAN handover without the UPF reallocation.

Figure 11. Xn-based Inter NG-RAN Handover without UPF Reallocation
Table 12. Xn-based Inter NG-RAN Handover Call Flow Description (Without UPF Reallocation)

Step

Description

1a

During the handover execution, the source NG-RAN node provides RAN usage data Report to the AMF. The source NG-RAN node provides this report only when the target NG-RAN has confirmed handover over Xn interface.

This report includes N2 SM Information (Secondary RAT usage data), Handover Flag, and Source to Target transparent container. The Handover Flag indicates that the report needs to be buffered by the SMF.

1b

The target NG-RAN sends an N2 Path Switch Request message to the AMF to inform that the UE has moved to a new target cell. The NG-RAN provides a List Of PDU Sessions To Be Switched. The N2 SM Information includes the AN Tunnel Info for each PDU Session to be switched.

2

The AMF sends N2 SM information by invoking the Nsmf_PDUSession_UpdateSMContext request service operation for each PDU session in the lists of PDU Sessions received in the N2 Path Switch Request.

3

The SMF sends an N4 Session Modification Request message to the UPF. The SMF may notify the UPF that originated the Data Notification to discard downlink data for the PDU Sessions and/or to not provide further Data Notification messages.

4

The UPF returns an N4 Session Modification Response message to the SMF after the requested PDU sessions are switched.

5

The UPF sends one or more "end marker" packets for each N3 tunnel on the old path immediately after switching the path. The UPF starts sending downlink packets to the target NG-RAN.

6

The SMF sends an Nsmf_PDUSession_UpdateSMContext response (CN Tunnel Info) to the AMF for PDU sessions which have been switched successfully.

Important 

Step 6 can occur any time after the receipt of N4 Session Modification Response at the SMF.

7

Once the Nsmf_PDUSession_UpdateSMContext response is received from all the SMFs, the AMF aggregates the received CN Tunnel Info and sends this aggregated information as a part of N2 SM Information along with the Failed PDU Sessions in N2 Path Switch Request Ack to the target NG-RAN. If none of the requested PDU sessions have been switched successfully, the AMF sends an N2 Path Switch Request Failure message to the target NG-RAN.

8

The target NG-RAN confirms success of the handover by sending Release Resources message to the source NG-RAN.

9

The UE initiates Mobility Registration Update procedure if one of the triggers of registration procedure applies.

The following figure shows the detailed call flow of the Xn handover without UPF reallocation.

Figure 12. Xn Handover Without UPF Relocation Call Flow
Table 13. Detailed Call Flow Description for the Xn Handover Without UPF Relocation

Step

Description

1

The NF Service Consumer (AMF) requests the SMF to switch the user plane connection of the PDU session. The AMF sends a POST request with the following information:

  • The toBeSwitched indication.

  • N2 SM information received from the 5G-AN (PDU session path switch request transfer IE), including the new transport layer address and tunnel endpoint of the downlink termination point for the user data for this PDU session.

  • User location and user location timestamp.

  • Other information, if necessary.

2

The SMF switches the N3 tunnel of the PDU session after receiving the request. The SMF initiates PFCP session modification procedure toward the UPF with downlink FAR updated with the following option:

  • Forwarding Action is enabled with the remote node “forwarding parameters” details, such as the IP address and GTP-U F-TEID.

3

The SMF marks the PDU handover as successful after receiving the successful response from the UPF node.

4

The SMF initiates the 200 OK response. This response includes the N2 SM information, which has the transport layer address and tunnel endpoint of the uplink termination point for the user plane data for this PDU session, that is UPFs GTP-U F-TEID for the uplink traffic.

N2-based Inter NG-RAN Handover

The source NG-RAN decides to initiate an N2-based handover (HO) to the target NG-RAN. Initiation of this procedure could be due to any of the following reasons:

  • New radio conditions

  • Load balancing

  • If there is no Xn connectivity to the target NG-RAN

  • An error indication from the target NG-RAN after an unsuccessful Xn-based handover (that is, no IP connectivity between Target RAN (T-RAN) and Source UPF (S-UPF))

  • Based on dynamic information learnt by the Source RAN (S-RAN)

The source NG-RAN determines the availability of a direct forwarding path and indicates the same to the SMFs. If the IP connectivity is available between the source and target NG-RAN and security association is in place between them, a direct forwarding path is available. If a direct forwarding path is not available, use the indirect forwarding. The SMFs use the indication from the source NG-RAN to choose the data forwarding path.

When performing the handover in a shared network, the source NG-RAN determines a PLMN for use in the target network as specified by 3GPP TS 23.501. The source NG-RAN indicates the selected PLMN ID to the AMF as part of the Tracking Area sent in the HO Required message.

If the AMF generates the N2 downlink signalling and receives a rejection to a N2 interface procedure due to the ongoing N2 handover, the AMF reattempts the same N2 interface procedure either when the handover is complete or the handover is deemed to have failed. If the Inter NG-RAN node handover changes the serving AMF, the source AMF terminates any other ongoing N2 interface procedures except the handover procedure.

If the AMF is still the serving AMF, the AMF pauses non-handover related N2 interface procedures and resumes them after the N2 handover is complete.

If the AMF detects that it needs to be changed, the AMF rejects any SMF-initiated N2 request and includes an indication that the request has been temporarily rejected due to the ongoing N2 handover procedure.

The following figure depicts the call flow for the preparation phase of the N2-based inter NG-RAN handover procedure.

Figure 13. Inter NG-RAN Node N2-based Handover - Preparation Phase
Table 14. Inter NG-RAN Node N2-based Handover Call Flow Description - Preparation Phase

Step

Description

1

The Source NG-RAN (S-RAN) sends the Handover Required message to the Source AMF (S-AMF). This message includes the following:

  • Target ID

  • Source to Target transparent container

  • SM N2 info list

  • PDU Session IDs

  • Intra system handover indication

The Source to Target transparent container includes NG-RAN information for use in Target RAN (T-RAN), and is transparent to 5GC. It also contains the corresponding User Plane Security Enforcement information, QoS flows/DRBs information subject to data forwarding.

If direct data forwarding is available, the SM N2 info includes Direct Forwarding Path Availability.

Direct Forwarding Path Availability indicates whether direct forwarding is available from the S-RAN to the T-RAN. This indication from S-RAN is based on the presence of IP connectivity and security association between the S-RAN and the T-RAN.

2

When the S-AMF cannot serve the UE anymore, the S-AMF selects the T-AMF as described in clause 6.3.5 on "AMF Selection Function" in TS 23.501.

3

The S-AMF initiates Handover resource allocation procedure by invoking the Namf_Communication_CreateUEContext service operation towards the T-AMF.

The Namf_Communication_CreateUEContext Request includes the following:

  • N2 Information

    • Target ID

    • Source to Target transparent container

    • SM N2 information list

    • PDU Session IDs

  • UE context information

    • SUPI

    • Service area restriction

    • Allowed NSSAI for each Access Type if available

    • Tracing Requirements

    • The list of PDU Session IDs along with the corresponding SMF information and the corresponding S-NSSAI(s), PCF ID(s), and DNN

When the S-AMF can still serve the UE, this step and step 12 are not needed.

4

For each PDU session indicated by S-RAN, the AMF invokes the Nsmf_PDUSession_UpdateSMContext Request to the associated SMF. However, if the S-NSSAI associated with PDU session is not available in the T-AMF, the T-AMF does not invoke Nsmf_PDUSession_UpdateSMContext for this PDU session.

If the T-AMF detects that the UE moves into a restricted area based on Service area restrictions, the T‑AMF notifies that the UE is only reachable for regulatory prioritized services to each NF consumer which has subscribed for UE reachability event.

5

Based on the Target ID, the SMF checks the acceptance of N2 handover for the indicated PDU session. The SMF also checks the UPF Selection Criteria. If the UE has moved out of the service area of the UPF connecting to NG-RAN, the SMF selects a new intermediate UPF.

6a

If the SMF selects a new UPF to act as intermediate UPF for the PDU session, and the different CN Tunnel Info need to be used, the SMF sends N4 Session Modification Request message to UPF (PDU Session Anchor (PSA)). If the SMF allocates the CN Tunnel Info, it provides the CN Tunnel Info on N9, and the UPF (PSA) associates CN Tunnel Info with UL Packet detection rules.

6b

The UPF (PSA) sends an N4 Session Establishment Response message to the SMF. If the UPF (PSA) allocates CN Tunnel Info (on N9) of UPF (PSA), it provides CN Tunnel Info (on N9) to the SMF. The UPF (PSA) associates the CN Tunnel Info (on N9) with UL Packet detection rules provided by the SMF.

6c

If the SMF selects a new intermediate UPF (T-UPF) and if the T-UPF allocates the CN Tunnel Info, the SMF sends an N4 Session Establishment Request message to the T-UPF. This request enables the Packet detection, enforcement, and reporting rules to be installed on the T-UPF. The T-UPF receives the CN Tunnel Info (on N9) of UPF (PSA) for this PDU session, which is used to set up N9 tunnel.

6d

The T-UPF sends an N4 Session Establishment Response message to the SMF with DL CN Tunnel Info and UL CN Tunnel Info (that is, N3 tunnel info). The SMF starts a timer to release the resource of S-UPF, which is to be used in step 13a of the Execution Phase.

7

If N2 handover for the PDU session is accepted, the SMF includes the N2 SM Information in the Nsmf_PDUSession_UpdateSMContext response. The N2 SM Information contains the N3 UP address and the UL CN Tunnel ID of the UPF and the QoS parameters indicating that the N2 SM Information is for the Target NG-RAN.

If the N2 SM information received at step 4 does not include the Direct Forwarding Path Availability and the SMF knows that there is no indirect data forwarding connectivity between source and target, the N2 SM Information includes a Data forwarding not possible indication.

If the N2 handover for the PDU session is not accepted as described in step 5, the SMF does not include the N2 SM Information to avoid establishment of radio resources at the target NG-RAN. The SMF provides a reason for non-acceptance. If the SMF receives notification from T-AMF that UE is only reachable for regulatory prioritized service, the SMF deactivates the PDU session.

8

The AMF supervises the Nsmf_PDUSession_UpdateSMContext Response messages from the involved SMFs. At the expiry of maximum wait time or when all Nsmf_PDUSession_UpdateSMContext Response messages are received, the AMF continues with the N2 Handover procedure (Handover Request message in step 9).

9

If the subscription information includes Tracing Requirements, the target AMF provides the target RAN with Tracing Requirements in the Handover Request.

The Handover request includes Source to Target transparent container, N2 MM Information, N2 SM Information list, and Tracing Requirements.

The T-AMF determines T-RAN based on Target ID. T-AMF allocates a 5G-GUTI valid for the UE in the AMF and target TAI.

N2 MM Information includes, for example, security information and Mobility Restriction List if available in the T-AMF. N2 SM Information list includes N2 SM Information for the T-RAN in the Nsmf_PDUSession_UpdateSMContext Response messages received within allowed max delay supervised by the T-AMF in step 8.

10

The T-RAN sends Handover Request Acknowledge to the T-AMF. The Acknowledge message includes Target to Source transparent container, List of PDU Sessions to Hand-over with N2 SM information, List of PDU Sessions that failed to be established with the failure cause given in the N2 SM information element.

11a

The AMF sends Nsmf_PDUSession_UpdateSMContext Request (PDU Session ID, N2 SM response) to the SMF.

For each N2 SM response received from the T-RAN, the AMF sends the N2 SM response to the SMF indicated by the respective PDU Session ID.

If no new T-UPF is selected, the SMF stores the N3 tunnel info of T-RAN from the N2 SM response if N2 handover is accepted by T-RAN.

The SMF/UPF allocates the N3 UP address and Tunnel IDs for indirect data forwarding corresponding to the data forwarding tunnel endpoints established by T-RAN.

If a PDU session is indicated as a rejected PDU session by the Target NG-RAN, the SMF triggers the release of this PDU session. In all other cases of PDU Session rejection, the SMF decides whether to release the PDU session or to deactivate the UP connection of this PDU session.

If some of the QoS Flows of a PDU Session are not accepted by the Target NG-RAN, the SMF initiates the PDU Session Modification procedure to remove the non-accepted QoS Flows from the PDU Session(s) after the handover is completed.

11b

The SMF sends N4 Session Modification Request to the T-UPF. This request includes T-RAN SM N3 forwarding Information list, and indication to allocate DL forwarding tunnel(s) for indirect forwarding.

11c

The T-UPF allocates Tunnel Info and returns an N4 Session Modification Response message to the SMF. The T-UPF SM N3 forwarding info list includes T-UPF N3 address, T-UPF N3 Tunnel identifiers for forwarding data.

11d

The SMF sends N4 Session Modification Request to the S-UPF. This request includes T-RAN SM N3 forwarding Information list or T-UPF SM N3 forwarding Information list, and an indication to allocate DL forwarding tunnel(s) for indirect forwarding.

11e

The S-UPF allocates Tunnel Info and returns an N4 Session establishment Response message to the SMF.

The S-UPF SM N3 forwarding Information list includes S-UPF N3 address and S-UPF N3 Tunnel identifiers for DL data forwarding.

11f

The SMF sends an Nsmf_PDUSession_UpdateSMContext Response message per PDU session to the T-AMF.

12

The AMF supervises the Nsmf_PDUSession_UpdateSMContext Response message from the involved SMFs. At the expiry of maximum wait time or when all Nsmf_PDUSession_UpdateSMContext Response messages are received, the T-AMF sends the Namf_Communication_CreateUEContext Response to the S-AMF.

The following figure depicts the call flow for the execution phase of the N2-based inter NG-RAN handover procedure.

Figure 14. Inter NG-RAN Node N2-based Handover - Execution Phase
Table 15. Inter NG-RAN Node N2-based Handover Call Flow Description - Execution Phase

Step

Description

1

The Source AMF (S-AMF) sends the Handover Command to the Source NG-RAN (S-RAN).

The Handover Command includes Target to Source transparent container, List Of PDU Sessions to be handed-over with N2 SM information containing information received from T-RAN during the handover preparation phase, and List Of PDU Sessions failed to be set up.

The SM forwarding info list includes T-RAN SM N3 forwarding info list for direct forwarding or S-UPF SM N3 forwarding info list for indirect data forwarding.

The S-RAN uses the PDU Sessions failed to be setup list and the indicated reason for failure to decide whether to proceed with the N2 handover procedure.

2

The S-RAN sends Handover Command (UE container) to the UE.

The UE container is a UE part of the Target to Source transparent container which is sent transparently from T-RAN via AMF to S-RAN and is provided to the UE by the S-RAN.

2a - 2c

The S-RAN sends the Uplink RAN Status Transfer message to the S-AMF. The S-RAN refrains from sending this message if none of the radio bearers of the UE are treated with Packet Data Convergence Protocol (PDCP) status preservation.

3

The T-RAN sends the uplink packets to the T-UPF and UPF (PSA). The UPF (PSA) sends the downlink packets to the S-RAN via S-UPF.

The S-RAN forwards the downlink data towards the T-RAN for QoS flows or Data Radio Bearers (DRBs) subject to data forwarding. The data forwarding path is either direct (step 3a) or indirect forwarding (step 3b).

4

After the UE has successfully synchronized to the target cell, it sends a Handover Confirm message to the T-RAN.

5

The T-RAN sends Handover Notify message to the T-AMF. This message is sent to indicate that the handover is successful.

6a.

The T-AMF notifies to the S-AMF about the N2 handover notify received from the T-RAN by invoking the Namf_Communication_N2InfoNotify.

The S-AMF uses a timer to supervise the release of resources in S-RAN.

6b

The S-AMF acknowledges by sending the Namf_Communication_N2InfoNotify ACK to the T-AMF.

6c

The S-AMF sends Nsmf_PDUSession_ReleaseSMContext Request to the SMF. This request includes SUPI, PDU Session ID, and N2 SM Information (Secondary RAT Usage Data).

If the PDU Session(s) is not accepted by the T-AMF, the S-AMF triggers PDU Session Release procedure after the reception of N2 Handover Notify.

7

The T-AMF sends Nsmf_PDUSession_UpdateSMContext Request to the SMF. This request includes Handover Complete indication for PDU Session ID, UE presence in LADN service area, and N2 SM Information (Secondary RAT usage data).

The T-AMF sends Handover Complete indication per each PDU Session to the corresponding SMF to indicate the success of the N2 handover.

8a

If a new T-UPF is inserted or an existing intermediate S-UPF is reallocated, the SMF sends N4 Session Modification Request indicating DL AN Tunnel Info of T-RAN to the T-UPF.

8b

The T-UPF acknowledges by sending N4 Session Modification Response message to the SMF.

9a

If the UPF is not reallocated, the SMF sends N4 Session Modification Request indicating DL AN Tunnel Info of T-RAN to the S-UPF.

9b

The S-UPF acknowledges by sending N4 Session Modification Response message to SMF.

10a

For non-roaming or local breakout roaming scenario, the SMF sends N4 Session Modification Request message to PDU Session Anchor UPF, UPF (PSA). If a new T-UPF is inserted or an existing intermediate S-UPF is reallocated, the SMF provides N3 AN Tunnel Info of T-RAN or the DL CN Tunnel Info of T-UPF.

If the T-UPF is not inserted or an existing intermediate S-UPF is not reallocated, skip the step 10a and step 10b.

10b

The UPF (PSA) sends N4 Session Modification Response message to the SMF.

When there are multiple UPFs (PSA), perform step 10a and step 10b for each UPF (PSA).

11

The SMF sends Nsmf_PDUSession_UpdateSMContext Response (PDU Session ID) to the T-AMF. The SMF confirms reception of Handover Complete.

12

The UE initiates Mobility Registration Update procedure as defined in 3GPP TS 23.502.

13a

If there is a source intermediate UPF, the SMF initiates resource release by sending an N4 Session Release Request (Release Cause) to the source UPF. This message is also used to release the indirect data forwarding resource in the S-UPF.

13b

The S-UPF acknowledges with an N4 Session Release Response message to confirm the release of resources.

In case of indirect data forwarding, the resource of indirect data forwarding is also released.

14a

After the expiry of timer (defined in step 6a), the AMF sends UE Context Release Command.

14b

The source NG-RAN releases its resources related to the UE and responds with a UE Context Release Complete () message.

15a

If indirect forwarding applies and the UPF is reallocated, after the timer of indirect data forwarding expires, the SMF sends N4 Session Modification Request to the T-UPF. Then, the T-UPF releases the indirect data forwarding resources.

15b

The T-UPF acknowledges with an N4 Session Modification Response message to confirm the release of indirect data forwarding resources.

Limitations

The Xn-based handover with UPF reallocation is currently not supported.

OAM Support

This section describes the operations, administration, and maintenance information for this feature.

Statistics Support

The "smf_ran_failed_flows" metric is added to identify the number of QoS flows released by RAN as part of various call flow procedures including the Xn and N2 handover procedures.

The SMF uses the "xn_handover" label to account for Xn handovers. Similarly for the N2 handovers, the SMF uses the "n2_handover" label.

Wi-Fi Handover

Feature Description


Important

The PGW-C term used in this chapter denote the EPS interworking functionality supported by SMF and must not be assumed as a standalone P-GW that is used in the LTE network.

The SMF+PGW-C product supports Wi-Fi handovers. The cloud-based architecture supports the following Wi-Fi handovers in 5GS or EPS and non-3GPP untrusted access.

  • EPC to non-3GPP untrusted Wi-Fi handover

  • Non-3GPP untrusted Wi-Fi to EPC handover

  • Non-3GPP untrusted Wi-Fi to 5GS handover with EPS fallback

  • Non-3GPP untrusted Wi-Fi to 5GS handover

  • 5GS to non-3GPP untrusted Wi-Fi handover

Handover Indication Support

The SMF+IWF rejects the Create Session Request received with handover (HO) indication even if the session does not exist. This support is applicable only to the 4G and Wi-Fi sessions.

The gtpc message-handling create-session-request ho-ind new-call-reject CLI command under access profile rejects the call with "Context Not Found".

For more information, see the Configuring Calls with Handover Indication section.

Architecture

The following sections describe the architecture for interworking between the ePDG or EPC and 5GS and the nonroaming architecture within the EPS using S5 and S2b interfaces.

ePDG and 5GS Interworking for Handover

The following figure illustrates the non-roaming architecture for interworking between the ePDG or EPC and 5GS.

Figure 15. Non-roaming Architecture for Interworking between ePDG or EPC and 5GS

The interworking between the ePDG and 5GS is similar to the interworking between the EPC and 5GS without the N26 interface. In this interworking, the IP address preservation occurs on the UEs on inter-system mobility. Fetching and saving the PGW-C and SMF and the corresponding APN and DNN information through the HSS and UDM makes interworking possible. In such networks, the AMF also supports interworking with UEs without the N26 interface during the initial registration in 5GC. The AMF may support interworking with UEs without N26 in the Attach procedure in 5GS. In case of a non-3GPP untrusted Wi-Fi access, the ePDG does not communicate with the AMF because the N26 interface does not exist.

A 5GS supports network slicing and can interwork with the EPS in its PLMN or in other PLMNs. The SMF+PGW-C performs UDM registration for each UE with PGW-C FQDN and NSSAI values. With this registration, the AMF or ePDG identify the PGW-C IP-address from the UDM or HSS as part of the subscription information after the UE authorization is completed.

The mobility between 5GC to EPC does not ensure that all the active PDU sessions can be transferred to the EPC. During PDN connection establishment in the EPC, the UE allocates the PDU session ID and sends it to the PGW-C+SMF through the PCO.

An S-NSSAI that is associated with the PDN connection is determined based on the operator policy by the PGW-C+SMF. For example, the combination of PGW-C+SMF address and APN is sent to the UE in the PCO along with a PLMN ID to which the S-NSSAI relates. If the PGW-C+SMF supports multiple S-NSSAI and the APN is valid for multiple S-NSSAIs, the PGW-C+SMF selects only the S-NSSAI that is mapped to the subscribed S-NSSAIs of the UE.

The UE saves the S-NSSAI and the PLMN ID that is associated with the PDN connection. The UE derives the requested NSSAI through the received PLMN ID. The NAS registration request message includes the requested NSSAI. The RRC carries the registration request when the UE registers in 5GC. This scenario is applicable if the UE is non-roaming or the UE has configured NSSAI for the VPLMN in roaming case.

EPS and ePDG Interworking for Handover

The following figure illustrates the non-roaming architecture within the EPS using S5 and S2b interfaces.

Figure 16. Non-roaming Architecture Within EPS using S5, S2a, and S2b Interfaces

For 3GPP access to non-3GPP access untrusted Wi-Fi handover and for non-3GPP access untrusted Wi-Fi to 3GPP access handover, if a UE has multiple PDN connections to different APNs in the source access and the UE can route different simultaneously active PDN connections through different access networks, the UE can transfer from the source to the target access all the PDN connections that were active in source access before handover or only a subset of them. This transfer can have the restriction that multiple PDN connections to the same APN have one access.

The transfer process can occur in the following scenarios:

  • 3GPP access to non-3GPP access untrusted Wi-Fi handover

  • Non-3GPP access untrusted Wi-Fi to 3GPP access handover

The UE can transfer from the source to the target access all the PDN connections that were active in source access before handover or only a subset of them if the following conditions are met:

  • The UE has multiple PDN connections to different APNs in the source access

  • The UE can route different, but simultaneously active, PDN connections through different access networks."

The SMF supports untrusted Wi-Fi access for end-users over S2b interface with ePDG after establishment of IPSec connection between the end-user and ePDG.

For untrusted Wi-Fi to EPC handover, the SMF provides a PGW-C FQDN during UDM registration and fetches the subscription information.

During UE handover, the MME fetches PGW-C FQDN from the HSS. After authentication, the MME initiates GTPv2 create session request indicating handover. The SMF+PGW-C does not perform the UDM registration and subscription procedures while processing handover request. SMF+PGW-C ensures that GTPv2 MB request indicating handover is sent to perform data path switching from untrusted Wi-Fi to EPC.

For EPC to untrusted Wi-Fi handover, the HSS provides SMF+PGW-C FQDN after the subscriber authentication. When UE performs handover, after authentication HSS provides SMF+PGW-C FQDN. The ePDG initiates GTPv2 create session request indicating handover toward PGW after IPSec tunnel establishment. SMF+PGW-C performs the UDM registration and no subscription procedures exist while processing the handover request.

TFT Handling for Wi-Fi Handovers

In 4G and 5G deployment, the three-way audio or video multiparty call conference, and RCS message use cases, PGW-C ends up having more than four filters (it can go upto max 16 filters) for both UL and DL direction. SMF includes “EPS Bearer Level Traffic Flow Template (Bearer TFT)” is included in the GTPv2 CBReq or UBReq of BearerContextList. CBReq or UBReq carry maximum of 4 TFTs per bearer.

In case of three-way Audio/Video and multiparty call-conference, PCF tries to push the pccRules by adding different subscriber TFTs in multiple “N7 Policy Notify Req” messages. PGW-C handles the received “N7 Update Notify Req” in dedicated bearer establishment or update towards Wi-Fi or LTE by initiating GTPv2 CBReq or UBReq messages. SMF accommodates the received SDF Filters in TFT as it never crosses more than 256 Bytes (4 TFTs).


Note

PGW-C don’t support more than 4TFTs received from PCF “N7 Policy Notify Req”.

PCF keeps pushing multiple pccRules for same bearer by sending “N7 Policy Notify Req” and over the period SMF ends up having 12-16 filters for case of multiparty call.

When subscriber moves from LTE to Wi-Fi or Wi-Fi to LTE or NR to Wi-Fi Handover call-model cases, SMF first establishes default bearer creation as part of HO. SMF then tries to send out CBReq for Dedicated bearer establishment by accommodating all 16 filters in “EPS Bearer Level Traffic Flow Template (Bearer TFT)” of bearer context list of the subscriber and if it fails to encode because of these restrictions. The SMF sends out CBReq without “EPS Bearer Level Traffic Flow Template (Bearer TFT)” IE based on HO type, SGW, MME, or ePDG rejects GTPv2 CBResp with Mandatory IE Incorrect with “TFT Semantic Errors”.

After receiving CBResp from SGW or ePDG, SMF doesn’t free up policy or charging resources for respective failed bearers and that leads to further stale entries on SMF and UPF which leads to system inconsistency for that subscriber with “EBI Mismatch – 408 Error Voice Call Failure Wi-Fi HOs”.

Standards Compliance

The Wi-Fi handovers feature complies with the following standards:

  • 3GPP TS 23.502 V15.2.0 (2018-09)

  • 3GPP TS 23.402 V15.3.0 (2018-03)

  • 3GPP TS 29.214 V15.5.0 (2018-03)

How it Works

This section describes the Wi-Fi to LTE handover, Wi-Fi handover with EPS fallback, and Wi-Fi to 5GS handover.

EPC to Non-3GPP Untrusted Wi-Fi Handover Call Flow

This section describes the EPC to non-3GPP untrusted Wi-Fi handover call flow.

Figure 17. EPC to Non-3GPP Untrusted Wi-Fi Handover Call Flow
Table 16. EPC to Non-3GPP Untrusted Wi-Fi Handover Call Flow Description
Step Description
1

The UE is attached to the 3GPP access network.

The SMF+PGW-C communicates with UPF, PCF, and CHF for IPv4, IPv6, or dual-stack to establish 4G LTE PDU session. The PCF sends the Policy Control Request trigger, which is the SM policy decision, in response to SM policy control create. The CHF provides session-level or rating-group-level triggers to the SMF in Charging Data Create response.

2 The UE connects to an untrusted non-3GPP access and an ePDG is selected through the ePDG selection process. Then, the UE initiates the handover attach procedure as defined in 3GPP TS 23.402, section 8.6.2.1. After the IKE tunnel is established between the UE and ePDG and after the UE is authenticated over SWm interface with AAA server, the UE initiates IKE authentication (IKE_AUTH). The IKE_AUTH includes configuration parameters of the earlier assigned IPv4 or IPv6 addresses in the EPC and P-CSCF and the DNS options.
3

The ePDG sends a Create Session Request to the PGW-C. This request includes the following details:

  • IMSI

  • APN

  • Handover indication

  • RAT type

  • ePDG TEID of the Control Plane

  • ePDG address for the User Plane

  • ePDG TEID of the User Plane

  • EPS bearer identity

  • User location

The RAT type indicates the non-3GPP access technology type. If the UE supports the IP address preservation and is included in the port analyzer adapter (PAA), then the ePDG configures the handover indication in the Create Session Request to allow the PDN gateway to reallocate the same IP address or the prefix assigned to the UE. This IP address or prefix is assigned while UE is connected to the 3GPP IP access and initiates the policy modification procedure with PCF.

4a

The SMF performs UDM registration by updating the PGW-C FQDN with UDM.

The UDM registration does not occur during the session establishment with EPC.
4b The SMF detects the charging triggers with the information available in Step 3 against the charging triggers that are received during EPC session establishment.
4c The SMF detects the PCF triggers with the information available in Step 3 against the Request Policy Control triggers that are received in the communication with PCF during EPC session establishment.
5 Based on the detected armed Policy Control Triggers that are received in Step 4b, the SMF sends the SM Policy Control Update request with the detected access parameters in Step 3 to the PCF.
6 The PCF includes new or updated PCC rules and sends the SM Policy Control Update response. The Update response includes information on the SM policy decision.
7 Based on the information received in Step 6 and existing policy data of EPC session, SMF prepares the information for the new or updated PCC rules.
8 If new PCC rules are received in Step 6 with new Rating Group that requires quota information, SMF sends the Charging Update request to CHF. SMF also includes new access parameters for the PDU session information.
9 CHF sends the Charging Update Response with multi-unit information that contains quota information for the requested rating-group in Step 8 to SMF. CHF may also send the new quota information for the existing rating-group of EPC session.
10 SMF processes the information that is received as Charging Update response from CHF.
11 SMF sends the N4 session modification request to UPF for Wi-Fi tunnel. This request includes details on creation of uplink PDR, creation of QER, creation of URR for received new rating-group quota information, and update on URR for modified quota information.
12 UPF sends the UL tunnel information that is in created PDR as the N4 session modification response to SMF.
13 SMF sends the GTPv2 Create Session response to S-GW. This response details on request accepted or request accepted partially, PGW-C S2b F-TEID, PAA, APN-AMBR, bearer context creation, charging gateway address, and APCO.
14 SMF sends the GTPv2 Create Bearer request to S-GW. This request includes information on bearer context list, which contains DL tunnel information to end-user, to be created.
15 S-GW sends the GTPv2 Create Bearer response to SMF. The response includes details on request accepted or request accepted partially and bearer contexts.
16 SMF processes the Create Bearer response and derives the DL tunnel Information for the established bearer and the the failed EBI list, if any. SMF sends the N4 session modification request to UPF for Wi-Fi tunnel. This request is to create the DL PDR and DL FAR with DL tunnel information for each bearer, RAT modification information, and to delete resources for the 4G tunnel. SMF also deletes the N4 resources of Wi-Fi tunnel for the received failed EBI list or the failed QFI list.
17 UPF sends the usage report as N4 Session Modification response to SMF.
18 SMF+PGW-C sends the GTPv2 DB request to S-GW. This request includes EBI or list of EBIs.
19 S-GW sends the GTPv2 DB response to SMF+PGW-C.
20 SMF sends the Charging Update request to CHF. This request includes the PDU session information with the new access params and multi-usage report containing details on the access params and usage report that is received in Step 8
21 CHF sends the multi-unit information as Charging Update response to SMF. The multi-unit information may include new quota information for the existing rating-groups.
22

SMF sends the SM Policy Control Update request to UPF. This request includes the new access params and rule report for failed QFI list that is received from AMF as part of Create Bearer response.

PCF sends the SM policy decision as SM Policy Control Update response.

SMF processes the SM policy decision and handles it as PCF Initiation Modify procedure as defined in 3GPP 23.502, section 4.3.3.2.

Non-3GPP Untrusted Wi-Fi to EPC Handover Call Flow

This section describes the non-3GPP untrusted Wi-Fi to EPC handover call flow.

Figure 18. Non-3GPP Untrusted Wi-Fi to EPC Handover Call Flow
Table 17. Non-3GPP Untrusted Wi-Fi to EPC Handover Call Flow Description
Step Description
1 One or more PDU sessions are established between UE and ePDG through untrusted non-3GPP access. With the 5G NAS capability of UE, ePDG selects a combined PGW+SMF. UE sends the PDU session ID to the PGW+SMF.
2

UE discovers the E-UTRAN access and hands over the sessions from the currently used non-3GPP access system to E-UTRAN. For details on UE discovery of the 3GPP access system, see 3GPP TS 23.401, section 4.8.

UE sends an Attach request to MME for the Handover Attach request type. E-UTRAN routes the messages received from UE to MME as defined in 3GPP TS 23.401. UE includes the one of the APNs which are corresponding to the PDN connections in the source non-3GPP access. The APN is provided as defined in 3GPP TS 23.401.

3

MME and HSS perform authentication, which is followed by location update procedure and subscriber data retrieval to receive the APN information.

The MME selects an APN, an SGW and PDN gateway as defined in 3GPP TS 23.401. MME sends a Create Session Request message to SGW. This request includes information on IMSI, MME context ID, PDN-GW address, handover indication for the “handover” request type, and APN.

4

SGW sends a Create Session Request, which is handover indication, message to PDN-GW in the HPLMN as described in 3GPP TS 23.401. As the MME includes the handover indication information in the Create Session Request message, the SGW sends the GTPv2 Create Session Request message to PDN GW. This message includes details on IMSI, APN, handover indication, RAT type, S5-C TEID, S5-U TEID of the user plane, EBI, and user location information. The RAT type indicates the 3GPP IP access E-UTRAN technology type. If the UE supports IP address preservation and is included in PAA, the SGW configures the handover indication in the Creation Session Request. With this configuration, the PDN GW re-allocates the same IP address or prefix that was assigned to the UE while it was connected to the 3GPP IP access. With this configuration, SGW initiates the Policy Modification Procedure to the PCF.

As the handover indication is includes, the PDN GW does not switch the tunnel from non-3GPP IP access to 3GPP access system at this point.

SMF does not perform the UDM Registration as the registration happens during the Wi-Fi session establishment.
4a SMF detects the charging triggers with the information available in Step 3 against the charging triggers that are received during EPC session establishment.
4b SMF detects the PCF triggers with the information available in Step 3 against the Request Policy Control triggers that are received in the communication with PCF during EPC session establishment.
5 Based on the detected armed Policy Control Triggers that are received in Step 4b, SMF sends the SM Policy Control Update request with the detected access parameters in Step 3 to PCF.
6 PCF sends the SM Policy Control Update response, which is the SM policy decision, by including new or updated PCC rules.
7 Based on the information received in Step 6 and existing policy data of EPC session, SMF prepares the information for the new or updated PCC rules.
8 If SMF receives new PCC rules in Step 6, the SMF sends the Charging Update request, with the new rating-group having quota information, to CHF. This request includes the PDU session information with the new access params.
9 CHF sends the multi-unit information as Charging Update response to SMF. The multi-unit information includes new quota information for the rating-group and the existing rating-group of EPC session, if any.
10 SMF prepares the charging data of the received Charging Update Response that CHF sent.
11 SMF sends the N4 Session Modification Request to UPF. This request includes the details on creation of UL and DL PDR, creation of QER, creation of URR for received new rating-group quota information, updated URR for modified quota information, and creation of FAR.
12 UPF sends the UL tunnel information in the created PDR as N4 Session Modification response to SMF.
13 SMF sends the GTPv2 Create Session response to S-GW. This response details on request accepted or request accepted partially, PGW-C S2b F-TEID, PAA, APN-AMBR, bearer context creation, charging gateway address, and APCO.
14 SGW sends the Modification Bearer request with handover indication to PGW for data path switching from Wi-Fi tunnel to 4G tunnel.
15 PGW sends the N4 Session Modification request to delete the Wi-Fi tunnel and to configure DL tunnel information that is received in GTPv2 Create Session request for 4G tunnel in Step 4.
16 UPF sends the N4 Session Modification response to SMF.
17 SMF sends the GTPv2 Create Session request, which includes the bearer context list, to SGW. This list includes the DL Tunnel information for the end-user.
18 SGW sends the GTPv2 Create Session response to SMF. This response includes details on request accepted or request accepted partially and bearer contexts.
19 ePDG sends the GTPv2 Create Bearer resp (accepted EBIs with DL tunnel info to SMF
20 SMF processes the Create Bearer response and derives the DL tunnel Information for the established bearer and the failed EBI list, if any. SMF sends the N4 session modification request to UPF for Wi-Fi tunnel. This request is to update the DL FAR with the DL tunnel information, RAT modification information, and to delete resources for the 4G tunnel. SMF also deletes the N4 resources of Wi-Fi tunnel for the received failed EBI list or the failed QFI list.
21 UPF sends the N4 Session Modification Response with usage report to SMF.
22 SMF sends the Charging Update request to CHF. This request includes the PDU session information with new access params and multi-usage report consisting of access-params and usage report that is received in Step 8.
23 CHF sends the Charging Update Response with multi-unit information that contains quota information for the existing rating-groups to SMF.
24 SMF+PGW-C initiates the GTPv2 DB Request toward SGW by including EBI or EBI list.
25 SGW sends the GTPv2 DB Response toward SMF+PGW-C.
26

SMF sends the SM Policy Control Update request to UPF. This request includes the new access params and rule report for failed QFI list that is received from AMF as part of Create Bearer response.

PCF sends the SM policy decision as SM Policy Control Update response.

SMF processes the SM policy decision and handles it as PCF Initiation Modify procedure as defined in 3GPP 23.502 section 4.3.3.2.

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.

Figure 19. Non-3GPP Untrusted Wi-Fi to 5GS Handover with EPS Fallback Call Flow
Table 18. Non-3GPP Untrusted Wi-Fi to 5GS Handover with EPS Fallback Call Flow Description

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:

  • PDU session ID

  • Requested PDU session type

  • Requested SSC mode

  • 5GSM capability PCO

  • SM PDU DN request container

  • Number of packet filters

  • Optional requested always-on PDU session

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:

  • If the AMF does not identify the PDU Session ID or the subscription context that the AMF received from UDM during the registration.

  • If the subscription profile update notification procedure contains no SMF ID corresponding to the PDU Session ID.

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:

  • SUPI

  • DNN

  • S-NSSAIs

  • PDU Session ID

  • AMF ID

  • Request Type

  • PCF ID

  • Priority Access

  • N1 SM container including the PDU Session Establishment Request

  • User location information

  • Access Type

  • PEI

  • GPSI

  • Subscription For PDU Session Status Notification

  • DNN Selection Mode

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:

  • Create uplink PDR.

  • Create QER.

  • Create URR (for new rating group quota information)

  • Update on URR (for modified quota information)

  • Create FAR

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:

  • “PDU Session Resource Set up Unsuccess Transfer” N2 message with “IMS voice EPS fallback or RAT fallback triggered” cause.

  • “PDU Session Resource Setup Response Transfer” with “QoS Flow Failed Setup List” cause as “IMS voice EPS fallback or RAT fallback triggered”.

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:

  • QueryUrr for WiFiTunnel

  • Remove the resources of WiFi tunnel.

  • Create DlPdr/Far for gNB tunnel of pccRule-1 and pccRule-4.

  • Remove the resources of gNB tunnel for failed QFI of pccRule-3 and pccRule-5.

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.
Note 

The SMF performs the Step 23 through the Step 25 if there are any failed QFIs.

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.
Note 

The SMF performs Step 38 through Step 40 only when the Step 27 through Step 37 is not executed, that is, when the EPS fallback procedures are not triggered.

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.

Non-3GPP Untrusted Wi-Fi to 5GS Handover Call Flow

This section describes the non-3GPP untrusted Wi-Fi to 5GS handover call flow.

Figure 20. Non-3GPP Untrusted Wi-Fi to 5GS Handover Call Flow
Table 19. Non-3GPP Untrusted Wi-Fi to 5GS Handover Call Flow Description

Step

Description

1

One or more PDU sessions are established between UE and ePDG through untrusted non-3GPP access. With the 5G NAS capability of UE, ePDG selects a combined PGW+SMF. UE sends the PDU session ID to the PGW+SMF.

2

UE sends the PDU Session Establishment request through 3GPP access to AMF. This request includes details on PDU session ID, requested PDU session type, requested SSC mode, 5GSM capability PCO, SM PDU DN request container, number of packet filters, and an optional requested always-on PDU session.

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 UDM. For this request type, if AMF does not identify the PDU Session ID or the subscription context that the AMF received from UDM during the Registration or if the subscription profile update notification procedure contains no SMF ID corresponding to the PDU Session ID, an error occurs. Then, 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 is performed when the SMF ID corresponding to the PDU Session ID and the AMF are part of the same PLMN.

AMF sends the NSMF PDU Session Create SM Context Request with the request type “Existing PDU Session” to SMF. This request includes information on SUPI, DNN, S-NSSAIs, PDU Session ID, AMF ID, Request Type, PCF ID, Priority Access, N1 SM container including the PDU Session Establishment Request, User location information, Access Type, PEI, GPSI, Subscription For PDU Session Status Notification, DNN Selection Mode.

SMF analyzes the existing PDU session from the PDU Session Establishment request using SUPI+PDU-Session-ID. SMF also compare the IPv4 or IPv6 addresses of the received UE against the retrieved PDU session IPv4 or IPv6 addresses. SMF reject the request if the session is not retrieved or IPv4 or IPv6 addresses do not match.

4

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 Wi-Fi session.

4a

SMF detects the charging triggers with the information available in Step 3 against the charging triggers that are received during Wi-Fi session.

4b

SMF does not perform the UDM registration as happens during Wi-Fi Session Establishment.

5

SMF sends the NSMF PDU Session Create SM Context response to 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, SMF sends the SM Policy Control Update request with the detected access parameters in Step 3 to PCF.

7

PCF sends the SM Policy Control Update response, which is the SM policy decision, by including new or updated PCC rules.

8

Based on the information received in Step 7 and existing policy data of Wi-Fi session, SMF prepares the information.

9

If SMF receives new PCC rules in Step 7, the SMF sends the Charging Update request to CHF with new rating-group for quota information. This request includes the PDU session information with the new access params.

10

CHF sends the multi-unit information as Charging Update response to 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

SMF processes the data that is received Charging Update response from CHF.

12

SMF sends the N4 session modification request to UPF for gnb tunnel. This request includes details on creation of uplink PDR, creation of QER, creation of URR for received new rating-group quota information, update on URR for modified quota information, and creation of FAR.

13

UPF sends the UL tunnel information that is in created PDR as the N4 session modification response to SMF.

14

SMF sends the EBI assignment request to AMF. This request includes the ARP list for the PDU session ID.

15

AMF sends the list of EBIs as response to SMF.

16

SMF sends the N1 N2 Transfer Request toward 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

AMF sends the N1 N2 Transfer acknowledgement to SMF.

18

AMF sends the SM Context Update request to SMF with “PDU Session Resource Setup Response Transfer” containing the failed QFI list and the DL tunnel information.

19

SMF sends the N4 session modification request to UPF for the gnb tunnel resources. This request is to create the DL PDR, to create DL FAR with DL tunnel information, include details on RAT-change and delete resources for Wi-Fi tunnel. SMF also deletes the N4 resources of gnb tunnel for received failed QFI list.

20

UPF sends the N4 Session Modification Response with the usage report to SMF.

21

SMF sends the SM Context Update response to AMF.

22

SMF sends the Charging Update request to PCF. This request includes the PDU session information with new access params and multi-usage report with old access-params and usage report that is received in Step 18.

SMF receives the Charging Update response that includes new quota information for existing rating-groups.

23

SMF+PGW-C initiates the GTPv2 DB request, which includes EBIs, to ePDG.

24

ePDG sends the GTPv2 DB response to SMF+PGW-C.

25

SMF receives the SM Context Update request with N1 message for PDU session modification completion from AMF.

26

SMF sends 200/204 OK as SM Context Update response to AMF.

27

SMF sends the SM policy decision as SM Policy Control Update response to AMF.

28

SMF sends the SM Policy Control Update request to PCF. This request includes the new access params and rule report for failed QFI list that is received from AMF as part of N2 message.

29

PCF sends the SM policy decision as SM Policy Control Update response to SMF.

30

SMF processes the SM policy decision and handles it as PCF Initiation Modify procedure as defined in 3GPP 23.502 section 4.3.3.2.

5GS to Non-3GPP Untrusted Wi-Fi Handover Call Flow

This section describes the 5GS to non-3GPP untrusted Wi-Fi handover call flow.

Figure 21. 5GS to Non-3GPP Untrusted Wi-Fi Handover Call Flow
Table 20. 5GS to Non-3GPP Untrusted Wi-Fi Handover Call Flow Description

Step

Description

1

The UE and the SMF or the UPF communicate through the NG-RAN to establish one or more PDU sessions.

2

The UE connects to an untrusted non-3GPP access and selects an ePDG. Then, the UE initiates the handover attach procedure, as defined in 3GPP TS 23.402, section 8.6.2.1. After establishing the IKE tunnel between the UE and the ePDG, and authenticating the UE over SWm interface with the AAA server, the UE initiates IKE_AUH. The IKE_AUH includes cfg_params of the earlier assigned IPv4 or IPv6 addresses in 5GS and P-CSCF and DNS options.

3

The ePDG sends a Create Session request to the PGW-C. This request includes the following details:

  • IMSI

  • APN

  • Handover indication

  • RAT type

  • ePDG TEID of the control plane

  • ePDG address for the user plane

  • ePDG TEID of the user plane

  • EPS bearer identity

  • User location

The RAT type indicates the non-3GPP access technology type. If the UE supports the IP address preservation and includes it in the port analyzer adapter (PAA), then the ePDG configures the handover indication in the Create Session request. This configuration allows the PGW-C to reallocate the same IP address or the prefix assigned to the UE. The IP address or prefix assignment occurs while the UE is connected to the 3GPP IP access. The policy modification procedure begins with the PCF.

4

The SMF does not perform the UDM registration as it has already been registered with UDM during the 5GS session establishment.

4a

The SMF detects the charging triggers with the information available in Step 3 against the charging triggers that are received during the Wi-Fi session.

4b

The SMF detects the policy triggers with the information available in Step 3 against the requested policy control triggers that are received while communicating with PCF during the Wi-Fi session establishment.

5

Based on the detected armed Policy Control Triggers that are received in Step 4b, the SMF sends the SM Policy Control Update request with the detected access parameters to the PCF.

6

The PCF sends the SM policy decision in the SM Policy Control Update response by including new or updated PCC rules.

7

Based on the information received in Step 6 and the existing policy data of 5GS session, the SMF prepares the “ModPolData” information.

8

If the SMF receives new PCC rules in Step 6, 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.

9

The CHF sends the multi-unit information as Charging Update response to the SMF. The multi-unit information includes quota information for the rating-groups received in Step 8 and for the existing rating-group of 5GS session.

10

The SMF processes the ModChargingData in the Charging Update response that SMF receives from the CHF.

11

The SMF sends the N4 session modification request to the UPF for Wi-Fi tunnels. This request includes details on creation of uplink FAR, creation of QER, creation of URR for the received new rating-group quota information, and update on URR for the modified quota information.

12

The UPF sends the N4 session modification response to the SMF with the UL tunnel information in the created PDR.

13

The SMF sends the GTPv2 Create Session response to the S-GW. The response includes details on accepted request or partially accepted request, PGW-C S2b F-TEID, PAA, APN-AMBR, creation of bearer context, charging gateway address, and APCO.

14

The SMF sends the GTPv2 Create Bearer request to the S-GW. This request includes information on bearer context list, which contains UL tunnel information for each dedicated bearer to end-user.

15

The S-GW sends the GTPv2 Create Bearer response to the SMF. The response includes details on accepted request or partially accepted request and bearer contexts.

16

The SMF processes the Create Bearer response and derives the DL tunnel information for the established bearer and the failed EBI list, if any. The SMF sends the N4 session modification request to the UPF for Wi-Fi tunnel. This request is to create DL PDR and DL FAR with the DL tunnel information or list of charging description IDs for the detected charging triggers.

The SMF deletes the gnb tunnel resources and the N4 resources of the Wi-Fi tunnel for the failed bearer context list.

17

The UPF sends the usage report in the N4 Session Modification response to the SMF.

18

The SMF initiates the NAMF communication N1 N2 message transfer, to the S-GW. This transfer message includes the PDU Session Resource Release Request N2 message.

19

The AMF sends N1 N2 Transfer Acknowledgement to the SMF.

20

The AMF sends the SM Context Update request to the SMF. This request includes the SM Resource Release Acknowledgement N2 message.

21

The SMF sends the 200/204 OK as SM Context Update response to the AMF.

22

The AMF sends the SM Context Update request to the SMF. This request includes the PDU Session Release Complete N1 message.

23

The SMF sends the 200/204 OK as SM Context Update response to the AMF.

24

If the SMF supports the June 2019 compliance version of 3GPP specification 23.502, the SMF indicates the release details to the AMF. The SMF achieves this functionality by sending the SM Context Status Notification message (statusInfo {Cause: PDU_SESSION_HANDED_OVER, resourceStatus: RELEASED). The SMF sends this notification after a successful handover of 5GS to Non-3GPP Untrusted WiFi session.

The SMF processes the message as per the compliance profile configured for the corresponding service. For information on the compliance profile configuration, see the Configuring Compliance Profile section.

Important 

If the SMF supports the December 2018 compliance version of 3GPP specification, the Step 24 and Step 25 are not applicable.

25

The AMF sends the 204 OK as SM Context Status Notify response to the SMF.

Important 

If the SMF supports the December 2018 compliance version of 3GPP specification, the Step 24 and Step 25 are not applicable.

26

The SMF sends the Charging Update request to the CHF. This request includes the PDU session information with the new access parameters and multi-usage report containing details on the old access parameters and the usage report that is received in Step 17.

27

The CHF sends the multi-unit information as Charging Update response to SMF. The multi-unit information includes new quota information for the existing rating-groups.

28

The SMF sends the SM Policy Control Update to PCF. This update includes the new access parameters and rule report for failed QFI list that are received from the AMF as part of Create Bearer response.

29

The PCF sends the SM policy decision through the SM Policy Control Update response to the SMF.

30

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.

Non 3GPP Untrusted LTE to WiFi Handover

This section describes the non-3GPP untrusted LTE to WiFi handover call flow.

Figure 22. Non-3GPP Untrusted LTE to WiFi Handover with TFTs more than 4 for a Dedicated Bearer
Table 21. Non-3GPP Untrusted LTE to WiFi Handover Call Flow Description

Step

Description

1

Session is established in LTE with a default bearer and dedicate bearer with 8 TFTs.

2

LTE to Wi-Fi Handover is triggered, when CSReq is received with hi flag configured from ePDG.

3

After successfully handling CSReq, CSResp is sent back to ePDG, indicating that the default bearer is successfully handed over.

4

For the dedicated bearer which has 8 TFT, since all TFTs cannot be sent in CBReq, the CBReq message is triggered with only 4 TFTs toward ePDG.

5

After successful CBResponse from ePDG, SMF sends the remaining TFTs in the UBReq message.

6

After successful UBResponse from ePDG, SMF continues with completion of establishing the bearer towards UPF.

7

In case of failure in CBResponse or failure in UBResponse at Step 5 or Step 6, the SMF deletes that bearer, and if armed, sends rule report to PCF with corresponding rules information as Inactive.


Important

Steps 4-7 are applicable for LTE to Wi-Fi and NR to Wi-Fi if a dedicate bearer has more than 4 TFTs.

IE Support for GTPC

The SMF supports the following IEs in GTPC messages.

Table 22. Supported IEs in GTPC Messages

IE

Scenario

UE Local IP Address

If SMF receives UE Local IP Address from ePDG during Create Session Request, Create Bearer Response, Modify Bearer Request, or Delete Bearer Response procedure, then SMF sends the n3gaLocation attribute towards PCF and CHF if triggers are met.

UE UDP Port

If SMF receives UE UDP Port from ePDG during Create Session Request, Create Bearer Response, Modify Bearer Request, or Delete Bearer Response procedure, then SMF sends the n3gaLocation attribute towards PCF and CHF if triggers are met.

Example

The following example shows the n3GaLocation attribute in the output of the show subscriber supi imsi-123456789012345 nf-service smf psid 5 full command. 

"n3GaLocation": {
"PortNumber": 4661,
"UeIpv4Addr": "209.165.200.227",
"ueLocationTimestamp": "2021-03-09T12:34:02Z"
}

Configuring the WiFi Handovers Feature

This section describes the configurations related to the Wi-Fi Handovers feature.

Configuring Compliance Profile

The SMF provides the compliance profile support for the 3GPP specification 23.502 through the CLI configuration. This compliance profile is in use during the 5GS to non-3GPP untrusted Wi-Fi handover procedure.

Use the following configuration to configure the SMF in compliance with the 3GPP specification.

config 
   profile compliance profile_name 
      service threegpp23502 version   spec  {  15.4.0 | 15.6.0 } spec_version full version_format  
      uri_version uri_version 
         range 
         ! 
         !

Important

For more information on how to configure compliance profile, contact your Cisco Account representative.

NOTES:

  • full : Specifies the full version in the format — <Major-version>.<Minor-version>.<patch-version>.[alpha-<draft-number>]

  • spec : Specifies the 3GPP specification version number. It can be one of the following values:

    • 15.4.0

    • 15.6.0

    To support 3GPP December 2018 specification compliance, configure the specification version as 15.4.0. The default version is 15.4.0.

    To support 3GPP June 2019 specification compliance, configure the specification version as 15.6.0.

  • uri : Specifies the URI version in the format — "v" concatenated with a number. The version can be both v1 and v2, or either v1 or v2.

Configuring Calls with Handover Indication

Use the following sample configuration to handle calls coming with handover (HO) indication and no existing session. 

config 
   profile access access_profile_name 
      gtpc message-handling create-session-request ho-ind new-call-reject 
      exit

NOTES:

  • ho-ind : Indicates that Create Session Request is received with handover.

  • new-call-reject : If the session does not exist, SMF rejects Create Session Request received with HO indicator.