Test Us
Stingray GTP-C Proxy

GTP-C Proxy

GTP-C control plane proxy for mobile networks

About the solution

Stingray GTP-C Proxy lets you combine PGWs from different vendors into shared pools, distribute subscribers according to operator rules, and handle failures without changing SGW and MME configuration: you only need to point the APN to the proxy in DNS once.

The solution supports GTPv1 and GTPv2, helps you evolve the network without reconfiguring SGW and MME, and preserves connection state when the proxy restarts.

gtp-c proxy diagram

Why operators need GTP-C Proxy

Multi-vendor PGWs in one network

GTP-C Proxy combines gateways into shared pools managed through unified rules. Existing SGW and MME configuration stays unchanged.

PGW selection based on operator rules

Subscribers are routed to the right gateways by IMSI, MSISDN, APN, PLMN, radio access type (RAT), and user location (ULI), or any combination of them. Pool weights and backup PGWs let you tune distribution to your network's requirements.

Failure handling without manual switchover

If a PGW fails, GTP-C Proxy removes it from the pool and routes new connections to healthy PGWs with a compatible GTP version. Connection state is stored in Redis, so it survives restarts of the proxy itself.

2G/3G and LTE transitions

GTP-C Proxy supports GTPv1 and GTPv2 and handles the protocol version change when a subscriber moves between network generations.

How Stingray GTP-C Proxy works

gtp-c proxy pools

GTP-C Proxy operates on the GTP-C control plane between the SGW / SGSN and the PGW. To the SGW, the proxy looks like a PGW; to the PGW, it looks like an SGW. The operator’s DNS points the APN to the proxy, which selects the target PGW according to the configured rules and forwards signaling to it.

GTP-U subscriber traffic flows directly between the SGW and the PGW. GTP-C Proxy is not part of the user data path.

As a result, the operator gains an additional layer of control over PGW selection while keeping the existing access network architecture. All interaction uses standard GTP messages.

Request a personalized demo and trial of the solution

Scaling

Performance grows with the number of threads

gtp-c proxy scaling

How does the infrastructure scale?

GTP-C Proxy scales at three levels: processing threads on the server, proxy instances, and state storage. Each level scales independently.

Processing threads

Signaling is handled by several worker threads pinned to CPU cores. On a production-grade test bed, processing performance reaches 348,000 Modify Bearer operations per second on four cores.

Proxy instances

Multiple GTP-C Proxy instances share common storage and common routing rules. Session state is stored centrally, so the failure of one instance does not cause connection loss. Failover between instances is handled via BGP.

State storage

A single Redis server handles about 105,000 Modify Bearer/s. For higher loads, a Redis cluster with replicas and automatic failover on primary node failure is used.

Rule changes without restart

PGW pools, weights, and routing rules are stored in a single document (a YAML file or Redis) and applied to all instances on the fly, with no restart and no session loss.

Fault tolerance

2.03 s max (maximum failover time when the Redis primary node failed during a load test)

Proxy restart

State is stored in Redis, so connections are preserved.

PGW failure or restart

A failed PGW is removed from the pool, and new connections are routed to healthy PGWs with a compatible GTP version. PGW restarts are detected via Echo messages.

SGW restart

Sessions are preserved and restored following the 3GPP TS 23.007 procedure (clause 27).

Overload

Existing subscribers are served first; new connections are rejected.

Instance redundancy

Failover between proxy instances via BGP.

Stingray GTP-C Proxy capabilities

Protocols and routing

  • GTPv2 on S5/S8 and GTPv1 on Gn/Gp.
  • Session continuity during 2G/3G and LTE transitions.
  • Multi-vendor PGW pools.
  • Routing and rebalancing of new connections across PGWs, session parameter rewriting, and location reporting for S5/S8 and Gn/Gp.
  • Connection preservation on SGW restart per TS 23.007, clause 27.

Reliability, capacity, and management

  • Performance of up to 348,000 Modify Bearer operations per second on four threads.
  • Load management and watchdog timer.
  • Web interface, Prometheus, and Grafana.
  • Session viewing and Gn/Gp pool configuration in the web interface.
  • Delivered as RPM packages for VEOS 8.x and EL8.

Single management console

Web interface

Sessions, routing document history, instance and PGW status, administrator and viewer roles.

Prometheus

Metrics for messages, transactions, failures, storage, and PGWs by GTP version.

Grafana

Built-in monitoring dashboards with authentication via the web interface.

Deployment requirements

Parameter Requirements
OS VEOS 8.x or EL8, x86_64; glibc 2.28, systemd 239
Delivery gtpcproxy and gtpcproxy-web RPM packages. Installation, upgrade, and rollback via dnf
Virtualization KVM or VMware. Dedicated vCPUs mapped 1:1 to physical cores of a single NUMA node are recommended
Network 8 MiB signaling receive buffer: CAP_NET_ADMIN or net.core.rmem_max of at least 8 MiB
Redis Redis must respond without pauses longer than 250 ms (for example, during live VM migration). Migrate the Redis VM during a maintenance window
CPU and memory For 348,000 Modify Bearer/s: 19 dedicated cores in total, 4 of them for signaling processing
Container Podman (rootless)

Request a Free GTP-C Proxy Demo

Fill in the form
We will contact you, specify the task, provide access to the documentation and answer your questions.
Choose the solution
We discuss the current situation: traffic volume, available equipment, the functionality you need.
Free trial
Our engeniers install the selected software and adapt it to your specific tasks. Сontract — only after the test is successful.

Related solutions

ePDG

Solution for launching Wi-Fi Calling (VoWiFi) in MVNOs
Learn More

PCEF

PCEF enforces quality of service (QoS) policies and flexible billing based on various conditions as required by the PCRF
Learn More

PGW

PGW or PDN GW is intended for use by telecom operators within the EPC (Evolved Packet Core) architecture of the LTE/4G standard
Learn More

Turnkey MVNO Launch

Launch new MVNO with VAS Experts and our technological partners
Learn More

Latest On The Blog

Mobile Networks

Stingray GTP-C Proxy: a new product for a multi-vendor mobile network core

November 6, 2026
Mobile Networks

Inside GTP-C Proxy: 348,000 Modify Bearer Requests per Second and Sessions That Survive Failures

November 6, 2026
Mobile Networks

Four Operator Challenges GTP-C Proxy Solves

November 6, 2026
Mobile Networks
Telecom

Becoming a Convergent Operator: Broadband & MVNO on One Core

October 22, 2026