GigaSMART GTP and CUPS Correlation
Required License: GTP Filtering and CUPS Correlation
Supported Devices: GigaVUE-HC3 Gen 2
Refer to Supported GigaSMART Operations for more details on the devices that support GigaSMART operations.
The GigaSMART GTP application correlates traffic based on mobile subscriber IDs in the packet data networks of service providers. It provides a mechanism to filter and forward session traffic for subscribers to tools. GTP and CUPS correlation assists mobile carriers in debugging and analyzing GTP traffic in their 3G/4G networks.
Note: For Generation 3 cards, you can use Flow Sampling with sampling rate as 100% to achieve the same behavior as flow filtering.
GPRS Tunneling Protocol (GTP) is an IP/UDP-based protocol that carries mobile data across service provider networks. The protocol is used in General Packet Radio Service (GPRS) networks such as: Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), and Long Term Evolution (LTE). The protocol encapsulates user data that passes through the core network and carries subscriber-specific signaling traffic. |
GTP includes both control plane (GTP-c) and user-data plane (GTP-u) traffic. To gain an accurate view into the subscriber’s session, GTP tunnels are used to correlate the subscriber-specific control plane and user-data plane traffic. A GTP session is the minimum unit of GTP and CUPS correlation consisting of one control and multiple user tunnels. All GTP traffic belonging to the same session is forwarded to the same tool port. |
Using GTP and CUPS correlation, you can filter, replicate, and forward specific subscriber sessions to specific tools by correlating the subscriber IDs that are exchanged as part of the control sessions to the corresponding tunnel IDs (TEIDs) that are part of the user-data plane traffic. |
GTP and CUPS correlation provides the following:
stateful filtering based on subscriber IDs (IMSI, IMEI, and MSISDN) |
stateful filtering based on GTP version or EPC interface |
stateful correlation of GTP-c with GTP-u traffic |
correlation of subscriber ID with corresponding tunnel ID |
forwarding of the subscriber-specific control and user-data plane traffic to a tool or group of tools |
It supports 12 million GTP subscriber sessions for GigaVUE‑HC3 nodes |
option to combine with GigaSMART Load Balancing to load balance GTP traffic to a set of tool ports. For information on GTP load balancing, refer to stateful load balancing in the section GigaSMART Load Balancing. For examples of GTP load balancing, refer to GTP Correlation Configuration Examples. Starting in software version 4.6, GTP load balancing in a cluster is supported for GTP flow filtering. For an example of GTP load balancing in a cluster, refer to GigaSMART GTP Whitelisting and GTP Flow Sampling. |
Starting in software version 4.5, a GigaSMART group (gsgroup) associated with GTP applications can have multiple GigaSMART engine port members (e ports), up to four, forming an engine group. Refer to GTP Scaling.
Licensing Requirements
-
For GTP flow sample with the rule percentage (0 or 100), the GTP_MAX license is required.
-
For GTP flow sample with the rule percentage in all ranges (between 0 to 100) or for GTP Whitelist, the GTP_MAX and FVUE licenses are required
-
For GTP flow filtering, the GTP_MAX license is rquired. The GTP flow filtering is supported only on Gen 2 devices.
GTP stateful filtering supports filtering of GTP sessions based on the following subscriber IDs:
Component |
Description |
imsi |
The International Mobile Subscriber Identity (IMSI) is a number that identifies a subscriber of a cellular network. It is a unique identification associated with all cellular networks. An IMSI is usually a 15 digit number, associated with GSM, UMTS, and LTE network mobile phone users. |
imei |
The International Mobile Station Equipment Identity (IMEI) is a number, usually unique, that identifies 3rd Generation Partnership Project (3GPP), for example, GPRS, LTE, as well as Integrated Digital Enhanced Network (iDEN) mobile phones, and some satellite phones. The IMEI identifies the device, but has no permanent relationship to the subscriber. Instead, the subscriber is identified by transmission of an IMSI number, stored on a SIM card. |
msisdn |
The Mobile Station International Subscriber Directory Number (MSISDN) is a unique number that identifies subscribers in a GSM or UMTS mobile network. This numbering plan is defined in the ITU-T recommendation E.164. The maximum length of an MSISDN is 15 digits. |
In addition to filtering on subscriber IDs, you can optionally filter on GTP version (v1 or v2) or Evolved Packet Core (EPC) interface. Filtering on the EPC interface allows traffic to be segmented for a given interface.
The supported interfaces for EPC filtering are as follows:
Gn/Gp |
S11U |
S11/S1-U |
S5/S8 |
S10 |
S2B |
When filtering on EPC interface, you do not also need to specify version, as the version is implied.
To create maps using GTP, specify a Second Level Flow Sample map and select GTP for the rule. When adding a map rule, you can specify the following:
subscriber IDs (IMSI, IMEI, or MSISDN) |
number of digits. The maximum number of digits for the IMSI or MSISDN value is 15. The maximum number of digits for the IMEI value is 16. To specify the prefix for IMSI, IMEI, or MSISDN, you can use a wild card character or a digit string followed by a wild card character. |
map comment to label the purpose of a rule or the type of traffic covered by a rule |
GTP version 1 or version 2 (refer to 1) or EPC interface Gn/GP, S5/S8, or S10, S2B, or S11/S1U (refer to 2) |
Note: In a map, version and EPC interface cannot be specified in the same flowrule, but they can be specified in different flowrules.
Note: The maximum number of GTP flowrules is 32 per map.
For examples of filtering on GTP version, refer to GigaSMART GTP and CUPS Correlation.
1 | GTP Version |
2 | GTP EPC Interface |
Each GTP session has one control tunnel and one or more user tunnels. All the tunnels are correlated together into a session. Packets belonging to the same session will be forwarded to the same tool port. Refer to the following figure.
In a second level map, the following can be specified:
one tool port—packets from one subscriber (same subscriber ID), from one or more GTP sessions, will be forwarded to the same tool port. |
multiple tool ports—packets from one subscriber (same subscriber ID), from multiple GTP sessions will be correlated and forwarded to same tool port. Using load balancing, GTP traffic that matches the same map but belongs to different subscribers can be load balanced to multiple tool ports. |
GTP is used at multiple interfaces by multiple devices in the core network. GTP stateful correlation is implemented for the following interfaces:
Gn/Gp (for GPRS). The Gn interface is between SGSN-GGSN only. |
S5/S8 (for LTE) |
S1-U, S11U and S11 (for LTE) |
S10 (for S1-based mobility) Refer to Conditional S10 Support |
S2B |
Support for interfaces for both GPRS and LTE networks includes the handovers between the different networks. Refer to the following figure.
For LTE networks, the following GTP traffic will be correlated to the specific mobile subscriber and routed to the same tool port:
GTP-c traffic on the S11 interface between MME and S-GW |
GTP-u traffic on the S11u interface between MME and S-GW |
GTP-u traffic on the S1u interface between eNodeB and S-GW |
GTP-c traffic on the S10 interface between MMEs |
GTP-c traffic on the S5/S8 interface between S-GW and P-GW |
GTP-u traffic on the S5u interface between S-GW and P-GW |
GTP-c traffic on the S2b interface between P-GW and ePDG |
GTP-u traffic on the S2b-U interface between P-GW and ePDG |
In order to correlate GTP-c and GTP-u traffic running on different interfaces, you must tap into the correct interfaces, as follows:
Gn/Gp—one interface runs both GTP-c and GTP-u |
S5/S8—one interface runs both GTP-c and GTP-u |
S1u, S11u, and S11—these three interfaces have to be tapped at the same time to get both GTP-c and GTP-u to perform the correct correlation. |
S2b-C and S2b-U interfaces needs to be tapped to get GTP-c and GTP-u traffic for correlation. |
For examples of filtering on GTP interface types Gn/Gp, S5/S8, S1 and S11, refer to GigaSMART GTP and CUPS Correlation.
The following table outlines support for the S10 interface. In the table, No means not supported, Conditional means there is limited support of the S10 interface.
S10 |
Support |
Forward Relocation Request/Resp |
Conditional; IMSI must be present in Forward Relocation Request |
Forward Relocation Complete Notification/Ack |
Conditional; IMSI must be present in Forward Relocation Request for Forward Relocation Complete Notification/Ack to be supported |
Context Request/Response and Ac |
Conditional; IMSI must be present |
Identification Request/Response |
No |
Forward Access Context Notification/Ack |
No |
Relocation Cancel Request/Response |
No |
Configuration Transfer Tunnel |
No |
To access GigaSMART within GigaVUE‑FM, access a device that has been added to GigaVUE‑FM from the GigaVUE‑FM interface. GigaSMART appears in the navigation pane of the device view on supported devices. Refer to Access GigaSMART from GigaVUE‑FM for details.
In prior software versions, the complete GTP session timeout was eight hours. Starting with software version 4.2, the GTP session timeout is configurable, with eight hours as the default.
To configure the GTP session timeout, do the following:
1. | From the left navigation pane, go to System > GigaSMART >GigaSMART Groups > GigaSMART Groups. |
2. | Click New to create a new GigaSMART Group or Edit to modify an existing one. |
3. | Under GigaSMART Parameters, go to GTP Flow. |
4. | Enter the timeout in the Timeout field. The following figure shows an example where the timeout value is set to 60. |
5. | Click Save. |
The GTP session timeout disconnects a GTP session if it has been inactive for the timeout value. The timeout can be configured as an integer from 1 to 6000, in increments of 10 minutes. The default value is 48, which is 480 minutes, which is 8 hours.
One virtual port can have multiple maps, and for each map, you can add multiple flow rules with different filtering attributes. The priorities for flow rules are as follows:
a rule with a drop action has a higher priority than a rule with a pass action |
for the same pass or drop action, the priorities are IMSI, IMEI, or MSISDN in descending order |
In a GTP session, if one IMSI, IMEI, or MSISDN rule is matched, the map is matched. For example, if any one of the following matches any rule shown in the following figure, map1 (which is a Second Level Flow Filter map) is matched:
In addition, in one map, all drop rules are matched first and all pass rules are matched next.
For example, in a GTP session, if an IMSI matches the first rule in map1 and an IMEI matches the second rule in map1, because the drop rule has higher priority, the packet will be dropped:
If multiple maps are matched, the map with the highest priority will be considered for further processing. For example, the 3 shows the rule for map1 while the rule 1 shows the rule for map2. In a GTP session, if an IMSI matches the first rule in map1 and an IMEI matches the first rule in map2, because map1 has higher priority, the packet will be passed.
3 | Rule in Map1 |
4 | Rule in Map2 |