GGSN

Overview

The GGSN — Gateway GPRS Support Node — is the anchor point for subscriber data sessions in 2G GPRS and 3G UMTS networks. It sits at the boundary between the mobile core and external IP networks, providing the gateway function through which all subscriber internet traffic flows. While the SGSN handles subscriber mobility and radio access management, the GGSN is stationary: a subscriber's IP address is allocated by and anchored at the GGSN for the lifetime of their data session, regardless of how many times they change SGSN.

The GGSN terminates the GTP tunnel that begins at the SGSN. When a subscriber activates a PDP context, the SGSN and GGSN establish a GTP tunnel identified by a Tunnel Endpoint Identifier (TEID). All user-plane data for that subscriber flows through this tunnel — encapsulated in GTP-U on the mobile side, forwarded as plain IP on the Gi interface toward the internet or operator services.

Because every subscriber's data session is anchored at the GGSN, it is also the natural enforcement point for per-subscriber and per-APN policies: quality of service markings, charging triggers, and access control to specific services. This policy role is a direct forerunner of the P-GW's function in 4G, and the GTPv1 protocol the GGSN uses was later replaced by GTPv2 (with more structured message semantics) and ultimately by PFCP (which separates the control and user planes) in the 4G and 5G architectures.

The GGSN is replaced by the Packet Data Network Gateway (P-GW) in 4G EPC. In deployments bridging 3G and 4G, combined PGW/GGSN products handle both GTPv1 from legacy SGSNs and GTPv2/S5-S8 from the 4G MME and SGW.

---

How it works

The GGSN operates through a simple request-response model driven by GTP-C signalling from the SGSN. Its core functions are PDP context management, address allocation, and user-plane forwarding.

PDP context creation

When a subscriber initiates a data session, the SGSN sends a Create PDP Context Request to the GGSN over the Gn interface. This GTP-C message specifies the requested APN, the subscriber's IMSI, the SGSN's GTP-U tunnel address and TEID, and QoS requirements. The GGSN validates the IMSI against any access control list, selects an IP address from the address pool for the APN, establishes the GTP-U tunnel endpoint, and returns a Create PDP Context Response containing the allocated IP address and the GGSN's TEID. The subscriber's data session is now live.

User-plane forwarding

With the GTP-U tunnel established, all subscriber traffic flows bidirectionally. Uplink: the subscriber's IP packets arrive at the SGSN encapsulated in GTP-U frames, are forwarded through the tunnel to the GGSN's TEID, where the GTP-U header is stripped and the inner IP packet is forwarded out the Gi interface to the internet. Downlink: IP packets destined for the subscriber's allocated address arrive at the GGSN's Gi interface, are matched against the active PDP context table by destination IP, re-encapsulated in GTP-U with the SGSN's TEID, and forwarded back through the tunnel.

PDP context modification and deletion

QoS parameters for an active session can be updated via an Update PDP Context Request. When the session ends — either via subscriber deactivation, SGSN-initiated teardown, or timeout — a Delete PDP Context Request is exchanged, and the GGSN deallocates the IP address and removes the tunnel entry.

Roaming — the Gp interface

When a subscriber roams to a foreign network, their SGSN is in the visited network while their subscribed APNs reside in the home network. The visited SGSN establishes the GTP-C tunnel to the home network's GGSN over the Gp interface, which traverses the IPX/GRX roaming backbone. The GGSN in the home network serves the subscriber's data session just as it would for a domestic subscriber, anchoring their home IP address regardless of their roaming location.

---

Architecture role

The GGSN sits at two network boundaries simultaneously: the internal boundary with the SGSN pool (Gn interface), and the external boundary with internet and operator service networks (Gi interface). In roaming, it additionally faces the IPX/GRX interconnect via the Gp interface.

Operators typically deploy a small pool of GGSNs — often just two or four for redundancy — handling the data sessions of the entire subscriber base. Each GGSN serves one or more APNs, with dedicated GGSNs sometimes allocated to high-traffic APNs (mobile internet) or restricted APNs (enterprise VPN, IMS signalling).

In 2G GPRS: The GGSN is reached from SGSNs via GTPv1 over the Gn interface. GTP was designed for GPRS and the message set is relatively simple: Create, Update, and Delete PDP Context are the primary control messages.

In 3G UMTS: The same GTPv1 protocol applies. 3G networks may use Direct Tunnel mode, where GTP-U tunnels are established directly from the RNC to the GGSN, bypassing the SGSN for user-plane traffic while the SGSN retains control-plane responsibility. This reduces SGSN processing load for high-bandwidth sessions.

In 4G LTE: The GGSN is replaced by the P-GW. Combined PGW/GGSN nodes (often labelled as "SPGW" products) speak both GTPv1 toward 3G SGSNs and GTPv2/Diameter toward the 4G MME/SGW, providing a single anchor point during the multi-year 3G-to-4G transition.

The Gc interface — between the GGSN and HLR — allows the GGSN to query subscriber address information directly. In practice this interface is rarely used in deployed networks; the SGSN provides the necessary subscription context at PDP creation time.

---

Key interfaces

---

Security posture

The GGSN has a medium overall threat level, lower than the SGSN or HLR because it does not handle subscriber identity or authentication operations. It does, however, sit at the data plane boundary of the network — all subscriber internet traffic passes through it — and its GTP-C interface is exposed to the open IPX/GRX network via the Gp roaming interface.

The core GTP security weakness is the absence of peer authentication. GTPv1 provides no cryptographic mechanism to verify that a Create PDP Context Request comes from a legitimate SGSN. The GGSN accepts or rejects requests based on IP source address filtering and simple plausibility checks on the IMSI/APN combination — neither of which constitutes strong authentication.

The Gi interface, connecting the GGSN to the internet, creates a second attack surface. Poorly configured Gi networks have allowed direct internet traffic to reach subscriber addresses, enabling port scanning and exploitation of vulnerabilities on subscriber devices.

---

Attack surface

GTP-C Create PDP Context spoofing

Any host with network access to the GGSN's GTP port can send a syntactically valid Create PDP Context Request. In roaming scenarios, the Gp interface is accessible to any operator connected to the IPX/GRX. An attacker who successfully creates a PDP context for a valid IMSI can redirect the subscriber's data session to a GGSN they control, enabling traffic interception.

Impact: Data session hijacking; man-in-the-middle on subscriber internet traffic. Difficulty: Medium. Requires routable access to the Gp interface and knowledge of a target IMSI.

GTP-U packet injection

GTP-U tunnels are identified by a Tunnel Endpoint Identifier (TEID). If an attacker can determine the TEID of an active session (possible via traffic analysis or information disclosure), they can inject arbitrary packets into the GTP-U tunnel, which the GGSN will forward to the subscriber as legitimate downlink traffic.

Impact: Traffic injection into subscriber sessions; potential for session manipulation. Difficulty: Medium. Requires network access and TEID enumeration.

PDP context flooding

An attacker with access to the Gp interface can send large volumes of Create PDP Context Requests for valid IMSIs, exhausting the GGSN's IP address pool or session table, or overwhelming its processing capacity.

Impact: Denial of service for legitimate subscriber data sessions. Difficulty: Low. Sending GTP-C messages at volume requires only network access to the Gp port.

---

Mitigations

• GTP peer IP whitelisting on Gn and Gp: Maintain a list of known-legitimate SGSN IP addresses for each roaming partner (GSMA IR.21 data). Block Create PDP Context from IPs not on this list before messages reach the GGSN.

• Stateful GTP-U TEID validation: The GGSN should maintain a session table and reject GTP-U packets whose TEID does not correspond to an active PDP context. This prevents both injection and spoofed teardown attacks.

• Gi interface ACLs: Apply ingress ACLs on the Gi interface to prevent direct inbound connections from the internet to subscriber IP addresses. Subscriber devices are not servers; unsolicited inbound traffic is almost always hostile.

• PDP context creation rate limiting: Apply per-source-SGSN rate limits on Create PDP Context Requests to prevent flooding attacks from a single compromised or rogue peer.

• GTP firewall on Gp: Deploy a dedicated GTP firewall at the Gp interface, inspecting GTP-C message types, APN validity, and IMSI plausibility against home subscriber data.

---

Spec references

• 3GPP TS 23.060 — GPRS service description. Section 5 defines the GGSN functional model; Section 9 defines PDP context procedures including creation, modification, and deletion.

• 3GPP TS 29.060 — GTP across Gn and Gp interfaces. The normative GTPv1-C specification that defines all GGSN-facing control messages, including message formats, information elements, and error handling.

• GSMA IR.88 — LTE and EPC Roaming Guidelines. Relevant to the Gp interface; defines baseline GTP security requirements for roaming partners, including source IP validation.

---

Related topics

The GGSN is the user-plane counterpart of the SGSN, which manages the control-plane signalling. GTP tunnels are established using GTP-C and carry user traffic via GTP-U. The GGSN connects to the HLR on the Gc interface via MAP over SS7, though this is rarely used in practice.

The GGSN is replaced by the P-GW in 4G EPC. Roaming data sessions traverse the GGSN via the Gp interface across the GRX/IPX network, as described in the roaming architecture.