UMTS IRAT OptimizationGuideline

Lucent Worldwide Services
Subject:
Inter-RAT
Guideline
Handover
for
Cingular Wireless
UMTS
Optimization Date:
Deployment
April 10, 2006
in
From:
Melanie Wang
Tony Houweling
Version 1.1
Abstract
This document provides the optimization guideline for deploying Lucent inter-system
handover feature between the Radio Access Technology UMTS and GSM (a.k.a. IRAT) in
Cingular Wireless UMTS markets. It is based on the release u03.01 IRAT feature
capability as well as current IRAT deployment requirements per Cingular Wireless.
INTRODUCTION..................................................................................................................................3
IRAT HANDOVER METHODS...........................................................................................................4

2.1
UMTS-TO-GSM CELL RESELECTION............................................................................................4
2.2
UMTS-TO-GSM IRAT HANDOVER...............................................................................................5
2.2.1
CS UMTS-to-GSM Mobile-Assisted Handover........................................................................5
2.2.2
CS UMTS-to-GSM Database-Assisted Handover....................................................................8
2.2.3
PS UMTS-to-GSM Handover...................................................................................................9
2.3
GSM-TO-UMTS CELL RESELECTION..........................................................................................10
2.3.1
GSM-to-UMTS IRAT Handover.............................................................................................10
IRAT HANDOVER DEPLOYMENT RECOMMENDATION.......................................................11

3.1
3.2
3.2.1
3.2.2
3.2.3
3.3
3.4
3.4.1
3.4.2
IRAT HANDOVER OPTIMIZATION...............................................................................................23

4.1
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.3.6
4.3.7
4.3.8
4.4
BORDER CELL COVERAGE OPTIMIZATION...................................................................................23

CS IRAT HANDOVER DRIVE TEST..............................................................................................24
Entrance Criteria...................................................................................................................24
Test Equipment.......................................................................................................................24
Drive Test Cluster and Drive Route.......................................................................................24
Drive Test Procedure..............................................................................................................25
Drive Test Data Analysis........................................................................................................25
CS IRAT HANDOVER DRIVE TEST TROUBLE SHOOTING............................................................30
Failures Due to No MeasurementReport Message for e3a....................................................30
Failures Due to No Utran2GsmHOcmd Message UTRAN Issues......................................33
Failures Due to No Utran2GsmHOcmd Message Core Network Issues............................37
Failures Due to UE Reporting HOFrmUtranFail Configuration Unaccepted...................39
Failures Due to UE Reporting HOFrmUtranFail Physical Channel Failure....................39
IRAT Handover UTRAN Parameters Optimization...............................................................44
IRAT Handover Failures in Areas with No Call Drops..........................................................44
IRAT Drive Test Showing Significant GSM Originations......................................................45
PS UMTS-TO-GSM DRIVE TEST OPTIMIZATION........................................................................47
IRAT HANDOVER PERFORMANCE MONITORING.................................................................48

5.1
5.2
5.3
5.4
IRAT DESIGN RECOMMENDATIONS.............................................................................................11

UTRAN TRANSLATION PARAMETERS.........................................................................................11
Cell Reselection Parameters..................................................................................................11
UMTS-to-GSM IRAT Handover Parameters.........................................................................14
GSM Neighbor List................................................................................................................17
GSM TRANSLATION CONFIGURATION.........................................................................................19
NETWORK INTERCONNECTIVITY..................................................................................................20
PLMN.....................................................................................................................................20
LCP Procedure to Interconnect 3G and 2G MSCs................................................................21
COMPRESSED MODE PERFORMANCE MEASUREMENTS...............................................................48

RELOCATION PREPARATION PERFORMANCE MEASUREMENTS.....................................................49
IRAT HANDOVER PERFORMANCE MEASUREMENTS....................................................................50
IRAT HANDOVER MATRIX...........................................................................................................51
REFERENCES.....................................................................................................................................52
Introduction
For the existing GSM service providers, the initial UMTS deployment would typically be
limited to certain areas, e.g. metropolitan areas around large cities. Within UMTS
coverage, there may also be pockets of coverage holes due to various reasons associated
with deployment. GSM, on the other hand, provides nearly full geographic coverage and
has been comparatively well optimized. To provide seamless coverage and service to
UMTS subscribers, UMTS-to-GSM IRAT handover is considered an essential capability
for the network. Its performance is therefore a critical service indicator during initial
UMTS deployment.
This Optimization Guideline is intended to facilitate efficient IRAT handover
implementation and optimization in the field markets.
In Section 2, UMTS-to-GSM cell reselection and IRAT handover algorithms are
described to give users a high-level understanding of the functionality. Cell reselection is
entirely an UE action when it is in idle mode or in URA_PCH / Cell_FACH states and its
performance is therefore generally not captured by the network. However, it does have
impact on subscribers perceived network performance and, in u03.01 UMTS-to-GSM PS
handover is basically only supported via cell reselection. Some common IRAT handover
optimization issues such as RF coverage and GSM neighbor list would also impact cell
reselection performance. The focus of the document is nevertheless on CS UMTS-toGSM IRAT handover.
In Section 3, the recommended translation parameter values, GSM neighbor list
population, and backbone interconnectivity procedures are provided. Those are required
to ensure functional performance of IRAT handover and are considered to be the first
steps in the IRAT handover deployment and optimization process.
The typical optimization techniques are covered in Section 4. Border cell coverage
optimization should be performed based on RF design tool and/or local RF knowledge,
identifying power attenuation / antenna down-tilts to minimize pilot pollution and
overshoots. Drive test could then be used to further identifying IRAT handover
performance issues. Typical failure cases such as due RF, handover trigger point, GSM
neighbor list, backbone / network issues and their troubleshooting procedures are also
described. As a last step, if necessary, especially in areas with challenging terrain, certain
parameters/thresholds could be fine tuned to further optimize the IRAT handover
performance.
Relevant SM peg counts and KPIs should be monitored to identify potential IRAT
handover optimization hot spots after initial implementation in the market. They should
again be observed after each change / optimization step to ensure positive performance
trending. Information related to IRAT handover performance monitoring is documented
in Section 5.
IRAT Handover Methods
Lucent UMTS system supports UMTS-to-GSM cell reselection for UE in non-DCH

mode and UMTS-to-GSM IRAT handover for UE in DCH mode. The procedures and
algorithms for each are reviewed in Section 2.1 and Section 2.2 respectively. References
[1] and [2] in Section 6 have further details on the subjects. GSM-to-UMTS cell
reselection and IRAT handover are mainly controlled by the GSM network and are
described briefly here for reference purpose only. Currently, GSM-to-UMTS IRAT
handover is not enabled per deployment requirement.
2.1 UMTS-to-GSM Cell Reselection
To ensure optimal call setup performance, UE in idle mode or RRC connected mode
needs to select and continuously reselect the most appropriate cell of the available
networks based on certain priorities and radio conditions. In u03.01, the RRC connected
states relevant to cell reselection are URA_PCH and Cell_FACH states, both only
applicable to a PS connection. UTRAN broadcasts in SIB11 GSM neighbor cells and
reselection parameters in addition to UMTS neighbor cells if the cells of the GSM
network are defined in the neighbor lists of the UMTS network. This allows the UE to
reselect an appropriate neighbor cell from the GSM network when it is entering an
UMTS coverage hole in the internal network, or when it is entering the UMTS border,
approaching GSM only coverage area.
Similar to intra/inter-frequency UMTS cell reselection process, based on the broadcast
parameters. The UE starts to perform IRAT (GSM) measurements when the UMTS
quality drops below a certain level, which is the min quality level for UMTS cell
selection/reselection (QqualMin) plus a threshold (sSearchRAT) , both translatable. The
UE then performs cell ranking based on cell ranking quality criteria. The quality value
for UMTS FDD cells is measured by CPICH Ec/No or CPICH RSCP , based on
translation selection, and is the averaged received signal level for GSM cells. Basically,
the comparison between GSM and UMTS cells is always based on the received signal
level criterion (CPICH RSCP for the UMTS cells), biased with applicable offsets (GSM
cell is subtracted with qOffset, UMTS cell is added with Qhyst1). If the best cell from
this ranking is a UMTS cell and the UMTS selection criterion is set to CPICH-Ec/NO, a
second ranking of only the UMTS cells based on CPICH-E c/NO is performed and the best
cell from this ranking is chosen for reselection. If a GSM cell is ranked as the best cell,
then the UE will perform cell reselection to that GSM cell when the following cell reselection conditions are met:
The new cell is better ranked than the serving cell during a time interval
Treselection.
More than 1 second has elapsed since the UE camped on the current serving cell.
Upon cell reselection from UMTS to GSM, the UE is required to perform location /
routing area update in GSM system. If the UE has an active PDP context, it is transferred
from UMTS to GSM provided that 3G and 2G PS core networks are inter-connected. If
the UE was in Cell_FACH state, the packet session can be continued when the higher
layer protocol (e.g. TCP) performs re-transmissions.
4
2.2 UMTS-to-GSM IRAT Handover

For optimal performance and seamless voice and/or data service across UMTS and GSM
border when UE has an active RAB, Lucent UTRAN supports intra-PLMN and as well as
inter-PLMN handover from UMTS to GSM for all GSM frequency bands. Lucent CS
UMTS-to-GSM IRAT handover feature is applicable when the UE has an active CS call
or a simultaneous CS and PS (DCH or HSDPA) call. The algorithm supports mobileassisted handover (MAHO) as well as database-assisted handover (DAHO) so that
handover could be executed with or without measurements of the target GSM cells. In
case of MAHO (u2913), the handover is triggered by IRAT measurements received from
the UE. In case of DAHO (u2356a), the handover is solely performed based on network
configuration data. Both algorithms use the service based handover demand received
from the CN. However, the final decisions whether to perform handover to GSM or not
is made in the UTRAN. MAHO / DAHO algorithm can be enabled separately or together
in a cell at the same time. In the latter case, priority is given to MAHO, i.e. if both
MAHO and DAHO are active in a cell, MAHO is always preferred if it is possible.
Lucent release u03.01 does not support PS IRAT handover until load 16.70. Therefore
PS UMTS-to-GSM handover currently relies on UE performing cell reselection. PS
UMTS-to-GSM IRAT handover will be supported via Cell Change Order Lite feature
(DAHO based) in load 16.70. The full Cell Change Order feature will be available in
u03.03
2.2.1 CS UMTS-to-GSM Mobile-Assisted Handover
The advantage of MAHO is that the inter-RAT handover decision takes into account the
received signal level of the GSM neighbor cells. MAHO supports Service Handover info
provided by the CN. Upon the establishment of RRC RAB, CN may pass Service
Handover IE from MSC to UTRAN. The Service Handover value is valid throughout the
lifetime of the RAB or until changed by a RAB modification. However, the final
decision whether to trigger handover to GSM or not is made by UTRAN. The allowed
values for Service Handover are:
should: the RAB connection should be handed over to GSM as soon as
possible.
should not: the RAB should remain in UMTS as long as possible.
shall not: the RAB shall never be handed over to GSM. This means that
UTRAN shall not initiate handover to GSM for the UE unless the RABs with this
indication have first been released with the normal release procedures.
If the Service Handover information is not provided by the MSC, the Lucent UTRAN
applies the option "should not".
The preconditions for triggering MAHO are:
UMTS to GSM Handover is enabled in the SRNC;
MAHO by GSM Measurements is set to true in the strongest active set cell;
The UE supports GSM
At least one GSM neighbor is defined in the active set;
5
Compressed mode (CM) is allowed in all cells of the active set if the UE requires
CM for IRAT measurement;
The Service Handover is set to should or should not.
The Service Handover option should not is typically applied in markets where interRAT handover is only desired when the UMTS RF quality is no longer adequate, such as
entering an UMTS coverage hole / border, and the GSM network is able to offer
continuing coverage.
In this case, when a border cell, defined by translation Border Cell to GSM set to true,
is added into the active set, and the UE requires CM for IRAT measurement, the SRNC
will send a Measurement Control Message to UE to start UMTS measurement type 2D
and 2F. If the quality of the current UTRAN active set CPICH Ec/No falls below a
threshold value for time to trigger as defined by the translation UMTS to GSM HO
measurement - UMTS Quality to Activate Compressed Mode, the UE will send a
Measurement Report Message to UTRAN reporting event 2D. Upon receiving reporting
event 2D, the RNC starts compressed mode and orders the UE to start IRAT measurement
type 3A. If anytime the quality of the current UTRAN active set CPICH Ec/No is again
above a threshold value for time to trigger as defined by the translation UMTS to
GSM HO measurement - UMTS Quality to Deactivate Compressed
Mode, the UE will send a reporting event 2F to the UTRAN. Upon receiving reporting
event 2F, the RNC deactivates compressed mode and orders the UE to stop IRAT
measurement type 3A. The purpose of this is to reduce unnecessary compressed mode
operation since is has negative impact on UTRAN system capacity / performance. If the
UE does not require CM for IRAT measurement, the RNC will order the UE to start IRAT
measurement type 3A as soon as a border cell is added into the active set.
If the quality of the current active set CPICH Ec/No falls below a threshold value for
time to trigger as defined by UMTS to GSM HO measurement - UMTS Quality to
Trigger MAHO, and the quality of BCCH received signal level of one or more GSM cell is
above the threshold defined by UMTS to GSM HO measurement - GSM quality to trigger
MAHO (umts2GsmHOMeas.gsmQualityThreshold), the UE will send UTRAN a reporting
event 3A, listing the target GSM cell(s) in the order of the measured quality. Upon
receiving reporting event 3A, the RNC orders the UE to release reporting event 2D, 2F and
3A and triggers IRAT handover.
If the Service Handover is should, the RNC will immediately order the UE to start
IRAT measurement type 3C. If the quality of BCCH received signal level of one or more
GSM cell is above the threshold defined by UMTS to GSM HO measurement - GSM
quality to trigger MAHO (umts2GsmHOMeas.gsmQualityThreshold), the UE will send
UTRAN a reporting event 3C, listing the target GSM cell(s) in the order of the measured
quality. Upon receiving reporting event 3C, the RNC orders the UE to release reporting
event 3C and triggers IRAT handover.
When IRAT handover is triggered, up to top 4 GSM cells may be forwarded to 3G MSC
for Relocation Preparation: if the first cell fails handover relocation preparation and
therefore cannot be used for IRAT handover, then the next cell will be forwarded to 3G
MSC. The SRNC sends Handover From UTRAN Command message to the UE
including the GSM Handover Command message. The UE will send Handover Complete
message on the GSM reverse link after it completes the handover. When the GSM BTS
receives the message, 2G MSC will inform 3G MSC that the handover is successful and
UTRAN resource will be released. As the current UEs and GSM networks do not
support simultaneous CS and PS calls in GSM, the PS session will drop in GSM on IRAT
handover.
Figure 2 -1 shows a summary of MAHO algorithm flow diagram.
Preconditions:
- UMTS to GSM Handover is enabled in the SRNC
- The UE supports GSM
- At least one GSM neighbor cell is defined in the active set
- Compressed mode is allowed in all cells of the active set if
UE requires CM for inter-RAT measurement
- The Service Handover Criterion is not set to shall not
- In case of Service Handover is set to should not, the active
set contains a border cell
should
Service
Handover?
should not
CM required for IRAT

measurement?
no
yes
Setup
measurement 3C
Setup
measurement 2D
and 2F
Setup measurement 3A
UE sends
event 2D
Wait
Change of active Set:

pre-conditions still
fulfilled
Service Handover
changes from "should"
to "should not"
UE sends
event 3C

pre-conditions no
longer fulfilled
Wait
Update GSM
neighbour cell list in
measurement 3C
- Release
measurement 3C

pre-conditions no
longer fulfilled
- Release
measurement 2D/2F
- Exit MAHO procedure
Wait
Update GSM
neighbour cell list in
measurement 3A
Release measurement
3A

pre-conditions still
fulfilled
UE sends
event 2F
- Release
measurement 3C
- Trigger inter-RAT HO
- Release
measurement 2D, 2F
and 3A
- Trigger inter-RAT HO
UE sends
event 3A
- Release
measurement 3C
- Release
measurement 2D, 2F
and 3A

pre-conditions no
longer fulfilled
Exit MAHO
procedure
Figure 2-1: MAHO IRAT flow diagram

2.2.2 CS UMTS-to-GSM Database-Assisted Handover
Database-Assisted Handover (DAHO) supports IRAT handover without the need for the
UE to perform IRAT measurements. It has no negative impact on the UTRAN
capacity/performance as in the MAHO case when CM is required by the UE for IRAT
measurements. The DAHO handover decision is based on UE measurements of the
current UTRAN frequency and the GSM target cell is identified via database translation
mapping. When both MAHO and DAHO are applicable in the strongest cell of the active
set, MAHO will take precedence; if MAHO is enabled, and the UE requires CM for
IRAT measurements but CM is not enabled in all cells of the active set, the RNC will
apply DAHO.
The Lucent DAHO algorithm allows the operator to define up to 3 GSM target cells each
for quality (should not) and non-quality (should) based handovers. Depending on the
Service Handover option, the associated GSM target cell list is used. Every time the
active set is updated (adding, removing or replacing a link) during the soft/softer
handover algorithm procedure, the RNC checks the conditions for DAHO once DAHO is
selected. If the Service Handover option is should not, the strongest cell in the active
set has at least one GSM target cell configured for quality based DAHO and the UE
supports frequency band of at least one of these GSM target cells, the SRNC will send a
Measurement Control Message to the UE to start UMTS measurement type 2D. If the
quality of the current UTRAN active set CPICH Ec/No falls below a threshold value
for time to trigger as defined by the translation UMTS to GSM HO measurement UMTS quality to trigger DAHO (umts2GsmQTriggerDAHO), the UE will send a
Measurement Report Message to UTRAN reporting event 2D. Upon receiving reporting
event 2D, the RNC will trigger UMTS-to-GSM IRAT handover. If the Service Handover
option is should, the RNC will trigger UMTS-to-GSM IRAT handover immediately if
the strongest cell in the active set has at least one GSM target cell configured for nonquality based DAHO and the UE supports the frequency band of at least one of these
GSM target cells. Figure 2 -2 shows the DAHO flow diagram.
Once the UMTS-to-GSM handover procedure is triggered, the SRNC will send one at a
time, up to 3 potential GSM target cells from the GSM target cell list of the strongest
active set cell to the 3G MSC. Only those GSM cells whose frequency bands are
supported by the UE may be used. The first GSM cell will be selected for handover
execution if relocation preparation is successful; otherwise the next cell on the list will be
forwarded to the 3G MSC. The handoff execution procedure is the same as that
described in the MAHO method.
To ensure acceptable IRAT handover performance, the populated DAHO GSM target cell
should overlap the entire handover region.
Wait for
measurement report
Event type
1A/1B/1C
2D for IRAT
DAHO
Soft Handover algorithm executed

(NLSA identifies strongest cell and
updates and active set
Active set has been updated
IE
Service Handover
should
should not
Strongest cell has

GSM target cells for
DAHO?
No
Yes
UE supports
frequency band(s) of
the GSM cell(s)?
Strongest cell has

GSM target cells for
DAHO?
shall not
No
Yes
No
UE supports
frequency band(s) of
the GSM cell(s)?
Measurement Control
(setup/modify event 2D)
No
Measurement Control
(release event 2D)
Execute the UMTS to

GSM handover procedure
Figure 2-2: DAHO IRAT flow diagram

2.2.3 PS UMTS-to-GSM Handover
Lucent release u03.01 does not support PS IRAT handover before load 16.70. It will be
supported via feature Cell Change Order Lite in u03.01 load 16.70 and Cell Change
Order in u03.03. As the UE moves out of the UTRAN coverage area toward the
GPRS/EDGE coverage area, the PS call in Cell_DCH or HSPDA could be dragged for a
considerable time and eventually dropped due to insufficient radio quality. It is also
likely that if the radio quality does not support 64, 128, 384 kbps or HSDPA service, or if
the data application being used is TCP/IP based such as FTP and TCP flow control kicks
in as the throughput degrades significantly due to poor radio quality, the UE will be sent
to Cell_FACH state. Once the PS call is in idle or in Cell_FACH / URA_PCH states, the
UE could switch from UMTS to GSM autonomously through cell reselection procedure
described in Section 2.1. This process could take 30secs or even longer, depending on
UE behavior and neighbor cell info.
When the feature Cell Change Order is available, similar to CS IRAT handover, the PS
IRAT handover will also be triggered by quality measurements and the GSM target cell is
determined based on DAHO or MAHO (Cell Change Order Lite in load 16.70 supports
DAHO only). In case of MAHO, the UE performs measurements of the current UMTS
frequency, and if the quality gets below a certain threshold, IRAT measurements of GSM
target cells may be started and the best GSM cell is selected for Cell Change Order. The
handover interruption is typically below 8 seconds on the RRC level.
2.3 GSM-to-UMTS Cell Reselection
Cell reselection by an idle mode UE from a GSM cell to an UMTS cell is entirely
controlled by the GSM network parameters. The GSM network similarly broadcasts
UMTS neighbor cells and cell reselection parameters in addition to GSM neighbor cells.
The UE cell ranking is again based on UE performing IRAT measurement and the
received signal level from the cells. The UE will perform cell reselection to an UMTS
cell if the measured Ec/No value of the UMTS cell meets GSM-to-UMTS cell reselection
criteria.
When the UE reselects to a UMTS cell, it will perform location and routing area update
in UMTS. If the UE had an active PDP context in GSM then it is transferred from GSM
to UTRAN provided that 2G and 3G PS core networks are inter-connected.
2.3.1 GSM-to-UMTS IRAT Handover
GSM-to-UMTS IRAT handover decision is made within GSM network. GSM broadcasts
UMTS neighbor cells for UE measurement. Handover can be enabled/disabled per target
UMTS cell. Since currently GSM-to-UMTS IRAT handover is not enabled in Cingular
Wireless deployment markets, therefore not discussed in detail in this document.
10
IRAT Handover Deployment Recommendation
In this section, we present IRAT handover design recommendations and associated

translation configuration recommendations. In areas such as UMTS coverage border /
coverage hole, a right set of cells need to be identified for UMTS-to-GSM IRAT
handover configuration to ensure call quality and to prevent premature or delayed
handover, or sneak outs. Also, the functional capability of IRAT handover depends on
the proper configuration of relevant UTRAN translation parameters, GSM neighbor lists,
as well as appropriate facility / interconnectivity growth in the backbone / core network.
It is critical to ensure that the recommended values for the required translations are
populated, best choice GSM neighbors are entered and interconnectivity procedures are
followed before any optimization attempt on the IRAT handover performance.
3.1 IRAT Design Recommendations
As preferred by Cingular Wireless, in the initial stage of UMTS deployment, IRAT is
enabled and configured for all cells in the network for quality-based handover using
MAHO algorithm. This is possibly due to the fact that the UMTS coverage may not have
been fully build out and optimized. It may be more desirable to allow IRAT handover in
the interiors of the UMTS network in order to maintain subscriber perceived network
coverage and performance. As the UMTS deployment matures, having IRAT HO
deployed in the interior network may no longer offer any benefits. On the other hand, it
may impact UMTS traffic loading or performance due to un-necessary CM IRAT
measurements or handovers triggers. We may revisit the current design recommendation
in the future.
3.2 UTRAN Translation Parameters
With the current IRAT design recommendation, every UMTS cell is defined as a border
cell to GSM. Therefore, both interior and border UMTS cells should have the required
UMTS-to-GSM cell reselection and IRAT handover translations / GSM neighbor lists
configured on UTRAN OMC-UPS. The database population should follow the NDP
process. The procedures for the application of RF template / RF tools used for NDP can
be
found
at
the
following
web
link:
http://narndp2.ih.lucent.com:7779/pls/portal/ndpproject64.A_File.show
The initial NDP RF Template used to build database entries may not have all the updated
values. It is recommended that the relevant translations be dumped and compared against
current golden values before optimization. Procedure for Parameter Audit can be
found in reference [4]. Diff marked the parameters should be verified and corrected if
there is no market specific reasons for the deviations.
3.2.1 Cell Reselection Parameters
cellSelAndResQualMeas
Object: LRNC.LNodeB.Lcell
11
Definition: Choice of measurement (CPICH Ec/No or CPICH RSCP) to use as quality

measure for FDD cells. This is sent in SIB11/12. Both occurrences should have the same
value.
Range: CPICH Ec/No, CPICH RSCP, NA
Recommended Setting: CPICH EcNo
outGSMAdjCells.qOffset
Definition: An offset added to the measurement quantity for the GSM neighbor cell, used
for UMTS to GSM cell reselection.
Range: -50 50 dB
Recommended Setting: 0
sIB3EnableSIB4Indicator
Definition: Indicates whether SIB4 information is broadcasted.
Recommended Setting: FALSE
sIB3QqualMin
Definition: Minimum required CPCH Ec/No quality level a cell must have to be
considered for selection/reselection in idle mode.
Range: -24 0 dB
Recommended Setting: -19
sIB4QqualMin
Definition: Minimum required quality level, if sIB3EnableSIB4Indicator = TRUE
(activation of SIB4 for connected mode.)
Range: -24 ... 0 dB
sIB3QrxlevMin
Definition: Minimum required received level (in RSCP) a cell must have to be considered
for selection/reselection in idle mode.
Range: -115 -25 dBm, 2 dBm steps
sIB4QrxlevMin
Definition: Minimum required received level (in RSCP) a cell must have to be considered
for selection/reselection in idle mode. if sIB3EnableSIB4Indicator = TRUE (activation of
SIB4 for connected mode.)
12
QRXLEVMIN
Object: OMCU.EXTERNALS.EXTERNALGSMCELL
Definition: Minimum receive-quality level that is needed in the neighboring GSM cell.
sIB3RAT.rATId
Definition: Indicates the RAT type
Recommended Setting: rATIDGSM
sIB4RAT.rATId
Definition: Indicates the RAT type
Recommended Setting: rATIDGSM
sIB3RAT.ssearchRAT
Definition: A threshold to start GSM measurements for reselection (SsearchRAT).
Range: -32 20 dB, 2 dB steps
sIB4RAT.ssearchRAT
Definition: A threshold to start GSM measurements for reselection (SsearchRAT), if
sIB3EnableSIB4Indicator = TRUE (activation of SIB4 for connected mode).
Range: -32 20 dB, 2dB steps
sIB3Qhyst1
Definition: Hysteresis value prioritizing the ranking of the serving cell if CPICH RSCP is
used as a quality measure. Value is only applied for the hysteresis toward GSM cells if
the recommended Ec/No quality measure is used for reselection between UTRAN cells.
Range: 0 40 dB, 2 dB steps
sIB4Qhyst1
Definition: Hysteresis value prioritizing the ranking of the serving cell if CPICH RSCP is
used as a quality measure. Value is only applied for the hysteresis toward GSM cells if
the recommended Ec/No quality measure is used for reselection between UTRAN cells,
when isIB3EnableSIB4Indicator = TRUE (activation of SIB4 for connected mode).
13
sIB3Qhyst2
Definition: Hysteresis value prioritizing the ranking of the serving cell if CPICH Ec/No is
used as a quality measure.
Range: 0 40dB, 2 dB steps
sIB4Qhyst2
Definition: Hysteresis value prioritizing the ranking of the serving cell if CPICH Ec/No is
used as a quality measure, when sIB3EnableSIB4Indicator = TRUE (activation of SIB4
for connected mode).
sIB3Treselection
Definition: Time interval for reselection
Range: 0 ... 31 sec
sIB4Treselection
Definition: Time interval for reselection, if sIB3EnableSIB4Indicator = TRUE (activation
of SIB4 for connected mode).
Range: 0 ... 31 sec
BSIC Verification
Definition: The BSIC Verification Required parameter defines whether, in case of
MAHO, the UE has to verify the BSIC of the GSM frequency in order to recognize the
GSM cell as valid for handover.
Range: True / False
Recommended Setting: True
3.2.2 UMTS-to-GSM IRAT Handover Parameters
umtsToGsmHandover
Object: LRNC
Definition: The parameter enables/disables the UMTS to GSM handover feature per
RNC.
Range: True / False / NA
Recommended Setting: TRUE
14
mahoByGsmMeasurements
Definition: This parameter enables/disables the mobile-assisted handover algorithm
(MAHO) for triggering the UMTS-to-GSM handover procedure.
borderCellToGsm
Object: LRNC.LNodeB.Lcell, LRNC.FddExCell
Definition: Marks a cell as a border cell of the UMTS network to a GSM network.
compressedModeInterRat
Definition: The parameter defines whether the use of the compressed mode is allowed in
the cell for inter-RAT measurements.
GsmToUmtsHandover
Definition: The parameter enables/disables the GSM to UMTS handover feature on a per
cell basis.
Recommended Setting: FALSE
umts2GsmQActCM2D.threshold
Definition: UMTS CPICH Ec/No quality threshold for reporting event 2d (CM
activation.)
Range: -24 ... 0 dB
umts2GsmQActCM2D.timetotrigger
Definition: Specifies the time interval for which the UMTS quality threshold condition
must be true before the UE sends an event 2d measurement report to the UTRAN.
Range: enum msec
umts2GsmQDeactCM2F.threshold
Definition: UMTS CPICH Ec/No quality threshold for reporting event 2f (CM
deactivation.)
Range: -24 ... 0 dB
15

umts2GsmQDeactCM2F.timetotrigger
must be true before the UE sends an event 2f measurement report to the UTRAN.
Range: enum msec
umts2GsmQTriggerMAHO.threshold
Definition: UMTS CPICH Ec/No quality threshold for reporting event 3a (IRAT
handover trigger.)
Range: -24 ... 0 dB
umts2GsmQTriggerMAHO.timetotrigger
must be true before the UE sends an event 3a measurement report to the UTRAN.
Range: enum msec
umts2GsmQTriggerMAHO.weight
Definition: Specifies weighting between the strongest link and the remaining active links
for computing the quality of the UMTS system.
Range: 0.0 up to 2.0, 0.1 steps, NA
umts2GsmHOMeas.combinedGsmNeighborListSize
Object: LRNC
Definition: Defines the maximum number of GSM neighbor cells related to the active set, which
should be sent to the UE for reporting event 3a /3c (IRAT handover trigger.)
Range: 1-32
umts2GsmHOMeas.gsmQualityThreshold
Object: LRNC
Definition: GSM quality threshold for reporting event 3a /3c.
Range: -115 ... 0 dB
umts2GsmHOmeas.gsmfiltercoefficient
Object: LRNC
16
Definition: Defines a low pass filter for the GSM measurements. Used for event 3A and
event 3C measurements.
Range: coeff_0, coeff_1, coeff_9, coeff_11, coeff_13, coeff_15, coeff_17, coeff_19,
NA
Recommended Setting: coeff_3
maxUlTxPwr
Definition: The maximum amount of power that the UE is allowed to use on the
GSM Random Access Channel (RACH).
Range: -50 to 33 dBm
Recommended Setting: 33 (GSM_850), 30 (GSM_1900)
3.2.3 GSM Neighbor List
GSM neighbor list is generated for each UMTS cell by Cingular Wireless and needs to be
entered on UTRAN OMC-U as part of the NDP procedure as well. The GsmExtCell
Table on OMC-U should contain all the GSM neighbor info for all the cells on the RNC.
The outGSMAdjCells field under LRNC.LNodeB.Lcell.adjacentCell should contain
GSM neighbor list for the specific LNodeB.Lcell as shown in Figure 3 -3.
GSM Neighbor list
Figure 3-3: An Example of GSM Neighbor List Entry

The outGSMAdjCells has the following fields for each neighbor list entry:
enableBroadcast, refCell, qOffset, enableMAHO and cioForHO. refCell is the RDN of
the GSM cell in the GsmExtCell list. When the GSM neighbor entry is specified as
IsCrsMAHO, both enableBroadcast and enableMAHO would bet set to true, which
17
means that the GSM cell may be used for both cell reselection and MAHO IRAT HO; it is
sent out in both sIB11 and the Measurement Control messages. If the GSM neighbor
entry is specified as IsCrsOnly, only enableBroadcast would be set to true, which
means that the GSM neighbor cell is for cell reselection only; it is sent out in sIB11 but
not in the Measurement Control message sent to the UE for IRAT HO consideration. If
the GSM neighbor entry is specified as MAHOOnly, only enableMAHO would be set to
true, which means that the GSM cell is used for MAHO IRAT HO only; it is sent out in
the Measurement Control message. In general, all GSM neighbors should be
IsCrsMAHO.
Also note that in the current u03.01 release, there is a limit of up to 32 UMTS cells (in
coming UTRAN neighbors per GsmExtCell) that could have the same GSM cell as a
neighbor per OMC-U. If the incoming UTRAN cells exceed this limit when adding a
GSM neighbor entry or running CLI script for UMTS-to-GSM relation, Error Code
0200: Command failed. Add GSM Relation Use Case failed with description of
Consistency Check Failure would occur. A less critical GSM neighbor entry would need
to be deleted in order for this same GSM cell to be added to a more critical GSM
neighbor list entry. An enhancement in u3.03 will allow the limit to increase to 999
incoming URTAN cells.
For markets that have co-located 850 blue (AT&T) / orange (CW), and/or co-located 850
orange and 1900 orange GSM networks, it may be redundant to have all of the co-located
cells entered as GSM neighbors since the neighbor list is size limited. In that case, the
GSM cell that supports Edge service, and/or has better coverage (typically 850-band cell
has better coverage than co-located 1900 cell if all else being the same) would be the
preferred choice.
Certain GSM network activities such as frequency retune, new cell addition, re-home,
etc., will also result in GSM neighbor info / neighbor list changes in the UMTS network
and therefore need to be coordinated with UMTS operation to ensure that they are
promptly updated in the UMTS network. GSM network retunes / cell additions will often
require substantial changes to GsmExtCell or outGSMAdjCells list. Any such updates
that require more than just a few manual changes on the OMC-U should in general follow
the NDP procedure for Add GSM Neighbor Relation to RF Template under the RF tool
suite. When GSM system retune only involves frequency plan changes but no cell
changes, the following awk script may also be used instead of the NDP RF tool, and is
considered by field engineers to be an efficient alternative.
The awk script is designed to generate the OMC CLI script used to modify the LAC,
BCCH, BCC and NCC parameters in GsmExtCell. Note that BCC and NCC are the two
parts of a BSIC. The script can be copied and pasted as follows:
# USAGE: awk -f changeGsmLAC_BCCH_BSIC.awk <input_file> > <omccli_script>
# <input_file> consists of 6 columns: <OMC_U#>,<GsmExtCell>,<LAC>,<BCCH>,<BCC>,<NCC>
# CLI>
list-externalgsmcell:;
# Author: Mateen Hussain
BEGIN {FS=","};
{
18
printf
"modifyextgsmcellexternalgsmcell:name=\"OMCU="$1",EXTERNALS=1,EXTERNALGSMCELL="$2"\",lAC="$3",N
CC="$6",BCC="$5",BCCHFREQUENCY="$4";\n";
}
If any of the parameters is not changing, the original value should be used in the input csv
file. Below is an example of the input csv file format and the output OMC CLI script
generated by the above awk file:
Input example:
2
20308
41022
161
Output example:
Modifyextgsmcellexternalgsmcell:name="OMCU=2,EXTERNALS=1,EXTERNALGSMCELL=20308",
lAC=41022,NCC=2,BCC=4,BCCHFREQUENCY=161;
The awk file may also be modified to fit certain variations of the above scenario. For
example, if only LAC needs to be updated in the GsmExtCell, the awk script could be
modified as:
# USAGE: awk -f changeGsmLAC.awk <input_file> > <omccli_script>
# <input_file> consists of 3 columns: <OMC_U#>,<GsmExtCell>,<LAC>
# CLI>
list-externalgsmcell:;
BEGIN {FS=","};
{
printf
"modifyextgsmcellexternalgsmcell:name=\"OMCU="$1",EXTERNALS=1,EXTERNALGSMCELL="$2"\",lAC=
"$3";\n";
3.3 GSM Translation Configuration

Relevant GSM parameters and UMTS neighbor list need to be entered on the GSM
network to support GSM-to-UMTS cell reselection / IRAT handover. The exact GSM
database locations of those fields are dependent on GSM vendor implementation and the
GSM database population is handled entirely by Cingular Wireless, and therefore not
discussed in details in this document. Here we only provide a summary of key
parameters that should be present in the GSM System Information Type 2quater message
received over the air in the drive test log. Please refer to section 4.3.8 for additional
trouble shooting details. Note that GSM-UMTS IRAT handover is currently not enabled.
Define UMTS Neighbor Cells for the GSM Cells
The SI2quater message should contain 3G Neighbor Cell Description fields with a list of
non-zero UMTS cells if UMTS neighbor cells are properly defined in the GSM database.
Define GSM-to-UMTS Cell Reselection Parameters for Idle Mode
The SI2quater message should contain 3G Measurement Parameters Description for the
following parameters:
19
1. Qsearch_I
This parameter provides the 2G signal level at which the UE should start searching
for 3G cells.
Default value 7 means always, i.e. 3G cells are searched independently of the 2G
signal level.
2. FDD_Qoffset
This parameter applies an offset to RLC_A (the received level averages).
Value 0 means that a 3G cell should be selected if it is suitable (see FDD_Qmin)
independently of the 2G signal level.
3. FDD_Qmin
This is the minimum Ec/No threshold for Utran FDD cell re-selection. This parameter
should be set to a value that ensures a suitable minimum UMTS quality.
e.g. value 5 (-10 dB), 7 (-12 dB). If a lower dB value is chosen then this might cause
pingponging between UMTS and GSM.
Define GSM-to-UMTS Cell Reselection Parameters for Connected Mode
The SI2quater message should contain 3G Measurement Parameters Description for the
following parameters:
4. Qsearch_C
This parameter provides the 2G signal level at which the UE should start searching
for 3G cells.
Default value 7 means always, this means that 3G cells are searched independently
of the 2G signal level.
5. FDD_MULTIRAT_REPORTING
Number of Utran FDD cells that should be included in the MeasurementReport
message. This parameter has to be set to 1 or higher.
6. 3G_SEARCH_PRIO
Indicates if 3G cells may be searched when BSIC decoding is required.
Should be set to value 1, i.e. 3G cell should be searched even if BSIC decoding is
required.
3.4 Network Interconnectivity

Here we discuss some common backbone configuration and interconnectivity tasks that
must be carried out at the 3G core network to support IRAT handover functionality, such
as IMT trunk growth, SS7 routing entries, etc., on 3G MSC for CS connectivity; and 3G
SGSN entries for PS connectivity.
3.4.1
PLMN
If the UMTS and GSM networks have different PLMNs , the Equivalent PLMN under IMS
Wireless configuration needs to be set. I.e. for reselection from UMTS to GSM, the 3G MSC
20
has to specify the GSM PLMN as the equivalent PLMN. Likewise, for reselection from GSM to
UMTS, the 2G MSC has to specify the UMTS PLMN as equivalent PLMN.
3.4.2 LCP Procedure to Interconnect 3G and 2G MSCs

Below is a brief description of LCP update procedure to interconnect 3G and 2G MSCs.
The procedure also applies in case of a GSM re-home. In order to complete the
necessary updates to the Lucent Control Platform to associate another GSM switch for
handover and roaming, the following information is required from the customer:
Inter-MSC Trunk (IMT) information

Far end Point Code
Bearer Channel CICs
SPAN connectivity
MSRN (Roaming Number) range
Mobile Handover Number range
Location Area Codes (LAC) that are bordering UMTS MSC
MCC/MNC to be handled by the new MSC
All data must be reviewed the night before the implementation between concerned parties
to ensure the accuracy and correct understanding. Tasks that need to be performed during
the implementation of the LCP update are summarized below. More details can be found
in reference [3].
1. Grow Route/Destination for IMT trunk group to new MSC:
Under System View Component Group SS7 DS Route/Destination, grow
in Pointcode for the new MSC.
2. Grow Channel Group for IMT trunk group to new MSC:
Under Channel Groups SS7 Channel Group, add new Channel Group with
appropriate Incoming/Outgoing Digit Tables and Route Tables.
3. Add Bearer Channels to the IMT Channel Group:
Under Channel Groups SS7 Channel Group new channel group name, add
bearer channels.
4. Grow in RouteList for IMT trunk group:
Under RouteList Route List, add a Route List to point to the new IMT Channel
Group.
5. Grow in Route for MSRN pointing to IMT trunk group:
Under Route Table Route Tables route table name: update the appropriate
Route Table to add information for the MSRN and Mobile Handover Number
6. Grow in Route for Mobile Handover Number pointing to IMT trunk group:
21
Following step 5, Under Route Table Attributes: Route List should point to the
new IMT Trunk Group.
7. Grow in Digit Table for MSRN range:
Under Digit Tables Incoming Digit Tables table name: update Digit Table to
add analysis for MSRN.
8. Grow in Digit Table for Mobile Handover Number Range:
Following step 7, update Digit Table to add analysis for Mobile Handover
Number. Note that when adding the handover numbers to the digit tables for 3G
to 2G handover (the HO number is routed to 2G MSC), the number should be
provisioned with the digit table Operation field set to Translation. If the
handover number to be provisioned in the digit table is for 2G to 3G handover
(the HO number is routed to 3G MSC), the digit table Operation field should to
set to Local HO Translation. Also, under Incoming Digit Table Attributes: for
Cingular, if the MSRN and Mobile Handover are 1+ dialing (i.e. 1-NXX-NPAxxxx), then ensure that the Nature of Address is International Number, it won't
work if it is set to NATIONAL NUMBER when 1+ numbers (1-xxx-xxx-xxxx) is
used.
9. Associate LAC to MSC:
Under IMS MAP Tables LAC to MSC SCCP GTT WLGTMSC: associate
the new LACs to the MSC by adding entries to the MSC MAP table. The MSC
SCCP GTT Digits are provided by the operator.
Note: LAC to MSC SCCP GTT might be referred to as MSC E.164 address.
10. Associate LAC to VLR:
Under IMS MAP Tables LAC to VLR SCCP GTT Digits WLGTVLR:
associate the LACs to the VLR by adding entries to the VLR Map Table. Add
entries for all MCC/MNC/LAC combinations that will be supported by the new
MSC.
Step 1 ~ 4 can be skipped if theres no need for IMT trunk growth. Step 9 and 10 are
required to be executed for each MCC/MNC/LAC combination.
22
IRAT Handover Optimization
4.1 Border Cell Coverage Optimization

During the initial UMTS deployment, optimization efforts have been in general focused
on the internal UMTS coverage. It is possible that some border cells have yet been
optimized. Many of the IRAT handover failures seen in the field could be attributed to
border cell optimization issues. It is recommended that before performing drive test
optimization, efforts should be made first to optimize the border cell coverage in
conjunction with Cingular design engineer based on design tool and/or local engineering
knowledge of the terrain propagation. If necessary, appropriate antenna downtilt / power
attenuation should be applied and GSM neighbor list be updated.
Figure 4 -4 illustrates some of the common border cell optimization scenarios. A typical
non-optimized UMTS border cell transmits at nominal power with zero antenna downtilt.
Its CPICH could reach far beyond the desired coverage under certain terrain condition as
cell A in the example. An idle UE with dual UMTS and GSM capability could camp on
cell A at cell D location when it is otherwise expected to find GSM only. During call
origination / termination, RAB assignment may fail due to GSM interference; or call may
drop shortly after RAB establishment. An existing CS call could also drive far beyond
the expected IRAT handover region and result in poor handover performance or drop call
because the GSM cells in the IRAT neighbor list are no longer optimal candidates.
Non-optimized border cells could also cause pilot pollution in the border region,
degrading key performance metrics and border cell capacity. One may also need to
watch for any first or second tier interior cells (e.g. cell C in the example) overshooting
into the border region that were overlooked during the interior network optimization.
23
Overshoot from cell A. Idle UE will most likely

camp on cell A, possibly increasing orig/term
RAB assignment failures. UE on cell_DCH
could drag well beyond IRAT HO region,
causing increased RAB drop due to IRAT HO
failures. Recommend: downtilt or power
attenuation.
IRAT HO Region
Non-optimized border cell could

also cause pilot pollution in the
border region. Also check for any
overshooting from an interior cell
C
A
GSM only cells

UMTS interior cells
UMTS border cells
Figure 4-4: Examples of Border Cell Optimization Concerns
4.2
CS IRAT Handover Drive Test
4.2.1 Entrance Criteria

UMTS and GSM coverage and performance are optimized.
4.2.2 Test Equipment
IRAT handover optimization requires the same test equipment used for UMTS
optimization, plus the GSM scanners for 850 MHz and 1900 MHz bands. The typical test
equipment used by field deployment is the Agilent Wireless Solutions E6474A (or
equivalent). Alternatively, Ericsson TEMS or Qualcomm MDM may also be used,
especially for troubleshooting drive test. RF engineer should be familiar with the
configuration / operation of the Agilent equipment and know how to obtain information
such as receive pilot Ec/No, BLER, etc, for analysis.
4.2.3 Drive Test Cluster and Drive Route
For Cingular Wireless deployment, IRAT drive test is performed for both interior and
border clusters since MAHO IRAT handover is enabled everywhere. Ideally the border
24
cluster should consist of approximately 6-8 border cells and 12-16 interior cells. Drive
route should last at least 2-3 hours and include major highways as well as side streets in a
crisscross pattern. Drive route for the border cluster should extend sufficiently into the
UMTS-to-GSM only region to ensure adequate IRAT handover samples. Cluster drive
routes should also have enough overlap to ensure acceptable performance between
clusters.
4.2.4 Drive Test Procedure
For general IRAT optimization, origination calls could be used for drive test purpose.
The following is the common drive test procedure:
1. Move the test van to the start point of the drive test route. Ensure UE is set to
automatic mode, and the acquisition sequence has WCDMA first.
2. Start the UE data logging.
3. At the starting point, establish CS voice (UE to UE or UE to PSTN) call. Ensure the
call is on UMTS. The origination call pattern could be set to 10 seconds call setup
time, 40 seconds call duration, 10 seconds call tear down time.
4. Document any notable observations and anomalies especially the ones associated
with failures along the drive routes on the drive test log where necessary.
5. Drive towards the end of the route.
6. Stop data collection and save the log files. Record the log filenames on the drive test
log.
7. Return any modified parameters to their original values.
4.2.5 Drive Test Data Analysis
The UE log files (*.sd5 files) from each drive test should be processed by the RF
engineer using Lucent LDAT 3G drive test post processing tool for UMTS. A typical
IRAT analysis plot is shown in Figure 4 -5. The CPICH Ec/Io Max Finger map plot
indicates UTRAN RF condition with overlay IRAT locations for the test cluster.
Relevant IRAT performance statistics such as total number of calls, 2d/3a events, IRAT
HO commands, successes, and failures could also be summarized in the Overlay legend
window. Based on the result, the RF engineer could further investigate individual IRAT
performance by analyzing the downlink BLER, power measurement, UMTS / GSM
scanner plots, L3 message logs etc, generated by the LDAT3G tool.
25
Figure 4-5: An example of IRAT handover analysis plot in LDAT3G

The example below illustrates the expected L3 message sequences from a successful CS
MAHO IRAT HO. Since MAHO IRAT handover is currently enabled and configured in
all cells, after call setup complete (UE sends RBSetupComplete), UTRAN will send a
MeasurementControl (MC) message that contains event 2d/2f thresholds to setup UE
event 2d/2f measurement and report. If 2d condition is met, the UE will send a
MeasurementReport message reporting event 2d. Upon receiving the 1st 2d report,
UTRAN will send RBReconfig message to the UE containing timing gap parameters for
CM configuration, followed by a MeasurementControl for Compressed Mode Order
containing IRAT neighbor list and event 3a thresholds to setup UE event 3a measurement
and report. Note that the interRATCellID index for the IRAT neighbor list may not be
necessarily consecutive and may skip a few numbers. UTRAN will update IRAT
neighbor list if necessary as the UE moves from cell to cell. If 3a condition is met, the
UE will send a MeasurementReport message reporting event 3a containing the
interRATCellID index for the GSM cell(s), e.g. bsicReported verifiedBSIC : 12 in the
e3a MeasurementReport message indicates that the GSM cell reported corresponds to the
one in the IRAT neighbor list with index number 12. Upon receiving event 3a report,
UTRAN will send MeasurementControl messages to deactivate CM and release e3a
reporting. UTRAN will then send Utran2GsmHOcmd for UE to perform hard handover
to GSM. The UE will send a Handover Complete message on the GSM uplink once it
has acquired the GSM on the downlink.
26
Time Stamp
10:02:35.298 PM
Message Type
RRC SigMsg
Message Name
UL CCCH:RRCConnRequest
Key Information / Comments

Originating Conversational Call
10:02:36.492 PM
RRC SigMsg
UL CCCH:RRCConnRequest
Originating Conversational Call
10:02:37.248 PM
RRC SigMsg
DL CCCH:RRCConnSetup
Addressed To Own UE; RNTI=50183
10:02:37.358 PM
RRC SigMsg
UL DCCH:RRCSetupComplete
10:02:37.362 PM
NAS SigMsg
UL MM CM Service Request
10:02:37.365 PM
RRC SigMsg
UL DCCH:InitialDirectTransfer
10:02:37.474 PM
RRC SigMsg
UL DCCH:MeasReport
10:02:38.024 PM
RRC SigMsg
DL DCCH:MeasurementCtrl
10:02:38.124 PM
RRC SigMsg
DL DCCH:SecurityModeCmd
10:02:38.126 PM
RRC SigMsg
UL DCCH:SecurityModeComplete
10:02:38.346 PM
NAS SigMsg
UL CC Setup
10:02:38.349 PM
RRC SigMsg
UL DCCH:ULDirectTransfer
10:02:38.465 PM
RRC SigMsg
DL DCCH:DLDirectTransfer
10:02:38.467 PM
NAS SigMsg
DL MM TMSI Reallocation Command
10:02:38.471 PM
NAS SigMsg
UL MM TMSI Reallocation Complete
10:02:38.473 PM
RRC SigMsg
UL DCCH:ULDirectTransfer
10:02:38.745 PM
RRC SigMsg
DL DCCH:DLDirectTransfer
10:02:38.747 PM
NAS SigMsg
DL CC Call Proceeding
10:02:39.215 PM
RRC SigMsg
DL DCCH:RBSetup
10:02:39.680 PM
RRC SigMsg
UL DCCH:RBSetupComplete
10:02:39.897 PM
RRC SigMsg
10:02:40.017 PM
RRC SigMsg
Event 2d, 2f thresholds
10:03:06.996 PM
10:03:07.236 PM
10:03:07.441 PM
10:03:07.542 PM
10:03:07.572 PM
10:03:08.012 PM
10:03:08.104 PM
10:03:08.115 PM
10:03:08.368 PM
10:03:09.113 PM
10:03:09.256 PM
10:03:09.266 PM
10:03:09.609 PM
10:03:09.871 PM
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
UL DCCH:MeasReport
UL DCCH:MeasReport
DL DCCH:ActiveSetUpdate
UL DCCH:ASUpdateComp
UL DCCH:MeasReport
UL DCCH:MeasReport
UL DCCH:MeasReport
EventID=e1a, PSC1=213
10:03:10.170 PM
RRC SigMsg
DL DCCH:RBReconfign
setting up config parameters for CM
10:03:10.236 PM
10:03:10.591 PM
RRC SigMsg
RRC SigMsg
UL DCCH:RBReconfComp
10:03:13.154 PM
10:03:13.528 PM
10:03:13.551 PM
10:03:14.447 PM
10:03:14.449 PM
10:03:17.481 PM
10:03:17.750 PM
10:03:17.831 PM
10:03:17.854 PM
10:03:18.479 PM
10:03:18.688 PM
10:03:18.817 PM
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
UL DCCH:MeasReport
UL DCCH:MeasReport
UL DCCH:MeasReport
TMSI Reallocation Command
Call Proceeding
Add PSC213
EventID=e1b, PSC1=213
Remove PSC213
Remove PSC197
EventID=e2d, 1st time reporting e2d,

trigger for CM
Compress mode order, IRAT neighbor

list
Add PSC157
update IRAT neighbor list

Add PSC189
update IRAT neighbor list
27
10:03:19.493 PM
10:03:20.184 PM
10:03:20.639 PM
10:03:20.662 PM
10:03:21.201 PM
10:03:21.771 PM
10:03:22.039 PM
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
RRC SigMsg
UL DCCH:MeasReport
UL DCCH:MeasReport
UL DCCH:MeasReport
EventID=e2d
Add PSC501
10:03:22.041 PM
RRC SigMsg
release 3a (measurement identity 7)
10:03:22.954 PM
10:03:23.381 PM
10:03:23.599 PM
10:03:23.601 PM
RRC SigMsg
RRC SigMsg
GSM L3 SD5
GSM L3 SD5
UL DCCH:MeasReport
DL DCCH:Utran2GsmHOcmd
DL RRM Physical Information
UL RRM Handover Complete
IRAT handover command
10:03:23.680 PM
10:03:23.791 PM
GSM L3 SD5
RRC RrcState
DL RRM Physical Information

WCDMA RRC States
EventID=e3a
release CM (measurement identity 3)
IRAT handover to GSM successful
Disconnected(or Idle)
One may also notice that the e2d and e2f thresholds sent to the UE in the
MeasurementControl
message
may
not
be
the
same
as
the
umts2GsmQActCM2D.threshold / umts2GSMQDeactCM2F.threshold translation values.
For example, when translations are set to umts2GsmQActCM2D.threshold = -13;
umts2GsmQDeactCM2F.threshold = -11, the threshold values sent in the message are
shown below in bold:
value DL-DCCH-Message ::=
{
integrityCheckInfo
{
messageAuthenticationCode '01011100 01001011 11010101 01000000'B,
rrc-MessageSequenceNumber 3
},
message measurementControl : r3 :
{
measurementControl-r3
{
rrc-TransactionIdentifier 0,
measurementIdentity 7,
measurementCommand setup : interFrequencyMeasurement :
{
interFreqCellInfoList
{
},
interFreqMeasQuantity
{
reportingCriteria interFreqReportingCriteria :
{
filterCoefficient fc4,
modeSpecificInfo fdd :
{
freqQualityEstimateQuantity-FDD cpich-Ec-N0
}
}
},
interFreqReportingQuantity
{
utra-Carrier-RSSI FALSE,
frequencyQualityEstimate FALSE,
nonFreqRelatedQuantities
{
dummy type1,
cellIdentity-reportingIndicator FALSE,
cellSynchronisationInfoReportingIndicator FALSE,
28
modeSpecificInfo fdd :
{
cpich-Ec-N0-reportingIndicator FALSE,
cpich-RSCP-reportingIndicator FALSE,
pathloss-reportingIndicator FALSE
}
}
},
reportCriteria interFreqReportingCriteria :
{
interFreqEventList
{
event2d :
{
usedFreqThreshold -12,
usedFreqW 10,
hysteresis 4,
timeToTrigger tt320
},
event2f :
{
usedFreqThreshold -12,
usedFreqW 10,
hysteresis 4,
timeToTrigger ttt640
}
}
}
},
measurementReportingMode
{
measurementReportTransferMode acknowledgedModeRLC,
periodicalOrEventTrigger eventTrigger
}
}
}
}
This is expected because the values sent in this message for e2d and e2f are derived
values based on the translations using the following formula:
event2d: hysteresis
= umts2GsmQDeactCM2F.threshold - umts2GsmQActCM2D.threshold
= (-11) (-13)
= 2dB
= 4 (0.5dB steps)
event2d: threshold
= umts2GsmQActCM2D.threshold + event2d: hysteresis / 2

= (-13) + 2 / 2
= -12dB
event2f: hysteresis
= umts2GsmQDeactCM2F.threshold - umts2GsmQActCM2D.threshold
= (-11) (-13)
= 2dB
= 4 (0.5dB steps)
event2f: threshold
= umts2GsmQDeactCM2F.threshold - event2d: hysteresis / 2

= (-11) - 2 / 2
= -12dB
29
Moreover, if the translation values for umts2GsmQActCM2D.threshold (e.g. 13) and

umts2GsmQDeactCM2F.threshold (e.g. 10) result in an odd value for hystersis (e.g. 3),
e2d / e2f thresholds would become -13 + 3/2 = -11.5 and -10 3/2 = -11.5 respectively.
In this case, value 11.5 would be rounded down by RNC to 12 since only integer
values are allowed. The UE then calculates umts2GsmQActCM2D.threshold and
umts2GsmQDeactCM2F.threshold values based on the parameters in the
MeasurementControl message using the following formula:
umts2GsmQActCM2D.threshold = event2d: threshold - (event2d: hysteresis * 0.5dB)/2
umts2GsmQDeactCM2F.threshold = event2f: threshold + (event2f: hysteresis * 0.5dB)/2.
4.3 CS IRAT Handover Drive Test Trouble Shooting

Common trouble shooting scenarios are discussed in this section. After post processing
of the drive test logs, the RF engineer should evaluate IRAT handover performance and
investigate any IRAT handover failures in the test cluster. For an interior test cluster,
except for known coverage holes, the goal should also be to minimize or eliminate if
possible IRAT handovers / CM triggers through UMTS optimization, since frequent
IRAT occurrences, especially the ones resulting in call drops after IRAT handover
failures, may be signs of potential optimization issues within UMTS network such as
power / antenna tilt adjustments, soft handover (UMTS) neighbor list, pilot pollution,
interference, etc. Topics regarding performance optimization within UMTS network are
in general beyond the scope of this document. Here, we offer techniques and approaches
for trouble-shooting root causes associated with some typical IRAT handover failures.
The intention is not necessarily to include every possible failure cases found in the field,
but to offer some insights on how to identify different failure characteristics to facilitate
the investigation.
4.3.1 Failures Due to No MeasurementReport Message for e3a
When IRAT handover does not occur as expected in the border region and UE message
log shows e2d reports but no e3a report, it is a sign of potential missing GSM neighbor(s)
or strong GSM co-BCCH interference (UE could not resolve BSIC). The absence of
IRAT handover often leads to eventual call drop in this case. GSM re-tune / re-home
could often increase such failures.
4.3.1.1 GSM Neighbor List Optimization Issues
GSM neighbor list should be optimized from its original entries based on drive test GSM
scanner data. The GSM scanner BCCH-BSIC pairs plot along with Top BCCH Power /
Power of Specific BCCH plots from LDAT3G could be used to find the best GSM
servers, or spot potential co-BCCH interference if the scanner measures strong BCCH
power but not BCCH BSIC pair. The illustration in Figure 4 -6 showed such an
optimization scenario: after UE reported e2d and Compressed Mode Order was sent, the
UE continued to go into marginal RF converge with best active set pilot Ec/Io below
-16dB without reporting e3a and call dropped. GSM neighbor list issue was suspected.
The problem was resolved by adding the missing GSM neighbor identified based on the
BCCH-BSIC pairs plot in Figure 4 -7.
30
Figure 4-6: No e3a report after Compressed Mode Order resulting in call drop
Figure 4-7: Using BCCH-BSIC Pairs plot to identify missing GSM neighbor
31
Note that he BSIC from the scanner can be displayed in decimal or octave depending on
the setting selected in LDAT3G during the creation of the dataset. In the L3 message or
GsmExtCell database, the BSIC is defined in octave. So BSIC = NCC (0-7) and BCC (07). For example: BSIC 00oct = 0dec; BSIC 77oct = 63dec; if NCC = 4 and BCC = 5, the
BSIC is 45oct and 4*8+5= 37 in decimal. To simplify the matter, one could just use the
octave setting in LDAT3G to be consistent.
To help identify GSM neighbor issues, it is also useful to create a GSM cell map layer
using the Site Mapper.exe application. The GSM cell map layer could then be overlaid
with drive data within LDAT3G. To create the map layer files, the input .csv table of
current GSM data from the market should be in the following format, for example:
Site
Sector
Cellid
Bcch
Bsic
NCC
BCC
LAC
TCH
MAL Lat
CONTENTS
Long
Azi Ant.Ht
BAND
47.815601
-116.863998
182.22
1900
47.815601
-116.863998
88
182.22
1900
47.815601
-116.863998
254 182.22
1900
ID009 ID009A
40091 536
46
417
ID009 ID009B
40092 528
36
417
ID009 ID009C
40093 538
417
ID013 ID013A
40131 532
51
417
47.943901
-116.702004
30
70.01
1900
ID013 ID013B
40132 540
66
417
47.943901
-116.702004
170 70.01
1900
517 548 555
Optimizing GSM neighbor list and fixing GSM neighbor issues are critical to improving
IRAT handover performance in many cases. To perform this task effectively, RF
engineers also need to understand the way the IRAT neighbor list is formed.
The current IRAT neighbor list selection algorithm (NLSA) builds a combined list of
GSM neighbor cells based on the active set pilots: first the GSM neighbor cells of the
strongest UMTS cell in the active set are added, followed by the GSM neighbor cells of
the next strongest cell and so on. If a certain GSM cell is already included in the list, it
will not be added twice. The entire list is then truncated to the number specified by the
Combined GSM Neighbor List Size translation. The candidates that are in the strongest
active set cells GSM cell list and / or at the front of the GSM cell list would have a better
chance of making it in the combined GSM neighbor list sent to the UE. Therefore,
during GSM neighbor list optimization, dominant / strong GSM neighbors that are not in
the UEs GSM neighbor list should be added to the strongest active set cells
outGSMAdjCells list (as well as the RNCs GsmExtCell table if not already there). It is
also important to control the GSM neighbor list size by removing un-necessary
neighbors.
Additionally, UTRAN active set info is only updated when it receives SHO triggers from
the UE (i.e. event 1a, 1b or 1c reports). The active set info is not updated by the UTRAN
when it receives e2d since the pilot Ec/Io or RSCP measurements are not requested from
the UE for the e2d report.
As event 2d could occur well after the last
MeasurementReport for 1a, 1b or 1c, the best Ec/Io active set member info tracked by the
32
RNC could be out of date. Therefore with the existing IRAT neighbor list selection
algorithm, the IRAT neighbor list sent to the UE may not be optimum and may contain
none or very few of the best GSM serving cells for the current location of the UE.
This could be especially a problem at the network border where the UE is often in SHO
with a full active set, and the call may have continued for considerable time without a
recent 1a, 1b or 1c event to update the RNC with best active set member info. Call
failure could occur when the UE sends an e2d and gets an outdated IRAT neighbor list
and never triggers an e3a. If UE continues to leave the network the call will drop. Call
failure could also occur when an e3a is triggered, as the UE is able to decode one of the
GSM BSICs because the GSM RSSI threshold for HO is set quite low at -98dBm even
though it may be far outside its best service area. IRAT handover in this case would be
attempted. However when the UE received the handover command, the GSM traffic
channel may not be of sufficient quality to complete handover or the RACH power
allocated by the GSM to the UE is not sufficient for the RACH to reach the target cell,
resulting in IRAT handover failure with the cause "physical channel failure".
To improve the effectiveness of the IRAT neighbor list, the RF engineer may need to
further optimize the RF design so that the UTRAN border cell is more dominant, and also
add the desired GSM targets to the best active set member that was reported in the e1a,
e1b and e1c prior to the e2d. Future enhancements such as implementing e1d so that the
RNC would get more up to date best active set member info and thus be able to send the
UE a more effective IRAT neighbor list is also planned.
4.3.2 Failures Due to No Utran2GsmHOcmd Message UTRAN Issues
When IRAT handover does not occur in the expected handover region, and the UE
message log shows that the UE sends an e3a report but the UE does not receive an
Utran2GsmHOcmd message from the UTRAN under acceptable RF condition, it could
be an indication of potential UTRAN bugs / issues (or core network issues as discussed in
section 4.3.3.) This may lead to an eventual call drop. The RF engineer should open an
AR in this case so that it could be escalated to the responsible UTRAN support group.
RncCallTrace could typically be enabled in conjunction with targeted drive test for
further investigation. Some of the known UTRAN issues that result in such failure
characteristics are described below.
4.3.2.1 removedInterRATCellList Call Processing Issue
One of the known root causes for failures with e3a report but no Utran2GsmHOcmd
message could be due to that IRAT cell list is currently not being refreshed when setting
up the initial e3a measurement as shown below in bode:
value DL-DCCH-Message ::=
{
integrityCheckInfo
{
messageAuthenticationCode '10100101 11011100 01110001 00110110'B,
rrc-MessageSequenceNumber 2
},
message measurementControl : r3 :
{
33
measurementControl-r3
{
rrc-TransactionIdentifier 0,
measurementIdentity 3,
measurementCommand setup : interRATMeasurement :
{
interRATCellInfoList
{
removedInterRATCellList removeNoInterRATCells : NULL,
===IRat list not re-freshed
newInterRATCellList
{
{
interRATCellID 0,
technologySpecificInfo gsm :
{
interRATCellIndividualOffset 0,
bsic
{
ncc 6,
bcc 7
},
frequency-band dcs1800BandUsed,
bcch-ARFCN 173
}
},
{
interRATCellID 1,
{
bsic
{
ncc 5,
bcc 7
},
bcch-ARFCN 176
}
},
===cell index 2, 3, 4 arent in the current IRAT list
{
interRATCellID 5,
{
bsic
{
ncc 2,
bcc 7
},
bcch-ARFCN 169
}
},
This could result in a potential problem that UE may consider an old GSM cell (e.g.
interRATCellID 4 that could be from sIB11 or from a previous e3a setup) that is not in
the current IRAT neighbor list to be a valid neighbor and report it in the e3a
MeasurementReport message (it may be reported even though it may not be the optimal
candidate depending on the UE behavior). The RNC will recognize that the reported cell
index is not in the current neighbor list and therefore will not trigger UMTS-to-GSM
handover. The following rncCallTrace showed that a RRC measurementReport for e3a
was received from the UE. The RNC then sent RRC measurementControl messages to
turn off CM and to release the IRAT measurement (this is what normally occurs in
34
response to e3a.) However the RNC did not send a RANAP RelocationRequired
message to the 3G MSC as expected in the successful example, so the
Utran2GsmHOcmd is never sent. This could result in a drop call should the UTRAN RF
condition deteriorate before a successful IRAT handover can occur.
Example Failure Case:
2006-02-28T20:26:31.670000-08:00 0 RRC measurementReport E2D
2006-02-28T20:26:31.789000-08:00 0 RRC measurementControl dcs1800 SETUP
interRATMeasurement [3]
event3a :
thresholdOwnSystem -13, w 10,
thresholdOtherSystem -98, hysteresis 0,
timeToTrigger ttt0
ARFCN: 165 174 169 176 176 165 177 164 177 170 163 171 174 163 177 171 163
173 166 167
2006-02-28T20:26:33.550000-08:00 0 RRC measurementReport E3A saw BSIC 23
2006-02-28T20:26:33.588000-08:00 0 RRC measurementControl RELEASE [3]
2006-02-28T20:26:35.590000-08:00 0 RRC measurementReport E1C
2006-02-28T20:26:35.595000-08:00 0 NBAP RadioLinkSetupRequestFDD
2006-02-28T20:26:35.657000-08:00 0 NBAP RadioLinkSetupResponseFDD
2006-02-28T20:26:35.661000-08:00 0 RRC activeSetUpdate
2006-02-28T20:26:35.950000-08:00 0 RRC activeSetUpdateComplete
2006-02-28T20:26:36.024000-08:00 0 RRC measurementControl
2006-02-28T20:26:36.026000-08:00 0 RRC measurementControl SETUP
interFrequencyMeasurement [7]
event2d :
usedFreqThreshold -12, usedFreqW 10,
hysteresis 4, timeToTrigger tt320
event2f :
usedFreqThreshold -12, usedFreqW 10,
hysteresis 4, timeToTrigger ttt640
2006-02-28T20:26:36.499000-08:00 0 NBAP RadioLinkRestoreIndication
2006-02-28T20:26:36.720000-08:00 0 NBAP RadioLinkRestoreIndication
2006-02-28T20:26:36.957000-08:00 0 NBAP RadioLinkDeletionRequest
2006-02-28T20:26:36.979000-08:00 0 NBAP RadioLinkDeletionResponse
2006-02-28T20:26:38.269000-08:00 0 RRC measurementReport E2F
Example Successful Case:

2006-02-28T21:22:57.145000-08:00 0 RRC measurementReport E3A saw BSIC 0
2006-02-28T21:22:57.163000-08:00 0 RANAP RelocationRequired
CAUSE: radioNetwork : relocation-desirable-for-radio-reasons
2006-02-28T21:22:58.575000-08:00 0 RANAP RelocationCommand
2006-02-28T21:22:58.577000-08:00 0 RRC handoverFromUTRANCommand-GSM dcs1800
2006-02-28T21:22:59.475000-08:00 0 RANAP Iu-ReleaseCommand
CAUSE: radioNetwork : successful-relocation
35
A future enhancement (umtsn061433 currently targeted for u03.01 load 16.70 and as
feature u3285 in u03.03) that will re-fresh IRAT cell list in the initial e3a setup (i.e. set
"removedInterRATCellList = removeAllInterRATCell" in the MC message) should
reduce the failures due to this problem. Additional enhancements that will allow UE to
continue Compressed Mode and e3a reports (i.e. UTRAN not sending MC messages to
release CM and e3a measurement after receiving e3a report, targeted for feature u3851 in
u03.03+) will also mitigate failures due to this issue. In the meantime, the workaround
would be to identify this old cell based on its interRADCellID and add it to the GSM
neighbor list.
4.3.2.2 Compressed Mode Synchronization Issue
When RNC receives an e3a report from the UE, it currently instructs nodeB and sends
measurementControl message to the UE to stop Compressed Mode. However in some
cases, the UE may not receive the MC message resulting in nodeB and the UE out of
sync: nodeB operating in non Compressed Mode while UE is still in Compressed Mode.
When this happens, the block error rate would increase significantly as shown in Figure
4 -8 leading to call drop. There are also cases that the UE receives the
Utran2GsmHOcmd before call drop with this scenario. The enhancement discussed in
section 4.3.2.1 that UTRAN would not immediately stop CM after receiving e3a from the
UE will also serve to alleviate failures here.
Figure 4-8: An Example of LDAT3G R99 BLER Composite Downlink Plot
36
4.3.2.3 Invalid cGI

In handover preparation message sent from 3G MSC to 2G MSC to prepare for the HO,
the cGI = MCC+MNC+LAC+cELLiD. If the cGI does not exist in the 2G MSC, the HO
will be rejected and the UNTRAN will receive Relocation Failure from 3G MSC with
failure in target system cause. The cGI is based on the entries in the GsmExtCell
database on the RNC/OMC-U, so the RF engineer should ensure that data supplied by
Cingular Wireless and the data entry are correct.
4.3.3 Failures Due to No Utran2GsmHOcmd Message Core Network Issues
When the UE message log shows e3a reports but UTRAN never sends an
Utran2GsmHOcmd message to the UE under acceptable RF condition, and RNC trace
does not indicate any UTRAN issues, the AR should be escalated to the responsible MSC
support group. MSC traces (e.g. MAP trace, ISUP trace, etc.) may be enabled to identify
potential core network provisioning / configuration bugs. Some of the common root
causes found in the field are summarized here. Those problems may often occur /
increase after GSM network re-tune / re-home activities. It is therefore recommended
that the necessary IMT trunk / LAC growth, etc., on the LCP be verified by following
procedures described in section 3.4.2. Failures due to CN issues often occur in
significant numbers.
4.3.3.1 UTRAN Receives Unspecified Failure from 3G MSC
After sending Relocation Required request, UTRAN receives Relocation Preparation
Failure on RANAP from the 3G MSC with unspecified failure cause. A few examples
of issues that could cause this problem are described here.
1. 3G MSC Missing Provisioning Data for New LACs / or other Required Entries. This
problem could be solved by for example, identifying the new LACs from the market
RF Template and adding the missing LACs in the MSC / VLR MAP Table.
2. Incorrect 3G MSC Digit Table Entry. In this case, unspecified failure cause would
be received by UTRAN for certain handover numbers. Using the handover number,
the SPAN being used could be identified and ISUP monitor could be setup to run
tests. If the handover number (e.g. 180164378XX ) is by mistake translated
incorrectly in the 3G MSC Digit Tables entry (e.g. 80164379&), the 2G MSC will be
sending back a Release right after the 3G MSC sends an IAM, because the 2G MSC
does not know how to route this number.
3. ISUP Exchange Failures. Anything that causes the ISUP exchange to fail during the
setup of the trunk to 2G MSC would likely result in an unspecified failure. This
includes trunk blocked, busy, out of service, CIC maintenance/blocked, or setup
timeouts. The trunk should be taken OOS momentarily and the customer needs to be
contacted to bring the trunk / CIC in service.
37
4. MAP Error / MAP Aborts. MAP Prepare Handover Response received with a MAP
error instead of an embedded Handover Failure message; MAP abort received in
response to MAP Prepare Handover; or in some rare odd case when the MSC couldn't
populate the AN-PDU when it should.
5. No ACM Received for IAM. When no ACM is received for the IAM (handover
number).
4.3.3.2 UTRAN Receives No Resource Available from 3G MSC
After sending Relocation Required request, UTRAN receives Relocation Preparation
Failure on RANAP from the 3G MSC with cause no resource available. This indicates
no MGW resource is available for the relocation.
4.3.3.3 3G MSC Receives BSSMAP Prepare Handover Failure from 2G MSC
After receiving Relocation Required request from the UTRAN, the 3G MSC will send
MAP Prepare Handover Request to the 2G MSC. If handover preparation is successful,
the 3G MSC will receive Handover Request Acknowledge in the 2G MSC MAP Prepare
Handover Response. If handover preparation is not successful, Handover Failure with
specific cause codes may be returned in the 2G MSC MAP Prepare HO Response.
For example when an Invalid Cell error is returned, it indicates that the LAC in the
3GMSC handover request is not valid from the 2GMSC's perspective. The Cingular
Wireless customer needs to be contacted to verify which 2GMSC E164 address should
the LAC be associated with.
The Table 4 -1 below shows a list of example causes codes in the BSSMAP Prepare
Handover Failure from the 2G MSC. The 3G MSC will then map them to the cause
codes in RANAP Relocation Preparation Failure message sent to the UTRAN. Basically,
most of the failures including Equipment Failure, No Radio Resource Available, etc. are
mapped to Relocation Failure in Target CN/RNC or Target System on RANAP.
48.008
HANDOVER FAILURE
25.413
RELOCATION PREP. FAILURE
Ciphering algorithm not supported
Requested ciphering and/or

protection is not supported
Notes
integrity
Circuit pool mismatch

Equipment failure
Invalid message contents
No radio resource available
O and M intervention
1
Relocation failure in target CN/RNC or
target system
Abstract Syntax Error
target system
O and M intervention
38
Radio interface failure, reversion to old channel

Radio interface message failure
Relocation failure
target system
Requested speech version unavailable
Relocation failure
target system
Requested terrestrial resource unavailable
Relocation failure
target system
Requested transcoding/rate adaptation unavailable Relocation failure
target system
Switch circuit pool
2
in target CN/RNC or
in target CN/RNC or
in target CN/RNC or
in target CN/RNC or
1
Terrestrial circuit already allocated

target system
Traffic load in the target cell higher than in the Traffic load in the target cell higher than in
source cell
the source cell
Any other value
target system
NOTE 1: Cause code not used at inter-system handover.
NOTE 2: Cause code not applicable to this traffic case.
Table 4-1: Mapping of cause codes in BSSMAP Handover Failure and in RANAP
Relocation Preparation Failure
4.3.4 Failures Due to UE Reporting HOFrmUtranFail Configuration Unaccepted
If IRAT handover fails after the UE receives the Utran2GsmHOcmd, and sends
HOFrmUtranFail with Configuration Unaccepted, it means that the UE does not support
the requested GSM handover configuration and therefore rejects the HO command.
Possible causes could be that the UE has been locked onto a certain band or does not
support the requested band class, or codec compatibility issues.
Lucent uses frequency-band dcs1800BandUsed in the Utran2GSMHO command to a
GSM 850 cell based on standards. Certain UE such as Motorola A845 or Nokia 6651
will also fail the handover with Configuration Unaccepted due to potential UE
standards compatibility issue. Those UEs however, would perform handover normally to
a GSM 850 cell if frequency-band pcs1900BandUsed were in the handover command
instead. The Utran workaround for this UE bug is planned for U03.01 load 16.70.
4.3.5 Failures Due to UE Reporting HOFrmUtranFail Physical Channel Failure
Another common IRAT handover failure scenario observed in the field is that the UE
receives the Utran2GsmHOcmd, and then sends HOFrmUtranFail with Physical Channel
Failure. Here, we discuss several potential root causes.
39
4.3.5.1 GSM Cell in Handover Command Does Not Match the One in E3a Trigger
We discussed earlier in section 4.3.2.3 that when GsmExtCell database has incorrect /
non-updated info due to GSM retune / re-home, 2G MSC may reject the handover request
because the cGI is invalid. However, in some cases, for example after a GSM local
retune, if GsmExtCell is not updated, the GSM cell reported in e3a may end up being
mapped to a different cell by the 2G MSC. The BCCH/BSIC returned by the 2G MSC
and sent in the Utran2GsmHOcmd will be different from the BCCH/BSIC associated
with the InterRATCellID reported in the e3a. IRAT handover will fail because the GSM
cell that is transmitting and acquiring the UE is not the one that the UE measured and
should be handed over to. This situation could also occur under certain race condition
associated with the problem that is discussed in section 4.3.2.1 that currently IRAT
neighbor list is not being refreshed when we setup the initial e3a measurement, i.e.
removedInterRATCellList=removeNoInterRATCells (NULL). The race condition occurs
when immediately after the UE sends an e3a reporting an old IRAT cell X (e.g. with
interRADCellID=4) that is not in the current IRAT neighbor list, it gets an updated IRAT
neighbor list from UTRAN that does include this interRADCellID but assigned to cell Y.
By the time that UTRAN receives the e3a report, it has already updated its IRAT
neighbor list and therefore interprets the reported cell as cell Y.
Below we use a normal scenario to illustrate the procedure that the RF engineer may use
to verify that if the GSM cell in the handover command does / does not match the one in
the e3a trigger.
First, from LDAT3G L3 window or Agilent E6474A export wizard, find the reported
interRATCellID in the decoded e3a MeasurementReport message:
RRC:
Length
UL
|
|
|
Message
|
|
RRC
|
|
|
|
|
|
|
|
|
|
|
|
| | | | | Verified BSIC = 5
Message
Time stamp : 983377254
UL
DCCH
=
9
Message
Integrity
Check
Info
Authentication
Code
=
00000110011001100000111011111110B
Message
Sequence
Number
=
13
UL
DCCH
MessageType
|
Measurement
Report
|
Measurement
Identity
=
3
|
Inter
RATEvent
Results
|
Event
IDInter
RAT
=
E3a
(0)
|
Cell
To
Report
List[0]
=
this
is
the
reported
interRATCellID
Dump:
0x8333077F6A0448005043
DCCH
From the MeasurementControl message sent after the first current e2d to setup e3a
measurement and any subsequent MC messages sent before e3a report to update IRAT
neighbor list, find the corresponding interRATCellID and its BCCH/BSIC values. In the
race condition described earlier, one may need to search the old IRAT neighbor list before
the current e2d or sIB11 to find the corresponding interRATCellID
RRC:
Length
DL
|
|
|
DL
DCCH
=
DCCH
|
|
Message
RRC
Integrity
Authentication
Message
Code
=
Sequence
90
Message
Check
Info
01010000101001001011011000011111B
Number
=
8
40
|
DL
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | | | | | | | Inter RATCell ID = 5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DCCH
MessageType
Measurement
Control
|
Measurement
Control
R3
|
Measurement
Control
R3
IEs
|
RRC
Transaction
Identifier
=
0
|
Measurement
Identity
=
3
|
Measurement
Command
=
Setup
|
|
|
Inter
RATMeasurement
|
|
|
Inter
RATCell
Info
List
|
|
|
Remove
No
Inter
RATCells
|
|
|
New
Inter
RATCell
List[0]
|
|
|
|
Inter
RATCell
ID
=
0
|
|
|
|
|
|
Gsm
|
|
|
Inter
RATCell
Individual
Offset
=
0
|
|
|
|
|
|
BSIC
|
|
|
|
|
|
NCC
=
2
|
|
|
|
|
|
BCC
=
3
|
|
Frequency
Band
=
Dcs1800
Band
Used
(0)
|
|
|
|
|
BCCH
ARFCN
=
139
|
|
|
New
Inter
RATCell
List[5]
=find the corresponding index and record BSIC/BCCH info
|
|
|
|
|
|
Gsm
|
|
|
Inter
RATCell
Individual
Offset
=
0
|
|
|
|
|
|
BSIC
|
|
|
|
|
|
NCC
=
0
|
|
|
|
|
|
BCC
=
3
|
|
Frequency
Band
=
Dcs1800
Band
Used
(0)
|
|
|
|
|
BCCH
ARFCN
=
133
Then from Utran2GsmHOcmd (this is obtained from the E6474A export wizard,
LDAT3G L3 window currently does not give the complete hex value), select the hex
portion of the GSM Message List:
RRC:
DL
DCCH
Length
=
46
DL
DCCH
Message
|
Integrity
Check
Info
|
|
Message
Authentication
Code
=
11011010111100001010111101110111B
|
|
RRC
Message
Sequence
Number
=
14
|
DL
DCCH
MessageType
|
|
Handover
From
UTRANCommand
GSM
|
|
|
Handover
From
UTRANCommand
GSM
R3
|
|
|
|
Handover
From
UTRANCommand
GSM
R3
IEs
|
|
|
|
|
RRC
Transaction
Identifier
=
0
|
|
|
|
|
RAB
Info
|
|
|
|
|
|
Gsm
MAP
RAB
Identity
=
00000001B
|
|
|
|
|
|
CN
Domain
Identity
=
CS
Domain
(0)
|
|
|
|
|
|
Re
Establishment
Timer
=
Use
T314
(0)
|
|
|
|
|
Frequency
Band
=
Dcs1800
Band
Used
(0)
|
|
|
|
|
Gsm
Message
List
|
|
|
|
|
|
GSM
Message
List[0]
| | | | | | | GSM Message List = 062B03850E72C12D05D0628E407C000FFFFFC000000...H select the bode hex value
Message
Dump:
0xED7857BBF18400448F831581C28739609682E83147203E0007FFFFE000000000000000003190B90207FFFFEFC88000
Time stamp : 983378505
Open the NAS a la Torsten decoder on http://135.86.68.177/umtsdecoder and paste the

hex value to get the decoded handover command:
5.
CellDescription: 03 85 : 2 octets ARFCN=133 ChannelDescription2: 0e 72 c1 : 3 octets
Query Results
NAS decode of message
062B03850E72C12D05D0628E407C000FFFFFC000000
41
{
'Message' => {
'MessageType' => 'HANDOVER COMMAND',
'MessageContents' => {
'PowerCommandAndAccessType' => {
'FastPowerControl' => 0,
'PowerLevel' => 5,
'AccessTypeControl' => 'mandatory'
},
'SynchronizationIndication' => {
'NormalCellIndication' => 0,
'SI' => 'Non-synchronized',
'ReportObservedTimeDifference' => 0
},
'DescFirstChannelAfter' => {
'TrainingSequenceCode' => 3,
'HoppingChannel' => 16,
'TimeslotNumber' => 6,
'ChannelType' => 'TCH/F + FACCH/F and SACCH/F'
},
'CellDescription' => {
'ARFCN' => 133,
'NCC' => 0,
'BCC' => 3
},
'HandoverReference' => 45
}
},
'Protocol' => 'RRM'
=BCCH/BSIC of the cell in the HO command
If the target cell BCCH/BSIC in the HO command does not match the one reported by the
UE in e3a, the failure root cause could be due to incorrect info in GsmExtCell database,
or the race condition associated with removedInterRATCellList problem. Similar
resolutions as discussed in section 4.3.2.3 and/or section 4.3.2.1 should be applied.
4.3.5.2 GSM Cell Reported in E3a Not the Optimal Candidate
When e2d report is received, the RNC generates the IRAT neighbor list based on the
active set info of the last received SHO trigger (1a / 1b / 1c report). This could result in a
non-optimal IRAT neighbor list sent to the UE and thus a non-optimal candidate being
reported. Section 4.3.1.1 has detailed description of this issue and its resolution.
Co-BCCH/BSIC cells in the GSM network could also result in the UE measuring a strong
candidate but report a non-optimal candidate instead. In this case, a distant but dominant
cell, e.g. cell Y, is co-BCCH/BSIC with a close-in but weak cell X that is on the IRAT
neighbor list sent to the UE. The UE measures the BCCH/BSIC from cell Y but will
think its from cell X and report it in e3a. 3G MSC will request to 2G MSC for handover
to cell X. IRAT handover in this case will most likely fail because the UE may not be
able to acquire DL from cell X. The GSM map layer plot mentioned in section 4.3.1.1
could help identify the potential co-BCCH/BSIC cell which may often be a cell on a
higher terrain couple tiers away. Drive test may also need to be conducted during the
maintenance hours with the close-in cell turned off to verify the co-BCCH/BSIC cell. If
cell design changes, or optimization techniques (downtilt, power adjustment) are not
possible to control the overshoot from the distant cell and in the mean time increase the
42
dominance of the close-in cell, Cingular customer should be requested to change the coBCCH/BSIC planning and add the distant dominant cell to the GSM neighbor list.
In some IRAT handover Physical Channel Failures cases, it was observed that the GSM
cell reported in e3a was not necessarily the strongest / optimal candidate based on the
GSM scanner plots and in the mean time, there were stronger / optimal candidates in the
IRAT neighbor list. This behavior may be UE dependent. Also, the time between e3a
trigger and Utran2GsmHOcmd is at least 2-3 seconds. GSM cell signal may be available
but not sufficient due to significant RF fluctuation especially in challenging terrain. The
current MAHO GSM threshold 98dBm may be too low for those cases. Higher
threshold values, e.g. 95dBm, -92dBm, -89dBm, etc. could be evaluated via drive test
and service measurements optimization.
4.3.5.3 UE Compressed Mode Deactivated Before Handover
UTRAN currently sends MeasurementControl messages to stop compressed mode and
release e3a measurements after receiving an e3a report from the UE.
This
implementation un-necessarily prevents the UE from continuing to report e3a and
therefore avoiding a potential call drop in case the previous e3a does not result in a
handover command. It may also cause call drop due to potential compressed mode out of
sync between the UE and the UTRAN. Those issues are discussed in detail in section
4.3.2.1 and section 4.3.2.2.
Additionally, this implementation may also cause IRAT handover physical channel failure
because the two MC messages would cause potential queuing delay for the handover
command. More critically, according to Qualcomm, when the UE receives the MC
message to deactivate the compressed mode, it will also erase the synchronization
information for the GSM target cell that it has obtained during IRAT measurements. This
interaction of CM deactivation and the UE behavior could be very detrimental to the
handover performance as the UE would take much longer time to reacquire the
synchronization of the GSM target cell upon handover and could result in potential
handover failure. In this case, the UE would send HOFromUtranFail with Physical
Channel Failure. This issue will be resolved with feature u3851 (targeted for u03.03+),
Lucent UTRAN will not deactivate IRAT measurements and compressed mode before
execution of the IRAT handover.
4.3.5.4 Incorrect Parameter Setting on 2G MSC
Incorrect parameter setting on 2G MSC could also result in IRAT handover failure with
Physical Channel Failure. For example, the BSS Type parameter on the GSM switch
should be set to R99 for GSM to support IRAT handover from the UTRAN. Otherwise,
the GSM BTS will not support the 3G ciphering algorithm being used by the UE and the
handover will fail.
43
4.3.6 IRAT Handover UTRAN Parameters Optimization

If IRAT handover optimization issues discussed in the previous sections have all been
identified and resolved, but the performance is still not acceptable, certain UTRAN
parameters relevant to IRAT handover performance may be further optimized. This may
be useful in areas with challenging RF condition / terrain where pilot Ec/Io fluctuates /
swaps quickly but no dominant pilot in the active set, especially if drive test result shows
call drops in weak RF condition before the UE could trigger e3a, or because e3a is
triggered too late to receive IRAT handover command or the UE never receives IRAT
handover command due to weak RF.
In those cases, umts2GsmQActCM2D.threshold value may be increased from the current
13dB to e.g. 11dB so that Compressed Mode Order could be sent to the UE sooner to
start MAHO monitoring.
If necessary, umts2GsmQTriggerMAHO.weight may also be reduced from the current
value 1 to e.g. 0.8, 0.6, or 0.4. When calculating aggregate active set Ec/Io, all pilots are
equally weighted by the UE with a weight value of 1. In non-dominant active set cases,
pilot Ec/Io may degrade quickly and it may be more advantageous to trigger e3a sooner
by using less weight factor for secondary pilots when calculating aggregate active set
signal strength. Alternatively, umts2GsmQTriggerMAHO.threshold may be increased
from the current 13dB to e.g. 11dB to trigger e3a sooner.
Different parameter combinations / data set values may be experimented with in order to
evaluate the optimal setting for the area / cluster. For example:
e2d = -11dB, weight = 1;
e2d = -13dB, weight = 0.5;
e2d = -11dB, weight = 1; MAHO = -11dB
, etc.
During the parameters optimization, drive test should be conducted and service
measurement metrics should be closely monitored in case of severe degradation.
Performance improvement / tradeoffs should be evaluated for the optimal setting.
4.3.7 IRAT Handover Failures in Areas with No Call Drops
When there are IRAT failures but the UE is able to consistently hold on to the UMTS call
in the area without call drops, it is an indication that those IRAT triggers may be premature, in addition to understanding of the root causes of the failures. This is also true
even if the frequent IRAT handovers in the area are successful. Pre-mature IRAT
handovers could UMTS coverage / traffic loading unnecessarily. It should be avoided by
increasing
the
e3a
umts2GsmQTriggerMAHO.threshold
and/or
e2d
umts2GsmQActCM2D.threshold values (especially if they are set higher than the current
recommended values of 13dB).
44
IRAT Failures w/o Call Drops
Figure 4-9: Example of IRAT Failures without Call Drops

4.3.8 IRAT Drive Test Showing Significant GSM Originations
Normally during IRAT drive test, after the UE has performed an IRAT handover to GSM
and the call ends, (origination calls are typically set to ~40s during drive test), the UE
should perform GSM-to-UMTS cell reselection and continue call originations on UMTS
if the UE is in automatic mode and has returned to the UMTS coverage region.
Significant percentage of GSM originations, or UE staying on GSM indefinitely after an
IRAT handover may indicate problems with GSM-to-UMTS cell reselection.
The GSM System Information Type 2quater message has to contain the list of applicable
UMTS neighbor cells and "3G Measurement Parameters Description" IE for cell
reselection. If that information is not present, then GSM-to-UMTS reselection will not
occur. It is recommended that all GSM cells within the overlay UMTS coverage area as
well as GSM only cells covering UMTS-GSM only border regions need to have the 3G
reselection parameters and 3G neighbor list populated. Note that the SI2quater message
may be split into several parts. The parameter SI2quater_COUNT value plus 1 (e.g.
SI2quater_COUNT : 1 means there are 2 parts) gives the number of parts. The parameter
SI2quater_INDEX is the index of the part (if there are 2 parts, then the index should be 0,
1). In the below decoded L3 SI2quater message (from TEMs trace), SI2quater_COUNT
is 1, indicating that there are two parts; SI2quater_INDEX is 0, indicating this decoded
message is the first part. The UMTS neighbors are listed in the first part. The 2nd part
with index 1 should contain the IE "3G Measurement Parameters Description".
Time: 17:31:57.62
header
Command Code : 16
45
Length : 38
Log Code (Hex) : 0x512F
1.25 ms/40 counter (32 kHz clock) : 0
CFN : 190
1.25 ms counter : 281473991977431
Channel type : (129) DL BCCH
Message type : System Information Type 2quater
Length : 23
L2 Header
L2 Length field
Length : 1
Skip indicator : 0
Protocol discriminator : (6) Radio resources management messages
Message type : 7
Rest octets
BA_IND : 1
3G_BA_IND : 1
MP_CHANGE_MARK : (0) MS does not have to re-read the MEASUREMENT and 3G MEASUREMENT INFORMATION
from all the SI2quater messages
SI2quater_INDEX : 0
SI2quater_COUNT : 1
REPORT_TYPE : (1) MS shall use normal report type
SERVING_BAND_REPORTING : 3
3G Neighbour Cell Description
= GSM-to-UMTS reselection will fail if 3G Neighbors are not
present / missing
UTRAN FDD description
Neighbors :
[0 ] :
FDD ARFCN : 9875
Fdd_Indic0 : 0
NR_OF_FDD_CELLS : 12
Cell information :
[0 ] : Scrambling code : 104 Diversity : 0
[10] : Scrambling code : 388 Diversity : 0
[11] : Scrambling code : 412 Diversity : 0
Message dump (Hex):
60 00 10 00 26 00 26 00 2F 51
03 BE 3E 29 4E C5 99 00 81 07
17 05 06 07 C0 3E 04 A9 A4 CC
41 3A 06 D9 CB 81 82 BF 1C F8
68 58 0B 2B
In some cases, significant percentage of GSM originations from the drive result may also
be due to potential UE problems. It was observed with a Samsung UE that it did not
seem to be able to measure the desired pilot correctly on a good part of the drive route.
The UMTS scanner would show strong / reasonable Ec/Io (indicating the cells were
transmitting ok,) while the UE finger Ec/Io was much weaker than expected although the
UE could be next to that sector, or the desired sector wouldn't even be in the active set.
The call would be originating on / carried by non-optimal pilots causing failure / drop due
to radio link failure. UE would abandon UMTS and went to GSM. If the failures happen
mostly close to a desired sector, it could be an indication of potential UE receiver
46
overload / de-sensitization. A different OEM / Qualcomm UE may be used to re-test the

drive route in order to verify if the problem is reproducible.
4.4 PS UMTS-to-GSM Drive Test Optimization

Border cell optimization discussed in section 4.1 and GSM IsCrsMAHO neighbor list
optimization discussed in section 4.3.1.1 could also help improve PS UMTS-to-GSM cell
reselection successes. After CS UMTS-to-GSM IRAT handover optimization is
completed, further PS UMTS-to-GSM drive test optimization may be conducted since
currently only UMTS-to-GSM cell reselection is supported for PS calls. The UE also
needs to be set to automatic mode for the testing.
For PS UMTS-to-GSM cell reselection to occur, the UE needs to be in Cell_FACH /
URA_PCH states, or in idle state after the call drop. Therefore it may need to go further
beyond the CS IRAT handover region. The current GSM reselection cell list which is the
same as the MAHO GSM neighbor list (IsCrsMAHO entries) may not be adequate /
optimal for cell reselection at that point.
As the UE throughput degrades due to lower radio quality and/or TCP flow control, it
performs reconfiguration to Cell_FACH state. If the UE finds a GSM cell from SIB11
GSM cell reselection list that meets the reselection criteria, it will perform cell reselection
to the GSM cell. When UE is in Cell_FACH / URA_PCH state, it would perform routing
area update and reestablished a GPRS or EDGE PS call. The serving 2G SGSN will
request the transfer of the PDP context and a modify PDP context message will be sent to
the UE. For this scenario, the reselection could in general complete within 40secs, and
the TCP/upper layer application may not have timed-out and could possibly continue
without user intervention.
However, if the UE does not find a target GSM cell because GSM cell reselection list
does not have the desired GSM cells, the PS call would continue to drag and eventually
drop due to radio link failure. The UE then starts scanning for a suitable UTRAN / GSM
cell. For this scenario, the reselection would mostly take much longer and the TCP /
higher layer applications would likely have timed-out, user intervention would be needed
to re-start the application / TCP connection.
To improve PS cell reselection performance, specific IsCrsOnly GSM cells may need to
be added to outGSMAdjCell list based on the drive test / GSM scanner result.
47
IRAT Handover Performance Monitoring
While drive test is an important and effective tool for investigating optimization issues
and troubleshooting failures, its statistic results may vary widely from run to run and/or
UE dependent. Performance measurements on the other hand, offer system wide statistic
results for all the users. Peg counts and metrics relevant to IRAT handover performance
should be monitored regularly to observe trending and/or spot any degradation of IRAT
handover performance in the market. They should also be closely monitored after
network activity such as new loads, GSM retune / re-home, as well as any IRAT related
parameter / configuration changes. Here, we briefly discuss their usage in terms of IRAT
performance optimization. The definition of those peg counts and metrics can be found
in reference [5] or at http://umi.web.lucent.com/
5.1 Compressed Mode Performance Measurements

There are two metrics available to monitor if compressed mode activation is successful
on RL and over RB.
When e2d is received, RNC sends NBAP: Radio Link Reconfiguration Prepare to Node
B and pegs NumAttCMPrep. If it receives Radio Link Reconfiguration Failure (or
timeout) from NodeB, it pegs NumFailCMPrep. The formula below reflects the
compressed mode activation performance on the RL (between RNC and Node B):
((A - B) / A) 100
Where:
A = NumAttCMPrep
B = NumFailCMPrep
If RNC receives NBAP: Radio Link Reconfiguration Ready from Node B, it then sends
RRC: Radio Bearer Reconfiguration to the UE and pegs NumRBReconfAtt.CM. If it
receives RRC: Radio Bearer Reconfiguration Failure from the UE (or timeout), it pegs
NumRBReconfFail.CM. The formula below reflects the compressed mode activation
performance over the RB (between RNC and UE):
((A - B) / A) 100
Where:
A = NumRBReconfAtt.CM
B = NumRBReconfFail.CM
Any degradation on those two metrics may indicate potential performance issues with
compressed mode activation. IRAT handover may not be triggered when needed, and as
a result may lead to increased call drop.
48
5.2 Relocation Preparation Performance Measurements

When e3a report (IRAT handover trigger) is received, RNC sends RANAP: Relocation
Required to the 3G MSC and pegs IRATHO.AttRelocPrepOutCS and starts
TRELOCprep timer. If relocation preparation is successful between 3G MSC and 2G
MSC, the RNC will receive RANAP: Relocation Command from the 3G MSC. If not,
the RNC will peg IRATHO.FailRelocPrepOutCS.sum when it receives RANAP:
Relocation Preparation Failure, or when TRELOCprep timer expires in which case
IRATHO.FailRelocPrepOutCS.T_RELOCprep_exp is also pegged. Also depending on
the failure cause value in the Relocation Preparation Failure message, the RNC may peg
IRATHO.FailRelocPrepOutCS:
.FailTarSys;
.NotSupTarSys;
.TarNotAllowed;
.NoRRTarSys.
However, due to the reason explained in section 4.3.3.3, among those four causes, only
failure cause Relocation Failure in Target CN/RNC or Target System (.FailTarSys) is
pegged by RNC. Any degradation (increase) in the following formula reflects potential
relocation preparation problems documented in section 4.3.2.3 and section 4.3.3.3 (i.e.
any failures returned by 2G MSC that are mapped to RANAP: Relocation Failure in
Target CN/RNC or Target System):
(A/B) x 100
Where:
A = IRATHO.FailRelocPrepOutCS.FailTarSys
B = IRATHO.AttRelocPrepOutCS
Currently there are no specific RNC peg counts for failure causes documented in section
4.3.3.1, section 4.3.3.2 and any causes that are not mapped to Relocation Failure in Target
CN/RNC
or
Target
System
in
section
4.3.3.3.
Instead,
only
IRATHO.FailRelocPrepOutCS.sum is incremented. Degradation (increase) in the
following formula reflects potential relocation preparation problems in those areas:
((A-B-C)/D) x 100
Where:
A = IRATHO.FailRelocPrepOutCS.sum
B = IRATHO.FailRelocPrepOutCS.FailTarSys
C = IRATHO.FailRelocPrepOutCS.T_RELOCprep_exp
D = IRATHO.AttRelocPrepOutCS
Any increase in relocation preparation failure due to TRELOCprep timer expiration will
be reflected by the following formula:
(A/B) x 100
Where:
A = IRATHO.FailRelocPrepOutCS.T_RELOCprep_exp
49
B = IRATHO.AttRelocPrepOutCS
5.3 IRAT Handover Performance Measurements

When RNC receives Relocation Command from the 3G MSC indicating successful IRAT
handover relocation preparation, it sends RRC: Handover from UTRAN Command to the
UE and pegs IRATHO.AttOutCS and starts TRELOCOverall timer. If the UE handover
to the GSM system is successful, the RNC will receive lu Release Command from the 3G
MSC. If the UE handover to the GSM system is not successful, the UE will return to the
UMTS system and send RRC: Handover from UTRAN Failure. If the RNC receives
Handover from UTRAN Failure from the UE or if TRELOCOverall timer expires, it pegs
IRATHO.FailOutCS.sum, and in the later case also IRATHO.TRELOCOverall.
Depending on the failure cause value in the Handover from UTRAN Failure message, the
RNC pegs either:
IRATHO.FailOutCS.ConfUnaccept
IRATHO.FailOutCS.PhyChnFail
IRATHO.FailOutCS.ProtErr.
Any degradation (increase) in the following formula reflects potential problems discussed
in section 4.3.4:
(A/B) x 100
Where:
A = IRATHO.FailOutCS.ConfUnaccept
B = IRATHO.AttOutCS
Any degradation (increase) in the following formula reflects potential problems discussed
in section 4.3.5:
(A/B) x 100
Where:
A = IRATHO.FailOutCS.PhyChnFail
B = IRATHO.AttOutCS
Any degradation (increase) in the following formula reflects potential RF coverage
degradation in IRAT handover region. In addition to resolve handover failures to the
target GSM system discussed above, IRAT handover UTRAN parameter optimization
described in section 4.3.6 may also be attempted to allow handover to be triggered
sooner:
(A/B) x 100
Where:
A = IRATHO.TRELOCOverall
B = IRATHO.AttOutCS
50
5.4 IRAT Handover Matrix

IRAT handover matrix may be used to assess how often and how successful a specific
GSM neighbor is used for IRAT handover. When the RNC sends RRC: Handover from
UTRAN Command to the UE, it also pegs NumUMTS-GSM_HOPerNCell.Att, and
when it receives RRC: Handover from UTRAN Failure from the UE, it also pegs
NumUMTS-GSM_HOPerNCell.Fail.
Those counts are pegged at the originating cell (best UTRAN active set member at RNC)
for each GSM target cell. The originating cell is derived from MOID. The GSM target
cell is identified by NumUMTS-GSM_HOPerNCell: _MCC (mobile country code),
_MNC (mobile network code), _LAC (location area code) and _CI (cell ID).
Degradation in .fail/.att rate for a particular GSM target cell may indicate a non-optimal
handover candidate and/or call processing issues at the target cell. If a particular GSM
target cell is rarely attempted, it may indicate that IRAT neighbor is of low importance.
However, due to IRAT NLSA and potential outdated active set info discussed in section
4.3.1.1, a critical GSM target cell may also get left out of the combined IRAT neighbor
list and rarely attempted.
51
References
[1] UMTS RF Translation Application Note: Inter-RAT Handover: UMTS-GSM

Release u03.01, July 2005.
[2] UMTS RF Translation Application Note: Cell Selection and Reselection, version
5.02, June 20, 2005.
[3] Lucent Worldwide Services Method of Procedures (MOP) - Flexent Wireless
Network Lucent UMTS Changes for Portland MSC Growth, version 1.1, Dec. 14,
2005.
[4] Procedure for Parameter Audit on RNC Data, January 11, 2006
[5] UMTS Performance measurements definitions manual, UMTS-03.01, 401-382803R03.01 Issue2, October 2005
52

UMTS IRAT OptimizationGuideline

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

UMTS IRAT OptimizationGuideline

Hochgeladen von

Copyright:

Verfügbare Formate

Lucent Worldwide Services

April 10, 2006

IRAT HANDOVER METHODS...........................................................................................................4

IRAT HANDOVER DEPLOYMENT RECOMMENDATION.......................................................11

IRAT HANDOVER OPTIMIZATION...............................................................................................23

BORDER CELL COVERAGE OPTIMIZATION...................................................................................23

IRAT HANDOVER PERFORMANCE MONITORING.................................................................48

IRAT DESIGN RECOMMENDATIONS.............................................................................................11

COMPRESSED MODE PERFORMANCE MEASUREMENTS...............................................................48

IRAT Handover Methods

Lucent UMTS system supports UMTS-to-GSM cell reselection for UE in non-DCH

2.2 UMTS-to-GSM IRAT Handover

CM required for IRAT

Change of active Set:

Change of active Set:

Change of active Set:

Change of active Set:

Change of active Set:

Figure 2-1: MAHO IRAT flow diagram

Soft Handover algorithm executed

Strongest cell has

Strongest cell has

Execute the UMTS to

Figure 2-2: DAHO IRAT flow diagram

IRAT Handover Deployment Recommendation

In this section, we present IRAT handover design recommendations and associated

Definition: Choice of measurement (CPICH Ec/No or CPICH RSCP) to use as quality

Recommended Setting: -11

GSM Neighbor list

Figure 3-3: An Example of GSM Neighbor List Entry

3.3 GSM Translation Configuration

3.4 Network Interconnectivity

3.4.2 LCP Procedure to Interconnect 3G and 2G MSCs

Inter-MSC Trunk (IMT) information

IRAT Handover Optimization

4.1 Border Cell Coverage Optimization

Overshoot from cell A. Idle UE will most likely

Non-optimized border cell could

GSM only cells

UMTS border cells

Figure 4-4: Examples of Border Cell Optimization Concerns

CS IRAT Handover Drive Test

4.2.1 Entrance Criteria

Figure 4-5: An example of IRAT handover analysis plot in LDAT3G

Key Information / Comments

Originating Conversational Call

Addressed To Own UE; RNTI=50183

DL MM TMSI Reallocation Command

UL MM TMSI Reallocation Complete

Event 2d, 2f thresholds

setting up config parameters for CM

TMSI Reallocation Command

EventID=e2d, 1st time reporting e2d,

Compress mode order, IRAT neighbor

update IRAT neighbor list

update IRAT neighbor list

release 3a (measurement identity 7)

DL RRM Physical Information

IRAT handover to GSM successful

= umts2GsmQActCM2D.threshold + event2d: hysteresis / 2

= umts2GsmQDeactCM2F.threshold - event2d: hysteresis / 2

Moreover, if the translation values for umts2GsmQActCM2D.threshold (e.g. 13) and

4.3 CS IRAT Handover Drive Test Trouble Shooting

517 548 555