'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.
RRC states in UTRA RRC Connected Mode. All four states keep the RRC connection, and only CELL_DCH and CELL_FACH are drawn with arrows to and from IDLE MODE.
Four states, one mode : URA_PCH, CELL_PCH, CELL_DCH and CELL_FACH all sit inside the grey UTRA RRC Connected Mode box. IDLE MODE is outside it, so a move to IDLE MODE ends the RRC connection.In Service and Out of Service : URA_PCH, CELL_PCH and CELL_FACH carry the labels [Out of Service] and [In Service]. In these states the UE keeps looking for a suitable cell when it loses coverage. 25.331 subclause 7.2.2 runs timers such as T305, T307, T316 and T317 for that case. CELL_DCH has no such label, because a lost radio link in CELL_DCH is handled as a radio link failure.Connection establishment and release : the arrows to and from IDLE MODE start and end at CELL_DCH and CELL_FACH. A UE therefore enters connected mode in one of these two states.No arrow between the PCH states or from PCH to CELL_DCH : a UE in CELL_PCH or URA_PCH goes through CELL_FACH first. This is why the sequences further down always show a CELL FACH step.
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.
The two PCH states differ in how precisely the network knows where the UE is. In CELL_PCH, the UE sends a CELL UPDATE whenever it reselects a new cell, so the RNC knows the cell. In URA_PCH, the UE sends a URA UPDATE only when it moves into a new UTRAN Registration Area, so the RNC knows only the URA. URA_PCH therefore suits a UE that moves fast, because it sends fewer updates. In both states, timer T305 also triggers a periodic update.
One more detail changed after R99. From Rel-7, a FDD UE that supports HS-DSCH reception in CELL_PCH can receive DCCH and DTCH on the HS-DSCH while it is in CELL_PCH. The cell has to broadcast the HS-DSCH paging system information in SIB5 for this. So the statement that a UE in PCH cannot receive user data holds for R99 style CELL_PCH, and for URA_PCH in every release. In URA_PCH, 25.331 subclause 7.2.2.1 allows neither DCCH nor DTCH.
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 ?
- Reference
Why we need RRC State Change ?
A packet data session does not send data all the time. It sends a burst, waits, and sends another burst. The question here is what the UE and the network should do with the radio resources during the waits. The answer explains why UMTS has four connected states instead of one.
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 this type 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 amount of 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.
So each state trades resources against delay. CELL_DCH holds a dedicated code and gives the lowest delay. CELL_FACH shares common channels with other UEs, so it costs the network little but gives a lower data rate. The PCH states hold no radio channel for the UE at all. But they keep the RRC connection, so the way back to CELL_FACH is a single cell update rather than a full connection setup.
The goal is fewer idle-to-connected transitions : the PCH states keep the RRC connection alive during a pause, so a new burst of data does not need a new RRC CONNECTION REQUEST.Dedicated codes are the scarce resource : moving an inactive UE out of CELL_DCH frees its OVSF code for other UEs.The price is latency : each step down makes the first packet of the next burst wait longer, because the UE has to move back up first.
RRC Sequences to get into FACH/PCH
Following is the overal RRC message sequence for switch from DCH to FACH and from FACH to PCH. 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 send some 'indication' implying 'I want to switch to FACH' by sending a special message (e.g, Signalling Connection Release Indication), but it is upto network whether it takes 'proposal' or not.
Moving down from CELL_DCH to CELL_PCH. Every step is a reconfiguration message from the network, and the UE only confirms it.
Radio Bearer Setup : the sequence starts after the radio bearer exists, so the UE is in CELL DCH with user data flowing.Radio Bearer Reconfiguration, DCH to FACH : the network moves the UE to CELL FACH, and the UE answers with Radio Bearer Reconfig. Complete.Physical Channel Reconfiguration, FACH to PCH : the network moves the UE on to CELL PCH, and the UE answers with Physical Channel Reconfig. Complete.The message type is a network choice : the target state is the IE RRC state indicator, and it is not tied to one message. RADIO BEARER SETUP, RADIO BEARER RECONFIGURATION, RADIO BEARER RELEASE, TRANSPORT CHANNEL RECONFIGURATION and PHYSICAL CHANNEL RECONFIGURATION can all carry it. So another network can use a different message for the same step.
The RRC state indicator is a four value field in 25.331. The listing below is the current ASN.1 text, and its four values are the four states of the state diagram above.
Following is based on
RRC-StateIndicator ::= ENUMERATED { cell-DCH, cell-FACH, cell-PCH, ura-PCH }
The network decides when to send these messages, and 25.331 does not fix the rule. Many networks run an inactivity timer in the RNC. Some also use traffic volume measurements from the UE. For example, reporting event 4B tells the RNC that the Transport Channel Traffic Volume has fallen below an absolute threshold.
The UE has one message that asks for a step down: the SIGNALLING CONNECTION RELEASE INDICATION. From Rel-8, this message can carry the cause "UE Requested PS Data session end". The UE sends it when upper layers indicate no more PS data for a prolonged period. Timer T323 then stops the UE from sending it again too soon. Even so, the network still chooses what happens next.
The network always moves the UE down : every transition to a lower activity state arrives in a message from the network.Look for the RRC state indicator : in a log, this IE inside the reconfiguration message tells you the target state, whatever the message name is.The UE can only ask : a SIGNALLING CONNECTION RELEASE INDICATION with the Rel-8 cause is a request, and T323 limits how often the UE can send it.
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.
Moving up from CELL_PCH to CELL_DCH. The two cases differ only in the first message: the network originated case starts with a Paging, and the UE originated case starts directly with a Cell Update.
Paging : in the network originated case, the network pages the UE with a PAGING TYPE 1 because downlink data is waiting.Cell Update : the UE moves to CELL_FACH by itself and sends a CELL UPDATE. The cause is "paging response" in the network originated case, and "uplink data transmission" in the UE originated case.Cell Update Confirm and Utran Mobility Information Confirm : the network answers with a CELL UPDATE CONFIRM, which typically gives the UE a new C-RNTI. The UE confirms with a UTRAN MOBILITY INFORMATION CONFIRM, and it is now in CELL FACH.Physical Channel Reconfiguration, FACH to DCH : if the data volume needs a dedicated channel, the network sends a second reconfiguration and the UE ends in CELL DCH.
The UE side of these sequences is set in 25.331 subclause 8.3.1.2. A UE in CELL_PCH or URA_PCH starts a cell update with the cause "uplink data transmission" when it has RLC data on RB1 or upwards to send. It uses the cause "paging response" when it receives a PAGING TYPE 1 that asks for a cell update. So the UE does start the move from PCH to CELL_FACH by itself. The final state is still decided by the network in the CELL UPDATE CONFIRM.
The drawing shows one common case, and a network can shorten it. The CELL UPDATE CONFIRM carries its own RRC state indicator and can include the channel information for CELL_DCH. In that case, the UE goes straight to CELL_DCH and answers with a reconfiguration complete message instead of the UTRAN MOBILITY INFORMATION CONFIRM. The response message depends on which IEs the CELL UPDATE CONFIRM includes.
The UE starts the move out of PCH : the CELL UPDATE is sent by the UE, with the cause "uplink data transmission" or "paging response".CELL_FACH is always the first stop : the UE sends the CELL UPDATE from CELL_FACH, even if the network wants it in CELL_DCH at the end.Wake-up delay is the cost of PCH : the paging, the cell update and a reconfiguration all happen before the first user packet moves on a DCH.
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.
UE current over a DCH, FACH and PCH cycle. After the end of traffic, the UE keeps drawing current during T1 and T2, the waiting times before each step down.
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 this is 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 at least 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 D : 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 C : 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 "Signalling Connection Release Indication', 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).
The graph and the markers lead to one practical conclusion. Current levels A and C depend on the data and the UE Tx power, so the network cannot change them much. T1 and T2, on the other hand, are timer settings in the RNC. 25.331 does not define them, so each network vendor and each operator sets its own values. A UE that finishes a short download therefore spends a fixed time at level B and a fixed time at level D, whatever the amount of data was.
The FACH level sits between DCH and PCH : level D, FACH with no traffic, is lower than level B, DCH with no traffic, and far above level E in PCH.Timers dominate the energy of short bursts : for a small transfer, T1 and T2 can take longer than the data itself.Measure your own device : the values in the linked paper give an order of magnitude. A real budget needs current measurements of the device on the target network.
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.
In 3GPP terms, the RRC connection stays in place in all four connected states, and so does the Iu signalling connection to the core network. The radio access bearers are kept as well. Only the radio resource under them changes: a dedicated channel in CELL_DCH, common channels in CELL_FACH, and no channel at all in the PCH states. So the PDP context and the IP address of the UE do not change when the RRC state changes.
The IP layer only sees a change in delay. A packet that arrives while the UE is in CELL_PCH has to wait for the paging, the cell update and any reconfiguration. So a ping test often shows a long first round trip after an idle pause, and shorter round trips for the packets that follow.
The IP session survives every RRC state change : the PDP context and the IP address stay the same in CELL_DCH, CELL_FACH, CELL_PCH and URA_PCH.Only the radio resource goes away : the RRC connection, the Iu signalling connection and the RABs are kept.A long first packet delay is normal after a pause : it is the time the UE needs to move back from 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.
One refinement makes this statement precise. The network decides every target state, but the UE does start two kinds of transition. First, a UE in CELL_PCH or URA_PCH moves to CELL_FACH by itself to send a CELL UPDATE, as the wake-up sequences show. Second, a UE in CELL_DCH that detects a radio link failure moves to CELL_FACH and sends a CELL UPDATE with the cause "radio link failure". In both cases the UE only reaches CELL_FACH, and the network then decides where the UE goes next.
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.
The network owns the target state : the UE can ask with a SIGNALLING CONNECTION RELEASE INDICATION, but the network chooses whether and where the UE moves.The UE can still move itself to CELL_FACH : it does this for a cell update, from PCH or after a radio link failure in CELL_DCH.Fast Dormancy is a request, not a command : a network that does not act on it leaves the UE where it is.
How to test RRC State Changes ?
A state change is easy to see in a log but hard to cause on demand, because the network decides when it happens. So a test setup needs a way to control the network side, or at least to predict it.
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.
Whichever setup you use, the same few fields tell you what happened in the log. The RRC state indicator in each reconfiguration message gives the target state. The cause in each CELL UPDATE tells you whether the UE or the network started the move out of PCH. The time between the last user data and each reconfiguration gives you the T1 and T2 of the network.
A live network shows the real timers : but it does not let you choose when the state changes, and it may not use the PCH states at all.A network simulator gives control : it can trigger the change at a fixed moment, or from an IP throughput condition.Check the IEs, not only the message names : the RRC state indicator and the cell update cause tell you the transition and who started it.
Reference
- 3GPP TS 25.331 : Radio Resource Control (RRC); Protocol specification, v19.0.1. Subclauses 7.1, 7.2.2, 8.1.14, 8.2.2, 8.3.1, 14.4.2 and the ASN.1 of RRC-StateIndicator.