Direct Tunnel for 4G (LTE) Networks

This chapter briefly describes support for direct tunnel (DT) functionality over an S12 interface for a 4G (LTE) network to optimize packet data traffic.

Cisco LTE devices (per 3GPP TS 23.401 v8.3.0) supporting direct tunnel include:

  • Serving GPRS Support Node (S4-SGSN)

  • Serving Gateway (S-GW)

  • PDN Gateway (P-GW)


Important

Direct Tunnel is a licensed Cisco feature. A separate feature license is required for configuration. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.

The following sections are included in this chapter:

Direct Tunnel for 4G Networks - Feature Description

The amount of user plane data will increase significantly during the next few years because of High Speed Packet Access (HSPA) and IP Multimedia Subsystem technologies. Direct tunneling of user plane data between the RNC and the S-GW can be employed to scale UMTS system architecture to support higher traffic rates.

Direct Tunnel (DT) offers a solution that optimizes core architecture without impact to UEs and can be deployed independently of the LTE/SAE architecture.


Important

Direct tunnel is a licensed Cisco feature. A separate feature license is required for configuration. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.


Important

Establishment of a direct tunnel is controlled by the SGSN; for 4G networks this requires an S4 license-enabled SGSN setup and configured as an S4-SGSN.

Once a direct tunnel is established, the S4-SGSN/S-GW continues to handle the control plane (RANAP/GTP-C) signaling and retains the responsibility of making the decision to establish direct tunnel at PDP context activation.

Figure 1. GTP-U Direct Tunneling


A direct tunnel improves the user experience (for example, expedites web page delivery, reduces round trip delay for conversational services) by eliminating switching latency from the user plane. An additional advantage, direct tunnel functionality implements optimization to improve the usage of user plane resources (and hardware) by removing the requirement from the S4-SGSN/S-GW to handle the user plane processing.

A direct tunnel is achieved upon PDP context activation when the S4-SGSN establishes a user plane tunnel (GTP-U tunnel) directly between the RNC and the S-GW over an S12 interface, using a Create Bearer Response or Modify Bearer Request towards the S-GW.

Figure 2. Direct Tunneling - LTE Network, S12 Interface


A major consequence of deploying a direct tunnel is that it produces a significant increase in control plane load on both the SGSN/S-GW and GGSN/P-GW components of the packet core. Hence, deployment requires highly scalable GGSNs/P-GWs since the volume and frequency of Update PDP Context messages to the GGSN/P-GW will increase substantially. The SGSN/S-GW platform capabilities ensure control plane capacity will not be a limiting factor with direct tunnel deployment.

S4-SGSN supports establishment of a GTP-U direct tunnel between an RNC and the S-GW under the scenarios listed below:
  • Primary PDP activation
  • Secondary PDP activation
  • Service Request Procedure
  • Intra SGSN Routing Area Update without S-GW change
  • Intra SGSN Routing Area Update with S-GW change
  • Intra SGSN SRNS relocation without S-GW change
  • Intra SGSN SRNS relocation with S-GW change
  • New SGSN SRNS relocation with S-GW change
  • New SGSN SRNS relocation without S-GW relocation
  • E-UTRAN-to-UTRAN Iu mode IRAT handover with application of S12U FTEID for Indirect Data Forwarding Tunnels as well
  • UTRAN-to-E-UTRAN Iu mode IRAT handover with application of S12U FTEID for Indirect Data Forwarding Tunnels as well
  • Network Initiated PDP Activation
Scenarios that vary at S4-SGSN when direct tunneling is enabled, as compared to DT on a 2G or 3G SGSN using the Gn interface, include:
  • RAB Release
  • Iu Release
  • Error Indication from RNC
  • Downlink Data Notification from S-GW
  • Downlink Data Error Indication from S-GW
  • MS Initiated PDP Modification
  • P-GW Initiated PDP Modification while the UE is IDLE
  • HLR/HSS Initiated PDP Modification
  • Session Recovery with Direct Tunnel

The above scenarios exhibit procedural differences in S4-SGSN when a direct tunnel is established.

How It Works

DT functionality enables direct user plane tunnel between RNC and SGW within the PS domain. With direct tunneling the S4-SGSN provides the RNC with the TEID and user plane address of the S-GW, and also provides the S-GW with the TEID and user plane address of the RNC.

The SGSN handles the control plane signaling and makes the decision when to establish the direct tunnel between RNC and S-GW, or use two tunnels for this purpose (based on configuration).

DT Establishment Logic

The following figure illustrates the logic used within the S4-SGSN/S-GW to determine if a direct tunnel will be setup.

Figure 3. Direct Tunneling - Establishment Logic


Establishment of Direct Tunnel

The S4-SGSN uses the S12 interface for DT.

Direct Tunnel Activation for Primary PDP Context

For the PDP Context Activation procedure this solution uses new information elements (IEs) for the GPRS Tunnelling Protocol v2 (GTPv2) as defined in TS 29.274. SGSN provides the user plane addresses for RNC and S-GW as S12U FTEIDs as illustrated in the figure below.

The sequence for establishing a direct tunnel between the RNC and S-GW during PDP activation is as follows:
  • SGSN sends a Create Session Request to the S-GW with the indication flag DTF (direct tunnel flag) bit set
  • In its Create Session Response, the S-GW sends the SGSN an S12U FTEID (Fully Qualified Tunnel Endpoint Identifier).
  • The SGSN forwards the S-GW S12U to the RNC during the RAB Assignment Request.
  • In its RAB Assignment Response, the RNC sends the SGSN its transport address and Tunnel Endpoint ID (TEID).
  • The SGSN forward the RNC S12 U FTEID o the S-GW via a Modify Bearer Request.
Figure 4. Primary PDP Activation with Direct Tunnel


Direct Tunnel Activation for UE Initiated Secondary PDP Context

The following is the general sequence for establishing a direct tunnel for a Secondary PDP Context Activation:
  • The SGSN sends a Bearer Resource Command to the S-GW with no flags set. (S-GW already knows Direct Tunnel is enabled for primary.)
  • The S-GW sends a Create Bearer Response that includes the S12U FTEID to the SGSN.
  • The SGSN forwards the S-GW S12U to RNC via a RAB Assignment Request.
  • In its RAB Assignment Response, the RNC sends its transport address and TEID to the SGSN.
  • The SGSN forwards the S12U TEID received from the RNC to the S-GW via a Create Bearer Response.
Figure 5. Secondary PDP Activation with Direct Tunnel


RAB Release with Direct Tunnel

If the SGSN receives a RAB Release Request from the RNC for bearer contexts activated with Direct Tunnel, it sends a Release Access Bearer Request to the S-GW.

Upon receiving the Release Access Bearer Request, the S-GW removes the S12 U RNC FTEID. If any downlink data appears, the S-GW sends a Downlink Data Notification because it does not have a user plane FTEID with which to forward data.

Bearers with a streaming or conversational class will not be included in the Release Access Bearer Request because these bearers should be deactivated. However, S4-SGSN currently does not support deactivation of streaming/conversational bearers upon RAB release.

Figure 6. RAB Release Procedure with Direct Tunnel



Important

Operators should not use conversational or streaming class bearers in S4-SGSN.

Iu Release with Direct Tunnel

If the SGSN receives an Iu Release and bearers are activated with direct tunneling, it sends a Release Access Bearer Request to the S-GW.

Bearers with a streaming or conversational class will not be included in the Release Access Bearer Request because these bearers should be deactivated. However, S4-SGSN currently does not support deactivation of streaming or conversational bearers upon Iu release.


Important

Operators should not use conversational or streaming class bearers in S4-SGSN.

Figure 7. Iu Release Procedure with Direct Tunnel


Service Request with Direct Tunnel

When a UE is Idle and wants to establish a data or signaling connection, it sends a Service Request for data. Alternatively a UE can also send a Service Request to the SGSN when it is paged by the SGSN.

Upon receiving a Service Request for data, the SGSN establishes RABs and sends a Modify Bearer Request to the S-GW with the 12U FTEID received from the RNC.

Figure 8. Service Request Procedure with Direct Tunnel


Downlink Data Notification with Direct Tunnel when UE in Connected State

When RABs are released (but UE retains an Iu connection with the SGSN), the SGSN notifies the S-GW to release the RNC side TEIDs via a Release Access Bearer Request.

If the S-GW receives any downlink GTPU data from the P-GW after receiving the Release Access Bearer Request, it knows neither the RNC TEID nor SGSN user plane TEID to which to forward the data. So it signals the SGSN to establish the RABs. This signaling message is a Downlink Data Notification message from the S-GW.

If the Downlink Data Notification is received from the S-GW, all of the missing RABs are established and a Modify Bearer Request is sent to the S-GW with the RNC S12U FTEID

Figure 9. Downlink Data Notification with Direct Tunnel


Downlink Data Notification with Direct Tunnel when UE in Idle State

When an Iu is released the UE goes IDLE. The SGSN informs the S-GW to release the RNC side TEIDs by sending a Release Access Bearer Request. After this point if the S-GW receives any downlink GTPU data from the P-GW, it knows neither the RNC TEID nor SGSN user plane TEID to which to forward the data.

If the S-GW receives any downlink GTPU data after receiving the Release Access Bearer Request, it knows neither the RNC TEID nor SGSN user plane TEID to which to forward the data. So it signals the SGSN to establish the RABs. This signaling message is a Downlink Data Notification from the S-GW. If a Downlink Data Notification is received from S-GW when the UE is idle, the SGSN pages the UE before establishing the RABs. The SGSN sends a Modify Bearer Request to the S-GW with the RNC S12U FTEID.

Figure 10. Downlink Data Notification when UE in Idle State


Intra SGSN Routing Area Update without SGW Change

For a Routing Area Update without an S-GW change with Direct Tunnel, the SGSN sends a Modify Bearer Request to the S-GW with the RNC FTEID. The SGSN will establish RABs with the target RNC only if the RABs were present with the source RNC.

Figure 11. Routing Area Update Procedure without SGW Change


The table below includes detailed behaviors for a Routing Area Update without S-GW change.

Table 1. Routing Area Update without S-GW Change Behavior Table
Scenario Old RNC Status Old RNC RAB Old RNC DT Status PLMN Change NEW RNC DT Status S-GW Change SGSN Action
Intra RAU Not Present No RAB Supported No Supported No No RAB establishment with new RNC. No Modify Bearer Request to S-GW
Intra RAU Present No RAB Supported No Supported No No RAB establishment with new RNC. No Modify Bearer Request to S-GW
Intra RAU Present Some RABs Supported Do not care Supported No Only the present RABs are established. MBR sent to S-GW with the bearers with RABs that are be modified and the rest released. The bearers without RABs will be deactivated post RAU. If PLMN changed then MBR will carry the new PLMN ID.
Intra RAU Not Present No RAB Supported Yes Supported No No RAB establishment with new RNC. MBR is sent with only PLMN change. Bearer Context will not carry any TEID.
Intra RAU Present No RAB Supported Yes Supported No Same as above.
Intra RAU Not Present No RAB Not Supported No Supported No No RAB establishment with new RNC. Modify Bearer Request to S-GW with DTF set and no user FTEID.
Intra RAU Present No RAB Not Supported No Supported No Same as above.
Intra RAU Present Some RABs Not Supported Do not care Supported No Only the present RABs are established. MBR sent to S-GW with the bearers with RABs to be modified and the rest to be released. The bearers without RABs will be deactivated post RAU. If PLMN changed then MBR will carry the new PLMN ID.Modify Bearer.
Intra RAU Not Present No RAB Not Supported Yes Supported No No RAB establishment with new RNC. MBR is sent with only PLMN change. SGSN will page / Service req / establish RABs when a downlink data notification is received.
Intra RAU Present No RAB Not Supported Yes Supported No Same as above.
Intra RAU: New RNC does not support Direct Tunnel. No SGW relocation
Intra RAU Not Present No RAB Supported Do not care Not Supported No No RAB establishment with new RNC. SGSN sends Modify Bearer Request to S-GW with S4U TEID. If there is change in PLMN ID, then new PLMN ID will be carried.
Intra RAU Present No RAB Supported Do not care No Supported No Same as above.
Intra RAU Present Some RABs Supported Do not care Not supported No Only the present RABs are established. MBR sent to S-GW with all bearers having S4U TEID. If there is change in PLMN ID, the new PLMN ID will be carried.

Routing Area Update with S-GW Change

In a Routing Area Update with an S-GW change, the SGSN sends a Create Session Request with DTF flag set and no user plane FTEID. In its Create Session Response,. the S-GW sends an S12U FTEID which is forwarded to the RNC via a RAB Assignment Request.

The SGSN sends the RNC FTEID received in the RAB Assignment Response to the S-GW in a Modify Bearer Request. There are many scenarios to consider during Intra SGSN RAU.

Figure 12. Routing Area Update Procedure with SGW Change


The table below includes detailed behaviors for a Routing Area Update with S-GW change.

Table 2. Routing Area Update with S-GW Change Behavior Table
Scenario Old RNC Status Old RNC RAB Old RNC DT Status PLMN Change NEW RNC DT Status S-GW Change SGSN Action
Intra RAU: Both RNCs support Direct Tunnel. SGW relocation
Intra RAU Not Present No RAB Supported Do not care Supported Yes Send CSR request to new S-GW with DTF flag but no S4U / S12U FTEID. S-GW will send its S12U TEID that SGSN stores as part of DP's remote TEID. SGSN will not initiate any MBR request to S-GW since no RABs are established with new RNC. If S-GW subsequently gets downlink data, SGSN will get DDN and establish RABs and send MBR.
Intra RAU Present No RAB Supported Do not care Supported Yes Same as above.
Intra RAU Present Some RABs Supported Do not care Supported Yes Send CSR request to new S-GW with DTF flag but no S4U / S12U FTEID. S-GW sends its S12U TEID. RABs that are present will be established with new RNC. MBR will be initiated only with those RABs that are present rest of bearers to be removed.
Intra RAU: Old RNC does not support Direct Tunnel. SGW relocation
Intra RAU Not Present No RAB Not Supported Do not care Supported Yes Send CSR request to new S-GW with DTF flag but no S4U / S12U FTEID. S-GW sends its S12U TEID that SGSN stores as part of our DP's remote TEID. SGSN will not initiate any MBR request to S-GW since no RABs are established with new RNC. If S-GW subsequently gets downlink data, SGSN gets DDN and establishes RABs and sends MBR.
Intra RAU present No RAB Not Supported Do not care Supported Yes Same as above.
Intra RAU Present Some RABs Not SUpported Do not care Supported Yes Send CSR request to new S-GW with DTF flag but no S4U / S12U FTEID. S-GW sends its S12U TEID. RABs that are present will be established with new RNC and MBR will be initiated only with those RABs that are present and the rest as bearers to be removed.
Intra RAU: New RNC does not support Direct Tunnel. SGW relocation
Intra RAU Not Present No RAB Supported Do not care Not Supported Yes CSR request without DTF flag and with S4U FTEID.
Intra RAU Present No RAB Supported Do not care Not Supported Yes CSR request without DTF flag and with S4U FTEID.
Intra RAU Present Some rABs Supported Do not care Not Supported Yes CSR request without DTF flag and with S4U FTEID. No deactivation of PDPs.

Intra SRNS with S-GW Change

In Intra SRNS (Serving Radio Network Subsystem) with S-GW change, the SGSN sends a Create Session Request with DTF flag set and no user plane FTEID. The Create Session Response from the new S-GW contains the SGW S12U FTEID which the SGSN forwards to the Target RNC in a Relocation Request.

The SGSN sends the RNC S12U FTEID to the new S-GW in a Modify Bearer Request.

Figure 13. Intra SRNS with S-GW Change


The table below includes detailed behaviors for intra SRNS scenarios.

Intra SRNS without S-GW Change

In Intra SRNS without S-GW change, a Relocation Request is sent with SGW S12U FTEID. The RNC S12U FTEID received is forwarded to the S-GW in a Modify Bearer Request.

Figure 14. Intra SRNS without S-GW Change


The table below includes detailed behaviors for intra SRNS scenarios.

Table 3. Intra SRNS Behaviors
Old RNC DT Status New RNC DT Status S-GW Relocation Behavior
Supported Supported No Relocation Request to Target RNC is sent with S-GW S12 U FTEID. Modify Bearer Request to S-GW is sent with RNC S12 U FTEID.
Supported Not Supported No Relocation Request to Target RNC is sent with SGSN S4 U FTEID. Modify Bearer Request to S-GW is sent with SGSN S4 U FTEID
Not Supported Supported No Relocation Request to Target RNC is sent with S-GW S12U FTEID. Modify Bearer Request to S-GW is sent with RNC S12 U FTEID.
Not Supported Supported Yes Create Session Request to new S-GW is sent with DTF flag set and no user plane FTEID. Even if S-GW sent S4U FTEID in CSR Response SGSN internally treats that as an S12U FTEID and continues the relocation. Relocation Request to Target RNC is sent with S12 U FTEID received in Create Session Response. Modify Bearer Request to new S-GW is sent with RNC S12U FTEID
Supported Not Supported Yes Create Session Request to new SGW is sent with S4 U FTEID. Relocation Request to Target RNC is sent with SGSN U FTEID.Modify Bearer Request is sent with SGSN S4U FTEID.
Supported Supported Yes SGSN sends a Create Session Request to new SGW with DTF flag set and no user plane FTEID.Even if S-GW sent S4U FTEID in CSR Response, SGSN will internally treat that as S12U FTEID and continue the relocation. Relocation Request to the Target RNC is sent with the S12 U FTEID received in the Create Session Response. Modify Bearer Request to new S-GW is sent with RNC U FTEID.

New SRNS with S-GW Change and Direct Data Transfer

The new SGSN sends a Create Session Request with DTF flag set and no user plane FTEID to the new S-GW. The new SGSN sends the SGW S12U FTEID received in the Create Session Response in Relocation Request to the Target RNC. The new SGSN sends the RNC S12U FTEID received in a Relocation Request Ack to the new S-GW in a Modify Bearer Request.

Figure 15. New SRNS with S-GW Change with Data Transfer


The table below includes detailed behaviors for New SRNS scenarios.

New SRNS with S-GW Change and Indirect Data Transfer

Indirect Data Transfer (IDFT) during a new SGSN SRNS happens during E-UTRAN-to-UTRAN connected mode IRAT handover. See the figure below for a detailed call flow.

Figure 16. New SRNS with S-GW Change and Indirect Data Transfer


The table below includes detailed behaviors for New SRNS scenarios.

Table 4. New SRNS Behaviors
Target RNC DT Status Direct Forwarding S-GW Relocation Behavior
Supported No No Relocation Request with SGW S12U FTEID received in Forward Relocation Request. SGSN includes RNC U FTEID in Forward Relocation Response. RNC U FTEID is also sent in Modify Bearer Request with DTF flag set.
Supported Yes No Relocation Request with SGW S12U FTEID received in Forward Relocation Request. In Forward Relocation Response RNC U FTEID is included. And in Modify Bearer Request RNC U FTEID is sent and DTF flag is set.
Supported No Yes Create Session Request with DTF flag set and no user plane FTEID. Relocation Request is sent is SGW S12U FTEID received in Create Session Response. Even if SGW sent S4U FTEID in CSR Response we will internally treat that as S12U FTEID and continue the relocation. Create Indirect Data Forwarding Tunnel Request is sent with RNC FTEID received in Relocation Request Acknowledge.In Forward Relocation Response SGW DL U FTEID received in Create IDFT response is sent. Modify Bearer Request is send with DTF set and RNC U FTEID.
Supported Yes Yes Create Session Request with DTF flag set and no user plane FTEID. Relocation Request is sent with SGW S12U FTEID received in Create Session Response. Even if SGW sent S4U FTEID in CSR Response we will internally treat that as S12U FTEID and continue the relocation. In Forward Relocation Response RNC FTEID is sent and Modify Bearer Request is sent with DTF flag set and RNC U FTEID

Old SRNS with Direct Data Transfer

This scenario includes SRNS relocation between two SGSNs and hence IDFT is not applicable. Data will be forwarded between the source and target RNCs directly. Forward Relocation Request is sent with S12U FTEID.

Figure 17. Old SRNS with Direct Data Transfer


The table below includes detailed behaviors for Old SRNS.

Old SRNS with Indirect Data Transfer

Indirect Data Transfer (IDFT) during Old SGSN SRNS happens during UTRAN-to-E-UTRAN connected mode IRAT handover. A Forward Relocation Request is sent with SGW S12U FTEID.

Figure 18. Old SRNS with Indirect Data Transfer 4


Table 5. Old SRNS Behaviors
Source RNC DT Status Direct Forwarding S-GW Relocation Behavior
Supported No No Forward Relocation Request is send with SGW S12 U FTEID. If peer is MME, IDFT is applied. Then a Create Indirect Data Forwarding Tunnel Request is sent with User plane FTEID received in the Forward Relocation Response. This will be the eNB user plane FTEID. The SGW DL forwarding user plane FTEID received in the Create Indirect Data Forwarding Tunnel Response is sent in the Relocation Command.
Supported Yes No Forward Relocation Request is sent with SGW S12 U FTEID. The eNB / RNC user plane FTEID received in the Forward Relocation Response is sent in the Relocation Command.
Supported No Yes Forward Relocation Request is sent with SGW S12 U FTEID. If peer is MME, IDFT is applied. Then Create Indirect Data Forwarding Tunnel Request is sent with eNB User plane FTEID received in the Forward Relocation Response. The SGW DL forwarding user plane FTEID received in the Create Indirect Data Forwarding Tunnel Response is sent in the Relocation Command.
Supported Yes Yes Forward Relocation Request is sent with SGW S12 U FTEID. The eNB / RNC use plane FTEID received in the Forward Relocation Response is sent in the Relocation Command.

Network Initiated Secondary PDP Context Activation

The S-GW sends a Create Bearer Request for Network Initiated Secondary PDP Context Activation with the SGW S12U FTEID. This FTEID is sent in a RAB Assignment Request to the RNC. The RNC S12U FTEID received in the RAB Assignment Response is sent to the S-GW in a Create Bearer Response.

Figure 19. Network Initiated Secondary PDP Context Activation 5


PGW Init Modification when UE is Idle

If UE is in IDLE state and PGW Init Modification is received, the SGSN sends the first MBR. Upon getting PGW Init Modification in Idle State, the SGSN queues the PGW Init Modification and feeds a Downlink Data Notification internally. This sets up all RABs (using old QoS) and sends a Modify Bearer Request. When the Downlink Data Procedure is completed, the queued PGW Init Modification is processed.

Figure 20. PGW Init Modification when UE in Idle State


Limitations

During an intra RAU, intra SRNS or Service Request triggered by RAB establishment, if a few RABs fail the Modify Bearer Request the SGSN will mark those RABs as bearers to be removed. Under current specifications, it is not possible to send a Modify Bearer Request with a few bearers having S12U U-FTEIDs and a few bearers not having U-FTEIDs.

There is an ongoing CR at 3GPP to allow such Modify Bearer Requests and the S-GW should send DDN when it gets downlink data for the bearers that did not have U-FTEIDs. If this CR is approved, the SGSN will support (in a future release) sending a partial set of bearers with S12U FTEID and some bearers without any U-FTEID.

Standards Compliance

The Direct Tunnel complies with the following standards:
  • 3GPP TS 23.060 version 10 sec 9.2.2 General Packet Radio Service (GPRS) Service description
  • 3GPP TS 29.274 v10.5.0 3GPP Evolved Packet System (EPS) Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C)

Configuring Support for Direct Tunnel

The SGSN determines if setup of a direct tunnel is allowed or disallowed. Currently, the SGSN and S-GW are the only products that provide configuration commands for this feature. All other products that support direct tunnel do so by default.

By default, direct tunnel support is

  • disallowed on the SGSN/S-GW

  • allowed on the GGSN/P-GW

The SGSN/S-GW direct tunnel functionality is enabled within an operator policy configuration. One aspect of an operator policy is to allow or disallow the setup of direct GTP-U tunnels. If no operator policies are configured, the system looks at the settings in the operator policy named default. If direct tunnel is allowed in the default operator policy, then any incoming call that does not have an applicable operator policy configured will have direct tunnel allowed. For more information about the purpose and uses of operator policies, refer to the section Operator Policy.

Configuring Direct Tunnel on an S4-SGSN

Configuration of a GTP-U direct tunnel (DT) requires enabling DT both in a call control profile and for the RNC.


Important

Direct tunneling must be enabled at both end points to allow direct tunneling for the MS/UE.

Enabling Setup of GTP-U Direct Tunnel

The SGSN determines whether a direct tunnel can be setup and by default the SGSN does not support direct tunnel. The following configuration enables a GTP-U DT in a call control profile: 

config 
   call-control-profile policy_name 
      direct-tunnel attempt-when-permitted [ to-ggsn | to-sgw ] 
      end
Notes:

  • A call-control profile must have been previously created, configured, and associated with a previously created, configured, and valid operator policy. For information about operator policy creation/configuration, refer to the Operator Policy chapter in this guide.

  • Beginning with Release 19.3.5, to-ggsn and to-sgw options have been added to the direct-tunnel command to enable the operator to select the interface the SGSN will use for its direct tunnel. For a collocated Gn/GP-SGSN and an S4-SGSN,

    • Use the keyword attempt-when-permitted without a filter to enable both interface types: GTP-U towards the GGSN and S12 towards the SGW.

    • Use the keyword attempt-when-permitted with the to-ggsn keyword filter to enable only the GTP-U interface between the RNC and the GGSN.

    • Use the keyword attempt-when-permitted with the to-sgw keyword filter to enable only the S4's S12 interface between the RNC and the SGW.

  • To remove the direct tunnel settings from the configuration, use the following command: direct-tunnel attempt-when-permitted [ to-ggsn | to-sgw ]

  • Direct tunnel is allowed on the SGSN but will only setup if allowed on both the destination node and the RNC.

Enabling Direct Tunnel to RNCs

SGSN access to radio access controllers (RNCs) is configured in the IuPS service. Each IuPS service can include multiple RNC configurations that determine communications and features depending on the RNC. By default, DT functionality is enabled for all RNCs.

The following configuration sequence enables DT to a specific RNC that had been previously disabled for direct tunneling: 

config 
   context ctxt_name 
      iups-service service_name 
         rnc id rnc_id 
            default direct-tunnel 
            end
Notes:
  • An IuPS service must have been previously created, and configured.
  • An RNC configuration must have been previously created within an IuPS service configuration.
  • Command details for configuration can be found in the Command Line Interface Reference.

Restricting Direct Tunnels

The following configuration scenario prohibits the S4-SGSN to setup direct tunneling over the S12 interface during Inter SGSN RAUs: 


config 
   call-control-profile profile_name 
      rau-inter avoid-s12-direct-tunnel  
      end

Restrict direct tunneling by a specific RNC. The following configuration scenario restricts the SGSN from attempting to setup a direct tunnel when a call originates from a specific RNC. 


config 
   context context_name 
      iups-service service_name 
         rnc id rnc_id 
            direct-tunnel not-permitted-by-rnc 
												end

Verifying the Call-Control Profile Configuration

Use the following command to display and verify the direct tunnel configuration for the call-control profiles: 

show call-control-profile full name <profile_name>

The output of this command displays all of the configuration, including direct tunnel for the specified call-control profile. 

Call Control Profile Name = ccprofile1 
. 
. 
. 
Re-Authentication                                                                                  : Disabled 
Direct Tunnel                                                                                          : Not Restricted 
GTPU Fast Path                                                                                        : Disabled 
. 
.

Verifying the RNC Configuration

Use the following command to display and verify the direct tunnel configuration in the RNC configuration: 

show iups-service name  <service_name>

The output of this command displays all of the configuration, including direct tunnel for the specified IuPS service. 

IService name                                                : iups1 
. 
. 
. 
Available RNC: 
    Rnc-Id                                                          : 1 
    Direct Tunnel                                            : Not Restricted

Configuring S12 Direct Tunnel Support on the S-GW

The example in this section configures an S12 interface supporting direct tunnel bypass of the S4 SGSN for inter-RAT handovers.

The direct tunnel capability on the S-GW is enabled by configuring an S12 interface. The S4 SGSN is then responsible for creating the direct tunnel by sending an FTEID in a control message to the S-GW over the S11 interfaces. The S-GW responds with it's own U-FTEID providing the SGSN with the identification information required to set up the direct tunnel over the S12 interface.


Important

If you modify the interface-type command, the parent service (service within which the eGTP/GTP-U service is configured) will automatically restart. Service restart results in dropping of active calls associated with the parent service.

Use the following example to configure this feature. 

configure 
   context egress_context_name -noconfirm 
      interface s12_interface_name 
         ip address s12_ipv4_address_primary 
         ip address s12_ipv4_address_secondary 
         exit 
      exit 
   port ethernet slot_number/port_number 
      no shutdown 
      bind interface s12_interface_name egress_context_name 
      exit 
   context egress_context_name -noconfirm 
      gtpu-service s12_gtpu_egress_service_name 
         bind ipv4-address s12_interface_ip_address 
         exit 
      egtp-service s12_egtp_egress_service_name 
         interface-type interface-sgw-egress 
         validation-mode default 
         associate gtpu-service s12_gtpu_egress_service_name 
         gtpc bind address s12_interface_ip_address 
         exit 
      sgw-service sgw_service_name -noconfirm 
         associate egress-proto gtp egress-context egress_context_name egtp-service s12_egtp_egress_service_name 
         end

Notes:

  • The S12 interface IP address(es) can also be specified as IPv6 addresses using the ipv6 address command.

Monitoring and Troubleshooting Direct Tunnel

show subscribers sgsn-only

The output of this command indicates whether. Direct Tunnel has been established. 

show subscribers sgsn-only full all 
   
Username: 123456789012345 
 Access Type: sgsn-pdp-type-ipv4        Network Type: IP 
 Access Tech: WCDMA UTRAN 
  | 
  | 
 NSAPI: 05                               Context Type: Primary 
 Context initiated by: MS 
 Direct Tunnel : Established

show gmm-sm statistics sm-only

The output of this command indicates the number of total active PDP contexts with direct tunnels.
show gmm-sm statistics sm-only 
Activate PDP Contexts: 
 Total Actv PDP Ctx: 
  3G-Actv Pdp Ctx:             1  2G-Avtv Pdp Ctx:       0 
  Gn Interface:                1  Gn Interface:          0 
  S4 Interface:                1  S4 Interface:          0 
 Total Actv Pdp Ctx: 
  with Direct Tunnel:          1

Direct Tunnel Bulk Statistics

Currently there are no bulk statistics available to monitor the number of PDP contexts with Direct Tunnel.

Bulk statistics under the EGTPC schema are applicable for both Direct Tunnel and Idle Mode Signalling Reduction (ISR) [3G and 2G]. The following statistics track the release access bearer request and response messages which are sent by the SGSN to the S-GW upon Iu or RAB release when either a direct tunnel or ISR is active:
  • tun-sent-relaccbearreq
  • tun-sent-retransrelaccbearreq
  • tun-recv-relaccbearresp
  • tun-recv-relaccbearrespDiscard
  • tun-recv-relaccbearrespaccept
  • tun-recv-relaccbearrespdenied
The following bulkstats under EGTPC schema track Downlink Data Notification (DDN) Ack and failure messages between the S-GW and the SGSN when either direct tunnel or ISR is active:
  • tun-recv-dlinknotif
  • tun-recv-dlinknotifDiscard
  • tun-recv-dlinknotifNorsp
  • tun-recv-retransdlinknotif
  • tun-sent-dlinknotifackaccept
  • tun-sent-dlinknotifackdenied
  • tun-sent-dlinkdatafail

For complete descriptions of these variables, see the EGTPC Schema Statistics chapter in the Statistics and Counters Reference.