umts irat optimizationguideline

Lucent Worldwide Services

Subject: Inter-RAT Handover Optimization

Guideline for UMTS Deployment in

Cingular Wireless

Version 1.1

Date:

From:

April 10, 2006

Melanie WangTony Houweling

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.

1

1 INTRODUCTION..................................................................................................................................3

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

2.1 UMTS-TO-GSM CELL RESELECTION............................................................................................42.2 UMTS-TO-GSM IRAT HANDOVER..............................................................................................5

2.2.1 CS UMTS-to-GSM Mobile-Assisted Handover........................................................................52.2.2 CS UMTS-to-GSM Database-Assisted Handover....................................................................82.2.3 PS UMTS-to-GSM Handover...................................................................................................9

2.3 GSM-TO-UMTS CELL RESELECTION..........................................................................................102.3.1 GSM-to-UMTS IRAT Handover.............................................................................................10

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

3.1 IRAT DESIGN RECOMMENDATIONS............................................................................................113.2 UTRAN TRANSLATION PARAMETERS.........................................................................................11

3.2.1 Cell Reselection Parameters..................................................................................................113.2.2 UMTS-to-GSM IRAT Handover Parameters..........................................................................143.2.3 GSM Neighbor List.................................................................................................................17

3.3 GSM TRANSLATION CONFIGURATION.........................................................................................193.4 NETWORK INTERCONNECTIVITY..................................................................................................20

3.4.1 PLMN.....................................................................................................................................203.4.2 LCP Procedure to Interconnect 3G and 2G MSCs................................................................21

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

4.1 BORDER CELL COVERAGE OPTIMIZATION..................................................................................234.2 CS IRAT HANDOVER DRIVE TEST..............................................................................................24

4.2.1 Entrance Criteria....................................................................................................................244.2.2 Test Equipment.......................................................................................................................244.2.3 Drive Test Cluster and Drive Route.......................................................................................244.2.4 Drive Test Procedure.............................................................................................................254.2.5 Drive Test Data Analysis........................................................................................................25

4.3 CS IRAT HANDOVER DRIVE TEST TROUBLE SHOOTING............................................................304.3.1 Failures Due to No MeasurementReport Message for e3a....................................................304.3.2 Failures Due to No Utran2GsmHOcmd Message – UTRAN Issues......................................334.3.3 Failures Due to No Utran2GsmHOcmd Message – Core Network Issues............................374.3.4 Failures Due to UE Reporting HOFrmUtranFail – Configuration Unaccepted...................394.3.5 Failures Due to UE Reporting HOFrmUtranFail – Physical Channel Failure....................394.3.6 IRAT Handover UTRAN Parameters Optimization...............................................................444.3.7 IRAT Handover Failures in Areas with No Call Drops.........................................................444.3.8 IRAT Drive Test Showing Significant GSM Originations......................................................45

4.4 PS UMTS-TO-GSM DRIVE TEST OPTIMIZATION........................................................................47

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

5.1 COMPRESSED MODE PERFORMANCE MEASUREMENTS...............................................................485.2 RELOCATION PREPARATION PERFORMANCE MEASUREMENTS....................................................495.3 IRAT HANDOVER PERFORMANCE MEASUREMENTS...................................................................505.4 IRAT HANDOVER MATRIX..........................................................................................................51

6 References..............................................................................................................................................52

2

1 IntroductionFor 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 subscriber’s 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-to-GSM 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.

3

2 IRAT Handover MethodsLucent 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 ReselectionTo 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-Ec/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 re-selection 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 HandoverFor 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 mobile-assisted 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. i f 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 HandoverThe 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 RAB’s 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 inter-RAT 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 CompressedMode, 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

6

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.

7

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

ServiceHandover?should should not

CM required for IRAT measurement?

yes

no

Setupmeasurement 2D

and 2F

Setupmeasurement 3C

Wait

- Releasemeasurement 3C

- Trigger inter-RAT HOUE sendsevent 3C


- Exit MAHO procedure

Change of active Set:pre-conditions no

longer fulfilled

Update GSMneighbour cell list inmeasurement 3C

Change of active Set:pre-conditions still

fulfilled


Service Handoverchanges from "should"

to "should not"

Wait

- Releasemeasurement 2D/2F



longer fulfilled

Setup measurement 3A

Wait

- Releasemeasurement 2D, 2Fand 3A


UE sendsevent 3A


- Trigger inter-RAT HO

Release measurement3A

UE sendsevent 2F

Update GSMneighbour cell list inmeasurement 3A

UE sendsevent 2D

Change of active Set:pre-conditions nolonger fulfilled

Change of active Set:pre-conditions stillfulfilled

Exit MAHOprocedure







ServiceHandover?should should notServiceHandover?should should not

CM required for IRAT measurement?CM required for IRAT measurement?

yes

no

Setupmeasurement 2D

and 2F

Setupmeasurement 3C

Wait






longer fulfilled



fulfilled



to "should not"

Wait




longer fulfilled


Wait



UE sendsevent 3A




UE sendsevent 2F


UE sendsevent 2D



Exit MAHOprocedure

Setupmeasurement 2D

and 2F

Setupmeasurement 3C

Wait



UE sendsevent 3C




longer fulfilled


longer fulfilled



fulfilled


fulfilled



to "should not"


to "should not"

Wait




longer fulfilled


Wait





UE sendsevent 3AUE sendsevent 3A






UE sendsevent 2FUE sendsevent 2F


UE sendsevent 2D





Exit MAHOprocedure

Figure 2-1: MAHO IRAT flow diagram

2.2.2 CS UMTS-to-GSM Database-Assisted HandoverDatabase-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 non-quality 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.

8

Figure 2-2: DAHO IRAT flow diagram

2.2.3 PS UMTS-to-GSM HandoverLucent 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.

9

IEService Handover

Strongest cell has GSM target cells for

DAHO?

UE supports frequency band(s) of

the GSM cell(s)?

Event type


DAHO?

Wait for measurement report

Soft Handover algorithm executed (NLSA identifies strongest cell and

updates and active set

1A/1B/1C2D for IRAT DAHO

Active set has been updated

should should not shall not

No

Yes

No UE supports frequency band(s) of

the GSM cell(s)?

No

Yes

No

Execute the UMTS to GSM handover procedure

Measurement Control (setup/modify event 2D)

Measurement Control (release event 2D)


IEService Handover


DAHO?


the GSM cell(s)?

Event type


DAHO?







No

Yes


the GSM cell(s)?

No

Yes

No




IEService Handover

IEService Handover


DAHO?


the GSM cell(s)?

Event type


DAHO?







No

Yes


the GSM cell(s)?

No

Yes

No





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 ReselectionCell 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 HandoverGSM-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

3 IRAT Handover Deployment RecommendationIn 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 RecommendationsAs 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 ParametersWith 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 ParameterscellSelAndResQualMeas Object: LRNC.LNodeB.Lcell

11

http://narndp2.ih.lucent.com:7779/pls/portal/ndpproject64.A_File.show

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, NARecommended Setting: CPICH EcNo

outGSMAdjCells.qOffsetObject: LRNC.LNodeB.LcellDefinition: An offset added to the measurement quantity for the GSM neighbor cell, used for UMTS to GSM cell reselection.Range: -50 … 50 dBRecommended Setting: 0

sIB3EnableSIB4IndicatorObject: LRNC.LNodeB.LcellDefinition: Indicates whether SIB4 information is broadcasted.Recommended Setting: FALSE

sIB3QqualMin Object: LRNC.LNodeB.LcellDefinition: Minimum required CPCH Ec/No quality level a cell must have to be considered for selection/reselection in idle mode.Range: -24 … 0 dBRecommended Setting: -19

sIB4QqualMin Object: LRNC.LNodeB.LcellDefinition: Minimum required quality level, if sIB3EnableSIB4Indicator = TRUE (activation of SIB4 for connected mode.)Range: -24 ... 0 dBRecommended Setting: -19

sIB3QrxlevMin Object: LRNC.LNodeB.LcellDefinition: 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 stepsRecommended Setting: -115

sIB4QrxlevMin Object: LRNC.LNodeB.LcellDefinition: 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.)Range: -115 … -25 dBm, 2 dBm stepsRecommended Setting: -115

12

QRXLEVMIN Object: OMCU.EXTERNALS.EXTERNALGSMCELLDefinition: Minimum receive-quality level that is needed in the neighboring GSM cell.Range: -115 … -25 dBm, 2 dBm stepsRecommended Setting: -109

sIB3RAT.rATIdObject: LRNC.LNodeB.LcellDefinition: Indicates the RAT typeRecommended Setting: rATIDGSM

sIB4RAT.rATIdObject: LRNC.LNodeB.LcellDefinition: Indicates the RAT typeRecommended Setting: rATIDGSM

sIB3RAT.ssearchRATObject: LRNC.LNodeB.LcellDefinition: A threshold to start GSM measurements for reselection (SsearchRAT).Range: -32 … 20 dB, 2 dB stepsRecommended Setting: 4

sIB4RAT.ssearchRATObject: LRNC.LNodeB.LcellDefinition: A threshold to start GSM measurements for reselection (SsearchRAT), if sIB3EnableSIB4Indicator = TRUE (activation of SIB4 for connected mode).Range: -32 … 20 dB, 2dB steps Recommended Setting: 4

sIB3Qhyst1Object: LRNC.LNodeB.LcellDefinition: 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 stepsRecommended Setting: 2

sIB4Qhyst1Object: LRNC.LNodeB.LcellDefinition: 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).Range: 0 – 40 dB, 2 dB stepsRecommended Setting: 2

13

sIB3Qhyst2Object: LRNC.LNodeB.LcellDefinition: Hysteresis value prioritizing the ranking of the serving cell if CPICH Ec/No is used as a quality measure. Range: 0 – 40dB, 2 dB stepsRecommended Setting: 2

sIB4Qhyst2Object: LRNC.LNodeB.LcellDefinition: 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).Range: 0 – 40 dB, 2 dB stepsRecommended Setting: 2

sIB3TreselectionObject: LRNC.LNodeB.LcellDefinition: Time interval for reselectionRange: 0 ... 31 secRecommended Setting: 1

sIB4TreselectionObject: LRNC.LNodeB.LcellDefinition: Time interval for reselection, if sIB3EnableSIB4Indicator = TRUE (activation of SIB4 for connected mode).Range: 0 ... 31 secRecommended Setting: 1

BSIC VerificationObject: OMCU.EXTERNALS.EXTERNALGSMCELLDefinition: 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 / FalseRecommended Setting: True

3.2.2 UMTS-to-GSM IRAT Handover ParametersumtsToGsmHandoverObject: LRNCDefinition: The parameter enables/disables the UMTS to GSM handover feature per RNC.Range: True / False / NARecommended Setting: TRUE

14

mahoByGsmMeasurementsObject: LRNC.LNodeB.LcellDefinition: This parameter enables/disables the mobile-assisted handover algorithm (MAHO) for triggering the UMTS-to-GSM handover procedure.Range: True / False / NARecommended Setting: TRUE

borderCellToGsmObject: LRNC.LNodeB.Lcell, LRNC.FddExCellDefinition: Marks a cell as a border cell of the UMTS network to a GSM network.Range: True / False / NARecommended Setting: TRUE

compressedModeInterRatObject: LRNC.LNodeB.Lcell, LRNC.FddExCellDefinition: The parameter defines whether the use of the compressed mode is allowed in the cell for inter-RAT measurements.Range: True / False / NARecommended Setting: TRUE

GsmToUmtsHandoverObject: LRNC.LNodeB.LcellDefinition: The parameter enables/disables the GSM to UMTS handover feature on a per cell basis.Range: True / False / NARecommended Setting: FALSE

umts2GsmQActCM2D.thresholdObject: LRNC.LNodeB.Lcell, LRNC.FddExCellDefinition: UMTS CPICH Ec/No quality threshold for reporting event 2d (CM activation.)Range: -24 ... 0 dBRecommended Setting: -13

umts2GsmQActCM2D.timetotriggerObject: LRNC.LNodeB.Lcell, LRNC.FddExCellDefinition: 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 msecRecommended Setting: 320

umts2GsmQDeactCM2F.threshold Object: LRNC.LNodeB.Lcell, LRNC.FddExCellDefinition: UMTS CPICH Ec/No quality threshold for reporting event 2f (CM deactivation.)Range: -24 ... 0 dB

15

Recommended Setting: -11

umts2GsmQDeactCM2F.timetotriggerObject: LRNC.LNodeB.Lcell, LRNC.FddExCellDefinition: Specifies the time interval for which the UMTS quality threshold condition must be true before the UE sends an event 2f measurement report to the UTRAN.Range: enum msecRecommended Setting: 640

umts2GsmQTriggerMAHO.thresholdObject: LRNC.LNodeB.Lcell, LRNC.FddExCellDefinition: UMTS CPICH Ec/No quality threshold for reporting event 3a (IRAT handover trigger.)Range: -24 ... 0 dBRecommended Setting: -13

umts2GsmQTriggerMAHO.timetotriggerObject: LRNC.LNodeB.Lcell, LRNC.FddExCellDefinition: Specifies the time interval for which the UMTS quality threshold condition must be true before the UE sends an event 3a measurement report to the UTRAN.Range: enum msecRecommended Setting: 0

umts2GsmQTriggerMAHO.weightObject: LRNC.LNodeB.Lcell, LRNC.FddExCellDefinition: 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, NARecommended Setting: 1 umts2GsmHOMeas.combinedGsmNeighborListSizeObject: LRNCDefinition: 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-32Recommended Setting: 32

umts2GsmHOMeas.gsmQualityThresholdObject: LRNCDefinition: GSM quality threshold for reporting event 3a /3c. Range: -115 ... 0 dBRecommended Setting: -98

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

maxUlTxPwrObject: OMCU.EXTERNALS.EXTERNALGSMCELLDefinition: The maximum amount of power that the UE is allowed to use on theGSM Random Access Channel (RACH).Range: -50 to 33 dBmRecommended Setting: 33 (GSM_850), 30 (GSM_1900)

3.2.3 GSM Neighbor ListGSM 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.

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

GSM Neighbor listGSM Neighbor list

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 HussainBEGIN {FS=","};{

18

printf "modifyextgsmcell-externalgsmcell:name=\"OMCU="$1",EXTERNALS=1,EXTERNALGSMCELL="$2"\",lAC="$3",NCC="$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 4 2

Output example:Modifyextgsmcell-externalgsmcell: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 "modifyextgsmcell-externalgsmcell:name=\"OMCU="$1",EXTERNALS=1,EXTERNALGSMCELL="$2"\",lAC="$3";\n";

3.3 GSM Translation ConfigurationRelevant 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 CellsThe 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 ModeThe SI2quater message should contain 3G Measurement Parameters Description for the following parameters:

19

1. Qsearch_IThis 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_QoffsetThis 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_QminThis 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 ModeThe SI2quater message should contain 3G Measurement Parameters Description for the following parameters:

4. Qsearch_CThis 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_REPORTINGNumber 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_PRIOIndicates 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 InterconnectivityHere 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 MSCsBelow 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:Following step 5, Under Route Table Attributes: Route List should point to the new IMT Trunk Group.

21

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-NPA-xxxx), 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 there’s no need for IMT trunk growth. Step 9 and 10 are required to be executed for each MCC/MNC/LAC combination.

22

4 IRAT Handover Optimization

4.1 Border Cell Coverage OptimizationDuring 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

Figure 4-4: Examples of Border Cell Optimization Concerns

4.2 CS IRAT Handover Drive Test

4.2.1 Entrance CriteriaUMTS and GSM coverage and performance are optimized.

4.2.2 Test EquipmentIRAT 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 RouteFor 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

UMTS interior cellsUMTS border cells

GSM only cells

A

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 RegionNon-optimized border cell could also cause pilot pollution in the border region. Also check for any overshooting from an interior cell

B

C

D


GSM only cells

A




GSM only cells

A



B

C

D

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 ProcedureFor 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 AnalysisThe 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 Message Type Message Name Key Information / Comments

27

10:02:35.298 PM RRC SigMsg UL CCCH:RRCConnRequest 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 TMSI Reallocation Command 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 Call Proceeding 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 DL DCCH:MeasurementCtrl 10:02:40.017 PM RRC SigMsg DL DCCH:MeasurementCtrl Event 2d, 2f thresholds…… 10:03:06.996 PM RRC SigMsg UL DCCH:MeasReport EventID=e1a, PSC1=213 10:03:07.236 PM RRC SigMsg DL DCCH:MeasurementCtrl 10:03:07.441 PM RRC SigMsg UL DCCH:MeasReport EventID=e1a, PSC1=213 10:03:07.542 PM RRC SigMsg DL DCCH:ActiveSetUpdate Add PSC213 10:03:07.572 PM RRC SigMsg UL DCCH:ASUpdateComp 10:03:08.012 PM RRC SigMsg UL DCCH:MeasReport EventID=e1b, PSC1=213 10:03:08.104 PM RRC SigMsg DL DCCH:ActiveSetUpdate Remove PSC213 10:03:08.115 PM RRC SigMsg UL DCCH:ASUpdateComp 10:03:08.368 PM RRC SigMsg DL DCCH:MeasurementCtrl 10:03:09.113 PM RRC SigMsg UL DCCH:MeasReport EventID=e1b, PSC1=197 10:03:09.256 PM RRC SigMsg DL DCCH:ActiveSetUpdate Remove PSC197 10:03:09.266 PM RRC SigMsg UL DCCH:ASUpdateComp 10:03:09.609 PM RRC SigMsg DL DCCH:MeasurementCtrl 10:03:09.871 PM RRC SigMsg UL DCCH:MeasReport EventID=e2d, 1st time reporting e2d,

trigger for CM 10:03:10.170 PM RRC SigMsg DL DCCH:RBReconfign setting up config parameters for CM

10:03:10.236 PM RRC SigMsg UL DCCH:RBReconfComp 10:03:10.591 PM RRC SigMsg DL DCCH:MeasurementCtrl Compress mode order, IRAT neighbor

list 10:03:13.154 PM RRC SigMsg UL DCCH:MeasReport EventID=e1a, PSC1=157 10:03:13.528 PM RRC SigMsg DL DCCH:ActiveSetUpdate Add PSC157 10:03:13.551 PM RRC SigMsg UL DCCH:ASUpdateComp 10:03:14.447 PM RRC SigMsg DL DCCH:MeasurementCtrl 10:03:14.449 PM RRC SigMsg DL DCCH:MeasurementCtrl update IRAT neighbor list 10:03:17.481 PM RRC SigMsg UL DCCH:MeasReport EventID=e1a, PSC1=189 10:03:17.750 PM RRC SigMsg UL DCCH:MeasReport EventID=e1b, PSC1=349 10:03:17.831 PM RRC SigMsg DL DCCH:ActiveSetUpdate Add PSC189 10:03:17.854 PM RRC SigMsg UL DCCH:ASUpdateComp 10:03:18.479 PM RRC SigMsg DL DCCH:MeasurementCtrl 10:03:18.688 PM RRC SigMsg DL DCCH:MeasurementCtrl update IRAT neighbor list

28

10:03:18.817 PM RRC SigMsg DL DCCH:MeasurementCtrl 10:03:19.493 PM RRC SigMsg UL DCCH:MeasReport EventID=e2d 10:03:20.184 PM RRC SigMsg UL DCCH:MeasReport EventID=e1a, PSC1=501 10:03:20.639 PM RRC SigMsg DL DCCH:ActiveSetUpdate Add PSC501 10:03:20.662 PM RRC SigMsg UL DCCH:ASUpdateComp 10:03:21.201 PM RRC SigMsg DL DCCH:MeasurementCtrl 10:03:21.771 PM RRC SigMsg UL DCCH:MeasReport EventID=e3a 10:03:22.039 PM RRC SigMsg DL DCCH:MeasurementCtrl release CM (measurement identity 3)

10:03:22.041 PM RRC SigMsg DL DCCH:MeasurementCtrl release 3a (measurement identity 7)

10:03:22.954 PM RRC SigMsg UL DCCH:MeasReport EventID=e1b, PSC1=189 10:03:23.381 PM RRC SigMsg DL DCCH:Utran2GsmHOcmd IRAT handover command 10:03:23.599 PM GSM L3 SD5 DL RRM Physical Information 10:03:23.601 PM GSM L3 SD5 UL RRM Handover Complete IRAT handover to GSM successful

10:03:23.680 PM GSM L3 SD5 DL RRM Physical Information 10:03:23.791 PM RRC RrcState WCDMA RRC States 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,

29

cellSynchronisationInfoReportingIndicator FALSE, 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

30

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)/2umts2GsmQDeactCM2F.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 e3aWhen 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 IssuesGSM 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.

31

Figure 4-6: No e3a report after Compressed Mode Order resulting in call drop

32

Figure 4-7: Using BCCH-BSIC Pairs plot to identify missing GSM neighbor

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 (0-7). 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 CONTENTS

Lat Long Azi Ant.Ht BAND

ID009 ID009A 40091 536 46 4 6 417 47.815601 -116.863998 2 182.22 1900

ID009 ID009B 40092 528 36 3 6 417 47.815601 -116.863998 88 182.22 1900

ID009 ID009C 40093 538 4 0 4 417 517 548 555 47.815601 -116.863998 254 182.22 1900

ID013 ID013A 40131 532 51 5 1 417 47.943901 -116.702004 30 70.01 1900

ID013 ID013B 40132 540 66 6 6 417 47.943901 -116.702004 170 70.01 1900

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 cell’s 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 UE’s GSM neighbor list should be added to the strongest active set cell’s outGSMAdjCells list (as well as the RNC’s 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

33

MeasurementReport for 1a, 1b or 1c, the best Ec/Io active set member info tracked by the 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 IssuesWhen 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 IssueOne 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 :

34

{ 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, technologySpecificInfo gsm : { interRATCellIndividualOffset 0, bsic { ncc 5, bcc 7 }, frequency-band dcs1800BandUsed, bcch-ARFCN 176 } }, ===cell index 2, 3, 4 aren’t in the current IRAT list { interRATCellID 5, technologySpecificInfo gsm : { interRATCellIndividualOffset 0, bsic { ncc 2, bcc 7 }, frequency-band dcs1800BandUsed, 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

35

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 E2D2006-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 232006-02-28T20:26:33.588000-08:00 0 RRC measurementControl RELEASE [3] 2006-02-28T20:26:33.589000-08:00 0 RRC measurementControl RELEASE [7] 2006-02-28T20:26:35.590000-08:00 0 RRC measurementReport E1C2006-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.590000-08:00 0 RRC measurementReport E1C2006-02-28T20:26:36.594000-08:00 0 NBAP RadioLinkSetupRequestFDD 2006-02-28T20:26:36.646000-08:00 0 NBAP RadioLinkSetupResponseFDD 2006-02-28T20:26:36.648000-08:00 0 RRC activeSetUpdate 2006-02-28T20:26:36.720000-08:00 0 NBAP RadioLinkRestoreIndication 2006-02-28T20:26:36.949000-08:00 0 RRC activeSetUpdateComplete 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:36.983000-08:00 0 RRC measurementControl 2006-02-28T20:26:37.469000-08:00 0 RRC measurementReport E1C2006-02-28T20:26:37.475000-08:00 0 NBAP RadioLinkSetupRequestFDD 2006-02-28T20:26:37.540000-08:00 0 NBAP RadioLinkSetupResponseFDD 2006-02-28T20:26:37.543000-08:00 0 RRC activeSetUpdate 2006-02-28T20:26:37.789000-08:00 0 RRC activeSetUpdateComplete 2006-02-28T20:26:37.795000-08:00 0 NBAP RadioLinkDeletionRequest 2006-02-28T20:26:37.808000-08:00 0 NBAP RadioLinkDeletionResponse 2006-02-28T20:26:37.813000-08:00 0 RRC measurementControl 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 02006-02-28T21:22:57.153000-08:00 0 RRC measurementControl RELEASE [3] 2006-02-28T21:22:57.153000-08:00 0 RRC measurementControl RELEASE [7] 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 dcs18002006-02-28T21:22:59.475000-08:00 0 RANAP Iu-ReleaseCommand CAUSE: radioNetwork : successful-relocation 2006-02-28T21:22:59.485000-08:00 0 NBAP RadioLinkDeletionRequest

36

2006-02-28T21:22:59.505000-08:00 0 NBAP RadioLinkDeletionResponse

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 IssueWhen 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 Figure4-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

37

4.3.2.3 Invalid cGIIn 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 IssuesWhen 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 MSCAfter 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.

38

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 MSCAfter 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 MSCAfter 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 25.413 NotesHANDOVER FAILURE RELOCATION PREP. FAILURE

Ciphering algorithm not supported Requested ciphering and/or integrity

protection is not supported

Circuit pool mismatch 1

Equipment failure Relocation failure in target CN/RNC or target system

Invalid message contents Abstract Syntax Error

No radio resource available Relocation failure in target CN/RNC or target system

O and M intervention O and M intervention

39

Radio interface failure, reversion to old channel 2

Radio interface message failure Relocation failure in target CN/RNC or target system

Requested speech version unavailable Relocation failure in target CN/RNC or target system

Requested terrestrial resource unavailable Relocation failure in target CN/RNC or target system

Requested transcoding/rate adaptation unavailable Relocation failure in target CN/RNC or target system

Switch circuit pool 1

Terrestrial circuit already allocated Relocation failure in target CN/RNC or target system

Traffic load in the target cell higher than in the source cell

Traffic load in the target cell higher than in the source cell

Any other value Relocation failure in target CN/RNC or 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 FailureAnother 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.

40

4.3.5.1 GSM Cell in Handover Command Does Not Match the One in E3a TriggerWe 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: UL DCCH Length = 9 UL DCCH Message | Integrity Check Info | | Message Authentication Code = 00000110011001100000111011111110B | | RRC 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] | | | | | Verified BSIC = 5 = this is the reported interRATCellIDMessage Dump: 0x8333077F6A0448005043Time stamp : 983377254

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: DL DCCH Length = 90 DL DCCH Message | Integrity Check Info | | Message Authentication Code = 01010000101001001011011000011111B | | RRC Message Sequence Number = 8

41

| DL 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] | | | | | | | | | Inter RATCell ID = 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 valueMessage Dump: 0xED7857BBF18400448F831581C28739609682E83147203E0007FFFFE000000000000000003190B90207FFFFEFC88000Time 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 ResultsNAS decode of message 062B03850E72C12D05D0628E407C000FFFFFC000000

42

http://135.86.68.177/umtsdecoder

{ '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 =BCCH/BSIC of the cell in the HO command }, 'HandoverReference' => 45 } }, 'Protocol' => 'RRM'}

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 CandidateWhen 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 it’s 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 dominance of the close-in cell, Cingular customer should be requested to change the co-BCCH/BSIC planning and add the distant dominant cell to the GSM neighbor list.

43

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 HandoverUTRAN 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 MSCIncorrect 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.

4.3.6 IRAT Handover UTRAN Parameters OptimizationIf IRAT handover optimization issues discussed in the previous sections have all been identified and resolved, but the performance is still not acceptable, certain UTRAN

44

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 DropsWhen 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 pre-mature, 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).

45

Figure 4-9: Example of IRAT Failures without Call Drops

4.3.8 IRAT Drive Test Showing Significant GSM OriginationsNormally 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.62header Command Code : 16

46

IRAT Failures w/o Call DropsIRAT Failures w/o Call Drops

Length : 38 Log Code (Hex) : 0x512F 1.25 ms/40 counter (32 kHz clock) : 0 CFN : 190 1.25 ms counter : 281473991977431Channel type : (129) DL BCCHMessage type : System Information Type 2quaterLength : 23L2 Header L2 Length field Length : 1Skip indicator : 0Protocol discriminator : (6) Radio resources management messagesMessage type : 7Rest 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 [1 ] : Scrambling code : 112 Diversity : 0 [2 ] : Scrambling code : 156 Diversity : 0 [3 ] : Scrambling code : 212 Diversity : 0 [4 ] : Scrambling code : 220 Diversity : 0 [5 ] : Scrambling code : 236 Diversity : 0 [6 ] : Scrambling code : 260 Diversity : 0 [7 ] : Scrambling code : 284 Diversity : 0 [8 ] : Scrambling code : 297 Diversity : 0 [9 ] : Scrambling code : 369 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

47

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 OptimizationBorder 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.

48

5 IRAT Handover Performance MonitoringWhile drive test is an important and effective tool for investigating optimization issues and troubleshooting failures, it’s 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 MeasurementsThere 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) × 100Where:A = NumAttCMPrepB = 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) × 100Where:A = NumRBReconfAtt.CMB = 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.

49

http://umi.web.lucent.com/

5.2 Relocation Preparation Performance MeasurementsWhen 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 100Where:A = IRATHO.FailRelocPrepOutCS.FailTarSysB = 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 100Where:A = IRATHO.FailRelocPrepOutCS.sumB = IRATHO.FailRelocPrepOutCS.FailTarSysC = IRATHO.FailRelocPrepOutCS.T_RELOCprep_expD = IRATHO.AttRelocPrepOutCS

Any increase in relocation preparation failure due to TRELOCprep timer expiration will be reflected by the following formula:

(A/B) x 100Where:A = IRATHO.FailRelocPrepOutCS.T_RELOCprep_exp

50

B = IRATHO.AttRelocPrepOutCS

5.3 IRAT Handover Performance MeasurementsWhen 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.ConfUnacceptIRATHO.FailOutCS.PhyChnFailIRATHO.FailOutCS.ProtErr.

Any degradation (increase) in the following formula reflects potential problems discussed in section 4.3.4:

(A/B) x 100Where:A = IRATHO.FailOutCS.ConfUnacceptB = IRATHO.AttOutCS

Any degradation (increase) in the following formula reflects potential problems discussed in section 4.3.5:

(A/B) x 100Where:A = IRATHO.FailOutCS.PhyChnFailB = 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 100Where:A = IRATHO.TRELOCOverallB = IRATHO.AttOutCS

51

5.4 IRAT Handover MatrixIRAT 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.

52

6 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-382-

803R03.01 Issue2, October 2005

53

umts irat optimizationguideline

Documents