IDFT Support

Feature Summary and Revision History

Summary Data

Table 1. Summary Data

Applicable Product(s) or Functional Area

cnSGW-C

Applicable Platform(s)

SMI

Feature Default Setting

Enabled - Always-on

Related Documentation

Not Applicable

Revision History

Table 2. Revision History

Revision Details

Release

First introduced.

2021.02.0

Feature Description

cnSGW-C supports Indirect Forwarding Tunnel (IDFT) Creation and Deletion for Pure-S call with dedicated bearers, with and without SGW relocation.

Standards Compliance

This feature complies with the following standards specifications:

  • 3GPP TS 23.401 "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access"

  • 3GPP TS 23.402 "Architecture enhancements for non-3GPP accesses"

  • 3GPP TS 29.274 "Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C)"

  • 3GPP TS 23.214 "Architecture enhancements for control and user plane separation of EPC nodes"

  • 3GPP TS 29.244 "Interface between the Control Plane and the User Plane nodes"

  • 3GPP TS 24.008 "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3"

How it Works

This section describes how this feature works.

Call Flows

This section describes the key call flows for this feature.

IDFT Support without SGW Relocation Call Flow

This section describes the IDFT Support without SGW Relocation call flow.

Figure 1. IDFT Support without SGW Relocation Call Flow
Table 3. IDFT Support without SGW Relocation Call Flow Description

Step

Description

1

Call is connected with the Source eNodeB and there’s a decision to trigger relocation via S1.

The MME sends the Create IDFT Request to the SGW-C.

2

The MME receives the Create IDFT Response from the SGW-C.

3

The indirect forwarding of the data starts from the Source eNodeB to the SGW-C.

The indirect forwarding of the data starts from the SGW-C to the eNodeB.

The Target eNodeB sends the Downlink Data to the UE.

The Target eNodeB sends the Uplink Data to the UP.

The MME sends the Modify Bearer Request to the SGW-C.

4

The SGW-C sends the Modify Bearer Response to the MME.

The UP sends the End Marker to the Source eNodeB, and the Source eNodeB forwards the End Marker to the UP.

The UP sends the Downlink Data and the End Marker to the Target eNodeB.

5

The MME sends the Delete IDFT Request to the SGW-C.

6

The MME receives the Delete IDFT Response from the SGW-C.

IDFT Support with SGW Relocation Call Flow

This section describes the IDFT Support with SGW Relocation call flow.

Figure 2. IDFT Support with SGW Relocation Call Flow
Table 4. IDFT Support with SGW Relocation Call Flow Description

Step

Description

1

Call is connected with the Source eNodeB and there's a decision to trigger relocation via S1.

The MME sends the Create Session Request to the Target SGW-C.

2

The MME receives the Create Session Response from the Target SGW-C.

3

The MME sends the Create IDFT Request to the Target SGW-C.

4

The MME receives the Create IDFT Response from the Target SGW-C.

5

The MME sends the Create IDFT Request to the Source SGW-C.

6

The MME receives the Create IDFT Response from the Source SGW-C.

The indirect forwarding of the data starts from the Source eNodeB to the Source SGW-C.

The indirect forwarding of the data starts from the Source SGW-C to the Target SGW-C.

The indirect forwarding of the data starts from the Target SGW-C to the Target eNodeB.

The Target eNodeB sends the Downlink Data to the UE.

The Target eNodeB sends the Uplink Data to the Target UP.

7

The MME sends the Modify Bearer Request to the Target SGW-C.

8

The Source SGW-C sends the Modify Bearer Response to the MME.

The Target UP sends the End Marker to the Source eNodeB, and the Source eNodeB forwards the End Marker to the Target UP.

The Target UP sends the Downlink Data and the End Marker to the Target eNodeB.

9

The MME sends the Delete Session Request to the Source SGW-C.

10

The MME receives the Delete Session Response from the Source SGW-C.

11

The MME sends the Delete IDFT Request to the Source SGW-C.

12

The MME receives the Delete IDFT Response from the Target SGW-C.

13

The MME sends the Delete IDFT Request to the Target SGW-C.

14

The MME receives the Delete IDFT Response from the Target SGW-C.

5G to 4G Handover Flow for Pure-S Call Flow

This section describes the 5G to 4G Handover flow for Pure-S call flow.

Figure 3. 5G to 4G Handover Flow for Pure-S Call Flow
Table 5. 5G to 4G Handover Flow for Pure-S Call Flow Description

Step

Description

1

5G call is established.

The NG-RAN sends the Handover Required message to the AMF.

2

The AMF sends the Relocation Request to the MME.

3

The MME sends the Create Session Request to the Target SGW-C.

4

The MME receives the Create Session Response from the Target SGW-C.

5

The MME sends the Handover Request to the E-UTRAN.

6

The MME receives the Handover Request ACK from the E-UTRAN.

7

The MME sends the Create IDFT Request with the Bearer Context with the eNodeB DL and UL FWD FTEID, to the Target SGW-C.

8

The Target SGW-C sends the Sx Modification Request with the Create PDRs and FARs to the Target SGW-U.

9

The Target SGW-U sends the Sx Modification Response with the Create PDRs and FARs to the Target SGW-C.

10

The Target SGW-C sends the Create IDFT Response with the Bearer Context with the SGW DL and UL FWD TEID, to the MME.

11

The MME sends Create IDFT Request with the Bearer Context, along with SGW DL and UL FWD FTEID, to the Source SGW-C.

12

The Source SGW-C sends the Sx Modification Request with Create PDRs and FARs, to the Source SGW-U.

13

The Source SGW-C receives the Sx Modification Response with Create PDRs and FARs, from the Source SGW-U.

14

The MME receives the Create IDFT Response with the Bearer Context, with the SGW DL and UL FWD TEID, from the Source SGW-C.

15

The MME sends the Relocation Response to the AMF.

The PDN sends the Downlink Data to the Source SGW-U, and the Source SGW-U sends the Downlink Data to the Source eNodeB.

The indirect forwarding data (IDFT Tunnel) starts from the Source eNodeB to the Target SGW-U, and from the Target SGW-U to the Target eNodeB.

The Target eNodeB sends the Downlink Data to the UE.

The UE sends the Uplink Data to the Source eNodeB, and the Source eNodeB sends the Uplink Data to the Source SGW-U.

The PDN sends the indirect forwarding data to the Target SGW-U, and the Target SGW-U sends the indirect forwarding data to the Target eNodeB.

16

The MME sends the Modify Bearer Request to the Target SGW-C.

17

 The MME receives the Modify Bearer Response from the Target SGW-C.

18

The MME sends the Delete IDFT Request to the Target SGW-C.

19

The Target SGW-C sends the Sx Modification Request with PDRs and FARs (to remove), to the Target SGW-U.

20

The Target SGW-C receives the Sx Modification Response from the Target SGW-U.

21

The MME receives the Delete IDFT Response from the Target SGW-C.

4G to 5G Handover Flow for Pure-S Call Flow

This section describes the 4G to 5G Handover flow for Pure-S call flow.

Figure 4. 4G to 5G Handover Flow for Pure-S Call Flow
Table 6. 4G to 5G Handover Flow for Pure-S Call Flow Description

Step

Description

1

4G call is established.

The E-UTRAN sends the Handover Required message to the MME.

2

The MME sends the Forward Relocation Request to the AMF.

3

The AMF sends the Handover Request message to the NG-RAN.

4

The AMF receives Handover Request ACK message.

5

The MME receives the Forward Relocation Response from the AMF.

6

The MME sends the Create IDFT Request with the Bearer Context with the eNodeB DL and UL FWD FTEID, to the Target SGW-C.

7

The Target SGW-C sends the Sx Modification Request with Create PDRs and FARs to the Target SGW-U.

8

The Target SGW-U sends the Sx Modification Response with Create PDRs and FARs to the Target SGW-C.

9

The Target SGW-C sends the Create IDFT Request with the Bearer Context along with eNodeB DL and UL FWD FTEID to the MME.

10

The MME sends the Create IDFT Request with the Bearer Context along with target SGW DL and UL FWD FTEID to the Source SGW-C.

11

The Source SGW-C sends the Sx Modification Request with Create PDRs and FARs to the Source SGW-U.

12

The Source SGW-C receives the Sx Modification Response with Create PDRs and FARs from the Source SGW-U.

13

The MME receives the Create IDFT Response with the Bearer Context along with SGW DL and UL FWD FTEID, from the Source SGW-C.

The PDN sends the Downlink Data to the Source SGW-U, and the Source SGW-U sends the Downlink Data to the Source eNodeB.

The indirect forwarding data (IDFT Tunnel) starts from the Source eNodeB to the Target SGW-U, and from the Target SGW-U to the Target eNodeB.

The Target eNodeB sends the Downlink Data to the UE.

The UE sends Uplink Data to the Source eNodeB, and the Source eNodeB sends the Uplink Data to the Source SGW-U.

The Source SGW-U sends the indirect forwarding data to the Target SGW-U, and the Target SGW-U sends the indirect forwarding data to the Target eNodeB.

14

The MME sends the Modify Bearer Request to the Target SGW-C.

15

The MME receives the Modify Bearer Response from the Target SGW-C.

16

The MME sends the Delete IDFT Request to the Target SGW-C.

17

The Target SGW-C sends the Sx Modification Request to the Target SGW-U, to remove the PDRs and FARs.

18

The Target SGW-C receives the Sx Modification Response from the Target SGW-U.

19

The MME receives the Delete IDFT Response from the Target SGW-C.

Create IDFT (System-level) Call Flow

This section describes the Create IDFT (System-level) call flow.

Figure 5. Create IDFT (System-level) Call Flow
Table 7. Create IDFT (System-level) Call Flow Description

Step

Description

1

Call is connected with the Source eNodeB.

The MME sends the S11 Create IDFT Request with the Bearer Context with a DL/UL enB FTEID, to the GTP-EP S11.

2

The GTP-EP S11 sends the S11 Create IDFT Request with the Bearer Context with a DL/UL enB FTEID, to the SGW-SVC.

The SGW-SVC receives the S11 Create IDFT Request and performs the following:

  • Creates a new transaction

  • Completes GTP validations

3

The SGW-SVC sends the Sx Modification Request with Create PDRs, Create FARs, and Create Traffic Endpoints, to the PFCP-EP.

4

The PFCP-EP sends the Sx Modification Request with Create PDRs, Create FARs, and Create Traffic Endpoints, to the UP.

5

The UPF sends the Sx Session Modification Response with Created Traffic endpoints, to the PFCP-EP.

6

The SGW-SVC receives the Sx Session Modification Response from the PFCP-EP and performs the following:

  • Ends the transaction/procedure

  • Updates the CDL

  • Sends the Create IDFT Response with cause as Accepted

Delete IDFT (System-level) Call Flow

This section describes the Delete IDFT (system-level) call flow.

Figure 6. Delete IDFT (System-level) Call Flow
Table 8. Delete IDFT (System Level Flow) Call Flow Description

Step

Description

1

Call is connected with the Source eNodeB and indirect forwarding tunnels are created.

MME sends the S11 Delete IDFT Request with Bearer Context with a DL/UL enB FTEID, to the GTP-EP S11.

2

The GTP-EP S11 forwards the S11 Delete IDFT Request with Bearer Context with a DL/UL enB FTEID, to the SGW-SVC.

The SGW-SVC receives the S11 Delete IDFT Request and performs the following:

  • Creates a new transaction

  • Completes the GTP validations

3

The SGW-SVC sends the Sx Modification Request with Remove Traffic Endpoints, to the PFCP-EP.

4

The PFCP-EP sends the Sx Modification Request with Remove Traffic Endpoints, to the UP.

5

The UP sends the Sx Session Modification Response to the PFCP-EP.

6

The SGW-SVC receives the Sx Session Modification Response from the PFCP-EP and performs the following:

  • Ends the transaction/procedure

  • Updates the CDL

  • Sends the Delete IDFT Response with cause as Accepted

OAM Support

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

Viewing IDFT Configuration

This section describes the command to view IDFT configurations.

Non- active IDFT for the UE

Command: show subscriber namespace sgw imsi 123456789012345

Output:

{ "subResponses": [ { "status": true,
…
…
"pdnInfoList": { "totalPdn": 1,
"bearerInfoList": {
"totalBearer": 1, "bearerInfo": [ { "bearerId": "Bearer-1", "state": "Connected",
…
…
} }
]
}

Active IDFT for the UE with one PDN having one bearer

Command: show subscriber namespace sgw imsi 123456789012345

Output:

{ "subResponses": [ { "status": true,
…
…
"pdnInfoList": { "totalPdn": 1,
"bearerInfoList": {
"totalBearer": 1, "bearerInfo": [ { "bearerId": "Bearer-1", "state": "Connected",
…
…
"IndirectForwardingInfo": {
“UplinkInfo”:{
"localTeid": "[0x1100000e] 285212686", "localIPv4Address": "209.165.201.8", "remoteTeid": "[0x1100000f] 285212687", "remoteIPv4Address": "209.165.201.8",
}
“DownlinkInfo”:{
"localTeid": "[0x1100000e] 285212686", "localIPv4Address": "209.165.201.8", "remoteTeid": "[0x1100000f] 285212687", "remoteIPv4Address": "209.165.201.8",
}
}
}
]
}

Active IDFT for the UE with one PDN having one bearer in downlink direction

Command: show subscriber namespace sgw imsi 123456789012345

Output:

{ "subResponses": [ { "status": true,
…
…
"pdnInfoList": { "totalPdn": 1,
"bearerInfoList": {
"totalBearer": 1, "bearerInfo": [ { "bearerId": "Bearer-1", "state": "Connected",
…
…
"IndirectForwardingInfo": {
“DownlinkInfo”:{
"localTeid": "[0x1100000e] 285212686",
"localIPv4Address": "209.165.201.8",
"remoteTeid": "[0x1100000f] 285212687",
"remoteIPv4Address": "209.165.201.8",
}
}
}
]
}

Active IDFT for one bearer for the UE with one PDN having two bearers

Command: show subscriber namespace sgw imsi 123456789012345

Output:

"subResponses": [ { "status": true,
…
…
"pdnInfoList": { "totalPdn": 1,
"bearerInfoList": {
"totalBearer": 2, "bearerInfo": [ { "bearerId": "Bearer-1", "state": "Connected",
…
…
"IndirectForwardingInfo": {
“UplinkInfo”:{
"localTeid": "[0x1100000e] 285212686", "localIPv4Address": "209.165.201.8", "remoteTeid": "[0x1100000f] 285212687", "remoteIPv4Address": "209.165.201.8",
}
“DownlinkInfo”:{
"localTeid": "[0x1100000e] 285212686", "localIPv4Address": "209.165.201.8", "remoteTeid": "[0x1100000f] 285212687", "remoteIPv4Address": "209.165.201.8",
}
}
"bearerInfo": [ { "bearerId": "Bearer-2", "state": "Connected",
…
}
}
]
}

Note

The displayed IndirectForwardingInfo block is only for bearers having indirect forwarding tunnels.

Failure Handling

cnSGW-C supports failure handling for creating or deleting IDFT request procedure.

Following are the failure types that can occur during message processing:

  • Advance validation failure on request and response

  • Retransmissions timeout

  • Transaction SLA

  • Failure reported from peer (UP/PGW/MME), depending on the stage of message processing.

The following table depicts the behavior of cnSGW-C during different failure scenarios in call processing.

Failure Scenario

SGW-SVC behavior

Signaling (S11)

  1. Create IDFT Request advance validation failure.

  2. cnSGW doesn’t have a bearer context for any of the EBIs received in Create IDFT.

Sends failure or No signaling over Sx.

Negative Create IDFT response.
Single PDN

  1. Sx Session Modify Request (for example, IPC, Retransmission, Internal Failure) with single PDN

  2. Sx Session Modify Response (Cause!= ACCEPTED) with single PDN

  3. Sx Modification Response validation failure

Sends failure.

Sends Context not found of nonexisting EBI.

Clear the PDN if sxCause = Context Not Found.

Negative Create IDFT response.

DBR and DSR over S11 and S5 when sxCause = Context Not Found.
Multi PDN (Partial Failure)

  1. Partial Existing PDN: Continue with existing PDN

  2. Sx Session Modify Request (for example, IPC, Retransmission Timeout, Internal Failure) for some PDNs

  3. Sx Session Modify Response (Cause!= ACCEPTED) for some PDN

  4. Sx Modification Response validation failure

Send Context Not Found for nonexisting PDNs.

Send failure in Bearer Context for PDNs for which Sx Modification Request fails.

Partially Accepted Create IDFT Response.

DBR and DSR over S11 and S5 for the PDN for which sxCause = Context Not Found.
Multi PDN (Complete Failure):

  1. Partial Existing PDN: Continue with existing PDN.

  2. Sx Session Modify Request (for example, IPC, Retransmission Timeout, Internal Failure)

  3. Sx Session Modify Response (Cause!= ACCEPTED)

  4. Sx Modification Response validation failure

Send Context Not Found for nonexisting PDNs.

Send failure in Bearer Context for PDNs which has Sx Modification Request fails.

Negative Create IDFT Response.

DBR and DSR over S11 and S5 for the PDN for which sxCause = Context Not Found.

Delete IDFT Request Advance validation failure.

Send failure or No signaling over Sx.

Negative Delete IDFT response.

  1. Single and Multi-PDN

  2. Sx Session Modify Request (for example, IPC, Retransmission Timeout, Internal Failure)

  3. Sx Session Modify Response (Cause!= ACCEPTED)

Ignore Failure.

Positive Delete IDFT Response.

DBR and DSR over S11 and S5 for the PDN for which sxCause = Context Not Found.

Bulk Statistics Support

The following statistics are supported for the IDFT Support feature.

sgw_service_stats{app_name="smf",cluster="cn",data_center="cn",fail_reason="",
instance_id="0",interface="interface_sgw_ingress",reject_cause="",service_name="sgw-service",
sgw_procedure_type="create_indirect_data_forwarding_tunnel",status="attempted",sub_fail_reason=""} 3
sgw_service_stats{app_name="smf",cluster="cn",data_center="cn",fail_reason="",instance_id="0",
interface="interface_sgw_ingress",reject_cause="",service_name="sgw-service",sgw_procedure_type=
"create_indirect_data_forwarding_tunnel",status="success",sub_fail_reason=""} 2
sgw_service_stats{app_name="smf",cluster="cn",data_center="cn",fail_reason="",instance_id="0",
interface="interface_sgw_ingress",reject_cause="",service_name="sgw-service",sgw_procedure_type=
"delete_indirect_data_forwarding_tunnel",status="attempted",sub_fail_reason=""} 1
sgw_service_stats{app_name="smf",cluster="cn",data_center="cn",fail_reason="",
instance_id="0",interface="interface_sgw_ingress",reject_cause="",service_name="sgw-service",
sgw_procedure_type="delete_indirect_data_forwarding_tunnel",status="success",sub_fail_reason=""} 1
sgw_service_stats{app_name="smf",cluster="cn",data_center="cn",fail_reason="",instance_id="0",
interface="interface_sgw_ingress",reject_cause="",service_name="sgw-service",sgw_procedure_type=
"indirect_data_forwarding_tunnel_guard_timer_expiry",status="attempted",sub_fail_reason=""} 1
sgw_service_stats{app_name="smf",cluster="cn",data_center="cn",fail_reason="",instance_id="0",
interface="interface_sgw_ingress",reject_cause="",service_name="sgw-service",sgw_procedure_type=
"indirect_data_forwarding_tunnel_guard_timer_expiry",status="success",sub_fail_reason=""} 1