/me HAPPY !!! 8->

Tags: happy

Sym no 5.

Tags: music, passion

I’ve kept saying I was going to post this:

http://eventhelix.com/

In  my opinion, a very good tutorial website for LTE – radio. The EPC part is kindda old – it presents the March 2009 spec, but still good for the general idea.

Enjoy!

Tags: EPC, IMS, links, LTE, passion, SAE, techie, tutorial

Doing some more reading in the TS 29.061, I ended up in some other dilemmas.

The following information results from this spec so far (as per my understanding):

1. the PGW acts as a “proxy” for the SIP-IMS messages, encapsulating them in GTPv1-U

2. in order for the PGW to locate the P-CSCF, this PGW can have a pre-configured list of P-CSCFs

3. when the UE connects to that APN, the PGW must look through the list of pre-configured Ps, verify which ones are still up (by using ICMP, for example) and send to the UE a list of Ps; if there are multiple Ps in the list, the PGW will use the PCO IE to provide to the UE a prioritized list of Ps

Now, the dilemma comes. As the PGW is a control-plane entity and a user-plane entity in the 4G world, it can send both 4G control-plane messages (to the SGW – that may propagate or not till the MME – GTPv2-C messages) and user-plane messages (which are GTPv1-U messages encapsulating SIP, DHCP, whatever protocol).

TS 29.061 states the following, about how the PGW sends the IP / IPs of the P-CSCF to the UE: – section 13a.2.2  IMS Specific Procedures in the GGSN/P-GW:

The GGSN/P-GW shall then provide only those P-CSCF address(es) that are available in a Create PDP Context Response/Create Bearer Response.

Now, there are 2 issues with this statement:

1. the Create Bearer Response message is actually sent FROM the MME/SGW TO the PGW; the PGW is the one sending the Create Bearer Request message

2. disregarding item 1 and only thinking about the fact that the PGW will send the IP of the P-CSCF as part of the GTPv2-C signaling (rather the proxying it via the GTPv1-U tunnel), TS 29.274 leaves no room for more IEs in the Bearer Context grouped IE:

Table 7.2.3-2: Bearer Context within Create Bearer Request

So, if the 3GPP guys actually claim to configure multiple P-CSCF addresses in the above grouped IE, where are they putting those IP addresses?

where:

IMS – IP Multimedia Subsystem

P-CSCF – Proxy Call Session Control Function

PGW – PDN Gateway

PDN – Packet Data Network

SGW – Serving Gateway

MME – Mobility Management Entity

UE – User Equipment

IE – Information Element

GTP – GPRS Tunneling Protocol

Tags: 4G, HSS, IMS, LTE, P-CSCF, passion, PGW, SAE, techie

I’ve been looking, as one of this blog’s readers asked for, a 3GPP spec to describe the functionality of the PGW (or SGW)..or, for the matter of fact, the 4G network element that deals with the IMS interaction. The common sense advised me the “culprit” in this matter should be the PGW.

[The reader is Jason Miller - RCS Engineer at Verizon Wireless :d ]

And TS 29.061 confirmed my idea

First let’s take a short look at the 4G – IMS picture.

[Show as slideshow]

As you should know by now:

1. MME, unlike SGSN, only does control-plane traffic, only GTPv2-C signaling

2. SGW does both signaling and user-plane traffic

3. all user-plane traffic that flows from the eNB via the SGW to the PGW is encapsulated in GTPv1-U tunnels

4. there is a “default” bearer structure that represents the connection of the UE to the PGW (PGW being the one that allocates the IP for the UE and it is also the main anchor point for mobility purposes) – this bearer is only used for fallback and the specs don’t recommend sending user-data over it; the QoS and attributes of the default bearer reside in the local 4G HSS database, connected via S6a to the MME

5. in order to be able to better shape the user-plane traffic, there are “dedicated” bearer structures that have a QoS class associated; the PCRF contains the information about these bearers, classifying traffic according to its importance; the PGW is the one responsible to communicate with PCRF, gather these rules and trigger the dedicated bearers creation to sustain this traffic

6. the PGW deals with encapsulation of the downlink data into the correct GTPv1-U tunnels according to the appropriate QoS settings – which results in specific user-plane bearer identifiers being used to identify these tunnels; also, the PGW deals with the decapsulation of the uplink data traffic and routing it to the appropriate destination in the Internet/IMS networks/intranet…etc. As the enforcer of the QoS patterns, the PGW acts as border MPLS router, translating the bearer QoS structures into plain IP QoS structures

In the TS 29.061 – section 13.a, the 3GPP guys shortly define the roles of the PGW:

Interworking with the IP Multimedia Core Network Subsystem (IMS) puts additional requirements on the GGSN/P-GW. When the MS/UE connects to the IP Multimedia Core Network Subsystem (IMS), specific parameters in Session Management messages may be handled. The IMS specific parameters are: IMS signalling flag, P-CSCF address request, returned P-CSCF address(es) and flow identifier(s).

For interworking with the IMS, the Gx interface (see 3GPP TS 29.212 [75]) is used to correlate the session (SIP/SDP) and the bearer (PDP Contexts).

The mechanisms in GGSN/P-GW to support IMS shall be:

-     P-CSCF discovery.

-     Dedicated signalling bearer (e.g. PDP contexts) (with or without enhanced QoS) for IMS signalling; with associated packet filters to permit signalling to/from designated servers.

-     Gx interface for policy and charging control of bearer (e.g. PDP contexts) for IMS media flows.

These mechanisms are however not restricted to the IMS and could be used for other services that could benefit from these mechanisms.

* the details can be read from the TS

Tags: 4G, HSS, I-CSCF, IMS, LTE, P-CSCF, passion, PCRF, PGW, S-CSCF, SAE, SGW, techie, UE

passion for Andrea Bocelli

Tags: music, passion

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.

[Show as slideshow]

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

cine zicea ca romanii nu stiu muzica

Tags: music, passion

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…

[Show as slideshow]

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

Tags: eNB, LTE, MME, Paging, passion, SAE, SGW, techie, UE