Posts Tagged ‘PDN’

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.


This is how it looks like

(at least imho)


EPS roaming architecture with  local breakout

Sometime in the future posts I will describe in details everything. This is part of an article called An Analysis of Secure Interoperation of EPC and Mobile Equipments, submitted to a conference from IARIA.

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

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:



As I was telling you about in a previous post – my first eGTP test, the reply (first reply) to a CreateSessionRequest message is a CreateSessionResponse message, described below. This message contains:

1 2 3 4



– GTPversion 2, Message Type information, in this case, this is a Response, the length of the message, the sequence number (1) and the TEID (tunnel Endpoint Identifier) – which is copied from the CreateSessionRequest message

– the Cause field indicates this is a Response for an Accepted Request – in case there would be any error, the Cause Source field would indicate the cause of the error

– PDN Address Allocation (PAA) – field which is completed at this moment  (in the CreateSessionResponse) by the SGW with the IP address of the PDN – should you remember, in the CreateSessionRequest message, this field indicated the type of address (IPv4) and value; as per 3GPP TS 29.274 – this value is a fixed IPv4/IPv6 address as indicated by the HSS registers, or it leaves the value to indicating that the PDN GW address is assigned dynamically

– F-TEID (Fully Qualified Tunnel Endpoint Identifier) – as mentioned also in the previous post, there are 2 F-TEIDs: one for the S11 interface, and another one for the S5/S8 interface, both source IP addresses of GTP-C:

— one for the S11 interface (the one between MME and SGW) – the SGW end – the IP of the SGW from the S11 interface

— one for the S5/S8 interface (the one between SGW and PGW) – the IP address of the APN server

– APN Restriction header – as per 3GPP TS 29.274, it “denotes the restriction on the combination of types of APN for the APN associated with this EPS bearer Context.” – haven’t  used it yet, so I cannot say too much about it

– Bearer Context – information I have neglected to describe in sufficient detail in the CreateSessionRequest description. Here, in the CreateSessionResponse message, the Bearer Context header has 6 sub-headers:

— EPS Bearer ID

— Charging ID

— F-TEIDs : here both of the identifiers contain the IP address of the SGW’s S11 interface – the source GTP-U interface

— Cause : here is Request Accepted, no Cause Source

— Bearer QoS, which contains the QCI label and some other QoS identifiers that shall be described – hopefully I’ll be able to see them at work till then

my first eGTP test

Posted: January 4, 2010 in technical
Tags: , , , , , , , ,

Today I have created my first eGTP scenario, trying to analyze the Wireshark capture and better understand this protocol…

eGTP, or GTPv2 is one of the ongoing and work in progress 3GPP standards, following the GTPv1 of UMTS, eGTP is used on the SAE architecture, GTP-c (GTP Control-Plane) between the two components of the EPS (Evolved Packet System): MME (Mobility Management Entity) and SGW (Serving Gateway) and between SGW and PGW (PDN Gateway) and GTP-u(GTP User-Plane) between eNodeB and SGW for the user traffic.

Basically, when the phone/UE (User Equipment) is turned on, it looks for a radio network. When it finds one, it signals its location and identity and tries to contact it’s home network – procedure called initial attach. During this procedure, the UE is given a permanent IP address by the PGW (PDN – Packet Data Network Gateway) – this being one of the purposes of this attach procedure. As a consequence, a (default) bearer (UMTS context) is created, a basic connection between the UE and the PGW, mainly to identify the UE in the PGW and keep track of its existence while it is connected to the network. This procedure is basically the initial registration to the network and the messages exchanged here are part of the so-called control-plane traffic.

The complete signaling scheme is triggered by the UE sending an AttachRequest to its closest eNodeB device, this forwards the request to its MME (to one of its MMEs, if there are more), then MME talks to SGW (after allocating an EPS bearer ID for the default bearer associated with the UE) and the SGW talks to PGW, in order to create a session for our user. The complete flow is presented below.

Still, what is of interest to eGTP, the flow between MME and SGW consists of only 2 messages: CreateSessionRequest and CreateSessionResponse (in case the bearer is modified, also ModifyBearerRequest and ModifyBearerResponse).

1 2 3 4042792944_57805b8268_o

The CreateSessionRequest contains:

– identification information of the UE (IMSI, MSISDN, MEI – Mobile Equipment Identity, ULI – User Location Information)

– information regarding the radio access: the access can be E-UTRAN (where we have an eNodeB device) or other 3GPP and non-3GPP RANs

– information about the destination network /serving network (MCC – Mobile Country Code and MNC – Mobile Network Code)

– information about the path of the tunnel – where the user is to be registered; as the user is registered on the PGW, and this message (CreateSessionRequest) is sent by the MME, the next logical hop is the SGW; therefore there are 2 Fully Qualified Tunnel Endpoint Identifiers:

— one for the S11 interface (the one between MME and SGW)

— one for the S5/S8 interface (the one between SGW and PGW)

these two headers contain a field called F-TEID IPv4 (or IPv6) having as values the IP address of the next logical interface (SGW’s S11, respectively PGW’s S5/S8 interface)

– type of the final gateway (registration point): either IPv4 or IPv6

– information about the type of transaction in place, like: type of network selection, PDN address allocation ( in this message on S11) and an Indication header used for future signaling in case a Handover takes place, for instance

– the APN (Access Point Name) – DNS name, APN restrictions, AMBR (Aggregate Maximum Bit Rate) – used in QoS (I’ll study this one later on), Bearer information (ID, QoS…) and a Restart Counter

Following up this message, the SGW also creates an entry for the default bearer of that UE and sends a CreateBearerRequest message to the PGW.

The CreateSessionResponse in the next chapter 😛

***I have noticed that, in order to completely understand the entire flow of messages is better to follow-up a type of message from its starting point (let’s say, the UE or eNodeB triggering the flow) up until the PGW device. The message above has been caught on the S11 interface, between the MME and the SGW, but