Route traffic on the value of any GTP element — not just IP or APN.
Because GTP Proxy parses every GTP-C message natively, it can make a routing decision the instant a session is established, based on anything inside it — radio access type, serving network, location, subscriber range, QoS class — alone or combined.
# GTP Proxy routing rules — illustrative syntax
route_rule "NB-IoT roamers via Australia":
match CreateSessionRequest:
RAT-Type == NB-IoT
Serving-Network.MCC == 505 # Australia
then:
route-to: iot-core-pool
apply-qos: iot-low-power-profile
charging-profile: iot-roaming-wholesale
route_rule "Emergency sessions":
match CreateSessionRequest:
Bearer-Context.ARP.priority-level <= 2
or present(Emergency-Info)
then:
route-to: priority-core-pool
A subscriber's NB-IoT sensor roams onto a partner network in Australia. The moment it attaches, its Create Session Request carries RAT-Type = NB-IoT and a Serving Network Information Element with MCC 505. GTP Proxy matches that combination before the session ever reaches your general-purpose core — and routes it to a dedicated low-power IoT core pool, with an IoT-appropriate QoS profile and a wholesale roaming charging profile applied automatically. The roaming partner changes nothing on their side; the decision happens entirely on your GTP Proxy, per session, in real time.
The same mechanism generalises: steer any RAT type (2G/3G/4G/5G/NB-IoT/eMTC) to capacity-appropriate infrastructure, give emergency or high-priority ARP sessions a protected path, isolate traffic from a specific APN or IMSI range for troubleshooting, or apply differentiated policy per roaming partner — all from Information Elements already present in the signalling, without touching endpoints.