10
Aug
Archive for August 10th, 2010
10
Aug
TAU dilemmas – take tz
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.
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.
Tags: ECM-CONNECTED, ECM-IDLE, HSS, LTE, MME, passion, SAE, SGW, techie, UE, UE triggered service request
10
Aug
TAU dilemmas – take 3
PGW initiated dedicated bearer creation versus Downlink Data Notification
There are 2 scenarios that involve the “awakening” of the UE from ECM-IDLE to ECM-CONNECTED:
A. The PCRF decides the creation of a new dedicated bearer, via the Create Bearer Request message. The Spec (TS 23.401) describes this procedure in 3 places:
1. TS23.401 – 5.4.1 Dedicated bearer activation
- in step 3 (corresponding to the sending of Create Bearer Request from SGW to MME), it states that, if the UE is in ECM-IDLE, then the MME with do the “network triggered service request” procedure (5.3.4.3) first, buffering the Create Bearer Request message received from the SGW, until it awakens the UE
2. TS23.401 – 5.3.4.3 Network Triggered Service Request
- this section starts with an introduction that indicates the procedure should begin from step 3 if this procedure is triggered by a control-plane signaling coming from the SGW (like in my case); and step 3 is Paging the UE
- after this, the procedure “calls” yet another procedure, namely the UE triggered service request procedure
3. TS23.401 – 5.3.4.1 UE Triggered Service Request
- this procedure includes the NAS Service Request, the Authentication process and the setup of the bearer contexts
It’s like calling recursive procedures in programming. Very hard to follow, when trying to understand a scenario. Visually it should look something like this…
B. The “second” scenarios happens (or at least to my understanding happens) specifically when there is downlink data to be sent from the SGW to the UE, without (necessarily???) having to send control-plane signaling.
In this case, the hop-by-hoping through the sections of TS 23.401 starts with
1. TS 23.401 – 5.3.4.3 Network Triggered Service Request
with Step 1
and, nevertheless, we get to
2. TS 23.401 – 5.3.4.1 UE Triggered Service Request
which is executed fully, just as in the first scenario, then the execution flows goes back to 5.3.4.3