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?

Tags: Delete Bearer Request, ECM-CONNECTED, ECM-IDLE, LTE, MME, passion, SAE, SGW, TAU, techie

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?

Tags: ECM-CONNECTED, ECM-IDLE, LTE, SAE, TAU, techie

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

Relocation_States

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.

Tags: ECM-CONNECTED, ECM-IDLE, eNB, handover, MME, mobility, SGW, TAU, techie, UE

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:

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…

Tags: ECM, ECM-CONNECTED, ECM-IDLE, EMM, EMM-DEREGISTERED, EMM-REGISTERED, LTE, S1 release procedure, SAE, TAU, techie