15
Feb

my first eGTP test – take 3 – Creating Default Bearers

   Posted by: cristina_crow   in technical

As I was saying in a previous post, Bearers are structures that define a single QoS traffic between eNB – MME – SGW – PGW. They are created via GTP-C (control GTP) negotiation, and have effect on the actual traffic that flows between these entities (GTP-U – User plane). There 2 types of bearers: default bearers and dedicated bearers. While the default bearers are created by default during the Initial Attach procedure, simply stating that the UE is “logged in” the network (and usually no User plane traffic is permitted over these bearers), the dedicated bearers are created specifically when a particular type of application needs to send traffic over the network. If this happens, the network (here read PGW in correspondence with PCRF) looks at its QoS level. Should there be a TFT (associated to a dedicated bearer) already created for that application, the network simply uses that bearer to pass on those IP packets, otherwise it creates a new, dedicated, bearer, with a QoS specific to the needs of the application in question.

So… How is this “default bearer” created after all?

The most usual case is when the MME sends a Modify Bearer Request to the SGW. This message is a simple UDP packet, with destination port 2123, encapsulated as GTPv2. Its content looks like this:

- Flags: showing GTP version (2)

- Type of Message: “Modify Bearer Request”

- Length of Message: 30

- T-EID (Tunnel Endpoint Identifier) of the GTP-C on S11 (between MME and SGW)

- EPS Bearer ID

- F-TEID (Fully Qualified Tunnel Endpoint Identifier) which indicates the type of IP address (here it is IPv4), the type of interface where the bearer would take place (it is S1-U – S1 – User plane, the interface between the eNB served by the MME in question and the SGW in question)

** Why is this S1-U? Why this interface? Why a “U” interface? Because the purpose of the GTP-C is to negotiate the GTP-U part. Basically, via these GTP-C messages I am negotiating which are the GTP-U interfaces that will transfer the actual data. And, as MME is ONLY a GTP-C entity, it has the role of negotiating the bearers that will carry the traffic between the GTP-U entities, here eNB and SGW. So, the GTP-C passes through MME, while GTP-U does not. This is why I can see on the GTP-C message sent from MME to SGW the TEID of a S1 interface, rather than a S11 interface.

- F-TEID IPv4 – this is the IP address of the eNB, in this case 40.0.0.3

** This F-TEID IPv4 is the actual IP address that eNB will use in order to send data-plane packets flowing between UE and PDN. As the path of the GTP-U is between UE – eNB – SGW – PGW – PDN ( the MME only appears in the GTP-C flow), the F-TEID IPv4 address here should have layer 3 connectivity with the SGW IP address. I had a rough time today trying to understand why on earth my GTP-U traffic disappeared, while I was having the eNB and SGW IP addresses on two different subnets and no router to route packets from one subnet to another – smarty, I know :P

The Modify Bearer Request packet looks something like this:

If the MME has been a good kid (and the UE also), the SGW acknowledges its request and responds with a Modify Bearer Response packet having as Cause : Request accepted. The fields of this packet are the following:

- Flags – indicating the GTPv2 and some other stuff

- Cause – has the IE (Information Element) type, which is 2 here, Cause being Request Accepted and the ID of the Cause is 0 (it should be different than 0 if the request were not accepted)

- Bearer Context – this indicates that the SGW reserved resources for a new context (default one) and instructs the eNB and the PGW to do the same; this field contains the

- – -  EPS Bearer ID : 5

- – - Cause subfield : indicates “Request accepted”

- – - F-TEID: type of IPv4, the interface is S1-U (S1 – User plane between eNB and SGW) and the F-TEID IP is the IP address of the SGW (40.0.0.2)

Basically this message confirms the creation of the Default Bearer, the reservation of the network resources for the traffic flowing over this bearer (if any). The user is officially logged in the network and has the first, most simple and non-priviledged session with the PDN.

The Modify Bearer Response packet looks something like this:

Tags: , , , , , , , , , , , , , , , ,

This entry was posted on Monday, February 15th, 2010 at 11:55 pm and is filed under technical. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

6 comments so far

andrei rusan
 1 

nice post ;)
de ceva zile ma intreb de ce EPS Bearer ID e intotdeauna 5? any hint? :P

February 16th, 2010 at 11:19 am
 2 

Nu as putea zice :P Tre sa mai intreb, dupa cateva zile de LTE nu sunt chiar guru…

February 16th, 2010 at 11:25 am
 3 

so: I have asks the gurus – they say that TS 23.401 specifies that (I haven’t looked it up yet) bearer ID should be between 5 and 15 (including) and…as we are looking at ze first bearer, this guy has ID == 5 :D voila!

February 16th, 2010 at 11:38 am
 4 

Really nice post! I has been looking for it several times!
Also the enthusiasm grows when you see ue, eNodeB, MME, SGW, PDNGw as kids ;-)

February 16th, 2010 at 12:49 pm
 5 

@Rakesh: wow. Thanks for the comment. Appreciate it :)
—sorry – I am in hurry, in my head the name was actually correct. please excuse the typo :”>

February 16th, 2010 at 12:52 pm
andrei rusan
 6 

tks pt dezlegarea enigmei cu valoarea 5 ;) adding this post to my bookmarks pt asta ;)

February 16th, 2010 at 2:41 pm

Leave a reply

Name
Mail (will not be published)
URI
Comment