4G to 5G Data Session Handover Support

Feature Summary

Summary Data

Table 1. Summary Data

Applicable Product(s) or Functional Area

SMF

Applicable Platform(s)

SMI

Feature Default Setting

Disabled - Configuration Required

Related Changes in this Release

Not Applicable

Related Documentation

Not Applicable

Revision History

Table 2. Revision History

Revision Details

Release

First introduced.

Pre-2020.02.0

Feature Description

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

After a PDU session is created on PGW-C+SMF through E-UTRAN, MME, and S-GW, the SMF can perform 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.

Call Flows

This section describes the following call flows.

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

  • EPS to 5G Handover with N26 Interface – Execution Call Flow

  • UE Idle Mode Mobility from EPS to 5GS using N26 Interface – PDU is in Inactive State

  • UE Idle Mode Mobility from EPS to 5GS using N26 interface – User Plane Connection Reactivation Request

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 1. Preparation of the EPS to 5G Hand-over with the N26 Interface Call Flow
Table 3. Preparation of the EPS to 5G Hand-over with the N26 Interface Call Flow Description
Step Description
1 Call handover initiation starts from UE and E-UTRAN toward each other, proceeds from E-UTRAN to the S-GW, and then for roaming calls, call handover initiation proceeds from S-GW to the UPF+P-GW-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 Nsmf_PDUSession_CreateSMContext 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 in this release.
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 Nsmf_PDUSession_CreateSMContext 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 P-GW-C+SMF determines that session continuity from EPS to 5GS is not supported for the PDU session, then the P-GW-C+SMF does not provide the Session Manager information for the corresponding PDU session. However, the P-GW-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 the Handoff Request Acknowledgment for the received Handover Request to the AMF.
11

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

The Nsmf_PDUSession_UpdateSMContext 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 Nsmf_PDUSession_UpdateSMContext 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 2. Execution of the EPS to 5G Hand-over with the N26 Interface Call Flow
Table 4. Execution of the EPS to 5G Hand-over with the N26 Interface Call Flow Description
Step Description
1

Call handover initiation starts from the UE and E-UTRAN toward each other, proceeds from E-UTRAN to S-GW, and then for roaming calls, call handover initiation proceeds from S-GW to the UPF+P-GW-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 Nsmf_PDUSession_UpdateSMContext 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 informs PCF of the RAT type change.

Important 
Cisco SMF does not support this step in this release.
10 The SMF sends Nsmf_PDUSession_UpdateSMContext Response, with PDU Session ID, to SMF. The SMF confirms the reception of Handover Complete.
11 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.
12 The UE starts the EPS to 5GS mobility registration procedure and sends it to H-PCF.
13 The E-UTRAN performs the resource cleanup in EPC by MME.

UE Idle Mode Mobility from EPS to 5GS using N26 Interface

SMF and PGW-C supports EPS to 5GS Idle Mode Mobility procedure. For Idle Mode Mobility from EPS to 5GS, UE performs Mobility Registration Update Procedure with AMF. AMF and SMF retrieves MM and SM context from EPC and moves 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 3. 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 4. 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 5. Message Flow across 5GS NEs and Subscriber

This image is not available in preview/cisco.com

Standards Compliance

The SMF Support for 4G to 5G Data Session Handover feature complies with the following standard:

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

Limitations

In this release, this feature has the following limitations:

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

  • SMF does not support PCF trigger.

  • SMF does not support charging and PCF integration.

  • SMF does not support the roaming scenario.

Emergency SoS Support

Feature Description

The Emergency SoS Support feature enables the co-located cloud-native SMF and PGW-C to support SoS emergency over LTE for subscribers camped on the 4G network and SoS emergency service fallback to LTE for subscribers camped on the 5G network.

The Emergency SoS Support feature supports the following functionalities:

  • Provides a new configuration to skip UDM interaction.

  • Enables an emergency PDN connection creation in 4G (LTE) for PGW-C.

  • Supports emergency service fallback to LTE requirement for SMF serving subscriber in NR.

  • Supports interworking with an existing charging interface failure handling to ‘continue’ emergency call creation upon failure.

  • Supports interworking with an existing secondary authentication using radius to skip radius authentication for emergency calls when not configured.

  • Provides inter-RAT handover support (4G to 5G and 5G to 4G) for EPS interworking capable subscribers.

How it Works

This section provides a brief of how the Emergency SoS Support feature works.

Call Flows

This section includes the following call flows.

Emergency Session Creation in LTE Call Flow
Figure 6. Emergency Session Creation in LTE


Step Description
1

When an emergency service is required and an emergency PDU session is not already established, the UE initiates the UE-requested PDU session establishment procedure with a request type indicating, "Emergency Request" in LTE.

2

The MME selects an APN or DNN for the emergency PDN creation, and sends a ‘Create Session Request’ to the P-GW via the S-GW.
3

The DNN profile lookup at P-GW is based on the subscriber policy or DNN policy. These policies are associated in the SMF profile. The subscriber policy has higher precedence over DNN policy when both the configurations are present.

4

The DNN policy can have the DNN profile configuration for each of the UE-requested APN or DNN received in the “Create Session Request” from the MME or S-GW.

5

When a new configuration ‘authorization local’ under the selected DNN profile is present:

  • P-GW skips the UDM interaction for fetch subscription and uses the values received in the ‘Create Session Request’ message from the MME.

  • P-GW skips the UDM interaction to ‘Subscribe-for-Notification’ from the UDM.
6

When the ‘Secondary Authentication Radius’ under the selected DNN profile is not present, the PGW-C rejects the RADIUS-based secondary authentication.

7

When ‘failure handling’ for charging interaction is set as ‘action continue’:

  • P-GW continues the call if converged charging is not configured.

  • P-GW falls back to offline charging and continues the call.
8

During handover from 4G to 5G using N26, if the emergency PDN gets handed over, the SMF checks the DNN profile and if ‘authentication local’ is present, it skips the UDM interactions for registration and deregistration.

Emergency Services Fallback to LTE Call Flow
Figure 7. Emergency Services Fallback to LTE


Step Description
1

UE camps on E-UTRA or NR cell in the 5GS (in either CM_IDLE or CM_CONNECTED state).
2

UE has a pending IMS emergency session request (example, voice) from the upper layers.
3

If the AMF has indicated support for emergency services using fallback via the “Registration Accept” message for the current RAT, the UE sends a “Service Request” message indicating that it requires an emergency services fallback.

4

The 5GC executes an NG-AP procedure in which it indicates to the NG-RAN that this is a fallback for emergency services. This procedure triggers the “Emergency Services Fallback” request. Currently the Cisco SMF and PGW-C supports Emergency Services in the EPC core Network (LTE). The AMF includes the EPC as a target CN to trigger inter-RAT fallback. When the AMF initiates the redirection for UEs that are successfully authenticated, AMF includes the security context in the request to trigger fallback towards the NG-RAN.

5

The NG-RAN initiates the handover or redirection to the E-UTRAN connected to the EPS (N26 interface based handover or redirection procedure). The NG-RAN uses the security context that the AMF to secure the redirection procedure.

If the redirection procedure is used, the target CN is also conveyed to the UE to enable it to perform the S1 mode NAS procedures. The UE uses the emergency indication in the RRC message and E-UTRAN provides the emergency indication to the MME during the “Tracking Area Update”.
6

After handover to the target cell, the UE establishes a PDU session or PDN connection for IMS emergency services and performs the IMS procedures for establishment of an IMS emergency session (example, voice).

Configuring Emergency SoS Support

This section describes how to configure the Emergency SoS Support feature.

Configuring the Emergency SoS Support involves the following steps:

  1. Local authorization configuration under DNN profile

  2. Secondary authentication configuration under DNN profile

  3. Charging failure handling configuration under Charging profile

Configuring Local Authorization

To configure the local authorization under the DNN profile, use the following commands:

configure 
   profile dnn pool_name 
      [ no ] authorization local 
      end

NOTES:

no : Disables the local authorization under the DNN profile.

Configuring Secondary Authentication

To configure secondary authentication under the DNN profile, use the following commands:

configure 
   profile dnn pool_name 
      [ no ] secondary authentication radius 
      end

NOTES:

  • no : Disables the secondary authentication under the DNN profile.

  • radius : Specifies RADIUS for secondary authentication.

Configuring Charging Failure Handling

To configure failure handling action for both converged charging and offline charging failure cases under the charging profile, use the following commands: 

configure 
   profile network-element chf charging_profile_name 
      nf-client-profile offline_charging_profile_name 
      failure-handling-profile failure_handling_profile_name 
      exit 
      exit

NOTES:

  • profile network-element chf charging_profile_name : Specifies the charging function (CHF) as the network element profile. charging_profile_name must an alphanumeric string representing the corresponding network element profile name.

  • nf-client-profile offline_charging_profile_name : Specifies the local NF client profile.offline_charging_profile_name must an alphanumeric string representing the corresponding NF client profile name.

  • failure-handling-profile failure_handling_profile_name : Specifies the NRF failure handling network profile for the configured NF type. failure_handling_profile-name must an alphanumeric string representing the corresponding NRF failure handling network profile name.

Sample Configuration

The following is a sample configuration of the failure handling action for converged charging:

profile nf-client-failure nf-type chf
profile failure-handling [failure_handling_profile_name]
service name type nchf-convergedcharging
message type ChfConvergedchargingCreate 
status-code httpv2 0 
action continue 
exit