Posts Tagged ‘LTE’

Mwell…my dear dear journal, today I had to learn about Mobility over SAE. As we very well know, our naughty user (User Equipment) does not just stay in one single cell, but rather moves around between different antennas. As per TS 23.401 (I have studied the June edition), there are several “cases” of mobility, or handover, as the 3GPP guys call them.

What is to know about how these “cases” are delimited:

1. whether the UE only moves from one eNodeB to another (the rest of the EPS is the same) or other components (like MME and/or SGW) are also changing => X2-handover and S1-handover

2. whether or not the eNodeBs are connected each-other (when they are connected, the interface is called X2) => this results in 2 separate cases: Direct Tunneling (we have X2) and Indirect Tunneling (we don’t have X2)

3. whether or not the MME changes (is relocated, as per the TS) => no MME relocation and MME relocation scenarios

4. whether or not the SGW changes (is relocated, as per the TS) => no SGW relocation and SGW relocation scenarios

5. in each of these cases, what happens to the user-plane traffic in terms of the path it takes; the uplink usually goes directly through the new components of handover, but the downlink data is forwarded back and forth around those elements – in the diagrams attached I have represented the user-plane in dotted lines – hope you’d like it 😛

6. the user-plane flow problem appears only in the time interval that the handover is not completed, otherwise it is the usual; this is why there is only a downlink user-plane traffic described

So—let’s do this by the book.

TS 23.401, section 5.5.1.1.2 – X2-based handover with NO SGW relocation and NO MME relocation (implicit direct tunneling)

– UE moves from source eNB to target eNB, the X2 interface is present

– the downlink data flows this way: PGW -(via S5/S8)> SGW -(via S1-U)> source eNB -(via X2)> target eNB -(via LTE radio)> UE

55112

TS 23.401, section 5.5.1.1.3 – X2-based handover with SGW relocation and NO MME relocation (implicit direct tunneling)

– UE moves from source eNB to target eNB, the X2 interface is present

– the downlink data flows this way: PGW -(via S5/S8)> source SGW -(via S1-U)> target eNB -(via LTE radio)> UE

55113

* no MME relocation for X2-based handover :d

TS 23.401, section 5.5.1.2.2 – S1-based handover, NO SGW relocation and MME relocation + Direct Tunneling

– UE moves from source eNB to target eNB, the X2 interface is present

– the downlink data flows this way: PWG -(via S5/S8)> SGW -(via S1-U)> source eNB -(via X2)> target eNB -(via LTE radio)> UE

55122-dir

TS 23.401, section 5.5.1.2.2 – S1-based handover, NO SGW relocation and MME relocation + Indirect Tunneling

– UE moves from source eNB to target eNB, the X2 interface is NOT present

– the downlink data flows this way: PGW -(via S5/S8)> SGW -(via S1-U)> source eNB -(via S1-U)> SGW -(via S1-U)> target eNB -(via LTE radio)> UE

* this is the case when there are some downlink packets that have been forwarded from the SGW to the source eNB, BEFORE the handover is completed; this means that the source eNB (knowing there is a handover ongoing), resends/sends back these packets to the SGW they came from; the SGW, at this point, should be aware of the handover and buffer the packets until the handover is completed, then forward them via the appropriate S1-U to the target eNB

55122-indir

TS 23.401, section 5.5.1.2.3 – S1-based handover, SGW relocation and NO MME relocation + Indirect Tunneling

– UE moves from source eNB to target eNB, the X2 interface is NOT present

– the downlink data flows this way: PGW -(via S5/S8)> source SGW -(via S1-U)> source eNB -(via S1-U)> source SGW -(via…to check this up)> target SGW -(via S1-U)> target eNB -(via LTE radio)> UE

55123-indir-no-mme

TS 23.401, section 5.5.1.2.3 – S1-based handover, SGW relocation and MME relocation + Direct Tunneling

– UE moves from source eNB to target eNB, the X2 interface is present

– the downlink data flows this way: PGW -(via S5/S8)> source SGW -(via S1-U)> source eNB -(via X2)> target eNB -(via LTE radio)> UE

55123-dir

TS 23.401, section 5.5.1.2.3 – S1-based handover, SGW relocation and MME relocation + Indirect Tunneling

55123-indir

– UE moves from source eNB to target eNB, the X2 interface is NOT present

– the downlink data flows this way: PGW -(via S5/S8)> source SGW -(via S1-U)> source eNB -(via S1-U)> source SGW -(via…to check this up)> target SGW -(via S1-U)> target eNB -(via LTE radio)> UE

 

The signaling required for these handovers are described in TS 23.401 as a flow and in TS 29.274 at the IE level.

I will try to describe each flow (or at least the most significant ones) in future articles. Enjoy :p

At first, I thought I was too noob to understand this stuff. I still consider myself a noob, but the way these TSs are written sometimes really gets on my nerves.

Let’s just consider the case of the S1-based handover with MME relocation and SGW relocation and Indirect Tunneling – meaning there is no X2 link between the source and target eNBs. All I can do for the moment is to look at the S11 interface, because this is the one I have the opportunity to study at this point.

So, the 2 TSs involved in this case, at least at the high  level are TS 23.401 – which describes the message flows between the SAE entities and TS 29.274 – which describes each message and its IEs.

The S1 based handover with MME/SGW relocation and Indirect Tunneling looks something like this:

55123-indir

In order to make this more human-readable, I have considered the following scenario:

mme2

where my UE (UE-1) moves from eNB 30.0.0.1 to eNB 30.0.0.5 (which have an X2 link together) – doing X2 handover (with no MME relocation), then it moves from eNB 30.0.0.5 to eNB 30.0.0.8 (which don’t have an X2 link between them). As you can see from the picture, these 2 eNBs belong to 2 different MMEs and SGWs. This means that, when the UE moves from eNB5 (30.0.0.5) to eNB8(30.0.0.8), it will generate an S1 handover signaling between the source MME – MME1 (30.0.1.1), source SGW – SGW1 (30.0.2.1), target MME – MME4 (30.0.1.4) and target SGW – SGW2 (30.0.2.2). As there is no X2 link between eNB5 and eNB5, the downlink packets coming from the PGW while the UE is in the handover process with reach eNB5, then they will be “reflected” back to SG1, which will then forward them via an “indirect” tunnel to SGW2, which will forward them to the new eNB8, which is in charge of my UE.

The flow is like this (3GPP copy-pasted 🙂 )

ts1

1)  So, as this picture states, once the handover is decided, the source MME sends a Forward Relocation Request to the target MME. This message must at least contain the following mandatory IEs, as per TS 29.274:

– IMSI

– Sender’s F-TEID for Control Plane

– MME/SGSN UE EPS PDN Connections

– SGW S11/S4 IP Address and TEID for Control Plane

– MME/SGSN UE MM Context

2) Then the target MME sends a Create Session Request message to the target SGW, including (M == Mandatory):

– IMSI (M)

– RAT Type – here is E-UTRAN (M)

– Sender F-TEID for Control Plane – here it is the IP address of the source MME: 30.0.1.4 + it’s TEID/GRE Key (this “key” is actually a hexadecimal number on 2 bytes) (M)

– APN Name (M)

– Maximum APN Restriction (M)

– LBI – Linked EPS Bearer ID – indicates the default bearer of the connection – the ID of the default bearer, usually this has value 5 (C)

– PGW S5/S8 Address for Control Plane or PMIP – this is the IP address of the PGW: 20.0.0.1 (C)

3) the target SGW replies to the target MME with a Create Session Response message, containing:

– Cause (M)

– Sender F-TEID for Control Plane – this is the IP address of the target SGW: 30.0.2.2 (C)

– APN Restriction (M)

– Bearer Contexts created (M) – this means that all the bearers that have the OK to be created for the UE in question are going to be present here, in a separate group IE; the IEs within a Bearer Context have the following:

— EBI – EPS Bearer ID (M)

— Cause (M)

— S1-U SGW F-TEID – the IP address of the SGW used for user-plane and a TEID/GRE identifier on 2 bytes – this is usually the same identifier used for the initial traffic of this user, _before_ the handover, let’s just call it Key-A – which is the uplink identifier for the user (C)

— Bearer Level QoS – the new QoS parameters, if they have been changed (C)

** Let’s stop for a second a recap. What do I have at this point? I have an UE (UE-1 in the picture) with an IP address (let’s say: 40.0.0.91). It is attached to the eNB 30.0.0.5, having a default bearer in place with the MME 30.0.1.1 (source) and the SGW 30.0.2.1 (source). This default bearer has an uplink identifier TEID, called as above Key-A, which also has a downlink identifier TEID, called Key-1. Let’s say that what travels in uplink has a key made out of letters, and what travels in downlink has keys made out of numbers 🙂

Ooook, what’s next. Well, as my UE moves to eNB 30.0.0.8, AND there is no X2 link between eNB5 and eNB8, target MME creates an indirect tunnel for the packets. Once the UE has moved to eNB8, the uplink flows directly from this new eNB, to the new SGW and so on. So, the indirect path is for the downlink packets, more precisely, for THOSE downlink packets that have already been routed by the source SGW to the source eNB (eNB5). eNB5 cannot contact eNB8 directly, so it re-routes these packets back to the source SGW, which will also re-route them via this indirect tunnel to the target SGW – which has direct S1-U connectivity to the target eNB to deliver the packets to my dear UE 🙂

How does EPC do that?

4) Target MME (30.0.1.4) sends a Create Indirect Data Forwarding Tunnel Request message to the Target SGW (30.0.2.2), containing all the grouped IEs Bearer Contexts that are to be forwarded this way, this grouped IE being the only Mandatory IE in this message. This Bearer Context IE contains:

— EBI – EPS Bearer ID (M)

— S1-U eNodeB F-TEID for data forwarding – this is the IP address of the target eNB (30.0.0.8) and its associated TEID/GRE key, let’s call it Key -2. This key instructs the target SGW about the destination of the packets for my UE (C)

5) then the Target SGW (30.0.2.2) responds to this message with a Create Indirect Data Forwarding Tunnel Response message. This message has 2 Mandatory IEs: the Cause and the Bearer Contexts grouped IE. This Bearer Context IE has:

— EBI (M)

— Cause (M)

— S1-U SGW F-TEID for data forwarding – this is the IP address of the target SGW and its TEID/GRE identifier – Key-B

6) After this, the target MME sends a Forward Relocation Response message to the source MME, instructing it about the bearers that have been accepted for creation on this indirect path

7) Now, the source MME (30.0.1.1) sends a Create Indirect Data Forwarding Tunnel Request to the source SGW (30.0.2.1), with elements similar to the corresponding message above, except that in this case, the Bearer Context has the TEID/GRE identifiers of the target SGW, contained in the Create Indirect Data Forwarding Tunnel Response from above – Key-B – when source SGW will forward the packets to target SGW, this will be the GRE Identifier used for encapsulating those packets

8) The source SGW responds with a Create Indirect Data Forwarding Tunnel Response message, same as above, but the TEID/GRE ID is the one of the IP address of the source SGW. This ID shall be used for uplink data on the indirect tunnel from the source eNB to the source SGW. Let’s call this ID Key-3.

*** At this point, we have an indirect tunnel created between the following entities:

source eNB (30.0.0.5) -> source SGW (30.0.2.1) : TEID Key-3

source SGW (30.0.2.1) -> target SGW (30.0.2.2) : TEID  Key-B

target SGW (30.0.2.2) -> target eNB (30.0.0.8) : TEID Key-2

At this point, the user traffic is like this:

traffic

1: packets already forwarded by the source SGW to the source eNB are “reflected” by this eNB – use the downlink GRE ID established initially, Key-1

2: the reflected packets from source eNB back to source SGW use the GRE negotiated via the messages above: Key-3

3: packets then travel on the tunnel from source to target SGW, via the TEID/GRE ID: Key-B

4: then the target SGW finally forwards the packets down to the target eNB via GRE ID: Key-2

*** During all this complicated process, the uplink is already using the target eNB as source for the encapsulating tunnel

So, what happens afterwards?

9) the target MME sends a Modify Bearer Request message to the target SGW, describing the newly created tunnels for downlink, not the indirect ones, the usual, direct ones and the target SGW replies with a Modify Bearer Response message in order to acknowledge (or state a cause for rejecting) this

10) the source MME deletes its session from its (source) SGW, using a Delete Session Request /  Delete Session Response pair of messages, carefully indicating the SGW that this is only a “local detach” of the UE, not a complete detach, meaning that the UE just moved and the local information about it is no longer valid, NOT that the UE disappeared from the network and the resources are to be deleted !

11) 12) both pairs of source and target MME/SGW now delete the indirect tunnel by exchanging the Delete Indirect Data Forwarding Tunnel Request / Delete Indirect Data Forwarding Tunnel Response messages.

And everybody is happy.

EXCEPT Me, because there are a lot of misleading and confusing “explanations” in the specs regarding this type of scenarios, like for instance:

a) one spec (TS 23.401) states that the delete session procedure should have Cause and LBI IEs in the Create Session Request message, while TS 29.274 defines these 2 IEs as Conditional, and, as per the condition in place, none of them should appear in this message when the source MME disconnects from the source SGW. Instead, the SGW should look at the Indication Flags in this request: if the Operation Indication is set, then this is a full detach, if the Scope Indication is set, this is a local detach.

b) look at the above flags: shouldn’t it be better to have just 1 flag, and, if it is set, we have a full detach, otherwise we have a local detach?

c) what happens in the S1 handover with no SGW relocation (whether or not the MME is relocated) and Indirect Tunneling? How is that going? Do I still send the two pairs of Create Indirect Data Forwarding Tunnel Request/Response?

and more to come

Ref:

CSFB vs. SRVCC, or how to “sudo make me Voice over LTE” – take 1

CSFB vs. SRVCC, or how to “sudo make me Voice over LTE” – take 2

by Alex

it was about time to display a nice message flow diagram of the messages being exchanged for Combined EPS/IMSI Attach

Enjoy!

combined

continuing the CSFB vs. SRVCC, or how to “sudo make me Voice over LTE” – take 1 series, by Alex

I was thinking the other day and I realized that CSFB is meant to be used only if VoLTE cannot be used for some reason. That sounded strange to me as in order to be able to use CSCF you need the special combined EPS/IMSI attach but in some cases you may find yourself unable to use VoLTE after you attach. On example of such case is when the network prefers VoLTE and the UE is able to do VoLTE but IMS voice is not available (for example the registration to the IMS network fails).  To find the answer to my questions I turned to TS 23.221, maybe it can help in some way.

What I found is than an UE can be either voice centric or data centric. This usage setting basically tells the network what’s more important for that UE (voice or data). For example a voice centric UE will disconnect from E-UTRAN and try GERAN/UTRAN if it is not able to obtain voice service in E-UTRAN while a data centric UE will not do that.

Now, there’s another setting on the UE which is called voice domain preference and has one of four values CS Voice only, IMS PS Voice only, CS voice preferred, IMS PS Voice as secondary, IMS PS voice preferred, CS Voice as secondary.  Based on these 2 settings and what happens in the network the UE will prefer one of the following 4 states:

 

Voice centric UE

Data centric UE

CS Voice preferred/ CS Voice only

CS/PS mode 1

CS/PS mode 2

IMS PS Voice preferred/ IMS PS Voice only

PS mode 1

PS mode 2

* an IMS PS Voice preferred UE may still be connected to both systems.

* an IMS PS Voice Only UE will not use combined attach or CSFB

*TS 23.221 Annex A gives guidance on how a CS and IMS capable UE should behave.

On the other hand, the network has its settings and preferences too. When an UE attempts to do a combined attach, the network may inform the UE of its settings, like CS Fallback not preferred, SMS-only (the CS network is to be used to SMS over SGs only, not for CSFB) or IMS voice not available. The UE may transition between these states if its settings or the network’s settings change. Also an UE in a PS mode state will transition to the corresponding CS/PS mode state if IMS is unavailable for some reason.

Now, in order to do CSFB or SMS over SGs one needs to be in one of the CS/PS modes. To be in one of these modes the UE needs to do a combined EPS/IMSI attach. Now let’s say our UE is set to prefer the IMS for voice calls but its registration to the IMS network fails for some reason or the network indicates to the UE it does not support PS voice. In this case the UE is already connected to the EPS network but most likely not to the CS network and in order to use CSFB it needs to transition to a combined EPS/IMSI attach situation. To do this the UE will do a Combined TA/LA Update Procedure (TS 23.272 section 5.4.1).

Later edit:

Relevant specs for the UICC side:

TS 24.008 – Layer 3 specifications, Core network protocols

TS 31.102 – USIM Applications

Why? : Because I would like to see in more detail how this entire CSFB/SRVCC story happens at the UE+UICC(SIM) level.

Finally, I’ve managed to get my favourite real-life geek (the non-real-life geek is Spencer Reed) to write an article (which shall become a series, I hope) for my blog. Here it goes, Alex.

=====

The other day I realised that working in the 4G/EPC field has some advantages. One is that I get to see how things work and that is the coolest thing, but sometimes you realise things are so complicated it may be a good idea to wait for a while before upgrading.   Take for example the voice calls. In order to do voice calls in 4G you have 2 major options:

1.       VoLTE  which is VoIP using the 4G  (LTE and EPC devices) and IMS network – this is how things should be done in a real 4G network

2.       CSFB (Circuit Switched (CS) fallback TS 23.272) which means that when the UE(phone) needs to make or receive a call it is moved to an older 3GPP technology (2G/3G). This mechanism is used if the IMS network is not available or the UE is not able to do VoLTE for some reason (for example registration to the IMS network failed)

(more…)

Open EPC – Fraunhofer Fokus

Posted: August 16, 2012 in technical
Tags: , , , , ,

Proud to be Romanian. Go go guys!

http://www.openepc.net/_docs/OpenEPC_tutorial.pdf

[re-post] IP address allocation

Posted: August 8, 2012 in technical
Tags: , , , ,

To my great surprise IP address distribution to the UEs proves to be quite tricky in 4G. First of all there are 2 types of addresses supported: IPv4 addresses and IPv6 addresses. Each PDN connection needs at least one IP address associated with it, IPv4 or IP6, but it may have one IPv4 and one IPv6 address associated with it. All UEs and PDNs need to support at least IPv4 address allocation during default bearer activation and IPv6 prefix allocation via IPv6 stateless autoconfiguration, but may also support IPv4 and IPv6 address allocation via DHCPv4 and DHCPv6. Also there is the possibility of using static addresses/prefixes, but this is transparent to the UE (23.401 “It is transparent to the UE whether the PLMN or the external PDN allocates the IP address and whether the IP address is static or dynamic. It is transparent to the UE whether the PLMN or the external PDN allocates the IP address and whether the IP address is static or dynamic.”). If a static address/ prefix is to be used this needs to be configured in the HSS or in a DHCP/Radius/Diameter server.

I will not talk about the IPv4 address allocation as it seems to be quite simple. The PGW is allocating or obtaining an IPv4 address for the UE and forwards this address to the SGW and the SGW in turn to the MME in the Create Session Response message (PAA IE). The MME will store it and send it the UE. The address will be released upon the release of the entire session.

IPv6 prefix allocation
– Each UE and PDN connection is allocated a globally unique /64 prefix (23.401 |IPv6 Stateless Address autoconfiguration specified in RFC 4862 [18] is the basic mechanism to allocate /64 IPv6 prefix to the UE.”)
During default bearer activation the PGW sends to the SGW (and MME) a complete IPv6 address that contains a /64 prefix and an interface identifier. This address is included in the Create Session Response message in the PAA IE. The MME will forward only the interface identifier to the UE and it will store the prefix. Upon activation of the default bearer the UE may send a Router Solicitation message to the PGW. This message will travel encapsulated in GTP-U over the S1-U and S5/S8 interfaces. So, this RS message will be received by the PGW accompanied by a GTP-U header that contains the PGW-U TEID allocated to the UE for the default bearer. After the default bearer activation the PGW will send a Router Advertisement message to the UE containing the same IPv6 prefix as the one allocated during default bearer activation and sent to the SGW and MME. This RA message is sent on the GTP-U tunnel associated with the default bearer and can be sent solicited or unsolicited. Using the prefix received in the RA message and any interface identifier other than the one received the UE creates globally unique IPv6 address (23.401 “For stateless address autoconfiguration however, the UE can choose any interface identifier to generate IPv6 addresses, other than link-local, without involving the network. “).

Note: The RS message uses the following source and destination IPv6 addresses:
– Source IP address: a link local address formed using the interface identifier received by the UE during the activation of the default bearer (FE80::received prefix)
– Destination IP address: IPv6 all routers (FF01::2)
The RA message uses the following source and destination IPv6 addresses:
– Source IP address: a link local address of the PGW
– Destination IP address can be either:
– IPv6 all nodes: FF01::1
– The source IPv6 address of the RS message.
Source: RFC 4861.

Details on the IP address allocation can be found in:
– 23.401 section 5.3.1
– 29.061 section 11.2.1.3.2a IPv6 Stateless Address Autoconfiguration for EPC

Update:
There are 2 questions that I couldn’t find an answer for yet:
1. Why was the stateless autoconfiguration mechanism chosen? Why not just pass the prefix to the UE?
2. In Create Session Request for handover and sometimes for attach the MME includes the UE’s IPv6 address. What IPv6 address is included, considering that the MME and HSS only keep the prefix in the information storage databases? (per 23.401 Information Storage section)

[re-post] NAS messages format

Posted: August 8, 2012 in technical
Tags: , , , ,

It’s been a long time since the last time I wrote anything, but latly I feel the need to write down what I’ve been reading (just to have some reference for the future). Today’s post will be about how the NAS messages are constructed. As I was used to working with GTPv2, the NAS protocol looked like a big mess to me. Here’s what I’ve figured out so far.

The spec governing the NAS protocol in 4G is 24.301. It describes both the procedures and the message format. Each time I need to figure out what messages should appear for a certain event I first have to read the procedure and find the names of the messages. The description of the procedure usually contains some directions for the content of the messages too. The next phase is analyzing each message. For each message there is a table with the Information Elements (IEs) that are to be included. Note that the IEs are marked as mandatory, conditional or optional. Each IE has the a dedicated chapter where the structure of the IE is described. Note that there are multi types of IEs (V – value, LV – length-value, TV – type-value, TLV-type-length-value, etc.). The mandatory IEs are included in the packets without the type (24.301 8.1 )and that is why for the NAS messages the IEs need to be put in the packet in the exact same order as in the table describing the message. In that table it can be noticed that these mandatory IEs have no IEI (IE Identifier) associated with them.
As the communication between the UE and the MME needs to be secure, usually the NAS messages are integrity protected and sometimes ciphered. Depending on wheather the NAS message is security protected or not, the format changes. In case the message is security protected a security header appears. (24.301 9.1) This security header contains the security type, the protocol discriminator(always “EPS mobility management messages” for security protected messages, – 24.301 9.2), a MAC (message authentication code – a hash that allows the other end of the communication to see if the messages was tempered with) and a sequence number. After this header the NAS message actually begins, with its own header. This header of the plain NAS message consists of protocol discriminator (this time it can be different tha “EPS mobility management messages”), EPS bearer identity or security header type (this time “Plain NAS message, not security protected”), a procedure transaction identifier and a message type. After this mandatory header the other information elements appear.

Note: When setting the security type the negotiated encryption and ciphering algorithms play no part at all. (24.301 4.4.5 Ciphering of NAS signalling messages). This means to say a message that was encrypted with the NULL algorithm (not encryoted at all) can still be encoded as a security protected message that is ciphered.

The first post is about handovers in LTE. I will not describe the LTE architecture because anyone who might be interested in the subject must already knows that. This post is not about what happens in the core of the network when a handover is decided, but what happens in the access area. Between two eNBs that are connected though an X2 link, as far as I understand, there are two types of handovers: seamless and lossless. The names are not very intuitive, but the idea is that seamless handover is used for bearers transporting traffic that is very sensitive to delay and jitter and would rather accept retransmissions than delay, like VoIP, while the lossless handover is used for bearers that transport traffic that does not care too much about delay but is sensitive to retransmissions, like FTP and HTTP.

The decision for one of the HO types or the other is made by the source eNB. The major difference between the two HO types is that when using lossless HO besides the information sent by the source eNB to the target eNB in the Handover Request message, the source eNB also sends on the X2 link the downlink packets it received for the UE and which have not been sent or acknowledged yet. This way all the packets are delivered and no retransmission should occur. When thinking about this one must take into consideration that in a VoIP conversation the packets used are very small while for HTTP an FTP large packets are used. The retransmission of such large packets would use valuable bandwidth and TCP would protocol to slow down the conversation. On the other hand for VoIP the packets used are very small (retransmission of a few packets is not very expensive in terms of bandwidth), and it is very important that the packets arrive with the smallest delay possible.

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 5.3.2.1 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 0.0.0.0 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.