3G/UMTS

RRC State Change

'RRC State' refer to various different phases in which UE/Network be after RRC Connection Setup and before RRC Release. In most case, these states occurs after Radio Bearer Setup. RRC State Change refers to the process of switching between these states.

Roughly there are three different stages (DCH, FACH, PCH).. but in more detail you can classify them into four different stages as shown below. As you see below, in most case you can jump from one states to any other stages by single step, but there are a couple of cases you cannot switch with a single step. For example, you cannot switch from CELL_PCH to URA_PCH directly.You can switch from DCH to PCH directly, but you cannot switch from PCH to DCH directly.

Let's think about what can happen in each of these states.

DCH : You can call this state as 'Normal traffic mode'. When you make any connection for traffic (e.g, voice call and data call), in most case you (UE/Network) establish DCH state and most of traffic (Voice data, packet data) are being transmitted and received in this stage.

FACH : This is the stage in which UE can still send and receive user data but at much lower data rate comparing to DCH. For the detailed understanding on this stage, you have to understand the detailed channel mapping. But it is out of scope of this page. see Cell FACH Channel Mapping for R99/R5/R6 and R7.

PCH : In terms of mode of operation, PCH is very similar to IDLE mode. UE cannot send and receive the user data, it can only monitor/recieve SIBs and Paging. The difference between PCH and IDLE mode is that PCH is still a kind of 'RRC Connected' stage. So it would require less steps of RRC procedure to go back to FACH/DCH for user data transaction.

This is a brief overview of RRC State Change. Now let's get a little bit deeper into the topic. Followings are the list of topics on RRC State Change

• Why we need RRC State Change ?
• RRC Sequences to get into FACH/PCH
• RRC Sequences to wake up from FACH/PCH
• Factors on Current Consumption
• What happen to IP layer in Each of States ?
• Who is the Decision Maker for RRC State Change ? UE or NW ?
• How to test RRC State Changes ?

Why we need RRC State Change ?

Why do we need this kind of multiple stages ? Let me give you an example situation where these state change become helpful.

Let's suppose that UE just establish a data connection and downloaded a web page and you started reading the page. While you are reading the page, there would be no traffic between UE and network. So it would be waste of energy (on UE side) if they are still in normal connected mode (DCH) and Network also maintain the spreading code even though it is not used. (spreading code (OVSF code)is one of the most valuable and limited resource for the network).

Then would there be any better way ?

If you can guarantee that there would be no traffic for a long time, the simplest option would be just completely tear down the RRC session and goes to IDLE mode. But what if you clicked a hyperlink in the webpage and goes to the link. Then UE has to establish RRC session and create the radio bearer from scratch which would take long procedure and cosume a lot of energy. If you repeat thistype of operation, ie. the repetition of short traffic - short pause, it would not be efficient if they blindly go to IDLE mode and reestablish the connection.

Then what would be the best way ?

It would be better if we have some 'intermediate' states between IDLE and DCH (Fully Connected Mode) in which they are still in 'partially' connected mode and save energy/critical resource at the same time. FACH and PCH are the 'intermediate stage'. Usually UE/Network goes into FACH when there is no user traffic for a certain time period and it stays there when there is only a small amountof data traffic. If there is no user traffic even in FACH for a certain time period, they switch to PCH.

If they start getting user data in FACH or PCH, they can switch back to DCH or FACH depending on the amount of the data.

RRC Sequences to get into FACH/PCH

Following is the overal RRC message sequence for switch from DCH to FACH and from FACH to DCH.  What you should notice is that this transition is triggered by Network, not UE.  It means that UE has no direct control over this transition, it is all up to Network to determine whether it switch to other states or not. It is also upto Network when to switch to other states. UE may sendsome 'indication' implying 'I want to switch to FACH' by sending a special message (e.g, Signaling Connection Release Indicator), but it is upto network whether it takes 'proposal' or not.

RRC Sequences to wake up from FACH/PCH

Following is generic sequence by which they can wake up from PCH to FACH or switch from FACH to DCH. This procedure can be triggered by Network or UE as shown below. It means UE can initiate data traffic any time it wants.

Factors on Current Consumption

One of the biggest motivation for adopting RRC State Change technique is for reducing energy consumption. So I think it is worth talking a little bit about energy consumption over these different states.

Following is an illustrations that would show you overal power consumption (energy consumption) profile over time. To have meaningful energy consumption information for any specific cases, you need to detailed measured data for all the markers (A,B,C,D,E and T1,T2) that I put in the graph.

I linked a paper which would give you a little bit detailed story about RRC State Changes and Energy consumption(See this paper (by Pekka H. J. Perälä1 et al) for detailed information.). But thisis not the full story, you would need your own measurement data for your own device if you want to get the accurate value for your own device.

Let me give you just a big pictures for each of the marker shown above.

Marker A : This is the period during which is in DCH and data traffic is on-going. In this period, the most important factors for energy consumtion is UE Tx power and type of radio bearer. So without the specific value for UE Tx power and radio bearer type, it would be hard to evaluate the energy consumption. (According to the paper linked above and some of my experience, you would see atleast 200 mA or higher at this period).

Marker B : This is the period during which is in DCH and no data transmission/reception is on-going. so UE Tx power would not give influence here, but radio bearer type would be more influential. Especially if the Radio Bearer is in HSPA mode, UE would send CQI report even when there is no user data transmission. In this case, UE Tx power would play role as well.

Marker C : This is the period during which is in FACH and no data transmission/reception is on-going. According to the paper linked above, this period would consume 100 mA or higher.

Marker D : This is the period during which is in FACH and data traffic is on-going. In this period, the most important factors for energy consumtion is UE Tx power. So without the specific value for UE Tx power, it would be hard to evaluate the energy consumption.

Marker E : This is the period during which is in PCH. Since the mode of PCH operation is very similar to IDLE mode operation. The overall current consumption would be almost same as IDLE mode current consumption. According to the paper linked above, the current consumption would be less than 5 mA, but it would vary according to idle mode DRX cycle.

Marker T1 : This is the period during which there is no data in DCH and network would need some time to make any decision on whether it would continue to stay in DCH or switch to FACH. This duration would influence a lot with long term energy consumption on UE but UE does not have much control over length of this period. UE may send some indication by sending "Signal Connection ReleaseIndication', but it is up to Network whether to take it or not. Normally this period would take several seconds (e.g, 5 sec).

Marker T2 : This is the period during which there is no data in FACH and network would need some time to make any decision on whether it would continue to stay in FACH or switch to PCH. This duration would influence a lot with long term energy consumption on UE but UE does not have much control over length of this period. Normally this period would take several seconds (e.g, 5 sec).

What happen to IP layer in Each of States ?

What would happen to IP layer in Each of RRC States ? The 'IP layer' in this question can be the whole NAS/Core network in case of live network. If it is with the test equipment, it would mean TE port/Network Interface Port on the equipment. If it is on UE side, this would also mean NAS layer and IP stack dedicated to this specific connection (the specific RRC Connection).

The answer would be obvious if you think of logic/motivation of RRC State Change. The main motivation of RRC State Change is to turn down RRC layer (Dedication, Critical Resource, usually very limitted comparing to NAS/Corenetwork) while there is no traffic or very little traffic with NAS/Corenetwork staying on as it is.

So even when the RRC Status is in Cell PCH/URA PCH, there should be no (almost no) changes in NAS/Corenetwork side. In case of equipment and UE side, the IP stack and Network Interface should alive all the time regardless of whether the states is in DCH/FACH or in PCH.

Who is the Decision Maker for RRC State Change ? UE or NW ?

Who (UE or NW) triggers switching from an RRC state to another state ? If you look at the protocol sequence described above, you would notice that every state change is initiated by a RRC message sent by the Network. It means that each state change can be triggered only by Network. There is no way that UE can trigger this process. It means.. even there is no user data being exchanged between UE and NW (even when you pulled out IP layer cable between UE and NW), UE cannot trigger this state change.

There is a mechanism that UE can trigger to switch from high active mode (e.g, Connected mode) into low activity (no activity) mode (e.g, Idle). It is called Fast Dormancy. You can refer to Fast Dormancy page for the details.

How to test RRC State Changes ?

Now let's think of how we can test this RRC State Changes (mostly on testing UE side implementation).

First, you may use live network to test it by trying simples steps as follows.

i) Power on UE and Put Airplane Mode On

ii) Setup UE protocol logging tool and start logging

iii) Put Airplane Mode Off

iv) Wait until it completes the attach to a Network

v) Start Browse and view a web page

vi) Give some time (a couple of min) without any user activity (like click the link, moving to new page, even scrolling the page)

vii) Stop Protocol Logging on UE

viii) Analyze the log

This MAY give you a good example of live network operation of RRC State Change, but it MAY NOT give you the expected result. You may expect the network to trigger RRC State Change during step vi). but it would not always turn out as you expected. One unexpected possibility would be that Network does not support RRC State Change and the communication would stay in DCH even when UE does not have any user traffic. Another unexpected result would be that UE initiated Fast Dormancy procedure before Network initiate RRC State change and the communication switched to Idle states rather than in FACH or PCH.

This implies that live network would not be the perfect solution to test RRC State Change. You would want some more controllable test equipment like Network Simulator.

Initially this kind of testing were not easy even with Network Simulator. About 6~7 years ago (around 2008) when I first asked to help testing this with the test equipment, I used a specially created protocol sequence that popup a window asking if I want to switch to Cell FACH or Cell PCH. If you process a button, the network simulator initiate the protocol sequence to switch the RRC States. This would let you trigger the state change exactly at the moment you want to initiate and good enough for RRC layer activities that needs to be validated, but it is a little bit different from real life situation.

A couple of years later (around 2009 or 2010), I got access to an equipment (Anritsu MD8470/MD8475) that can test the RRC State Change in more realistic scenario.  In this equipment, you can specify the specific condition to trigger the status change (e.g, IP layer data throughput and the timer before it trigger RRC State when the IP layer data is within the specified range). With this configuration, the equipment keep monitoring the IP layer throughput flowing through its network interface and triggers the RRC status change when the condition is met.