How Mobile Networks Route Traffic: PGW, SGW, and Why Your IP Changes

Mobile networks have their own internal architecture for routing IP traffic. PGW, SGW, IPv6-first cores, and what it means for geolocation and detection.

How Mobile Networks Route Traffic: PGW, SGW, and Why Your IP Changes

A user opens your app on their phone. They walk down the street; their connection might switch from Wi-Fi to LTE to 5G and back. Their public IP might change once, twice, or many times. The geolocation for the IP they’re currently using might point to a city hundreds of kilometers from where they actually are. All of this is normal — and all of it is shaped by the specific architecture of mobile networks.

This post is a practical primer on how mobile networks route IP traffic: the PGW/SGW model, how mobile IPs differ from residential ones, why mobile users hit gateways in unexpected locations, and what this means for any application that geolocates or classifies mobile traffic.

Why Mobile Is Different

Wired internet is conceptually simple: your modem gets an IP from your ISP; your devices share it via NAT. The IP is fixed for hours or days. Geolocation is fairly accurate to your city.

Mobile is more complex:

  • Devices are highly mobile. Cells hand off as you move; sessions need to follow.
  • One IP per device isn’t economically feasible at carrier scale. CGNAT is universal.
  • Internal traffic is often IPv6 while external is IPv4 (via NAT64).
  • Roaming routes your traffic through gateways in unexpected countries.
  • Subscriber identity is on the SIM, separate from the IP — strong identification doesn’t need IP.

The result: mobile IPs are slipperier and less geographically meaningful than wired ones.

The 4G/5G Core Architecture

Modern mobile networks (LTE/4G and 5G) use a similar high-level architecture:

eNodeB / gNodeB

The cell tower’s base station. Talks radio to your phone.

SGW (Serving Gateway)

The gateway closest to where you currently are. Handles handoff between cells. As you move, you might switch SGWs while keeping the same session.

PGW (Packet Data Network Gateway)

The gateway between the mobile network and the wider internet. Your public IP is assigned here. PGWs are typically in major metro areas — one carrier might have only a handful of PGWs serving an entire country.

MME (Mobility Management Entity) / AMF (5G)

Handles control-plane things — authentication, session setup, mobility management. Not in the data path.

HSS / UDM

Subscriber database. Knows your SIM, your plan, your home network.

Internet

What everyone else sees.

The data path for your traffic:

Phone ↔ eNodeB ↔ SGW ↔ PGW ↔ Internet

Your public IP is assigned by the PGW. That’s the IP geolocation services see.

Why Your IP Geolocates to the Wrong Place

The PGW is the key. There are a small number of PGWs per carrier per country. Your traffic enters the internet from whichever PGW your session is anchored to.

Consequences:

City may be wildly off

You’re using your phone in Brisbane. The carrier’s PGW for Queensland is in Sydney. Geolocation says you’re in Sydney. The IP is correct; the geographic mapping is correct; you’re just not actually in Sydney.

Cross-country PGWs

A carrier without a PGW in a small country might route traffic through a PGW in a neighboring country. You’re in Luxembourg, geolocated to Brussels (where the carrier’s BGW is). Common in Europe.

Roaming routes home

When roaming internationally, traffic is often routed back to the home country’s PGW, then out to the internet. You’re in Spain on a US T-Mobile SIM; your public IP is American.

For geolocation accuracy on mobile, “country” is usually right (~95%) but “city” is much weaker (~50-70% in well-mapped markets).

CGNAT on Mobile

Mobile carriers universally use CGNAT. One public IPv4 address may serve thousands of subscribers simultaneously. The carrier maintains a NAT table mapping each subscriber’s internal IP and port to a shared external IP and port.

Implications:

  • Many users share one external IP. Blocking that IP affects thousands of legitimate users.
  • Port exhaustion can happen at peak load when the NAT runs out of available external ports.
  • Long-lived TCP sessions sometimes break when the NAT garbage-collects mappings.
  • Per-IP rate limiting is broken on mobile — you can’t tell users apart.

IPv6-First Mobile

A growing trend: mobile carriers run their internal core as IPv6, with NAT64 gateways for IPv4 destinations.

  • T-Mobile US has been IPv6 internally since 2012.
  • Reliance Jio (India) launched IPv6-first.
  • Major European carriers are increasingly IPv6-first.

For internet services, this means:

  • A meaningful fraction of mobile traffic arrives as IPv6.
  • IPv4 traffic from these carriers comes through NAT64 — the source IP is a shared NAT64 gateway IP.
  • Geolocation on the NAT64 IP shows the gateway’s location, not the user’s.

For your IPv6 readiness, see IPv6 deployment guide.

Wi-Fi Calling and VoLTE

Modern phones use IP for voice too:

  • VoLTE (Voice over LTE) carries voice as IP packets over the cellular network.
  • Wi-Fi Calling routes voice through your Wi-Fi connection back to the carrier core via an IPsec tunnel.

For the second one: even when you’re on Wi-Fi, your phone is still anchored to the cellular network for call routing. Voice traffic doesn’t behave like ordinary IP traffic.

This doesn’t usually matter for web/app traffic, but it’s why some things (cellular signal indicator, push notification reachability) work differently than you’d expect.

Detection Implications

For application developers, mobile traffic has specific patterns:

High false-positive rate for “different country” alerts

A user travels; their phone hits a roaming PGW; your fraud system says “user logged in from a new country!” Often a false alarm.

CGNAT means per-account rate limits, not per-IP

Per-IP rate limiting catches more legitimate users than fraudsters on mobile.

Mobile carrier ASN is a strong “is mobile” signal

If you classify by ASN, traffic from T-Mobile, Verizon Wireless, Vodafone, Reliance Jio, etc. is almost certainly mobile (regardless of what the User-Agent says). See detect mobile vs desktop.

Switch from Wi-Fi to mobile breaks sessions

The IP changes; sticky-session schemes lose state. Design for stateless or use server-side session IDs decoupled from IP.

Geolocation drift is normal

Mobile users’ geolocated location can move across cells, even staying still. Don’t make hard decisions based on geographic shifts of mobile IPs.

How Mobile ASNs Look

A few examples of major mobile ASNs in 2026:

  • AS21928 — T-Mobile US
  • AS22394 — Cellco / Verizon Wireless
  • AS6167 — Sprint (now T-Mobile-aligned)
  • AS3303 — Swisscom Mobile
  • AS12389 — Rostelecom Mobile
  • AS55836 — Reliance Jio India

These ASNs are well-known and stable. Maintaining a “mobile carrier ASN” list is straightforward. The Ip2Geo API returns ASN type inline so you don’t have to maintain the list manually.

5G and What It Changes

5G introduced architectural changes:

  • Service-Based Architecture (SBA) — Core network functions communicate via APIs, not protocols. Easier to scale and update.
  • Network Slicing — Carriers can run multiple “virtual” networks on the same physical infrastructure, each with different characteristics. A slice for IoT, a slice for fixed wireless, a slice for premium consumer.
  • Edge computing integration — 5G makes it easier for carriers to run application-level edge computing inside their network.
  • Lower latency — Aspirationally. Real-world 5G latency is often 20-50ms, similar to good LTE.

For application developers, most of this is invisible. The PGW/CGNAT/anchored-IP behavior continues. The lower-latency promises haven’t fully delivered for consumer apps but help for specific edge-computing use cases.

What This Means for Geolocation Services

Mobile traffic is where geolocation services have to make trade-offs:

  • Country accuracy stays high because PGWs are usually in the right country (modulo roaming).
  • Region/city accuracy drops because the PGW location ≠ user location.
  • ASN classification is essential — mobile ASN is what tells you “this is mobile” reliably.
  • Network type (mobile vs fixed) should come from ASN type, not from User-Agent.

A good provider returns the PGW’s location with the ASN type, so your application can decide how to use the data: “use country, ignore city for mobile.”

TL;DR

  • Mobile networks anchor your IP to a PGW — a metro-area gateway. Your IP shows the PGW’s location.
  • CGNAT is universal — thousands of subscribers share one public IP.
  • IPv6-first cores are increasingly common. NAT64 bridges to IPv4 destinations.
  • Roaming routes traffic through your home country’s gateway — mobile users abroad geolocate to the home country.
  • For application logic: use ASN type (“mobile carrier”) as the strong signal; don’t trust city-level on mobile; don’t use per-IP rate limits.
  • 5G changes the core architecture but the IP-layer behavior is mostly the same as 4G.

Mobile traffic is one of the major sources of “geolocation isn’t what you think it is” experiences. Once you understand the PGW anchoring and CGNAT layering, the patterns make sense. For the broader detection picture, see detect mobile vs desktop; for the NAT layer specifically, NAT and CGNAT. To classify mobile vs fixed traffic by ASN in your application, the Ip2Geo API returns the ASN type with every lookup.

Get Started

Convert IPs into accurate location data in milliseconds.

Sign up today and get 1,000 free monthly stored conversions, and discover why developers trust us for fast, reliable, and affordable IP conversions.