The telecommunication industry has always considered “monitoring mobile networks traffic” to be complex and expensive. The main reasons are that the mobile networks are quite spread out geographically, and many protocols (with various versions and specifications each) are used in the communication between the different types of nodes. One of the most prominent protocols is called GTP (GPRS Tunnelling Protocol, where GPRS is General Packet Radio Service) and it can be decomposed in two separate protocols:
- GTP-U – used to carry user-data traffic.
This is the application-level data traffic exchanged between the mobile phone and other Internet devices or sites.
- GTP-C – used to carry signalling within the core network.
Each time a mobile phone connects, disconnects, or roams around inside the network, the network generates messages between the involved nodes. Monitoring GTP-C is the key to determining the association between the user (i.e., the International Mobile Subscriber Identity or IMSI) and the assigned dynamic IP address within the mobile network. GTP-C also keeps track of much more information, such as the user phone number, the location (Cell ID and/or GPS coordinates), the phone model (the International Mobile Equipment Identity or IMEI), and the Access Point Name. But most importantly, GTP-C is used to negotiate Tunnel IDs, which are then used to transport user traffic. So GTP-C traffic state must be stored locally on the monitoring machine to keep the association between a user and the assigned IP address.
GTP is used in both UMTS and LTE. GTP version 1 is used in UMTS to establish Packet Data Protocol (PDP) contexts, and version 2 was introduced to support LTE networks and the EPS Bearer context.
In UMTS networks, the User Equipment (UE) must request a PDP context so the data session can be established. Right after the UE completes the Attach procedure (alerting the Serving GPRS Support Node – SGSN – that the UE has powered up), the UE requests a Primary PDP Context, which establishes the data session and allocates an IP address to the UE. This PDP Context will have a QoS (and other characteristics) associated with it based on the needs in the request. If the UE needs to have multiple data sessions, due to different characteristics, the UE requests a Secondary PDP Context activation.
In LTE, there are two types of data session setups: Default EPS Bearer, and Dedicated EPS Bearer. The first is established as part of the Attach procedure, and it supports a nominal QoS, which should be sufficient for application signalling. When the UE needs to establish a service, a Dedicated EPS Bearer will be established with the QoS requirements needed for the service.
Monitoring both types of networks requires dissecting the packets of the GTP protocol and extracting key Information Elements to correlate the transactions and keep track of sessions. This presents an extra challenge for the inter-RAT (Radio Access Technology) handover cases.
The system that is going to monitor all these details will have to tap the data on the UMTS or LTE links or both. The packets are directed to a packet entry module, where the lower layers are processed to direct the packet to the flow processor based on the standard IP 5-tuple (src IP, dest IP, src port, dest port, TCP/UDP). Packets with the same 5-tuple are processed by the same processor.
After choosing the flow processor, the message is classified as either GTP-C or GTP-U and sent into the processing chain as described below:
The first step is to decode the GTP-C packets according to the GTP specifications and extract the message type and the control IEs (Sequence Number, all the Tunnel Endpoint Identifiers, IMSI, MSISDN, etc.). The key to assembling messages in a transaction is the sequence number (a request and a response in the same transaction have the same sequence number). When a transaction is assembled, it is sent to the session processing module where the Tunnel Endpoint IDs are extracted, and monitoring sessions are created based on the TEIDs (Tunnelling End Identity). The session processing module handles the state machine for GTP-C and creates a table to facilitate directing GTP-U messages to the appropriate node where they should be handled. This would be the same node where the GTP-C packets were directed.
The GTP-U messages are decoded and the Tunnel ID is extracted. The Tunnel ID is matched into the Tunnel Endpoint ID table, and forwarded to the appropriate node, centralizing the processing of information received from various taps (GTP-C and GTP-U) into a single node to improve scalability. The tunneled layers are then decoded again and processed by their corresponding decoders/processors.
All types of handovers can be handled with this solution (inter-eNodeB, inter-MME, inter-MME/SGW, and most importantly inter-RAT). The GTP-C processing for the different RAT types and different flows are updated in the TEID table and thus the tunnelled traffic is processed correctly by the same node before and after handover.
This solution faces many challenges and many corner cases because of the complexity of mobile networks. The main challenge in implementing this solution is the sheer amount of data that goes through these links. Multiple separate processors need to run intelligently in parallel to be able to handle this amount of traffic in real time. The second challenge is the large number of links to tap into and the different type of traffic that goes on each. The logic that processes the GTP-C data changes when a certain type of link is monitored or not.
Implementing such a solution is quite costly to develop and to install but not impossible to achieve, and most mobile operators break the piggy-bank to have it installed. But in recent years, the tendency has gone towards open source in all software domains and the first baby steps are being taken to implement scalable real-time monitoring solutions.
For mobile operators, the technology behind GTP monitoring helps to ensure service availability, meet Quality of Service, and more. Northforge works on helping mobile operators monitor their GTP networks and improve the service offered to their subscribers. Let us know if we can help with your GTP monitoring needs.
By Fahed E.