Signaling Flow of WCDMA Advanced

Radio Interfaces

ZTE University
Objectives

To understand the main service flows and

classification of WCDMA radio interfaces.
To understand network selection and cell re-
selection flows.
To understand the handover flow in the
system.
To understand the call service flow.
Content

Overview of the Basic Signaling Flow

Network Selection Flow
Handover Flow in the System
Call Service Flow
Service Release Flow
Classification of Flows
A variety of signaling flows exist in a WCDMA system. In terms of protocol
stack, signaling flows can be access layer signaling flows or non-access layer
signaling flows. In terms of network composition, signaling flows can be
categorized as circuit-switched or packet-switched.
Access layer and non-access layer signaling flows are actually so named from
the perspective of protocol stack. In the protocol stack, the RRC layer, RANAP
layer, and the protocol layers below them are access layers, while the MM, SM,
CC, and SMS layers above them are known as non-access layers. Simply put,
the flow at the access layer is the flow where the RNCs and NodeBs at the
radio access layer need to take part in the processing. The flow at a non-
access layer refers to a signaling flow where only UEs and CNs, but not RNCs
or NodeBs, need to take part in the processing. The signaling at the access
layer paves the way for the signaling interaction at a non-access layer.
Through the signaling interaction at the access layer, a signaling path is
established between the UE and CN so that the signaling flow at a non-access
layer can be started.
The flows at the access layer include PLMN selection, cell selection, and radio
resource management flows. The radio resource management flows are the
flows at the RRC layer, including the RRC connection setup flow, flow of the
signaling setup between UEs and CNs, RAB setup flow, call release flow,
handover flow, and SRNS redirection flow. For the handover and SRNS
redirection flows, the cross-RNC and cross-SGSN/MSC cases exist. In such
cases, SGSN/MSC is also needed. Therefore, from the perspective of protocol
stack, the flows at the access layer are all bottom layer flows, through which
bottom layer bearer is established for the signaling flows at upper layers.
Uu Protocol Layers
Control Plane User Plane
Network layer protocol:
Non Access
Management functions: MM, CC Ipv4, Ipv6, ... AMR Stratum
Layer 3

RRC (Radio Resource Control)

PDCP BMC

Access
Layer 2 RLC (Radio Link Control) Stratum

MAC (Medium Access Control)

Layer 1 PHY (PHYsical)

Calling service flow
When a subscriber UE is powered on, the signaling interaction at the access layer is
performed first. PLMN selection is then performed to select the network of a carrier,
followed by cell selection to reside in an appropriate cell. After that, an RRC connection is
established and the signaling connection on the Iu interface is set up. At this point, through
the signaling flows at these access layers, a signaling channel is established between the
UE and CN in preparations for the signaling flows at non-access layers.
Then, the mobility management flows at non-access layers between the UE and CN are
started. The subscriber then starts attached flows, including small flows such as
authentication, encryption, and location update.
After the flows such as authentication pass, the UE enters the service-related flows at non-
access layers. Such flows include the call connection flows of the circuit domain and the
session management flows of the packet domain. Through these flows, the service bearer
links are established for the service. After that, the subscriber can start to make a call or
access the Internet.
When the subscriber finishes using the service, the call connection flows of the circuit
domain and the session management flows of the packet domain are also performed to
tear down the service bearer links.
If the subscriber powers off his/her mobile phone, the mobility management flows at non-
access layers are performed between the UE and CN to separate the circuit domain from
the packet domain.
When the signaling interaction at non-access layers is complete, the system performs the
signaling flows at the access layer to tear down the Iu signaling connection and RRC
signaling connection previously established.
At this point, the whole flow in which a subscriber powers on his/her mobile phone, uses
the service, and powers off the mobile phone without moving is complete. This shows that
the completion of the service process requires the cooperation between the signaling flows
at the access layer and those at non-access layers. The flows at the access layer establish
the signal bearer for the flows at non-access layers.
Called Service Flow

MM/SM/CC/SMS
Layer

:RRC

:RANAP
UTRAN CN

RRC


Iu

MM

CC





SM

CC





SM

RRC


Iu








Called service flow
The subscriber UE is in standby mode. The subscriber UE is
paged from the network side.
If no signaling connection exists between the UE and CN, the
signaling flows at the access layer are performed between the
UE, RNC, and CN to establish an RRC connection and Iu
interface signaling connection.
Then, the authentication and encryption flows of mobility
management may be performed.
After that, service bearer links are established through the call
connection flows of the circuit domain and session
management flows of the packet domain so that the service
can be performed.
When the service is finished, the related service bearer links
are torn down.
Then, the signaling connections at the access layer, including
the signaling connection on the Iu interface and the RRC
connection, are released.
UE State
UE state
1.CELL_DCH state
The CELL_DCH state has the following features:
(1) A dedicated physical channel is assigned to the UE
along the uplink and downlink;
(2) The cell to which the UE belongs can be obtained
through the current active set of the UE;
(3) The UE can use the dedicated transport channel,
uplink/downlink shard transport channel, or a combination
of these transport channels.
The UE enters the CELL_DCH state in the following two ways:
(1) When the UE is in idle mode, the RRC connection is
established on the dedicated channel, and therefore the UE
enters the CELL_DCH state from idle mode;
(2) When in the CELL_FACH state, the UE uses the
common transport channel and uses the dedicated
transport channel after a channel switchover. The UE
enters the CELL_DCH state from the CELL_FACH state.
UE state
CELL_FACH state
The CELL_FACH state has the following features:
(1) No dedicated transport channel is assigned to the UE.
(2) UE continuously listens on a downlink FACH channel.
(3) A default uplink common channel or uplink shared transport channel (for
example, RACH) is assigned to the UE so that the UE can use the channel at
any time during the access.
(4) The location of the UE is known to the UTRAN network at the cell level and
is specifically the cell reported when the UE sent the most recent cell update.
In the CELL_FACH sub-state, the UE:
(1) Listens on a FACH.
(2) Listens on the BCH of the current service cell to decode the system
information messages.
(3) Initiates a cell update when the cell changes to another UTRA cell.
(4) Uses the C-RNTI assigned in the current cell as the UE identifier on the
common transport channel unless a new cell is selected.
(5) Transports uplink control signaling and small packets on the RACH.
In the CELL_FACH state, if the data service remains inactive during a period of
time, the UE enters the CELL_PCH state to reduce power loss. In addition,
when the UE temporarily gets out of the CELL_PCH to perform a cell update
and the update is complete, if there is no data transport need at the UE or
network side, the UE returns to the CELL_PCH state.
UE state
The CELL_PCH state has the following features:
(1) No dedicated transport channel is assigned to the UE.
(2) The UE uses the Discontinuous Reception Mechanism (DRX) technology to
listen on the information on the PCH at a particular paging time.
(3) No location of any uplink active UE should be known to the UTRAN at the
cell level. The location is specifically the cell reported when UE sends the most
recent cell update in the CELL_FACH state.
In the CELL_PCH state, the UE performs the following actions:
(1) The UE listens on the paging time at the DRX interval and receives the
paging messages on the PCH.
(2) Listens on the BCH of the current service cell to decode the system
information.
(3) The UE initiates a cell update when the cell changes.
(4) In this state, the UE cannot use the DCCH logical channel. If the network
attempts to initiate any activity, the network needs to sends a paging request on
the PCCH logical channel in the cell to which the UE belongs.
The UE enters the CELL_FACH state in two ways. One is through UTRAN
paging, and the other is through any uplink access.
UE state
URA_PCH state
The URA_PCH state has the following features:
(1) No dedicated transport channel is assigned to the UE.
(2) The UE uses the DRX technology to listen on the information on the PCH at
a paticular paging time.
(3) No uplink activity should be performed.
(4) The location of the UE is known to the UTRAN at the URA level and is
specifically the URA reported when UE sends the most recent URA update in
the CELL_FACH state.
In the URA_PCH state, the UE performs the following actions:
(1) The UE listens on the paging time at the DRX interval and receives the
paging messages on the PCH.
(2) The UE listens on the BCH of the current service cell to decode the system
information.
(3) The UE initiates a URA update when the URA changes.
(4) In this state, the UE cannot use the DCCH logical channel. If the network
attempts to initiate any activity, the network needs to sends a paging request on
the PCCH logical channel of the URA to which the UE belongs.
(5) In the URA_PCH state, no resource is assigned for the use in data transport.
Therefore, the UE needs to enter the CELL_FACH state before transporting
any data.
UTRAN State Transitions in Connection Mode
Cell_FACH ->URA_PCH
Instruction from UTRAN

URA_PCH-> Cell_FACH Cell_DCH ->URA_PCH

UL activity or paging 1 Release DCH (phys channel
reconfiguration, RB reconfig.)

URA_PCH Cell_PCH
Cell_FACH ->Cell_PCH
Cell_DCH ->URA_PCH Instruction from UTRAN
Release DCH (phys channel
reconfiguration, RB reconfig.) Cell_PCH ->Cell_FACH
Through paging type1
Cell_DCH Cell_FACH
Cell_DCH -> Cell_FACH
All dedicated channels released
Cell-DCH -> Idle
Cell_FACH ->Idle
Release RRC connotation Cell_FACH -> Cell_DCH
Release RRC connection
Establish dedicated channels
Idle ->Cell_DCH
Idle ->Cell FACH
RRC connection establishment
RRC connection establishment

Idle
UTRAN State Transitions in Connection Mode
CELL_DCH state
1. Transition from the CELL_DCH state to the idle mode

The UE enters idle mode after releasing the RRC connection.

2. Transition from the CELL_DCH state to the CELL_FACH state
When all the dedicated physical channels are released, the state
transitions to CELL_FACH. The state transition is completed through
clear signaling (for example, physical channel reconfiguration, radio
bearer reconfiguration, radio bearer release, radio bearer
establishment, and transport channel reconfiguration).
3. Transition from the CELL_DCH state to the CELL_PCH state
This state transition is completed through clear signaling (for example,
physical channel reconfiguration, radio bearer reconfiguration, radio
bearer release, radio bearer establishment, and transport channel
reconfiguration).
4. Transition from the CELL_DCH state to the URA_PCH state
This state transition is completed through clear signaling (for example,
physical channel reconfiguration, radio bearer reconfiguration, radio
bearer release, radio bearer establishment, and transport channel
reconfiguration).
UTRAN State Transitions in Connection Mode
5. Radio resource allocation task (CELL_DCH)
For DCH, multiple physical channel allocation policies should be provided. Such allocation may be
permanent (a DCH release message is needed) or based on time segment or data volume.
For each burst packet, resource configuration can be completed through the fast signaling on the DCH.
For each radio frame, the UE and network use the Transport Format Combination Indicator (TFCI) to
indicate the current data rates (respectively corresponding to uplink and downlink traffic). In TDD mode,
however, DCH and DSCH or USCH may be mapped to different CCTrCHs, with their respective TFCIs
completely independent. DCH transport does not change because the DSCH/USCH exists at the same time.
If the configured combination set (the transport format set for a transport channel) is found to be insufficient
to maintain the QoS required by a transport channel, the network starts a transport format set (TFS) for the
transport channel for reconfiguration. The reconfiguration can be completed during or between data transport.
In addition, on the network, physical channels can be configured and the peak data rates can be increased
or decreased.
For uplink data transport, the UE reports the service traffic observed to the network so that the network can
re-assess the current resource allocation. This report should contain the volume of data to be transported,
buffer statuses within the UE, and so on.
6. RRC connection mobility task (CELL_DCH)
Whether to use macro diversity (soft handover) is used depending on the data quantity and frequency.
RRC connection mobility is processed by measurement report, soft handover, and non-
synchronization/synchronization.
7. UE measurement (CELL_DCH)
The UE should perform the measurement according to the measurement control information and send a
measurement report.
The UE should use the connection mode measurement control information received in other states until the
UE is assigned new measurement control information.
8. Capturing of system information (CELL_DCH)
In FDD mode, a UE with a specific capability (This UE supports the reception on one SCCPCH and one
DPCH simultaneously) can read the system information broadcast on the FACH.
UTRAN State Transitions in Connection Mode
1. Transition from the CELL_FACH state to the CELL_DCH state
This state transition is completed when a dedicated physical channel is established through clear signaling
(for example, physical channel reconfiguration, radio bearer reconfiguration, radio bearer release, radio
bearer establishment, and transport channel reconfiguration).
2. Transition from the CELL_FACH state to the CELL_PCH state
This state transition occurs when the UTRAN instructs the UE to enter the CELL_PCH state through clear
signaling, such as cell update confirmation and radio bearer reconfiguration.
3. Transition from the CELL_FACH state to idle mode
The UE enters the idle mode after releasing the RRC connection.
4. Transition from the CELL_FACH state to the URA_PCH state
This state transition occurs when the UTRAN instructs the UE to enter the URA_PCH state through clear
signaling, such as URA update confirmation and radio bearer reconfiguration.
5. Radio resource allocation task (CELL_FACH)
In the CELL_FACH state, the UE listens on a FACH. The UE should be able to send uplink control signals
and send small packets on the RACH.
The network can assign in advance transport channel parameters, such as the transport format set, to the
UE for use when the UE uses the DCH. When a physical channel is assigned to the DCH, the UE should
enter the CELL_DCH state and is used as the TFS allocated in advance to the DCH.
If no UE dedicated physical channel or transport channel configuration is specified, the UE should use the
common physical channel and transport channel configuration according to the system information.
For uplink data transport, the UE reports the service traffic observed to the network so that the network can
re-assess the current resource allocation. This report should contain the volume of data to be transported,
buffer statuses within the UE, and so on.
When user data or control data is transmitted, a selection process is started to determine whether to
transport the data through a common transport channel or to transition to the CELL_DCH state. This
selection is dynamic and dependent on specific parameters, such as service parameters (data size and
packet burst frequency).
In FDD mode, the UTRAN can assign CPCH resources to the UE in the CELL_FACH state. After being
assigned CPCH resources, the UE continues to listen on the FACH. The UE may use the RACH to send
uplink control signals and small packets. The UE can also choose to send large packets (larger than the
packets carried on the RACH) on the CPCH. The UE chooses either the RACH or one CPCH to maximally
use the available capacity on the channel.
UTRAN State Transitions in Connection Mode
In FDD mode, for each CPCH used, the UE provides the UTRAN with CPCH measurement data, including
data, queue length (the size of the current data buffer), average access time, and the service traffic of each
CPCH used. Based on the measurement information, the UTRAN can periodically reassign network
resources. The UTRAN assigns a CPCH set to each cell and assigns one to the UE. The UE can
dynamically access these CPCH resources without UTRAN control.
6. RRC connection mobility task (CELL_FACH)
In this state, the UE location on the cell level is known. When the UE selects a new cell to observe the
common downlink channel of the new cell, the UE uses the cell update process to report to the UTRAN.
Data transport can initiated on the downlink FACH without paging in advance.
The UE listens on the system information about the UE itself and neighboring cells on the broadcast channel
and BCCH, and determines whether to perform a cell location update based on this information.
The UE should perform cell re-selection and start the cell update process when selecting a new UTRA cell. If
another non-UTRA radio access system cell is selected, the UE should enter the idle mode and complete
access according to the system specifications.
7. UE measurement (CELL_FACH)
The UE should perform the measurement according to the measurement control information and send a
measurement report.
By default, the UE should use the measure control information broadcast in system information. The network,
however, can also provide measurement control information in MEASUREMENT CONTROL messages. In
this case, the messages have a higher priority.
8. Sending and updating system information (CELL_FACH)
The UE should read the BCH to obtain valid system information. For each acquisition, the UE may need the
different combinations of the system information broadcast on the BCH. The system information on the
broadcast channel is arranged based on the time the UE spends in obtaining the information needed.
After the system information is modified, the time arrangement information is updated to reflect the change in
the system information transported on the BCH. The new time arrangement information is broadcast on the
FACH to notify the UE of the change. If the change is applicable to the UE, the modified system information
is read on the BCH.
UTRAN State Transitions in Connection Mode
1. Transition from the CELL_PCH state to the CELL_FACH state
The UE transitions to the CELL_FACH state through the paging (paging type 1) from the UTRAN or any
uplink access.
2. Radio resource allocation task (CELL_PCH)
In the CELL_PCH state, no resource is designated to be used for data transport. To transport data, the UE
must transition to another state.
The UE may use DRX to reduce power consumption. When the DRX is used, only one paging occasion is
needed for each DRX interval. The network may instruct the UE to use a specific DRX interval length. The
UE should determine its paging occasion in a mode the same as the idle mode.
3. RRC connection mobility task (CELL_PCH)
In the CELL_PCH state, the UE mobility is performed through the cell re-selection process.
The UE should perform cell re-selection. When selecting a new UTRA cell, the UE transitions to the
CELL_FACH state and starts a cell update process in the new cell. After the cell update process is
performed, if neither the UE nor the network transports data , the UE should return to the CELL_PCH state.
If another non-UTRA radio access system cell is selected, the UE should enter the idle mode and complete
access according to the system specifications.
When the UE activity is low, the UTRAN may order the UE to transition to the URA_PCH state to reduce
frequent cell updates. This transition is completed through the CELL_FACH state. The UTRAN may provide
a inactive timer and an optional counter used to count the number of cell updates. When the number of cell
updates exceeds a certain limit (network parameter), the UTRAN orders the UE to transition to the
URA_PCH state.
4. UE measurement (CELL_PCH)
The UE should perform the measurement according to the measurement control information and send a
measurement report.
When no dedicated measurement control information is assigned to the UE, the UE should uses the
measurement control information according to the system information.
5. Updating of transport and system information (CELL_PCH)
The UE should read the BCH to obtain valid system information. For each acquisition, the UE may need the
different combinations of the system information broadcast on the BCH. The system information on the
broadcast channel is arranged based on the time the UE spends in obtaining the information needed.
UTRAN State Transitions in Connection Mode
1. Transition from the URA_PCH state to the CELL_FACH state (URA_PCH)
Any activity will cause the UE to transition to the CELL_FACH state. For example, the RACH performs uplink
access or the paging (paging type 1) from the UTRAN.
Note that an RRC connection cannot be released in the URA_PCH state. The UE must first transition to the
CELL_FACH state before releasing the signing.
2. Radio resource allocation task (URA_PCH)
In the URA_PCH state, no resource is designated to be used for data transport. To transport data, the UE
must transition to the CELL_FACH state.
The UE may use DRX to reduce power consumption. When the DRX is used, only one paging occasion is
needed for each DRX interval. The network may instruct the UE to use a specific DRX interval length. The
UE should determine its paging occasion in a mode the same as the idle mode.
3. RRC connection mobility task (URA_PCH)
In the URA_PCH state, the location of the UE on the URA level is known.
In this state, mobility is completed through the URA re-selection process. The UE should perform cell re-
selection. When selecting a new UTRA cell (This URA cell is not the one originally used by the UE), the UE
should transition to the CELL_FACH state and initiate a URA update to the network. After the URA update
process is performed, if neither the UE nor the network transports data , the UE should return to the
URA_PCH state.
If another non-UTRA radio access system cell is selected, the UE should enter the idle mode and complete
access according to the system specifications.
4. UE measurement (URA_PCH)
The UE should perform the measurement according to the measurement control information and send a
measurement report.
When no dedicated measurement control information is assigned to the UE, the UE should uses the
measurement control information according to the system information.
5. Sending and updating system information (URA_PCH)
In the URA_PCH state, the mechanism of sending and updating system information is the same as that in
CELL_PCH state.
Content

Overview of the Basic Signaling Flow

Network Selection Flow
Handover Flow in the System
Call Service Flow
Service Release Flow
Network Selection Flow
Network selection flow
After being powered on, the UE first selects a PLMN. After
selecting a PLMN, the UE begins to select a cell belonging to
this PLMN. When such a cell is found, the information about
the neighboring cell can be obtained from the system
information (broadcast). Thus, the UE can select a cell with the
best signals among these cells and reside in the cell. Then, the
UE initiates the location registration process (attach or location
update). If the operation succeeds, the UE resides in the cell.
The UE resides in the cell for four purposes:
1. To receive the system information broadcast by the

PLMN.
2. To initiate the random access process in the cell.

3. To receive paging from the network.

4. To receive the broadcast services of the cell.

Network selection flow
When the UE resides in the cell and the registration succeeds, as the
UE moves, the signal strengths of the current cell and the neighboring
cell keep changing. In this case, the UE needs to select a most
suitable cell. This is known as the cell re-selection process. This most
suitable cell is not necessarily the cell that currently has the best
signals. The reason is this: suppose the UE is at the edge of a cell
and moves to and fro between the two cells, which happen to belong
to different LAs or RAs. Thus, the UE needs to keeps initiating location
updates. This wastes not only resources but also the UE energy.
Therefore, there are certain rules as to which cell to be reselected
among all the cells.
After the UE reselects a cell, if the cell is found to belong to another
rLA or RA, the UE initiates the location update process so that the
network obtains the latest UE location information. The UE discovers
LA or RA changes through the SIB1 in the system broadcast
information.
If the location registration or update fails, for example, when the
network rejects the UE, or when the current PLMN is out of the
coverage area, the UE can perform PLMN re-selection to select
another usable PLMN.
Cell Selection and Re-selection

After selecting a PLMN, the UE begins to select a

cell, aiming to select the cell belonging to the PLMN
and with the best signals.
If the UE stores information, such as frequency and
scrambling code, related to the PLMN, the UE
performs a cell search (stored information cell
selection) by using the information. Thus, a network
can be found quickly. This is because in most cases,
the UE is powered off and on in the same place. For
example, the UE is powered off at night and is
powered on in the morning. Such information is
stored in the SIM card or the non-volatile memory of
the mobile phone.
Cell selection
Freq. Has been locked

1. Slot synchronization

Cell 2. Frame synchronization

search & PSC group identification
Select the next freq.

3. PSC identification

UE reads BCH

Right PLMN ?
False

Read SIBs
Cell selection

UE reads SIB3

Cell residence No UE tries to find a cell among

standards are met ? Neighbors (SIB11)

UE resides in the cell.

UE reads other needed system informations
UE bigin LA registration
Cell Selection
The procedure of cell selection is roughly as follows:
1. Cell search

The purpose of cell search is to find a cell, which, though,

may not belong to the selected PLMN. The steps of cell
search are as follows (A frequency needs to be locked first,
of course): The UE obtains timeslot synchronization
through the primary SCH. After timeslot synchronization,
frame synchronization needs to be performed. Frame
synchronization is completed through the synchronization
code of the secondary SCH. In this procedure, the
scrambling code group of the cell is also determined. Then,
the UE associates each scrambling code of the scrambling
code group on the CPICH until it finds the greatest one
among the related results. Thus, the primary scrambling
code is determined. Obviously, if the UE already knows
some information about the cell, such as the frequency
used and even the primary scrambling code, the above-
mentioned procedure can be accelerated greatly.
Cell Selection
2. Reading the broadcast channel
From the above-mentioned procedure, the UE obtains the scrambling code of
the PCCPCH, whose channel code is known and unique through the whole
UTRAN. Thus, the UE can read the information of the broadcast channel.
When reading the MIB, the UE can determine whether the found PLMN is the
one intended, because there is a PLMN domain in the MIB. If yes, the UE finds
another SIB and obtains its contents based on the scheduling information in
other SIBs contained in the MIB. If not, the UE has to look for the next
frequency, starting the procedure all over again (from cell search).
If the current PLMN is the one intended by the UE, the UE reads SIB3 and
obtains "Cell selection and re-selection". Through the information obtained, the
UE performs calculations to determine whether the cell residence standards
are met. If yes, the UE considers the cell a suitable cell. The UE resides in the
cell and reads the other system information needed and initiates the location
registration procedure.
If the above-mentioned conditions are not met, the UE reads SIB11 and obtains
the information on the neighboring cells. Thus, the UE can perform calculations
and determines whether the neighboring cell meets the cell selection residence
standards.
If the UE finds that any neighboring meets the cell residence standards, the UE
resides in the cell, reads other system information needed, and initiates the
location registration procedure.
If the UE finds no cell that meets the cell residence standards, the UE
considers that there is coverage and continues the PLMN selection and re-
selection.
Cell Re-selection

In idle mode, the UE keeps monitoring the signal

quality of the current cell and neighboring cells to
select the best cell for providing services. This is
known as cell re-selection. If the cell re-selection
conditions are met within the re-selection time, the
UE selects the cell, resides in the cell, and reads the
broadcast messages of the cell. Cell re-selection is
complete.
Content

Overview of the Basic Signaling Flow

Network Selection Flow
Handover Flow in the System
Call Service Flow
Service Release Flow
Handover Overview
Handover is one of the most remarkable features that distinguish mobile
communications from fixed communications. UTRA FD supports the following
handover modes:
1. Intra-mode handover: Softer handover, soft handover, and hard handover
are intra-mode handovers. A hard handover can be a intra-frequency handover
or inter-frequency handover.
2. Inter-system handover: For the R99, an inter-system handover refers a
handover to the GSM system, namely, a handover to the 900 MHz, 1800 MHz,
1900 MHz GSM systems.
During a hard handover, before a new link is established, the old link of a
mobile station is released. That is, a channel can be established only after it is
released. The old channel is torn down before being synchronized with the new
channel. The old and the new channels do not take effect at the same time.
During a soft handover or softer handover, the mobile station and UTRAN
maintain at least one link between them. That is, a channel is removed before
a new channel is established. The original channel is removed only after the
new channel takes effect.
Inter-frequency handovers and inter-system handovers are always hard
handovers. Intra-frequency handovers are not necessarily soft handovers. For
example, if no Iur interface exists, a cross-Iur interface intra-frequency
handover is a hard handover, and the new and old links cannot take effect at
the same time. Here is another example. If the transmitting diversity modes of
intra-frequency cells are different, no soft handover can be performed, either.
Basic Concepts:

1. Active set: Set of cells connected to a mobile

station. Subscriber information is sent from these
cells.
2. Monitor set: Cells not in the active set but
monitored according to the adjacent cell list
assigned by the UTRAN belong to the monitor set.
The UE measures the cells in the monitor set. If the
measurement results meet certain conditions, these
cells may be added to the active set. Therefore, the
monitor set is sometimes known as the candidate
set.
3. Detected Set: Set of cells in neither the active set
nor the monitor set.
Typical Handover Procedure:

The typical handover procedure is measurement

control -> measurement report -> handover decision
-> handover execution -> new measurement control.
During the measurement control phase, the network
sends measurement control messages to notify the
UE of the parameters of the measurement. During
the measurement report phase, the UE sends
measurement report messages to the network.
During the handover decision phase, the network
makes a handover decision based on the
measurement report. During the handover execution,
phase, the UE and network carry out the signaling
flow and give responses according to the signaling.
Typical Handover Procedure:
Mainly initiated by the network side, soft handovers are one of the
indispensable core technologies unique to the direct spread spectrum
CDMA system. Soft handovers are used to update UE active sets in
the CELL-DCH state. During a soft handover, multiple service
channels are activated (for the diversity of service channels) between
intra-frequency channels to effectively lower the call drop rate in the
handover. A soft handover is performed at the same frequency in
different base stations. A soft handover performed between the
sectors with the same frequency in the same base station is known as
a softer handover. When a softer handover is performed, diversity
signals are merged to the largest ratio at NodeB. This is different from
a soft handover where selective merging of diversity signals is
performed at the RNC. The RNC soft handover and softer handover
flow consists of two steps: radio link operations on the Iub interface
and active set update operations on the Uu interface. Radio link
operations on the Iub interface are RADIO LINK SETUP, RADIO LINK
ADDITION, and RADIO LINK REMOVAL. Active set update
operations on the Uu interface are soft addition, software removal,
and soft replacement.
Typical Handover Procedure:
Difference between a soft handover and a softer handover is as
follows: Soft handover means uplink link merging in macro-diversity
status is performed at an RNC. Softer handover means the merging of
uplinks is performed at NodeB.
During a softer handover, a mobile station is located where the
coverage of two adjacent sectors of a base station overlaps. The
mobile station and base station communicate with each other through
two air interface channels. There is one air interface channel in each
sector. Thus, two spread spectrum codes need to be used in the
downlink and the mobile station can distinguish these signals. The
mobile station receives and processes these two signals through
Rake receiver. This process is very similar to multi-path reception
except that despread spectrum codes are need to be generated for
each sector to ensure correct despread spectrum operations. In the
uplink, a similar process is performed on the base station: The code
division channel of the mobile station is received in each sector, sent
to the same baseband Rake receiver, and merged to the maximum
ratio through a normal method. During a softer handover, for each
connection, only one power control loop is active.
Typical Handover Procedure:
During a soft handover, a mobile station is located where the
coverage of two sectors of different base stations overlaps.
Same as a softer handover, the mobile station and two base
stations perform communication through two different air
interface channels at the same time. Same as a softer
handover, the mobile station receives two channels (signals)
through merging to the maximum ratio by using a Rake
receiver. From the perspective of the mobile station, there is
very little difference between a soft handover and a softer
handover. In the uplink, however, the difference between a soft
handover and a softer handover is very great: Two base
stations receive the code division channels from the mobile
station, but the received data is sent to the RNC for selective
merging. This is because the frame reliability indicator provided
for external loop power control needs to be used in the RNC to
select the better frame from the two candidate frames. Such
selection occurs each time the interlacing interval is complete.
That is, the selection occurs ever 10 ms to 80 ms.
Between Cells in NodeB

In this case, the radio uplink

can be merged in NodeB or
the SRNC. If the radio uplink
is merged in NodeB, it is
known as a softer handover.
Between NodeBs in the Same RNC

The softer handover flow is basically the same as

the soft handover flow between NodeBs. The only
difference is that a softer handover is a handover in
NodeB, with Iub interface message as RADIO LINK
ADDITION REQUEST, while the switching Iub
interface message between NodeBs is RADIO LINK
SETUP REQUEST.
Between RNCs
Hard Handover
Mainly initiated by the network side, a hard handover is used for the
handovers between the intra-frequency/inter-frequency channels of
the UE in the CELL_DCH state. During a hard handover, only one
service is activated. An inter-frequency hard handover changes the
radio frequency of the connection between the UE and UTRAN. the
trigger decision between inter-frequency channels needs inter-
frequency measurement supported by the compression mode
technologies The process of a hard handover is to first tear down the
communication with the original cell before gaining access from the
new cell. Therefore, the performance of a hard handover is not as
good as that of a soft handover. Thus, generally, an intra-frequency
hard handover is considered only when the system cannot perform a
soft handover. If the two cells involved in the handover belong to two
different RNCs between which there is no Iur interface, an intra-
frequency hard handover occurs. Depending on the range involved, a
hard handover can be a hard handover between the FDD and TTD
modes inside a cell, a hard handover between cells under the same
NodeB, a hard handover between cells in the same RNC, or a hard
handover between RNCs. Inter-RNC hard handovers fall into two
parts: hard cut-aways to the DRNC through the Iur interface and inter-
RNC hard cut-aways controlled by the core network. Inter-RNC hard
cut-aways controlled by the core network are the same as UE-related
relocation.
Hard Handover

Hard handovers correspond to Iub interface

operations and Uu interface operations. Iub interface
operations correspond to radio link reconfiguration.
Uu interface operations are completed through the
following five types of operations, of which physical
channel reconfiguration is the most commonly
performed operation.
1. RADIO BEARER SETUP;
2. RADIO BEARER RELEASE;
3. RADIO BEARER RECONFIGURATION;
4. Transport channel reconfiguration;
5. Physical channel reconfiguration;
Compression Modes
Also known as a slotted mode, a compression mode is used by a non-all frequency
receiver in a CDMA system to measure other frequencies. The signal reception and
transmission processing of a mobile phone stops for several milliseconds so that physical
layer resources are set aside for the measurement of other frequencies. The reception and
transmission are stopped not to lose data but to compress the data transmission time.
Frame compression in a compression mode can be completed in three ways:
1. Upper-layer planning
The upper layer obtains the scheduling information of the compression mode, lowers the
data rate, and inserts DTX bits when a radio frame mapping is established to create
transmission slots.
2.Spreading spectrum factors reduced by half
Change spreading spectrum factors to improve data rates. For example, the physical layer
changes the timeslot sequence number assigned by the upper layer from the timeslot
format corresponding to the spreading spectrum factor 128 to the timeslot format
corresponding to the spreading spectrum factor 64. This effectively doubles the number of
symbols for valid physical timeslots and creates blank timeslots.
3. Puncturing methods
With the spread spectrum factor and channelized code sequence unchanged, the
puncturing of rate matching module in the code, multiplexing link at the physical layer can
be used to lower the data rates. The transmission gap lengths (TGL) generated in this way,
however, are relatively short.
A compression mode is generally used for the downlink. If the uplink enters the
compression mode, the downlink must enter the compression mode in cooperation at the
same time.
Inter-Frequency Hard Handover under the
Same RNC
Inter-RNC Hard Handover under the same MSC
Inter-Systems Handover
All the inter-system handovers in the CS domain are initiated by the
network side and completed through handover commands. There are
three possibilities of CS system cut-aways: 1) Based on a
measurement report, the RNC determines that a handover to the
GSM system needs to be performed; 2) The CN specifies to perform a
handover when delivering RAB designation, namely, a inter-CS
system switching; Direct retry (For example, when no resource is
available for distribution) In terms of flow, a CS-domain inter-system
cut-away consists of two phases: Iu interface CS-domain inter-system
cut-away preparation and Uu interface inter-system cut-away request.
Iu interface CS-domain inter-system cut-away preparation phase
corresponds to the relocation preparation message. Uu interface inter-
system cut-away request phase corresponds to the cut-away
message HANDOVER FROM UTRAN COMMAND. CS-domain inter-
system cut-aways involve the Iu interface relocation process and Uu
interface system CS-domain cut-away process. The Iu interface
relocation process corresponds to the resource allocation message.
The Uu interface system CS-domain cut-away process corresponds to
the HANDOVER TO UTRAN COMPLETE message, with the Uu
interface system CS-domain cut-away process as an intermediate
process.
Handover between systems
A PS-domain handover can be initiated by the UE or by the network side. A
PS-domain cut-away is initiated by the network side for the UE in the
CELL_DCH or CELL_FACH state, involving the Uu interface PS-domain cut-
away process and Iu interface context information acquisition process. The Uu
interface PS-domain cut-away process corresponds to the CELL CHANGE
ORDER FROM UTRAN message. The Iu interface context information
acquisition is an intermediate process, corresponding to the Iu interface
context information acquisition message. The PS-domain cut-away initiated by
the UE is for the UE in the CELL_FACH, CELL_PCH, or URA_PCH state,
triggered by the UE cell re-selection process and with no corresponding
message on Uu interface. Only the context information acquisition process
exists on the Iu interface. The context information acquisition process on the Iu
interface consists of two phases: Iu interface context information acquisition
request and context transfer, respectively corresponding to the messages
SRNS CONTEXT REQUEST/SRNC CONTEXT RESPONSE and SRNS DATA
FORWARD COMMAND/FORWARD SRNC CONTEX. Note that the failure of
Iu interface context information acquisition process does not affect subsequent
flows. PS-domain cut-in triggering corresponds to the RRC connection
establishment request message. The PS-domain cut-in initiated by the UE
corresponds to the RRC connection establishment request reason Inter-RAT
cell re-selection. The PS-domain cut-in initiated by the network side
corresponds to the RRC connection establishment request reason Inter-RAT
cell change order. The subsequent RAB assignment message on Iu interface
contains the serial number information about the PDCP and GTP-U.
Forward Handover
A forward handover means that the UE initiates a cell update/URA
update for the mobility management of the UE in the UTRAN
connection mode but using only the common channel. A cell update
generally refers to a notification of a location change of the UE in the
CELL_PCH/CELL_FACH state to the RNC for timely updating of the
information about the UE on the UTRAN side. A cell update is also
used to monitor RRC connections, switch RRC connection states, and
perform the anomaly report functions. The URA update flow is used
for the UTRAN registration area URA update by the UE in the
URA_PCH state. Depending on ranges, forward handovers fall into
two types:
1. Cell update process among the cells in the RNC. Depending on
parameter differences, this process can be divided into two flows:
one requiring reconfiguration (returning the RB/Trch/Phy
reconfiguration complete message) and the other requiring no
reconfiguration (If a parameter such as a newly assigned C_RNTI,
the UE needs to return the Mobility Info Confirm message).
2. Cell update process among different RNC cells. This process is
further divided into two flows: one requiring relocation (updating
SRNC) and the other requiring no relocation (updating DRNC).
Cell Update with SRNS Relocation
Cell Update via Iur without SRNS Relocation
Content

Overview of the Basic Signaling Flow

Network Selection Flow
Handover Flow in the System
Call Service Flow
Service Release Flow
Overview
When the UE finds a cell and reads the system messages of the cell,
the UE can obtain the parameter configuration information about the
system and the conditions for network access.
There are two types of call establishment: UE as the caller and the UE
as the callee. The difference between the two is that when the UE acts
as the callee, the system needs to page the UE in the specified area
through the paging flow before the call is established.
Regardless of whether the UE acts as the caller or callee, call
establishment and call release contain the following procedure:
1. An RRC connection is established between the UE and UTRAN.

2. A connection is established between the UE and CN through a

direct transfer message.
3. UE capability information flow.

4. RAB establishment flow.

5. RAB release and Iu release flow.

6. RRC connection release flow.

Paging Flow
Paging can be initiated by the CN or UTRAN.
The paging initiated by the CN is used to establish a signaling connection. The paging
initiated by the CN can be collaborated or non-collaborated. Through the RANAP PAGING
message, the CN indicates whether the RNC needs to perform UTRAN collaborated
paging.
In collaborated paging, the RNC checks whether the UE has any other CN-domain
signaling connection. If the UE has any other CN-domain signaling connection and is in
the CELL_DCH or CELL_FACH state, the paging message is delivered through the DCCH
channel of the existing connection on the radio interface. If the UE has any other CN-
domain signaling connection and is in the CELL_PCH or URA_PCH state, the paging
message is delivered through the PCCH channel on the radio interface. If the UE has no
other CN-domain signaling connection, the paging message is delivered through the
PCCH channel.
In non-collaborated paging, the RNC directly delivers the paging message through the
PCCH channel in the paging area specified by the CN without checking whether UE has
any CN-domain signaling connection not in the paging domain.
In paging initiated by the UTRAN, the UE in the CELL_PCH or URA_PCH state can be
paged. The UE initiates a cell update process through a paging response to transit the
user state from CELL_PCH or URA_PCH to CELL_FACH. Alternatively, when the system
information changes, the UTRAN triggers the UE (in idle mode, CELL_PCH or URA_PCH
state) to read the system information after the update again through paging messages.
If the UE is in idle mode or in the CELL_PCH or URA_PCH state. The RNC pages the UE
by using the PAGING TYPE1 message through the PCCH channel.
If the UE is in the CELL_FACH or CELL_DCH state. The RNC pages the UE by using the
PAGING TYPE2 message through the DCCH channel.
Paging the UE in Idle Mode or PCH State
The UTRAN generally pages the UE in idle mode, CELL_PCH, or
URA_PCH state by using the PAGING TYPE1 message through the
PCCH channel.
Such paging generally occurs in the following cases:
1. Paging is initiated by an upper level of the network side to
establish a call or a signaling connection;
2. The UTRAN initiates the paging that triggers UE state transition
to transit the UE state from CELL_PCH or URA_PCH to
CELL_FACH;
3. When the system information changes, the UTRAN initiates the
paging that triggers the UE to read the updated system
information. In this case, the value label of the master information
block (MIB) is contained in the "BCCH modification info" in
PAGING TYPE 1 message.
The UTRAN sends the PAGING TYPE1 message when an
appropriate paging opportunity is available to start the paging process.
The UTRAN can select multiple paging opportunities to repeatedly
page a UE to increase the possibility of the UE correctly receiving
paging messages.
The UE in idle mode or PCH state monitors the appropriate paging
opportunities and receives the paging messages from the network
layer.
Paging the UE in CELL_DCH or CELL_FACH
State (Dedicated paging)
The UTRAN generally pages the UE in CELL_DCH or
CELL_FACH state by using the PAGING TYPE2 message
through the DCCH channel.
The UTRAN sends the PAGING TYPE2 message through the
DCCH channel to initiate the paging process. Such paging is
also known as dedicated paging. The UE receives and reads
the contents in the PAGING TYPE 2 message and reports the
paging reason, paging record category identifier, and other
information to the non-access layer of the local side. The
paging flow is complete.
This process does not affect any other RRC process running
on the UE side.
If the UE finds any protocol error in the PAGING TYPE 2
message received, the UE discards the paging message, uses
the AM RLC mode through the uplink DCCH, and sends the
RRC STATUS message to the UTRAN.
Example of Paging Process
1. The CN initiates paging and the UE in idle mode.
In this case, the UTRAN pages the UE by sending a
PAGING TYPE1 message.
2. The CN initiates paging and the UE is in CELL_DCH or
CELL_FACH state of the connection mode.
In this case, the UTRAN pages the UE by sending a
PAGING TYPEE2 message.
3. The CN initiates paging and the UE is in CELL_PCH or
URA_PCH state of the connection mode.
In this case, the UTRAN first transitions the state of the UE
from CELL_PCH or URA_PCH to CELL_FACH by sending
a PAGING TYPE1 message. Then, the UTRAN pages the
UE by sending a PAGING TYPE2 message.
4. The UTRAN initiates paging and the UE is in CELL_PCH or
URA_PCH state of the connection mode.
In this case, the UTRAN pages the UE by sending a
PAGING TYPE1 message so that the state of the UE
transitions to CELL_FACH.
RRC Connection Establishment Flow
When the UE is in idle mode, if the NAS (non-access layer) of
the UE requests the establishment of a signaling connection,
the UE initiates the RRC connection request flow.
When the RNC receives an RRC connection request from the
UE, the RNC determines whether to accept or reject the
request based on a specific algorithm (. If the RNC accepts the
request, the RNC determines whether to establish the RRC
connection on a dedicated channel or common channel based
a specific radio resource algorithm. The RRC connection
establishment flows vary with RRC connection establishment
channels. If the RRC connection cannot be established, the
RNC rejects the establishment of the RRC connection.
Description
RRC connection establishment requests are always initiated by
the UE. An RRC connection release request is initiated by the
RNC. Each UE can have up to one RRC connection.
Establishing an RRC Connection on a
Dedicated Channel
Description of the Signaling Flow:

The sends an RRC CONNECTION REQUEST message through the uplink

CCCH to request the establishment of an RRC connection.
The RNC determines that the UE is established on a dedicated channel based
on the reason of the RRC connection request and system resource status, and
assigns RNTI, radio resources, and other resources (L1 and L2 resources).
The RNC sends a RADIO LINK SETUP REQUEST message to NodeB to
request the NodeB to assign the specific radio link resources needed for
establishing the RRC connection.
Upon completing the resource preparations, NodeB sends a RADIO LINK
SETUP RESPONSE message to the RNC.
The RNC establishes the Iub interface user plane transport bearer through
ALCAP and completes the synchronization between the RNC and NodeB.
The RNC sends a RRC CONNECTION SETUP message to the UE through
the downlink CCCH, with the message containing the information about the
dedicated channel assigned by the RNC.
After confirming the completion of the RRC connection establishment, the UE
sends an RRC CONNECTION SETUP COMPLETE message to the RNC
through the uplink DCCH. The RRC connection establishment flow ends.
Establishing an RRC Connection on a
Common Channel
RRC Connection Rejection
If the RNC determines that the RRC connection cannot be
established (for example, due to insufficient resources), the
RNC directly sends the UE an RRC CONNECTION REJECT
message which contains the reason for the rejection of the
RRC connection.
Direct Transfer Message Flow
A direct transfer refers to the signaling interaction NAS information,
such as authentication, service request, and connection establishment,
between the UE and CN. As these messages are transported
transparently in the RNC, they are known as direct transfer messages.
The RRC connection established is only the signaling connection
between the UE and RNC. Therefore, for the transport of direct
transfer messages, the signaling connections between the UE and CN
need to be established. When the RNC receives the first direct
transfer message (namely, the INITIAL DIRECT TRANSFER
message), the signaling connection between the RNC and the CN is
established on the SCCP of SS7.
After a signaling connection is established between the UE and CN,
the message sent by the UE to the CN is sent to the RNC through an
UPLINK DIRECT TRANSFER message. The RNC converts the
message to a DIRECT TRANSFER and sends it to the CN. The
message that the CN sends to the UE is sent to the RNC through a
DIRECT TRANSFER message. The RNC converts the message into
a DOWNLINK DIRECT TRANSFER, and sends it to the UE.
Initial Direct Transfer
The initial direct transfer process is used to establish a signaling connection
between the RNC and CN, carrying an initialized NAS message. The contents
of the NAS message is not explained in the RNC but forwarded to the CN.
Description
When the UE is in the CELL_PCH or URA_PCH state, for initial direct transfer,
a cell update is performed first so that the state of the UE transitions to
CELL_FACH, with a update reason of "uplink data transmission". When the cell
update is completed successfully, the UE continues to perform initial direct
transfer.
Description of the Signaling Flow

After an RRC connection is established, the UE sends the RNC an INITIAL

DIRECT TRANSFER message through the RRC connection. The message
carries the initial NAS information that the UE sends to the CN, CN identifier,
and other contents.
Upon receiving the INITIAL DIRECT TRANSFER message from the UE, the
RNC sends the CN an SCCP CONNECTION REQUEST message through Iu
interface.The message data is the INITIAL UE MESSAGE that the RNC sends
to the CN. This message contains the message contents that the UE sends to
the CN.
If the CN is to receive a connection request, the CN returns an SSCP
CONNECTION CONFIRM message to the RNC, indicating that the SCCP
connection is established successfully. Upon receiving the message, the RNC
confirms that the signaling connection is established successfully.
If the CN cannot accept a connection request, the CN returns an SCCP
CONNECTION REFUSE CONFIRM message to the RNC, indicating that the
SCCP connection establishment fails. Upon receiving the message the RNC,
the RNC confirms that the signaling connection establishment fails, and the
RRC release flow is initiated.
For the NAS contents carried in initial direct transfer, the CN sends the
information about the acceptance or rejection of the service to the UE through
the downlink direct transfer flow.
Uplink Direct Transfer
When the UE needs to send a NAS message to the CN on an existing
signaling connection, the UE initiates the uplink direct transfer procedure.
Description of the Signaling Flow:
1. The UE sends an UPLINK DIRECT TRANSFER message to the RNC to
initiate the uplink direct transfer process. The message contains such
information as NAS message and CN identification.
2. The RNC routes the message according to the CN identifier in the message
and sends the NAS information carried in the message to the CN through a
DIRECT TRANSFER message on Iu interface. The uplink direct transfer
process is complete.
Signaling Flow Description
1. The CN sends a DIRECT TRANSFER message to the RNC to initiate the
downlink direct transfer process. The message contains the NAS message.
2. The UTRAN sends a DOWNLINK DIRECT TRANSFER message through
the DCCH channel in AM RLC mode. The message carries the NAS
information that the CN sends to the UE and CN identifier.
The UE receives and reads the DOWNLINK DIRECT TRANSFER message
carrying the NAS information. If the received message contains a protocol error,
the UE sends an RRC STATUS message on the uplink DCCH in AM RLC
mode.
UE Capability Information Flow
UE capability information includes security capability, location capability,
measurement capability, physical channel capability, and transport channel
capability.
The vendors, specifications, and capabilities of UEs are different. Therefore,
after an RRC connection is established, the UE should send UE capability
information to the UTRAN so that the network side configures the UE
according to the capability parameters supported by the UE.
UE capability information can be transferred to the RNC in the following three
scenarios:
1. After an RRC connection is established, UE capability information is
transferred to the RNC through an RRC CONNECTION SETUP COMPLETE
message.
2. After an RRC connection is established, when the RNC finds that the
corresponding capability information does not exist, the RNC sends a UE
CAPABILITY ENQUIRY message to the UE. The UE sends the UE capability
information to the RNC through a UE CAPABILITY INFORMATION message;
3. After an RRC connection is established, when the UE capability information
changes, the UE sends the new UE capability information to the RNC through a
UE CAPABILITY INFORMATION message.
UE Capability Information Flow

Through a UE CAPABILITY ENQUIRY message, the

UTRAN requests the UE to initiate the UE capability
query process. The UTRAN sends a UE
CAPABILITY ENQUIRY message through the
downlink DCCH logical channel in AM RLC mode to
complete the UE capability enquiry process.
UE Capability Information Update
If the UTRAN initiates the UE capability information enquiry process or
the UE capability information changes during the RRC connection, the
UE initiates the UE capability information update process.
The UE capability information update process is used to transfer the
radio network related capabilities supported by the UE to the UTRAN.
1. The UE sends a UE CAPABILITY INFORMATION message in
AM or UM RLC mode on uplink DCCH. The message carries the
UE capability information.
2. The UTRAN reads the UE capability information and sends a
UE CAPABILITY INFORMA CONFIRM message in AM or UM
RLC mode on the downlink DCCH channel. The UE capability
information update process is complete.
RAB Establishment Flow
The RAB is used between the UE and CN to transfer voice,
data, multimedia, and other services. The RAB is established
only after a signaling connection is established between the UE
and CN. RAB establishment is the function initiated by the CN
for execution by the UTRAN.
The basic procedure of RAB establishment is as follows: The
CN initiates a RAB ASSIGNMENT REQUEST message. The
RNC configures the parameters related to the radio network
according tot he QoS parameters in the RAB ASSIGNMENT
REQUEST, and then returns a RAB ASSIGNMENT
RESPONSE message to the CN to indicate whether the RAB
is established.
A RAB ASSIGNMENT REQUEST is always initiated by the CN.
Each UE can have one or more RABs.
RAB Establishment Flow

Depending on the RRC connection states before

and after the RAB establishment, there are three
scenarios for the RAB establishment flow:
DCH-DCH: Before the RAB is established, an RRC
connection uses the DCH. After the RAB is
established, an RRC connection uses the DCH;
CCH-DCH: Before the RAB is established, an RRC
connection uses the CCH. After the RAB is
established, an RRC connection uses the DCH;
CCH-CCH: Before the RAB is established, an RRC
connection uses the CCH. After the RAB is
established, an RRC connection uses the CCH;
DCH-DCH

When the current RRC state of the UE is DCH, the

RAB assigned can be established on DCH only.
Based on radio link reconfiguration, the RAB
establishment flow can be divided into two scenarios:
1. Synchronous reconfiguration of radio links
2. Asynchronous reconfiguration of radio links
The difference between the two is whether the new
configuration parameter can be used immediately when
the NodeB and UE receive the configuration message
delivered by the Serving Radio Network Controller
(SRNC).
DCH-DCH
In this case, synchronization and reconfiguration of radio links
need to be performed among SRNC, NodeB, and UE. The
synchronization process is as follows:
When NodeB receives a reconfiguration radio link message
delivered by the SRNC, the NodeB cannot use the new
configuration parameter immediately. Instead, the NodeB
prepares the corresponding radio resources, waits for the
reconfiguration execution message delivered by the SRNC,
and obtains the synchronization time specified by the
SRNC;
Upon receiving the configuration message delivered by the
SRNC, the UE also cannot immediately use the new
configuration parameter. Instead, the UE obtains the
synchronization time specified by the SRNC in the
message;
At the synchronization time specified by the SRNC, NodeB
and UE use the new configuration parameter at the same
time.
DCH-DCH
DCH-DCH
The CN sends a RAB ASSIGNMENT REQUEST message to the UTRAN to initiate the
RAB establishment process.
Upon receiving the RAB establishment request, the SRNC maps the QoS parameters of
the RAB to AAL2 link feature parameters and radio resource feature parameters. The
ALCAP of Iu interface initiates the user plane transport bearer establishment process
according to the AAL2 link feature parameters (For the PS domain, this step does not
exist).
The SRNC sends a RADIO LINK RECONFIGURATION PREPARE message to the
controlled NodeB to request the controlled NodeB to prepare to add one or more
dedicated channels (DCHs) carrying RAB on the existing radio link.
NodeB allocates the resources accordingly and then sends a RADIO LINK
RECONFIGURATION READY message to the SRNC to which the NodeB belongs,
notifying the SRNC that the radio link reconfiguration preparation is complete.
The ALCAP of the Iub interface in the SRNC initiates the user plane transport bearer
establishment process on Iub interface. NodeB and SRNC exchange the uplink/downlink
synchronization frames of the DCH frame protocol for synchronization.
The SRNC sends a RADIO BEARER SETUP message of the RRC protocol to the UE.
The SRNC sends a RADIO LINK RECONFIGURATION COMMIT message to the
controlled NodeB.
After executing RB setup, the UE sends a RADIO BEARER SETUP COMPLETE message
to the SRNC.
Upon receiving the RADIO BEARER SETUP COMPLETE message, the SRNC returns a
RAB ASSIGNMENT RESPONSE message to the CN. The RAB establishment flow is
complete.
RAB Establishment Flow with Asynchronous
Reconfiguration Radio Links
In this case, synchronization and reconfiguration of
radio links does not need to be performed among
SRNC, NodeB, and UE. Upon receiving the
configuration message delivered by the SRNC, the
NodeB and UE immediately use the new
configuration parameter.
RAB Establishment Flow with Asynchronous
Reconfiguration Radio Links
RAB Establishment Flow with Asynchronous
Reconfiguration Radio Links
Description of the Signaling Flow:
The CN sends a RAB ASSIGNMENT REQUEST message of the RANAP protocol to the
SRNC to initiate the RAB establishment process.
Upon receiving the RAB establishment request, the SRNC maps the QoS parameters of
the RAB to AAL2 link feature parameters and radio resource feature parameters. The
ALCAP of Iu interface initiates the user plane transport bearer establishment process
according to the AAL2 link feature parameters (For the PS domain, this step does not
exist).
In asynchronous mode, radio reconfiguration does not need to be performed
synchronously. The SRNC sends an NBAP RADIO LINK RECONFIGURATION REQUEST
message to the controlled NodeB to request the controlled NodeB to establish a new DCH
on the existing radio link.
Upon receiving the RADIO LINK RECONFIGURATION REQUEST message, NodeB
assigns the resources accordingly and then returns a RADIO LINK RECONFIGURATION
RESPONSE message to the SRNC to which the NodeB belongs, notifying the SRNC that
the radio link reconfiguration is complete.
The ALCAP of the Iub interface in the SRNC initiates the user plane transport bearer
establishment process on Iub interface. NodeB and SRNC exchange the uplink/downlink
synchronization frames of the DCH frame protocol for synchronization.
The SRNC sends a RADIO BEARER SETUP message of the RRC protocol to the UE.
After executing radio bearer setup, the UE sends a RADIO BEARER SETUP COMPLETE
message to the SRNC.
Upon receiving the RADIO BEARER SETUP COMPLETE message, the SRNC returns a
RAB ASSIGNMENT RESPONSE message to the CN. The RAB establishment flow is
complete.
RRC Connection Establishment on a CCH

When a RRC connection is established on a CCH,

the RNC can establish the assigned RAB on a DCH
according to the QoS parameters in the RAB
assignment message. In this case, the RRC
connection state needs to be changed from CCH to
DCH.
RRC Connection Establishment on a CCH
Description of the Signaling Flow:
The CN sends a RAB ASSIGNMENT REQUEST message of the RANAP
protocol to the SRNC to initiate the RAB establishment process.
Upon receiving the RAB establishment request, the SRNC maps the QoS
parameters of the RAB to AAL2 link feature parameters and radio resource
feature parameters. The ALCAP of Iu interface initiates the user plane
transport bearer establishment process according to the AAL2 link feature
parameters (For the PS domain, this step does not exist).
The SRNC starts the radio link establishment process on Iub interface and
sends a RADIO LINK SETUP REQUEST message to the controlled NodeB to
request the NodeB to assign the specific radio link resources required for the
RRC connection.
Upon completing the resource preparations, NodeB sends a RADIO LINK
SETUP RESPONSE message to the RNC.
The RNC establishes the Iub interface user plane transport bearer through
ALCAP and completes the synchronization between the RNC and NodeB.
The SRNC sends a RADIO BEARER SETUP message of the RRC protocol to
the UE.
After executing radio bearer setup, the UE sends a RADIO BEARER SETUP
COMPLETE message to the SRNC.
Upon receiving the RADIO BEARER SETUP COMPLETE message, the SRNC
returns a RAB ASSIGNMENT RESPONSE message to the CN. The RAB
establishment flow is complete.
CCH-CCH

When a RRC connection is established on a CCH,

the RNC can continue to establish the assigned
RAB on a CCH according to the QoS parameters in
the RAB assignment message.
Description of the Signaling Flow:
The CN sends a RAB ASSIGNMENT REQUEST message of
the RANAP protocol to the UTRAN to initiate a RAB
establishment request.
Upon receiving the RAB establishment request, the SRNC
maps the QoS parameters of the RAB to AAL2 link feature
parameters and radio resource feature parameters. The
ALCAP of Iu interface initiates the user plane transport bearer
establishment process according to the AAL2 link feature
parameters (For the PS domain, this step does not exist).
The SRNC sends a RADIO BEARER SETUP message of the
RRC protocol to the UE.
After executing radio bearer setup, the UE sends a RADIO
BEARER SETUP COMPLETE message to the SRNC.
Upon receiving the RADIO BEARER SETUP COMPLETE
message, the SRNC returns a RAB ASSIGNMENT
RESPONSE message to the CN. The RAB establishment flow
is complete.
Content

Overview of the Basic Signaling Flow

Network Selection Flow
Handover Flow in the System
Call Service Flow
Service Release Flow
Service Release Flow
Service release flows fall into two types: high-layer release request initiated by the UE and
high-layer release request initiated by the CN. Regardless of release type, the ultimate
resource release process is initiated by the CN.
For a UE, such a scenario may exist: An RRC connection corresponds to multiple RABs
(For example, VP service and Web Browse service are performed at the same time), and
CS-domain and PS-domain correspond to a Iu signaling connection respectively. Service
release flow is roughly divided into several scenarios.
1. CS-domain service release
When the UE releases a CS-domain service:
If only one RAB is established in CS domain, the CN initiates an IU RELEASE COMMAND
message. Upon receiving this message, the RNC automatically releases the Iu signaling
connection and RAB. When the service release is complete, the SRNC determines whether
the RRC connection corresponds to any Iu signaling connection (PS domain). If not, the
RRC connection release process is initiated.
If multiple RABs are established in CS domain, the CN initiates the RAB release flow only
for the RAB that needs to be released, without releasing the Iu signaling connection.
2. PS-domain service release
When the UE releases a PS-domain service:
If only one RAB is established in PS domain, the CN first initiates the RAB release flow for
the RAB. When the release is complete, the CN sends an IU RELEASE COMMAND
message before releasing the Iu signaling connection on Iu-PS interface. When the service
release is complete, the SRNC determines whether the RRC connection corresponds to
any Iu signaling connection (CS domain). If not, the RRC connection release process is
initiated.
If multiple RABs are established in PS domain, the CN initiates the RAB release flow only
for the RAB that needs to be released, without releasing the Iu signaling connection.
Signaling Connection Release Request
The Iu connection release flow is generally initiated directly the CN
and can also be initiated by the CN at the request of the UTRAN. The
Iu connection release request flow is used by the UTRAN to request
the CN to initiate the Iu connection release process.
The SRNC sends an IU RELEASE REQUEST message to the CN
domain to initiate the Iu connection release request process. The
message indicates the reason for releasing the Iu connection. The CN
determines how to react to the Iu connection release request. For
example, if the CN decides to release the Iu connection, the CN
initiates the Iu connection release process.
Signaling Connection Release
The Iu connection release process is used by the CN to release an Iu
connection, releasing all the UTRAN resources related to a specific Iu
connection. The following shows the signaling flow.
The CN sends an IU RELEASE COMMAND message to the UTRAN to
initiate the signaling connection release process. The message contains
the reason for releasing the signaling connection, for example, "Successful
Relocation", "Normal Release", "Release due to UTRAN Generated
Reason", "Relocation Cancelled", and "No Remaining RAB". After sending
the message, the CN no longer sends any connection-oriented RNAP
message on this connection.
Upon receiving the message, the RNC clears the related resources in the
UTRAN. The RNC sends an IU RELEASE COMPLETE message to the
CN. The Iu connection release process is complete.
RAB Release Flow
For the RAB release flow, like the RAB establishment flow,
there are three scenarios:
DCH-DCH: Before the RAB is released, an RRC
connection uses the DCH. After the RAB is released, an
RRC connection uses the DCH;
CCH-CCH: Before the RAB is released, an RRC
connection uses the CCH. After the RAB is released, an
RRC connection uses the CCH;
DCH-CCH: Before the RAB is released, an RRC
connection uses the DCH. After the RAB is released, an
RRC connection uses the CCH;
Only the RAB release flow in the DCH-DCH scenario is
described. The RAB release flows in the other scenarios are
similar.
Similar to the RAB establishment flow, on a radio interface,
there are two scenarios for the DCH-DCH RAB release:
Synchronous reconfiguration of radio links

Asynchronous reconfiguration of radio links

RAB Release Flow
Description of the Signaling Flow:
The CN sends a RAB ASSIGNMENT REQUEST message (release) to start the
RAB release flow. The message indicates the ID of the RAB to be released.
The SRNC sends a RADIO LINK RECONFIGURATION PREPARE message to
the NodeB to request the NodeB to prepare for the releasing of the DCH
carrying the RAB.
The NodeB sends a RADIO LINK RECONFIGURATION READY message to
the SRNC to notify the SRNC that the release preparations are complete.
The SRNC sends a RADIO BEARER RELEASE message to the UE to start the
bearer release flow.
The SRNC sends a RADIO LINK RECONFIGURATION COMMIT message to
the NodeB.
The SRNC receives a RADIO BEARER RELEASE COMPLETE message from
the UE.
The RNC releases the data transport bearer on Iub interface.
The SRNC uses ALCAP. In case of AAL2 bearer, the SRNC sends an AAL2
release message to start releasing the Iu data transport bearer between the
SRNC and CN (This step is not needed for the PS domain).
The SRNC sends a RANAP RAB ASSIGNMENT RESPONSE to the CN. The
release flow is complete.
Note that, when the RNC user plane becomes abnormal, the RANAP sends a
RAB RELEASE REQUEST message to the CN to request the CN to release
the affected RAB.
Joint Release Flow of CS-Domain lu
Signaling Connection and RAB
If only one service is created in the CS domain,
when the service is released, the MSC first sends an
IU RELEASE COMMAND message to the RNC.
Upon receiving the message, the RNC releases the
Iu signaling connection and RAB on Iu-CS interface
at the same time.
Signaling Flow
Signaling Flow
The CN sends an IU RELEASE COMMAND message the SRNC.
The SRNC sends a RADIO LINK RECONFIGURATION PREPARE
message to the NodeB to request the NodeB to prepare for the
releasing of the DCH carrying the RAB.
The NodeB sends a RADIO LINK RECONFIGURATION READY
message to the SRNC to notify the SRNC that the release
preparations are complete.
The SRNC sends a RADIO BEARER RELEASE message to the UE
to start the bearer release flow.
The SRNC sends a RADIO LINK RECONFIGURATION COMMIT
message to the NodeB.
The SRNC receives a RADIO BEARER RELEASE COMPLETE
message from the UE.
The RNC releases the data transport bearer on Iub interface.
The SRNC uses ALCAP. In case of AAL2 bearer, the SRNC sends an
AAL2 release message to start releasing the Iu data transport bearer
between the SRNC and CN.
The SRNC sends an IU RELEASE COMPLETE message the CN.
RRC Connection Release Flow
After the RAB is released, the SRNC determines whether any Iu signaling
connection borne by the same RRC exists in the system. If all the Iu signaling
connections corresponding to the UE are released, the RRC connection is
released. To release an RRC connection is to release the signaling links
between the UE and UTRAN and all the radio bearers. Through the RRC
connection release flow, all the signaling connections related to the UE are
released on the radio interface.
Based on the resource consumption by the RRC connection, there are two
types of connection release: release of an RRC connection established on a
dedicated channel and release of an RRC connection established on a
common channel.
An RRC connection can be released only when it is in the CELL_DCH or
CELL_FACH state. If the current RRC connection is in the CELL_PCH or
URA_PCH state, the UTRAN initiates paging to transition the UE state to
CELL_FACH before releasing the RRC connection.
Based on actual conditions, the RNC sends an RRC CONNECTION RELEASE
message in UM RLC mode on the downlink DCCH or CCCH.
If the DCCH is available during the RRC connection release, the UTRAN
sends an RRC CONNECTION RELEASE message through the downlink
DCCH. Otherwise, the UTRAN sends an RRC CONNECTION RELEASE
message through the downlink CCCH.
Releasing an RRC Connection Established on
a Dedicated Channel
Description of the Signaling Flow:

The SRNC sends an RRC CONNECTION RELEASE message

to the UE through the DCCH. The SRNC may sends the
message for several times to ensure that the UE receives the
message.
The UE returns an RRC CONNECTION RELEASE
COMPLETE message to the SRNC.
The SRNC sends a RADIO LINK DELETION REQUEST
message to NodeB to delete the radio link resources in NodeB.
When the resources in the NodeB are deleted, NodeB returns
a RADIO LINK DELETION RESPONSE message to the SRNC.
The RNC uses ALCAP to initiate the releasing of the user
plane transport bearer on Iub interface. The RRC connection
release flow is complete.
Releasing an RRC Connection Established on
a Common Channel
The SRNC sends an RRC CONNECTION RELEASE message through the
CCCH to the UE to initiate the RRC connection release flow, and the UE
releases the resources.
When an RRC connection established on the common channel is released, no
RRC CONNECTION RELEASE COMPLETE message is sent. In addition,
because cell common resources are used, only the UE needs to be released
directly and there is no need to release NodeB resources and data transport
bearer.
Description
The UTRAN may send the RRC CONNECTION RELEASE message for
several times to ensure that the UE receives the message correctly. The RRC
SN values of these messages are the same. The number of message
retransmissions and transmission interval are controlled by the network.