3G DIRECT TUNNEL (3GDT)

3G Direct Tunnel (3GDT), FAJ 121 0148, is a license-controlled optional feature

applicable for WCDMA Systems only. The 3GDT feature separates the user
traffic (Iu-U) from the control traffic (Iu-C). Control traffic and user traffic from
roaming users are handled by the SGSN, while the non-roaming, non-camel, user
traffic is transported in a tunnel set up directly between the RNC and the GGSN.

OVERVIEW

3G Direct Tunnel (3GDT) Overview

1 PDP contexts = 1 IP address + 1 TEID for each GTP-U tunnel end-points.
Each node sets its own TEID and user plane IP-address.

Non-3GDT
Iu-C GTP-C
MS SGSN
RNC GGSN

Iu-U GTP-U

3GDT
Iu-C GTP-C
MS SGSN
RNC GGSN

Iu-U GTP-U

The main task of the SGSN is to provide the GGSN and the RNC with
the corresponding data.

The 3GDT feature enables a payload boost in the WCDMA packet Core Network
(CN) and is beneficial when the payload exceeds the SGSN limits. In other word,
3GDT bypasses the SGSN so that the RNC could connect directly to the GGSN
eliminating the bottleneck at the SGSN. Typically, this is expected to happen
when Turbo-3G High Speed Packet Access (HSPA) becomes a mass-market
service.

3GDT is an optional function to the current 3GPP architecture, in Iu mode, that

allows the SGSN to establish a direct user plane tunnel for payload between
RAN and GGSN within the PS domain.
 In a non-3GDT scenario, the SGSN knows the addresses of the tunnel between
the RNC and the SGSN, similarly the RNC knows the addresses of the tunnel
between SGSN and RNC, and additionally the SGSN and the GGSN knows the
addresses between themselves. That is, two tunnels are established for user plane
traffic.

In a 3GDT scenario, the two-tunnel solution is substituted with a direct tunnel

between GGSN and RNC for the user plane. Hence, GGSN has to know the IP-
address and TEID of the RNC at all times. In the same manner, the RNC has to
know the GGSN IP-address and TEID.

Since the non-roaming, non-CAMEL controlled WCDMA payload traffic is no

longer passing through the SGSN, the need for SGSN payload capacity
expansion, as the traffic increases, is reduced. The reduced need for capacity
expansion is of particular value when having mobile broadband and stationary,
payload intensive subscribers in the network.

TRAFFIC CASE

PDP Context Activation Procedure

Activate PDP Context Request Procedure

MS RNC SGSN GGSN

Activate PDP Context Request 1 2
Create PDP Context Request

Create PDP Context Response

4
RAB Assignment Request 3
GGSN UP TEID RAB Assignment Response 6
Update PDP Context Request
5
Update PDP Context Response 7
8 Activate PDP Context Accept
RNC UP TEID

PDP Context Activation Procedure

Initiated by the MS, a PDP Context Activation procedure establishes a virtual
data channel between the MS and a Packet Data Network (PDN), through the
GPRS network. When an MS requests a PDP context activation, the SGSN
decides if a direct tunnel should be set up.

The following conditions must be met in order to set up a direct tunnel between
the GGSN and RNC:
• The MS must be attached in the Universal Mobile Telecommunications
System (UMTS) Radio Access Technology (RAT) domain.
• The license-controlled 3GDT feature must be activated.
• The MS must be attached within a home Public Land Mobile Network
(PLMN), that is, the MS may not be a visiting subscriber.
• The subscriber profile may not contain a CAMEL Subscription Information
data.
• The MS must be attached through an RNC configured as 3GDT compliant.
• The 3GDT prefix in the subscribed APN received in the subscription data for
the MS, from the HLR, indicates if 3GDT is applicable for a particular APN and
MS. The 3GDT prefix in the APN entry, in the DNS, indicates if 3GDT is
applicable for a particular APN and GGSN.
• The GGSN must support GTP protocol version 1.

The APN must indicate that both the MS and the GGSN are candidates for 3GDT,
for that particular APN. In the PDP context activation procedure, the following
messages are effected by 3GDT

• RAB Assignment Request, which includes the user-plane IP

address and TEID value of the GGSN (bullet no 4).

• Update PDP Context Request, which includes the user-plane

IP address and TEID value of the RNC (bullet no 6).

From 3GPP 23.060 CR570 chapter 9.2.2.1 and 9.2.2.1.1 :

• If the SGSN decides to establish Direct Tunnel between RNC
and GGSN, the SGSN provides to the RNC the Direct Tunnel
specific parameters in the “RAB Assignment Procedure” and
shall initiate Update PDP Context procedure to update the IP
Address and TEID for Downlink data.
Inter RNC Intra SGSN RAU Procedure

Inter RNC Intra SGSN RAU Procedure

MS targetRNC sourceRNC SGSN GGSN

(1) Routing Area Update Request

(2) Authentication & Ciph Req/Resp

(3) Update PDP Context Request

SGSN UP TEID
(4) Update PDP Context Response
(5) Iu Release Command

(6) Iu Release Complete

(7) Routing Area Update Accept

(8) Routing Area Update Complete

(9) Service Request

(10) RAB Assignment Request
(11) RAB Assignment Response (13) Update PDP Context Request

(14) Update PDP Context Response

GGSN UP TEID

RNC UP TEID

Inter RNC Intra SGSN RAU Procedure

RABs are released at an Iu Release triggered by an inter-RNC intra-SGSN RAU

even if the PDP contexts are active. A GTP-U tunnel between the GGSN and
SGSN is required to handle downlink packets from the GGSN as the new RNC
may not be configured as 3GDT compliant in the SGSN.

The Intra-RNC Intra-SGSN RAU procedure follows the corresponding procedure

used for the two-tunnel solution, apart from the differences highlighted in the
sequence diagram

The following messages are effected by 3GDT :

1 Update PDP Context Request, due to Iu Release to the source

RNC, which includes the user-plane IP address and TEID value
of the SGSN (bullet no 3).

2 RAB Assignment Request, which includes the user-plane IP

address and TEID value of the GGSN (bullet no 10).

3 Update PDP Context Request, which includes the user-plane IP

address and TEID value of the RNC (bullet no 13).
 GGSN needs to be updated with a ”working” TEID at all times, when the RAB is
not yet established the GGSN needs to be updated with the SGSN UP TEID.

Affected Signaling Procedures

The following are the procedures affected due to 3GDT :

• Activate (Secondary) PDP Context Procedure

• Iu Release/RAB Release/Preservation
• RAB Re-establish.
• SGSN Initiated PDP Modification
• GGSN Initiated Update
• Inter RNC Intra SGSN RAU Procedure
• ISRAU Procedure

RESTRICTIONS

3GDT restrictions required in 3GPP Rel7

From 23.060 v.7.4.0 chapter 15.6:
“Direct Tunnel shall not be used in following traffic cases:

1) In roaming case

2) SGSN has received CAMEL Subscription

Information in the subscriber profile in HLR

3) GGSN does not support GTP protocol

version 1.”

3GDT Restrictions
 3GDT has restrictions in implementation according to 3GPP 23.060 v.7.4.0
chapter 15.6. Direct Tunnel shall not be used in following traffic cases:

• In roaming case - The SGSN needs to know whether the

GGSN is in the same or different PLMN.

• SGSN has received CAMEL Subscription Information in the

subscriber profile from the HLR.

If Direct Tunnel is established then volume reporting from

SGSN is not possible as the SGSN no longer has visibility of
the User Plane. Since a CAMEL server can invoke volume
reporting at anytime during the life time of a PDP Context, the
use of Direct Tunnel shall be prohibited for a subscriber
whose profile contains CAMEL Subscription Information.

• GGSN does not support GTP protocol version 1.

IMPLEMENTATION IN SGSN R8

Implementation in SGSN R8 – 3GPP

R7 partly “3GDT Basic”
ƒ Optional feature controlled by parameter 3gdt.
ƒ Includes direct or legacy GTP tunnel handling
configurable on RNC, GGSN and/or subscriber basis
(using APN)
Gives the operator the possibility to use 3GDT for ONE subscriber , ONE RNC and ONE
GGSN for testing purposes.

ƒ Functional with legacy nodes GGSN R4 and UTRAN

P5 with the following excluded items:
– Signaling interface optimizations (GGSN/UTRAN)
– Error indication handling (GGSN/UTRAN)
– Combined 3GDT and PS Handover or SRNS Relocation
functionality.
– DTI Flags IE handling towards GGSN.

Implementation in SGSN R8
The following parameters are related to 3GDT:
• 3gdt
• DirectTunnel
• SGSN_3gdt_prefix

The 3GDT feature is designed to operate in a legacy network,

which means that the changed 3GPP R7 signaling procedures for
3GDT are not supported between the SGSN and the legacy RNCs
and GGSNs. The following areas are not supported for 3GDT:
• GGSN initiated update procedure.
• Error signaling between SGSN-RNC-GGSN
• Procedures for hanging PDP context in the SGSN in error
situations.
• Push services in error situations.
• IMS services in, and after, some error scenarios.
• S-CDR/G-CDR discrepancy during, and after, error scenarios.
• PS Handover (FAJ 121 0147) and SRNS Relocation (FAJ 121
958), which will be blocked. Normal RAU procedures
according to 3GPP TS 23.060 will apply.

These limitations will be removed in alignment with future design

evolutions in the SGSN, RNC and GGSN respectively as
applicable.
NETWORK IMPACT

Network Impact
ƒ The added signaling will decrease the SAU capacity in the SGSN
with at most 10%.

ƒ The signaling will in certain scenarios increase with more than

50% over the Gn i/f, impacting the GGSNs.

ƒ Limitiation in SGSN regarding payload is no longer applicable for

the DT payload since it bypasses the SGSN.

ƒ No capacity impact is forseen in the RNC.

ƒ Packet Backbone Network has to be prepared, including the

possible routers and firewalls, regarding setup issues when
connecting the Gn (Core network) side with the Iu (Radio network)
side.

Signaling will increase with the use of 3GDT. For example, in PDP context
activation, GTP messages is modified to accommodate sending and updating
RNC TEID and GGSN TEID across the GPRS backbone. Additional GTP
procedures is also put to support 3GDT. Limitiation in SGSN regarding payload
is no longer applicable for the DT payload since it bypasses the SGSN.

Since 3GDT impacts both payload and signaling, on network as well as on node
level, it is strongly recommended to perform a network analysis of the specific
operator traffic case. This is done in order to determine optional configurations
and node sizes. The analysis may also involve SGSN Pool and HSPA. For
dimensioning of the SGSN, consider the payload and signaling described below.

The total payload through the SGSN is the sum of the following payloads:
• The roaming WCDMA traffic payload.
• The GSM payload, for Dual Access SGSN.
• The non-roaming WCDMA payload for WCDMA users
configured for 3GDT OFF.

The total signaling in the SGSN consists of the following:

• The initial SGSN signaling.
• The additional 3GDT signaling, particularly number of 3GDT context