C 3 6270 Mobility 002 KH PDF

3.
Mobility
¾ 3.1 Handover types
¾ 3.2 Measurements
¾ 3.3 Soft handover
¾ 3.4 Hard handover
¾ 3.5 SRNC relocation
TA-TC 6270 /Version 01/Chap. 03 – Mobility 1

3.1 Handover types

Mobility in UMTS
The current location of a UE is which known to the network depends on the state a UE is in.
RRC Idle: The UE initiates Location/Routing Area Updates if necessary. It is not known in UTRAN.
Once it requests radio resources it enters the UTRA RRC connected mode and gets known in the
RNC. The RRC states can be characterized as follows:
1. In Cell_DCH state, the UE has dedicated channel resources (dedicated physical channel(s)).
The dedicated resources are reserved between the RNC and the BTS (in the Iub interface) for
the UTRAN - UE connection. The location of the UE is known at cell level based on the
existing radio link(s) between the UE and the BTS(s). Only in this substate the Network
initiates handovers.
2. In Cell_FACH state, the UE uses UTRAN common channel resources and there are no
dedicated Iub resources reserved for the UE. The location of the UE is known at cell level
based on the cell update sent by the UE at cell reselection.
3. In Cell_PCH state, the UE can use discontinuous reception (DRX) and it only has to monitor
paging indications and paging messages sent by the RNC. The location of the UE is known at
cell level based on the cell updates sent by the UE at cell reselection.
4. In URA_PCH state, the UE can use DRX and it only has to monitor paging indications and
paging messages sent by the RNC. Should the RNC wish to initiate downlink activity (for user
plane data or signalling messages), it must first transfer the UE to the Cell_FACH state by
means of paging it. The location of the UE is known at URA level based on the URA updates
sent by the UE when a URA change occurs.

Mobility in UMTS
-Cell selection/Reselection
RRC idle -Location Updates
-Routing Area Updates
-Handovers
Cell_DCH -Network controlled Cell Reselection
Cell_FACH -Cell Updates (Cell Reselection)
RRC connected
Cell_PCH -Cell Updates (Cell Reselection)
URA_PCH -URA Updates (Cell Reselection)

Handover types
The purpose of handover control is to manage the mobility aspect of a radio resource control (RRC)
connection (in Cell_DCH).
• intra-frequency handover: The cells use the same carrier frequency.
• Inter-frequency handover: The cells use different carrier frequencies.
• Inter-system handover. The cells are of different radio access technologies (RAT), and
consequently different frequencies, too. A handover between a GSM cell and a WCDMA cell is, for
example, a typical inter-system handover.
There is a fundamental difference between the intra-frequency handovers and the other handover
types; the intra-frequency handovers allow the UE to move around, whereas the other types of
handover provide added coverage. Handovers are divided into soft and hard handovers. In soft
handovers, the UE is simultaneously connected to more than one WCDMA BTS, which all use the
same carrier frequency. In soft handover, the UE is not disconnected at all - instead it simply drops
one out of two or more radio links, which remain active. The inter-frequency and inter-system
handovers are always hard handovers.
Compressed
Handover type Soft Hard Evaluated by
mode needed
Intra-frequency Yes Yes Mobile No
Inter-frequency No Yes Network Yes
Inter-system No Yes Network Yes

Hard and Soft Handover
Hard Handover
Frequency 3 (GSM)
Soft/softer Handover Cell F
Frequency 2
Cell E
Cell D
Frequency 1
Cell C
Cell B Cell A
No Iur!!

Handover procedures
From the UTRAN point of view, the following handover types are defined. In parallel, when the UE changes the
RNC the SRNC relocation procedure will be required.
•Intra-frequency handover
•Intra-Node B (softer handover)
•Inter-Node B intra-RNC (soft handover) Triggered by radio condition (downlink quality)
•Inter-Node B inter-RNC (hard handover)
•Inter-RNC intra-CN (soft handover)
•Inter-CN (soft handover)
•Inter-frequency handover (hard handover)
Triggered by load,
•Intra-Node B handover
traffic characteristics,
•Inter-Node B intra-RNC handover coverage and user
•Inter-RNC intra-CN handover mobility characteristics.
•Inter-CN handover
•Inter-system handover
triggered mainly for
•UMTS to GSM/GPRS coverage reasons
•GSM/GPRS to UMTS
Handover control is part of the radio resource management (RRM) functions which resides in Serving RNC.
Measurement control is responsible for the configuration of measurements in the UE and the Node B. It must
co-ordinate the measurements performed for different radio resource management functions and for
performance management. Furthermore, it defines the reporting conditions and the pre-processing. The
decision to perform a handover is based mainly on measurements done by the UE and reported to the SRNC.

Handover types
Handover SRNC Relocation required
Intra-frequency handover
Intra-Node B (softer handover) Triggered by radio
Inter-Node B intra-RNC (soft handover) condition
Inter-Node B inter-RNC (hard handover) (downlink quality)
Inter-RNC intra-CN (soft handover)
Inter-CN (soft handover)
•Inter-frequency handover (hard handover) Triggered by load, traffic

•Intra-Node B handover characteristics, coverage
•Inter-Node B intra-RNC handover and user mobility
•Inter-RNC intra-CN handover characteristics.
•Inter-CN handover
•Inter-system handover
•UMTS to GSM/GPRS triggered mainly for
•GSM/GPRS to UMTS coverage reasons

Handover types
Handover
Backward initiated by the network

the MS loses contact with the network
Hard
(for a short period of time) Forward initiated by the terminal
In the case of radio link drop or
For PS services
Soft/softer Evaluated by UE
There are two general types of hard handovers defined for the UTRAN: forward and backward
handover. The forward handover is initiated by the Mobile Station, the backward handover is
initiated by the network. When a hard handover is performed – in difference to a soft handover – the
MS loses contact with the network (when it switches from old radio link to the new one) for a very
short time period (short enough to be not noticed by the user who has an ongoing active voice call).
While Hard Handover can be both, Forward or Backward Handover, Soft Handover procedures are
always controlled by the SRNC so that all Soft (and Softer) Handover belong to the group of
Backward Handover.

3.2 Measurements

Measurements
In the RRC Measurement Control message the UE is informed about what the UE shall measure.
Measurement type: describes what the UE shall measure (there may be 2 messages):
-Intra-frequency measurements: measurements on downlink physical channels at the same frequency as the active set.
A measurement object corresponds to one cell.
-Inter-frequency measurements: measurements on downlink physical channels at frequencies that differ from the
frequency of the active set and on downlink physical channels in the active set. A measurement object corresponds to
one cell.
-Inter-RAT measurements: measurements on downlink physical channels belonging to another radio access technology
than UTRAN, e.g. GSM. A measurement object corresponds to one cell.
-Traffic volume measurements: measurements on uplink traffic volume. A measurement object corresponds to one cell.
-Quality measurements: Measurements of downlink quality parameters, e.g. downlink transport block error rate. A
measurement object corresponds to one transport channel in case of BLER.
-UE-internal measurements: Measurements of UE transmission power and UE received signal level.
-UE positioning measurements:
Measurement objects: The objects on which the UE shall measure measurement quantities, and corresponding object
information.
Measurement quantity: The quantity the UE shall measure on the measurement object. This also includes the filtering of the
measurements.
Reporting quantities: The quantities the UE shall include in the report in addition to the quantities that are mandatory to
report for the specific event.
Measurement reporting criteria: The triggering of the measurement report, e.g. periodical or event-triggered reporting.
Measurement Validity: Defines in which UE states the measurement is valid.
Measurement reporting mode: This specifies whether the UE shall transmit the measurement report using AM or UM RLC.
Additional measurement identities: A list of references to other measurements. When this measurement triggers a
measurement report, the UE shall also include the reporting quantities for the measurements referenced by the additional
measurement identities.

Measurements
Node B
FACH DL RLC UMD rrcConnectionSetup

(rrc-TAID, IMSI or TMSI, U-RNTI, UL_ScrCd/DL_ChCd, PScrCd, SRB Info)
DCH UL RLC AMD rrcConnectionSetupComplete
DCH DL RLC AMD rrcMeasurementControl

DCH UL RLC AMD RRC initialDirectTransfer xxxxxx1. Intra-frequency measurements

2. Inter-frequency measurements
3. Inter-RAT measurements
There may be several 4. Traffic volume measurements
„rrcMeasurementControl“ 5. Quality measurements
messages 6. UE-internal measurements
7. UE positioning measurements:

Intra frequency events
A UE in CELL_DCH state can be served by several cells using the same frequency simultaneously. The active
set contains the Cells in soft/softer handover connection. Each cell in the active set provides one radio link. The
active set is known by the SRNC and the decision about the addition, removal or replacements of cells is done
by the SRNC with the help of events reported by the UE, initialized with the ‚rrcMeasurementControl‘ message.
It informs the UE as well about which neighbours it shall monitor. Monitored cells (candidates) are in the
neighbor set: their signal is not strong enough to be added to the Active set. Soft handover is a mobile evaluated
handover (MEHO). The interfrequency, intrafrequency and inter-RAT measurements can be filtered by the UE.
Intra frequency measurements are handled by event 1A,B,C,D,E,F while only event 1A, B, C are taken as input
into the soft handover algorithm.
• Event 1A: Active set addition
• Event 1B: Active set removal
• Event 1C: Active set replacement
In order to get informed about the best server, the
• Reporting event 1D: Change of best cell
may be configured.
Received signal code power (RSCP) measurement result on the primary CPICH can be used to trigger off inter-
frequency handover if the serving cell (or cells participating in soft handover) has neighbor cells on another
carrier frequency. Event 1E and 1F are configured in the UE.
• Event 1E: A Primary CPICH becomes better than an absolute threshold
• Event 1F: A Primary CPICH becomes worse than an absolute threshold
(event 1F is valid for all active set cells simultaneously)

Measurements
Reporting event 1A: A Primary CPICH enters the reporting range Reporting event 1B: A primary CPICH leaves the reporting range
Definable Definable
Measurement offset CPICH Cell B Measurement offset CPICH Cell B
Qantity Frequency 1 Qantity Frequency 1
CPICH Cell A CPICH Cell A

Frequency 1 Frequency 1
Distance, Time Distance, Time

UE in DCH state served by Cell A moves
UE in DCH state served by Cell A/B moves
Reporting event 1C: A non-active primary CPICH becomes better
than an active primary CPICH Reporting event 1D: Change of best cell
Definable Definable
Measurement offset CPICH Cell B offset CPICH Cell B
Measurement
Qantity Frequency 1 Frequency 1
Qantity
CPICH Cell A CPICH Cell A
Frequency 1 Frequency 1
UE in DCH state served by Cell A/C/D moves, cell A UE in DCH state served by Cell A/B moves
worst value (max active set size is full!)

Other events 1
Depending on the vendor of the RNC different events may be in use to trigger Handovers, RBC
or CTS.
Inter-frequency reporting events
Event 2a: Change of best frequency
Event 2b: The estimated quality of the currently used frequency is below a certain threshold and the estimated quality
of a non-used frequency is above a certain threshold
Event 2c: The estimated quality of a non-used frequency is above a certain threshold
Event 2d: The estimated quality of the currently used frequency is below a certain threshold
Event 2e: The estimated quality of a non-used frequency is below a certain threshold
Event 2 f: The estimated quality of the currently used frequency is above a certain threshold
InterRAT reporting events

Event 3a: The estimated quality of the currently used UMTS frequency is below a certain threshold and the estimated
quality of of the other system is above a certain threshold
Event 3b: The estimated quality of the other system is below a certain threshold
Event 3c: The estimated quality of the other system is above a certain threshold
Event 3d: Change of best cell in other system
Traffic Volume reporting triggers

Reporting event 4 A: Transport Channel Traffic Volume becomes larger than an absolute threshold Event 2b: The
estimated quality of the currently used frequency is below a certain threshold and the estimated quality of a non-used
frequency is above a certain threshold
Reporting event 4 B: Transport Channel Traffic Volume becomes smaller than an absolute threshold
Quality reporting events

Reporting event 5A: A predefined number of bad CRCs is exceeded

Other events 2
The list is not complete, additional events may be defined.
UE internal measurement reporting events

Reporting event 6A: The UE Tx power becomes larger than an absolute threshold
Reporting event 4 B: Transport Channel Traffic Volume becomes smaller than an absolute threshold
Reporting event 6B: The UE Tx power becomes less than an absolute threshold
Reporting event 6C: The UE Tx power reaches its minimum value
Reporting event 6D: The UE Tx power reaches its maximum value
Reporting event 6F: The UE Rx-Tx time difference for a RL included in the active set becomes larger than an absolute
threshold
Reporting event 6G: The UE Rx-Tx time difference for a RL included in the active set becomes less than an absolute
threshold
UE positioning reporting events

Reporting Event 7a: The UE position changes more than an absolute threshold
Reporting Event 7b: SFN-SFN measurement changes more than an absolute threshold
Reporting Event 7c: GPS time and SFN time have drifted apart more than an absolute

3.3 Soft-handover

Softhandover
The Handover control (HC) RRM entity in the SRNC manages user mobility in call (CELL_DCH) by ensuring that
UE is always served by the optimal cell(s) in order to ensure quality, minimise interference and optimise the
available capacity.
Counters do not differentiate between Soft and Softer Handover. One of the big differences is that in case of soft
handover 2 Iub resources are used, in case of softer handover only one.
The bigger the softhandover-area the more resources (power, codes, transport resources, Base band
capacity…) are ‘wasted’, but the better the service quality gets.
What concerns counters and KPI care has to be given, if events are updated for all cells in the active set, or for
only one cell (for which one?)
Depending on the vendor some counters (for example the call drop) are updated for only one cell, it could be the
latest cell, which has been added or the best cell (requires implemntation of event 1d [change of best server] for
example).

Soft Handover UL
Power of UE
Frequency 1
Cell B Cell A

Soft handovers
Drift Serving
New
Node B
Event 1A,C
event-triggered or periodic
RRC: Measurement Report
RNSAP: RL Setup Request
NBAP: RL Setup
NBAP: RL Setup Response

RNSAP: RL Setup Response
Iub Bearer Setup
UP FP: Downlink Synch.

UP FP: Uplink Synch.
RRC: Active Set Update (RL Addition, Deletion, Replacement)

RRC: Active Set Update Complete

Soft Handover Analyses
Soft HO (RRC)
RL Deletion to Active Set
RL Addition to Active Set
Attempt Success Failure Attempt Success Failure
Based on the
RRC: Active Set Update (RL Addition/RL deletion)
-softer handover between cells served by one Node B.
-soft handover between cells served by diferent Node Bs within one RNC.
-soft handover between NodeBs controlled by different RNCs.

Soft handover failure
Drift Serving
New
Node B
Event 1A,C
No Transport or Code or Power resources in target cell

In the case, that no resources are available no message is sent!!
RRC: Active Set Update (RL Addition, Deletion, Replacement)

RRC: RRC activeSetUpdateFailure
-Different failure indication messages on different protocol layers may cause Soft HO
failure.
-Procedure may be aborted if any message is not sent/received (timer expiry cannot be
measured with cumulative event counters).
-Additional analysis tools necessary to show relations between cells, e.g. Cell Overlapping
Matrix
In most cases the RNC will release the RRC connection!!

Soft handover “overhead”
There is usually a soft-handover gain on the air, but if the softhandover area is too big, There may be a
soft-handover loss. And each branch in different Node Bs requires transport resources. So the
softhandover ratio should be monitored. Different approaches may apply:
Cell based:
Gives a good idea of the real distribution of traffic in the network.
In this example, there are 7 UE served by one Radio Link and 8 UE served by
two Radio Links, the soft handover overhead so (7x1 + 8x2)/15=1.53, the
Soft handover-area is quite big. Different approaches may apply, one may just
count the users, where with cell has been added lately or where this cell A is the
best server. Then (7x1 + 4x2)/11=1.35. The other Ues are counted within the other
cells.
‚Call‘ based:
The user may be served temporarily by 1, 2 or 3 Radio links. The information about is given by active set
update messages.
This can be received by tracing the successfull branch additions/deletions or active set update messages.
for that UE one gets an the same information

RL Addition RL Deletion
=branch addition =branch deletion
Cell A Soft handover area Cell B
Active set size: 1 Active set size: 2 Active set size: 1

Radio Link in cell B
Radio Link in cell A
Time
1 RRC connection

Cell based: Active set size = 1 Active set size = 2
Cell A Soft handover area
UEs, where A is best server

Call based:
RL Addition RL Addition RL Deletions
Active set size: 1 2 3 2 1
RAB establishment 2. RAB establishment Time

RRC establishment End of observation

Active Set Size
Active Set Size of UEs as seen by Cell / RNC
Each UE in Cell_DCH is counted once or

Number of UE with Active Set=1 The counter is based on Radio Links!
The sum corresponds to the number of
Number of UE with Active Set=2 UE per cell (the latest or best) or per RNC.
Number of UE with Active Set=3
[Active Set=1] x1+ [Active Set=2]x2 +[Active Set=3]x3

Formula per cell: Average AS size:
[Active Set=1] + [Active Set=2] +[Active Set=3]
Based on active UEs

Formula: RNC wide: Average AS size:
[Active Set=1]/1 + [Active Set=2]/2 +[Active Set=3] /3
Based on Radio Links

Active Set Size
Cell level counters can be seen as an local estimation of the active set size!
[Active Set=1] x1+ [Active Set=2]x2 +[Active Set=3]x3

Formula per cell: Average AS size:
2 UE 1 UE
Active set size = 1 Active set size = 2
(2x1 ) + (1x2)
Average AS size cell A= = 1.33 Average AS size cell B = not defined (no active UE)
2+1

Active Set Size
Based on Radio Links establishments/releases
Formula: RNC wide: Average AS size:
2 UE 1 UE
Active set size = 1 Active set size = 2
2+1
Average AS size= = 1.2
(2/1 ) + (1/2)

Soft-handover overhead
Number of radio Links
General formula: Soft-handover overhead = -1
Number of UE in cell_DCH

Formula: RNC wide: Soft handover overhead = -1
2 UE 1 UE In this example it would be

Active set size = 1 Active set size = 2 0,2 or 20 %

Soft/softer handover and Iub
The difference between Soft and Softer Handover is whether the 2 different Radio Links are from the same or
from a different NodeB.
Soft Handover – the UE is served by 2 Node Bs
Softer Handover – the UE is served by one Node B
That means only in the case of a Soft Handover two transport resources on the IuB are needed.
This has to be considered for the Iub. The Iub should be dimensioned accordingly.

Soft-handover and IuB
UE 1: Softer Ho
UE 5: No HO
Example:
5 active UE:
UE 2: Soft-Softer HO
2 UE no HO
UE 3: Soft-Soft HO 1 UE softer HO
1 UE Soft Softer HO
1 UE Soft-Soft HO
Softhandover overhead:
100% (5 active UE but 10 RLs)
For Iub:
Only 40 %
UE 4: No HO
(only Soft HO are counted)

3.4 Hard-handover

Inter frequency measurements
In order to maintain the current connection on a certain frequency while performing measurements on another
frequency for most UEs compressed mode is needed. This allows the UE to monitor neighbouring cells on
another frequency (FDD) or radio access technology (RAT), typically GSM., inter-frequency and inter-RAT
(GSM) handovers are only possible if compressed mode is used.
Compressed mode means that transmission and reception are halted for a short time - a few milliseconds - in
order to perform a measurement on another frequency or RAT. The UE informs the RNC whether or not it
requires compressed mode in order to perform inter-frequency or inter-RAT (GSM) measurements. Compressed
mode is activated separately for the uplink and downlink directions according to the measurement capabilities of
the UE. The type of receiver that the UE is equipped with determines the need for downlink compressed mode.
A UE equipped with a single receiver requires downlink compressed mode in order to perform inter-frequency
and GSM measurements, whereas a UE equipped with a dual receiver can perform the measurements in
question without downlink compressed mode.The need for uplink compressed mode depends on whether
transmission on the currently used uplink radio frequency can interfere with downlink measurements on the
monitored frequency.
Compressed mode patterns for intersystem and inter-frequency measurements cannot be active at the same
time.
Inter-frequency and inter-system measurements are stopped if the quality of the current frequency is above a
certain threshold. Trigger 2F/1E is used to stop the interfrequency measurements and to stop the intersystem
measurements.

Inter system/ inter frequency
handovers
UEs with a dual synthesizer can receive on two frequencies simultaneously
however the majority of the UEs have a single synthesizer.
Compressed mode
initialization
Handover?
WCDMA
GSM or Cell B
another UMTS
frequency

Compressed Mode
In order to maintain the current connection on a certain frequency while performing measurements on another
frequency for most UEs compressed mode is needed. This allows the UE to monitor neighbouring cells on
another frequency (FDD) or radio access technology (RAT), typically GSM., inter-frequency and inter-RAT
(GSM) handovers are only possible if compressed mode is used.
Compressed mode means that transmission and reception are halted for a short time - a few milliseconds - in
order to perform a measurement on another frequency or RAT. The UE informs the RNC whether or not it
requires compressed mode in order to perform inter-frequency or inter-RAT (GSM) measurements. Compressed
mode is activated separately for the uplink and downlink directions according to the measurement capabilities of
the UE. The type of receiver that the UE is equipped with determines the need for downlink compressed mode.
A UE equipped with a single receiver requires downlink compressed mode in order to perform inter-frequency
and GSM measurements, whereas a UE equipped with a dual receiver can perform the measurements in
question without downlink compressed mode.The need for uplink compressed mode depends on whether
transmission on the currently used uplink radio frequency can interfere with downlink measurements on the
monitored frequency. Gap pattern parameters have to be configured in phone.
Frame Frame Frame Frame Frame Frame
Transmission gap within frames
Data Data
Transmission gap
(No data)
Frame Frame
Transmission gap between frames

Compressed mode initialization
Event 1F (or 2D)

RNSAP: RL Reconfiguration
NBAP: RL Reconfiguration Prepare
Prepare
NBAP: RL Reconfiguration RNSAP: RL Reconfiguration
Ready Ready
RNSAP: RL Reconfiguration
NBAP: RL Reconfiguration Commit
Commit
RRC: Physical Channel Reconfiguration

RRC: Physical Channel Reconfiguration Complete

Inter frequency Handover
Source Target
Event 2D, 2A, 2B, 2F

RNSAP: RL Setup Request

NBAP: RL Setup Request
NBAP: RL Setup Confirm RNSAP: RL Setup Confirm

RRC: Physical Channel Reconfiguration
UE synchronizesNBAP: RL Restore Indication
RNSAP: Restore Indication
RRC: Physical Channel Reconfiguration Complete
NBAP: RL Failure Indication
UE has changed the frequency

Inter Frequency Handover
Hard HO (RRC) Intra/inter Node B, Intra/inter RNC
Number of attempted outgoing hard handovers
Transmission of an RRC: PHYSICAL CHANNEL RECONFIGURATION message from the UTRAN to the UE,
indicating the attempt of inter-frequency handover.
Number of successful outgoing hard handovers
Receipt of an RRC: PHYSICAL CHANNEL RECONFIGURATION COMPLETE message sent from the UE to the
UTRAN, indicating the successful inter-frequency handover..”
Number of unsuccessful outgoing hard handovers per handover type per failure cause
Receipt of an RRC: PHYSICAL CHANNEL RECONFIGURATION FAILURE message sent from the UE to the UTRAN,
indicating a failed inter-frequency handover or no response. 3GPP causes:
Configuration unsupported
Physical channel failure
Incompatible simultaneous reconfiguration
HHO interruption by receiving NBAP: RL FAILURE INDICATION message
HHO interruption by receiving RRC: Cell UPDATE and RNSAP: UPLINK SIGNALLING TRANSFER message
Cell update occurred
Invalid configuration
Configuration incomplete

Inter System Handover CS
Number of outgoing Inter System handover

Due to the fact that there is no support in most cases for the handover procedure in
GPRS and Video calls are not supported in GSM the Handover from UTRAN is only
initialized if the UE has only CS services, which are supported in GSM active and if Successfull
there was a successfull SRNC relocation procedure before. SRNC
Relocation .
( RLC-SAP: AM, DCCH ) HANDOVER FROM UTRAN COMMAND

[ GSM Handover Command ]
Number of incoming Inter System handover

Successfull
Before the UE can access UTRAN the Radio Link has to be established, the Trigger will SRNC
be the SRNC relocation procedure initiated by the MSC Relocation .
( RLC-SAP: AM, DCCH ) HANDOVER TO UTRAN COMPLETE
[ CN Domain Id ]

Handover to GSM/GPRS
UE in
This procedure may be used in CELL_DCH state. This
Cell_DCH To GSM procedure may be used when no RABs are established or
when the established RABs are only in the CS domain or
when the established RABs are in both CS and PS
domains. indicating an attempted outgoing inter RAT
handover.
HO fom UTRAN command relocation preparations
HANDOVER FROM UTRAN FAILURE

IU RELEASE COMMAND
UE in To GPRS
Cell_FACH/DCH This procedure may be used in CELL_DCH and
CELL_FACH state. This procedure may be used when
no RABs are established or when the established RABs
are only from PS domain. indicating an attempted
CELL CHANGE ORDER FROM UTRAN outgoing PS inter RAT handover.
CELL CHANGE ORDER FROM UTRAN FAILURE
SRNS CONTEXT REQUEST

Intersystem Handover
UE/MS
To GSM
RRC: MEASUREMENT REPORT(DCH: DCCH) Relocation Required
Relocation Command
HO fom UTRAN command
NBAP: RADIO LINK FAILURE INDICATION Iu Release Command
Iu Release Complete
The Node B will indicate a Radio Link Failure!!

Inter system Handover CS
UE/MS UE/MS
BSC
To GSM Relocation Required Handover-Request
Relocation Command Handover-Request Ack

radio link failure in UTRAN and radio link establishment in GSM/BSS
HO-Detect HO-Access
Source HO-Complete HO-Complete
Iu Release Command
Iu Release Complete
Relocation Required Handover Required

From GSM
Relocation Request Ack
Handover Command
Source
HO-Complete Relocation Detect
Relocation Complete
Clear Command
Clear Detect

Inter System Handover CS
Inter System Handover
Number of attempted outgoing inter system handovers
Transmission of a RRC: HANDOVER FROM UTRAN COMMAND message sent from the UTRAN to the UE.
Number of successful outgoing inter-system handovers
Receipt of a RANAP: IU RELEASE COMMAND message sent by the CN to the UTRAN indicating a successful
inter-system handover.
Number of unsuccessful outgoing inter system handovers per handover type per failure cause
Receipt of an RRC: HANDOVER FROM UTRAN FAILURE message sent from the UE to the UTRAN in response to a RRC:
HANDOVER FROM UTRAN COMMAND message or timer expiry (non- receipt of a RANAP: IU RELEASE COMMAND
message, UE lost!)
Number of attempted incoming inter system handovers
has to be be seen by the SRNC Relocation Procedure
Number of successful incoming inter-system handovers
Receipt of an RRC: HANDOVER TO UTRAN COMPLETE message sent from the UE to the target RNC, indicating
a successful inter RAT handover.
Number of unsuccessful incoming inter-system handovers

Inter System Handover PS
Number of outgoing Inter System handover
( RLC-SAP: AM, DCCH ) CELL CHANGE ORDER

FROM UTRAN COMMAND RANAP: SRNS
CONTEXT REQUEST
Number of incoming Inter System handover
( RLC-SAP: AM, DCCH ) CELL CHANGE ORDER TO

UTRAN COMPLETE
[ CN Domain Id ]

Inter System Handover PS
Inter System Handover
Number of attempted outgoing inter system handovers
Transmission of a RRC: CELL CHANGE ORDER FROM UTRAN message sent from the serving RNC to the UE,
indicating an attempted outgoing PS inter RAT handover (UTRAN controlled).
Number of successful outgoing inter-system handovers
Receipt of a RANAP: IU RELEASE COMMAND message (for DCH: PS Single calls), sent by the PS CN to the
serving RNC, indicating a successful outgoing UTRAN controlled PS inter RAT handover.
Number of unsuccessful outgoing inter-system handovers per handover type per failure cause
Receipt of an RRC: CELL CHANGE ORDER FROM UTRAN FAILURE message sent from the UE to the serving RNC,
indicating an unsuccessful PS inter RAT handover
Number of successful outgoing packet switched Inter-RAT handovers, UE controlled
UE in Cell Fach state performed cell reselection to GPRS

Number of attempted incoming inter system handovers
Number of successful incoming inter-system handovers

Mobility for PS
UE in CELL_PCH/CELL_FACH state
( RLC-SAP: TM, CCCH ) CELL UPDATE

[ U-RNTI, Update Cause ]
( RLC-SAP: UM, CCCH / DCCH ) CELL UPDATE CONFIRM

[ RRC TAId, opt. New U-RNTI ]
( RLC-SAP: AM, DCCH ) optional reconfiguration *

[ RRC TAId, reconf. specific info ]
( RLC-SAP: AM, DCCH ) CELL UPDATE

( RLC-SAP: UM, CCCH ) RRC CONNECTION RELEASE

[ U-RNTI, RRC TAId, Release-Cause ]

Mobility for PS
UE in URA_PCH state
( RLC-SAP: TM, CCCH ) URA UPDATE

( RLC-SAP: UM, CCCH / DCCH ) URA UPDATE CONFIRM

[ RRC TAId, opt. New U-RNTI ]
( RLC-SAP: AM, DCCH ) optional reconfiguration *

[ RRC TAId, reconf. specific info ]
( RLC-SAP: AM, DCCH ) URA UPDATE

( RLC-SAP: UM, CCCH ) RRC CONNECTION RELEASE

[ U-RNTI, RRC TAId, Release-Cause ]

Handover statistics
A cell will give traffic due to handovers and take traffic, so it is important to monitor Handovers on
an adjacency basis, which neighbour takes the traffic?, where do incoming handovers come from?
This allows to verify the current plan and to check, if the load is optimal distributed. As well by
observing the failure one may detect some local problems.
Handovers are only possible, if the source/target cell is defined as neighbour.
Is adjacent to
Cell Cell
Handover possible

3.5 SRNC Relocation

Serving RNS Relocation
Core Network Core Network
Target Source Iu Iu
SRNS
DRNS Iur SRNS RNS
Cells
Before SRNS Relocation After SRNS Relocation
The relocation of the serving RNC is the result of the mobility of the user. The change of the serving RNC
strongly affects the core network, because the Iu interface the UE’s signaling connection is maintained on
will change. The relocation procedure is comparable with the GSM inter-BSC handover, but should not be
considered to be a handover. Indeed a relocation is completely independent on procedures of the air
interface.

Relocation preparations
The relocation is done in four major steps :
1 Relocation Preparation :
The decision to start a relocation comes always from the source RNC (old serving RNC). This decision is based
on project dependent criteria. For this the source RNC will send the RANAP message RELOCATION
REQUIRED to the core network. The message contains the relocation type (UE involved or not involved), the
source RNC ID and the target RNC ID. Additionally a transparent container to the target RNC will be included.
The core network will now decide to perform the relocation or not. If yes the CN will send RELOCATION
REQUEST in a CR (Connection Request) to the target RNC. This will trigger the target RNC to allocate all
necessary resources (RABs, SCCP connection) for the relocation. c) When the preparation is completed the
target RNC sends back RELOCATION REQUEST ACKNOWLEDGE in a CC (Connection Confirm) message of
SCCP. This concludes the preparation.
2 Relocation Execution :
Now the CN knows that everything is ready, hence it triggers the execution of the relocation with RELOCATION
COMMAND. The exact execution procedure depends on whether the UE is involved or not.
3 Relocation Completion :
When the target RNC detects the UE on the physical level (i.e. frame synchronization) it will send the message
RELOCATION DETECT to the core network. When the target RNC has a logical relation with the UE (i.e. new S-
RNTI) the target RNC which proves to be the new serving RNC will indicate the end of the relocation to the CN
with RELOCATION COMPLETE. With this the relocation is in fact completed.
4 Release Resources :
Resources of the source RNC that is now no longer the serving RNC can be cleaned up. Hence the CN will send
IU RELEASE COMMAND to the source RNC which will trigger the release of all no longer necessary RABs and
the release of the old SCCP connection.

Relocation preparations
Source Target
attempted outgoing attempted incoming

relocation preparations relocation attempts
RELOCATION REQUIRED
TYPE: “UE involved” RELOCATION REQUEST
“UE not involved”
Cause: “Time critical Relocation"
"Resource optimisation relocation"
"Relocation desirable for radio reasons"
,"Directed Retry",
"Reduce Load in Serving Cell“ RELOCATION REQUEST
"Access Restricted Due to Shared Networks „
..... ACKNOWLEDGE
RELOCATION COMMAND
RELOCATION PREPARATION FAILURE RELOCATION FAILURE
e.g. “TRELOCalloc expiry(no response “Requested Ciphering and/or Integrity Protection algorithms not supported
” “Resource failure in TRELOCalloc expiry
Unknown target RNC
target CN/RNC or target system,” “Relocation not supported inRelocation cancelled
target RNC or target system”) Relocation failure in target CN/RNC or target system
...

Relocation Types
If the UE is involved in the relocation procedure it always means that a backward hard handover controlled by old
SRNC (RNC 1) is performed. The special feature of the UE involved SRNS relocation is that neither signaling nor
any other kind of data is exchanged via Iur interface. This is necessary if no Iur interface exists or if source and
target cell are working on different UTRAN frequencies.
RNC 1 is SRNC and receives measurement report from UE that new cell became available. Based on this
measurement report the decision is made to perform hard handover and SRNS relocation in one step.
Iur
Iur only required in case of

‚UE not involved‘

Relocation procedure PS
Source Target
1 2
UE
In cell DCH 1. Relocation Required
In case that 2 SGSN
are involved
2. Forward Relocation Request

GTP tunnel created between
target SGSN and target RNC
3. Relocation Request
4. Relocation Request Acknowledge
5. Forward Relocation Ack
6. Relocation Command
DATA DUPL. STARTED

RRC RANAP GTP

Relocation procedure PS
Source Target
1 2
UE
In FACH
Cell Update In case that 2 SGSN
Uplink Signalling
1. Transfer Indication are involved
Relocation Required
Forward Relocation Request
GTP tunnel created between
target SGSN and target RNC
Relocation Request
Relocation Request Acknowledge
Relocation Command
Relocation Committ
Forward Relocation Response
Forwarding
of Data the target RNC shall start SRNC operation
Relocation Detect
Cell Update Confirm the CN switch the user plane from
the source RNC to the target RNC.
Iu Release

Inter system Handover
UE/MS UE/MS
BSC
To GSM Relocation Required Handover-Request
Relocation Command Handover-Request Ack

radio link failure in UTRAN and radio link establishment in GSM/BSS
HO-Detect HO-Access
Source HO-Complete HO-Complete
Iu Release Command
Iu Release Complete
Relocation Required Handover Required

From GSM
Relocation Request Ack
Handover Command
Source
HO-Complete Relocation Detect
Relocation Complete
Clear Command
Clear Detect

Relocation Preparations
Relocation Preparations
Number of attempted outgoing relocation preparations per relocation cause per relocation type
(per intra/inter PLMN)
Transmission of a RANAP: RELOCATION REQUIRED message sent by the Source RNC to the CN.Relocation
Types (“UE involved” and “UE not involved”)
Number of successful outgoing relocation preparations per failure cause (per intra/inter PLMN)
Receipt of a RANAP: RELOCATION COMMAND message sent by the CN to the Source RNC.
Number of unsuccessful outgoing relocation preparations per failure cause (per intra/inter
PLMN)
Receipt of a RANAP: RELOCATION PREPARATION FAILURE message sent by the CN to the Source RNC or no
response to the RANAP: RELOCATION PREPARATION message received or no response.
The cause is set in target system! And specified by 3GPP TS25.413.
Example:
UE not involved - Relocation failure in target CN/RNC or target system
Number of successful incoming relocation preparations
Transmission of a RANAP: RELOCATION REQUEST ACKNOWLEDGE message sent by the Target RNC
to the CN. 3GPP TS25.413.

C 3 6270 Mobility 002 KH PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

C 3 6270 Mobility 002 KH PDF

Uploaded by

Copyright:

Available Formats

3.

TA-TC 6270 /Version 01/Chap. 03 – Mobility 1

TA-TC 6270 /Version 01/Chap. 03 – Mobility 2

TA-TC 6270 /Version 01/Chap. 03 – Mobility 3

Cell_FACH -Cell Updates (Cell Reselection)

Cell_PCH -Cell Updates (Cell Reselection)

URA_PCH -URA Updates (Cell Reselection)

TA-TC 6270 /Version 01/Chap. 03 – Mobility 4

TA-TC 6270 /Version 01/Chap. 03 – Mobility 5

TA-TC 6270 /Version 01/Chap. 03 – Mobility 6

TA-TC 6270 /Version 01/Chap. 03 – Mobility 7

Handover SRNC Relocation required

•Inter-frequency handover (hard handover) Triggered by load, traffic

TA-TC 6270 /Version 01/Chap. 03 – Mobility 8

Backward initiated by the network

TA-TC 6270 /Version 01/Chap. 03 – Mobility 9

TA-TC 6270 /Version 01/Chap. 03 – Mobility 10

TA-TC 6270 /Version 01/Chap. 03 – Mobility 11

FACH DL RLC UMD rrcConnectionSetup

DCH UL RLC AMD rrcConnectionSetupComplete

DCH DL RLC AMD rrcMeasurementControl

DCH UL RLC AMD RRC initialDirectTransfer xxxxxx1. Intra-frequency measurements

TA-TC 6270 /Version 01/Chap. 03 – Mobility 12

TA-TC 6270 /Version 01/Chap. 03 – Mobility 13

Qantity Frequency 1 Qantity Frequency 1

CPICH Cell A CPICH Cell A

Distance, Time Distance, Time

TA-TC 6270 /Version 01/Chap. 03 – Mobility 14

InterRAT reporting events

Traffic Volume reporting triggers

Quality reporting events

TA-TC 6270 /Version 01/Chap. 03 – Mobility 15

UE internal measurement reporting events

UE positioning reporting events

TA-TC 6270 /Version 01/Chap. 03 – Mobility 16

TA-TC 6270 /Version 01/Chap. 03 – Mobility 17

TA-TC 6270 /Version 01/Chap. 03 – Mobility 18

TA-TC 6270 /Version 01/Chap. 03 – Mobility 19

NBAP: RL Setup Response

Iub Bearer Setup

UP FP: Downlink Synch.

RRC: Active Set Update (RL Addition, Deletion, Replacement)

TA-TC 6270 /Version 01/Chap. 03 – Mobility 20

RL Deletion to Active Set

RL Addition to Active Set

Attempt Success Failure Attempt Success Failure

TA-TC 6270 /Version 01/Chap. 03 – Mobility 21

No Transport or Code or Power resources in target cell

RRC: Active Set Update (RL Addition, Deletion, Replacement)

In most cases the RNC will release the RRC connection!!

TA-TC 6270 /Version 01/Chap. 03 – Mobility 22

TA-TC 6270 /Version 01/Chap. 03 – Mobility 23

Cell A Soft handover area Cell B

Active set size: 1 Active set size: 2 Active set size: 1

TA-TC 6270 /Version 01/Chap. 03 – Mobility 24

Cell based: Active set size = 1 Active set size = 2

Cell A Soft handover area

UEs, where A is best server

Active set size: 1 2 3 2 1

RAB establishment 2. RAB establishment Time

TA-TC 6270 /Version 01/Chap. 03 – Mobility 25

Active Set Size of UEs as seen by Cell / RNC

Each UE in Cell_DCH is counted once or