4G to 5G Data Session Handover Support

• Feature Summary , on page 1

• Feature Description, on page 2
• How it Works, on page 2
• Emergency SoS Support, on page 13

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

4G to 5G Data Session Handover Support

1
 4G to 5G Data Session Handover Support
Feature Description

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.

4G to 5G Data Session Handover Support

2
 4G to 5G Data Session Handover Support
EPS to 5G Handover with N26 Interface – Preparation Call Flow

• 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 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+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.

4G to 5G Data Session Handover Support

3
 4G to 5G Data Session Handover Support
EPS to 5G Handover with N26 Interface – Preparation Call Flow

Step Description
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 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 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
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 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.

4G to 5G Data Session Handover Support

4
 4G to 5G Data Session Handover Support
EPS to 5G Handover with N26 Interface – Execution Call Flow

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

4G to 5G Data Session Handover Support

5
 4G to 5G Data Session Handover Support
UE Idle Mode Mobility from EPS to 5GS using N26 Interface

Step Description
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 NsmfPDUSessionUpdateSMContext Response, with PDU Session ID, to AMF.
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

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.

4G to 5G Data Session Handover Support

6
4G to 5G Data Session Handover Support
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.

4G to 5G Data Session Handover Support

7
 4G to 5G Data Session Handover Support
User Plane Connection Reactivation Request

Step Description

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.

4G to 5G Data Session Handover Support

8
4G to 5G Data Session Handover Support
User Plane Connection Reactivation Request

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.

4G to 5G Data Session Handover Support

9
 4G to 5G Data Session Handover Support
User Plane Connection Reactivation Request

Step Description

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.

4G to 5G Data Session Handover Support

10
 4G to 5G Data Session Handover Support
Message Flows

Step Description

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.

4G to 5G Data Session Handover Support

11
 4G to 5G Data Session Handover Support
Standards Compliance

Figure 5: Message Flow across 5GS NEs and Subscriber

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
The 4G to 5G Data Session Handover 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.

4G to 5G Data Session Handover Support

12
 4G to 5G Data Session Handover Support
Emergency SoS Support

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

4G to 5G Data Session Handover Support

13
 4G to 5G Data Session Handover Support
Emergency Session Creation in LTE Call Flow

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.

4G to 5G Data Session Handover Support

14
 4G to 5G Data Session Handover Support
Emergency Services Fallback to LTE Call Flow

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:

4G to 5G Data Session Handover Support

15
 4G to 5G Data Session Handover Support
Configuring Local Authorization

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.

4G to 5G Data Session Handover Support

16
4G to 5G Data Session Handover Support
Configuring Charging Failure Handling

• 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

4G to 5G Data Session Handover Support

17
 4G to 5G Data Session Handover Support
Configuring Charging Failure Handling

4G to 5G Data Session Handover Support

18