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 MMErelocation 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

* 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

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)

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…

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.

“c1” because…mwell, because “a” was the register and 4G/IMS architecture, “b” was the OpenIMSCore and “c” should be an actual call flow.

Unfortunately, I cannot show you the actual 4G encapsulation, because I don’t have any tool to emulate that, but, as we’ve understood from the registration flow, each IMS message coming from or going to the IMS mobile device will be encapsulated in GTPv1-u header between the eNodeB, SGW, PGW and then forwarded, without the GTPv1-u encapsulation, to the P-CSCF. Juuust as for the Register flow…

Oook, now let’s take a look at the IMS-SIP call flow. Basically, what I’m going to show here is a Basic Callwith Voice.

Now, the most basic SIP (Session Initiation Protocol) call flow has the following structure:

Basically, Alice sends an INVITE message to Bob (via a sip proxy server or directly), inviting Bob to a voip message exchange, and also sending in the SDP (Session Description Protocol) header (presented as a SIP message body), the RTP (Real-Time Protocol) codecs that Alice’s phone is supporting. 1xx is provisional messaging. 100 Trying and 180 Ringing is a good sign, they mean I am actually contacting Bob, I am just waiting for him to pick-up the phone. When he does that, his device signals a 200 OK (sending in this message also the RTP codecs known by Bob’s device), and Alice’s device Acknowledges. Now the RTP session can begin, with one of the matching codecs. Once the two guys finish talking, Alice’s phone (usually) is the one signaling the end of the conversation, by sending a BYE message to Bob, and this one acknowledges. Alice can also send her supported RTP codecs barely in her ACK message, procedure called late negotiation.

Now, this may rightfully seem simple enough, but wait! We haven’t yet got to the IMS part 🙂

The same “basic” SIP call flow in the IMS context would look like this (of course, excluding the 4G encapsulation which we’ve agreed we understand):

In the next chapter I’ll detail these messages.

For the moment, let’s just observe the presence of a weird new message called PRACK. The PRACK is defined in RFC3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP). The RFC 3262 states:

The PRACK request plays the same role as ACK, but for
provisional responses. There is an important difference, however.
PRACK is a normal SIP message, like BYE. As such, its own
reliability is ensured hop-by-hop through each stateful proxy. Also
like BYE, but unlike ACK, PRACK has its own response. If this were
not the case, the PRACK message could not traverse proxy servers
compliant to RFC 2543 [4]."