Resource: RF and Microwave Engineering Tutorial Site

Lately I don't have spare time to read and prepare something for all of you.

Today I hit really good resource covering RF and Microwave and radio signal modulation in one place.
I wish I found that when I was at the University. For all of you who can find it useful.

Enjoy!

RF and Microwave Engineering Tutorial Site

• Comprehensive – Everything about Wireless, RF and Microwave
• Media rich - Graphics, Images, Videos, Animations, Flashes, Calculators, Java Applets
• Unique - No such tutorial exists today anywhere on the Web!
• Practical
• Free
http://rf-mw.org/table_of_contents_toc.html

Tracking Area Update (TAU) procedure

In this article major topic will be Tracking Area Update (TAU) procedure. What cause it, how the procedure made and what it causes for UE.

Because there are couple of reasons why TAU can take place we won't start from picture as always.

Almost all what you will see below you can read in details in 3GPP TS 23.401.
Also, maybe you are looking for Periodic Tracking Area Update, don't you huh?

Triggers for TAU procedure

When TAU procedure is taking place SGW can be changed or not, but what really bring Tracking Area Update procedure to live is what we should ask about.
According to the spec I've mentioned above a standalone tracking area update occurs when a GPRS-attached or E UTRAN-attached UE experiences any of the following conditions:

• UE detects it has entered a new TA (Tracking Area) that is not in the list of TAIs (Tracking Area Indicators) that the UE registered with the network;
• the periodic TA update timer has expired;
• UE was in UTRAN PMM_Connected state (e.g. URA_PCH) when it reselects to E-UTRAN;
• UE was in GPRS READY state when it reselects to E-UTRAN;
• the TIN indicates "P-TMSI" when the UE reselects to E-UTRAN (e.g. due to bearer configuration modifications performed on GERAN/UTRAN);
• the RRC connection was released with release cause "load re-balancing TAU required";
• the RRC layer in the UE informs the UE's NAS layer that an RRC connection failure (in either E-UTRAN or UTRAN) has occurred;
• when the UE changes the radio capability of at least one of the following radio access technologies: GERAN, UTRAN or CDMA 2000;  *
• for a UE supporting CS fallback, or configured to support IMS voice, or both, a change of the UE's usage setting or voice domain preference for E-UTRAN.
• for a SR-VCC capable UE, a change of MS Classmark 2 and/or MS Classmark 3 and/or Supported Codecs.
• UE manually selects a CSG cell whose CSG ID is absent from both the UE's Allowed CSG list and the UE's Operator CSG list.

For all cases except case "periodic TA update timer" UE shall set the EPS update type IE to "TA updating", but for "TA update timer" case the UE shall set the EPS update type IE to "periodic updating".
For trigger marked with "*" the UE shall include a UE radio capability information update needed IE in the TRACKING AREA UPDATE REQUEST message.
The TAU procedure is initiated by an UE in either ECM-IDLE state or ECM-CONNECTED state. The decision to perform SGW change during the tracking area update procedure is made by the MME independently from the triggers above.

The eNodeB shall include TAI+ECGI of the current cell in every S1AP Uplink NAS Transport message it sends. There are situations where eNodeB can contain cells from more than one TA and cell changes that happen on same sNodeB are not notified to the MME. However to finish TAU procedure with accept message MME needs to know UE's current TAI.

eUTRAN to UTRAN (4G to 3G) Iu mode handover

Few last articles were about Handover in LTE network. From old eNB to new eNB, with or without using new MME/SGW, with or without using X2 interface, and so on.
Today we will be talking about handovers from eUTRAN to UTRAN, from 4G to 3G.

Sorry guys, today I don't have time to create abstract picture which we could use to start from.
But it should be easy for you to imagine.
UE is moving from area where is 4g coverage to area where is only 3g coverage.
eNBs change to RNCs, MME to SGSN, only the mobility anchor (PGW) stays the same.

More about this you can find in 3GPP TS 23.401.

Inter RAT handover - general information

During Inter RAT handover indirect forwarding may apply for the dowlink data forwarding performed as part of the handover. From its configuration data the MME knows whether indirect forwarding applies and it allocates a dowlink data forwarding path on a Serving GWs for indirect forwarding. From its configuration data the S4 SGSN knows whether indirect forwarding applies and it allocates dowlink data forwarding paths on Serving GWs for indirect forwarding. It is configured on MME and S4 SGSN whether indirect dowlink data forwarding does not apply, applies always or applies only for inter PLMN inter RAT handovers.

eUTRAN to UTRAN Iu mode Inter RAT handover

General information

Pre-conditions:

• The UE is in ECM-CONNECTED state (E-UTRAN mode).

If emergency bearer services are ongoing for an UE, handover to the target RNC is performed independent of the Handover Restriction List. The SGSN checks, as part of the Routing Area Update in the execution phase, if the handover is to a restricted area and if so SGSN deactivate the non-emergency PDP context.

S1 interface based handover

 Last two articles (you can find them here1 and here2) were about handover in scenario where there is direct connectivity between eNB. But what happen when there is no X2 connection old and new eNodeB?
Answer to that is S1 based handover procedure which you can find described below.

All of this information you can find by reading specific section of 3GPP TS 23.401 document.

As it is now like a little tradition, we will start with high level of abstract image.

Fig. 1. UE is moving from old to new RAN coverage provided by eNodeB.

This image should look familiar for those who was reading about X2-based handover. The thing what has change in this scenario is that there is lack of connectivity between two eNBs between which UE moves.
That's why, to do the handover the MMEl has to be involved directly. If you compare previous cases with this one, the first thing that each one of you should notice is that here eNodeB is contacting with MME, and the target eNodeB address is found because of SGW.
Before we will see detailed call flow please keep in mind few general S1 handover information.

X2-based handover with SGW relocation

Last time article was about handover based on X2 interface but without SGW change, that is why it's time to deal with X2 based handover with SGW relocation.

All of this information you can find by reading 3GPP TS 23.401.
Today as usually we will start with a high level of abstract picture. Please see below.

As you can see Fig. 1. is almost the same as it was in X2 based handover, where the green arrow was demonstrating the case we talked about last time (if interested you can read about it here) where was no need to change SGW. Today we are interested in case illustrated by blue (azure? blueish?) arrow. Where handover is done bye X2 interface with SGW relocation.
Lines that are green, between UE and eNB, showing changed path on the end of handover operation without SGW change. Blue lines between UE, eNB, MME and new SGW are showing new path after changing old SGW to new.

Fig. 1. UE is moving from old to new RAN coverage provided by eNodeB.

Before we will jump into detailed description of handover few general information about X2 interface based handover.

X2-based handover without SGW relocation

Last article was about IMSI, TMSI and GUTI, and how they are created, it was also mentioned there that GUTI is used in handover (HO) procedure. I thought that today is a good time to say few words about handover.
There are two general types of handovers in LTE.

• X2 based, and
• S1 based

In this article I'm going to describe only X2 based HO and to be perfectly honest with you I have to admit, that I will publish information about X2 based handover with case where no SGW is changed.

For others types please look for different article (After publishing articles describing other HOs I will update this line with direct links. [Update-16-03-2012] First one is X2-based handover with SGW relocation).

All of this information you can find by yourself just by reading 3GPP TS 23.401.

As always it's good to start with general picture, so here it is.

Fig. 1. UE is moving from old to new RAN coverage provided by eNodeB,

As you can see, green arrow is demonstrating UE movement between two eNodeBs controlled by the same MME. Such procedure as you should know is called a handover. In this procedure every bearer set between UE and PGW will be moved to new eNodeB(if target eNodeB is able to handle them).
Please see below general description of X2-based handover according to specyfication.

IMSI, TMSI and GUTI - how they are created

Last time, in article about Network Attach, many times I was using IMSI, P-TIMSI, GUTI and few more numbers. This time I will try to explain most of them. It's good to know what consist on them, how they are created, and what's the purpose of using them.

As always is good to start with a big picture, that this time, we will start with general description of mentioned above.

Mobile subscribers identification

General information

A unique International Mobile Subscriber Identity (IMSI) shall be allocated to each mobile subscriber in every (GSM, UMTS, and EPS) system. In order to support the subscriber identity confidentiality service the VLRs, SGSNs and MMEs may allocate Temporary Mobile Subscriber Identities (TIMSI) to visiting mobile subscribers. The VLR, SGSN, and MME must be capable of correlating an allocated TIMSI with the IMSI of the Mobile Station (MS) to which it is allocated.

An MS may be allocated three TMSIs, one for services provided through the MSC, one for services provided through the SGSN (P-TIMSI for short) and one for the services provided via the MME (M-TIMSI which is part of GUTI).

For addressing on resources used for GPRS, a Temporary Logical Linkt Identity (TLLI) is used. The TLLI to use is built by the MS either on the basis of the P-TIMSI (local or foreign TLLI), or directly (random TLLI).

In order to speed up the search for subscriber data in the VLR a supplementary Local Mobile Station Identity (LMSI) is defined. The LMSI may be allocated by the VLR at location updating and is sent to the HLR together with the IMSI. The HLR makes no us of it but includes it together with the IMSI in all messages sent to the VLR concerning that MS.

LTE attach procedure

Last two articles was about Offline and Online charging interfaces. So now, after we know "how the things are  are going" in charging domain, it's a good time to describe how UEs are able to being charged for services they receive.

Always it's good to start with a high level abstract picture, but not today.
Being honest, today I'm a little bit lazy and just don't want to draw network architecture myself. You can easily find that on Google image search engine.
Information below are part of 3GPP TS 23.401, I just copied them. Below is everything you need to know about Network Attach procedure in LTE with many references.

UE needs to register with the network to receive services that require registration. This registration is called Network Attachment. The always on IP connectivity for UE is enabled by establishing a default EPS bearer during Network Attachment procedure. Predefined PCC rules most common set in PGW will be applied for default bearer. Attach procedure may trigger one or multiple Dedicated Bearer Establishment procedures to establish dedicated EPS bearer for that UE.
During the Initial Attach procedure the Mobile Equipment Identity is obtained from the UE. The MME operator may check the Mobile Equipment Identity with EIR. At least in roaming situations, the MME should pass the ME Identity to the HSS, and, if a PGW outside of the VPLMN (Visited PLMN), should pass the ME Identity to the PGW.

The E-UTRAN Initial Attach procedure is used for Emergency Attach by UEs that need to perform emergency service but cannot gain normal services from the network. These UEs are in limited service state (more about this in 3GPP TS 23.122). Also UEs that had attached for normal services and do not have emergency bearers established and are camped on a cell in limited service state shall initiate the Attach procedures indicating that the attach is to receive emergency services. UEs that camp normally on a cell, i.e. UEs that are not in limited service state, should initiate normal initial attach when they are not already attached and shall initiate the UE Requested PDN Connectivity procedure to receive emergency EPS bearer services.

Gy interface - sitting between OCS and PCEF

Last time I tried to cover Gx interface topic, with many details such as Diameter based PCC rules flow, short description on PCEF and PCRF functions, and Policy Charging and Control (PCC) itself. Every thing what I just mentioned you can find here. Almost whole article is based on information mentioned earlier. I will put links to every section if needed.

Gy is between Online Charging System (OCS) and PCEF. In most cases PCEF is based inside PDN GW (Packed Data Network Gateway) or just short PGW.

Gy interface allows online credit control for service data flow based charging. 

As always, today is also good way to start with a quite high level abstract figure. So.. please enjoy.

Fig. 1. Gy reference point at the Policy Charging and Control (PCC) architecture

The basic structure follows a mechanism where the online client (in OCS represented by CTF) requests resource allocation and reports credit control information to the Online Charging System (OCS). As described earlier charging could be based on different Charging Scenarios.

Gx interface - sitting between PCRF and PCEF

After you are familiar with OFCS (Offline Charging System) and OCS (Online Charging System) time has come to be more up to date with interfaces that are being used to exchange signaling data. At first I will talk about Gx interface which is responsible for Offline Charging, but not only.

The Gx reference point is located between the Policy Control and Charging Rules Function (PCRF) and the Policy and Charging Enforcement Function (PCEF). The Gx reference point is used for provisioning and removal of Policy and Charging Control (PCC) rules from the PCRF to the PCEF and the transmission of traffic plane events from the PCEF to the PCRF. The Gx reference point can be used for charging control, policy control or both by applying AVPs relevant to the application.

As you probably know, it's always good to start from big picture. Here we go.

Fig. 1. Gx reference point at the Policy and Charging Control (PCC) architecture

So at first, few information about..