GTP-C vs GTP-U

[hjazz]

Hi,

I'm a little confused about whether GTP-C messages are sent/received between GSNs in tunnels like GTP-U messages are in a GPRS network. The tunnel ID field is present on the GTP header, but how can GTP-C messages know the tunnel ID when these messages are used for the purpose of creating tunnels?

Thank you.

[WMBrown]

Hi,

GTP-U is, in effect a relatively simple IP based tunnelling protocol which permits many tunnels between each set of end points. When used in the UMTS, each subscriber will have one or more tunnel, one for each PDP context they have active plus, possibly separate tunnels for specific connections with different Quality of service requirements.

The separate tunnels are identified by a TEID (Tunnel Endpoint Identifier) in the GTP-U messages, which should be a dynamically allocated random number. If this random number is of cryptographic quality, then it will provide a measure of security against certain attacks. Even so, the requirement of the 3GPP standard is that all GTP traffic, including user data should be sent within secure private networks, not directly connected to the Internet.

[hjazz]

So are GTP-C messages tunnelled from GSN to GSN in the same sense that GTP-U messages are?

[Raves]

GTP-U are Network Domain Security for IP (NDS/IP) as specified in draft TS 33.210 shall also be used for protection of SIP messages in IMS.

Technically this is fully possible, but it is at odds with the current assumption on how NDS/IP will be used. The problem is that SIP in IMS is carried within GTP-U messages, and that NDS/IP currently do
not protect GTP-U.
Now it would be fairly easy to change TS 33.210 to also accommodate GTP-U. However, with the normal IPsec processing rules it will not be possible to inspect the contents of GTP-U to discriminate between SIP signalling contained within GTP-U and other user data. NDS/IP uses IPsec in its intended
way, and consequently there is no easy way to separate SIP signalling from other data in GTP-U. So unless one wants to extend the IPsec (NDS/IP) processing rules to inspect the payload contents of the
packets one is left with the choice of either protect all of GTP-U or nothing. It must be said that it is not a good idea to change the processing rules since the performance overhead of inspection all GTP-U packets would likely be formidable.

[irishjohn]

it must be frustrating when you ask a question and get 2 answers to two different questions.
Anyway, the answer to your question is that GTP-C is just the control protocol used to set up the user tunnels. It is a common misconception in the GPRS world that tunnels are also created for GTP-C messaging.

[jaahas]

Actually GTP-C gets allocated its own TEID by both ends of the connection so yes it is a tunnel of its own accord. Note also that the GSNs may (and some vendors do) use different IP addresses for GTP-U and GTP-C.

But you are correct in stating that GTP-U is used for user plane tunnelling and GTP-C is used for control plane (setup, teardown and modification of the user plane's parameters mainly).

GTP-C is used for some other tasks as well, but 99% of it is related to individual user plane control.

Both use UDP and fixed port numbers (2123 for GTP-C and 2152 for GTP-U). User's are separated based on the TEID (which is unique per direction).

[irishjohn]

jaahas, your reasoning is based on the fact that the GTP-C protocol uses a TEID. However in the case of GTP-C the TEID is really a session ID. As hjazz pointed out in his original question the initial GTP-C message is sent from a source to a destination without the existence of any tunnel. When the reply comes back the two endpoints have exchanged identifiers for their continuing conversation. These identifiers should be thought of as session IDs. The designers of this protocol wanted to use the same header for both the control and user part of the tunnel protocol - hence the confusion. In similar protocols such as GRE, this confusion does not arise since the headers for the control protocol and user protocol are different.
The user data is transported through the GTP-U tunnel - it is actually passing through a tunnel. The control messages of GTP-C are not being tunneled as they originate and terminate at the tunnel endpoints.

[jaahas]

OK. Point noted about tunnel vs. "session" in the regular PDP context activation as there is no user data being tunneled, rather only signalling.

Never thought of it that far, but you are correct that there's nothing occurring "on top of" GTP-C, thus there is no tunnelling, just sessions. Hmm. should we try to get a CR through in 3GPP to change TEID in GTP-C messages to SEID?

Regs, Jarkko

[jaahas]

Heh. Just read the original question and the last part seems unanswered.

The answer is that neither end knows the TEID for a given user before PDP context (i.e. GTP-U tunnel) activation. The TEIDs are allocated as a random number for each tunnel _during_ the context activation.

The user has a unique ID (the IMSI), which is given to the GGSN during the context activation to identify the user (for charging purposes for example). The TEIDs is used after the initial context activation as the tunnel ID linked to a user ID within the SGSN and GGSNs.

[mungo]

I've got some questions about GPRS... I've acquired some Gn interface traffic (of GPRS), and now I want to measure some stats for different tunnels created on this interface. But the problem is that I don't have all the signalling messages used to create PDP contexts which are presently active in the trace, and thus I don't quite know which TEID correspond to which tunnel. My question is:

1) How do I filter traffic for each tunnel (in both directions). I know that tunnels in each node is identified by the IP address, port number and TEID (as per 3GPP specs). But I'm actually confused about how the endpoints identify a tunnel. I mean if e.g SGSN is receiving a tunnel traffic, does it recognize the tunnel by GGSN's IP address,source port and TEID (that it assigned to GGSN) , and how is the same tunnel identified at the GGSN? Please clarify with some example...

2)Is it possible for me to filter the traffic for each mobile user communicating over the Gn interface. If yes then how ?

[jaahas]

You need to know the user plane tunnel endpoint IP-address of the SGSN and the TEID that the SGSN has allocated to see uplink traffic (Terminal to Internet). The UDP port never changes.

To see downlink traffic, you need to filter based on the GGSNs IP address and the TEID it allocated for the user in question.

he port numbers are always fixed and the same for all users (2123 for control plane and 2152 for user plane).

I'll try to ASCII-graph it:

SGSN......................................................GGSN

User1:
IP:1.2.3.4...............................................1.2.3.10: IP
UDP:2123.................GTP-C.......................2123: UDP
TEID: 123<------------------------------>332: TEID

IP:1.2.3.5................................................1.2.3.11: IP
UDP:2152................GTP-U.........................2152: UDP
TEID: 4242<------------------------------>665: TEID

User2:
IP:1.2.3.4................................................1.2.3.10: IP
UDP:2123...............GTP-C.........................2123: UDP
TEID: 128<------------------------------>314: TEID

IP:1.2.3.5...............................................1.2.3.11: IP
UDP:2152................GTP-U.......................2152: UDP
TEID: 4443<------------------------------>7722: TEID

As you can see, the IP addresses for the tunnels can be different for GTP-C and GTP-U (often not the case though) and the IP-addresses for two different user planes can be either the same or different depending on which sub-unit within and SGSN or GGSN the user happened to be allocated to.

So how do you know, which IP's and TEIDs are used for a given user? You have to look at the PDP context activation requests for your user (Based on IMSI) to see the SGSN's allocated IP's and TEIDs for the particular tunnel. Then look at the corresponging response from the GGSN (destined to the GTP-C IP and TEID that the SGSN defined in the original request) to see the GGSN's IP addresses and TEIDs for the tunnel. The easiest filter in wireshark is gtp.imsi

The SGSN's tunnel endpoint IP address and tunnel ID can be seen in the PDP context activation request sent by the SGSN.

The GGSN's tunnel endpoint IP address and tunnel ID can be seen in the PDP context activation response sent by the GGSN to the SGSN.


Regs, Jarkko

[mungo]

WoW! Thanks Jarkko ! That was a great help indeed. Let me recapitulate here what you have taught me, please let me know if I'm wrong somewhere: To recognize the user traffic in uplink and downlink, I ought to get GTP-U address of SGSN and TEID Data I(advertised to GGSN in create PDP context request) for filtering downlink traffic, and GTP-U address of GGSN and TEID Data I(advertised to SGSN in create PDP context response) for filtering uplink traffic. I hope I'm right till now ?

But suppose I have a real traffic trace. And the initial signalling message are not caught in the traffic, when I put my logger on, for some tunnels. Is there still a way by which I can filter out the traffic for a user in both directions ?

Also could you please point out resources to learn more about Gn interface(having such illustrative examples, that you have drawn) ?

[jaahas]

You are correct in your understanding.

The answer to your follow-on question is: No unless you know the end-user's allocated IP address and filter based on that (gtp.user_ipv4 in wireshark).

The endpoint address might be the better choice for filtering in some cases since the user can have secondary PDP-contexts (i.e. same IP, but different QoS), where the TEID would be different for the same user with the same session and same IP address. To complicate even further, a multiple users could theoretically have the same IP address as well if they for example use private addressing and access separate corporate networks that are isolated from one another.

As to where to get more data, sorry. I don't know of a single book that would describe Gn signalling properly (some claim to do so and "properly" being a relative term). Even less if you include Iu-PS and Gb (which you would have to if you wanted to properly understand handovers). Some of the books out there have horrificly false information and understanding even though Gn is quite simple. There's not that much more going on than you see in those two messages. A bit, but not much.

Then again, the 3GPP specs aren't all that bad to read so going there would definitely help. 3GPP Specs 23.060 and 29.060 might be one start point. The 23 gives you the idea, 29 gives you the protocol spec. For Release 5 of these specs, here's the links Specs 23 Series and Specs 29 Series

I train this stuff for a living as a self employed trainer, that's why these basics are down pretty well "off the back of the head".

Regs, Jarkko

[mungo]

Thanks Jarkko. Now if I want to get some useful statistics out of the Gn interface traffic, I should filter the traffic by gtp.user_ipv4 i.e based on IPs in the payload of GTP ? But I guess the mobile IPs also change very fast...isn't it ? I have also got some user side traffic for my end mobile, captured at my handset for almost 10 minutes, and I can see many different IPs(other than that of wap gateway proxy) in that trace. So how do I keep track of different IPs of the same user?

[jaahas]

The Mobile's IP address changes every time you open a PDP context since in practise all Access Points defined in the GGSN for consumer use are dynamic on nature (Think simple DHCP).

This behaviour is worsened dramatically with BlackBerry's and iPhone (post 3.0 SW) since they employ a controversial fast idle behaviour, where they disconnect the PDP context after some seconds of idle time.

So you're back to looking at the PDP context activation requests and filtering for the IMSI (which never changes as it's your "real" phone number) if you want to get statistics on a particular user via Gn monitoring.

Regs, Jarkko