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.
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.
RRC and RAB
To work with modern wireless networks such as UMTS and LTE, it is essential that the telecom professional has full understanding of its basic concepts, such as those that control the call establishment and maintenance, whether it is voice (CS) or data (PS).
n this scenario, RAB and RRC are two of the most important concepts because they are responsible for all the negotiation involved in those calls.
In addition to RAB and RRC, we still have some other terms directly involved in context, as RB, SRB, TRB, among others. These terms are also important concepts, since without them RAB and RRC could not exist.
So lets try to understand today – the simplest possible way – what is the RRC and RAB role in the calls of these mobile networks in practice. As it become necessary, we will also talk about other concepts.
Introduction
To start, we can divide a call into two parts: the signaling (or control) and data (or information). Already ahead of key concepts, we can understand the RRC as responsible for the control, and the RAB as responsible for the information part.
As mentioned, other auxiliary concepts are involved in calls, but our goal today is to learn the most basic concepts – RRC and RAB, allowing us to evolve in our learning later.
Oddly enough, even professionals who already work with UMTS-WCDMA and LTE networks have trouble to fully understand the concepts of RRC and RAB. And without this initial understanding, hardly they can evolve with clarity and efficiency in their daily work.
Without further introduction, let’s go straight to the point and then try to understand once and for all these so important concepts.
Analogy
As always, and as usual the telecomHall, let’s make an analogy that helps us to understand the functioning of the RRC and RAB in practice.
Let’s start imagining the following scenario: two people are cut off by a cliff. On the left side, a person (1) want to buy some things that are for sale in a store (2) or deposit on the right side. In the right side, in addition to the deposit, we also have a seller (3), which will help the buyer to contact (negotiable) with the deposit.
As additional or auxiliary objects (4), we have some iron bars with different sizes, and some cars – some like train wagon, others like remote control cars.
In short, we have the situation outlined in the image below.
And so, how this situation can be solved?
Let’s continue with a possible solution: the buyer on the left write his request in a note, tie on a small stone that he found on the floor, and send (1) it to the seller on the other side. So, the stone carry the information or initial request.
The seller receives the request, but she need to send it to the deposit, in order for the shopping to be sent. She sends the request on a remote control car (1), which run a previously demarcated path to the deposit.
Some time later, the deposit response arrives to seller (1), which then checks to see whether she will be able to send the data or not.
So that we can proceed with our call, let’s consider a positive response. That is, what the buyer is willing, or the ‘resources’ are available.
Seller realizes that to fulfill the request, and be able to send the purchases, she will need to build a ‘path’ (1) between the two ends of the cliff, so the wagons could carry over with the orders/receipts and purchases. Then, the seller uses some of its iron bars and creates a link between the two sides.
Once established all the way between those involved, requests can be sent from both sides as well as the purchases or any other information can be transferred by different paths and wagons/cars!
If you managed to understand how the above problem was solved, congratulations, you just understand how the most common form of UMTS-WCDMA and LTE communication happens!
Although analogies are not perfect, it help us a lot to understand the complex functioning of these networks, especially in relation to new concepts such as RRC and RAB, but also a very often used, the ‘bearer’ — so much that it’s worth talking a little bit about it.
What is Bearer?
If we search the word ‘bearer’ in the dictionary, we’ll find something like trasnporter, or carrier. In a simple way: one who carries or conveys something from some point to another point. In a restaurant, we can compare the ‘bearer’ to a waiter.
But from the telecommunications point of view, ‘bearer’ is best understood as a ‘pipe’ that connects two or more points in a communication system, through which the data flows.
Technically speaking, it is a channel that carries Voice or Data, a logical connection between different points (nodes) that ensures that the packets that are traveling have the same QoS attributes. Explaining better: for each ‘bearer’ we have several associated parameters, such as the maximum delay and packet loss limit – and these attributes that make sure each packet going in the same channel have the same QoS attributes.
General Flowchart – RRC, RAB and Others
Now that we know what is bearer, let’s go back to the analogy presented earlier, but now bringing it to the real, more technical side.
All that we’ll talk can be summarized in a single figure, having all the concepts seen today, and that will be detailed from now on.
Note: If you manage to understand the concepts that will be explained in the figure below, you will be with a great base for both WCDMA and LTE networks. This is because, in order to facilitate we use WCDMA nomenclatures, but the principle is pretty much the same in LTE. Just do the equivalent replaces, like NodeB for eNB.
On that ficticious scenario, the seller is the UTRAN, responsible for creating and maintaining the communication between the UE (buyer) and CN (deposit) so that the QoS requirements of each are met.
- UTRAN: UMTS Terrestrial Radio Access Network
- NodeB
- RNC
- UE: User Equipment
- CN: Core Network
- MSC: for switched voice services
- SGSN: for packet-switched services
The cliff is the Uu Interface between the UE and the UTRAN, and the road through the remote control car goes until the deposit is the Iu Interface, between the UTRAN and CN.
Sending requests and receipts is part of signaling, or the RRC. The shipment of purchases is the data part, or the RAB. In our scenario, the RRC are the Rails, and RAB is the full service of sending data between the UE and the CN.
- RRC: Radio Resource Control
- RAB: Radio Access Bearer
Note: the RRC is in Layer 3 – control plane, while the RAB occurs between the UE and CN, in the user plane.
The railcars are the RBs, and convey the information in the radio path. These wagons define what type of thing will be transported, and in what quantity. Similarly, the RBs define what type of data will in the RRC, which can be Data or Signaling. When the QoS attributes change, then the Rbs associated with that RRC connection need to be reconfigured.
The remote control cars are the Iu bearer, and carry information on Iu Interface (between the UTRAN and the CN), either CS or PS.
- RB: Radio Bearer
- Iu bearer: Iu Bearer Interface
Note: RAB is the combination of RB and Iu bearer.
As examples of RAB for some services and different rates we have:
The Conversational RAB and the Interactive RAB can be used together, and in this case we have a case of MultiRAB.
The RB is a layer 2 connection between the UE and the RNC, and can be used for Signalling and control User Data. When it is used for Signalling or Control Messages is called SRB. And when it is used for user data is called TRB.
- SRB: Signalling Radio Bearer (Control Plane)
- TRB: Traffic Radio Bearer (User Plane)
Note: in an optimized network, we can find much of the traffic being handled by HSPA bearers, even MultiRAB. This option frees resources from CE (Channel Elements), relieving the load on R99 (that can only use these resources). However, it should be done with caution, because if improperly configured it can degrade the Performance Indicators with Blockage (Congestion) and Failures.
As you’ve probably noticed, we’re talking about several new technical terms, but these terms are what you’ll find for example when reading UMTS or LTE call flowcharts. But if you can understand at least in part the concepts presented today, everything will be much easier.
Let us then take a look again on our figure, and continue our analogy.
As we saw, in telecom we work with the concept of layers. And this way of seeing the network brings us many advantages, mainly because we were able to ‘wrap’ physical access. In this way, any modification or replacement can be made with less complexity.
We don’t need to tell you how much the radio path is complex, continuously changing, right? This structure using beares ensures this simplification: the RNC and CN bother with QoS requirements in the path between them (Iu Interface); and only the RNC have to worry about meeting the complex radio path QoS.
Sure, but why we have two types of carriers – wagons and remote control cars? The answer to this is in the very characteristic of the two existing paths. Being the Iu a more robust interface, and also because we have major changes in RABs during connections, it is normal that these bearers are also different for the paths. it’s like using a 4×4 pickup truck to climb a mountain, and a race car to an asphalt race.
Regardless the carriers, with the RAB the elements of the CN has the impression of a physical path to the UE, so don’t need to be worrying about the complex aspects of radio communication.
For example, a UE can have 3 RABs between he and the RNC, and these RABs may be changing, as in the case of soft handovers, while the RNC has only 1 Iu bearer for this connection.
From the point of view of the carriers, the main task of the UTRAN is managing these services on these interfaces. She controls the Uu interface, and along with the CN, controls the provision of services in the Iu interface.
Remember that in a communication between the UE and the CN, several other elements are involved, mainly to negotiate QoS requirements between both parties. These requirements are mapped in the RABs, that are visible to both (UE and CN), where the UTRAN is responsible for creating and maintaining these RABs so that all of this is served in all aspects.
A little bit more details…
A RRC connection exists when an UE performs the call establishment procedure, and get resources from the UTRAN. When a RRC connection is established, the UE will also get some SRBs. (If for some reason the initial request is not accepted, the UE can make a new request after some time).
Since the SRB was established between the UE and the CN, the RNC checks a series of information such as the UE identity, what is the reason for the request and whether the UE is able to handle the requested service.
The RNC that maps the requested RABs into RBs, to transfer between the UE and the UTRAN. In addition it is also check the attributes of the RABs: if they can be met by the available resources, and even whether to activate or reset radio channels (reconfiguration of lower layers services ) based on the number of Signaling Connections and RABs to be transferred.
This way, it creates the impression that there is a physical path between the UE and the CN. Remembering again that no matter how many signaling and RABs connections there are between the ue and the CN – there is only a single RRC connection used by the RNC to control and transfer between the UE and the UTRAN.
Now that we have seen a lot about RRC and RAB, let’s learn only a few more concepts today – after all, we already have enough information presented. Let’s talk about the AS and NAS.
- AS – Access Stratum is a group of specific protocols of access network
- NAS – NON Access Stratum: so, are the other protocols, or those that are not access network
At this point of view, the AS provides the RAB to the NAS, or information transfer service.
The UE and CN need to communicate (events/messages) with each other to perform several procedures with many purposes. And the ‘language’ of this conversation between them is called protocols.
The protocols are then responsible for allowing this conversation between the UE and CN, and cause the CN do not worry about the method of access (be it GSM/GPRS, UTRAN, LTE). In our case the RNC acts as a protocol – between the UTRAN and CN.
According to what we learned today, the RAB is carried:
- Between the UE and the UTRAN: within the RRC connection. The RRC Protocol is responsible for negotiating the (logical) channels of Uu and IuB interfaces, and for the establishment of signaling dedicated channels as SRBs and RBs among these interfaces.
- Between the RNC and the CN: after being negotiated and mapped, in the RANAP protocol connection, through Iu interface (CS/PS).
- RANAP: Radio Access Network Application Part
As we have seen above, the RNC maps requested RABs into RBs using current radio network resources information, and controls the services of lower layers. To optimize the use of these resources, as well as the network band and physical resource sharing between different entities, the UTRAN can also perform the function of CN messages distribution.
For this, the RRC Protocol transparently transfers messages from CN to the access network through a direct transfer procedure. When this occurs, a specific indicator of CN is inserted in these messages, and the entities with the distribution function in RNC use this same indicator for direct messages to the appropriate CN, and vice versa.
But now it started to get more complex, and we have already reached our goal today, which was to learn the basics of RRC and RAB.
Everything we just talked about above can be seen again in the same figure below, the same from the beginning of the explanations.
RRC and RAB in GSM?
Okay, we understand how RRC and RAB works in UMTS-WCDMA and LTE networks. But in GSM, does we have these concepts as well?
At first, the answer is NO. However, with what we learned today, we can make a comparison with some GSM ‘equivalent’ parameters.
We can compare the SDCCH phase and TCH phase of a GSM call with RRC and RAB in UMTS.
RRC is the Radio Resource Control that works as Control Plane in Layer 3. Is used primarily for Signaling in UMTS. Then we can compare with the signaling in GSM, as the Immediate Assignment process for SDCCH resource allocation.
RAB is the radio access ‘transporter’ that works as the User Plane to provide data for the services requested by the user. Then we can compare with the user part in GSM, as the TCH Assignment.
For each service requested by the user we have only 1 RAB. For example, if the requested service is a Voice Call (CS-AMR), then 1 CS RAB will be generated and provided to the user. The same is true for PS.
So our equivalence table would be:
| UMTS / LTE | GSM | |
| Control | RRC Connection | Immediate Assignment |
| User | RAB Assignment (RNC-CN) | Assignment (BSC-MSC) |
RRC Connection and RAB example
To complete for today, let’s see (always in simplified form) a simple RRC connection and RAB.
Whenever the UE needs the UTRAN resources, he asks. So that these resources are allocated, it establishes a RRC connection with some SRBs.
In this case, a RAB connection is created to enable the transfer of user data. We remind you that the RAB consists of RB + Iu bearer. The RAB is created by CN, with a specific QoS request.
For a single UE, there may be multiple RAB for NAS service (CS or PS).
But let’s just stick to the initial procedure, that is, how is performed the ‘RRC Setup’ procedure, from the UE’s request.
The following figure shows this more straightforward.
The RRC has always 3 steps:
- The UE requests a new connection in the Uplink (‘RRC CONNECTION REQUEST’);
- With sufficient resources available, the ‘RRC Downlink CONNECTION SETUP’ message is sent, including the reason, along with the SRB configuration; (Note: otherwise, if the RRC connection cannot be established, the message sent is ‘RRC CONNECTION SETUP REJECT’).
- If all goes well, the UE sends the message in the Uplink: ‘RRC CONNECTION SETUP COMPLETE’.
And after this, the ‘MEASUREMENT CONTROL’ message are being sent in the Downlink, for the communication continuity.
After the RRC connection is established, the UTRAN makes the checks between the CN and the UE, for example the authentication and security operations.
And so, the CN informs the RAB to UTRAN in accordance with requirements of the service requested by the UE. As we have seen, RAB occurs after the RRC, and without a RRC connection no RAB may be established.
Courtesy: telecomhall.com
