Posts Tagged ‘TAU’

Consider:

1. the UE is in ECM-IDLE mode

2. the network decides to delete some of the UE’s bearers, by sending a Delete Bearer Request message to the MME managing this UE

Question:

– Will the UE first be woken-up from ECM-IDLE and become CONNTECTED, and then the Delete Bearer Request is processed and responded? Or simply the MME will process the Delete Bearer Request message and NOT put the UE in ECM-CONNECTED?

Advertisements

TAU dilemma

Posted: August 5, 2010 in technical
Tags: , , , , , ,

Another one.

While discussing with a colleague. We have a dilemma about a specific thinggie from the TAU flow.

In TS23.401, page 67, nice 3GPP people state:

The bearer contexts shall be prioritized by the new MME. If the new MME is unable to support the same number of active bearer contexts as received from old MME/SGSN, the prioritisation is used to decide which bearer contexts to maintain active and which ones to delete. In any case, the new MME shall first update all contexts in one or more P‑GWs and then deactivate the bearer context(s) that it cannot maintain as described in the clause “MME Initiated Dedicated Bearer Deactivation Procedure”. This shall not cause the MME to reject the tracking area update.

So, I understand from this paragraph that, no matter if the new MME supports or not the dedicated bearers UE already established with the old MME, this new MME has to update all of them, and only then take a moment and say: “Oh, wait! I don’t support this and this and this bearer! Let’s delete them!”

— I must note that I don’t find this approach very efficient. As the new MME knows it cannot deliver those bearers, why not delete them at once?

Also, TS29.274, page 25, states, when describing the IEs of the Create Session Request message:

Bearer Contexts to be created M Several IEs with the same type and instance value shall be included as necessary to represent a list of Bearers.

One bearer shall be included for an “eUTRAN Initial Attach”, a “PDP Context Activation”  or a “UE requested PDN Connectivity”.

One or more bearers shall be included for a Handover/TAU/RAU with an SGW change.

Bearer Context 0
Bearer Contexts to be removed C This IE shall be included on the S4/S11 interfaces for the TAU/RAU/Handover cases where any of the bearers existing before the TAU/RAU/Handover procedure will be deactivated as consequence of the TAU/RAU/Handover procedure.

For each of those bearers, an IE with the same type and instance value shall be included.

Bearer Context 1

Now, from THIS particular paragraph I understand that, at this moment (when deciding to contact the new SGW), the new MME can already signal to the SGW that it wants to _remove_ this and this and this bearer.

So, the dilemma: Which version actually happens in real life? Will the MME enable all bearers, then do an MME initiated bearer deactivation procedure to delete the ones it does not support… OR it decides to remove the not supported ones directly, signaling via this message to the SGW its intentions?

TS 23.401 – section 5.3.4.3:

Afaik:

1. If the UE is in ECM-CONNECTED and it has a dedicated bearer matching the traffic, then a request from the network will result in simply routing the downlink packets from the SGW to the eNB via the existing dedicated bearer.

2. If the UE is in ECM-CONNECTED and it does NOT have a dedicated bearer matching the traffic, then the SGW/PGW(PCRF) will initiate a dedicated bearer creation, create the bearer and route the downlink packets to the appropriate eNB.

3. If the UE is in ECM-IDLE, ONLY THEN I see this Downlink Data Notification / Downlink Data Notification Ack (…Failure Indication) exchange meaningful.

Q: Does it make any sense/When does it happen for the SGW to initiate this message exchange if the UE is NOT in ECM-IDLE?

This one should be shorter, because I only have the questions, not the answers for all 😛 . Fortunately, there is one guy that strives to make me understand stuff. Hopefully, tonight his wife won’t beat his ass and let him write a post that (hopefully) would clarify some of my dilemmas:

(10:01:13 AM) Cristina: dunno..in a few days 🙂 I still have the week-end
(10:01:28 AM) Cristina: and..more importantly..I want to understand
(10:01:42 AM) SD: how about I write a nice article describing TAU tonight
(10:01:49 AM) SD: or by early tomorrow and send it to u?

So, till then:

Q1: When does the TAU relocate MME/SGW?

A1: see table

reloc

Q2: Why doesn’t the ECM-CONNECTED relocate MME/SGW?

A2: Because, if the UE is ECM-CONNECTED and it moves to an eNB that may require the relocation of both MME and SGW, there will be a Handover taking place. This Handover will relocate the MME and the SGW (as necessary). Then, the TAU’s place comes. But at this point, the UE is already behind the new eNB and the Handover took care of the “relocation” dilemmas. So, the TAU will only update the Network with the new UE’s location, without changing MME, nor SGW.

Q3: [Timing dilemmas] Scenario:

– UE is in ECM-IDLE

– UE moves to a new TAL, so it has to do TAU with MME relocation and SGW relocation (or just one of them, but at least one is relocated via TAU)

– then UE needs to do some traffic, so it becomes ECM-CONNECTED

What happens with the Handover in this case? Does it take place anymore? And what type of Handover would be – if it takes place?

Q4: Generic dilemma: I know that TAU and Handover are “independent”. Handover is always network-triggered, while TAU can be triggered by eNB or MME. Still, it seems to me they are very connected together right now.

The TAU – Tracking Area Update procedures are defined in TS 23.401 – section 5.3.3.

MOTO: TAU – the place of my most annoying dilemmas.

Before going any further, please refer to the nice picture below (shamelessly copy-pasted from Academic Press — SAE and the Evolved Packet Core – Driving the Mobile Broadband Revolution – Magnus Olsson(2009))

TAs

In order to better manage the UE – User Equipment, EPS – Evolved Packet System has the concept of areas (this concept is not new, it was present from 3G, but it is a bit different in 4G – we’ll see how).

To my understanding (and here comes my request to the nice inter-web readers for help and clarifications):

– a tracking area is a group of cells managed by an SGW; multiple SGWs can serve the same TA and multiple TAs can be served by the same SGW

– a tracking area can be shared by more than one eNB; one eNB can also serve more than one TA

– a registration area is a list of one or more tracking areas (TAs)

– when a UE attaches to the network, the MME gives it a list of areas where it can be tracked : Tracking Area List (or Registration Area)

– an MME can manage multiple tracking areas; the purpose of the MME here being to sent the TA list to the UE when this UE is registered to the network and also update the UE with the new TA list when this UE moves around the TAs

This has importance and impacts the following situations:

– When the UE is located at the edge of an area (registration area), it can go back and forth between 2 areas, which generates a lot of signaling, as the UE is required to update its position to the EPS. By having a list of areas where the user can move without having to constantly update the EPC about its position, the amount of signaling is low.

– When UE moves frequently between 3G and 4G, it has to update his position, de-register from 4G and register in 3G and vice-versa. By keeping being registered, it can go back and forth 3G and 4G without having to signal each time its updated status.

– The UE may be in ECM-CONNECTED state or in ECM-IDLE state. No matter its state, the UE must perform the TAU – Tracking Area Update whenever it moves outside of its Registration Area (or TAL – Tracking Area List) or when a certain TAU timer expires.

The TAU procedure is described very nicely in the picture below (shamelessly copy-pasted from Academic Press — SAE and the Evolved Packet Core – Driving the Mobile Broadband Revolution – Magnus Olsson(2009))

TAU_Procedure

[I’ll get into the details later on.]

– 2 MMEs can serve an overlapping set of TAs, when both of them are connected to the same SGW
the UE receives a TAList from the SGW where it attaches and this TAList does not change, unless there happens a case of SGW relocation – when the UE receives a new TAL (this TAL may have or not some of the TAs from the former TAL; some TAs may overlap)
Just as with any usual handover, TAU as well may trigger MME relocation and/or SGW relocation:
– how/when is it possible to change MME in idle/connected states?
– how/when is it possible to change SGW in idle/connected states?

The TAU procedure is not very complicated per se, but, as we should have got used to the marvels of 3GPP Specs, the Spec only describes a scenario, preferably the most complicated one, leaving the other scenarios to the reader’s understanding. Some times simply describing the most complicated scenario won’t do the “understanding” part for the “less complicated” scenarios.

For instance, you will see below the 2 TAU scenarios: SGW relocation and no SGW relocation, but both of them have the MME relocated.

The problems are:

1. Is it possible to have a TAU procedure with no MME relocation? – the spec seems to say you can…

2. What is the actual difference in the message flows and technical design between a TAU in ECM-IDLE and a TAU in ECM-CONNECTED states?

3. [Related to item 2 above] Santosh also has a dilemma:

Spec Ambiguity
Could somebody kindly tell me if a SGW could be relocated by a TAU request in connected mode? I think not? Interested in a debate? 3GPP TS 23.401 Chapter:- 5.3.3 Cheers, Santosh
So, nice people around the inter-web, please help us here 🙂

I am starting to have headaches again. First of all, I have read some of the posts from http://wired-n-wireless.blogspot.com, which is actually a great site and the owner actually works in the industry.

Second, I have taken the specs and some books and I try to understand this concept.

First of all, TAU comes from Tracking Area Update. The concept is closely related to some other concepts, which I should describe here – bear in mind that this is not an expert’s opinion, I am just the n00best person here trying to clarify stuff and hoping some nice people around the inter-web will give me a hand.

So, first things first, what is ECM and EMM? Take a look at TS 23.401.


I. ECM – EPS Connection Management – TS 23.401 – Section 4.6.3 Definition of EPS Connection Management States

ECM – IDLE

A UE is in ECM-IDLE state when no NAS signalling connection between UE and network exists. In ECM-IDLE state, a UE performs cell selection/reselection according to TS 36.304 [34] and PLMN selection according to TS 23.122 [10].

There exists no UE context in E-UTRAN for the UE in the ECM-IDLE state. There is no S1_MME and no S1_U connection for the UE in the ECM-IDLE state.

ECM – CONNECTED

The UE location is known in the MME with an accuracy of a serving eNodeB ID. The mobility of UE is handled by the handover procedure.

The UE performs the tracking area update procedure when the TAI in the EMM system information is not in the list of TA’s that the UE registered with the network, or when the UE handovers to an E‑UTRAN cell and the UE’s TIN indicates “P-TMSI”.

For a UE in the ECM-CONNECTED state, there exists a signalling connection between the UE and the MME. The signalling connection is made up of two parts: an RRC connection and an S1_MME connection.

The UE shall enter the ECM-IDLE state when its signalling connection to the MME has been released or broken. This release or failure is explicitly indicated by the eNodeB to the UE or detected by the UE.

Q: Now, the obvious question is: what are the conditions for the UE to switch between these states?

A: TS 23.401 says: ” The S1 release procedure changes the state at both UE and MME from ECM-CONNECTED to ECM-IDLE.” – but about the S1 release procedure later on

II. EMM – EPS Mobility Management – TS 23.401 – Section 4.6.2 Definition of EPS Mobility Management States

EMM – DEREGISTERED

In the EMM‑DEREGISTERED state, the EMM context in MME holds no valid location or routeing information for the UE. The UE is not reachable by a MME, as the UE location is not known.

In the EMM-DEREGISTERED state, some UE context can still be stored in the UE and MME, e.g. to avoid running an AKA procedure during every Attach procedure.

EMM – REGISTERED

The UE enters the EMM-REGISTERED state by a successful registration with an Attach procedure to either E-UTRAN or GERAN/UTRAN. The MME enters the EMM-REGISTERED state by a successful Tracking Area Update procedure for a UE selecting an E-UTRAN cell from GERAN/UTRAN or by an Attach procedure via E-UTRAN. In the EMM-REGISTERED state, the UE can receive services that require registration in the EPS.

TRANSITIONS between States

First let’s see the transitions between these states, then look at the S1 release procedure. The pictures are shamelessly copy-pasted from the Spec [TS 23.401].

EMM_State_Model_UE

 

EMM_State_Model_MME

 

ECM_State_Model_UE

 

ECM_State_Model_MME

 

Now, further on, let’s talk about the

S1 release procedure – TS 23.401 – section 5.3.5

The message flow appears below and the result is:

– The S1-U bearers for the UE are all torn down; the S5 bearers stay active
– The UE goes into ECM-IDLE state
– The IP remains bound to the UE

S1_Release_Procedure

The initiation of S1 Release procedure is either:

-eNodeB-initiated with cause e.g. O&M Intervention, Unspecified Failure, User Inactivity, Repeated RRC signalling Integrity Check Failure, Release due to UE generated signalling connection release, etc.; or

-MME-initiated with cause e.g. authentication failure, detach, etc.

…TAU in the next chapter…