Development Branch

France Telecom R & D

Controlled Diffusion
Ref.:
RADIUM Project FTR&D/DMR/IIM/03.0457/AD
Version : V1.0
Date: May 2003

Delays and timers of UTRAN signalling procedures

Authors:
Sbastien Baret, Anne Daviaud - FTR&D/DMR/IIM
Borja Jimnez Aldama, Gwenalle Georgeault - FTR&D/DMR/RMO

Editor:
Anne Daviaud - FTR&D/DMR/IIM

SYNTHESIS:

RRC, NBAP and RANAP procedures are involved in a number of RRM issues such as
mobility management, admission control, load control and QoS management. Delays in the
execution of those signalling procedures will have a significant impact on the network
behaviour. Therefore, it is crucial to evaluate the duration of the most important procedures
on an experimental platform. The impact of delays and timer on the signalling procedures is
the ultimate goal of the work initiated in this study and planned in two phases:
- This first study aims at defining the delays and identifying the main timers and
parameters. This work is preparatory and remains intermediate
- A second study will measure the real delays based on traces from experimental platform.
This second document will achieve the work and will provide final results and
conclusions.

This document firstly defines the different procedures of interest. They have been grouped
into three domains:
- mobility management procedures;
- connection management procedures;
- reconfiguration procedures.
In a second part, the study describes and analyses the different parameters. For each of
these three groups, involved RRC, NBAP and RANAP procedures and associated timers are
described. Then, the coordination of procedures of different protocols is exposed. This is of
particular interest since timers from various protocols may reveal to be interdependent. Next,
delay indicators are defined for the various procedures or sequences of procedures.
Finally, causes and consequences of delays in signalling procedures are analysed.
Delays and timers of UTRAN signalling procedures 2/43

Based on this preliminary work, the second phase of the study can start. It will analyse traces
from experimental platforms. This will be done for Alcatel release R2S1.5 and Nokia release
RAN1.5.2. A second document will be produced then to present results of these analyses,
and to suggest some default values for associated timers.

This document shows that delays in signalling procedures may be due to several factors (UE
delays, Network delays, Transmission delays on Air interface). Moreover, radio congestion or
general system dysfunction may have an impact on the total duration of procedures. In
another part, this document explains the impact of long delays for the execution of signalling
procedures:
On mobility functions: too long delays in UTRAN mobility functions (particularly, in
Active Set Update procedure) may increase the call drop rate.
On connection management functions: the time a user has to wait for the
establishment of a communication has a direct impact on the perceived QoS.
On reconfiguration functions: delays in those procedures, especially for RRC and
NBAP protocols, have a direct impact on RRM algorithms for resource allocation and
resource sharing.

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 3/43

Approval:
Name Y. Boursier M. Griguer
Date
Visa

Document history:
Date Version Modification
03/2003 V1.0 Creation

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 4/43

DIFFUSION

Distribution list:

Orange
E-mail distribution
Messrs. LASPOUGEAS P. OF/DTRS Messrs. BONNIN F. OF/DTRS
GUERIN N. OF/DTRS RIVOIRE A. OF/DTRS
MARZOUG M. OF/DTRS MARY A. OF/DTRS
MANZANO P. OF/DTRS

FTR&D
E-mail distribution
Project List th_radium FTR&D/DMR
Messrs FOUQUET A. FTR&D/DMR
BERNARD A. FTR&D/DMR
CHARLES J.-P. FTR&D/DMR

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 5/43

Content

1 Introduction 6

2 General view of procedure delays 7

2.1 Why the procedure delay can change? 7
2.2 Who analyses procedure delays? 8
3 Mobility procedures 10
3.1 Main procedures for mobility management 10
3.2 Sequence of mobility procedures 19
3.3 Definition of delay indicators for mobility procedures 20
3.4 Trace analysis 21
4 Connection management procedures 22
4.1 Main procedures for connection management 22
4.2 Sequence of connection management procedures 28
4.3 Definition of delay indicators for connection management procedures 30
4.4 Trace analysis 31
5 Reconfiguration procedures 32
5.1 Main procedures for reconfiguration 32
5.2 Sequence of reconfiguration procedures 37
5.3 Definition of delay indicators for reconfiguration procedures 38
5.4 Trace analysis 39
6 Synthesis 40
6.1 Granularity of delay indicators 40
6.2 Proposed values for timers 40
6.3 Main measured procedure delays 41
7 Conclusion 42

8 Reference 43

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 6/43

1 Introduction

RRC, NBAP and RANAP procedures are involved in a number of RRM issues such as mobility management,
admission control, load control and QoS management. Thus, delays in the execution of those signalling
procedures will have a significant impact on the network behaviour. Therefore, it is crucial to evaluate the
duration of the most important procedures, on an experimental platform.

For that purpose, this document is aimed at presenting the major signalling procedures for RRC, NBAP and
RANAP protocols. Procedures have been grouped into three domains:
mobility management procedures;
connection management procedures;
reconfiguration procedures.

For each of these three groups, first the involved procedures from each protocol are described, together with the
associated timers. Then, the relations between procedures of different protocols are highlighted, through
sequence diagrams. This is of particular interest since timers from various protocols may reveal to be dependent
between each others. Next, delay indicators are defined for the various procedures or sequences of procedures.

These delay indicators will be used to analyse traces obtained on Nokia and Alcatel experimental platforms.
Results of these analyses will be presented in a next version of this document, due to September, 2003.

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 7/43

2 General view of procedure delays

2.1 Why the procedure delay can change?

First of all, the duration of each procedure may be easily calculated according to the following
formula:

Procedure duration = Time of end Time of beginning

With:
Time of beginning = time of recording of the message corresponding to the beginning of the
procedure.
Time of end = time of recording of the message corresponding to the end of the procedure.

The duration of procedures can reveal any problem of load, of quality of radio link (due to
retransmission block rate) There are several components in procedure delay, which can globally be
grouped as follows:
The "UE delay" results from internal UE processes. For example, "UE delay" is the time
between downlink RRC message "Active Set Update" and uplink message "Active Set Update
Complete".
The "Network delay" results from internal access network processing. For example,
"Network delay" is the time between uplink RRC message "Measurement Report" and
downlink message "Active Set Update". This delay should be used carefully, because it can be
caused by CPU overload problems. A CPU overload can be due to, for example, a resource
allocation problem.
The "UE/Network signalling delay" results from communication between the radio access
network and the UE. This delay must be taken into account because it depends of radio link
quality (retransmission block rate).
Each indicator given in this document can be split up into these three groups (see 3.3, 4.3, 5.3).

Example:

Network UE
Measurement Report

Network Delay Active Set Update

UE/Network Signalling Delay

UE Delay
Active Set Update Complete
UE/Network Signalling Delay

Network Delay
Measurement Control
UE/Network Signalling Delay

Figure 2-1: various delays in UTRAN procedures

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 8/43

For these three groups, each duration raise can have different causes:
"UE delay" =>
o System cause
"Network delay" =>
o Core Network cause
o CPU load cause
o System cause
"UE/Network signalling delay" =>
o Radio link quality cause

In this study the investigation is done at RNC level. That means the observation is done with an OMC
or with an Iub analyser tool. It is possible to detect the network delay but it is not possible to separate
the UE delay and the delay generated by the radio transmission.

NB: Requirements on global procedure delays in UE are defined in TS25.133. However, they cannot
be compared to delays measured from experimental networks, since these delays are taken on the
network side, and since it is not possible to separate the UE delay from transmission delays.

2.2 How to analyse procedure delay?

A UTRAN procedure is generally composed of RRC and NBAP messages. For example, for dedicated
radio link creation (DCH), the RRC protocol performs the radio link creation at the UE level and
NBAP protocol creates the Iub link and performs the radio link creation at the Node B level. Thus, if
we are focusing on radio observations, the most important thing is to do an analysis with RRC
messages. However, as described below, in order to have a higher degree of accuracy, it is sometimes
necessary to make a study on NBAP level.

For a delay study, one tries to know how much time a procedure takes to be carried out. A procedure
is completely carried out when the UE is able to maintain a communication (power control, ) and
to execute radio measurements in order to do a handover.

The procedure delay is related to several factors, which are:

Size of the messages
UE and RNC reaction time
The information transfer time, which depends of the size of the message, of the radio load and
the quality of the radio link.

Hereafter is described a method of procedure delay observation. This observation is done with several
levels of detail:

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 9/43

UE NodeB RNC

Beginning of the procedure RRC

NBAP Delay 4

NBAP Delay 1 Delay 2 Delay 5

Delay 6
RRC
Delay 3
RRC

End of the procedure

Figure 2-2: Example of UTRAN procedure

This is a UMTS " traditional " procedure. It is made up of a UE request that triggers a RNC reaction.
The RNC makes on one hand an action at the Node B level (NBAP messages) and on the other hand at
the UE level (RRC messages).

General analysis
For a general analysis of the procedure delay it is necessary to look at the "delay 1", which represents
the procedure duration. However in some cases it is necessary to have a higher degree of accuracy, for
example, to know which part of the procedure takes most of the time For that, it is possible to make
a detailed study.

Detailed study
For a detailed study, it is necessary to look at the various delays that compose the procedure and this
with RRC messages only. One thus looks at the "delays 2 and 3". With this, it is possible to know if a
significant delay comes from the transfer time and UE reaction (which it is not possible to differentiate
with RNC or Iub analyses) or from a problem of RNC reaction time.
It is this level of details which is used for this study. It is possible to have a greater level of precision
by doing a very detailed study.

Very detailed study

For a very detailed study, it is necessary to look at the times between each message composing the
procedure. This type of study is used only in some cases to analyse very particular cases. This type of
study is not detailed in this document. The part on the procedures definition makes it possible to
do the study with this detail level.

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 10/43

3 Mobility procedures

3.1 Main procedures for mobility management

3.1.1 RRC procedures

3.1.1.1 Cell and URA update procedures

The general Cell or URA update procedure starts with a CELL UPDATE or URA UPDATE message
sent by UE on CCCH. In case of success of the procedure in UTRAN, the RNC sends back to the UE
a CELL UPDATE CONFIRM or URA UPDATE CONFIRM message, on CCCH or DCCH. Then,
depending on the content of the message, the UE may send a response message.
In case of failure, the RRC connection of the UE is released: the RNC answers the UE back by a RRC
CONNECTION RELEASE message on CCCH.

UE UTRAN

UE UTRAN
CELL UPDATE
CELL UPDATE
CELL UPDATE CONFIRM
CELL UPDATE CONFIRM
UTRAN MOBILITY INFORMATION
CONFIRM

Cell update procedure with update of UTRAN

Cell Update procedure, basic flow
mobility information
UE UTRAN UE UTRAN

CELL UPDATE CELL UPDATE

CELL UPDATE CONFIRM CELL UPDATE CONFIRM

PHYSICAL CHANNEL RECONFIGURATION COMPLETE TRANSPORT CHANNEL RECONFIGURATION

COMPLETE

Cell update procedure with physical channel Cell update procedure with transport channel
reconfiguration reconfiguration
UE UTRAN UE UTRAN

CELL UPDATE CELL UPDATE

CELL UPDATE CONFIRM CELL UPDATE CONFIRM

RADIO BEARER RELEASE COMPLETE RADIO BEARER

RECONFIGURATION COMPLETE

Cell update procedure with radio bearer

Cell update procedure with radio bearer release
reconfiguration

UE UTRAN

CELL UPDATE

RRC CONNECTION RELEASE

Cell update procedure, failure case

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 11/43

UE UTRAN
UE UTRAN
URA UPDATE
URA UPDATE
URA UPDATE CONFIRM
URA UPDATE CONFIRM
UTRAN MOBILITY INFORMATION
CONFIRM

URA update procedure with update of UTRAN

URA Update procedure, basic flow
mobility information

UE UTRAN

URA UPDATE

RRC CONNECTION RELEASE

URA update procedure, failure case

The URA update and cell update procedures serve several main purposes:
- to notify UTRAN after re-entering service area in CELL_PCH state;
- to notify UTRAN of an RLC unrecoverable error on an AM RLC entity;
- to be used as a supervision mechanism in the CELL_FACH, CELL_PCH or URA_PCH
state by means of periodical update (controlled by timer T305).

In addition, the URA update procedure also serves the following purpose:
- to retrieve a new URA identity after cell re-selection to a cell not belonging to the current
URA assigned to the UE in URA_PCH state.

In addition, the cell update procedure also serves the following purposes:
- to update UTRAN with the current cell the UE is camping on after cell reselection;
- to act on a radio link failure in the CELL_DCH state;
- to act on the transmission failure of the UE CAPABILITY INFORMATION message;
- when triggered in the URA_PCH or CELL_PCH state, to notify UTRAN of a transition to
the CELL_FACH state due to the reception of UTRAN originated paging or due to a
request to transmit uplink data.

The cell update procedure may include:

- a re-establish of AM RLC entities;
- a radio bearer release, radio bearer reconfiguration, transport channel reconfiguration or
physical channel reconfiguration.

A UE shall initiate the cell update procedure in the following cases:

- Uplink data transmission, if the UE is in URA_PCH or CELL_PCH state and if the UE
has uplink RLC data PDU or uplink RLC control PDU on RB1 or upwards to transmit.
- Paging response, if the UE in URA_PCH or CELL_PCH state receives a PAGING TYPE
1 message fulfilling the conditions for initiating a cell update procedure.
- Radio link failure, if the UE is in CELL_DCH state and the criteria for radio link failure is
met.
- Re-entering service area, if the UE is in CELL_FACH or CELL_PCH state and if the UE
has been out of service area and re-enters service area before expiration of timer T307 or
T317.
- RLC unrecoverable error, if the UE detects RLC unrecoverable error in an AM RLC
entity.
- Cell reselection, if the UE is in CELL_FACH or CELL_PCH state and the UE performs
cell re-selection or if the UE is in CELL_FACH state and the variable C_RNTI is empty.

This document is edited by France Telecom R&D.

 Delays and timers of UTRAN signalling procedures 12/43

- Periodical cell update, if the UE is in CELL_FACH or CELL_PCH state and if the timer
T305 expires and if periodic updating has been configured by T305 in the IE "UE Timers
and constants in connected mode" set to any other value than "infinity".

A UE in URA_PCH state shall initiate the URA update procedure in the following cases:
- URA reselection, if the UE detects that the current URA assigned to the UE, stored in the
variable URA_IDENTITY, is not present in the list of URA identities in system
information block type 2, or if the list of URA identities in SIB2 is empty, or if the SIB2
can not be found.
- Periodic URA update, if the timer T305 expires while the UE is in the service area and if
periodic updating has been configured by T305 in the IE "UE Timers and constants in
connected mode" set to any other value than "infinity".

Some RRC timers are associated to Cell and URA Update procedures. They are summarized in the
following table:

Timer Triggering event Stopping event Action at expiry Range Default

value
T302 Transmission of CELL Reception of CELL Retransmit CELL 100, 200... 2000 4000 ms
UPDATE/URA UPDATE UPDATE UPDATE/URA UPDATE if by step of 200,
CONFIRM/URA V302 N302, else, go to Idle 3000, 4000,
UPDATE CONFIRM mode. 6000, 8000
T305 Entering CELL_FACH or Entering another state. Transmit CELL UPDATE if 5, 10, 30, 60, 30
URA_PCH or CELL_PCH T307 is not activated and the 120, 360, 720, minutes.
state. Reception of CELL UE detects "in service area". infinity Infinity
UDPATE CONFIRM/URA Otherwise, if T307 is not = no
UPDATE CONFIRM. active, start T307. update
T307 When the timer T305 has When the UE detects Transit to idle mode. 5, 10, 15, 20, 30 s
expired and the UE detects "in service area". 30, 40, 50
"out of service area".
T314 When the criteria for radio When the Cell Update If T302 is running, wait for 0, 2, 4, 6, 8, 12, 12 s
link failure are fulfilled. procedure has been response message; else, if 16, 20
The timer is started if radio completed. T315 is running, release RB
bearer(s) that are associated associated with RABs for
with T314 exist or if only which T314 is specified; else,
RRC connection exists. transit to idle mode.
T315 When the criteria for radio When the Cell Update If T302 is running, wait for 0,10, 30, 60, 180 s
link failure are fulfilled. procedure has been response message; else, if 180, 600, 1200,
The timer is started only if completed. T314 is running, release RB 1800
radio bearer(s) that are associated with RABs for
associated with T315 exist. which T315 is specified; else,
transit to idle mode.
T316 When the UE detects "out When the UE detects Initiate cell update procedure 0, 10, 20, 30, 30 s
of service area" in "in service area". if in service area is detected. 40, 50, infinity
URA_PCH or CELL_PCH Otherwise start timer T317,
state. transit to CELL_FACH state
and initiate cell update
procedure when the UE
detects "in service area".
T3171 When the T316 expires or When the UE detects Transit to idle mode. 0,10, 30, 60, 180 s
when in CELL_FACH state, "in service area". 180, 600, 1200,
the UE detects "out of 1800
service area".

Table 3-1: timers involved in Cell and URA Update RRC procedures

1
3GPP specs should be changed soon, so that the mobile does not go autonomously to idle mode without
informing the network after expiry of T317, what causes de-synchronisation of RRC state between UE and
UTRAN. This will be done by setting the value of T317 to +infinity. See [10] for a detailed description of this
issue.

This document is edited by France Telecom R&D.

 Delays and timers of UTRAN signalling procedures 13/43

The following RRC counters and constants are associated with some of the above-mentioned timers:

Counter Reset Incremented Action when reaching max value

V302 When initiating the procedure Upon expiry of T302 When V302 > N302 the UE enters
Cell update or URA update idle mode.

Constant Usage Range Default value

N302 Maximum number of retransmissions of the 0..7 3
CELL UPDATE / URA UPDATE message

The role of each timer with the Cell and URA Update procedures is described by the following
figures:
X_PCH state Start T317
In Service enter Cell_FACH state
Area

S<0

search for suitable cell Out of service Area (No

(UTRAN/GSM) Suitable cell found)
During 12s
T316 ends

Out of service Area detected

Start T316 In service Area
Cell Selection (Suitable cell found)
T305 ends
suitable cell found

Cell Update
Stop T316
perform Cell/URA update if End Of T305
necessary (New Cell/URA)

X_PCH state
X_PCH state In Service Area
In Service Area

Figure 3-1: application of T316 and T317 timers for a UE in X_PCH state [11]

CELL_FACH state search for suitable cell

In Service Area (UTRAN/GSM)
S<0 During 4s

No suitable
Cell found

T317 ends
Go to Idle mode
Out of service Area detected
Start T317 search for suitable cell
Perform Cell update if necessary
Cell selection
(New RA/LA)
From Out of
service Area in T305 Ends
X_PCH state suitable Cell found
(UTRAN/GSM) ...

Stop T317 End Of T305

Perform Cell Update

CELL_FACH state
In Service Area

Figure 3-2: application of T316 and T317 timers for a UE in CELL_FACH state [11]

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 14/43

T307 ends
Go to Idle mode
End Of T305 Start T307 search for suitable cell
search for suitable cell

In service Area
detected

Transmit Cell/URA update

Figure 3-3: process when T305 ends in out of service area [11]

On top of those standard timers, some manufacturer-dependent timers may be involved in mobility
procedures. For instance, timers and counters are defined to manage transitions between
CELL_FACH, CELL_PCH and URA_PCH states, or between RRC_Connected and RRC_Idle modes.
These timers and counters are fully described in documents [4] and [5].

3.1.1.2 Active Set Update procedure

This procedure is initiated when UTRAN orders a UE in CELL_DCH state, to add and/or remove a
Radio Link of the active set of the connection. It consists of the following messages:
ACTIVE SET UPDATE: this message is sent by UTRAN on downlink DCCH using AM or
UM RLC. It specifies the RL to be added or removed.
ACTIVE SET UPDATE COMPLETE: response message sent by UE (on the uplink DCCH
using AM RLC) in case of success of the procedure.
ACTIVE SET UPDATE FAILURE: response message sent by UE (on the uplink DCCH
using AM RLC) in case of failure of the procedure.

UE UTRAN UE UTRAN

ACTIVE SET UPDATE ACTIVE SET UPDATE

ACTIVE SET UPDATE COMPLETE ACTIVE SET UPDATE FAILURE

Active Set Update procedure, successful case Active Set Update procedure, failure case

UTRAN decides to initiate an Active Set Update procedure in reaction to measurement reports from
the UE, reported through MEASUREMENT REPORT messages. After a successful Active Set Update
procedure, the UTRAN resets the measurement reporting configuration by sending to the UE a
MEASUREMENT CONTROL message.

No RRC timer is associated with these procedures.

3.1.2 NBAP procedures

Except for the Node B and Cell management, the NBAP protocol is used to manage dedicated radio
links and dedicated ATM Iub links. For that management, NBAP procedures are limited and exist only
for UEs in CELL_DCH state.

3.1.2.1 Cell and URA update procedures

For this mobility, the UE is not in CELL_DCH state so there is no dedicated link. There is no NBAP
procedure for this kind of mobility.

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 15/43

3.1.2.2 Active Set Update procedure

For this mobility, the mobile is always in CELL_DCH state, so there are NBAP procedures. There are
three kinds of Active Set Update procedures following the event that has generated the mobility. The
events are:
Event e1a: This event is used, by the UE, to add a cell in its Active Set.
If the recombining of the new cell is done by the RNC, the mobility is a Soft Handover. The RNC has
to create a new radio link and a new ATM Iub link. The procedures are:

NodeB UTRAN NodeB UTRAN

RADIO LINK SETUP REQUEST RADIO LINK SETUP REQUEST

RADIO LINK SETUP RESPONSE RADIO LINK SETUP FAILURE

Radio Link Setup procedure, successful case Radio Link Setup procedure, failure case

If the recombining of the new cell is done by the Node B, the mobility is a Softer Handover. The
RNC has to create a new radio link but doesn't have to create a new ATM Iub link. The procedures
are:

NodeB UTRAN NodeB UTRAN

RADIO LINK ADDITION REQUEST RADIO LINK ADDITION REQUEST

RADIO LINK ADDITION RESPONSE RADIO LINK ADDITION FAILURE

Radio Link Addition procedure, successful case Radio Link Addition procedure, failure case

Event e1b: This event is used, by the mobile, to remove a cell of its Active Set. For this event,
NBAP procedures are the same for soft and softer handover:

NodeB UTRAN

RADIO LINK DELETION REQUEST

RADIO LINK DELETION RESPONSE

Radio Link Deletion procedure

Event e1c: This event is used, by the mobile, to add and to remove n cells of its Active Set at
the same time. For that event, procedures are the same than for event e1a and event e1b.

3.1.3 RANAP procedures

3.1.3.1 SRNS Relocation

The general SRNS relocation procedure is made up of the following RANAP procedures:
Relocation Preparation procedure:
o Relocation Required message: the Source RNC indicates to the CN that SRNS
relocation is going to be performed.
o Relocation Command message: the CN confirms to the Source RNC that resources
have been allocated in the target RNS.
o Relocation Preparation Failure message: the CN indicates to the Source RNC that
resource allocation has failed.

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 16/43

Source RNC CN

RANAP: RELOCATION
REQUIRED

TRELOCprep

RANAP: RELOCATION
COMMAND

Relocation Resources Allocation procedure:

o Relocation Request message: the CN requests the Target RNC to allocate necessary
resources for the relocation procedure.
o Relocation Request Acknowledge message: the Target RNC informs the CN about the
final resource allocation for the requested relocation.
o Relocation Failure message: the Target RNC informs the CN of the failure of the
resource allocation.

UE Node B Target RNC CN

RANAP: RELOCATION
REQUEST

Allocation of the
requested resources RANAP: RELOCATION REQUEST TRELOCalloc
ACKNOWLEDGE

Relocation Detect procedure:

o Relocation Detect message: The Target RNC notifies the CN that the UE has been
detected in the Target RNS.

UE Node B Target RNC CN

MS detected by the target RNC RANAP: RELOCATION

DETECT

Relocation Complete procedure:

o Relocation Complete message: The Target RNC informs the CN about the completion
of the relocation procedure.

UE Node B Target RNC CN

RB reconfiguration complete in
UE and target RNS RANAP: RELOCATION
COMPLETE

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 17/43

Relocation cancel procedure:

o Relocation Cancel message: the Source RNC indicates to the CN that SRNS
relocation is going to be cancelled.
o Relocation Cancel Acknowledge message: the CN confirms to the Source RNC that
SRNS Relocation is cancelled.

Source RNC CN

RANAP: RELOCATION
CANCEL

RANAP: RELOCATION
CANCEL ACKNOWLEDGE

Iu Release procedure:
o Iu Release Command message: the CN indicates to the RNC that the Iu connection
must be removed.
o Iu Release Complete message: the RNC confirms to the CN that Iu connection has
been removed.

Source RNC CN

RANAP: Iu RELEASE
COMMAND

RANAP: Iu RELEASE
COMPLETE

Iu Release Request procedure:

o Iu Release Request message: the RNC requests the CN to release the Iu connection due to
some UTRAN internal reason (e.g. TRELOCoverall expiry). If the CN accepts to remove the Iu
connection, the Iu Release procedure will be triggered.

Source RNC CN

RANAP: Iu RELEASE
REQUEST

The RANAP timers associated to the SRNS relocation procedure are the following ones:

o TRELOCprep specifies the maximum time for performing the Relocation Preparation procedure.
This timer is located in the source RNC. The source RNC starts this timer when it sends the
Relocation Required message to the CN (Relocation Preparation procedure is triggered). The
source RNC stops this timer when it receives the Relocation Command message from the CN. If
this timer expires before receiving this message, the Source RNC shall cancel the Relocation
Preparation procedure by means of the Relocation Cancel procedure, with cause "TRELOCprep
expiry".

o TRELOCalloc specifies the maximum time for the Relocation Resources Allocation procedure. This
timer is located in the CN. It is activated when the CN sends the Relocation Request message to
the Target RNC and it is stopped when the CN receives the Relocation Request Acknowledge
message from the Target RNC. If the timer expires before receiving this acknowledge message,

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 18/43

the CN shall cancel the Relocation Resource Allocation procedure and shall initiate the Iu
Release procedure in order to remove the Iu connection eventually established between the CN
and the Target RNC.

o TRELOCoverall specifies the maximum time in the Source RNC to complete the whole Relocation
Execution Completion procedure. This timer is located in the source RNC. This timer is
activated when the Source RNC receives the Relocation Command message from the CN and it
is stopped when the Source RNC receives the Iu Release Command from the CN. If the timer
expires before receiving the Iu Release message, the Source RNC shall initiate the Iu Release
Request procedure towards the CN with the cause "TRELOCoverall expiry".

o TDATAfwd specifies the maximum time for data forwarding at the source RNC during the SRNS.
This timer is also located in the Source RNC and is only available for the RAB established in
the PS domain. It is activated when the Source RNC receives the Relocation Command message
from the CN. When this timer expires, the Iu connection is removed and the Source RNC sends
the Iu Release Complete message towards the CN.

o TRELOCcomplete specifies the maximum time for performing the Relocation Execution Completion
from the CN side. This timer is located in the CN. It is activated when the CN sends the
Relocation Command to the Source RNC and it is stopped when the CN receives the Relocation
Complete message from the Target RNC. If the timer expires, the CN should initiate release of
Iu connection towards the Source and the Target RNC by means of the Iu Release procedure
with cause " TRELOCcomplete expiry".

Hereafter we show the whole SRNS relocation procedure with the different RANAP procedures and
their associated timers:

UE Node B Target RNC Source RNC CN

RANAP: RELOCATION
REQUIRED

RANAP: RELOCATION REQUEST

Allocation of the TRELOCprep TRELOCalloc

requested resources RANAP: RELOCATION REQUEST ACKNOWLEDGE

RANAP: RELOCATION
COMMAND

TRELOCoverall
TDATA fwd TRELOCcomplete
MS detected by the target RNC (PS domain)

RANAP: RELOCATION DETECT

RB reconfiguration complete in
UE and target RNS RANAP: RELOCATION COMPLETE

RANAP: Iu RELEASE
COMMAND

RANAP: Iu RELEASE
COMPLETE

NAS mobility procedures are encapsulated in NAS signalling transfer RANAP messages, such as
RANAP UE Initial Message or RANAP Direct Transfer messages. These NAS mobility procedures
have also several associated timers, but these ones are out of the scope of this document.
Only for example, we can provide hereafter some NAS mobility procedures with their associated
timers located in the network side:

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 19/43

- Routing Area Update procedure: T3350.

- Location Updating procedure: T3250 and T3255.

3.2 Sequence of mobility procedures

Here is presented the chain of RRC and NBAP procedures involved in mobility functions. RANAP
procedures are not included, since their sequence is presented just above. Moreover, SRNS Relocation
and Active Set Update procedures are not necessarily linked: both procedures can occur independently
of the other.

Soft and Softer Handover

UE NodeB RNC
Measurement Report
RRC RRC

RADIO LINK SETUP REQUEST

Soft Handover NBAP NBAP
only RADIO LINK SETUP RESPONSE
NBAP NBAP
Add link only
RADIO LINK ADDITION REQUEST
Softer NBAP NBAP
Handover only RADIO LINK ADDITION RESPONSE
NBAP NBAP

Active Set Update

RRC RRC
Active Set Update Complete
RRC RRC

Measurement Control
RRC RRC

RADIO LINK DELETION REQUEST

NBAP NBAP
Delete link only
RADIO LINK DELETION RESPONSE
NBAP NBAP

For soft and softer-handover, in case of link addition, there is one NBAP procedure between the
"measurement Report" RRC message and the "Active Set Update message. The NBAP procedure is
used in order to configure the new Iub and radio link. In case of deletion of link, there is a procedure
NBAP after the RRC procedure in order to delete the Iub and the radio links.

For URA and Cell update, there is no NBAP procedure because there are no dedicated Iub and radio
link. So there are only RRC procedures.

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 20/43

3.3 Definition of delay indicators for mobility procedures

Mobility procedure must be performed quickly in order to avoid call drop. If the mobility procedure is
too long, the UE can lose its radio link due too pilot pollution. An other effect of a too long mobility
procedure relates to the coverage of each cell because then, the mobile can not communicate with the
best cell and generates interferences.

For these delay indicators, it can be useful to analyse their value depending on the moment where the
procedure is done. For example, the delay for a soft handover is not the same if the mobile is in
establishment step or if the mobile has done its establishment before.

Indicator Name Involved RRC Messages Events Note

URA Update
Success of URA Update URA Update Beginning
delay URA Update Confirm End
Failure of URA Update URA Update Beginning
delay RRC Connection Release End
Cell Update
Success of Cell Update Cell Update Beginning
delay Cell Update Confirm End
Note1
Failure of Cell Update Cell Update Beginning
delay RRC Connection Release End
Soft Handover
Success of Soft Handover Measurement Report Beginning
delay Measurement Control End
Failure of Soft Handover Measurement Report Beginning Note 2
delay Active Set Update Failure End Note 3
Measurement Report Beginning
RNC Reaction delay
Active Set Update End
Hard Handover
Physical Channel Reconfiguration Beginning
Success of Hard Handover
Physical Channel Reconfiguration End
delay
Complete
Physical Channel Reconfiguration Beginning
Failure of Hard Handover
Physical Channel Reconfiguration End
delay
Failure

Note 1: For this delay, it is important to analyse only Cell Update messages with Cell update cause
"UL Data Transmission" or "Paging Response".

Note 2: For these delay indicators it could be necessary to distinguish the different kind of handover.
For example soft and softer handover or add and remove radio link.

Note 3: For this delay indicator it is important to count only the first "Measurement Report" message,
because this message can be repeated after the first message to the Handover command.

NB: TS25.133 specification defines requirements on procedure delays on mobile side, for Active Set
Update and Hard Handover procedures, and for cell reselection processes in CELL_FACH,
CELL_PCH and URA_PCH states. However, it is not possible to check the compliance to these
requirements, since experimental traces that will be studied are measured on the network side.

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 21/43

SRNS RELOCATION procedure

Indicator Name Involved RANAP Messages Events Note
Relocation Preparation
Success of Relocation Relocation Required Beginning Note 1
Preparation delay Relocation Command End
Failure of Relocation Relocation Required Beginning
Preparation delay Relocation Preparation Failure End
Relocation Resource Allocation
Success of Relocation Relocation Request Beginning Note 1
Resource Allocation delay Relocation Request Acknowledge End
Failure of Relocation Relocation Request Beginning
Resource Allocation delay Relocation Failure End
Relocation Complete
Success of Relocation Relocation Command Beginning Note 1
Complete delay Relocation Complete End
Relocation Command Beginning
Failure of Relocation
Iu Release (towards source RNC & End
Complete delay
Target RNC)
Iu Release
Relocation Command Beginning
Success of Iu Release delay
Iu Release Command End
Relocation Command Beginning
Failure of Iu Release delay
Iu Release Request End

Note 1: This delay depends on the NBAP and RRC procedures involved in the radio resources
allocation in the target RNS.

3.4 Trace analysis

TO BE COMPLETED IN NEXT VERSION OF THE DOCUMENT

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 22/43

4 Connection management procedures

4.1 Main procedures for connection management

4.1.1 RRC procedures

4.1.1.1 RRC Connection management procedures

RRC connection establishment

UE UTRAN

RRC CONNECTION REQUEST

UE UTRAN

RRC CONNECTION SETUP RRC CONNECTION REQUEST

RRC CONNECTION REJECT

RRC CONNECTION SETUP COMPLETE

The purpose of this procedure is to establish an RRC connection.

The UE shall initiate the procedure when upper layers in the UE request the establishment of a
signalling connection and the UE is in idle mode (no RRC connection exists). It starts by submitting
an RRC CONNECTION REQUEST message for transmission on the uplink CCCH. Upon receiving
an RRC CONNECTION REQUEST message, UTRAN should either submit an RRC CONNECTION
SETUP message to the lower layers for transmission on the downlink CCCH, or submit an RRC
CONNECTION REJECT message on the downlink CCCH. In the RRC CONNECTION REJECT
message, the UTRAN may direct the UE to another UTRA carrier or to another system. After the RRC
CONNECTION REJECT message has been sent, all context information for the UE may be deleted in
UTRAN.
At reception of RRC CONNECTION SETUP message, the UE shall submit an RRC CONNECTION
SETUP COMPLETE message to the lower layers on the uplink DCCH which description was
provided in the UTRAN response message.

The first message in this procedure is sent in RLC Transparent Mode. It is controlled by a set of timers
and counters. T300 timer is initialised when RRC CONNECTION REQUEST message is sent by the
UE. If no response message has been received before expiry of T300, this message is repeated a
maximum of N300 times. V300 counts the effective number of RRC CONNECTION REQUEST
messages that have been sent.
Other messages are sent in UM RLC on uplink and AM RLC on downlink.

RRC connection release

UE UTRAN

RRC CONNECTION RELEASE

RRC CONNECTION RELEASE

COMPLETE

This document is edited by France Telecom R&D.

 Delays and timers of UTRAN signalling procedures 23/43

The purpose of this procedure is to release the RRC connection including all radio bearers and all
signalling radio bearers between the UE and the UTRAN. By doing so, all established signalling
connections will be released.

When the UE is in CELL_DCH or CELL_FACH state, the UTRAN may initiate at anytime an RRC
connection release by transmitting an RRC CONNECTION RELEASE message using UM RLC.
When UTRAN transmits an RRC CONNECTION RELEASE message the downlink DCCH should be
used, if available. If the downlink DCCH is not available in UTRAN and the UE is in CELL_FACH
state, the downlink CCCH may be used. This occurs particularly when this procedure follows on from
a Cell Update or URA Update procedure.
UTRAN may transmit several RRC CONNECTION RELEASE messages to increase the probability
of proper reception of the message by the UE. The number of repeated messages and the interval
between the messages is a network option.
The UE shall receive and act on an RRC CONNECTION RELEASE message in states CELL_DCH
and CELL_FACH. Furthermore this procedure can interrupt any ongoing procedures with the UE in
the above listed states.
If RRC CONNECTION RELEASE message was sent on DCCH, the UE answers with an RRC
CONNECTION RELEASE COMPLETE message on DCCH using UM RLC if it is in CELL_DCH
state and AM RLC if it is in CELL_FACH state. In case of UM RLC, the message can be repeated in
the same way as RRC CONNECTION REQUEST message, using V308, N308 counters and T308
timer.

Tables below summarize RRC timers and counters that are associated with RRC connection
management procedures:

Timer Triggering event Stopping event Action at expiry Range Default

value
T300 Transmission of RRC Reception of RRC Retransmit RRC CONNECTION 100, 200... 2000 1000 ms
CONNECTION CONNECTION REQUEST if V300 N300, else by step of 200,
REQUEST SETUP go to Idle mode 3000, 4000,
6000, 8000
T308 Transmission of RRC Not stopped Transmit RRC CONNECTION 40, 80, 160, 320 160 ms
CONNECTION RELEASE COMPLETE if V308
RELEASE COMPLETE N308, else go to idle mode.

Counter Reset Incremented Action when reaching max

value
V300 When initiating the RRC connection Upon expiry of T300 When V300 > N300, the UE
establishment procedure enters idle mode.
V308 When sending the first RRC Upon expiry of T308 When V308 > N308 the UE
CONNECTION RELEASE stops re-transmitting the RRC
COMPLETE message in a RRC CONNECTION RELEASE
connection release procedure. COMPLETE message.

Constant Usage Range Default

value
N300 Maximum number of retransmissions of the RRC 07 3
CONNECTION REQUEST message
N308 Maximum number of retransmissions of the RRC ? ?
CONNECTION RELEASE COMPLETE message

4.1.1.2 Initial/Downlink/Uplink Direct Transfer

Initial Direct Transfer

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 24/43

UE UTRAN

INITIAL DIRECT TRANSFER

The initial direct transfer procedure is used in the uplink to establish a signalling connection. It is also
used to carry an initial upper layer (NAS) message over the radio interface.
It consists of a single RRC message of INITIAL DIRECT TRANSFER transmitted on the uplink
DCCH using AM RLC on signalling radio bearer RB3. If the procedure is initiated while the UE is in
idle mode, it should first perform an RRC Connection establishment procedure; if the UE is in
CELL_PCH or URA_PCH state, it should first perform a cell update procedure, using the cause
"uplink data transmission".

Downlink Direct Transfer

UE UTRAN

DOWNLINK DIRECT TRANSFER

The downlink direct transfer procedure is used in the downlink direction to carry upper layer (NAS)
messages over the radio interface, after the initial signalling connection is established.
The UTRAN transmits the DOWNLINK DIRECT TRANSFER message on the downlink DCCH
using AM RLC on signalling radio bearer RB3 or signalling radio bearer RB4.

Uplink Direct Transfer

UE UTRAN

UPLINK DIRECT TRANSFER

The uplink direct transfer procedure is used in the uplink direction to carry all subsequent upper layer
(NAS) messages over the radio interface belonging to a signalling connection.
The UE shall transmit the UPLINK DIRECT TRANSFER message on the uplink DCCH using AM
RLC on signalling radio bearer RB3 or signalling radio bearer RB4.

4.1.1.3 Paging type 1 & 2

Paging Type 1

UE UTRAN

PAGING TYPE 1

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 25/43

This procedure is used to transmit paging information to selected UEs in idle mode, CELL_PCH or
URA_PCH state using the paging control channel (PCCH). Upper layers in the network may request
paging, to e.g. establish a signalling connection. UTRAN may initiate paging for UEs in CELL_PCH
or URA_PCH state to trigger a cell update procedure. In addition, UTRAN may initiate paging for
UEs in idle mode, CELL_PCH and URA_PCH state to trigger reading of updated system information.
UTRAN initiates the paging procedure by transmitting a PAGING TYPE 1 message on an appropriate
paging occasion on the PCCH.
UTRAN may repeat transmission of a PAGING TYPE 1 message to a UE in several paging occasions
to increase the probability of proper reception of a page.
UTRAN may page several UEs in the same paging occasion by including one IE "Paging record" for
each UE in the PAGING TYPE 1 message.
When a UE in idle mode receives a PAGING TYPE 1 message, it shall perform a RRC connection
establishment procedure.

Paging Type 2 (UE dedicated paging)

UE UTRAN

PAGING TYPE 2

This procedure is used to transmit dedicated paging information to one UE in connected mode in
CELL_DCH or CELL_FACH state. Upper layers in the network may request initiation of paging.
For a UE in CELL_DCH or CELL_FACH state, UTRAN initiates the procedure by transmitting a
PAGING TYPE 2 message on the DCCH using AM RLC.

4.1.1.4 Signalling connection release

UE UTRAN UE UTRAN

SIGNALLING CONNECTION
SIGNALLING CONNECTION RELEASE INDICATION
RELEASE

The signalling connection release procedure is used to notify the UE that one of its ongoing signalling
connections has been released. The procedure does not initiate the release of the RRC connection.
To initiate the procedure, the UTRAN transmits a SIGNALLING CONNECTION RELEASE message
on DCCH using AM RLC.

The signalling connection release indication procedure is used by the UE to indicate to the UTRAN
that one of its signalling connections has been released. The procedure may in turn initiate the RRC
connection release procedure.
To initiate the procedure, the UE transmits a SIGNALLING CONNECTION RELEASE
INDICATION message on DCCH using AM RLC. If it was in X_PCH state, it performs first a Cell
Update procedure.

4.1.1.5 Radio Bearer configuration

RRC procedures for RB configuration in case of a new connection are described in 5.1.1.1.

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 26/43

4.1.2 NBAP procedures

Except for the Node B and Cell management, the NBAP protocol is used to manage dedicated radio
links and dedicated ATM Iub links. For that management, NBAP procedures are limited and exist only
for UEs in CELL_DCH state.

4.1.2.1 Idle to CELL_FACH state

For this connection, the UE is not in CELL_DCH state so there is no dedicated link. There is no
NBAP procedure for this mobility.

4.1.2.2 Idle to CELL_DCH state

For this connection the RNC and the Node B have to create a radio link and two ATM Iub links. So
there are two NBAP procedures for that. The first one is used in order to create a DCH transport
channel for a DCCH logical channel:

NodeB UTRAN NodeB UTRAN

RADIO LINK SETUP REQUEST RADIO LINK SETUP REQUEST

RADIO LINK SETUP RESPONSE RADIO LINK SETUP FAILURE

Radio Link Setup procedure, successful case Radio Link Setup procedure, failure case

The second procedure is used in order to create a second DCH transport channel for a DTCH logical
channel. There is already a radio link, so it is necessary to reconfigure this radio link:

NodeB UTRAN NodeB UTRAN

RADIO LINK RECONFIGURATION PREPARE RADIO LINK RECONFIGURATION PREPARE

RADIO LINK RECONFIGURATION READY RADIO LINK RECONFIGURATION FAILURE

RADIO LINK RECONFIGURATION COMMIT

Radio Link Reconfiguration procedure, successful

Radio Link Setup Reconfiguration, failure case
case

NodeB UTRAN

RADIO LINK RECONFIGURATION PREPARE

RADIO LINK RECONFIGURATION READY

RADIO LINK RECONFIGURATION CANCEL

Radio Link Reconfiguration procedure, abort

case

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 27/43

4.1.3 RANAP procedures

4.1.3.1 RAB Establishment / RAB Release
RAB assignment procedure:
o RAB Assignment Request message: the CN requests the RNC to establish/release one or
several RABs for a same UE.
o RAB Assignment Response message: the RNC informs the CN about the outcome for the
RAB establishment request.

We find in this RANAP procedure two timers associated to the sequence of messages:

o Trabassig specifies the maximum time for the RAB Assignment procedure. This timer is
located in the CN. It is activated when the CN sends the RAB Assignment Request message to
the RNC and it is stopped when the CN has received a final outcome (either established or
failed) in the RAB Assignment Response messages from the RNC for all the RABs requested
previously in the RAB Assignment Request message. When the timer expires, those RABs not
reported as established or failed shall be considered as failed (even if they are still queuing).

o Tqueuing specifies the maximum time for queuing a RAB establishment request. This timer is
located in the RNC. It is activated when the RNC decides to queue a RAB establishment request
received in the RAB Assignment Request message sent by the CN. This timer is stopped when
for all the RABs requested in the RAB Assignment Request message a final outcome (either
established or failed) has been provided in a RAB Assignment Response message. If the timer
expires, the RAB Assignment procedure finish for all the queued RABs, and the RNC shall send
a RAB Assignment Response indicating these RABs as failed to establish.

UE Node B RNC CN

RANAP: RAB ASSIGNMENT

REQUEST

RB establishment TRAB assigt

RANAP: RAB ASSIGNMENT

RESPONSE

UE Node B RNC CN

RANAP: RAB ASSIGNMENT

REQUEST

RAB is put in queue

Start Tqueuing

Tqueuing
TRAB assigt
Stop Tqueuing
RB establishment
RANAP: RAB ASSIGNMENT
RESPONSE

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 28/43

NAS connection management procedures are encapsulated in NAS signalling transfer RANAP
messages, such as RANAP Paging, RANAP UE Initial Message or RANAP Direct Transfer
message. These NAS mobility procedures have also several associated timers, but these ones are out
of the scope of this document.
Only for example, we can provide hereafter some NAS connection management procedures with their
associated timers in the network side:
- Attach procedure: T3350.
- Detach procedure: T3322.
- TMSI reallocation procedure: T3250 and T3350.
- UMTS Authentication procedure: T3260 and T3360.
- Identification procedure: T3270 and T3370.
- Paging procedure: T3313
- Basic Call establishment procedure : T301, T303, T308, T310 and T313.
- Call Clearing procedure: T305.

4.2 Sequence of connection management procedures

Here are the sequence of RRC, NBAP and RANAP procedures for connection management.
For the first two chains of procedures (transitions from RRC_idle to RRC_connected mode), the Step
1 is the RRC connection procedure itself, and the step 3 is the Radio bearer establishment.

Idle CELL_DCH
UE NodeB RNC

RRC CONNECTION REQUEST

RRC RRC
RADIO LINK SETUP REQUEST
NBAP NBAP
RADIO LINK SETUP RESPONSE
Stage 1

NBAP NBAP

RRC CONNECTION SETUP

RRC RRC

RRC CONNECTION SETUP COMPLETE

RRC RRC
Stage 2

Security & NAS Procedures

RANAP : RAB
Assignement
request
RADIO LINK RECONF REQUEST
NBAP NBAP
RADIO LINK RECONF RESPONSE
Stage 3

NBAP NBAP

RADIO BEARER SETUP

RRC RRC
RANAP : RAB
RADIO BEARER SETUP COMPLETE
RRC Assignement
RRC response

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 29/43

For the attachment procedure there are NBAP procedures before each creation of Iub and radio link.
There is one other NBAP procedure for reconfiguration of radio link. The radio bearer setup is a
reconfiguration of radio link.

Idle CELL_FACH
UE NodeB RNC

RRC CONNECTION REQUEST

RRC RRC
EStage 1

RRC CONNECTION SETUP

RRC RRC

RRC CONNECTION SETUP COMPLETE

RRC RRC
Stage 2

Security & NAS Procedures

RADIO BEARER SETUP

Stage 3

RRC RRC

RADIO BEARER SETUP COMPLETE

RRC
RRC

For Idle to CELL_FACH transition, there is no NBAP procedure because there are no dedicated Iub
and radio link. So there are only RRC procedures.

RRC Connection Release, CELL_DCH

UE NodeB RNC

RRC CONNECTION RELEASE

RRC RRC

RRC CONNECTION RELEASE COMPLETE

RRC RRC
RADIO LINK DELETION REQUEST
NBAP NBAP
RADIO LINK DELETION RESPONSE
NBAP NBAP

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 30/43

Radio Bearer release, CELL_DCH

UE NodeB RNC

RADIO BEARER RELEASE

RRC RRC
RADIO BEARER RELEASE COMPLETE
RRC RRC
RADIO LINK DELETION REQUEST
NBAP NBAP
RADIO LINK DELETION RESPONSE
NBAP NBAP

For the release procedure there are NBAP procedures after each destruction or reconfiguration of Iub
and radio link.

RRC Connection release, CELL_FACH

UE NodeB RNC

RRC CONNECTION RELEASE

RRC RRC

RRC CONNECTION RELEASE COMPLETE

RRC RRC

Radio Bearer Release, CELL_FACH

UE NodeB RNC

RADIO BEARER RELEASE

RRC RRC
RADIO BEARER RELEASE COMPLETE
RRC RRC

For release or reconfiguration of radio links in CELL_FACH, there is no NBAP procedure because
there are no dedicated Iub and radio link. So there are only RRC procedures.

4.3 Definition of delay indicators for connection management procedures

This part deals with access time for a user that asks for a communication. In order to ensure a good
quality of service, it is important to optimise this step. For this step varying granularity is very
important because, for example, NAS procedures with CS core network is not at all the same than
NAS procedures with PS core network.

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 31/43

Indicators Name Involved RRC Messages Events Note

Step 1
RRC Connection Request Beginning
Success at step 1
RRC Connection Setup Complete End
Note1
RRC Connection Request Beginning
Failure at step 1
RRC Connection Reject End
RRC Connection Request Beginning
RNC reaction delay at step 1 Note 2
RRC Connection Setup End
UE reaction and transmitted RRC Connection Setup Beginning
Note 3
delay at step 1 RRC Connection Setup Complete End
Step 2
Delay of NAS procedure at RRC Connection Setup confirm Beginning
step 2 Security Mode Command End
UE reaction and transmitted Security Mode Command Beginning
delay at step 2 Security Mode Command Complete End
Step 3
Delay of NAS procedure at Security Mode Command Complete Beginning
step 3 Radio Bearer Setup End
UE reaction and transmitted Radio Bearer Setup Beginning
delay at step3 Radio Bearer Setup Complete End
All Step
RRC Connection request Beginning
Connection delay
Radio Bearer Setup Complete End

Note 1: For both these delay indicators, a long delay can be due to system dysfunction or radio
congestion as well as quality of radio link. In order to distinguish these different causes, there are two
other delay indicators. These two delay indicators are "RNC reaction delay at step 1" and "UE reaction
and transmitted delay at step 1".

Note 2: A long delay at this step is due to Network delay, i.e., the RNC have not allocated radio and
Iub resources immediately
Either the mobile has been queued
Or the RNC CPU is overloaded.

Note 3: A long time at this stage is due to a non-immediate answer of the mobile. This can be due to a
problem on the "UE/Network signalling delay".

Indicators Name Involved RANAP Messages Events Note

RAB Establishment
Success of RAB RAB Assignment Request Beginning Note1
establishment delay RAB Assignment Response End
Failure of RAB RAB Assignment Request Beginning Note 2
establishment delay RAB Assignment Response or TRAB assigt expiry End

Note 1: This delay depends on the NBAP and RRC procedures involved in the radio bearer
establishment procedure.
Note 2: if the CN has not received RAB establishment information at TRAB assigt expiry, then the CN
shall consider those RABs as failed.

4.4 Trace analysis

TO BE COMPLETED IN NEXT VERSION OF THE DOCUMENT

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 32/43

5 Reconfiguration procedures

5.1 Main procedures for reconfiguration

Reconfigurations are related to transitions between RRC modes and states, as described on the
following figure:

Idle

Cell_FACH Cell_DCH

Cell_PCH URA_PCH

The following table details RRC and NBAP procedures used for each mode reconfiguration.
Associated delay indicators are described in part 5.3.

Reconfigurations
Initial UE state Next UE state RRC procedure NBAP Procedure

CELL_FACH
CELL_FACH CELL_DCH RBReconfiguration RadioLinkSetup
CELL_FACH CELL_PCH RBReconfiguration
CELL_FACH URA_PCH RBReconfiguration
CELL_FACH Idle RRCConnectionRelease

CELL_DCH
CELL_DCH CELL_DCH RBReconfiguration RadioLinkReconfiguration
CELL_DCH CELL_FACH RBReconfiguration RadioLinkDeletion
CELL_DCH CELL_PCH RBReconfiguration RadioLinkDeletion
CELL_DCH URA_PCH RBReconfiguration RadioLinkDeletion
CELL_DCH Idle RRCConnectionRelease RadioLinkDeletion

CELL_PCH
CELL_PCH CELL_FACH CellUpdate

URA_PCH
URA_PCH CELL_FACH CellUpdate

Idle
Idle CELL_FACH RRCConnectionRequest
RadioLinkSetup
Idle CELL_DCH RRCConnectionRequest
RadioLinkReconfiguration

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 33/43

5.1.1 RRC procedures

5.1.1.1 Radio Bearer Control procedures

RB setup

UE UTRAN UE UTRAN

RADIO BEARER SETUP RADIO BEARER SETUP

RADIO BEARER SETUP COMPLETE RADIO BEARER SETUP FAILURE

RB reconfiguration

UE UTRAN UE UTRAN

RADIO BEARER RECONFIGURATION RADIO BEARER RECONFIGURATION

RADIO BEARER RADIO BEARER

RECONFIGURATION COMPLETE RECONFIGURATION FAILURE

RB release

UE UTRAN UE UTRAN

RADIO BEARER RELEASE RADIO BEARER RELEASE

RADIO BEARER RELEASE COMPLETE RADIO BEARER RELEASE FAILURE

Transport Channel reconfiguration

UE UTRAN UE UTRAN

TRANSPORT CHANNEL TRANSPORT CHANNEL

RECONFIGURATION RECONFIGURATION

TRANSPORT CHANNEL TRANSPORT CHANNEL

RECONFIGURATION COMPLETE RECONFIGURATION FAILURE

Physical Channel reconfiguration

UE UTRAN UE UTRAN

PHYSICAL CHANNEL PHYSICAL CHANNEL

RECONFIGURATION RECONFIGURATION

PHYSICAL CHANNEL PHYSICAL CHANNEL

RECONFIGURATION COMPLETE RECONFIGURATION FAILURE

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 34/43

General description

Reconfiguration procedures include the following procedures:

- the radio bearer establishment procedure;
- the radio bearer reconfiguration procedure;
- the radio bearer release procedure;
- the transport channel reconfiguration procedure; and
- the physical channel reconfiguration procedure (which is used to establish,
reconfigure and release physical channels).

To initiate any one of these reconfiguration procedures, UTRAN should first configure new radio links
in any new physical channel configuration and start transmission and reception on the new radio links
before sending the first message on the downlink DCCH using AM or UM RLC, i.e., RADIO
BEARER SETUP, RADIO BEARER RECONFIGURATION, RADIO BEARER RELEASE,
TRANSPORT CHANNEL RECONFIGURATION, or PHYSICAL CHANNEL
RECONFIGURATION message.

If the UE receives one of these messages, it can answer either by a success message (i.e. XXX
COMPLETE) or a failure message (i.e. XXX FAILURE). Success messages are transmitted on the
uplink DCCH using AM RLC. If the new state after the procedure is CELL_DCH or CELL_FACH,
the response message shall be transmitted using the new configuration after the state transition. If the
new state is CELL_PCH or URA_PCH, the response message shall be transmitted using the old
configuration before the state transition.

If after state transition the UE enters CELL_FACH or CELL_PCH or URA_PCH state, the UE shall,
after the state transition, start timer T305 using its initial value if timer T305 is not running and if
periodical update has been configured by T305 in the IE "UE Timers and constants in connected
mode" set to any other value than "infinity" (see Table 3-1).

In case of failure of the reconfiguration, the UE sends the XXX FAILURE message on DCCH using
AM RLC. If the reconfiguration procedure affects several radio bearers, the UE may include the
identities of the radio bearers for which the procedure would have been successful into the XXX
FAILURE message. When the UTRAN has received this message, it may restore the old and delete
the new configuration. Upper layers should be notified of the failure.

5.1.1.2 Transport Format Combination Control

UE UTRAN UE UTRAN

TRANSPORT FORMAT
TRANSPORT FORMAT COMBINATION CONTROL
COMBINATION CONTROL

TRANSPORT FORMAT
COMBINATION CONTROL FAILURE

The transport format combination control procedure is used to control the allowed uplink transport
format combinations within the transport format combination set.
To initiate this procedure, the UTRAN transmits the TRANSPORT FORMAT COMBINATION
CONTROL message on the downlink DCCH using AM or UM RLC. In case of failure, the UE sends
back a TRANSPORT FORMAT COMBINATION CONTROL FAILURE message on uplink DCCH
using AM RLC.

5.1.1.3 Cell Update

The Cell Update procedure, described in 3.1.1.1, is also used as a reconfiguration procedure in case
of transition from CELL_PCH or URA_PCH to CELL_FACH.

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 35/43

5.1.2 NBAP procedures

Except for the Node B and Cell management, the NBAP protocol is used to manage dedicated radio
links and dedicated ATM Iub links. For that management, NBAP procedures are limited and exist only
for UEs in CELL_DCH state.

5.1.2.1 CELL_FACH to CELL_DCH state reconfiguration

This procedure is used in PS mode and in order to allocate a dedicated Radio Bearer to a UE. So the
RNC has to create a new dedicated radio link and two ATM Iub link. The procedures are:

NodeB UTRAN NodeB UTRAN

RADIO LINK SETUP REQUEST RADIO LINK SETUP REQUEST

RADIO LINK SETUP RESPONSE RADIO LINK SETUP FAILURE

Radio Link Setup procedure, successful case Radio Link Setup procedure, failure case

5.1.2.2 CELL_DCH to CELL_FACH, CELL_PCH or URA_PCH state reconfiguration

This procedure is used in PS mode and in order to remove a dedicated Radio Bearer to a UE. The
RNC has to delete the radio link and all ATM Iub links. The procedure is:

NodeB UTRAN

RADIO LINK DELETION REQUEST

RADIO LINK DELETION RESPONSE

Radio Link Deletion procedure

5.1.2.3 CELL_DCH to CELL_DCH state reconfiguration

This reconfiguration is used in order to change the Radio Bearer allocated to the UE. The RNC has to
reconfigure the radio link and sometimes, it has to create a DCH transport Channel for DTCH logical
channel. The procedures are:

NodeB UTRAN NodeB UTRAN

RADIO LINK RECONFIGURATION PREPARE RADIO LINK RECONFIGURATION PREPARE

RADIO LINK RECONFIGURATION READY RADIO LINK RECONFIGURATION FAILURE

RADIO LINK RECONFIGURATION COMMIT

Radio Link Reconfiguration procedure, successful

Radio Link Setup Reconfiguration, failure case
case

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 36/43

NodeB UTRAN

RADIO LINK RECONFIGURATION PREPARE

RADIO LINK RECONFIGURATION READY

RADIO LINK RECONFIGURATION CANCEL

Radio Link Reconfiguration procedure, abort

case

5.1.3 RANAP procedures

5.1.3.1 RAB modification

For RAB modification, the RANAP protocol provides the same procedure as for RAB establishment
and RAB release procedures.

RAB assignment procedure:

o RAB Assignment Request message: the CN requests the RNC to modify one or several
RABs for a same UE.
o RAB Assignment Response message: the RNC informs the CN about the outcome for the
RAB modify request.

We find in this RANAP procedure two timers associated to the sequence of messages:

o Trabassig specifies the maximum time for the RAB Assignment procedure. This timer is
located in the CN. It is activated when the CN sends the RAB Assignment Request message to
the RNC and it is stopped when the CN has received a final outcome (either modified or failed)
for all the RABs requested in the RAB Assignment Request message RAB Assignment Response
messages from the RNC. When the timer expires, those RABs not reported as modified or failed
shall be considered as failed (even if they are still queuing).

o Tqueuing specifies the maximum time for queuing a RAB modify request. This timer is located
in the RNC. It is activated when the RNC decides to queue a RAB modify request received in
the RAB Assignment Request message sent by the CN. This timer is stopped when for all the
RABs requested in the RAB Assignment Request message a final outcome (either modified or
failed) has been provided in a RAB Assignment Response message. If the timer expires, the RAB
Assignment procedure finish for all the queued RABs, and the RNC shall send a RAB
Assignment Response indicating these RABs as failed to modify.

UE Node B RNC CN

RANAP: RAB ASSIGNMENT

REQUEST

RB establishment TRAB assigt

RANAP: RAB ASSIGNMENT

RESPONSE

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 37/43

UE Node B RNC CN

RANAP: RAB ASSIGNMENT

REQUEST

RAB is put in queue

Start Tqueuing

Tqueuing
TRAB assigt
Stop Tqueuing
RB establishment
RANAP: RAB ASSIGNMENT
RESPONSE

5.2 Sequence of reconfiguration procedures

Here are the sequences of procedures for reconfiguration. This is done only for NBAP and RRC.

CELL_FACH CELL_DCH
UE NodeB RNC

RADIO LINK SETUP REQUEST

NBAP NBAP
RADIO LINK SETUP RESPONSE
NBAP NBAP

RB RECONFIGURATION
RRC State = CELL_DCH
RRC RRC
RB RECONFIGURATION COMPLETE
RRC RRC

Note : "Radio Bearer Reconfiguration" can be replaced by the following procedures:

Physical Channel Reconfiguration
Transport Channel Reconfiguration
Radio Bearer Release

For a change from CELL_FACH state to CELL_DCH state there is a NBAP procedure before the
RRC procedure in order to create the Iub and the radio link.

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 38/43

CELL_DCH CELL_DCH
UE NodeB RNC
RADIO LINK RECONFIGURATION
PREPARE
NBAP NBAP
RADIO LINK RECONFIGURATION
READY
NBAP NBAP

RB RECONFIGURATION
RRC State = CELL_DCH
RRC RRC
RB RECONFIGURATION COMPLETE
RRC RRC
RADIO LINK RECONFIGURATION
COMMIT
NBAP NBAP

For a change from CELL_DCH state to CELL_DCH state there is a NBAP procedure before the RRC
procedure in order to reconfigure the radio link.

CELL_DCH CELL_FACH
UE NodeB RNC

RB RECONFIGURATION
RRC State = CELL_FACH
RRC RRC
RB RECONFIGURATION COMPLETE
RRC RRC
RADIO LINK DELETION REQUEST
NBAP NBAP
RADIO LINK DELETION RESPONSE
NBAP NBAP

Note :"Radio Bearer Reconfiguration" can be replaced by the following procedures:

Physical Channel Reconfiguration
Transport Channel Reconfiguration
Radio Bearer Release

For a change from CELL_DCH state to CELL_FACH state there is a NBAP procedure after the RRC
procedure in order to delete the Iub and the radio link.

5.3 Definition of delay indicators for reconfiguration procedures

In order to optimise the resource allocation and resource sharing, it is important to do reconfiguration
quickly in order to free some resources for other users.

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 39/43

Indicators Name Involved RRC Messages Events

Radio Bearer Reconfiguration Beginning
Reconfiguration delay 1
Radio Bearer Reconfiguration Complete End
Cell Update Beginning
Reconfiguration delay 2
Radio Bearer Reconfiguration Complete End

For this delay, it important to analyse only "Cell Update" messages with Cell update cause "UL Data
Transmission" or "Paging Response".

Same comment than for the UE reaction time at step 1.

5.4 Trace analysis

TO BE COMPLETED IN NEXT VERSION OF THE DOCUMENT

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 40/43

6 Synthesis

6.1 Granularity of delay indicators

This part gives all delay indicators granularity. This could be very useful in order to investigate any
dysfunction. For example, the NAS procedure delays are not at all the same for Core Network PS and
CS.

For example, the delay indicator "Success at step 1" can be calculated depending on the used Core
Network, the type of call (OC or TC), the class of service used for this connection and the UE RRC
state. So we can distinguish different values depending on the kind of connection that is done by the
UE.

Delay indicators
CN Type Class of service UE state
Delay indicator
CS/PS OC/TC Conv/Str/int/Back CELL_FACH/CELL_DCH
Call establishment
Step 1
Success at step 1 (Note1) X X X X
Failure at step 1 (Note1) X X X
RNC reaction delay at step 1 X X X X
UE reaction and transmitted delay at step 1 X X X X
Step 2
Delay of NAS procedure at step 2 X X X X
UE reaction and transmitted delay at step 2 X X X X
Step 3
Delay of NAS procedure at step 3 X X X X
UE reaction and transmitted delay at step 3 X X X X
All steps
Connection delay (Note 2) X X
Reconfigurations
Reconfiguration delay 1 and 2 X X X
Mobility
URA Update
Success of URA Update
Failure of URA update
Cell Update
Success of Cell Update
Failure of cell update
Soft and Softer Handover
Success of Soft Handover X X X
Failure of Soft Handover X X X
RNC reaction time X X X
Hard Handover
Success of Hard Handover X X X
Failure of Hard Handover X X X

Note 1: For the failure rate at step 1, it is not possible to have the core network used (CN CS or PS).
For the success rate at step 1 it is possible to have the core network used.

Note 2: At this step, it is not possible to have the core network used. Some manufacturers have core
network CS for class of service Conversational and Streaming and core network PS for class of service
Interactive and Background.

6.2 Proposed values for timers

This part of the document is to be completed in the next version of the document.

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 41/43

Delays measured on experimental traces, using indicators defined in the current document, will enable
to propose values for various RRC, NBAP and RANAP timers. For instance, T302 RRC timer will be
set according to the mean value of indicators Cell Update and URA Update defined in 3.3. Other
timers would require a more thorough analysis to be configured: for instance, T305 totally depends on
the traffic load in the network and on the required service accessibility, so it is difficult to analyse its
impact only from traces captured on an experimental network.

6.3 Main measured procedure delays

TO BE COMPLETED IN NEXT VERSION OF THE DOCUMENT

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 42/43

7 Conclusion
This document has presented the major RRC, NBAP and RANAP signalling procedures involved in
mobility, connection and reconfiguration management. The coordination of procedures from various
protocols has been exposed, and the associated timers have been highlighted. Furthermore, delay
indicators have been defined for each domain (mobility, connection management and reconfiguration).
All this matter will be employed to analyse traces obtained on experimental platforms. These delay
indicators may be used with various levels of detail, depending on the type of analysis to perform.

Delays in signalling procedures may be due to several factors:

UE delays are mostly due to internal system causes;
network delays may be caused by system problems, or CPU overload;
transmission delays on Air interface are caused by poor radio link quality.
Moreover, radio congestion or general system dysfunction may have an impact on the total duration of
procedures.

The impact of long delays for the execution of signalling procedures has been shown:
on mobility functions: too long delays in UTRAN mobility functions (particularly, in Active
Set Update procedure) may increase the call drop rate. Indeed, the UE may lose its radio link.
Moreover, delays may have an impact on cell coverage, since the UE will not be
communicating with the best cell as long as the procedure is not achieved, thus generating
more interferences. As a consequence, average delays for signalling procedures should be
taken into account in RRM algorithms concerning mobility, such as macro-diversity
management.
On connection management functions: the time a user has to wait for the establishment of a
communication has a direct impact on the perceived QoS. Therefore, it is crucial to optimise
this access time, both for PS and CS core network domains. These access delays should be
taken into account, for instance, in the algorithms deciding of the RRC state of inactive
mobiles: should they wait for communications in RRC_idle mode, or stay in RRC_connected
mode?
On reconfiguration functions: delays in those procedures, especially for RRC and NBAP
protocols, have a direct impact on RRM algorithms for resource allocation and resource
sharing. Therefore, they should be taken into account in the parameter setting of those
algorithms in order to optimise bandwidth efficiency.

Next step for this study is to analyse traces from experimental platforms. This will be done for Alcatel
release R2S1.5 and Nokia release RAN1.5.2. A second document will be produced then to present
results of these analyses, and to suggest some default values for associated timers.

This document is edited by France Telecom R&D.

Delays and timers of UTRAN signalling procedures 43/43

8 Reference
[1] NRT service QoS UE observation Editor: Sbastien BARET, Ref:
FTR&D/DMR/IIM/03.0017/EdG-SB
[2] Radio indicators of QoS on the UTRAN side Editor: Sbastien BARET, Ref:
FTR&D/DMR/IIM/02.1436/SB
[3] Procdures UMTS et mix de trafic, Anne Daviaud, ref. FTR&D/DMR/IIM/01.1122/AD
[4] Study of RRC Quality of Service Mechanisms in R'99 FDD UTRAN - Part 2: RRC States
Transitions - Manufacturers' implementation, Borja Jimenez Aldama, ref.
FTR&D/DMR/RMO/02.059/BJA
[5] Configuration of URAs and parameter setting for transitions between RRC states, Anne
Daviaud, ref. FTR&D/DMR/IIM/02.1420/AD
[6] 3GPP TS 25.331 v3.12.0 (09/2002), RRC protocol specification
[7] 3GPP TS 25.433 v3.11.0 (09/2002), UTRAN Iub interface NBAP signalling (R99)
[8] 3GPP TS 25.413 v3.11.1 (09/2002), UTRAN Iu interface RANAP signalling (R99)
[9] 3GPP TS 25.133 v3.13.0 (03/2003), Requirements for support of radio resource management
(FDD)
[10] Orange Group Standards Meeting Report, 3GPP Joint RAN2, CN1, SA2 ad-hoc on paging after
local RRC Connection release by UE, ref. FTR&D/DMR/IIM/03.0557/GD
[11] FTR&D/DMR/IIM/03-0627-GD Loss of synchronisation, Guillaume Decarreau

This document is edited by France Telecom R&D.