What are Modes, States and Transitions in GSM, UMTS

and LTE?
Hello friends. Today we will talk about a very important issue for those working with mobile
communications: what are the different modes and states that a mobile phone can take,
as well as how the transitions occurs between each of them.

The concept is simple, but the great amount of detail can end up making the topic an
extensive or complex task. This ends up causing many people simply give up trying to
understand, or even not to be interested about know such details.

However, the lack of knowledge of these key points of operation (when transitions occur,
why they occur, etc.) ultimately affects the understanding of other areas of the mobile
network, since the operation of the entire network is based on that. Not really
understanding this fundamental base of operation, then yes is that we run the risk of
thinking that everything is too complicated.

So we will try to show in a very simplified way all the key concepts involved in the modes,
states and transitions that a mobile can have on a 2G/3G/4G network. We hope that by
the end of this tutorial all that is shown in the following figure are clearer to you.

Note: This tutorial just getting a little long, and could be been divided into 'parts'. However,
we decided by the maintenance of the centralized content. Feel free to read it the way you
prefer - by parts, at once. All right?

So let's take a deep breath, and let's begin.

Note: All telecomHall articles are originally written in Portuguese. Following we translate
to English and Spanish. As our time is short, maybe you find some typos (sometimes we
just use the automatic translator, with only a final and 'quick' review). We apologize and
we have an understanding of our effort. If you want to contribute translating/correcting of
these languages, or even creating and publishing your tutorials, please contact
us: contact.
 Mode Off (Dead)

To demonstrate (always using our simple way of exemplifying) we start from the basic so
that the mobile can be: Off!

In this case, we do not have much to talk about, don't you agree? When the mobile is off,
it does not 'appear' to the network. Do not waste battery, does not consume network
resources. In terms of the network, it serves no purpose.

But serves at least for we to begin to understanding today's concepts: this is a 'mode' that
the mobile can take!

Location

Already making a short stop, before moving forward: a parenthesis in our conversation.
Before proceeding to the next modes and states, we need to talk about another important
issue, closely related to the theme, and one that should also be well understood: the
location of the mobile, and how the network sees it.

This is because the location of the mobile has a significant role in the ways and especially
in transition states that it can take. We must remember, even if very quickly, some basic
concepts of location in mobile systems.

The general rule is that whenever the mobile detects that it has changed cell, it performs
a procedure to inform the network its new location, ie, makes an update of its position,
stating its current 'location identifiers' in specific messages.
The following figure shows the different possible location identifiers, from the point of view
of RAN (Radio Access Network) and also Core CS (Circuit-Switched) and Core PS (Packet-
Switched).

For example, if the mobile moves from cell 'A' coverage area for the cell 'D' coverage area,
it performs a 'cell update' procedure and informs the network that now is being served by
the cell 'D' .

This is the general rule, and similar procedures occur whenever there is any change from
one area to another (whether an area of the cell, URA, LAC or RAC).

Of course the above rule does not set it all - there are still many aspects and concepts to
consider (for example, the cell update may be triggered by other events not only relating
to location). But it isn't our goal today, as we are seeking only to know the modes and
states. So we will continue, but feel free to extend after the study in the areas that you
are interested - will definitely be worth it.

Idle Mode

So we will continue knowing the modes.

The next mode that the mobile can take is quite intuitive: on. But the mode name is not
that - after being turned on and consequently turn out to be perceived by the network, we
say the mobile is in 'Idle' mode.

In idle mode, besides be seen (known) by the network, the mobile also comes to see
(know) the network and can then interact with it.

As such interaction in idle mode, the mobile can 'camp' in a given cell.
Even without knowing yet which means the mobile 'camp' in a cell, we can say that when
in idle mode mobile carries a huge amount of operations, depending for example of their
available technologies (2G, 3G and/or 4G ) or network where they are.

And it really is a lot that happens. You can check on the screen, so you turn on your
mobile: first comes a message that the mobile is searching the network. As soon as it
finds, come the antenna bars, followed by some indication of the type of technology that
it could connect (GSM, HSDPA, LTE, etc.). And to conclude, the name of the operator (or
any other message that it uses as ID).

At this time, we say that the mobile is 'camped' in a cell of the network.

We understand that it is 'aware', both to start and to receive a completed call. It does not
have an allocated dedicated channel, and can not make or receive calls. So it should be
constantly monitoring the available communication channels, to know what to do when
the time is right.

In this state, the mobile has no active connection to the network, and any data
transmission will require an establishment (or reestablishment) of a control connection, to
only then start to transmit data. It does not transmit almost nothing in that state (only in
some cases, small information only to update their registration area).

That is, the radio is 'asleep' most of the time and only wakes up when necessary - when
instructed to participate in any activity.

In the specific case of 4G mobile in idle mode, it has the support activities to the DRX
(Discontinuous Reception), System Information (SI System Information) for access, cell
reselection and paging information.

And in the specific case of 3G mobile in Idle mode, it stays listening to hear the CPICH
channel (Common Pilot Channel) of the cell where it is camped and also the neighbor cells.
Also listening to the PICH channel (Paging Channel Indicators). In the latter, he seeks its
'Paging Indicator' - a true or false value that tells whether it should read the Paging
Channel. In other words its 'Idle DRX' cycle (Discontinuous Reception).

To enter this mode, the mobile makes contact with your PLMN, seeking a suitable cell that
can provide you the service, and tunes to its control channel. As already mentioned, this
choice or tuning is what we call 'camp' in the cell - the mobile will register its presence in
that registration area.

If the mobile lose the coverage of this cell, it selects (search) a more suitable cell available,
and camps on that other - making a reselection.

But let's take a moment here: although the cell selection and reselection are closely related
concepts to the modes, states and transitions concepts, we are delving much a topic that
is not the main goal today. Let us return to the idle mode, in general. If so, and if there is
interest, we talk more specifically about this or other topics in another tutorial.

Returning (and summarizing) then the goal of the mobile camping on a cell in idle mode
is that it can receive information from the network. For calls originated by it, it already
starts the call in the corresponding control channel, from the the cell it is camped. And in
the case of terminated calls, the network previously known its location information, and in
which area it is, and then sends a 'paging' message for it in control channels of this
registration area, from where the it answers.

If we seek the direct meaning of Idle, we find something like 'not doing anything'. But not
quite exactly what happens. In addition to the initial procedures described above (power-
on procedure), the mobile continues to carry out many other activities.

Airplane mode

Although not illustrated in the figure above, the act of turning on (power-on) is not the
only one that takes the mobile into idle mode. The mobile can go into idle mode also when
we turn off the its 'airplane' mode.

This is a very particular mode, and in terms of network, we can consider the act of putting
the mobile in airplane mode as 'turning off the network'. Similarly, turn off airplane mode
is equivalent to 'connect to the network'.

Airplane mode, as the name suggests, was originated due to the ban on the use of wireless
mobile phones on airplanes. The 'problem' actually refers only to the use of radio frequency
device. So, it was created the option to turn 'off' only the radio part of the device, leaving
users free to use other features, such as games and tools like text editors and
spreadsheets.

And of course, it is not necessary to be on a plane to use this mode. Airplane mode can
be used whenever there is need to 'turn off'/'turn on' the device radios - without having
to wait for it to a complete restart.

When the mobile is switched on (or when Airplane Mode is turned off), it enters the mode
we already know: the Idle mode.

We will continue to know another mode that the mobile can take.

Unless you make (for example, call someone) or receive a voice call, or to make or receive
a data call (for example, browsing a web page), you will remain in Idle mode.
But if a call comes, then everything changes. The mobile switches to the mode known as
Connected mode.

Connected Mode

Okay, so far we understand how mobile comes in idle mode, and also that, although the
name does not indicate it is a very important mode, where much happens.

But the goal of every mobile is to transfer data in the form of calls, either voice or data.
And when the mobile is one of these calls, we say that it is in connected mode!

Unlike Idle mode, where we can do just about the same considerations for 2G technologies,
3G and 4G, the Connected mode considerations are different for each one.

The fact that is common to all is that when the mobile needs to initiate communication, it
needs to establish a control connection, and then a connection that allows traffic
information.

In the case of 3G and 4G: when the mobile initiates a call, it first sends a request to
establish a signaling connection. & Nbsp; Then it is then initiated RRC connection
establishment procedure (Radio Resource Control). When the RRC connection is
established, the mobile enters the Connected mode.

Note: In the case of 2G, the idea is the same, but some other concepts appear. As our
tutorial should get a little long because of the number of concepts that will be covered,
and because the transition from 2G states requires a little further explanation (concepts
only 2G), we will leave these detailed explanations for another tutorial if there is interest
from our readers. In any event, although not explained here, 2G state transitions remain
represented in the complete image.

At first, we are led to understand the connected mode simply as the 'opposite' of Idle
mode. Unfortunately, the picture is not so simple.

Today, it is increasing the number of smartphones on the market, whose side benefit was
greater adoption (mass) of data usage. Actually this range was very large, and is growing
bigger each day.

However, brought a challenge on how to support this signaling 'tsunami' that such massive
use of data requires.

The now many users want all to be connected at the same time, in many different types
of applications.

For several reasons and mechanisms, each of these smartphones periodically active and
disables its connections.

While the goal is that the user has the perception of always connected, the amount of
signaling makes this mission almost impossible.

Fortunately, to minimize this problem were created different 'states' in connected mode!
Although this tutorial are seeking generally to understand the state and mobile operating
modes in a network, UTRAN modes (3G UMTS) and E-UTRAN (4G LTE) has some states
and concepts more specific. So let's proceed, but speaking separately on each of them.

3G Connected Mode

When a 3G mobile is in connected mode, its level of connection with the UTRAN is
determined by the QoS requirements of the RAB active, and traffic characteristics.

The challenges in UMTS to keep a lot of users connected led to mechanisms and
implementations that seek to minimize this scenario.

For example, some implementations seek to minimize the mobile battery consumption,
and other implementations seek to reduce the signaling. Fast Dormancy functionality
(provided by the 3GPP in Release 8) also has mechanism to tackle this challenge. Other
features has yet been developed and improved till today.

Ironically, the UMTS systems have been developed to meet the growing demand for
multimedia (data) seen years ago. As was thought in a very large growth data, the system
has been designed in an efficient way to transport these high bit bandwidths, videos, etc.
Even with a slight delay to start, the system served well, especially in cases of high rates.

But in recent years, the seen explosion of data was larger than expected. Smartphones
increasingly cheap and affordable unlimited data plans extended up to prepaid users,
explosion of all kinds applications - especially applications using small volumes of periodic
data with frequent updates.

New applications have emerged or have become more used, such as Social and Messaging
Networks (Whatsapp, Twitter, Facebook), Stock Portfolios, Email/Calendar/Contacts/RSS
Sync.

While the UMTS system allows, it is not designed for this: send and receive very small
amounts of data, often less than 1 kB.

Each of these messages needs a connection with all the associated signaling load!

Many mobile operators keep a higher power channel for a longer period of time when
imagine that it will transmit or receive more data in the near future. But this ends up
spending more battery and taking up resources that could be in use by another user.

To help improve this problem 3G mobile that is in connected mode, there are the states:
CELL_DCH, CELL_FACH, CELL_PCH and URA_PCH.
Let us know each of them, and to facilitate understanding, we will make a classification
according to the items:

 Channel: channels that mobile use in this state are dedicated or shared?
 Knowledge by the network: the network knows where the mobile is in the cell level or at URA
level?
 Data Transfers: the volume of data to be transmitted is large or small?
 Transitions: when you finish downloading, or a particular timer ends, to where the mobile will
go?

From the above ratings, the one you maybe not fully understand is the dedicated or shared
channel. One way to understand the difference between dedicated and shared channel is
making an analogy.

Think of channels dedicated as rooms in a hotel - care guaranteed and individual to the
user. The only problem is that, as a hotel, the number of channels - rooms - is limited.
Anyway, the hotel always try to provide the service in the best possible way - as well as
the network.

Following the same analogy, shared channels would be a conference hall - serves many
more people, but not in the same way serves the rooms.

Let's talk about each of these states, seeking to make the aforementioned ratings.

CELL_DCH (UTRAN) State

If there is a state that is the 3G connected mode, this state is CELL_DCH.

Dedicated Channel. As the state's name suggests, the CELL_DCH (DCH: Dedicated
CHannel) uses a dedicated channel to the mobile in the Uplink and Downlink.

In the CELL_DCH state mobile is in connected mode, and utilizes a dedicated R99 channel
or a shared HS-DSCH (Downlink Shared Channel High Speed) and/or E-DPCH (Enhanced
Dedicated Physical Channel).
Known at Cell level. Also we can sense by the name that the network knows where the
mobile is in the cell level (according to the current Active Set).

Transfers of Large Data Volumes. When the mobile needs to transfer large volumes of
data, this is the ideal state.

But as we know the scenario has changed with the adoption of increasingly common
applications requiring small periodic data transfers. And if we use the limited resources of
CELL_DCH to all establishments and restablishments schemes, the system would
inevitably collapse. In our analogy with hotel rooms, there would be no rooms for
everyone!

The solution is to create an auxiliary state that supports the extra demand. And that means
using shared channels, which define the state that we will see below, the CELL_FACH.

Transitions to Idle or CELL_FACH (or PCH states, as we shall see soon). When the
mobile ends the transfer, it may return to idle mode (releasing the RRC connection), or
switch to the CELL_FACH state (if in a buffer an amount of data to be transferred smaller
than a certain set threshold - or other words, if there is little volume of data to be
transferred).

CELL_FACH (UTRAN) State

Channel Shared. The CELL_FACH state keeps the mobile in Connected mode, only
instead of dedicated physical channel, the mobile uses shared channels.

Compared to the analogy of the dedicated channel as rooms in a hotel, the shared channel
would be the this hotel conference room.

Small volumes data transfer. This makes this ideal state for transmission and reception
of small data packets:

 In Uplink is used the RACH channel (Random Access Channel): the mobile is constantly
transmitting RACH messages.
 For Downlink is used the FACH channel (Forward Access Channel): the mobile is constantly
decoding the FACH channel.
Known at Cell level. In the CELL_FACH state, the network also knows where the mobile
is in the cell level (the cell where the mobile has made the latest 'Cell Update').

Transitions to Idle or CELL_DCH (or PCH states, as we shall see soon). When the
mobile has finished transferring in the CELL_FACH, it may return to idle mode (releasing
the RRC connection), or switch to the CELL_DCH state (if in a buffer an amount of data to
be transferred greater than a certain set threshold - or in other words, if a large volume
of data to be transferred).

But even with the help of CELL_DCH and CELL_FACH (hotel rooms, plus the conference
hall), network capacity may not be enough. Also, if the output options of these states after
the end of the transfer was only the idle mode, we would worst the signaling increasing
problem (reestablishing connections).

But then what is the solution for those cases where it is already occupied? In the case of
hotel: get the name and give a password to each user over the limit, and call them as
soon as possible/necessary.

In the case of 3G network to minimize this problem, there are the PCH states (CELL_PCH
and URA_PCH). Are states where the mobile can be transferred, and not lose their RRC
connection (they were called and got a password).

But for now, can not take advantage of the hotel's services (sending or receiving data).
They can only be aware, and when necessary/appropriate, obtain service.

Let's know the PCH states?

CELL_PCH (UTRAN) State

The CELL_PCH state is one of PCH states, a connected mode so that the mobile can take
and it has some interesting features. Starting with the name: PCH refers to paging.

Although not the same as the idle state, this state closely resembles the behavior in that
way, especially the mobile point of view. The big difference here is that control connection
(RRC) is not lost (although the mobile rarely uses).
Whenever the mobile camps in a new cell it informs the network ('cell update'). Remember
that in the Idle state, the mobile informs the network only when there is change in LA -
Location Area or RA - Routing Area; that is, in this state we have more updates as we the
cell level.

But in this state, as in Idle, the mobile does not transfer data. And every time the mobile
need to send the 'cell update' message, the mobile needs to change temporarily to the
CELL_FACH state.

The mobile keeps listening to the same channels as in idle mode - uses DRX to monitor
the PCH channel selected via associated PICH. The radio remains inactive most of the time
and only wake up in the DRX cycle of the CELL_PCH state (Note: the DRX cycle of the
CELL_PCH state is different from the DRX cycle of Idle Mode).

As mentioned, the control connection is maintained, then any new data transmission can
be performed more quickly and with much less signaling, because it means for only
sending the data that are present.

In this state there is no downlink activity: whenever the mobile needs to transmit or
receive, it goes to the CELL_FACH state.

Known at Cell level. In the CELL_PCH state, the network knows where the mobile is in
the cell level (the cell where the mobile has made the last 'cell update'). Remembering:
the 'cell update' is done in the CELL_FACH state.

No Data Transfers. The only objective of this state are:

 Save energy (using DRX cycle similar to Idle mode)

 Allow quick access to the network, since the network know exactly which cell to send the paging
and because there is no need to set up new RRC connection.

Transitions to Idle or CELL_FACH. If after a certain time, continue without data

transfer, the mobile is released. Otherwise, go to the CELL_FACH state (data is being
transferred).

URA_PCH (UTRAN) State

The fourth and final state (URA_PCH) is virtually identical to the CELL_PCH state. The only
difference is that the 'cell updates' are sent only when the mobile changes URA (UTRAN
Registration Area) instead of Cell change.

With this, the mobile transmits even less frequently that in the CELL_PCH state
(remembering that keeps the control connection active).
Known at URA level. The network knows where the mobile is at the level of URA (UTRAN
Registration Area) according to the URA assigned for mobile during the last 'URA update'
- remembering that the 'URA update', as we saw in the CELL_PCH state, is done only in
the CELL_FACH state.

No Data Transfers. For the reason above, this state is recommended for moviles that
are moving fast. But continues with the similar goals of the state CELL_PCH:

 Save even more energy;

 Allow quick access to the network, since the network knows the URA to which to send the paging
and also because there is no need for new RRC connection setup.

Transitions to Idle or CELL_FACH. If after a certain time, continue without data

transfer, the mobile is released. Otherwise, go to the CELL_FACH state (data is being
transferred).

Comparison between Idle Mode and PCH States (CELL_PCH/URA_PCH)

After knowing the connected paging states CELL_PCH and URA_PCH, we can say that are
equivalent to Idle mode?

No. Remember that in idle mode, we do not have any established RRC connection, unlike
that in the CELL_PCH and URA_PCH states, where this connection still exists.

It is important not to be confused with the fact that in Idle Mode and CELL_PCH and
URA_PCH states the mobile has no radio resource allocated! For this reason, it can not
initiate any type of data transfer in dedicated and common channels. This is true.

But there is a big difference when the mobile try to initiate communication with the
network.

In Idle mode, the mobile needs to send an RRC connection request (via RACH). In the
CELL_PCH or URA_PCH state the mobile moves to CELL_FACH, and already sends a
message such as 'cell update', and is ready for communication - do not have to re-establish
the signaling connection, and then the RRC connection again.
Thus obtaining the network service is more efficient.

Battery and Signaling

Battery consumption and increased signaling and interference in the network are directly
related to some parameters configuration of state transitions, such as timers and other
settings.

But to really understand how it all works, we need to know some auxiliary information.

Let's see some of the data that influence the reduction of mobile battery consumption, and
reduced signaling.

Considering the modes seen so far, we can compare the battery consumption in each of
them by relative units. Thus we have the approximate consumption of each mode RRC:

 OFF = 0
 Idle = 1
 CELL_DCH = 100 (that is, 100 x Idle)
 CELL_FACH = 40 (that is, 40 x Idle)
 CELL_PCH < 2 (in this case it depends on the relation of DRX to Idle and mobility)
 URA_PCH ≤ CELL_PCH (in mobility scenarios it is less than the consumption in CELL_PCH state;
in static scenarios it is already the same.).

There is a relationship between energy consumption and the efficiency of communication.

The following figure helps us better understand this, because it shows the workflow UMTS
states, where the state that has the highest consumption is highest in the figure.
Remember though that the consumption should not be the only variable to be taken into
account: the greater the energy used by mobile, more immediately communication occurs.
If the mobile remains in the CELL_DCH state, it has almost immediate connection, and a
very high throughput. Only that it consumes the battery 100 times more than in the idle
mode.

If it remains in the CELL_FACH state, it has a lower throughput, but with 40% of CELL_DCH
consumption.

If it stays in paging state (CELL_PCH or URA_PCH), consumption is almost the same as in

idle mode. The advantage is that both maintains the control connection, namely the
communication is resumed faster than in Idle mode.

What the Idle mode is good in relation to this relationship (battery consumption versus
communication efficiency) is that the battery consumption is minimal, as the load produced
on the network as well.

Thus, the network always seeks to move the mobiles to the higher energy states when it
is necessary to transmit or receive, and as soon as possible, bring them back to lower
energy states when there is no provision of new transmissions.

The radio resource management algorithms (RRM) that take such decisions are
implemented by the network.

Important: The mobile alone can not change from one state to another, it is always
directed by the network!

Important: we are talking about battery consumption and increase signaling according to
the parameter settings on the network. So far we were short, and could calmly move to
the next and final mode of our tutorial today, 4G Connected mode. However, since we
have this very recent matter in our mind, and also the difficulty in finding specific
documentation on this topic, we will make an 'extra', and talk some more about it, but
now in a more detailed way. If you just want to know the modes and states in general,
you can skip to the last item (4G Connected mode). However, if you want to go a little
deeper in the 3G signal issue, just keep reading.

Battery and Signaling x Timers and Other Adjustments

Let's talk about the timers and triggers that make the mobile go from one state to another,
in 3G Connected mode.

We have seen that when the mobile is in the CELL_DCH state, it makes the
transmission/reception of large volumes of data. At any given time, there is nothing more
to be transmitted/received, the mobile stops transmitting.

But the network does not immediately remove the mobile from CELL_DCH state, since it
may have more data to transmit/receive soon.

This time that the network decides to move the mobile from CELL_DCH state to
CELL_FACH state is very critical (remember that while the mobile is in the CELL_DCH state,
it maintains a dedicated channel, or occupies a place in the HSDPA scheduling algorithm
(High speed Downlink Packet Access).
This downtime is informally named T1, since it is not standardized by 3GPP, but is widely
used by manufacturers.

Only after expiration of the inactivity time set for each state, it is that the network puts
the mobile in a more appropriate state.

In the case of the mobile which is transmitting in the state CELL_DCH stop transmitting,
starts counting a T1 timer. After this period the RNC sends the mobile to the CELL_FACH
or CELL_PCH state.

Now when the mobile is in the CELL_FACH state by transmitting/receiving small amounts
of data (or simply because it has been redirected from CELL_DCH), a similar timer is used
by the network to trigger the sending of the mobile into a lower energy state. Also
informally as the T1, this timer is called T2. The lower energy state where the network will
send the mobile may be the CELL_PCH or URA_PCH, depending on the availability of these
states in the network.

For networks that support CELL_PCH or URA_PCH, we still have a third timer, T3. When
the mobile is in the CELL_PCH state for a certain time, the RNC triggers the transition to
Idle.

The purpose of these times (elapsed times for the state transitions to start) is easy to
understand, if we try to answer the following question: In a set of mobiles, which of them
will back to send or receive first data (how likely)?

The answer is that it is more likely to be those who were using mobile data last recently.

For this reason the network keeps the mobile on a dedicated channel for a few seconds T1
before sending to the common CELL_FACH channels - may be that it will request more
data very soon.

This works well for some types of applications, such as a user navigating through pages
in a browser.

However, this algorithm is becoming increasingly inadequate, due to the emergence and
increasing use of applications that have regular update schedule, as exemplified earlier
this tutorial, as Social Networking and Instant Messengers (Whatsapp, Twitter, Facebook)
Stocks portfolios, Email/Calendar/Contacts/RSS Sync.

This kind of update can happen for example every 2 or 3 minutes.

And what does that mean? We have given time for the mobile back from CELL_DCH to
Idle! Again we will have to re-establish the RRC connection in each of these updates; again
get a dedicated or shared channel. And all this, often to transmit only 1 kB, lasting 1
second or less!

The mobile remains a few seconds occupying a high power consumption channel, spending
battery, wasting network resources and causing interference to other mobiles!

As we can see, we arrive at a challenging point. In fact, a dilemma.

Regarding the battery consumption is better the mobile back as quickly as possible to the
idle mode, just after it finish transmitting. Ie be 'connected' the shortest possible time.

In relation to the user experience, it is better that it stays as long as possible 'connected'.
The Idle mode to CELL_DCH (RAB activation time) transition time takes about 2 seconds.

When the transition occurs from a PCH state to CELL_FACH, the RAB activation time falls
to 0.25 seconds. In this case we need the network support some of PCH states (CELL_PCH
and/or URA_PCH).

That is, we have an equation with several variables (reduce battery consumption, improve
user experience, reduce signaling and interference) that depends on several factors (if the
network has PCH states, the value of T1 and T2, the activation time the RAB, DRX).

Different types of optimization can be done in an attempt to achieve the best according to
the network configuration.

We will try to show below some of the possible combinations in graphic, considering the
transmission of a small data packet (~ 1kB), in a very short time (~ 1 s), shown in red
(1).

In the vertical axis we have battery consumption compared to the consumption in the Idle
mode. On the horizontal axis we have the time in which the mobile is in each of the states,
which in turn are identified by colors. The respective areas represent the energy used.

Putting the key combinations together, we have the chart below.

In the first example (1) we have the time T1 and T2 (= 10 seconds) high, in a network
that does not have PCH states, and therefore always has a RAB high activation time (= 2
seconds).

In the following example (2) we have the same scenario, only reducing the T1 and T2
times in half (= 5/2). It is clear that the configuration of the timers T1 and T2 directly
affects the battery life perceived by the user - in this case reduced. However, the mobile
back much earlier to the Idle mode. This means that every time the user restarts the use
of data (such as a new click on a web page after some time they took reading the previous
page) it must go through the RAB activation process (Radio Access Bearer), waiting about
2 seconds.
In addition to the time that the user expects to be in itself an inconvenience, we still have
the problem of the large amount of signaling involved in this process, adding even more
load to the network (in this case, the RNC).

Trying to solve this problem, we use the PCH states, as in the following example (3). Now
we have an activation of the RAB (Radio Access Bearer) much faster (0.25 seconds), since
in the PCH state we still maintain the control connection.

The only drawback here is that the battery consumption in the PCH state, while also being
low, it is still double that in the Idle mode (lowest possible consumption). In the long term,
consumption also makes a difference in battery life.

To try to minimize this battery consumption in the PCH state, we can adjust the DRX cycle
of each of these states. In the previous example, the configuration was as recommended
with the DRX cycle of the CELL_PCH state twice the time of the idle mode DRX cycle.
Typical values are Idle DRX = 1280 ms and CELL_PCH DRX = 640 ms, or Idle DRX = 640
ms and CELL_PCH DRX = 320 ms.

But if we adjust the cycles to the same value as in the following example following graph
(4), battery consumption in the CELL_PCH state is almost equal to the consumption in Idle
mode.
Note: We'll talk in another tutorial about the DRX, but for now know that it affects the way
the mobile keeps 'listening' the paging. The lower this cycle, more responsive is the mobile
(closer, getting more page information), but higher battery consumption. The higher the
DRX cycle, lower battery consumption, but less responsive mobile is for calls initiated by
the network (pagings).

If we increase the DRX cycle of the CELL_PCH (to become equal to the idle mode) and
consequently reduce consumption, we have the disadvantage of slightly decrease the
likelihood of mobile responses to pagings.

As a last case of example (5), we will have the participation of terminal manufacturers, in
the past, when the signal problem was not as common as most recently, and they for its
own developed mechanisms to automatically save battery.

The basic idea of all was the obvious: if the mobile does not need to transmit more after
some time (idle) it must return to the Idle mode. Mobile simply alone decides when to
release its connection (not the network) through the SCRI message (SIGNALLING
CONNECTION RELEASE INDICATION), existing since Release 99, but did not expect any
response from the network.

Here again the graphics with some examples of optimization that may be done by setting
timers, use of PCH states, DRX cycles configuration, etc.
Important: In the examples, we always initiate transmission using the CELL_DCH state,
and then the CELL_FACH. Our aim was to illustrate the T1 and T2settings. But in our
particular example, we consider a small volume of data in a very short time.

From what we have seen, these are ideal conditions for the CELL_FACH state. That is, in
practice, this transmission example of the packet is set to happen in the CELL_FACH state,
rather than the CELL_DCH.

But regardless, we have a common factor to all the examples: all mobile transitions so far
are controlled by the network, there is no 'dialogue' with it. (Except for the last example,
with downtime proprietary implementations - and still is just an arbitrary mobile action
that simply decides to return to the idle mode).

That is, we do not have resource optimization. But no one more than the mobile knows
exactly what is going on, what is happening. Which applications are being used, and which
probably will demand the network.

And even better: no one better than the mobile to say that does not need anything else -
the network may terminate its connection!

If we establish this dialogue, the network can immediately move the mobile to a more
convenient power state at the time, and configured by the operator.

This conversation is great for both: the mobile saves battery, and network saves resources
(channels) and reduces interference!

Unfortunately, the importance of this dialogue was perceived a little late (when
manufacturers have followed their own implementation to release the signaling
connection, always to the Idle mode). Only in 2008/2009, the 3GPP Release 8 of the
standardized FD (Fast Dormancy) mechanism, which defined the mobile could
communicate with the network using the existing SCRI message, now with IE (Information
Element) 'Signalling Connection Release indication Cause' present and set to 'UE
Requested PS Data session end'.

In other words, with the FD, the mobile can tell the network that wants nothing more, and
it can immediately remove it from a high energy consumption channel, sending to a more
appropriate state.

The FD allows that the states control bypass the inactivity timers, after mobile finished
transferring all its data - when receiving the SCRI, the RNC can send the mobile to the
Idle mode.

Just then we see the main timers configuration scenarios related to state transitions, with
a little more detail (and we can still see that there is much to be seen and discussed!).

Again, we escaped the goal of being simple, but this understanding can be quite
instructive, even for the most experienced in the subject, and so we decided to approach
it.

Let's go back and finish our tutorial, talking a little about the connected mode in 4G.

4G Connected Mode

Finally, we come to the last mode of today's tutorial. Do not worry, we are almost done,
and very soon you will be able to understand the figure with overview we showed at the
beginning.

Just as the 3G mobile after being turned on, the mobile LTE performs a series of actions,
initial access procedures. This includes for example 'Cell Search' and 'Cell Selection',
receiving system information and the random access procedure. Again, these concepts are
not explained here today because we just want to generally understand just how the
modes, states, and transitions work.

Compared to 2G and 3G, LTE state and states transitions (4G) are much simpler: Either
the mobile is in idle mode, or is in Connected mode. This also applies to LTE-A (Advanced).
A concept that should already be clear to you, from what we have seen so far is the
importance of improving the efficiency of saving battery life and network resources. And
this is extremely related to the states, as and when they occur their transitions. Especially
in the growing global scenario like 'Always-on' applications with small data transmissions
often unpredictable.

You must be beginning to wonder how to apply some of the concepts in your own network,
but at the same time worrying because you can not see such an efficient solution able to
meet so many different variables.

But we have a good and great news. The first, and good news is that it is not only you
who have these doubts. 3G networks are not really the most appropriate for this scenario,
as they were not built for that purpose. In any case, they can be greatly improved with
the use of features such as 'Continuous Packet Connectivity'.

And the great news is that the LTE (4G) has been created thinking about this kind of
problem since its conception!

An example is the DRX (Discontinuous Reception) in Connected mode, which gives more
options to the mobile: the ability to periodically turn off its radio. This on-off time can be
set to 1 ms granularity!

We know, however, that turning off the mobile can bring a negative impact on latency. To
minimize this problem, we defined two stages of DRX.

In the first stage, from a certain time elapses without more data transfer, the mobile uses
the short DRX cycle, or can 'sleep' (turning off the radio) and for short periods. The radio
is 'asleep' and 'wake up' more often.

When using the short DRX cycle, we can move to the second stage (or even return to the
state of Continuous Reception, if any data to be transferred). The second stage follows the
same preceding idea: after a certain time without data to transfer, the mobile utilizes a
long DRX cycle, ie, will now 'sleep' (turn radio off) for longer periods.

On the one hand saves battery, on the other, it increases the latency.

Important: Be careful not to confuse the LTE connected DRX cycle with the DRX the Idle
mode. In Idle mode, the DRX is more related to paging, and so is often called DRX paging.
This Idle mode DRX cycle time is much longer than the LTE, reaching seconds!

In a way, we can consider these stages as 'sub-state' of LTE in the connected mode.

When the mobile LTE is in the connected mode, it has a RRC connection, and its
information is saved (known) in the network (e-NodeB). Mobile monitors control channels
associated with the shared data channel, and checks for scheduled data to it (or not),
reports the CQI (Channel Quality Feedback Information) after all the measurements and
also performs neighboring measures of all networks (2G/3G/4G).

Regarding to its knowledge by the network in the CELL_FACH state, the network (eNodeB)
know where the mobile is in the cell level (the cell where the mobile made the latest 'Cell
Update').

Speaking of transitions, we know that the LTE have only two basic states: Idle and
Connected. So the mobile LTE will in Idle mode to Connected or Connected to Idle.

To enter the Connected mode, the mobile performs the connection setup: RRC setup,
configuration/reconfiguration and security. And start a new connection or maintain existing
ones.

When the mobile does not request uplink or downlink resources of the network (eNodeB),
and likewise the network (eNodeB) does not receive signaling/traffic intended for the
mobile, the mobile reset/release all radio resources (including signaling), and tells the
network that is going out of this state and reason. In other words, when the connection
ends, the mobile is released.

Regarding the battery power when the mobile is in connected mode, the mobile has a
variable consumption. If it is actively transferring data we say that it is in the Continuous
Reception 'sub-state'.

After a certain time (t1) with no more data to be transferred, the mobile switches to the
Short DRX 'sub-state' - and waits for more data, obey a second set time (t2).

If more data comes, it then returns to the Continuous Reception 'sub-state', otherwise
goes to the Long DRX 'sub-state'.

Unlike 3G, the energy drain on the 4G LTE is variable, depending on the throughput. Lower
rates require less energy, but as the rates increase, power consumption also increases.

In a rough comparison with the 3G, LTE radio consumes more power because their
communication states (Short DRX and Long DRX) consume the same high energy, while
in 3G have the CELL_FACH, which consumes less than half the base CELL_DCH energy .
But although consumption a little higher, we can not forget that LTE is much faster than
the 3G.

All these comparisons and implemented algorithms can be seen indirectly in 2G/3G/4G
modes and states transition diagrams, like we have below.

Of course, this diagram is not fully complete, but we try to group at least the key
information necessary for explanations.

We hope that the goal today has been achieved, and that this summary help you to better
understand how is the operation of the mobile network from the point of view of the
mobile, particularly what this represents in terms of battery consumption, signaling
increased, latency, interference and other factors that directly affect the quality of the
network and hence the user experience.

Conclusion

All concepts of modes, connected states and transitions of mobile networks seen in this
tutorial are much broader (and complex) than what was presented. We try to present it in
a simple way, but the amount of detail (and auxiliary concepts that need to be well
understood) makes this very difficult task, we must recognize.

With the understanding of the concepts presented, it is easy to see the large space we
have for the techniques and solutions that can improve the efficiency of communication
and speed up traffic, while they can save the mobile battery and network resources.

After all this it is what we always seek: Help you to understand some complex scenarios,
making them easier to be understood, and thus giving grants for you to continue
progressing in your studies and work.
We count on you, keeping as a loyal reader, and especially being part of this project with
us. If you liked this tutorial (or other from our website), share with your colleagues and
friends.

Your recognition participating is what motivates us to keep following the evolution of

networks, and always bring new tutorials, news and innovations.