Posts Tagged ‘ECM-CONNECTED’

Uplink data while in ECM-IDLE

I know this sounds (at least a bit) weird. Why? Because the nice fellows from 3GPP state bravely that ECM-IDLE means NO USER-PLANE Bearers. Mwell, that’s not precisely (nor entirely) true.

Should you look at TS 23.401 – 5.3.5 S1 Release Procedure, the introduction states:

This procedure is used to release the logical S1-AP signalling connection (over S1-MME) and all S1 bearers (in S1-U) for a UE. The procedure will move the UE from ECM-CONNECTED to ECM-IDLE in both the UE and MME, and all UE related context information is deleted in the eNodeB.

Unfortunately, this is not exhaustive. The things described here DO happen, but something ELSE DOES NOT happen.

Step 3 in the procedure clarifies the situation:

3.   The S‑GW releases all eNodeB related information (address and TEIDs) for the UE and responds with a Release Access Bearers Response message to the MME. Other elements of the UE’s S‑GW context are not affected. The S‑GW retains the S1-U configuration that the S‑GW allocated for the UE’s bearers. The S‑GW starts buffering downlink packets received for the UE and initiating the “Network Triggered Service Request” procedure, described in clause 5.3.4.3, if downlink packets arrive for the UE. If the MME sends UE’s Location Information in step 8, the S‑GW sends a Modify Bearer Request to the PDN GW including the User Location Information IE.

Ok, so the 3GPP guys let us believe the ECM-IDLE ==EQUALS== NO user-plane bearers. OK, point taken, there are some bearers still up.

Buuut, this affects us when talking about the following scenario:

Take a look at the TS 23.401 – 5.3.4.1 UE Triggered Service Request. What is this section actually describing? Well, it says that the UE, while in ECM-IDLE simply decides to make traffic. What does it do first? Well, it has to become CONNECTED, that’s for sure, so it re-authenticates to the HSS via the MME, then the MME sends its eNB a S1-AP: Initial Context Setup Request. After the Radio Bearers are up, the UE CAN IMMEDIATELY SEND TRAFFIC in UPLINK.

!!! You will notice that, at this point, the UE is not in ECM-CONNECTED, as we define this state, meaning that there are no eNB S1-U bearers up. STILL, should you keep in mind the observations in the beginning of this post (that the SGW S1-U TEIDs are NOT deleted in the S1 Release Procedure), the eNB actually has the Uplink TEID, so it CAN encapsulate the Uplink data of this UE. The TEID of the SGW S1-U interface is passed on to the eNB by the MME, via the S1-AP: Initial Context Setup Request message.

calls

You’ll notice that barely after the UE actually uplinks data is the MME and SGW updating this UE’s information so that we can truly say it is in ECM-CONNECTED state.

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?

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.

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…