EPS Interworking

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 Enabled – Always-on
Related Changes in this Release Not Applicable
Related Documentation Not Applicable

Revision History

Table 2. Revision History
Revision Details Release

Introduced procedure to support dynamic configuration of the Access Profile configuration.

2020.03.0

New CLI command in the DNN profile configuration to reject calls from 4G-only UE devices.

2020.02.1
First introduced.

Pre-2020.02.0

Feature Description

The SMF implements the 3GPP recommendations for interworking of Evolved Packet System (EPS) and 5G Core Network (5GC).

The UEs capable of supporting both 4G and 5G NAS connect to the Evolved Terrestrial Radio Access Network (E-UTRAN) and the 5GC network. The SMF with the EPS interworking capability acts as a PGW-C+SMF and uses the S5 or S8 interface with S-GW to receive the 4G Session Creation Request. All the other interfaces involved in the 4G Session Creation (for example, Gx, Gy, Gz, and so on) are replaced by the corresponding 5GC Service Based Interfaces (for example, Npcf and Nchf).

After a PDU session is created on the PGW-C+SMF with E-UTRAN, Mobility Management Entity (MME) and Serving Gateway (S-GW), the UE can hand over E-UTRAN to 5G New Radio (NR) and vice-versa.

The SMF currently supports interworking with EPS using the N26 interface. This interface is an inter-CN interface between the MME and 5GS AMF to enable interworking between Evolved Packet Core (EPC) and the NG core networks. Support of N26 interface in the network is optional for interworking. N26 supports a subset of the functionalities over S10 interface to enable interworking.

The UE uses EPC NAS or 5GC NAS procedures depending on the core network by which it is served.

Architecture

The following figure shows the network architecture for the EPS-5G Core interworking.

Figure 1. 3GPP Non-Roaming Architecture for EPS-5GC Interworking

How it Works

A UE that supports only EPS based Dual Connectivity with secondary RAT NR:

  • Always performs initial access through E-UTRA (LTE-Uu) but never through NR.

  • Performs EPS NAS procedures over E-UTRA (that is, Mobility Management, Session Management and so on) as defined in 3GPP TS 24.301.

A UE that supports camping on 5G Systems with 5GC NAS:

  • Performs initial access either through E-UTRAN that connects to 5GC or through NR towards 5GC.

  • Performs initial access through E-UTRAN towards EPS, if supported and needed.

  • Performs EPS NAS or 5GC NAS procedures over E-UTRAN or NR respectively (that is, Mobility Management, Session Management, and so on) depending on whether the UE requests 5GC access or EPS access, if the UE also supports EPS NAS.

For interworking with EPS, the UE that supports both 5GC and EPS NAS can operate in one of the following modes:

  • Single-registration mode: UE has only one active MM state (either RM state in 5GC or EMM state in EPS) and it is either in 5GC NAS mode or in EPS NAS mode (when connected to 5GC or EPS, respectively).

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

Networks that support interworking with EPS, may support interworking procedures that use the N26 interface or interworking procedures that do not use the N26 interface.

  • Interworking procedures with N26 support provide IP address continuity on inter-system mobility to UEs that support 5GC NAS and EPS NAS and that operate in single registration mode. Interworking procedures using the N26 interface, enables the exchange of MM and SM states between the source and target network.

  • Networks that support interworking procedures without N26 support procedures to provide IP address continuity on inter-system mobility to UEs operating in both single-registration mode and dual-registration mode. For interworking without the N26 interface, IP address preservation is provided to the UEs on inter-system mobility by storing and fetching PGW-C+SMF and corresponding APN or DNN information via the HSS+UDM.


Important

Interworking of SMF and EPS currently works only with the N26 interface.

Standards Compliance

The 5GC and EPS Interworking feature complies with the following standards:

  • 3GPP TS 23.401, Version 15.6.0

  • 3GPP TS 23.501, Version 15.4.0

  • 3GPP TS 23.502, Version 15.4.0

  • 3GPP TS 29.502, Version 15.2.1

  • 3GPP TS 29.512, Version 15.2.0

Support for UE Initial Attach on E-UTRAN

Feature Description

The SMF supports the UE performing initial attach on E-UTRAN via MME and S-GW to create the default bearer.

Initial attach on E-UTRAN or EPS follows the procedure defined in 3GPP specification 23.401, Section 5.3.2.1. There are few deviations from the defined procedure to enable connectivity through the 5G core. The deviations are as follows:

  • The Packet Data Network Gateway (P-GW) in the procedure is replaced by SMF+PGW.

  • The IP-CAN Session establishment and modification is replaced by SM Policy Association Establishment procedure.

  • The online and offline charging functionality using Gy and Gz interfaces is replaced by integrated charging over Nchf interface with Charging Function (CHF).

  • The interface with the user-plane node is through N4 interface instead of Sxb interface.

How it Works

Call Flows
Initial Attach on E-UTRAN or EPS Procedure

The following figure shows the call flow derived from 3GPP reference for initial attach on E-UTRAN or EPS.

Figure 2. Call Flow for Initial Attach on E-UTRAN via 5G Core
Table 3. Call Flow Description for Initial Attach on E-UTRAN via 5G Core
Step Description
1 UE sends Attach Request to the MME through eNodeB.
2 The MME determines that the UE is capable and subscribed for handoff to NR. It selects an SMF node as the P-GW for this PDU session.
3 The MME sends Create Session Request to the selected S-GW and includes the selected SMF address in it.
4 The S-GW initiates Create Session Request towards the SMF.
5 The SMF extracts the PDU Session ID sent by the UE in the Protocol Configuration Option (PCO) 001AH (PDU session ID) and saves it. It then performs a Unified Data Management (UDM) registration and sends P-GW Fully Qualified Domain Name (FQDN) to the UDM. After registration, the SMF initiates subscription fetch from the UDM.
6

The SMF sends Npcf_SMPolicyControl_Create to the PCF to initiate SM policy Association Establishment.

The SMF includes the information elements received in Create Session Request message into the Npcf_SMPolicyControl_Create Service as follows:

  • The SUPI contains the IMSI.

  • The DNN contains the APN.

  • The PEI contains the IMEI-SV.

  • The Session AMBR contains the APN-AMBR.

  • The default QoS information contains the default EPS bearer QoS. The QCI values are mapped into 5QI values.
7 The SMF receives Policy Charging and Control (PCC) Rules and PDU Session Policy Information, 5G QoS information in PCC Rule and in PDU Session Policy Information which are mapped into EPS QoS information. The SMF creates Traffic Flow Template (TFT) from the Service Data Filters (SDFs) received in PCC rules and associates them with the corresponding default and dedicated bearers.
8 Based on the charging policies received from PCF, the SMF initiates Nchf_ConvergedCharging_Create operation towards the CHF. This procedure is similar to a 5G session and is based on the charging rules received from the PCF.
9 The SMF performs UPF+PGW-U selection and N4 Session Establishment. Since this is a 4G session connecting the SMF, a separate CN tunnel is created for each bearer and QoS Flow ID (QFI) is not sent in the QoS Enforcement Rule (QER) and Packet Detection Rule (PDR).
10

The SMF sends Create Session Response to S-GW and includes the bearer information and Tunnel Endpoint Identifier (TEID) for the default bearer. The SMF also includes the 5G QoS parameters in PCO options 001CH (QoS rules), 001DH (Session-AMBR), 001EH (PDU session address lifetime) and 001FH (QoS flow descriptions) to the UE.

11 The S-GW sends Create Session Response to the MME.
12 The MME sends Initial Context Setup Request to the eNodeB with N1 Attach Accept message.
13 The eNodeB and UE perform Radio Resource Control (RRC) configuration.
14 The UE sends Direct transfer message to the eNodeB.
15 The eNodeB sends Attach Complete message in Initial Context Setup Response to the MME along with the TEID of eNodeB.
16 The MME sends a Modify Bearer Request to the S-GW with eNodeB TEID.
17 The SMF sends the Modify Bearer Response to the S-GW.
18 The S-GW sends Modify Bearer Response to the MME.

Converged Core Refactoring Changes

This section describes the changes related to converged core refactoring in this chapter.

The k8 smf local tracing enable true CLI command is deprecated in 2021.01 and later releases.

Configuring the UE Initial Attach Feature

This section describes how to configure the UE Initial Attach feature.

Configuring the UE Initial Attach feature involves the following steps:

  1. Define FQDN in SMF Profile Configuration

  2. Configure S5 Binding Address in SMF Service Configuration

  3. Enable Kubernetes Configuration for SMF GTP Endpoint PODs

Define FQDN in SMF Profile Configuration

Use the following configuration to specify the FQDN of SMF+PGW-C. The configured FQDN is sent to the UDM during registration.


config 
   profile smf smf_profile_name 
fqdn fqdn_name 
      end

NOTES:

  • fqdn fqdn_name : Configures the PGW-C FQDN. fqdn_name must be an alphanumeric string.

Configure S5 Binding Address in SMF Service Configuration

Use the following configuration to define the S5 binding address at which the SMF listens for GTP messages from S-GW (S5 interface).


configure 
   profile smf smf_profile_name 
   service name smf_service_name 
      s5 bind-address { ipv4 ipv4_address | ipv6 ipv6_address } 
      end

NOTES:

  • s5 bind-address { ipv4 ipv4_address | ipv6 ipv6_address } : Enter the IP address at which SMF listens for GTP messages from S-GW via S5 interface. Enter the address in either standard IPv4 dotted decimal format or in standard IPv6 colon notation format.

Configuring GTP Endpoint Parameters

Use the following sample configuration to define the GTP endpoint parameters.

config 

      endpoint gtp 
         replicas replica_count 
         vip-ip ipv4_address 
         vip-ipv6 ipv6_address 
         end

NOTES:

  • endpoint gtp : Enter the GTP endpoint configuration.

  • replicas replica_count : Enter the number of replicas to be created per node. The default value is 1.

  • vip-ip : Specify the IPv4 address for the GTP endpoint.

  • vip-ipv6 : Specify the IPv6 address for the GTP endpoint.

Verifying the UE Initial Attach Feature Configuration

This section describes how to verify the UE Initial Attach feature configuration.

The following configuration is a sample output of the show running-config command: 

show running-config 
. 
. 
. 
profile smf smf1 
 node-id          ABC123 
 bind-address ipv4 127.0.0.1 
 bind-port        8008 
 allowed-nssai    [ slice1 ] 
 plmn-id mcc 123 
 plmn-id mnc 456 
 fqdn ciscosmf1 
 service name nsmf-pdu 
  type               pdu-session 
  . 
  . 
  . 
  n4 bind-address ipv4 10.81.70.229 
  s5 bind-address ipv4 10.81.70.229 
  http-endpoint base-url http://smf-service 
. 
. 
. 
k8 smf local redis-endpoint redis-primary:6379 
k8 smf local service no-of-replicas 1 
k8 smf local nodemgr no-of-replicas 1 

. 
. 
.

Detach Procedure for EPS on SMF and P-GW

Feature Description

The SMF supports the default bearer deletion procedures for a UE attached through E-UTRAN, MME, and S-GW.

How it Works

Call Flows

This section describes the call flows associated with this feature.

UE-initiated EPS Call Release Procedure

The following figure shows the call flow for UE-initiated release of EPS call.

Figure 3. UE-initiated EPS Call Release Flow

The detach procedures for the EPS are defined in 3GPP 23.401, Section 5.3.8. When the UE is attached to E-UTRAN, the detach procedure remains the same as mentioned in the specified 3GPP section except for the following changes:

  • Any interaction towards PCRF (CCR-T), that is PCEF-initiated IP-CAN session between P-GW and PCRF, is replaced by Npcf_SMPolicyControl_Update Request from the SMF to the PCF. The parameters sent in this message follow a mapping from Delete Session Request contents in a way similar to the Create Session Request message for initial attach.

  • All Gy and Gz interface messages are replaced by Nchf_ConvergedCharging_Release service operations.

  • The user plane resources are removed using the N4 Session Release procedure towards the UPF.

UE-initiated Call Release Detail Procedure

The following figure shows the detailed procedure of UE-initiated release of EPS call.

Figure 4. Detailed Call Flow of UE-initiated EPS Call Release
PCF-initiated Call Release Detail Procedure

The following figure shows the detailed procedure of PCF-initiated release of EPS call.

Figure 5. Detailed Call Flow of PCF-initiated EPS Call Release

Dedicated Bearer Activation and Deactivation

Feature Description

SMF supports the PCF-initiated dedicated bearer creation and dedicated bearer deletion procedures for a UE attached via E-UTRAN, MME, and S-GW.

How it Works

Call Flows

This section describes the call flows associated with this feature.

Dedicated Bearer Creation Call Flow

The following figure describes the Dedicated Bearer Creation procedure.

Figure 6. Dedicated Bearer Creation Call Flow

The dedicated bearer creation or activation procedure for the EPS session is defined in 3GPP 23.401, Section 5.4.1. When the UE is attached to E-UTRAN, the dedicated bearer procedure remains the same as mentioned in the specified 3GPP section except for the following changes:

  • Any interaction towards the PCRF (RAR from the PCRF or CCR-U to the PCRF) are replaced by Npcf_SMPolicyControl_UpdateNotify request from the PCF to the SMF and Npcf_SMPolicyControl_Update Request from the SMF to the PCF respectively.

  • The PCC rules provided by PCF are mapped to TFTs for the new dedicated bearer and the associated QoS is mapped to 4G QoS as defined in the Generating EPS PDN Connection Parameters from 5G PDU Session Parameters.

  • All Gy and Gz interface messages are replaced by Nchf_ConvergedCharging_Update service operations.

  • The user plane resources for dedicated bearers are added using the N4 Session Modification procedure towards UPF where PDRs, QERs and FARs are added for the SDF filters for the new dedicated bearer.

  • The SMF+PGW-C saves the EBI for the dedicated bearer as received in Create Bearer response.

The following figure describes the PCF-initiated Dedicated Bearer Activation procedure.

Figure 7. PCF-initiated Dedicated Bearer Activation
Dedicated Bearer Deactivation Call Flow

The following figure describes the Dedicated Bearer Deactivation procedure.

Figure 8. Dedicated Bearer Deactivation Call Flow

The dedicated bearer deactivation procedure for the EPS session is defined in 3GPP 23.401, Section 5.4.4. When the UE is attached to E-UTRAN, the dedicated bearer procedure remains the same as mentioned in the specified 3GPP section except for the following changes:

  • Any interaction towards PCRF (RAR from the PCRF/CCR-U to the PCRF) are replaced by Npcf_SMPolicyControl_UpdateNotify request from PCF to the SMF and Npcf_SMPolicyControl_Update Request from the SMF to the PCF respectively.

  • The PCC rules removed by PCF are mapped to the corresponding dedicated bearers and the bearer deactivation is triggered for these bearers.

  • All Gy and Gz interface messages are replaced by Nchf_ConvergedCharging_Update service operations.

  • The user plane resources for dedicated bearers are removed using the N4 Session Modification procedure towards UPF where PDRs, QERs and Forward Action Rule (FARs) are removed for the SDF filters for the deleted dedicated bearer.

MME-initiated Dedicated Bearer Deactivation

The MME uses the UE or MME-requested PDN Disconnection procedure to initiate the release of PDN connections. The following call flow illustrates the procedure in which the dedicated bearers are deactivated.


Note

The default bearers are not affected during the disconnection process.
Figure 9. MME-initiated Dedicated Bearer Deactivation

Step

Description

1

The release of Radio bearers for the UE in the ECM-CONNECTED state occurs due to local reasons such as abnormal resource limitation. The UE deletes the bearer contexts related to the released radio bearers.

2

When the eNodeB releases radio bearers, it sends an indication of bearer release to the MME. This indication could either be the Bearer Release Request (EPS Bearer Identity) message to the MME, or Initial Context Setup Complete, Handover Request Ack and UE Context Response. Path Switch Request can also indicate the release of a bearer. The eNodeB includes the ECGI and TAI in the indication sent to the MME.

3

The MME sends the Delete Bearer Command (EPS Bearer Identity, User Location Information, UE Time Zone, RAN or NAS Release Cause, if available) message per PDN connection to the S-GW to deactivate the selected dedicated bearer. RAN or NAS Release Cause indicates the RAN release cause or the NAS release cause. RAN or NAS Release Cause is only sent by the MME to the P-GW, if permitted according to the MME operator policy.

4

The S-GW sends the Delete Bearer Command (EPS Bearer Identity, User Location Information, UE Time Zone, RAN/NAS Release Cause) message per PDN connection to the P-GW.

5

If the PCC infrastructure is deployed, the P-GW informs the PCRF about the loss of resources by means of a PCEF-initiated IP‑CAN Session Modification procedure as defined in 3GPP TS 23.203 and provides the User Location Information, UE Time Zone and RAN or NAS Release cause, if available, received in the Delete Bearer Command from the S-GW if requested by the PCRF as defined in 3GPP TS 23.203. The PCRF sends an updated PCC decision to the P-GW.

Note 

User Location Information and UE Time Zone may be unavailable if the MME or the S-GW are of a previous release and did not provide this information.

6

The P-GW sends a Delete Bearer Request (EPS Bearer Identity) message to the S-GW.

7

The S-GW sends the Delete Bearer Request (EPS Bearer Identity) message to the MME.

8

This step involves invoking Step 5 through Step 8. Note that these steps are omitted if the bearer deactivation was triggered by the eNodeB in Step 1 and Step 2.

Also, these steps are omitted if the MME initiated bearer release due to failed bearer set up during handover, the UE and the MME deactivate the failed contexts locally without peer-to peer ESM signaling.

9

The MME deletes the bearer contexts related to the deactivated EPS bearer and acknowledges the bearer deactivation to the S-GW by sending a Delete Bearer Response (EPS Bearer Identity, User Location Information (ECGI)) message.

10

The S-GW deletes the bearer context related to the deactivated EPS bearer and acknowledges the bearer deactivation to the P-GW by sending a Delete Bearer Response (EPS Bearer Identity) message.

SMF-initiated Dedicated Bearer Deactivation

The following procedure describes the SMF-initiated dedicated bearer deactivation process as defined in 3GPP TS 23.203.


Note

Default bearers are not affected during the dedicated bearer deactivation process.

  • The SMF-initiated delete bearer is triggered using the clear subscriber command.

  • If the PCC infrastructure is deployed, the P-GW informs the PCRF about the loss of resources by means of a PCEF-initiated IP‑CAN Session Modification procedure and provides the User Location Information, UE Time Zone and RAN or NAS Release cause, if available, received in the clear subscriber command if requested by the PCRF. The PCRF sends an updated PCC decision to the P-GW.

  • The P-GW sends a Delete Bearer Request (EPS Bearer Identity) message to the S-GW.

  • The S-GW deletes the bearer context related to the deactivated EPS bearer and acknowledges the bearer deactivation to the P-GW by sending a Delete Bearer Response (EPS Bearer Identity) message.

The following call flow illustrates the SMF-initiated dedicated bearer deactivation.

Figure 10. SMF-initiated Dedicated Bearer Deactivation

EPS Fallback

Feature Description

SMF supports fallback to EPS from 5GC for IMS sessions if gNB rejects the dedicated bearer creation with ims-voice-eps-fallback or rat-fallback triggered.

For the UE devices not supporting VoNR, the SMF performs a fallback to EPS for voice calls. This includes 5G to EPS handover and dedicated bearer creation in 4G for voice call.

How it Works

Call Flows

The following call flow depicts the EPS Fallback procedure.

Figure 11. EPS Fallback Call Flow
Table 4. EPS Fallback Call Flow Description
Step Description
1 The UE initiates Mobile-Originated (MO) or a Mobile-Terminated (MT) IMS voice establishment procedure with NG-RAN in 5GS.
2 The Network-initiated PDU Session modification request to setup QoS flow for voice reaches the NG-RAN.
3

The NG-RAN is configured to support the EPS fallback for IMS voice. Based on the UE functionalities, indication from the AMF to redirect EPS fallback for voice, network configuration, and radio conditions, the NG-RAN triggers fallback to EPS. If the NG-RAN determines to not trigger the fallback to EPS, then the procedure stops, and the following steps are not performed.

The NG-RAN initiates measurement report solicitation from the UE including E-UTRAN as target.
4

The NG-RAN rejects the PDU Session modification request received in Step 2 with an indication that mobility due to fallback for IMS voice is ongoing.

The NG-RAN indicates the rejection of the PDU session modification to configure QoS flow for IMS voice that is received in Step 2 as PDU Session Response message toward the SMF through the AMF. This message includes the details on the ongoing mobility due to fallback for IMS voice. The SMF maintains the PCC rules that are associated with the QoS flows.

For a roaming scenario, the PDU Session Response message is sent toward H-SMF through V-SMF.
5

Based on the UE functionalities, the NG-RAN initiates handover to the EPS. The SMF reports change of the RAT type, if the PCF is subscribed for it.

A timer starts to track failure in the EPS fallback. After the timer expires, the SMF notifies the PCF about the dedicated bearer creation failure and new statistics, with the “smf_eps_fb” and “timeout” labels, is incremented.

6a For 5GS to EPS handover, the UE initiates TAU procedure.
6b The UE attaches the PDN connectivity request with the “handover” request type.
7 After the completion of the 5GS to EPS handover procedure, the SMF or P-GW re-initiates the configuration of the dedicated bearer for IMS voice and mapping the 5G QoS to EPC QoS parameters. The SMF notifies about the Successful Resource Allocation and Access Network Information, if the PCF is subscribed for it.
8 The IMS voice session establishment continues.

EPS Fallback Guard Timer Support

Feature Description

SMF supports the guard timer to track failure in the EPS fallback. After the timer starts, it waits for the EPS fallback to happen before the bearer creation failure information is communicated to PCF.

How It Works

The EPS fallback timer starts after receiving the notification for dedicated bearer creation failure with the EPS fallback cause from gNB through AMF. In this case, SMF does not send the failure notification to PCF and waits for 5G to 4G handover to complete. Then, SMF triggers the bearer creation in 4G. The EPS fallback timer stops on the completion of the 5G to 4G handover.

In case the timer expires before the completion of the 5G to 4G handover, SMF sends a notification for dedicated bearer creation failure to PCF. Then, the new statistics counter, with the “smf_eps_fb” and “timeout” labels, is incremented. However, the 5G to 4G handover procedure continues.

Call Flows

This section includes the following call flow.

EPS Fallback Guard Timer Call Flow

This section describes the 5G to EPS fallback guard timer call flow.

Figure 12. EPS Fallback Guard Timer Call Flow
Table 5. EPS Fallback Guard Timer Call Flow Description
Step Description
1 gNB sends the dedicated bearer creation failure information with the fallback cause through AMF.
2 EPS fallback timer starts.
In the successful EPS fallback with 5G to 4G handover scenario, Steps 3 –12 happen.
3 EPS fallback timer stops and triggers pending dedicated bearer creation.
4 SMF(+S5-C) sends the PFCP session modification request to UPF(+S5-U).
5 PDR and FAR are created.
6 UPF(+S5-U) sends the PFCP session modification response to SMF(+S5-C).
7 The information on the created PDR with the GTP-U TEID is available.
8 SMF(+S5-C) sends the Create Bearer Request to SGW.
9 SGW sends the Create Bearer Response to SMF(+S5-C).
10 SMF(+S5-C) sends the PFCP Session Modification Request to UPF(+S5-U).
11 UPF(+S5-U) sends the notification of the successful dedicated bearer creation to PCF.
12 EPS fallback guard timer stops.
13 PCF sends the “200 OK” acknowledgment to SMF(+S5-C)
In the EPS fallback timer expiry before handover completion scenario, Steps 14–16 happen.
14 SMF(+S5-C) sends the failure notification of the dedicated bearer creation to PCF.
15 PCF sends the “200 OK” acknowledgment to SMF(+S5-C).
16 The 5G to 4G handover procedure continues.

Standards Compliance

The EPS fallback guard timer support feature complies with the following standards:

  • 3GPP TS 23.502 V16.1.1 (2019-06)

Configuring the EPS Fallback Guard Timer

This section describes how to configure the EPS Fallback Guard Timer feature.

configure 
   profile access test [ eps-fallback | n2 | n26 ] 
   eps-fallback guard timeout timeout_value 
   n26 idft enable timeout n26_timeout_value 
   n2 idft enable timeout n2_timeout_value 
   end

NOTES:

  • profile access : Accesses the profile configuration.

  • test : Accesses the profile instance.

  • eps-fallback : Enters the EPS fallback configuration.

  • eps-fallback guard timeout : Enters the value for the EPS fallback timer from the range of 500 to 15000 milliseconds.

  • n26 : Enters the N26 interface, which is the E-UTRAN and NG-RAN configuration.

  • n2 : Enters the N2 interface, which is the NG-RAN configuration.

  • idft enable timeout : Enters the value from 15 to 60 for the IDFT timer to expire.

Indirect Data Forwarding Tunnel (IDFT) Timer Support

Feature Description

SMF supports the Indirect Data Forwarding Tunnel (IDFT) timer during the IDFT procedures for 5G to a 4G handover. During the handover, the IDFT tunnels of 5G are released. SMF receives the NSMF PDU Session Update SM Context Request to release the forwarding tunnels from AMF. When SMF does not receive this request, the IDFT timer ensures the release of unused tunnels.

How it Works

Call Flows

This section includes the following call flow.

5G to EPS Handover with IDFT Timer Call Flow

This section describes the 5G to EPS handover with IDFT timer call flow.

Figure 13. 5G to EPS Handover with IDFT Timer Call Flow
Table 6. 5G to EPS Handover with IDFT Timer Call Flow Description
Step Description
1 NG-RAN determines to handover UE to E-UTRAN. If NG-RAN is configured to perform inter-RAT mobility due to the IMS voice fallback that is triggered by QoS flow setup and request to set up QoS flow for IMS voice is received, then NG-RAN indicates the rejection of the QoS flow establishment. This indication is because of mobility due to fallback for the IMS voice through N2 SM information and triggers the handover to E-UTRAN. The NG-RAN sends a Handover Required message to the AMF. This message includes the details on target eNB ID, direct forwarding path availability, source to target transparent container, and inter-system handover indication. NG-RAN uses the source to target transparent container to indicate bearers for the corresponding 5G QoS flows for data forwarding.
2a AMF sends the NSMF PDU Session Context Request to the SMF+PGW-C to provide SM Context.
2b

SMF+PGW-C sends the N4 session modification to PGW-U+UPF to establish the CN tunnel for each EPS bearer. The bearer mapping to the 5G QoS and PCC rules, which PCC sends, are available in the SMF. The SMF also has the bearer IDs that are received from the bearer ID allocation procedure. The SMF+PGW-C creates new PDRs for the N4 session and gets the TEID allocated for each bearer as required by the 4G system.

The timer in SMF+PGW-C starts in this step. This timer monitors the resources for indirect data forwarding in UPF that are to be released.

Following are the cases for the IDFT timer expiry:

  • Step 21a does not happen and the timer expires—The PDRs and FARs that are not required for the indirect tunnels, are removed before Step 21a.

  • The timer expires before or during the Steps 14a and 16—The PDRs and FARs that are not required for the indirect tunnels, are removed and the call flow continues independently.

  • Step 21a happens after the timer expiry—The SMF does not send the N4 Modification Request to UPF+PGW-U as the resources are released on the timer expiry.

2c

SMF+PGW-C sends the EPS bearer contexts to AMF. The bearer context is a string with the byte format, which is the base64-encoded characters, encoding the UE EPS PDN Connection IE.

The SMF+PGW-C also provides the CN tunnel information to AMF for all the bearers for the uplink traffic from E-UTRAN.
3 AMF sends a Forward Relocation Request to MME. The AMF includes the mapped SM EPS UE Contexts for the PDU Sessions with and without active UP connections.
4 MME sends the Create Session Request to SGW. See S1-based handover in the normal case section in 3GPP TS 23.401, clause 5.5.1.2.2 for details.
5 SGW sends the Create Session Response to MME. See S1-based handover in the normal case section in 3GPP TS 23.401, clause 5.5.1.2.2 for details.
6 MME sends the handover request to E-UTRAN.
7 E-UTRAN sends the handover request acknowledgment to MME.
8 MME and SGW send and receive the indirect data forwarding request and response to each other.
9 MME sends the Relocation Response to AMF.
10a In case of indirect data forwarding, AMF sends the NSMF PDU Session Update SM Context Request to PGW-C+SMF. This request is for SGW addresses and SGW DL TEIDs for data forwarding and for creating the indirect data forwarding tunnel.
10b

PGW-C+SMF sends the N4 Modification Request to UPF+PGW-U to create more PDRs and FARs. The PDRs and FARS are created to receive the redirected DL data over the indirect tunnel from NG RAN and to forward them to eNodeB. The UL PDRs have the QFI to match the forwarded DL data from NG RAN. The associated QER has the QFI to forward the data to eNodeB. Also, the FAR redirects the received data to eNodeB over the appropriate tunnel based on the QFI.

10c

PGW-C+SMF sends the NSMF PDU Session Update SM Context Response to AMF. This response includes details on cause, CN tunnel information for data forwarding, and QoS flows for data forwarding. PGW-C+SMF sends this response to create indirect data forwarding. Based on the correlation between QFIs and SGW addresses and TEIDs for data forwarding, the PGW-U+UPF maps the QoS flows into the data forwarding tunnels in EPC.

11a AMF sends the Handover Command to the source NG-RAN.
11b

The source NG-RAN sends the Handover Command to UE to handover to the target access network.

The UE correlates the ongoing QoS Flows with the indicated EPS Bearer IDs (EBI) that are to be set up in the handover command. If the QoS Flow associated with the default QoS rule in the PDU Session has an unassigned EBI, the UE deletes the PDU Session locally. If the QoS Flow that is associatedthat is with the default QoS rule has an assigned EBI, the UE retains the PDU session. For the QoS Flow with unassigned EBIs, the UE deletes the QoS rules and the QoS Flow level QoS parameters locally if any associated with those QoS Flows. Then, the UE notifies the impacted applications that the dedicated QoS resource has been released. The UE deletes any UE-derived QoS rules. The EBI that was assigned for the QoS Flow of the default QoS rule in the PDU Session becomes the EBI of the default bearer in the corresponding PDN connection.

12a

UE sends the notification of handover completion to E-UTRAN.
12b

E-UTRAN sends the Handover Notify request to MME.
12c

MME sends the Relocation Complete Notification to AMF.
12d

AMF sends the Relocation Complete Notification acknowledgment to MME.
13

MME sends the Modify Bearer Request to SGW.
14a

SGW sends the Modify Bearer Request to SMF+PGW-C. This request includes the information on DL TEIDs on SMF for the bearers.
15

PGW-C+SMF initiates a N4 Session Modification procedure toward the UPF+PGW-U to update the User Plane path, which implies that DL User Plane for the indicated PDU Session is switched to E-UTRAN. The PGW-C+SMF releases the resource of the CN tunnel for PDU Session in UPF+PGW-U.

16

PGW-C+SMF sends Modify Bearer Response to SGW. At this stage, the User Plane path is established for the default bearer and the dedicated EPS bearers between the UE, target eNodeB, SGW, and the PGW-U+UPF. The PGW-C+SMF uses the EPS QoS parameters as assigned for the dedicated EPS bearers during the QoS Flow establishment. PGW-C+SMF maps all the other IP flows to the default EPS bearer.

If indirect forwarding tunnels are established, the PGW-C+SMF starts a timer to release the resources that are used for indirect data forwarding.

17

SGW sends Modify Bearer Response to MME.
18

UE initiates a Tracking Area Update procedure. See the S1-based handover in the normal case section in 3GPP TS 23.401, clause 5.5.1.2.2 for details.

This procedure deregisters the old AMF for 3GPP access from HSS+UDM. Any registration that is associated with the non-3GPP access in the old AMF is not removed. It implies that an AMF that is serving the UE over both the 3GPP and non-3GPP accesses does not consider the UE as deregistered over non-3GPP access and remains registered and subscribed to subscription data updates in UDM.

19

If PCC is deployed, then PCF determines to provide the earlier removed PCC rules to the PGW-C+SMF again. With these PCC rules, the PGW-C+SMF initiates the dedicated bearer activation procedure.

20

SGW sends the Delete Indirect Data Forwarding Tunnel Request to MME. The MME sends the Delete Indirect Data Forwarding Tunnel Response to SGW.

21a

AMF initiates NSMF PDU Session Update SM Context Request service operation with an indication to release the forwarding tunnels.
21b

SMF sends the N4 Modification Request to UPF+PGW-U to delete the PDRs and FARs for the indirect tunnels. The PDRs and FARs for the 5G session which are not required are also removed. The IDFT timer that started in Step 2b stops.

Standards Compliance

The IDFT timer support feature complies with the following standards:

  • 3GPP TS 23.502 V16.1.1 (2019-06)

  • 3GPP TS 23.401 version 12.6.0 Release 12

Configuring the IDFT Timer

This section describes how to configure the IDFT timer.

configure 
   profile access test [ eps-fallback | n2 | n26 ] 
   eps-fallback guard enable timeout timeout_value 
   n26 idft enable timeout n26_timeout_value 
   n2 idft enable timeout n2_timeout_value 
      end 
exit

NOTES:

  • profile access : Accesses the profile configuration.

  • test : Accesses the profile instance.

  • eps-fallback : Enters the EPS fallback configuration.

  • n26 : Enters the N26 interface, which is the E-UTRAN and NG-RAN configuration

  • n2 : Enters the N2 interface, which is the NG-RAN configuration.

  • idft enable timeout : Enters the value from 15 to 60 for the IDFT timer to expire.

Bearer Modification for EPS Session on SMF

Feature Description

SMF supports modification of EPS bearer that a PCF or an MME initiates. The SMF+PGW handles the following triggers for this feature:

  • QoS modifications.

  • RAT, ULI, and SGW modifications.

  • UE time zone modifications.

How it Works

The bearer modification for an EPS session on SMF works with the following modifications:

  • PCF and MME-Initiated Bearer Modifications for EPS session on SMF—These procedures are used either when one or multiple EPS Bearer QoS parameters QCI, GBR, MBR, or ARP are modified or to modify the APN-AMBR. The PCF-initiated or the MME-initiated bearer modification procedures do not support the modification from a QCI of non-GBR resource type to a GBR resource type QCI and vice versa.

  • X2 and S1 Based Handover for EPS Session Connected to SMF—The X2-based handover procedure is used to hand over a UE from a source eNodeB to a target eNodeB using X2. In this procedure, the MME is unchanged and the MME determines to relocate the SGW.

    The S1-based handover procedure is used when the X2-based handover cannot be used. The source eNodeB initiates a handover by sending the Handover Required message over the S1-MME reference point. This procedure may relocate the MME or the SGW.

Call Flows

This section includes the following call flows:

  • PCF-Initiated Bearer Modification for EPS session on SMF call flow

  • MME-Initiated Bearer Modification for EPS session on SMF call flow

  • X2 and S1 Based Handover for EPS Session Connected to SMF call flow

PCF-initiated Bearer Modification for EPS session on SMF Call Flow

This section describes the PCF-Initiated Bearer Modification for EPS session on SMF call flow.

Figure 14. PCF-Initiated Bearer Modification for EPS session on SMF Call Flow
Table 7. PCF-Initiated Bearer Modification for EPS session on SMF Call Flow Description
Step Description
1 PCF initiates the N7 Policy Update Notify with the updated parameters of QoS or TFT toward SMF.
2 SMF sends the “200 OK” acknowledgment to PCF. The PCC rules that the PCF provides are mapped to TFTs for the modified dedicated bearer. The associated QoS is mapped to 4G QoS.
3 SMF sends the Update Bearer Request to SGW.
4 SGW sends the Update Bearer Response to SMF with EPS Bearer ID and the modified QoS or TFT for the associated bearer.
5 SMF initiates the PFCP Modification request toward UPF.
6 UPF sends the PFCP Modification Response to SMF with updated QER.
7 SMF sends the PCF Notify message to PCF.
8 PCF sends the “200 OK” acknowledgment to SMF.
MME-initiated Bearer Modification for EPS session on SMF Call Flow

This section describes the MME-Initiated Dedicated Bearer Modification for EPS session on SMF call flow.

Figure 15. MME-Initiated Bearer Modification for EPS session on SMF Call Flow
Table 8. MME-Initiated Bearer Modification for EPS session on SMF Call Flow Description
Step Description
1 HSS sends an Insert Subscriber Data message to the MME. The subscription data includes the details on IMSI, EPS subscribed QoS (QCI and ARP), and the subscribed UE-AMBR and APN-AMBR.
2 If the subscribed UE-AMBR is modified, the MME calculates a new UE-AMBR value and sends the Modify Bearer Command to SGW.
3 SGW sends the Modify Bearer Command message to the SMF or PDN GW. This message includes the details on EPS Bearer Identity, EPS Bearer QoS, and APN-AMBR.
4 SMF or PDN GW sends the updated APN-AMBR to PCF.
5 PCF sends the updated PCC decision to the SMF or PDN GW. The PCF modifies the APN-AMBR that is associated with the default bearer in response to the SMF or PDN GW.
6 SMF sends the Update Bearer Request to SGW.
7 SGW sends the Update Bearer Request to MME. This request message includes the details on EBI, EPS Bearer QoS, TFT, and APN-AMBR.
8 MME sends the Update Bearer Response to SGW.
9 SGW sends the Update Bearer Response as acknowledgment for the bearer modification to the SMF or PDN GW. The response message includes the details on EBI and user location information.
10 UPF sends the PFCP Session Modification Response to SMF. Based on the PCC decision provision message (QoS policy) that is received from the PCF, the SMF or PDN GW initiates the dedicated bearer modification procedure. SMF or PDN GW uses the QoS policy to determine if a service data flow is to be added or removed from an active bearer or if the authorized QoS of a service data flow is changed.
11 UPF updates the PFCP parameters and sends a PFCP Session Modification Response to the SMF or PDN GW. UPF confirms the successful modification of the PFCP session.
12 SMF or PDN GW notifies PCF on the requested PCC decision whether it was enforced or not.
13 PCF sends the “200 OK” acknowledgment to SMF or PDN GW.
X2 and S1 based Handover for EPS Session Connected to SMF

This section describes the X2 and S1-Based Handover for EPS Session Connected to SMF.

Figure 16. X2 and S1 based Handover for EPS Session Connected to SMF
Table 9. X2 and S1 based Handover Call Flow Description
Step Description
1 The SGW sends the Modify Bearer Request to the SMF. This request includes the user location information IE, UE time zone IE, and the serving network IE per PDN connection to the associated PDN GWs information that is received from the MME.
2 In case of change in S-GW, SMF or P-GW sends the PFCP Session Modification Request to the UPF.
3 If Step 2 occurs, the UPF sends the PFCP Session Modification Response to SMF or PDN GW.
4 After receiving the response from the UPF, the SMF or P-GW sends the Modify Bearer Response to S-GW.
5 If PCF has armed notification for QoS modification, the SMF or P-GW sends a notification to the PCF.
6 If Step 5 occurs, the PCF sends the “200 OK” acknowledgment to the SMF or P-GW.
7 If PCF has armed notification for ULI or RAT modifications, SMF or PDN GW sends a notification to PCF.
8 If Step 7 occurs, PCF sends the “200 OK” acknowledgment to SMF or PDN GW.
9 If CHF has armed notification for QoS, ULI, or RAT modifications, SMF or PDN GW sends a notification to PCF.
10 If Step 9 occurs, PCF sends the “200 OK” acknowledgment to SMF or PDN GW.

The following call flow shows the X2-based handover with S-GW relocation:

Figure 17. X2-Based Handover with SGW Relocation Call Flow

For call flow description, see the section 5.5.1.1.3 "X2-based handover with Serving GW relocation" from 3GPP TS 23.401.

The following call flow shows the S1-based handover:

Figure 18. S1-based Handover Call Flow

For call flow description, see section 5.5.1.2.2 "S1-based handover, normal" from 3GPP TS 23.401.

Standards Compliance

The Bearer Modification for EPS Session on SMF feature complies with the following standards:

  • 3GPP TS 23.401

  • 3GPP TS 23.502 V16.1.1 (2019-06)

Session Management Procedures for EPS and 5GC Interworking

Feature Description

The 5G Session Management procedures defined in 3GPP TS 23.502 ensure that the EPS interworking is successful when the UE moves to an LTE 4G radio after performing the initial attach to a 5G NR radio.

Support for Number of Packet Filters in NAS Message

The UE sends the Number of packet filter IE to the SMF in PDU Establishment and Modification request messages. By default, the UE sends a maximum of 16 packet filters.

The UE supports more than 16 packet filters in the following scenarios:

  • When the UE is attaching to the SMF in N1 mode.

  • When the initial attach to the SMF in S1 mode is complete and the 4G to 5G handover is ongoing.

The SMF sends the maximum filters to the PCF in PolicyCreateControl in "NumOfPackFilter" field. If the Number of packet filter IE is received from the UE in N1 mode, then the SMF uses the “Maximum number of supported filters” field in PDU establishment request. If this IE is not received from the UE in N1 mode or if the received value is lesser than 16, the SMF sends the max filters as 16. If the UE attaches to the SMF in S1 mode and the 4G to 5G or 5G to 4G handover is ongoing, the SMF sends the default value, that is, 16 packet filters.

If there is any change in the packet filter value, then the SMF sends the new value to the PCF through PolicyUpdate message along with NUM_OF_PACKET_FILTER trigger.

The SMF controls the maximum filters allowed per PDU session based on the numOfPackFilter IE. If the number of packet filters crosses the maximum allowed by the UE, the SMF caps the packet filters. This means that the SMF drops the PCC rules when the limit crosses and sends the rule report with INCOR_FLOW_INFO failure code.


Note

INCOR_FLOW_INFO is not the correct failure code for this kind of deletion. Use the appropriate failure code when available in the 3GPP specification.

Maximum supported filters are only valid for dynamic rules and not for static and predefined rules.

The "pcc_rule_report_max_supported_filter" statistics is introduced under the policy_pcc_rule_report category. This statistics is incremented if the PCC rule report is generated upon reaching the maximum supported filters.

Support for PCF ID in SmContextCreate

The AMF includes the PCF ID in the Nsmf_PDUSession_CreateSMContext Request. The PCF ID identifies the Home Policy Control Function (H-PCF) in the non-roaming case and the Visited Policy Control Function (V-PCF) in the local breakout roaming case. See the 3GPP specification 23.501, section 6.3.7.1 for more details on when the AMF forwards the PCF ID to the SMF.

When the SMF receives the PCF ID, use the following CLI configuration in the PCF network profile to control the SMF behaviour in using the PCF ID.

UseAmfProvidedPCF [True/False]

The default behaviour is to use the PCF ID provided by AMF in SmContextCreate.

If the PCF ID provided by AMF is not reachable, the SMF behaves as per the configured failure handling template. In this case, it uses the static configuration.

Support for DNN Selection Mode in SmContextCreate

The SMF uses the DNN Selection Mode for deciding whether to accept or reject the UE request.

The SMF uses the DNN Selection Mode for deciding whether to retrieve the Session Management Subscription data. In case the DNN, S-NSSAI of the HPLMN is not explicitly subscribed, the SMF uses the local configuration instead of the Session Management Subscription data.


Note

The preceding use case is not supported.

The SMF validates the IE present in SmContextCreate data. If there is a DnnSelectionMode failure due to the mismatch between DnnSelectionMode and the configured CLI, the SMF does not proceed with the registration. When the DnnSelectionMode failure is observed, the “disc_pdusetup_sm_cxt_unsupported_ie" is incremented as part of the disconnect reasons.

DnnSelectionMode Type Description

Not Present

The SMF sends the subscription request to fetch the subscription data.

Verified

The SMF sends the subscription request to fetch the subscription data.

UE_DNN_NOT_VERIFIED

If the dnn-selection-mode verified ue-provided CLI command is configured as shown in the following configuration, the SMF sends the subscription request to fetch the subscription data. Otherwise, the SMF rejects the Context Request with "Invalid DNN selection Mode" cause.

NW_DNN_NOT_VERIFIED

If the dnn-selection-mode verified network-provided CLI is configured, the SMF sends the subscription request to fetch the subscription data. Otherwise, the SMF rejects the Context Request with "Invalid DNN selection Mode" cause.

The SMF uses the following configuration to configure the DnnSelectionMode.

configure 
   profile smf profile_name 
      dnn-selection-mode [ verified ue-provided | network-provided ] 
      end

One or more DnnSelectionMode types can be configured. By default, the DnnSelectionMode is verified.

Post the subscription request, if no subscription data is fetched from UDM, the SMF falls back to the local DNN profile for subscription data. Neither the subscription data is fetched from the UDM nor the local configuration is present, the SMF sends the SmContextCreateError with subscription failure.

How it Works

Call Flows

This section describes the 5G Session Management procedures to support EPS and 5GC interworking.

PDU Session Creation Call Flow

This section describes the PDU Session Creation procedure as specified in 3GPP TS 23.502, section 4.3.2.2.1.

Figure 19. PDU Session Creation Call Flow
Table 10. PDU Session Creation Call Flow Description
Step Description
1 The UE initiates the UE Requested PDU Session Establishment procedure by transmitting a NAS message containing a PDU Session Establishment Request within the N1 SM container. The PDU Session Establishment Request includes a PDU session ID, Requested PDU Session Type, a Requested SSC mode, 5GSM Capability PCO, SM PDU DN Request Container, Number of Packet Filters, and optionally Always-on PDU Session Requested.
2 The AMF performs SMF selection as described in 3GPP specification.
3 The AMF includes EPS Interworking Indication in the Nsmf_PDUSession_CreateSMContext Request message sent to the SMF. This parameter indicates whether the UE can perform 4G to 5G handover (and vice versa) and if it is allowed with or without the presence of the N26 interface between the AMF and MME.
4 If the EPS Interworking Indication received from the AMF indicates that the UE supports EPS interworking and the SMF determines (for example, if EPS interworking is allowed for this DNN and S-NSSAI based on UE subscription data) that the PDU session supports EPS interworking, the PGW-C+SMF FQDN for the S5/S8 interface is included in the Nudm_UECM_Registration Request message.
5

The SMF sends either Nsmf_PDUSession_CreateSMContext Response (Cause, SM Context ID or N1 SM container (PDU Session Reject (Cause))) or an Nsmf_PDUSession_UpdateSMContext Response depending on the Request received in Step 3.

If the SMF received Nsmf_PDUSession_CreateSMContext Request in Step 3 and the SMF can process the PDU Session Establishment Request, the SMF creates an SM context and responds to the AMF by providing an SM Context Identifier.

6

(Optional). If the Request Type in Step 3 indicates "Existing PDU Session", the SMF does not perform secondary authorization and authentication.

If the Request Type received in Step 3 indicates "Emergency Request" or "Existing Emergency PDU Session", the SMF does not perform secondary authorization and authentication.

If the SMF needs to perform secondary authorization and authentication during the establishment of the PDU Session by a DN-AAA server as described in 3GPP TS 23.501, section 5.6.6, the SMF triggers the PDU session establishment authentication and authorization as described in 3GPP TS 23.501, section 4.3.2.3.

7a If dynamic PCC is to be used for the PDU Session, the SMF performs PCF selection as described in 3GPP TS 23.501, section 6.3.7.1. If the Request Type indicates "Existing PDU Session" or "Existing Emergency PDU Session", the SMF uses the PCF already selected for the PDU Session. Otherwise, the SMF may apply local policy.
7b The SMF performs the mapping of PCC rules and 5G QoS parameters to 4G TFTs and 4G QoS as described in the Generating EPS PDN Connection Parameters from 5G PDU Session Parameters section in this document. Based on the QoS flows, the SMF+PGW-C also determines the number of dedicated bearers required for the session when it hands off to EPS and the required flows (all non-GBR flows) in the default bearer. The SMF+PGW-C saves the mapping of 5G flows to 4G bearers.
8 If the Request Type in Step 3 indicates "Initial request", the SMF selects an SSC mode for the PDU Session as described in 3GPP TS 23.501, section 5.6.9.3. The SMF also selects one or more UPFs as needed as described in 3GPP TS 23.501, section 6.3.3.
9

The SMF performs an SMF-initiated SM Policy Association Modification procedure as defined in 3GPP TS 23.502, section 4.16.5.1 to provide information on the Policy Control Request Trigger conditions that have been met. If Request Type is "initial request" and dynamic PCC is deployed and PDU Session Type is IPv4 or IPv6 or IPv4v6, the SMF notifies the PCF (if the Policy Control Request Trigger condition is met) with the allocated UE IP address/prefix(es).

SMF+PGW-C initiates the EBI allocation procedure as defined in 3GPP TS 23.502, section 4.11.1.4.

10

If the Request Type indicates "initial request", the SMF initiates an N4 Session Establishment procedure with the selected UPF. Otherwise, it initiates an N4 Session Modification procedure with the selected UPF.

If multiple UPFs are selected for the PDU Session, the SMF initiates N4 Session Establishment/Modification procedure with each UPF of the PDU Session in this step.

11 In the non-roaming or LBO scenario, the PGW-C+SMF includes the mapped EPS bearer context(s) and the corresponding QoS flow(s) to be sent to the UE in the N1 SM container. The PGW-C+SMF also indicates the mapping between the QoS flow(s) and mapped EPS bearer context(s) in the N1 SM container. The PGW-C+SMF also includes the mapping between the received EBI(s) and QFI(s) in the N2 SM information to be sent to the NG-RAN. The PGW-C+SMF sends the N1 SM container and N2 SM information to the AMF through the Namf_Communication_N1N2MessageTransfer message.
12

The AMF sends N2 PDU Session Request (N2 SM information, NAS message (PDU Session ID, N1 SM container (PDU Session Establishment Accept))) to the (R)AN.

The AMF sends the NAS message containing PDU Session ID and PDU Session Establishment Accept targeted to the UE and the N2 SM information received from the SMF within the N2 PDU Session Request to the (R)AN.

13 The (R)AN may issue AN-specific signaling exchange with the UE that is related with the information received from the SMF. For example, in case of an NG-RAN, an RRC Connection Reconfiguration may take place with the UE establishing the necessary NG-RAN resources related to the QoS rules for the PDU Session Request received in Step 12.
14 (R)AN issues N2 PDU Session Response (PDU Session ID, Cause, N2 SM information (PDU Session ID, AN Tunnel Info, List of accepted/rejected QFI(s), User Plane Enforcement Policy Notification)) to the AMF.
15

The AMF sends Nsmf_PDUSession_UpdateSMContext Request (N2 SM information, Request Type) to the SMF.

The AMF forwards the N2 SM information received from (R)AN to the SMF.
16a The SMF initiates an N4 Session Modification procedure with the UPF. The SMF provides AN Tunnel Information and the corresponding forwarding rules to the UPF.
16b

The UPF provides an N4 Session Modification Response to the SMF.

If multiple UPFs are used in the PDU session, the UPF in Step 16a refers to the UPF terminating N3.

After this step, the UPF delivers any downlink packets to the UE that may have been buffered for this PDU session.
17 The SMF sends Nsmf_PDUSession_UpdateSMContext Response (Cause) to the AMF.
18

(Conditional) The SMF sends Nsmf_PDUSession_SMContextStatusNotify (Release) to the AMF.

If during the procedure, any time after Step 5, the PDU Session establishment is not successful, the SMF informs the AMF by invoking Nsmf_PDUSession_SMContextStatusNotify (Release). The SMF also releases any N4 session(s) created, any PDU session address if allocated (for example, IP address) and releases the association with PCF, if any.

19 If the PDU Session Type is IPv6 or IPv4v6, the SMF generates an IPv6 Router Advertisement and sends it to the UE via N4 and the UPF.
20

If the PDU Session Establishment failed after Step 4, the SMF performs the following:

  • The SMF unsubscribes to the modifications of Session Management Subscription data for the corresponding (SUPI, DNN, S-NSSAI), using Nudm_SDM_Unsubscribe (SUPI, Session Management Subscription data, DNN, S-NSSAI), if the SMF is no more handling a PDU session of the UE for this (DNN, S-NSSAI). The UDM may unsubscribe to the modification notification from UDR by Nudr_DM_Unsubscribe (SUPI, Subscription Data, Session Management Subscription data, S-NSSAI, DNN).

  • The SMF deregisters for the given PDU session using Nudm_UECM_Deregistration (SUPI, DNN, PDU Session ID). The UDM may update corresponding UE context by Nudr_DM_Update (SUPI, Subscription Data, UE context in SMF data).

PDU Session Modification Call Flow

This section describes the PDU session modification procedure as specified in 3GPP TS 23.502, section 4.3.3.2.

Figure 20. PDU Session Modification Call Flow
Table 11. PDU Session Modification Call Flow Description
Step Description

1a

The UE initiates the UE Requested PDU Session Modification procedure by transmitting a NAS message containing a PDU Session Modification Request within the N1 SM container. The PDU Session Modification Request includes a PDU session ID, Packet Filters, Operation, Requested QoS, Segregation, and 5GSM Core Network Capability.

1b

(SMF-requested modification) The PCF performs a PCF-initiated SM Policy Association Modification procedure to notify the SMF about the modification of policies. The policy decision or upon AF requests, for example, Application Function influence on traffic routing, triggers this procedure.

1c

(SMF-requested modification) The UDM updates the subscription data of SMF by Nudm_SDM_Notification (SUPI, Session Management Subscription Data). The SMF updates the Session Management Subscription Data and acknowledges the UDM by returning an Ack with (SUPI).

1d

(SMF-requested modification) The SMF decides to modify PDU session. This procedure is also triggered based on locally configured policy or triggered from the (R)AN.

If the SMF receives one of the triggers in step 1b to 1d, the SMF starts SMF-requested PDU Session Modification procedure.

1e

(AN-initiated modification) (R)AN indicates to the SMF when the AN resources onto which a QoS Flow is mapped are released irrespective of whether notification control is configured.

(R)AN sends the N2 message (PDU Session ID, N2 SM information) to the AMF. The N2 SM information in the smf_PDU_Session_UpdateContext includes the following information:

  • QoS Flow Identifier (QFI)

  • User location Information

  • QoS Flow Release List IE - list of QoS flows which are released by NG-RAN node

  • QoS Flow Notify List IE and Notification Cause IE - list of GBR QoS flows that fulfilled a specific criteria, and the flows that missed fulfilling the criteria

The SMF supports AN-initiated modification to release the QFI from RAN. For details on this support, see the following section.

2

 The SMF reports the subscribed event to the PCF by performing an SMF-initiated SM Policy Association Modification procedure. The SMF skips this step if the PDU Session Modification procedure is triggered by step 1b or 1d. If the dynamic PCC is not deployed, the SMF may apply local policy to decide whether to change the QoS profile. The SMF does not invoke the steps 3 to 7 when the PDU Session Modification requires only action at a UPF (for example, gating).

3a

For UE or AN-initiated modification, the SMF responds to the AMF through Nsmf_PDUSession_UpdateSMContext including N2 SM information and N1 SM container.

The N2 SM information carries information that the AMF provides to the (R)AN. It includes the QoS profiles and the corresponding QFIs to notify the (R)AN that one or more QoS flows were added, or modified. It includes only QFI(s) to notify the (R)AN that one or more QoS flows were removed.

The N1 SM container carries the PDU Session Modification Command that the AMF provides to the UE. It includes the QoS rule(s), QoS rule operation, QoS Flow level QoS parameters if needed for the QoS Flow(s) associated with the QoS rule(s), and Session-AMBR.

3b

For SMF-requested modification, the SMF invokes Namf_Communication_N1N2MessageTransfer including N2 SM information and N1 SM container.

If the UE is in CM-IDLE state and an Asynchronous type communication (ATC) is activated, the AMF updates and stores the UE context based on the Namf_Communication_N1N2MessageTransfer, and skips the steps 4, 5, 6 and 7. When the UE is reachable, that is, when the UE enters CM-CONNECTED state, the AMF forwards the N1 message to synchronize the UE context with the UE.

4

The AMF sends N2 PDU Session Request (N2 SM information received from the SMF, NAS message (PDU Session ID, N1 SM container (PDU Session Modification Command))) Message to the (R)AN.

5

The (R)AN issues AN-specific signalling exchange with the UE that is related with the information received from the SMF. For example, in an NG-RAN, an RRC Connection Reconfiguration takes place with the UE modifying the necessary (R)AN resources related to the PDU session.

6

The (R)AN acknowledges N2 PDU Session Request by sending a N2 PDU Session Ack Message to the AMF.

7

The AMF forwards the N2 SM information and the User location Information from the AN to the SMF via Nsmf_PDUSession_UpdateSMContext service operation. The SMF sends Nsmf_PDUSession_UpdateSMContext Response.

If the (R)AN rejects QFI(s), the SMF updates the QoS rules and QoS Flow level QoS parameters if needed for the QoS Flow(s) associated with the QoS rule(s) in the UE accordingly.

8

The SMF updates N4 session of the UPF(s) that are involved by the PDU Session Modification by sending N4 Session Modification Request message to the UPF.

9

The UE acknowledges the PDU Session Modification Command by sending a NAS message (PDU Session ID, N1 SM container (PDU Session Modification Command Ack)).

10

The (R)AN forwards the NAS message to the AMF.

11

The AMF forwards the N1 SM container (PDU Session Modification Command Ack) and User Location Information from the AN to the SMF through Nsmf_PDUSession_UpdateSMContext service operation. The SMF sends Nsmf_PDUSession_UpdateSMContext Response.

12

The SMF updates N4 session of the UPF(s) that are involved by the PDU Session Modification by sending N4 Session Modification Request (N4 Session ID) message to the UPF.

For a PDU Session of Ethernet PDU Session Type, the SMF notifies the UPF to add or remove Ethernet Packet Filter Set(s) and forwarding rule(s).

13

If the SMF interacts with the PCF in step 1b or 2, the SMF notifies the PCF whether the PCC decision is enforced or not by performing an SMF-initiated SM Policy Association Modification procedure.

The SMF notifies any entity that has subscribed to User Location Information related with PDU Session change.

If the step 1b is triggered to perform Application Function influence on traffic routing, the SMF reconfigures the User Plane of the PDU session.

Releasing QFI During AN-initiated Modification Procedure

For the SMF to support AN-initiated modification to release the QFIs, perform the following steps:

  1. If the EPS Interworking Indication is enabled for a given PDU session, the SMF initiates the EBI release towards the AMF.

  2. The SMF sends N4 Modification to the UPF to delete the Packet Detection Rule (PDR), QoS Enforcement Rule (QER), and Usage Reporting Rule (URR) related to the flows being released.

  3. The SMF initiates N1N2TransferMessage containing N1 PDU Session Modification command. This message includes information about the deleted flows, Mapped EPS Bearer Context.

  4. Then, the SMF interacts with the PCF to report the flows released for the rules if “RES_RELEASE” trigger is set.


Note

The "policy_pdu_flows_total" statistics is available to check the released flows.
EPS Interworking Indication in PDU Session Modification

The EpsInternetworkingIndication field denotes the possibility of handover between EPS and 5GC. This field holds the following values:

  • NONE: The PDU session cannot be moved to EPS.

  • WITH_N26: The PDU session is moved to EPS, with N26 interface supported during EPS interworking procedures.

  • WITHOUT_N26: The PDU session is moved to EPS, without N26 interface supported during EPS interworking procedures.

The SMF allows the 4G to 5G handover and vice-versa only if the EpsInternetworkingIndication value is set to WITH_N26. For other values of EpsInternetworkingIndication, the SMF rejects the handovers.

During 4G and 5G PDU session establishment, if the EPS internetworking indication is received from the AMF, the SMF includes PGW-C+SMF FQDN for S5/S8 interface in the UDM Registration request.

With the EPS Interworking Indication Support Enabled:

If the EpsInternetworkingIndication value changes from NONE or WITHOUT_N26 to WITH_N26 for a created PDU session, follow these steps to support the EPS Interworking Indication change in the PDU modification procedure.

  1. The AMF invokes the Nsmf_PDUSession_UpdateSMContext request with the changed EpsInterworkingIndication value.

  2. The SMF receives the Nsmf_PDUSession_UpdateSMContext request from the AMF, and initiates the Namf_Communication_EbiAssignmentRequest. This request includes the PDU Session ID and Allocation/Retention Priority (ARP) List.

  3. The AMF sends Namf_Communication_EbiAssignmentResponse to the SMF. The AMF sends the following through the response:

    • assignedEbiList containing the successfully assigned EBIs.

    • failedArpList containing the failed ARPs for which the EBI assignment failed.

    • 4XX/5XX error along with AssignEbiError representing the EBI assignment failure.

  4. The SMF sends N1N2MessageTransfer request message if the EBIs are created successfully. This request includes the following:

    • N1:PDU SESSION MODIFICATION COMMAND ([Mapped EPS Bearer Contexts,Create])

    • N2:N2_PDU_SESSION_RESOURCE_MODIFY_REQUEST_TRANSFER (QoS Flow Add or Modify Request Item with EPS Radio Access Bearer (E-RAB) ID and QoS Flow ID)


    Note

    If the UE is in Idle mode, the SMF skips sending the N2 message.

  5. The SMF informs mapped EPS bearer context in the UE using N1 message. The SMF waits for N1: PDU SESSION MODIFICATION COMPLETE message.

  6. The SMF informs EBI to QoS Flow Identifier (QFI) mapping to gNodeB using N2 message. The SMF waits for N2: PDU SESSION RESOURCE MODIFY RESPONSE TRANSFER message.

  7. The SMF completes the PDU Session Modification procedure.

With the EPS Interworking Indication Support Disabled:

If the EpsInternetworkingIndication value changes from WITH_N26 to NONE or WITHOUT_N26 for a created PDU session, follow these steps to support the EPS Interworking Indication change in the PDU modification procedure.

  1. The SMF receives the Nsmf_PDUSession_UpdateSMContext request with the changed EpsInterworkingIndication value from the AMF.

  2. The SMF sends N1N2MessageTransfer request message. This request includes the following:

    • N1:PDU SESSION MODIFICATION COMMAND ([Mapped EPS Bearer Contexts,Delete])

    • N2:N2_PDU_SESSION_RESOURCE_MODIFY_REQUEST_TRANSFER


    Note

    If the UE is in Idle mode, the SMF skips sending the N2 message.

  3. The SMF deletes Mapped EPS bearer context in UE using N1 message. The SMF waits for N1: PDU SESSION MODIFICATION COMPLETE message.

  4. The SMF deletes EBI to QFI mapping to gNodeB using N2 message. The SMF waits for N2: PDU SESSION RESOURCE MODIFY RESPONSE TRANSFER message.

  5. The SMF completes the PDU Session Modification procedure.

Use the show subscriber command to determine the EPS interworking status of the PDU session, and the EBI mapping for the QoS flows.

PDU Session Release Call Flow

The PDU Session Release procedure is used to release all the resources associated with a PDU session, including:

  • The IP address/prefixes allocated for an IP-based PDU session

  • Any UPF resource that was used by the PDU session.

  • Any access resource that was used by the PDU session.

The SMF notifies any entity associated with the PDU session: PCF, Data Network (DN) (for example, when DN authorization has taken place at PDU session establishment), and so on.

There are different ways to initiate the PDU session release. It can be from UE, network, AMF, or RAN.

UE-initiated PDU Session Release Call Flow

The UE-initiated PDU session release procedure allows the UE to request the release of the PDU session. In the case of Local Breakout (LBO), the procedure is as in the case of non-roaming with the difference that the AMF, the SMF, the UPF, and the PCF are located in the visited network.

The following figure depicts the UE-initiated PDU session release procedure to support EPS interworking on the SMF as specified in 3GPP TS 23.502, section 4.3.4.2.

Figure 21. UE-initiated PDU Session Release Call Flow
Table 12. UE-initiated PDU Session Creation Call Flow Description
Step Description

1, 2

The UE sends PDU_SESSION_RELEASE_REQUEST in NAS message to the AMF through the RAN. The AMF sends the message to the SMF in SmContextUpdateRequest.

3, 4

The SMF sends N4SessionReleaseRequest to the UPF. The UPF sends response for the same.

5

The SMF sends SmContextUpdateResponse message with N1 and N2 content.

  • N1: PDU_SESSION_RELEASE_COMMAND

  • N2: N2_PDU_SESSION_RESOURCE_RELEASE_COMMAND. exclude if the SMF is in IDLE mode. Also, skip the steps 8, 9, and 10.

6, 7

The AMF exchanges the message with RAN. The RAN forwards it to the UE.

8, 9, 10

The RAN sends N2 release response to the AMF. The AMF sends N2 release response (N2_PDU_SESSION_RESOURCE_RELEASE_RESPONSE_TRANSFER) in N11 SmContextUpdateRequest message. The SMF responds back to the AMF as SmContextUpdateResponse.

11, 12, 13, 14

The UE sends N1 release response in NAS message to the AMF through the RAN. The AMF sends N1 release response (PDU_SESSION_RELEASE_COMPLETE) in N11 SmContextUpdateRequest message. The SMF responds back to the AMF as SmContextUpdateResponse.

15, 16

The SMF sends delete charging request to the CHF. The CHF responds back to the SMF with delete response.

17, 18

The SMF sends SmContextStausNotify to the AMF. The AMF responds back with SmContextStausNotifyResponse message.

19, 20

The SMF sends delete request to the PCF. The PCF responds back to the SMF with delete response

21, 22

The SMF sends UDM deregistration request. The UDM responds back to the SMF with deregistration response.
Network-initiated PDU Session Release Call Flow

The network-initiated PDU session release procedure allows the AMF, the SMF or the PCF to initiate the release of a PDU session.

The following figure depicts the network-initiated PDU session release call flow.

Figure 22. Network-initiated PDU Session Release Call Flow
Table 13. Network-initiated PDU Session Creation Call Flow Description
Step Description
1

This procedure can be triggered by PCF, CHF, UDM, UPF or CLI (clear subscriber) to initiate the release of a PDU session.

2, 3

The SMF sends N4SessionReleaseRequest to the UPF. The UPF sends response for the same.

Note 

Skip the steps 4 to 14 if the AMF has notified that the UE is not reachable.

4

The SMF sends N1N2MessageTransfer message with N11, N1 and N2 content.

  • N11: SkipInd=True

  • N1: PDU_SESSION_RELEASE_COMMAND

  • N2: N2_PDU_SESSION_RESOURCE_RELEASE_COMMAND. exclude if the SMF is in IDLE mode. Also, skip the steps 8, 9, and 10.

5

The AMF responds back to the SMF with the cause included in the N1N2MessageTransferRsp message.

Note 

Skip the steps 6 to 14 if the AMF sends the cause as N1_MSG_NOT_TRANSFERRED in step 5.

6, 7

The AMF exchanges the message with RAN. The RAN forwards it to the UE.

8, 9, 10

The RAN sends N2 release response to the AMF. The AMF transfers N2 release response (N2_PDU_SESSION_RESOURCE_RELEASE_RESPONSE_TRANSFER) in N11 SmContextUpdateRequest message. The SMF responds back to the AMF as SmContextUpdateResponse.

11, 12, 13, 14

The UE sends N1 release response in the NAS message to the AMF through the RAN. The AMF sends the N1 release response (PDU_SESSION_RELEASE_COMPLETE) in N11 SmContextUpdateRequest message. The SMF responds back to the AMF as SmContextUpdateResponse.

15, 16

The SMF sends delete charging request to the CHF. The CHF responds back to the SMF with delete response.

17, 18

The SMF sends SmContextStausNotify to the AMF. The AMF responds back with the SmContextStausNotifyResponse message.

19, 20

The SMF sends delete request to the PCF. The PCF responds back to the SMF with delete response.

21, 22

The SMF sends UDM deregistration request. The UDM responds back to the SMF with deregistration response.
AMF-initiated PDU Session Release

The AMF-initiated PDU session release procedure allows the AMF to initiate the release of a PDU session.

The following figure depicts the AMF-initiated PDU session release call flow.

Figure 23. AMF-initiated PDU Session Release Call Flow
Table 14. AMF-initiated PDU Session Creation Call Flow Description
Step Description
1

The AMF sends SmContextReleaseRequest.

2, 3

The SMF sends N4SessionReleaseRequest to the UPF. The UPF sends response for the same.

4

The SMF sends SmContextReleaseResponse to the AMF.

5, 6

The SMF sends delete charging request to the CHF. The CHF responds back to the SMF with delete response.

7, 8

The SMF sends delete request to the PCF. The PCF responds back to the SMF with delete response.

9, 10

The SMF sends UDM deregistration request. The UDM responds back to the SMF with deregistration response.
AMF-initiated PDU Session Release with N11 Release=True

The AMF-initiated PDU session release procedure allows the AMF to initiate the release of a PDU session with the N11 release in the SmContextModifyRequest being set to True.

The following figure depicts the AMF-initiated PDU session release call flow with the N11 release=True.

Figure 24. AMF-initiated PDU Session Release with N11 Release=True
Table 15. AMF-initiated PDU Session Creation Call Flow (N11 release=true) Description
Step Description
1

The AMF sends SmContextModifyRequest with release=True in 2 causes REL_DUE_TO_DUPLICATE_SESSION_ID or REL_DUE_TO_SLICE_NOT_AVAILABLE.

2, 3

The SMF sends N4SessionReleaseRequest to the UPF. The UPF sends response for the same.

4

The SMF sends SmContextUpdateResponse message with N1 and N2 content.

  • N1: PDU_SESSION_RELEASE_COMMAND, exclude if cause is REL_DUE_TO_DUPLICATE_SESSION_ID, skip steps 10,11,12,13

  • N2: N2_PDU_SESSION_RESOURCE_RELEASE_COMMAND. exclude if the SMF is in IDLE mode. Also, skip the steps 7, 8, and 9.

5, 6

The AMF exchanges message with RAN. The RAN forwards it to the UE.

7, 8, 9

The RAN sends N2 release response to the AMF. The AMF sends N2 release response (N2_PDU_SESSION_RESOURCE_RELEASE_RESPONSE_TRANSFER) in N11 SmContextUpdateRequest message. The SMF responds back to the AMF as SmContextUpdateResponse.

10, 11, 12, 13

The UE sends N1 release response in NAS message to the AMF through the RAN. The AMF sends N1 release response (PDU_SESSION_RELEASE_COMPLETE) in N11 SmContextUpdateRequest message. The SMF responds back to the AMF as SmContextUpdateResponse.

14, 15

The SMF sends delete charging request to the CHF. The CHF responds back to the SMF with delete response.

16, 17

The SMF sends SmContextStausNotify to the AMF. The AMF responds back with SmContextStausNotifyResponse message.

18, 19

The SMF sends delete request to the PCF. The PCF responds back to the SMF with delete response.

20, 21

The SMF sends UDM deregistration request. The UDM responds back to the SMF with deregistration response.
RAN-initiated PDU Session Release Call Flow

The RAN-initiated PDU session release procedure allows the RAN to initiate the release of a PDU session.

The following figure depicts the RAN-initiated PDU session release call flow.

Figure 25. RAN-initiated PDU Session Release Call Flow
Table 16. AMF-initiated PDU Session Creation Call Flow Description
Step Description
1

The AMF sends SmContextModifyRequest with N2 type: N2_PDU_SESSION_RESOURCE_NOTIFY_RELEASED_TRANSFER.

2, 3

The SMF sends N4SessionModificationRequest to the UPF with changing packet rule to Buffer from Forward. The UPF sends the response for the same, that is, the SMF moving to IDLE state.

4

The SMF sends SmContextUpdateResponse message with UpState as Deactivated.
EPS Bearer ID Allocation

This section describes the EPS Bearer ID Allocation procedure.

Figure 26. EPS Bearer ID Allocation Call Flow

Note
Not all the steps in the preceding call flow are supported. For more details, see the descriptions in the following table.
Table 17. EPS Bearer ID Allocation Call Flow Description
Step Description
1

The EBI Assignment procedure is initiated as specified in the relevant sections of 3GPP TS 23.502. The relevant steps of the procedure are executed as specified in the preceding call flow.

Note 

Roaming scenarios are currently not supported.
2 If the PGW-C+SMF (or H-SMF for home-routed cases) determines that EPS bearer IDs (based on operator policies, S-NSSAI, User Plane Security Enforcement information) need to be assigned to the QoS flows in the PDU session, the PGW-C+SMF invokes Namf_Communication_EBIAssignment Request (PDU Session ID, ARP list).
Step 3 through Step 6 apply only when the AMF needs to revoke EBI that was previously allocated for a UE to serve a new SMF request of EBI for the same UE.
3 (Conditional) If the AMF has no available EBIs, the AMF may revoke an EBI that was assigned to QoS flows based on the ARPs and S-NSSAI stored during PDU Session Establishment, EBI information in the UE context and local policies. If an assigned EBI is to be revoked, the AMF invokes Nsmf_PDUSession_UpdateSMContext (EBI(s) to be revoked) to request the related SMF (called “SMF serving the released resources”) to release the mapped EPS QoS parameters corresponding to the EBI to be revoked. The AMF stores the association of the assigned EBI, ARP pair to the corresponding PDU Session ID and SMF address.
4

The “SMF serving the released resources” that receives the request in Step 3 invokes Namf_Communication_N1N2Message Transfer (N2 SM information (PDU Session ID, EBI(s) to be revoked), N1 SM container (PDU Session Modification Command (PDU Session ID, EBI(s) to be revoked))) to inform the (R)AN and the UE to remove the mapped EPS QoS parameters corresponding to the EBI(s) to be revoked. In home-routed roaming scenario, the H-SMF includes EBI(s) to be revoked to V-SMF to inform V-SMF to remove the mapped EPS bearer context corresponding to the EBI(s) to be revoked.

The SMF can also decide to remove the QoS flow if it is not acceptable to continue the service when no corresponding EPS QoS parameters can be assigned.

For home-routed roaming scenario, the "SMF serving the released resources" sends an N4 Session Modification Request to request the PGW-U+UPF to release the N4 session corresponding to the revoked EBI(s).

In home-routed roaming case, the V-SMF starts a VPLMN-initiated QoS Modification for the PDU session. The V-SMF invokes the Namf_Communication_N1N2Message Transfer based on the corresponding QoS modification message received from H-SMF.

5

If the UE is in CM-CONNECTED state, the AMF sends N2 PDU Session Request (N2 SM information received from SMF, NAS message (PDU Session ID, N1 SM container (PDU Session Modification Command))) message to the (R)AN.

If the UE is in CM-IDLE state and an ATC is activated, the AMF updates and stores the UE context based on the Namf_Communication_N1N2MessageTransfer and Step 5 and Step 6 are skipped. When the UE is reachable, for example, when the UE enters CM-CONNECTED state, the AMF forwards the N1 message to synchronize the UE context with the UE.

6 The relevant steps of the procedure are executed as specified in the preceding figure.
7

If the AMF successfully assigns EBI(s), it responds with the assigned EBI(s). Otherwise, it responds with a cause indicating EBI assignment failure.

If a PDU session from another SMF already exists towards the same DNN, the AMF either rejects the EBI assignment request, or revokes the EBI(s) from the existing PDU session(s) to the same DNN but different SMF. The AMF makes the decision based on the operator policy.

Note 

The preceding statement applies only when the S-NSSAI(s) for the PDU sessions are different, otherwise the same SMF is selected for PDU sessions to the same DNN.

8

The PGW-C+SMF sends an N4 Session Establishment/Modification Request to the PGW-U+UPF.

For home-routed roaming scenario, if the EBI is assigned successfully, the PGW-C+SMF prepares the CN Tunnel Info for each EPS bearer. If the CN Tunnel info is allocated by the PGW-C+SMF, the PGW-U tunnel info for the EPS bearer may be provided to PGW-U+UPF. If the CN Tunnel info is allocated by PGW-U+UPF, the PGW-U+UPF sends the PGW-U tunnel info for the EPS bearer to the PGW-C+SMF. The PGW-U+UPF is ready to receive the uplink packets from E-UTRAN.

Note 

In the home-routed roaming scenario, the PGW-C+SMF prepares the CN Tunnel Info for each EPS bearer and provides it to the V-SMF. Thus, when the UE moves to EPS network, the V-SMF does not need to interact with the PGW-C+SMF to get the EPS bearer context(s).

Note 

If the CN Tunnel info is allocated by the PGW-C+SMF and not provided to PGW-U+UPF at PDU session establishment, when the UE moves to the target RAT the PGW-U+UPF cannot receive uplink (UL) data until the PGW-C+SMF has provided the Tunnel Info to the PGW-U+UPF in N4 Session Modification. This causes a short interruption to the UL data during the inter-system handover execution.

9

If the PGW-C+SMF receives any EBI(s) from the AMF, it adds the EBI(s) received into the mapped EPS bearer context(s).

In home-routed roaming scenario, the PGW-C+SMF generates EPS bearer context, which includes per EPS bearer PGW-U tunnel information. In addition, if the default EPS bearer is generated for the corresponding PDN Connection of PDU Session (that is, during the PDU Session establishment procedure), the PGW-C+SMF generates the PGW-C tunnel information of the PDN connection and includes it in UE EPS PDN connection.

9a (Conditional) In non-roaming or LBO scenario, the PGW-C+SMF includes the mapped EPS bearer context(s) and the corresponding QoS Flow(s) to be sent to the UE in the N1 SM container. PGW-C+SMF also indicates the mapping between the QoS flow(s) and mapped EPS bearer context(s) in the N1 SM container. PGW-C+SMF also includes the mapping between the received EBI(s) and QFI(s) in the N2 SM information to be sent to the NG-RAN. The PGW-C+SMF sends the N1 SM container and N2 SM information to the AMF via Namf_Communication_N1N2MessageTransfer.
9b (Conditional) In home-routed roaming scenario, the PGW-C+SMF sends the mapped EPS bearer context(s), the mapping between the received EBI(s) and QFI(s), and EPS bearer context to the V-SMF via Nsmf_PDUSession_Create Response during PDU Session Establishment, or via Nsmf_PDUSession_Update Request during PDU Session Modification. The V-SMF stores the EPS bearer context, and generates N1 SM container and N2 SM information, and forwards them to the AMF via Namf_Communication_N1N2MessageTransfer.
10 The N1 SM container and N2 SM information are sent to the UE and NG-RAN respectively. The relevant steps of the procedure are executed as specified in the preceding figure.

Standards Compliance

This feature complies with the following standards:

  • 3GPP TS 23.401, Version 15.6.0

  • 3GPP TS 23.502, Version 15.4.0

Limitations

TFT IE in mapped EPS bearer context is currently not supported.

Generating EPS PDN Connection Parameters from 5G PDU Session Parameters

This section describes how to generate the EPS PDN connection parameters from the 5G PDU session parameters in the PGW-C+SMF.

When the PGW-C+SMF is requested to set up or modify a PDN connection or a PDU session that supports interworking between EPS and 5GC, the PGW-C+SMF generates the PDN connection parameters from the PDU session parameters.

When the PGW-C+SMF generates the PDN connection parameters based on the PDU session parameters, the following rules hold:

  • PDN Type: The PDN type is set to IPv4 or IPv6 if the PDU Session Type is IPv4 or IPv6 respectively. The PDN type is set to Non-IP for Ethernet and Unstructured PDU Session Types.

  • EPS Bearer ID: The EBI is requested from the AMF during the establishment of a QoS Flow as described in 3GPP TS 23.502, section 4.11.1.4.1, for PDU sessions that support interworking between EPS and 5GC. The EBI is obtained from MME during the establishment of an EPS bearer (that is triggered by an establishment of the QoS Flow) as defined in 3GPP TS 23.401 for PDN connections hosted by PGW-C+SMF. The association between EBI and QoS Flow is stored by the SMF.

  • APN-AMBR: APN-AMBR is set according to the operator policy. For example, taking the session AMBR into account.

  • EPS QoS parameters (including ARP, QCI, GBR, and MBR):

    • If the QoS Flow is mapped to one EPS bearer: ARP, GBR, and MBR of the EPS bearer is set to the respective ARP, GFBR, and MFBR of the corresponding QoS Flow.

    • For standardized 5QIs, the QCI is mapped 1:1 to the 5QI. For non-standardized 5QIs, the PGW-C+SMF derives the QCI based on the 5QI and operator policy.


Note

A GBR QoS flow is mapped 1:1 to a GBR dedicated EPS Bearer if an EBI has been assigned. All other GBR QoS flows will be terminated during interworking. If multiple QoS flows are mapped to one EPS bearer, the EPS bearer parameters are set based on the operator policy. For example, EPS bearer QoS parameters are set according to the highest QoS of all mapped QoS flows.


Note

Non-GBR QoS flows for which no EBI has been assigned are mapped to the default EPS bearer.

5G to EPS Handover Using N26 Interface

Feature Description

The SMF supports handover of PDU sessions to EPS on 5GC when the N26 interface is present between the MME and the AMF. The handover supports the creation of applicable default and dedicated bearers.

How it Works

This section describes the 5G to EPS handover procedure and the 5G to EPS handover cancellation procedure.

Call Flows

This section describes the following call flows:

  • 5G to EPS Handover Call Flow

  • 5G to EPS Handover Cancellation Flow

5G to EPS Handover Call Flow

This section describes the 5G to EPS handover call flow with N26 interface.

The 5G to EPS Handover procedure for the EPS session is compliant with 3GPP 23.502, section 4.11.1.2.1.

  1. The AMF requests the SMF to provide the SM Context using Nsmf_PDUSession_ContextRequest.

  2. The SMF sends N4 Session Modification to the UPF to establish the CN tunnel for each EPS bearer. The bearer mapping to the 5G QoS and PCC rules received from PCC must already be present with the SMF. The SMF must also have the bearer IDs obtained from the Bearer ID Allocation procedure. The SMF creates new PDRs for the N4 session and gets TEID allocated for each bearer as required by the 4G system.

  3. The SMF provides EPS bearer contexts to the AMF. The SMF also provides the CN tunnel information to AMF for all bearers for the uplink traffic from E-UTRAN.

  4. If indirect data forwarding applies, the AMF sends the Nsmf_PDUSession_UpdateSMContext Request (S-GW address(es) and S-GW DL TEID(s) for data forwarding) to the SMF, for creating the indirect data forwarding tunnel.

  5. The SMF sends N4 Modification Request to the UPF to create additional PDRs and FARs to receive the redirected DL data over the indirect tunnel from NG RAN and forwards them to eNodeB. The uplink PDRs must have QFI to match the forwarded DL data from NG-RAN and the associated QER will not have QFI as data needs to be forwarded to the eNodeB. The FAR redirects the received data to the eNodeB over appropriate tunnel based on the QFI.

  6. The S-GW sends Modify Bearer Request to the SMF with DL TEIDs on the SMF for the bearers.

  7. The SMF sends N4 Modification Request to the UPF to activate the DL data path to E-UTRAN. At this time, both the indirect tunnel and the direct DL path are activated towards the eNodeB.

  8. The SMF sends the Modify Bearer Response to S-GW.

  9. The AMF initiates Nsmf_PDUSession_UpdateSMContext Request service operation with an indication to release the forwarding tunnels.

  10. The SMF sends N4 Modification Request to the UPF to remove the PDRs and FARs for the indirect tunnels. The PDRs and FARs for the 5G session which are not required are also removed.

5G to EPS Handover Cancellation Call Flow

When the Source Radio Access Network (RAN) triggers a handover cancellation after the preparation phase, the AMF invokes the "Nsmf_PDUSession_UpdateSMContext request (SUPI, Relocation Cancel Indication) toward the SMF. Based on the Relocation Cancel Indication, the SMF deletes the session resources established during the handover preparation phase. That is, the SMF removes all the Packet Detection Rules (PDRs), Forwarding Action Rules (FARs), and other rules that were allocated in preparation of handoff for indirect tunnel and the 5G session.

The following call flow depicts the 5GS to EPS handover cancellation procedure.

Figure 27. 5GS to EPS Handover Cancellation Call Flow
Table 18. 5GS to EPS Handover Cancellation Call Flow Description

Step

Description

1

The AMF requests the SMF to cancel the handover of an existing PDU session by sending a POST request for Sm Context Update service, with the following information:

  • updating the hoState attribute of the individual SM Context resource in the SMF to CANCELLED

  • cause information

2

The SMF returns a 200 OK response message including the following information:

  • hoState attribute set to CANCELLED

The SMF cancels the execution of the handover, for example, releases the resources reserved for the handover to the target RAN. Then, the SMF sets the hoState to NONE and deletes any stored targetServingNfId.

Standards Compliance

The 5G to EPS Handover feature complies with the 3GPP TS 23.502, version 15.3.0.

Create Dedicated Bearer Delay and Retry Support

Feature Description

The Create Dedicated Bearer Delay and Retry Support feature facilitates the following:

  • Delays the creation of the dedicated bearer that is based on the configured time after handover is complete.

  • Retries the creation of the dedicated bearer for the IMS bearer in either of the following scenarios:

    • When the MME fails with the handover in progress.

    • When the IMS bearer is temporarily unreachable.

  • After the handover is complete, the SMF service starts with the configured timer. Then, the dedicated bearer creation begins.

  • If the IMS dedicated bearer creation fails, the maximum retries configuration determines the number of retries the creation process attempts. The configured timeout determines the delay of each retry attempt.

How It Works

This section provides a brief of how the Create Dedicated Bearer Delay and Retry Support feature works.

Call Flows

This section includes the following call flow.

Figure 28. EPS Fallback Guard Timer Call Flow


Table 19. EPS Fallback Guard Timer Call Flow Description
Step Description
1 gNB sends the dedicated bearer creation failure information with the fallback cause through AMF.
2 EPS fallback timer starts.
With the successful EPS fallback following the 5G to 4G handover, steps 3 to12 occur.
3 EPS triggers pending dedicated bearer creation.
4 Delay timer starts.
5 SMF (+S5-C) sends the PFCP session modification request to UPF (+S5-U).
6 PDR and FAR are created.
7 UPF (+S5-U) sends the PFCP session modification response to SMF (+S5-C).
8 The information on the created PDR with the GTP-U TEID is available.
9 SMF (+S5-C) sends the Create Bearer Request to S-GW.
10 S-GW sends the Create Bearer Response to SMF (+S5-C).
11 SMF (+S5-C) sends the PFCP Session Modification Request to UPF (+S5-U).
12 UPF (+S5-U) sends the notification of the successful dedicated bearer creation to PCF.
13 EPS Fallback Guard Timer stops.
14 PCF sends the “200 OK” acknowledgment to SMF (+S5-C).
In the EPS fallback timer expiry before handover completion scenario, steps 13 to15 occur.
15 SMF (+S5-C) sends the failure notification of the dedicated bearer creation to PCF.
16 PCF sends the “200 OK” acknowledgment to SMF (+S5-C).
17 The 5G to 4G handover procedure continues.

Configuring Create Dedicated Bearer Delay and Retry Support

This section describes how to configure the Create Dedicated Bearer Delay and Retry Support feature.

configure 
   profile access accesstemp 
     eps-fallback cbr delay delay_time max-retry retry_count  
     timeout timeout_value 
     end

NOTES:

  • delay delay_time : Specifies the time delay in milliseconds for the creation of the dedicated bearer. The valid values range 0 through10000 milliseconds. The default is 0.

  • max-retry retry_count : Specifies the number of times to retry the creation of the dedicated bearer. The valid values range from 0 through 10. The default is 0.

  • timeout timeout_value : Specifies the time gap in seconds before retrying the creation of the dedicated bearer. The valid values range from 1 through 3 seconds. The default is 1.

Verifying the Create Dedicated Bearer Delay and Retry Support Configuration

This section describes how to verify the Create Dedicated Bearer Delay and Retry Support configuration.

Use the show running-config command to view the configuration.

The following is a sample output of the show running-config command. 

profile smf smf1
service name smf-service
  access-profile access1
!
!
profile access access1
eps-fallback cbr delay 100 max-retry 5 timeout 2

Handling GTP-U Error Indication for 4G Sessions

Feature Description

This section describes how the SMF handles GPRS tunneling protocol, user plane (GTP-U) error indication for the 4G sessions.

Serving Gateway (S-GW) sends GTP-U error indication message including the tunnel IDs to UPF when it receives a GTP-U message with an unknown Tunnel Endpoint Identifier (TEID). The UPF on receiving GTP-U error indication sends N4SessionReportRequest towards SMF including error indication (ERIR). The SMF retrieves EBI based on Fteid included in the N4SessionReportRequest, and initiates deletion of the session or bearer. The SMF sends Delete Bearer Request towards S-GW. On receiving the response from S-GW, the SMF sends either an N4 session modification request or N4 session release request to the UPF based on the bearer type, that is, dedicated or default bearer. CHF and PCF are also notified based on the bearer type.


Note

When the SMF receives PFCPSessionReportRequest, the IntSelfTxnN4SessRptReq message is displayed as part of the debug message.

Standards Compliance

The GTP-U Error Indication Handling feature complies with the following standards:

  • 3GPP TS 29.244, Version 15.6.0

  • 3GPP TS 23.527, Version 15.3.0

How it Works

GTP-U Error Handling Procedure

This section describes the call flow associated with the GTP-U error handling procedure for the 4G sessions.

Figure 29. GTP-U Error Indication Handling Call Flow
Table 20. GTP-U Error Handling Call Flow Description
Step Description

1

S-GW sends GTP-U Error Indication towards UPF, indicating the bearer with the failed bearer ID.

2

After receiving GTP-U error indication, the UPF sends PFCPSessionReport towards SMF along with the failed bearer ID.

3a and 3b

The SMF sends PFCPSessionReport Success message and N4 Session Modification Request for dropped packet towards the UPF.

4

The UPF sends N4 Session Modification Response to the SMF.

5

The SMF sends Delete Bearer Request towards S-GW along with TEID, EBI, and cause.

6

The S-GW sends Delete Bearer Response towards SMF along with TEID, EBI, and cause as request accepted.

7a

If the TEID is a dedicated bearer, then the SMF sends N4 Session Modification Request with Delete PDR.

7b

The UPF sends N4 Session Modification Response.

8a

If it is a default bearer, the SMF sends N4 Session Release Request.

8b

The UPF sends N4 Session Release Response.

9a

The SMF sends Charging Data Terminate Request towards CHF.

9b

The CHF responds with Charging Data Terminate Response.

10a

The SMF sends SMPolicyControl Update Request towards PCF.

10b

The PCF sends SMPolicyControl Update Response to the SMF.

GTP Path Failure Handling, Restoration, and Recovery

Feature Description

SMF now supports:

  • Handling of the following GTP-C path management messages as per 3GPP TS 29.274

    • Echo Request

    • Echo Response

  • Sending Echo Request message to the newly discovered GTP-C peer as per the configuration.

  • Sending Echo Response message as a reply if it receives Echo Request message from GTP-C peer.

  • Retransmitting Echo Request message to GTP-C peer for configured number of times if no response is received.

  • Clearing all the subscribers associated to a GTP-C peer if no response is received for Echo Request message for configured number of times for that GTP-C peer.

  • Clearing all the subscribers associated to a GTP-C peer if a different recovery value is received from that GTP-C peer.

The feature complies with the following standards:

  • 3GPP TS 29.274

  • 3GPP TS 23.007

Call Flows

The following call flows captures information specific to how GTP-C path management and GTP-C restoration messages are handled.

GTP-C Path Management

Figure 30. GTP-C Path Management
Table 21. GTP-C Path Management

Step

Description

1

Once the GTP-C peer is discovered (an Initial GTP-C Create Session Request or an GTP-C Modify Bearer Request message is received), CN SMF/PGW-C starts sending GTP-C Echo Request Messages periodically to the new GTP-C Peer as per configuration.

2

If GTP-C Echo response is not received, CN SMF/PGW-C retries sending GTP-C Echo Request (configured) N3 times for every configured T3 timer expiry.

3

Once all retries are exhausted, CN SMF/PGW-C clears all the sessions associated to that GTP-C peer.

GTP-C Echo Request Handling

Figure 31. GTP-C Echo Request Handling
Table 22. GTP-C Echo Request Handling

Step

Description

1

Whenever a GTP-C Echo Request message is received from a GTP-C peer, CN SMF/PGW-C sends GTP-C Echo Response message as a reply.

GTP-C Restoration on PGW-C/SMF

PGW-C/SMF can detect that there is a change in recovery value of SGW. PGW-C/SMF can detect this value from the following messages:

  • Create Session Request

  • Modify Bearer Request

  • Create Bearer Response

  • Echo Response

If PGW-C/SMF detects that there is a change in recovery value, then it initiates the cleanup of all the PDN connections associated with the SGW.

Figure 32. GTP Restoration due to SGW Restart

Memory and Performance Impact

The Node Manager pod to GTP-C peer path mapping is maintained in etcd and also in the local cache of NodeMgr and GTP-C Pods.

Configuring Echo at GTP Endpoint

Use the following sample configuration to configure the echo parameters at GTP endpoint.

config 

   endpoint gtp 
      interface { s2b | s5 | s5e | s8 | s11 } 
         echo interval echo_interval 
         echo retransmission-timeout retransmission_timeout_value 
         echo max-retransmissions max_retry_count

Sample Configuration

[unknown] smf# config
Entering configuration mode terminal

[unknown] smf(config)# endpoint gtp
[unknown] smf(config-endpoint-gtp)#
[unknown] smf(config-endpoint-gtp)# interface
s2b s5 s5e s8 s11 
[unknown] smf(config-endpoint-gtp)# interface s5
[unknown] smf(config-interface-s5)# echo interval 60
echo – Enable gtpc path management
interval - Configure echo interval in seconds, ranging from <60-360>
[unknown] smf(config-interface-s5)# echo retransmission-timeout 3
retransmission-timeout - Configure the echo retransmission timeout in seconds, ranging from <1–20>
[unknown] smf(config-interface-s5)# echo max-retransmissions 10
max-retransmissions  - Configure maximum retries for GTP echo request, ranging from <0-10>
[unknown] smf(config-interface-s5)#

Show Command

The show peers command displays all the connected GTP peers and their node information.

Example:

Bulk Statistics

The following dedicated disconnect reasons are used for PDN connections cleared due to peer GTP-C restart or path failure.

  • disc_pdnrel_gtpc_peer_restart

  • disc_pdnrel_gtpc_peer_pathfail

The following bulk statistics are added in nodemgr pod.
# HELP nodemgr_gtpc_msg_stats Gtpc Msg Stats
# TYPE nodemgr_gtpc_msg_stats counter
nodemgr_gtpc_msg_stats{app_name="SMF",cluster="Local",data_center="DC",
gtpc_msg_type="gtpc_echo_req_rx",gtpc_peer_ip="10.105.35.209",instance_id="0",service_name="nodemgr"} 1
nodemgr_gtpc_msg_stats{app_name="SMF",cluster="Local",data_center="DC",
gtpc_msg_type="gtpc_echo_req_tx",gtpc_peer_ip="10.105.35.209",instance_id="0",service_name="nodemgr"} 4
nodemgr_gtpc_msg_stats{app_name="SMF",cluster="Local",data_center="DC",
gtpc_msg_type="gtpc_echo_res_rx",gtpc_peer_ip="10.105.35.209",instance_id="0",service_name="nodemgr"} 1
nodemgr_gtpc_msg_stats{app_name="SMF",cluster="Local",data_center="DC",
gtpc_msg_type="gtpc_echo_res_tx",gtpc_peer_ip="10.105.35.209",instance_id="0",service_name="nodemgr"} 1
# HELP nodemgr_gtpc_peer_status Gtpc Peer Status
# TYPE nodemgr_gtpc_peer_status counter
nodemgr_gtpc_peer_status{app_name="SMF",cluster="Local",data_center="DC",
gtpc_peer_ip="10.105.35.209",gtpc_peer_status="gtpc_peer_path_down",instance_id="0",service_name="nodemgr"} 1
nodemgr_gtpc_peer_status{app_name="SMF",cluster="Local",data_center="DC",
gtpc_peer_ip="10.105.35.209",gtpc_peer_status="gtpc_peer_path_up",instance_id="0",service_name="nodemgr"} 1
nodemgr_gtpc_peer_status{app_name="SMF",cluster="Local",data_center="DC",
gtpc_peer_ip="10.105.35.209",gtpc_peer_status="gtpc_peer_restarted",instance_id="0",service_name="nodemgr"} 1

Limitations

From 3GPP TS 23.007, Section 20: It is recommended that GTPv2 Echo Request should be sent only when a GTP-C entity has not received any GTP response message for a previously sent request message on the GTP-C path for, an implementation dependent time period.

Currently, this is not supported.

Even if SMF receives GTPC echo req from peer, it is considered as path is up. The subsequent Echo Req from SMF is received after the echo interval expiry.

Configuration Support for Rejecting 4G-only Devices

The SMF provides configuration support to reject calls from 4G-only UE devices.

To reject calls from 4G-only UE devices, use the following configuration:

configure 
   profile dnn dnnprofile_name 
      only-nr-capable-ue true 
      end

NOTES:

  • only-nr-capable-ue true : Enable this command to reject any new call attempt for PDN session creation from a 4G only capable UE device.

Dynamic Configuration Change Support

Feature Description

The SMF allows you to change Access Profile configuration dynamically, without any impact on the existing sessions. For instance, when the configuration dynamically updates the current session continues to use the old values in the in-progress call flow or procedure.

How it Works

This section describes how dynamic change in configuration works for the supported Access Profile configurations.

Access Profile

The Access Profile defines the various parameters for the access-profile configuration.

The following table lists the configurations that allow dynamic update.

Table 23. Access Profile Parameters

Configuration Parameters

Configuration

Dynamic Change

Impact on Existing Sessions

eps-fallback cbr

 
eps-fallback cbr delay 
delay max-retry retry_count 
timeout timeout

Allowed

Sessions that use the old value in a call flow and procedure continues to use the old value.

n1 t3591-pdu-mod-cmd 

n1 t3591-pdu-mod-cmd timeout 
timeout max-retry 
retry_count

Allowed

Sessions that use the old value in a call flow and procedure continues to use the old value.

n1 t3592-pdu-rel-cmd 

n1 t3592-pdu-rel-cmd timeout 
timeout max-retry 
retry_count

Allowed

Sessions that use the old value in a call flow and procedure continues to use the old value.

Note 

The SMF does not support the timer functionality associated to this configuration.

n2 idft enable 

n2 idft enable timeout 
timeout

Allowed

Sessions that use the old value in a call flow and procedure continues to use the old value.

n26 idft enable 

n26 idft enable timeout 
timeout

Allowed

Sessions that use the old value in a call flow and procedure continues to use the old value.

n11 n11-failure-profile

 
n11 n11-failure-profile  
failure_profile

Allowed

Sessions that use the old value in a call flow and procedure continues to use the old value.

If the associated Failure-Handling Profile gets deleted or any of the parameters are modified, then the existing call flows are not impacted, which means that the existing call flows continue using the old value.

gtpc gtpc-failure-profile 

gtpc gtpc-failure-profile 
failure_profile

Allowed

Sessions that use the old value in a call flow and procedure continues to use the old value.

If the associated Failure-Handling Profile gets deleted or any of the parameters are modified, then the existing call flows are not impacted, which means that the existing call flows continue using the old value.