THERE ARE TWO TYPES OF RRC STATES IN WCDMA

IDLE
CONNECTED

1- IDLE MODE :
A-UE SWITCHED ON
B- IT CONDUCTS THE CELL SEARCH PROCEDURE & TUNES TO THE CONTROL CHANNEL OF
AN APPROPRIATE CELL
C- AFTER CAMPING ON A CELL UE CAN RECEIVE SYATEM INFO & BROADCAST MSG.

2- CONNECTED MODE: THERE ARE 4 TYPES IN THIS MODE

2.1 CELL DCH
2.2 CELL PCH
2.3 CELL FACH
2.4 URA PCH.

CELL_DCH state is characterized by:
A dedicated physical channel is allocated to the UE in uplink and downlink.
The UE is known on cell level according to its current active set.
Dedicated transport channels, downlink and uplink (TDD) shared transport
channels, and a combination of these transport channels can be used by the
UE.
CELL_FACH state is characterized by:
No dedicated physical channel is allocated to the UE.
The UE continuously monitors a FACH in the downlink.
The UE is assigned a default common or shared transport channel in the uplink
(e.g. RACH) that it can use anytime according to the access procedure for
that transport channel.
The position of the UE is known by UTRAN on cell level according to the cell
where the UE last made a cell update.
In TDD mode, one or several USCH or DSCH transport channels may have been
established.
CELL_PCH state is characterized by:
No dedicated physical channel is allocated to the UE.
The UE selects a PCH with the algorithm, and uses DRX for monitoring the
selected PCH via an associated PICH.
No uplink activity is possible.
The position of the UE is known by UTRAN on cell level according to the cell
where the UE last made a cell update in CELL_FACH state.
URA_PCH State is characterized by:

No dedicated channel is allocated to the UE.
The UE selects a PCH with the algorithm, and uses DRX for monitoring the
selected PCH via an associated PICH.
No uplink activity is possible.
The location of the UE is known on UTRAN Registration area level according to
the URA assigned to the UE during the last URA update in CELL_FACH state.

Now lets take a general example of all above mentioned stages.
Suppose I connect a Data card & when the connection established a homepage is opened. Now
if we dont do any kind of further activity then the UE will be Cell_FACH mode. It is used for
smaller data transfer like 32Kb.

If we started large data transfer then the UE will be in Cell_DCH mode means a dedicated
channel will be assigned to the user.
After Cell_FACH mode suppose we didnt do anything & the inactivity timer is expired then the
stage of UE would be either in Cell_PCH mode or in URA_PCH.

Cell_PCH mode is kept for those users who are in a single cell. They are not roaming anywhere .
Throughout the time they will be in a single cell (in case of Data Card)

Now for those users whose cell update happens frequently at that time the UEs will be in
URA_PCH mode (URA= UMTS Radio Area).

In URA_PCH Mode we will be having a group of Cells together define as a URA ID so that UE will
only update their location when their URA ID will change.

During the paging time if the UE is in Cell_PCH mode at that time paging occurs only for that
particular Cell form which UE is Presently latched on. Where as in URA_PCH mode paging occurs
for Particular URA_ID in which its also pages the Cells that are present in that particular URA_ID.
Due to this Keeping the User in URA_PCH mode Paging Load will increase in the Network.

So in Release 7 a new feature is introduced that is called CPC (Continuous Packet Connectivity ).
Enabling CPC on those particular cells where user paging behavior is like that , so what UE will
do when the inactivity timer is going to be expire, UE will send a bit so that timer will never
expire for only that kind of users & the paging load will also decrease in the network & the UE
will always remain in Cell_FACH mode.

*Cell_PCH mode is not there in Ericsson System











Some Ericsson Radio Connection Supervision (RCS) Parameters are listed below

1. cchWaitCuT: Waiting timer for cell update.

2. t305: The maximum time between adjacent Cell Updates (UE in CELL_FACH
state) or URA Update (UE in URA_PCH state). Infinity means no update.

3. rlFailureT: Guard period before sending RL Failure.

4. nInSyncInd: Number of frames to be considered for in-sync detection.

5. nOutSyncInd: Number of frames to be considered for out-of-sync detection.
dchRcLostTTimer that is started when all radio links for a connection are lost. At time-out, the
radio connection is considered lost.

6. blerQualityTargetDl: BLER quality target in the downlink.
This attribute is valid only if CRC is used.
7. blerQualityTargetUl: BLER quality target in the uplink.
This attribute is valid only if CRC is used.
8. hsDschRcLostT: Controls the RCS timer for supervision of uplink synch of RLS
containing the serving HS-DSCH radio link.