Happy New Year!

To you all - Happy New 2013!
All the best in New Year, for you, your families and close ones.


Have a good time. Regards,
Bart Barton

P.S. Come back for more of LTE/EPC shortly ;-)

Resource: filtering, principles, measurements durring HO, and more on Radio part

Yesterday I found good resource on multiple LTE Radio topics covered by one site.
To Whom it may concern.

Enjoy!

Multiple LTE Radio topics

• How Handover Filtering by UE in LT?
• Handover principles and Handover measurements in LTE
• Handover Algorithm and Procedure in LTE
• What is AMC & its Algorithm in LTE  
• How UE Switch to Service types in LTE?
• PLMN selection in “IDEL Mode” for LTE-UE
•   
• and much more from radio side
http://www.teletopix.org/category/4g-lte

EPS Mobility Management (EMM) and Connection Management (ECM) states

The EPS Mobility Management (EMM) states describe the Mobility Management states that result from the mobility management procedures e.g. Attach and Tracking Area Update procedures.
There are two EMM states described in Specs:

• EMM-DEREGISTERED
• EMM-REGISTERED

The EPS Connection Management (ECM) states describe the signalling connectivity between the UE and the EPC.
There are two ECM states described in Specs:

• ECM-IDLE
• ECM-CONNECTED

In general, the ECM and EMM states are independent of each other. Transition from EMM-REGISTERED to EMM-DEREGISTERED can occur regardless of the ECM state, e.g. by explicit detach signalling in ECM-CONNECTED or by implicit detach locally in the MME during ECM-IDLE. However there are some relations, e.g. to transition from EMM-DEREGISTERED to EMM-REGISTERED the UE has to be in the ECM-CONNECTED state.

The Sy interface - between PCRF and OCS

Now I have more work to do then I had and it's all focused on GGSN node part and additional equipment not covered by 3GPP specs.Few months ago, in comments some of you asked me to look deeper into the Sy interface. Have to admit that hadn't have much time lately and.. let's be honest, some kind of a mood to research, put together and publish new articles.

Back to the point where we should start.
     

The Sy interface overview

The Sy reference point is defined between the PCRF and the OCS. Big picture of the relationships between functional entities are shown in Fig 1. below.

Fig. 1. Sy overview

As you may (even should) notice on Fig 1. above are simoultaneously SPR and UDR. Those entities work separetly, that means if there is SPR with Sp interface, there is no UDR with Ud interface in the network. Those were put one one figure to save space. Cojunction or means there is the one OR the other. When UDC architecture is used, the SPR with Sp interface, whenever mentioned in this document, is replaced by UDR and Ud.

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..

Offline Charging System (OFCS) - introduction to Gx interface

Last time I tried to familiarize You with Online Charging System (OCS), with was a introduction to Gy based on a diameter. But before I will go to the diameter, and all those CCRs and CCAs just I wanted to talk about Offline Charging System.

What is Offline Charging System (OFCS)?
According to TS 32.240 and TS 32.299 3GPP documentation:
Offline charging is a process where charging information for network resource usage is collected concurrently with that resource usage. The charging information is then passed through a chain of logical charging functions, which are described below. At the end of this process, CDR files are generated by the network, which are then transferred to the network operator's Billing Domain for the purpose of subscriber billing and/or inter-operator accounting (or additional functions, e.g. statistics, at the operator’s discretion). The BD typically comprises post-processing systems such as the operator's billing system or billing mediation device.

Generally offline charging is a mechanism where charging information does not affect, in real-time, the service rendered.
As it's always good to start with a high level design picture, let's start.

Fig. 1. Offline Charging high level architecture

Where:

CTF: Charging Trigger Function

CDF: Charging Data Function

CGF: Charging Gateway Function

BD: Billing Domain. This may also be a billing system/ billing mediation device.

Online Charging System (OCS) - introduction to Gy interface

Previously I wrote about network elements and interfaces between them, now it's time to write about most important thing in a mobile network, from operator's side.
How to charge customers for the fact they are using mobiles to many activities, including web surfing. Today I'm going to present some informations about Online Charging System (OCS), how does it work, its call flow basics scenarios, and last but not least basic principles.

As always is good to know about what we will be talking about, so please have a look at high level architecture concept of online charging.
Ro is reference point from the Charging Trigger Function (CTF) to the Charging Data Function (CDF) and the Online Charging Function (OCF) respectively, and are intended for the transport of charging events. Ro reference point is equivalent to Gy interface.

Fig. 1. Online charging high level architecture

Where:
CTF: Charging Trigger Function
CDF: Charging Data Function
CGF: Charging Gateway Function
BD: Billing Domain. This may also be a billing mediation device / post-processing system.

Interfaces and their protocol stacks

After familiarising with main network elements, time has come to better know interfaces between those elements.
Interfaces are allowing MME, SGW and PGW cooperating with other network elements( e.g. HSS or PCRF).
Each one of them is built in standardised way described by 3GPP.org. Each interface described here is taken from 23.401 3GPP.org documentation.
Please keep in mind, that the documentation is (sometimes) bigger than we need it to be, so not every aspect of interfaces is described here.

Lets start with big picture of situation in which user is not roaming.

Fig.1. Non-roaming architecture by 3GPP

Functions of main LTE packet core elements - MME, SGW, PGW

Now when I have to start writing, I'm looking deep into back of my skull, to figure out with what I have my first LTE-like problem. And you know what? I don't remember.
So maybe the best way of starting anything is to start (writing) from the beginning.
Let's have a closer look at three main packet core elements of LTE network.

MME - Mobility Management Entity
MME is the key control node for LTE access network. It is responsible for tracking and paging procedure including retransmissions, and also for idle mode of User Equipment (UE). MME is also involved in bearer activation and its deactivation procedures, to its task also belongs choosing the SGW for a UE in process of initial attach and when the intra-handover take place which involves Core Network (CN) node relocation.
MME is responsible for authenticating user towards the HSS, if user is roaming MME terminates S6a interface towards user's home HSS. All Non Access Stratum (NAS) signaling terminates at the MME point, which is also responsible for generation and allocation of temporary UE identities (GUTI). Among its duties is also authorization UE to Public Land Mobile Network (PLMN) and enforcing UE roaming restrictions if there are any. MME is also termination point of ciphering and integrity protection for NAS signaling. Lawful Interception (LI) of signaling could be also supported by MME entity. It also provides the control plane function for mobility between LTE and 2G/3G networks by the S3 interface( from SGSN to MME).

This is where it all start

For all you people who will come to this site (some day I hope), I will try to publish posts about LTE/4G technology, but not only.

Being totaly honest, my idea for this tech-blog is to create but mostly to gather materials that helped me achive level of knowledge on which I am now. Of course I will be puting links to sources other blogs or 3gpp docs. I wont be asking for permission, but I'm not a thief.


Why do I am doing it?
I started doing this after being send to Hungary to work  on EPC. I noticed that I have many free time, and would rather do something for myself and maybe for others who are always looking for info, rather than just drinking beer, or watching cat videos.

Oh, and one more thing. As you can see English is not my native language, so if any of you spot something disturbing in spelling, grammar or also will have doubts as to the substantive content please feel free to write them in comment or let me know about this by email.