my first eGTP test – take 3 – Creating Default Bearers

Posted: February 15, 2010 in technical
Tags: , , , , , , , , , , , , , , , ,

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

** 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 😛

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 (

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:



  1. andrei rusan says:

    nice post 😉
    de ceva zile ma intreb de ce EPS Bearer ID e intotdeauna 5? any hint? 😛

  2. 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 😀 voila!

  3. Rakesh says:

    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 😉

  4. andrei rusan says:

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

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s