Posts Tagged ‘default bearer’

Helloooo, agaaainnn!!! Long time no see, 4G

Let’s have a short (very short) talk about this DAF thinggie. DAF stands for Dual Address Bearer and it is a flag only set in the Create Session Request message, sent from the MME to the SGW, over the S11 interface. Details about this funky flag are in TS 23.401 (Section E-UTRAN Initial Attach and Section 5.3.1 IP Address Allocation) and in TS 29.274 (Table 7.2.1-1 Information Elements in Create Session Request) and…might be in other TSs also, but I have no idea about those 😛

So, when and why we do use this flag? Mwell, TS 29.284 says the following:

DAF – Conditional :  Dual Address Bearer Flag: This flag shall be set to 1 when the UE requests a PDN type IPv4v6 and all SGSNs which the UE may be handed over to support dual addressing. This shall be determined based on node pre-configuration by the operator.

So, this flag is an indication sent from the MME to the SGW, telling the SGW at the moment of the Initial Attach procedure: Hey! you know what? My mobile device supports dual-stack. You can assign it at once, on the same bearer, both an IPv4 and an IPv6.

Also, if the UE moves from a 3G coverage to a 4G coverage (the definition above says the other way around, but logic tells me that the MME actually sends a Create Session Request when it is a _target_ MME, therefore when the UE moves from a 3G to a 4G network), doing an MME relocation, SGW relocation handover procedure, our MME would says the following to its fellow SGW: Dear SGW, my mobile device has just arrived here from a 3G network, more specifically from an SGSN that supports dual addressing. So don’t worry that I am asking for both an IPv4 and IPv6 addresses for the same bearer for this UE.

Now, there are several rules when using or not this DAF. The general rule is to set it, which seems to be the default rule in the 4G network context.

The only case when, in a 4G context we do NOT set this flag is when the interface between the SGW and the PGW (the S5/S8 interface) runs PMIP, and not GTPv2 (as S11 does).

So, usually, in this most common case, the UE that supports dual-stack will ask for a single default bearer, having an IPv4v6 dual-stack type of address. If the MME is running in a full 4G environment or it is aware that all SGSNs to which the user may handover to also support dual-stack and the MME is aware that the S5/S8 interface runs GTPv2, then the MME will set the DAF flag and hopefully the PGW also supports dual-stack, our dear UE will get an IPv4v6 address, actually meaning that it will get 2 IP addresses (one IPv4 and one IPv6) for the same, single, default bearer to this  APN.

But, even if the UE says it supports dual-stack, but the MME considers, for some reasons it has (it is aware of non-compatible SGSN, or it knows about S5/S8 running PMIP or whatever), not to set the DAF flag, then the UE’s type of address remains to be decided by the PGW….as it follows:

The PDN GW takes into account the received PDN type, the Dual Address Bearer Flag and the policies of operator when the PDN GW selects the PDN type to be used as follows. If the received PDN type is IPv4v6 and both IPv4 and IPv6 addressing is possible in the PDN but the Dual Address Bearer Flag is not set, or only single IP version addressing for this APN is possible in the PDN, the PDN GW selects a single IP version (either IPv4 or IPv6). If the received PDN type is IPv4 or IPv6, the PDN GW uses the received PDN type if it is supported in the PDN, otherwise an appropriate error cause will be returned. The PDN GW allocates a PDN Address according to the selected PDN type. If the PDN GW has selected a PDN type different from the received PDN Type, the PDN GW indicates together with the PDN type IE a reason cause to the UE why the PDN type has been modified.

What about the UE. What should it do after getting an IP?

After the Attach Accept message and once the UE has obtained a PDN Address, the UE can then send uplink packets towards the eNodeB which will then be tunnelled to the Serving GW and PDN GW. If the UE requested for a dual address PDN type (IPv4v6) to a given APN and was granted a single address PDN type (IPv4 or IPv6) by the network with a reason cause indicating that only single IP version per PDN connection is allowed sent together with the PDN type, the UE may request for the activation of a parallel PDN connection to the same APN with a single address PDN type (IPv4 or IPv6) other than the one already activated. If the UE receives no reason cause in step 18 in response to an IPv4v6 PDN type and it receives an IPv6 Interface Identifier apart from the IPv4 address or in the PDN Address field, it considers that the request for a dual address PDN was successful. It can wait for the Router Advertisement from the network with the IPv6 prefix information or it may send Router Solicitation if necessary.

Now, the applications on the UE must know which type of socket to create. They can either create an IPv4 or an IPv6 socket and choose among the available IP addresses.


TS 29.061, more precisely the Interworking between PGW and PDN, sections 11 to 13.

TS 23.401, sections 5.3.1 – IP Address Allocation, 5.3.2 – Attach Procedure

It seems that:

1. an UE can simultaneously connect to multiple APNs;

2. an UE can have multiple default bearers per APN connection: for example, one for IPv4 and one for IPv6;

2.a) 2 default bearers per APN connection are possible when the MME does NOT set the Dual Address Bearer Flag; this way, the MME forces the sending of separate IPv4 and IPv6 requests for PDN connectivity;

2.b) if the MME sets the Dual Address Bearer Flag, then it can send a request with dual-stack IPv4v6 and the APN can provide both of these IP addresses at once – this means that there are 2 IP addresses (one IPv4 and one IPv6 ONLY one of each type !) for a SINGLE default bearer;

3. Allocation of these IP addresses to the UE can happen from a local PGW pool or from the PDN. In the later case, the Create Session Response message sent from the PGW to the SGW (and further on to the MME) has PAA =, following the later completion of this address;

3.a) If the PGW has nothing to do with the further negotiation of the IP addresses, we are talking about a direct transparent access IP allocation; the PGW is just a proxy;

3.b) If the PGW is actively (protocol dependent) implicated in the IP address allocation, then we are talking about a non transparent access; the PGW is an active part in the IP negotiation: for instance, it may act as a DHCP server for the UE (via SGW, of course) and in the same time as DHCP client – when talking to the APN’s actual DHCP server;

*Note: the role of the PGW in the DHCP allocation case is different from the role of its 3G homologous, the GGSN – this entity playing the role of a DHCP relay agent in this scenario;

*Note: We are talking about the so-called IP-CAN (Connectivity to Access Network) session establishment – which, as far as I understand from TS 29.061, refers to the process of allocating an IP address (IPv4, IPv6 or IPv4v6) by a process other than gathering it from the PGW pool, for instance: via DHCP/DHCP-PD, PPP, IMS CN IM process…etc…

4. IP-CAN can be established at:

a) Initial Attach (default bearer activation) to the APN (in EPC) – Primary PDP Context Activation to the APN (in 3G)

b) after the initial attach, via a dedicated bearer/secondary PDP context

5. The IP assignment can take place:

a) either at the subscription phase – in which case we are talking about a static address

b) or at the IP-CAN session establishment – in which case we are talking about a dynamic address

*Note: Usually, as part of the IP-CAN negotiation ( no matter if this takes place at initial attach of afterwards), the PGW may request the UE to authenticate to the external APN’s AAA server

Everybody knows about this Quality of Service thinggie that helps admins to classify traffic and better allocate network and system resources to accommodate traffic needs and also to enforce the policies that exist for each user/groups of users – basically according to the amount of money they pay for this service 😛

In order to enforce a QoS on SAE entities, there are a few things to keep in mind:

A. PCRF – Policy Charging Rules Function device, which basically is a database that holds specific service QoS associations for each UE – this device is interrogated by the PGW in order to find out which QoS is applied on which traffic for each UE that requests a dedicated bearer

B. HSS – Home Subscriber Server, which has _nothing_ to do with QoS; this is a static database that holds information about the UE as is, and no information about any SLA of that UE with the provider

C. Only dedicated bearers hold a QoS level as part of their TFT association

D. The QoS on SAE has multiple variants, dividing the bearers into 2 groups:

GBR bearers (Guaranteed Bit Rate)

non-GBR bearers

E. The TFT (Traffic Flow Template – containing the filtering components for the traffic) that is associated with a bearer is not per flow, but per direction:

TFT-UL (TFT uplink)

TFT -DL (TFT downlink)

Also, the TFT can be:


SDF-level (service data flow level)

Now, we are interested in the GBR bearers. The GBR profile includes the following parameters:

1. QCI – QoS Class Identifier


a. 1 QCI corresponds to 1 bearer only

b. 2 services having different QCI values can NOT be on the same bearer (TFT)

c. 2 services having the different QCI values can NOT have the same ARP (see below) value

d. QCI values must belong to [1..255]

2. ARP – Allocation & Retention Priority


a. this value has NO influence on QoS

b. this value is set per eNB, following the PGW’s decision

c. it is established by PCRF according to a tuple of —activity type — subscription information — admission policies—

3. GBR – Guaranteed Bit Rate

4. MBR – Maximum Bit Rate

** There are also aggregated GBR bearers: AMBR (this is per APN) and UE-AMBR (the per-non-GBR, per UE rate) — [note to myself] to study more on this!

***Things to consider:

Thinking about the Mobility/Handover scenarios, keep in mind that, when a UE moves from one eNB to another, or from one MME to another, or from one SGW to another, the QoS is enforced on ALL the EPS components. This means that the QCI, ARP, GBR, MBR rates will all be verified on the resources of the destination (destination eNB, destination MME and so on). This means further on that, should at least one of the components not have enough resources to sustain all the QoS of a specific UE, some bearers will be dropped – this, again, is a decision of the SGW, taking into consideration, of course, the signaling came from the rest of the components.

[courtesy of my LTE guru colleagues]

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:



What about those LTE bearers? What exactly is a bearer?

Well, if we are to believe the 3GPP guys (3GPP TS 23.401 version 8.6.0 Release 8), an EPS bearer is a data structure (that appears on the UE, MME, SGW and PGW), a way of uniquely identifying a traffic flow between the UE and the PGW. We need to _uniquely_ identify these flows because of the QoS we want to use for that UE traffic.

When are these bearers created?

First of all, there are at most 11 bearers that can be created for a specific UE. 11 bearers TOPS – per UE. Why is this so important?


1. the first time an UE connects to an anchor point (PGW) – procedure called Initial Attach, simply by allowing that UE access on the PGW – a new (default) bearer is created – and, yes, those 11 bearers tops decrease once this happens!!!

2. an UE can be “attached” to more than 1 anchor point (PGW) – which means, an UE can have more than 1 “default”/”initial” bearers (of course, created via multiple Initial Attach procedures) – which means those 11 bearers tops decrease again

Leaving us with the rest of the bearers, those NOT created “by default” at the Initial Attach procedure, those which we call dedicated bearers.

***Note: there are not necessarily 11 bearers up and running all the time. The “11” is just the max number that can be active at a certain moment.

How do I use the bearers for QoS?

Each bearer, once created, has assigned a certain TFT set. “TFT” stands for Traffic Flow Template, the set of all packet filters associated with that certain bearer (we’ll look later on soon at the wireshark capture to see exactly how these “bearer” and “tft” look like).

How do I use the TFT for QoS?

TFT, being a set of packet filters, resides as a database tuple in the PCRF – Policy Control and charging Rules Function, a separate cute device that tells the PGW how to route, where to route, and what QoS to use for traffic flowing to and from a certain UE.

! Moment of thinking 1:

HSS – Home Subscriber Server

PCRF – Policy Control and charging Rules Function

The HSS is a database that holds only information regarding the default bearer (which basically identifies the UE as belonging to this network), while the PCRF has the role of “traffic shaping”.

! Moment of thinking 2:

Although the default bearer is more or less automatically created when the UE attaches to this network, as a network confirmation that this UE belongs to it, the dedicated bearer is NEVER initiated by the MME/UE (even if it is, the PGW will gracefully ignore it 😛 ) – the dedicated bearer will ALWAYS be initiated by the PGW, in response to a certain traffic pattern matching a rule in PCRF, though triggering the creation a new and shiny TFT.