Posts Tagged ‘4G’


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



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.

I have just had a series of talks the past weeks with a good friend of mine. He is a Security Architect for a large company up north. I’m curious about what he is doing there, so initially I was thinking of organising our discussions as some form of an interview. Later on, my proverbial laziness got the best of me, so I downgrade our nice chat to a short blog post (this one).

Bottom line: I’ve asked him what it means to be a Security Architect. It went somewhere along these lines:

What are you doing there? Is it cool? Is it nice? Do you do cool stuff? Cristina being a bit of a chipmunk at this point

You won’t find it that cool, most probably. I don’t get to dig into the GTPv2 as you do.

Absolutely unsatisfactory – I say. Nevertheless, our discussion digressed into an interesting side-area: security frameworks and how to do network architectures security assessments. I asked for a framework to do these assessment.

Ok I will recommend something – but I don’t usually stick to frameworks, as it depends on the assignment and other stuff more to me. Like experience. So I go by from my head – yueah I know it sounds bad, but it works for me, as long as I remember to include all the areas.

Again, completely unsatisfactory – I say. Still, continuing the discussion, I realise the guy is right: it _actually IS_ about experience. Whatever “framework” is just a nice area checklist to help you with not missing out on stuff. This guy has too much experience to use any frameworks at the moment, but I need something to start learning this stuff. I did find something, and my friend corroborated my findings. Fortunately, his examples and details from his experience nicely matched the framework that I also liked for my research: ITU-T X.805.


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)


Open EPC – Fraunhofer Fokus

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

Proud to be Romanian. Go go guys!

[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 IPv6 Stateless Address Autoconfiguration for EPC

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.

3g to 4g – abracadabra

Posted: January 21, 2011 in technical
Tags: , , , , , , ,

Hello, again! Missed me?

Mwell, if you do, then you’ll be happy to see I am still here, live and kicking. Lately I’ve focused on writing stuff for my PhD and therefore no techie article and very slow reply to answers (promise to get back to those who still have no answers to their inquires). Today, applauses for the 3GPP guys: they don’t expect the operators to simply put a Stop to whatever they were doing, upgrade to 4G every piece of their equipment, then Start over. Au contraire…mon frere 😛 They provide a way (actually, 2 ways) of gradually upgrading a 2G/3G network to a 4G fancy network.

Today, I’m gonna present briefly one of them: Iu mode inter-RAT Handover. This is also a subject for my next article – but I’m not going to copy-paste it, as it might get rejected.

First of all, let’s take a quick look at how those fancy network equipments connect to each other in a 3G-4G handover case.


Mwell. So, what do you have here?

From the 3G side….(applauses…applauses): a RNC and a SGSN. We assume our UE is connected to a 3G network. But, as the operator has (at least partially) upgraded to 4G, there is no more GGSN. The SGSN is connected to the SGW via S12 interface. Unlike MME, which is a dedicated control-plane device, the SGSN transfers both control-plane and user-plane information.  The simply dotted lines in the picture represent the air interface. The dotted and stroke connections represent interfaces where there are two types of traffic being delivered: control-plane and data-plane.

On the 4G side, the usual and familiar elements: eNB, MME, SGW. The PGW, HSS and PCRF are there to stay.

The SGSN talks to the MME via the S3 interface. And, in this case, the handover will directly forward packets from the source RNC to the target SGW via the S12 interface. If you consider that the S12 interface does not exists, then we are facing a case similar to what we call “indirect tunneling” in the intra-EUTRAN handovers. In this case, when the source RNChas no direct way of forwarding the UE’s packets (those that are sent in downlink after the UE had already moved to 4G) to the target SGW, it will use the S4 interface to forward these packets to a dedicated SGW for indirect tunneling.

Without detailing each packet (maybe later on, on another post), let’s have a quick look at the message exchange between these entities in the 3G to 4H handover scenario. ! My picture ! (long live good old “dia” software)


Yes, there is some TAU also, as far as I understand from the TS 23.401, in these inter-RAT handovers, the TAU always takes place. And also, the TAU packets carry a most important information: the updated security credentials of the new 4G connection…

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.

This is a summary of what I hope to be able to describe in the next several posts: the establishment of a basic SIP-IMS call flow, in a somewhat interesting scenario: when both Alice and Bob are in roaming.

Each of the participants talks to his/her own P, S and I servers. Here the presumption is that Alice is the one making the phone call.