MVNO gateway steering on shared APNs.
Several MVNOs riding the same host network's RAN often share one APN name from the handset's point of view — most commonly IMS, the APN every VoLTE call rides on. Each MVNO still needs its own subscriber traffic handed to its own GGSN/PGW for billing, policy, and control.
# GTP Proxy routing rule — illustrative syntax
route_rule "MVNO A — shared APN steering":
match CreateSessionRequest:
APN == "ims" # shared sponsor APN — VoLTE's IMS APN
IMSI.MNC == 88 # MVNO A's own MNC, riding sponsor's RAN
then:
route-to: mvno-a-ims-pgw-pool
charging-profile: mvno-a-wholesale
Rather than provisioning a separate APN per MVNO — which the sponsor's core, DNS, and device fleets all have to support — GTP Proxy reads the IMSI (MNC, or an assigned IMSI range) on the shared-APN Create Session Request and routes each MVNO's sessions to that MVNO's own gateway pool automatically.
The most common real-world case is IMS, the APN every VoLTE call rides on: a sponsor network hosts several MVNOs' voice traffic on one shared IMS APN, and GTP Proxy steers each MVNO's IMS sessions to its own IMS/PGW pool by IMSI/MNC — without touching the APN a single handset is provisioned with, and without the sponsor splitting its own IMS core per MVNO.
The same shape generalises to any shared-APN partner relationship — wholesale data APNs, IoT APNs shared across enterprise customers — wherever one APN name serves multiple billing/policy owners underneath.