Stingray SG can detect GTP-C traffic and extract subscriber parameters for the subscriber's IP and login binding from the GTP session creation requests. GTP-C versions 1 and 2 are supported. GTP support is enabled by parameters in fastdpi.conf:
# bras_enable=1
#
# GTP processing mode
# Values:
# 0 - (default) GTP processing is disabled
# 1 - [bind mode] In this mode, BNG/BRAS processes GTP-C packets of the session start and end,
# binding the IP-address issued to the subscriber with the login (IMSI or MSISDN is used as the login).
# At the end of the session, the login-IP connection is broken.
# 2 - [auth mode] authorization of GTP sessions is enabled. In this mode, BNG/BRAS processes GTP-C session start and end packets.
# Upon successful start of the GTP session, BRAS sends an L3 authorization request to PCRF,
# transmitting the subscriber's IP address, IMSI, MSISDN, IMEI and other parameters.
# At the end of the session, the login-IP connection is broken.
# SSG does not terminate GTP sessions, all GTP-C packets are dropped.
# 3 - [passive bind mode] Similar to mode 1 [mirror bind mode], but GTP-C packets are not dropped.
# The SSG should be in a gap on the S11 or S5 interface.
# 4 - [passive auth mode] Similar to mode 2 [mirror auth mode], but GTP-C packets are not dropped.
# The SSG should be in a gap on the S11 or S5 interface.
#bras_gtp_mode=0
Creating a session (bind IP-LOGIN) on responses:
#Response to Create PDP Context Request for GTPv1:
Create PDP Context Response
#Response to Create Session Request for GTPv2:
Create Session Response
Deleting a session (bind IP-LOGIN) on responses:
#Response to Delete PDP Context Request for GTPv1:
Delete PDP Context Response
#Response to Delete Session Request for GTPv2:
Delete Session Response
#Response to Delete Bearer Request for GTPv2:
Delete Bearer Response
The Stingray SG connection point is set by the parameter:
# Where the SSG is connected (which GTP-C is fed to the SCAT)
# Valid values:
# 0 - S5 protocol (SGW <-> PGW). This is the default
# 1 - S11 protocol (MME <-> SGW)
bras_gtp_mountpoint=0
In mirror mode (bras_gtp_mode 1 or 2), SSG drops all incoming GTP-C packets.
In passive mode ( bras_gtp_mode 3 or 4) SSG passes GTP-C traffic through itself.
You should also set the maximum size of active GTP-sessions internal database in fastdpi.conf
# Max number of concurrent GTP-sessions
# We recommend setting this parameter 1.5-2 times more than the actual max number of sessions
# Default value: 10000 sessions, minimum value: 10000
#bras_gtp_session=10000
After receiving a request to create a GTP-C session, SSG waits for a packet of successful session creation. Only at this moment, upon receiving a successful response and issuing an IP address to the subscriber, connects the login and IP. The response timeout is set by a parameter in fastdpi.conf:
# Max time to wait for a response to a GTP session creation, seconds
# Default = 3 seconds
#bras_gtp_pending_timeout=3
IMSI or MSISDN can be used as a login, which is set by a parameter in fastdpi.conf:
# What is the subscriber's login for GTP:
# 0 - IMSI (by default)
# 1 - MSISDN
#bras_gtp_login=0
To detect GTP-U, you have to enable tunnel parsing:
# enable the tunnels parsing by dispatchers check_tunnels=1 # enable the detection and parsing of GTP-U detect_gtp_tunnel=1
When you enable parsing of GTP-U tunnels, SSG will work with the real IP-address of the subscriber, and not with the IP-address of the tunnel. That means that it becomes possible to apply filtering, services and policing to the GTP-subscriber.
SSG does not terminate GTP-U tunnels.
The internal database of GTP-sessions can be controlled with a special set of CLI-commands.