Wcdma kpi-analysis

26,541 views

Published on

Published in: Technology, Business
2 Comments
23 Likes
Statistics
Notes
  • Hi everybody, Why in some cases CE expansion cause increment in call drop rate?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • tks for share
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
26,541
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
4,816
Comments
2
Likes
23
Embeds 0
No embeds

No notes for slide

Wcdma kpi-analysis

  1. 1. W-Handover and Call Drop Problem Optimization Guide For internal use only Product name Confidentiality level WCDMA RNP For internal use only Product version Total 202 pages 3.3 W-Handover and Call Drop Problem Optimization Guide (For internal use only) Prepared by Jiao Anqiang Date 2006-03-16 Reviewed by Xie Zhibin, Dong Yan, Hu Wensu, Wan Liang, Yan Lin, Ai Hua, Xu Zili, and Hua Yunlong Date Reviewed by Wang Chungui Date Approved by Date
  2. 2. Huawei Technologies Co., Ltd. All Rights Reserved Revision Records Date Version Description Author 2005-02-01 2.0 Completing V2.0 W-Handover and Call Drop Problems. Cai Jianyong, Zang Liang, and Jiao Anqiang 2006-03-16 3.0 According to V3.0 guide requirements, reorganizing and updating V2.0 guide, focusing more on operability of on-site engineers. All traffic statistics is from RNC V1.5. The update includes: Updating flow chart for handover problem optimization Moving part of call drop due to handover problem to handover optimization part Specifying operation-related part to be more applicable to on-site engineers Updating RNC traffic statistics indexes to V1.5 Integrating traffic statistics analysis to NASTAR of the network performance analysis Optimizing some cases, adding new cases, and removing outdated cases and terms Moving content about handover and call drop to the appendix, and keeping operations related to them in the body Adding explanations to SRB&TRB and RL FAILURE. Jiao Anqiang 2006-04-30 3.1 Adding HSDPA-related description HSDPA handover DT/CQT flow, definitions of traffic statistics in HSDPA handover, HSDPA handover problems. Adding algorithms and flows of HSDPA handover. Zhang Hao and Li Zhen 2006-10-30 3.11 Adding V17-related handover description as below: Changes in signaling flow for H2D HHO Changes in triggering events of H2D and D2H D2H handover in HSDPA based on traffic and timers Wang Dekai
  3. 3. Date Version Description Author Updating description of HSDPA serving cell and traffic statistics of HSDPA-DCH handover Adding call drop indexes in HSDPA DT/statistics 2007-08-09 3.2 Adding HSUPA-related description. Zhang Hao 2008-12-15 3.3 Adding MBMS-related description. Yearly review WangDekai / Hu Wensu
  4. 4. Contents 2.1 Handover Performance Indexes 15 2.2 Call Drop Performance Indexes 18 3.1 DT/CQT Index Optimization Flow 19 3.1.1 SHO DT Index Optimization Flow 19 3.1.2 HHO CQT Flow 23 3.1.3 Inter-RAT Handover CQT Flow 26 3.1.4 DT/CQT Flow for HSDPA Handover 28 3.1.5 DT/CQT Flow for HSUPA Handover 31 3.1.6 SHO Ratio Optimization 31 3.1.7 MBMS Mobility Optimization 31 3.2 Traffic Statistics Analysis Flow 33 3.2.1 Analysis Flow for SHO Traffic Statistics 34 3.2.2 Analysis Flow of HHO Traffic statistics 35 3.2.3 Traffic Statistics Analysis Flow for Inter-RAT Handover 36 3.2.4 Traffic Statistics Analysis for HSDPA Handover 39 3.2.5 Traffic Statistics Analysis for HSUPA Handover 40 3.3 SHO Cost Optimization 42 4.1 Definition of Call Drop and Traffic Statistics Indexes 43 4.1.1 Definition of DT Call Drop 43 4.1.2 Descriptions of Traffic Statistics Indexes 43 4.2 DT/CQT Optimization Flow 44 4.2.1 Call Drop Cause Analysis 45 4.2.2 Frequently-adjusted Non-handover Algorithm Parameters 47 4.2.3 Judgment Tree for Call Drop Causes 48 4.3 Traffic Statistics Analysis Flow 49 4.3.1 Analyzing RNC CDR 50 4.3.2 Analyzing Causes to Call Drop 50 4.3.3 Check Cells 51 4.3.4 Further DT for Relocating Problems 51 4.4 Optimization Flow for Tracing Data 51 4.4.1 Obtaining Single Subscriber Tracing Message 52 4.4.2 Obtaining Information about Call Drop Point 53
  5. 5. 4.4.3 Analyzing Call Drop due to SRB Reset 53 4.4.4 Analyzing Call Drop due to TRB Reset 53 4.4.5 Analyzing Abnormal Call Drop 54 4.4.6 Performing CQT to Recheck Problems 54 4.5 Optimization Process for MBMS Call Drop 54 5.1 SHO Problems 56 5.1.1 Over High SHO Rate due to Improper SHO Relative Threshold 56 5.1.2 Delayed Handover due to Over Great Intra-frequency Filter Coefficient 57 5.1.3 Missing Neighbor Cell 58 5.1.4 Redundant Neighbor Cells 62 5.1.5 Pilot Pollution 65 5.1.6 Turning Corner Effect 71 5.1.7 Needlepoint Effect 74 5.1.8 Quick Change of Best server Signal 75 5.2 HHO Problems 77 5.2.1 Intra-frequency Ping-pong HHO due to Improperly Configured 1D Event Hysteresis 77 5.2.2 Delayed Origination of Inter-frequency Measurement due to Improper Inter-frequency Measurement Quantity 78 5.3 Inter-RAT Handover Problems 80 5.3.1 Ping-pong Reselection 80 5.3.2 PS Inter-RAT Ping-pong Handoff 81 5.3.3 Failure in handoff from 3G to the 2G network 82 5.3.4 Inter-RAT Handover Call Drop 84 5.4 Call Drop Problems 91 5.4.1 Over Weak Coverage 91 5.4.2 Uplink Interference 92 5.4.3 Abnormal Equipment 95 5.5 HSDPA-related Problems 97 5.5.1 HSDPA Handover Problems 97 5.5.2 HSDPA Call Drop 98 5.6 HSUPA Problems 100 7.1 SRB&TRB Reset 102 7.1.1 RAB 102 7.1.2 SRB 103 7.2 RL FAILURE 105 7.3 SHO Flow 110 7.3.1 Analyzing Signaling Flow for Adding Radio Link 110 7.3.2 Analyzing Signaling Flow for Deleting Radio Link 113 7.3.3 Analyzing Signaling Flow for Adding and Deleting Radio Link 114
  6. 6. 7.3.4 SHO Algorithm 117 7.4 Ordinary HHO Flow 124 7.4.1 Ordinary HHO (lur Interface and CELL_DCH State) 124 7.4.2 Inter-CN HHO Flow 126 7.5 HHO Algorithm 129 7.5.1 Intra-frequency HHO Algorithm 129 7.5.2 Inter-frequency HHO Algorithm 129 7.6 Concept and Classification of HSDPA Handover 131 7.6.1 Concept of HSDPA Handover 131 7.6.2 Classification of HSDPA Handover 131 7.6.3 Signaling Flow and Message Analysis of HSDPA Handover 132 7.6.4 HS-PDSCH Serving Cell Update due to DPCH SHO 133 7.6.5 HS-PDSCH Serving Cell Update due to DPCH HHO 140 7.6.6 DPCH Intra-frequency HHO with HS-DSCH Serving Cell Update 141 7.6.7 DPCH Inter-frequency HHO with HS-DSCH Serving Cell Update 142 7.6.8 Handover Between HSDPA and R99 144 7.6.9 Handover between HSDPA and GPRS 153 7.6.10 Direct Retry of HSDPA 153 7.6.11 Switch of Channel Type 155 7.7 Concept and Classification of HSUPA Handover 158 7.7.1 Basic Concepts 158 7.7.2 Classification of HSUPA Handover 159 7.7.3 Signaling Flow and Message Analysis of HSUPA Handover 159 7.7.4 SHO from a HSUPA Cell to a Non-HSUPA Cell 165 7.7.5 SHO from a Non-HSUPA Cell to a HSUPA Cell 170 7.7.6 Handover Between a HSUPA Cell and a GSM/GPRS Cell 173 7.7.7 Direct Retry of HSUPA 173 7.7.8 Switch between Channel Types 175 7.8 Handover from WCDMA to GSM 176 7.9 Handover from GSM to WCDMA 180 7.10 Handover from WCDMA to GPRS 183 7.11 Handover from GRPS to WCDMA 187 7.12 Parameters of Handover from 3G to 2G Network 190 7.13 Data Configuration for Supporting Bi-directional Roaming and Handover Between WCDMA and GSM/GPRS 193
  7. 7. Figures
  8. 8. SHO DT data analysis flow 20 Optimization flow for HHO CQT 25 Inter-RAT handover CQT flow 27 DT/CQT flow for HSDPA handover 30 Movement of the MBMS UE between PTM cells 31 Analysis flow for handover traffic statistics data 34 Voce inter-RAT outgoing handover flow 37 Flow chart for analyzing call drop 45 Judgment tree for call drop causes 48 Flow for analyzing call tracing 52 SHO relative threshold 57 Signaling flow recorded by UE before call drop 59 Scrambles recorded by UE active set and scanner before call drop 59 Scrambles in UE active set before call drop 60 UE intra-frequency measurement control point before call drop 61 Analyzing signaling of UE intra-frequency measurement control before call drop 61 Confirming missing neighbor cell without information from scanner 62 Location relationship of 2G redundant neighbor cells 64 Pilot pollution near Yuxing Rd. 65 Best ServiceCell near Yuxing Rd. 65 The 2nd best ServiceCell near Yuxing Rd. 66 The 3rd best ServiceCell near Yuxing Rd. 66 The 4th best ServiceCell near Yuxing Rd. 67 Composition of pilot pollution near Yuxing Rd. 67 RSSI near Yuxing Rd. 68 RSCP of Best ServiceCell near Yuxing Rd. 68 RSCP of SC270 cell near Yuxing Rd. 69 Pilot pollution near Yuxing Rd. after optimization 70 Best ServiceCell near Yuxing Rd. after optimization 70 RSCP of best ServiceCell near Yuxing Rd. after optimization 71
  9. 9. RSCP of SC270 cell near Yuxing Rd. after optimization 71 Turning corner effect-signals attenuation 72 Turning corner effect-signal attenuation recorded by the UE 72 Turning corner effect-traced signaling recorded by the RNC 73 Needle point-signal variance 74 Call drop distribution of PS384K intra-frequency hard handover 75 Signal distribution of cell152 vs. cell88 (signal fluctuation in handover areas) 76 Reporting 1D event 77 Increasing hysteresis to reduce frequently reporting of 1D event 78 Attenuation relationship of RSCP and Ec/No 79 Indoor 3G RSCP distribution 83 Analyzing weak signals 91 Uplink interference according to RNC signaling 93 Uplink interference according to UE signaling 93 Uplink interference information recorded by UE 94 RTWP variation of the cell 89767 94 RTWP variation of the cell 89768 95 Pilot information recorded by scanner 97 UMTS QoS structure 103 SRB and TRB at user panel 103 Signaling flow for adding radio link 111 Signaling flow for deleting radio link 113 SHO signaling flow for adding and deleting radio link 115 Measurement model 117 Example 1A event and trigger delay 119 Periodic report triggered by 1A event 120 Example of 1C event 121 Example 1D event 122 Restriction from hysteresis to measurement report 122 Example of 1E event 123 Example of 1F event 123
  10. 10. Ordinary HHO flow (lur interface and CELL_DCH state) 125 Ordinary inter-CN HHO flow 127 Intra-NodeB synchronization serving cell update 134 Inter-NodeB synchronization serving cell update 136 Inter-NodeB HS-DSCH cell update after radio link is added 138 Inter-NodeB HS-DSCH cell update during HHO (single step method) 140 DPCH intra-frequency HHO with HS-DSCH serving cell update 142 DPCH inter-frequency HHO with HS-DSCH serving cell update 143 handover from HSDPA to R99 144 Intra-frequency handover from R99 to R5 144 DPCH SHO with handover from HSDPA to R99 (inter-NodeB) 146 DPCH SHO with handover from R99 to HSDPA 147 Inter-NodeB SHO with handover from HSDPA to R99 (V17) 148 Intra-frequency HHO with handover from R5 to R99 149 Intra-frequency HHO with handover form R99 to R5 149 Intra-frequency HHO with handover from R5 to R99 (V17) 150 Inter-frequency HHO from HS-PDSCH to DCH 151 Inter-frequency HHO from DCH to HS-PDSCH 152 Handover between HSDPA and GPRS 153 Flow for direct retry during setup of a service 154 Direct retry triggered by traffic 154 Switch of channel type 156 Intra-frequency SHO between two HSUPA cells 160 Signaling for HSUPA cell update triggered by a 1D event 160 Signaling for HSUPA cell update triggered by a 1D event (reported by the monitor set) 161 Intra-frequency HHO between two HSUPA cells 161 Signaling for intra-frequency HHO between two HSUPA cells 162 Inter-frequency HHO between two HSUPA cells 162 Signaling for inter-frequency HHO between two HSUPA cells 163 Inter-RNC HSUPA handover 164
  11. 11. SHO from a HSUPA cell to a non-HSUPA cell 166 Addition of an R99 cell when the service is on the E-DCH 167 Intra-frequency HHO from a HSUPA cell to a non-HSUPA cell 168 Signaling for intra-frequency HHO from a HSUPA cell to a non-HSUPA cell 168 Inter-frequency HHO from a HSUPA cell to a non-HSUPA cell 169 Signaling for inter-frequency HHO from a HSUPA cell to a non-HSUPA cell 170 SHO from a non-HSUPA cell to a HSUPA cell 171 SHO from a non-HSUPA cell to a HSUPA cell (triggered by a 1B event) 171 Intra-frequency HHO from a non-HSUPA cell to a HSUPA cell 172 Signaling for intra-frequency HHO from a non-HSUPA cell to a HSUPA cell 172 Inter-frequency HHO from a non-HSUPA cell to a HSUPA cell 173 Direct retry from an R99 cell to a HSUPA cell 174 Direct retry from a HSUPA cell to an R99 cell 174 Direct retry from a HSUPA cell to another HSUPA cell 175 Switch between HSUPA channel types 175 Signaling flow for handover from WCDMA to GSM 177 Tracing signaling of handover from WCDMA to GSM 177 Signaling flow for handover from GSM to WCDMA 180 Tracing signaling of handover from GSM to WCDMA 181 Flow of handover from WCDMA to GPRS (1) 184 Flow of handover from WCDMA to GPRS (2) 184 Tracing signaling of handover from WCDMA to GPRS 185 Signaling flow for handover from GPRS to WCDMA (1) 187 Signaling flow for handover from GPRS to WCDMA (2) 188 Data configuration in the location area cell table 194 Data configuration of neighbor cell configuration table 195 Configuration table for external 3G cells 197 Configuration table for GSM inter-RAT neighbor cells 198 Configuration table for 2G reselection parameters 199 Parameter configuration table for inter-RAT handover 200
  12. 12. Tables Handover performance indexes and reference values 15 HSDPA handover performance indexes and reference value 16 HSUPA handover performance indexes and reference value 16 CDR index and reference value 18 SHO failure indexes 35 HHO failure indexes 35 Traffic statistics indexes of CS inter-RAT handover preparation failure 37 Traffic statistics indexes of PS inter-RAT outgoing handover failure 38 Types of CDR indexes 44 Thresholds of EcIo and Ec 45 Traffic statistics indexes for analyzing causes to call drop 50 Relationship between the filter coefficient and the corresponding tracing time 58 2G handover times 63 Best servers and other cells 67 Timers and counters related to the synchronization and asynchronization 105 Timers and counters related to call drop at lub interface 108 Flow of serving cell update triggered by different events in SHO 133 Scenarios of handover between HSDPA and R99 (V17) 145 Handover between two HSUPA cells 159 Handover between a HSUPA cell and a non-HSUPA cell 164 Parameters of handover from 3G to 2G 191 W-Handover and Call Drop Problem Optimization Guide Key words:
  13. 13. Handover, call drop, and optimization Abstract: This document, aiming at network optimization of handover success rate and call drop rate, details the specific network operation flow. In addition, it analyzes common problems during network optimization. Acronyms and abbreviations: Acronyms and Abbreviations Full Spelling AMR Adaptive MultiRate CHR Call History Record CDR Call Drop Rate DCCC Dynamic Channel Configuration Control RAN Radio Access Network RNP Radio Network Planning SRB Signaling Radio Bearer TRB Traffic Radio Bearer SHO Soft Handover HHO Hard Handover PCH Physical Channel CN Core Network O&M Operation and maintenance MNC Mobile Network Code
  14. 14. MCC Mobile Country Code LAC Location Area Code CIO Cell Independent Offset HSUPA High Speed Uplink Packet Access E-DCH Enhanced uplink Dedicated Channel E-AGCH E-DCH Absolute Grant Channel E-RGCH E-DCH Relative Grant Channel
  15. 15. 1 Introduction This document aims to meet the requirements by on-site engineers on solving handover and call drop problems and making them qualified during network optimization. It describes the methods for evaluating network handover and call drop performance, testing methods, troubleshooting methods, and frequently asked questions (FAQs). The appendix provides fundamental knowledge, principles, related parameters, and data processing tools about handover and call drop. This document serves to network KPI optimization and operation and maintenance (O&M) and helps engineers to locate and solve handover and call drop problems. The RRM algorithms and problem implementation in this document are based on V16 RNC. If some RRM algorithms are based on V17 RNC, they will be highlighted. HSUPA is introduced in V18 RNC, so the algorithms related to HSUPA are based on RNC V18. The following sections are updated: y Traffic Statistics Analysis for HSDPA Handover y Handover Between HSDPA and R99 y Direct Retry of HSDPA y Switch of Channel Type Actually handover is closely relevant to call drop. Handover failure probably leads to call drop. Therefore handover-caused call drop is arranged in handover success rate optimization part. The CDR optimization includes all related to call drop except handover- caused call drop. This document does not include usage of related tools. This document includes the following 12 chapters: y 1Introduction y 2Handover and Call Drop Performance Indexes y 3Handover Index Optimization y 4CDR Index Optimization y 5FAQs Analysis y 6Summary y 7Appendix The traffic statistics analysis is based on RNC V1.5 counter. It will be updated upon the update of RNC counters.
  16. 16. 2 Handover and Call Drop Performance Indexes 2.1 Handover Performance Indexes According to RNA KPI baseline document, 2.1 lists the handover performance indexes and reference values. 1. Handover performance indexes and reference values Index Service Statistics method Reference value SHO success rate CS&PS DT&Stat. 99% Intra-frequency HHO success rate Voice DT&Stat. 90% VP DT&Stat. 85% PS UL64K/DL 64K DT&Stat. 85% PS UL64K/DL 144K DT&Stat. 80% PS UL64K/DL 384K DT&Stat. 75% Inter-frequency Voice DT&Stat. 92%
  17. 17. HHO success rate VP DT&Stat. 90% PS UL64K/DL 64K DT&Stat. 90% PS UL64K/DL 144K DT&Stat. 87% PS UL64K/DL 384K DT&Stat. 85% Inter-RAT handover success rate Voice handover out DT&Stat. 95% PS handover out DT&Stat. 92% SHO ratio N/A DT 35% SHO cost N/A Stat. 40% 2.1 lists the HSDPA handover performance indexes and reference value. 2. HSDPA handover performance indexes and reference value Index Service Reference value HSDPA-HSDPA intra- frequency serving cell update PS (HSDPA) 99% HSDPA-HSDPA inter- frequency serving cell update PS (HSDPA) 92%
  18. 18. Index Service Reference value HSDPA-R99 intra-frequency handover PS (HSDPA) 99% HSDPA-R99 inter-frequency handover PS (HSDPA) 90% Success rate of R99-to-HSDPA cell handover PS (HSDPA) 85% HSDPA-to-GPRS inter-RAT handover PS (HSDPA) 92% Note: The HSDPA handover KPIs are to be updated after formal issue by WCDMA&GSM Performance Research Department. 3. HSUPA handover performance indexes and reference value Index Service Reference value Success rate of inter-cell SHO in HSUPA (including adding, replacing, and deleting) PS (HSUPA) ± Success rate of inter-cell SHO serving cell update in HSUPA PS (HSUPA) ± Success rate of DCH-to- E-DCH reconfiguration in SHO mode (including replacing and deleting) PS (HSUPA) ±
  19. 19. Index Service Reference value Success rate of E-DCH- to-DCH reconfiguration in SHO mode (including replacing and deleting) PS(HSUPA) ± Success rate of inter-cell intra-frequency HHO in HSUPA PS (HSUPA) ± Success rate of intra- frequency HHO from a HSUPA cell to a non- HSUPA cell PS (HSUPA) ± Success rate of DCH-to- E-DCH reconfiguration in single-link mode (the second step of inter- or intra-frequency HHO from a non-HSUPA cell to a HSUPA cell) PS (HSUPA) ± Success rate of inter-cell inter-frequency HHO in HSUPA PS (HSUPA) ± Success rate of inter- frequency HHO from a HSUPA cell to a non- HSUPA cell PS (HSUPA) ± Success rate of HSUPA- to-GPRS inter-RAT handover PS (HSUPA) 92% Note: The HSUPA handover KPIs are unavailable and to be updated after formal issue by WCDMA&GSM Performance Department. Decide the specific value according to project requirements or contract requirements of commercial network
  20. 20. 2.2 Call Drop Performance Indexes 2.2 lists the CDR index and reference value. 4. CDR index and reference value Index Service Statistics method Reference value CDR Voice DT&Stat.&CQT 2% VP DT&Stat.&CQT 2.5% PS planned full coverage rate DT&CQT 3% PS (UL DCH full coverage rate/DL HSDPA) DT 3% PS Stat. 10% PS (UL HSUPA/DL HSDPA) DT 3% The values listed in 2.2 are only for reference. Decide the specific value according to project requirements or contract requirements of commercial network. The call drop rate of HSDPA is not defined yet, so engineers use call drop rate of PS temporarily.
  21. 21. 3 Handover Index Optimization 3.1 DT/CQT Index Optimization Flow DT and CQT are important to network evaluation and optimization. DT/CQT KPIs act as standards for verifying networks. Overall DT helps to know entire coverage, to locate missing neighbor cells, and to locate cross-cell coverage. HHO and inter-RAT handover are used in coverage solutions for special scenarios, in while CQT is proper. The following sections describe the DT/CQT index optimization flow in terms of SHO, HHO, and inter-RAT handover. 3.1.1 SHO DT Index Optimization Flow 3.1.1 shows the SHO DT data analysis flow.
  22. 22. 2. SHO DT data analysis flow Inputting Analysis Data Perform DT. Collect DT data, related signaling tracing, RNC CHR, and RNC MML scripts. Obtaining When and Where the Problem Occurs During the test, SHO-caused call drop might occur or SHO might fail, so record the location and time for the problem occurrence. This prepares for further location and analysis.
  23. 23. Missing Neighbor Cell During the early optimization, call drop is usually due to missing neighbor cell. For intra- frequency neighbor cells, use the following methods to confirm intra-frequency missing neighbor cell. y Check the active set Ec/Io recorded by UE before call drop and Best Server Ec/Io recorded by Scanner. Check whether the Best Server scramble recorded by Scanner is in the neighbor cell list of intra- frequency measurement control before call drop. The cause might be intra-frequency missing neighbor cell if all the following conditions are met: y The Ec/Io recorded by UE is bad. y The Best Server Ec/Io is good. y No Best Server scramble is in the neighbor cell list of measurement control. y If the UE reconnects to the network immediately after call drop and the scramble of the cell that UE camps on is different from that upon call drop, missing neighbor cell is probable. Confirm it by measurement control (search the messages back from call drop for the latest intra-frequency measurement control message. Check the neighbor cell list of this measurement control message) y UEs might report detected set information. If corresponding scramble information is in the monitor set before call drop, the cause must be missing neighbor cell. Missing neighbor cell causes call drop. Redundant neighbor cells impacts network performance and increases the consumption of UE intra-frequency measurement. If this problem becomes more serious, the necessary cells cannot be listed. Therefore pay attention to redundant neighbor cells when analyzing handover problems. For redundant neighbor cells, see 5. Pilot Pollution Pilot pollution is defined as below: y Excessive strong pilots exist at a point, but no one is strong enough to be primary pilot. According to the definition, when setting rules for judging pilot pollution, confirm the following content: y Definition of strong pilot Whether a pilot is strong depends on the absolute strength of the pilot, which is measured by RSCP. If the pilot RSCP is greater than a threshold, the pilot is a strong pilot. Namely, . y Definition of "excessive" When judging whether excessive pilots exist at a point, the pilot
  24. 24. number is the judgment criteria. If the pilot number is more than a threshold, the pilots at a point are excessive. Namely, y Definition of "no best server strong enough" When judging whether a best server strong enough exist, the judgment criteria is the relative strength of multiple pilots. If the strength different of the strongest pilot and the No. strong pilot is smaller than a threshold, no best server strong enough exists in the point. Namely, y Based on previous descriptions, pilot pollution exists if all the following conditions are met: y The number of pilots satisfying is more than . y Set , , and , the judgment standards for pilot pollution are: y The number of pilots satisfying is larger than 3. y Improper Configuration of SHO Algorithm Parameters Solve the following two problems by adjusting handover algorithm parameters. y Delayed handover According to the signaling flow for CS services, the UE fails to receive active set update command (physical channel reconfiguration command for intra-frequency HHO) due to the following cause. After UE reports measurement message, the Ec/Io of original cell signals decreases sharply. When the RNC sends active set update message, the UE powers off the transmitter due to asynchronization. The UE cannot receive active set update message. For PS services, the UE might also fail to receive active set update message or perform TRB reset before handover. Delayed handover might be one of the following: y Turning corner effect: the Ec/Io of original cell decreases sharply and that of the target cell increases greatly (an over high value appears) y Needlepoint effect: The Ec/Io of original cell decreases sharply before it increases and the Ec/Io of target cell increase sharply for a short time. According to the signaling flow, the UE reports the 1a or 1c measurement report of neighbor cells before call drop. After this the RNC receives the event and sends the active set update message, which the UE fails to receive.
  25. 25. y Ping-pong Handover Ping-pong handover includes the following two forms y The best server changes frequently. Two or more cells alternate to be the best server. The RSCP of the best server is strong. The period for each cell to be the best server is short. y No primary pilot cell exists. Multiple cells exist with little difference of abnormal RSCP. The Ec/Io for each cell is bad. According to the signaling flow, when a cell is deleted, the 1A event is immediately reported. Consequently the UE fails because it cannot receive the active set update command. Abnormal Equipment Check the alarm console for abnormal alarms. Meanwhile analyze traced message, locate the SHO problem by checking the failure message. For help, contact local customer service engineers for confirm abnormal equipment. Reperforming Drive Test and Locating Problems If the problem is not due to previous causes, perform DT again and collect DT data. Supplement data from problem analysis. Adjustment and Implementation After confirming the cause to the problem, adjust the network by using the following pertinent methods: y For handover problems caused by pilot pollution, adjust engineering parameters of an antenna so that a best server forms around the antenna. For handover problems caused by pilot pollution, adjust engineering parameters of other antennas so that signals from other antennas becomes weaker and the number of pilots drops. Construct a new site to cover this area if conditions permit. If the interference is from two sectors of the same NodeB, combine the two cells as one. y For abnormal equipment, consult customer service engineer for abnormal equipment and transport layer on alarm console. If alarms are present on alarm console, cooperate with customer service engineers. y For call drop caused by delayed handover, adjust antennas to expand the handover area, set the handover parameters of 1a event, or increase CIO to enable handover to occur in advance. The sum of CIO and measured value is used in event evaluation process. The sum of initially measured value and CIP, as measurement result, is used to judge intra-frequency handover of UE and acts as cell border in handover algorithm. The larger the parameter is, the easier the
  26. 26. SHO is and UEs in SHO state increases, which consumes resources. If the parameter is small, the SHO is more difficult, which might affects receiving quality. y For needle effect or turning corner effect, setting CIO to 5 dB is proper, but this increases handover ratio. For detailed adjustment, see SHO-caused call drop of FAQs Analysis. y For call drop caused by Ping-pong handover, adjust the antenna to form a best server or reduce Ping-pong handover by setting the handover parameter of 1B event, which enables deleting a cell in active set to be more difficult. For details, increase the 1B event threshold, 1B hysteresis, and 1B delay trigger time. 3.1.2 HHO CQT Flow HHO Types HHO includes the following types: y Intra-frequency HHO The frequency of the active set cell before HHO is the same as that of the cell after HHO. If the cell does not support SHO, HHO might occur. HHO caters for cross-RNC intra- frequency handover without lur interface, limited resources at lur interface, and handover controlled by PS service rate threshold of handover cell. The 1D event of intra-frequency measurement events determines intra-frequency HHO. y Inter-frequency HHO The frequency of the active set cell before HHO is different from that of the cell after HHO. HHO helps to carry out balanced load between carriers and seamless proceeding. Start compression mode to perform inter-frequency measurement according to UE capability before inter-frequency HHO. HHO judgment for selecting cell depends on period measurement report. y Balanced load HHO It aims to realize balanced load of different frequencies. Its judgment depends on balanced load HHO. Inter-frequency coverage usually exists in special scenarios, such as indoor coverage, so CQT are used. The following section details the optimization flow for inter-frequency CQT. Optimization Flow of HHO CQT 3.1.2 shows the optimization flow for HHO CQT.
  27. 27. 1. Optimization flow for HHO CQT Adjustment The optimization flow for HHO is similar with that of SHO and the difference lies in parameter optimization. Confirming inter-frequency missing neighbor cell is similar to that of intra-frequency. When call drop occurs, the UE does not measure or report inter-frequency neighbor cells. After call drop, the UE re-camps on the inter-frequency neighbor cell. HHO problems usually refer to delayed handover and Ping-pong handover. Delayed HHO usually occurs outdoor, so call drop occurs when the UE is moving. There are three solutions: y Increase the threshold for starting compression mode. The compression mode starts before inter-frequency or inter-RAT handover. Measure the quality of inter-frequency or inter-RAT cell by compression mode. Compression mode starts if the CPICH RSCP or Ec/Io meets the conditions. RSCP is usually the triggering condition. The parameter "inter-frequency measurement quantity" decides to use CPICH Ec/No or Ec/Io as the measurement target for inter-frequency handover. When setting "inter- frequency measurement quantity", check that the cell is at the carrier coverage edge or in the carrier coverage center. If intra-frequency neighbor cells lie in all direction of the cell, the cell is defined as in the carrier coverage center. If no intra-frequency cell lies in a
  28. 28. direction of the cell, the cell is defined as at the carrier coverage edge. In the cell at the carrier coverage edge, when UE moves along the direction where no intra-frequency neighbor cell lies, the CPICH Ec/No changes slowly due to the identical attenuation rate of CPICH RSCP and interference. According to simulation, when CPICH RSCP is smaller than the demodulation threshold (±100 dBm or so), the CPICH Ec/No can still reach ±12 dB or so. Now the inter-frequency handover algorithm based on CPICH Ec/No is invalid. Therefore, for the cell at the carrier coverage edge, using CPICH RSCP as inter-frequency measurement quantity to guarantee coverage is more proper. In the cell in the carrier coverage center, use CPICH RSCP as inter-frequency measurement quantity, but CPICH Ec/No can better reflect the actual communication quality of links and cell load. Therefore use CPICH Ec/No as inter-frequency measurement quantity in the carrier coverage center (not the cell at the carrier coverage edge), and RSCP as inter-frequency measurement quantity in the cell at the carrier coverage edge. In compression mode, the quality of target cell (inter-frequency or inter-RAT) is usually measured and obtained. The mobility of MS leads to quality deterioration of the current cell. Therefore the requirements on starting threshold are: before call drop due to the quality deterioration of the current cell, the signals of the target cell must be measured and reporting is complete. The stopping threshold must help to prevent compression mode from starting and stopping frequently. The RNC can distinguish CS services from PS services for inter-frequency measurement. If the RSCP is smaller than ±95 dBm, compression mode starts. If the RSCP is greater than ±90 dBm, compression mode stops. Adjust RSCP accordingly for special scenarios. y Increase the CIO of two inter-frequency cells. y Decrease the target frequency handover trigger threshold of inter- frequency coverage. For Ping-pong HHO problems, solve them by increasing HHO hysteresis and delay trigger time. The intra-frequency HHO optimization is similar to that of inter-frequency. Decrease the hysteresis and delay trigger time of 1D event according to local radio environment to guarantee timely handover. 3.1.3 Inter-RAT Handover CQT Flow Flow Chat 3.1.3 shows the inter-RAT handover CQT flow.
  29. 29. 1. Inter-RAT handover CQT flow Data Configuration Inter-RAT handover fails due to incomplete configuration data, so pay attention to the following data configuration. y GSM neighbor configuration is complete on RNC. The configuration includes: y Mobile country code (MCC) y Mobile network code (MNC) y Location area code (LAC) y GSM cell identity (CELL ID) y Network color code (NCC) y Base station color code (BCC) y Frequency band indicator (FREQ_BAND) y Frequency number y Cell independent offset (CIO) Guarantee the correctness of the previous data and GSM network.
  30. 30. y Add location area cell information near 2G MSC to location area cell list of 3G MSC. The format of location area identity (LAI) is MCC + MNC + LAC. Select LAI as LAI type. Select Near VLR area as LAI class and add the corresponding 2G MSC/VLR number. The cell GCI format is: MCC + MNC + LAC + CI. Select GCI as LAI type. Select Near VLR area as LAI class and add the corresponding 2G MSC/VLR number. y Add data of WCDMA neighbor cells on GSM BSS. The data includes: y Downlink frequency y Primary scramble y Main indicator y MCC y MISSING NEIGHBOR CELL y LAC y RNC ID y CELL ID According to the strategies of unilateral handover of inter-RAT handover, if the data configuration is complete, the inter-RAT handover problems are due to delayed handover. A frequently-used solution is increasing CIO, increasing the threshold for starting and stopping compression mode, increasing the threshold to hand over to GSM. Causes The causes to call drop due to 3G-2G inter-RAT handover are as below: y After the 2G network modifies its configuration data, it does not inform the 3G network of modification, so the data configured in two networks are inconsistent. y Missing neighbor cell causes call drop. y The signals fluctuate frequently so call drop occurs. y Handset problems causes call drop. For example, the UE fails to hand over back or to report inter-RAT measurement report. y The best cell changes upon Physical channel reconfiguration. y Excessive inter-RAT cell are configured (solve it by optimizing number of neighbor cells). y Improperly configured LAC causes call drop (solve it by checking data configuration). 3.1.4 DT/CQT Flow for HSDPA Handover
  31. 31. Type According to the difference of handover on DPCH in HSDPA network, the HSDPA handover includes: y SHO or softer handover of DPCH, with HS-PDSCH serving cell update y Intra-frequency and inter-frequency HHO of DPCH, with HS- PDSCH serving cell update According to different technologies used in the serving cell before and after handover, HSDPA handover includes: y Handover in HSDPA system y Handover between HSDPA and R99 cells y Handover between HSDPA and GPRS cells Methods For HSDPA service coverage test and mobility-related test (such as HHO on DPCH with HS- PDSCH serving cell update, handover between HSDPA and R99, and inter-RAT handover), perform DT to know the network conditions. For location of HSDPA problems and non-mobility problems, perform CQT (in specified point or small area). Flow When a problem occurs, check R99 network. If there is similar problem with R99 network, solve it (or, check whether the R99 network causes HSDPA service problems, such as weak coverage, missing neighbor cell. Simplify the flow). 3.1.4 shows the DT/CQT flow for HSDPA handover.
  32. 32. 1. DT/CQT flow for HSDPA handover The problems with handover of HSDPA subscribers are usually caused by the faulty handover of R99 network, such as missing neighbor cell and improper configuration of handover parameters. When the R99 network is normal, if the handover of HSDPA subscribers is still faulty, the cause might be improper configuration of HSDPA parameters. Engineers can check the following aspects: y Whether the HSDPA function of target cell is enabled and the parameters are correctly configured. Engineers mainly check the words of cell and whether the power is adequate, whether the HS- SCCH power is low. These parameters might not directly cause call drop in handover, but lead to abnormal handover and lowered the user experience. y Whether the protection time length of HSDPA handover is proper. Now the baseline value is 0s. Set it by running SET HOCOMM. y Whether the threshold for R99 handover is proper. The handover flow for HSDPA is greatly different from that of R99, so the handover of R99 service may succeed while the HSDPA handover
  33. 33. may fail. For example, in H2D handover, when the UE reports 1b event, it triggers RB reconfiguration in the original cell, reconfigures service bearer to DCH, and updates the cell in active set. If the signals of the original cell deteriorate quickly now, the reconfiguration fails. y Whether the protection time length of D2H handover is proper. Now the baseline value is 2s. Set it by running SET HOCOMM. 3.1.5 DT/CQT Flow for HSUPA Handover The DT/CQT flow for HSUPA handover is similar to that for HSDPA. For details, refer to DT/CQT Flow for HSDPA Handover. For the test of HSUPA service coverage and mobility-related tests (such as the test of success rate of HSUPA serving cell update), perform DT to know the network conditions. For locating HSUPA problems and the problems unrelated to mobility, perform CQT (in specified spot or area). 3.1.6 SHO Ratio Optimization This part is to be supplemented. 3.1.7 MBMS Mobility Optimization Currently, the radio network controller (RNC) V18 supports only the broadcast mode of the multimedia broadcast multicast service (MBMS); the MBMS user equipment (UE) moves only between point-to-multipoint (PTM) cells.
  34. 34. 2. Movement of the MBMS UE between PTM cells The movement of the MBMS UE between PTM cells is similar to the movement of UE performing PS services in the CELL-FACH state. The UE performs the handover between cells through cell reselection and obtains a gain through soft combining or selective combining between two cells to guarantee the receive quality of the service. The UE first moves to the target cell and then sends a CELL UPDATE message to notify the serving radio network controller (SRNC) that the cell where the UE stays is changed. The SRNC returns a CELL UPDATE CONFIRM message. The UE receives an MBMS control message from the MCCH in the target cell and determines whether the MBMS radio bearer to be established is consistent with that of the neighboring cell. If they are consistent, the original radio bearer is retained. The MBMS mobility optimization, which guarantees that the UE obtains better quality of service at the edge of cells, covers the following aspects: y Optimize cell reselection parameters to guarantee that the UE can be reselected to the best cell in time. y Guarantee that the power of the FACH in each cell is large enough to meet the coverage requirement of the MBMS UE at the edge of the cells.
  35. 35. y Guarantee that the transmission time difference of the UE between different links meets the requirement of soft combing or selective combining*. y Guarantee that the power, codes, transmission, and CE resources of the target cell are not restricted or faulty, and that the MBMS service is successfully established. The UE can simultaneously receive the same MBMS service from two PTM cells and combine the received MBMS service. The UE supports two combining modes: Soft combining: The transmission time difference between the current cell and the neighboring cell is within (one TTI + 1) timeslots and the TFCI in each transmission time interval (TTI) is the same. Selective combining: The transmission time difference between the current cell and the neighboring cell is within the reception time window stipulated by the radio link controller (RLC). The SCCPCH is decoded and the transmission blocks are combined in the RLC PDU phase
  36. 36. 3.2 Traffic Statistics Analysis Flow The traffic statistics data is important to network in terms of information source. In addition, it is the major index to evaluate network performance. The handover traffic statistics data is includes RNC-oriented data and cell-oriented data. RNC ±oriented data reflects the handover performance of entire network, while cell-oriented data helps to locate problematic cells. The analysis flow for SHO, HHO, inter-RAT handover, and HSDPA handover is similar, but the traffic statistics indexes are different from them. 3.2 shows the analysis flow for handover traffic statistics data.
  37. 37. 3. Analysis flow for handover traffic statistics data 3.2.1 Analysis Flow for SHO Traffic Statistics The SHO success rate is defined as below: SHO success rate = SHO successful times/SHO times According to the flow, SHO includes SHO preparation process and SHO air interface process. The SHO preparation process is from handover judgment to RL setup completion. The SHO air interface process is active set update process. y Check the SHO success rate of entire network and cell in busy hour. If they are not qualified, analyze the problematic cells in details. y Sort the SHO (or softer handover) failure times of the cell by TOP N and locate the cells with TOP N failure times. List the specific
  38. 38. indexes of failure causes. If locating specific causes from traffic statistics is impossible, analyze the corresponding CHR. 3.2.1 lists the detailed traffic statistics indexes to SHO (or softer handover) failure and analysis. 1. SHO failure indexes Failure causes Analysis Configuration nonsupport The UE thinks the content of active set update for RNC to add/delete links does not support SHO. This scenario seldom exists in commercial networks. Synchronization reconfiguration nonsupport The UE feeds back that the SHO (or softer handover) for RNC to add/delete links is incompatible with other subsequent processes. The RNC guarantees serial processing upon flow processing. This cause is due to the problematic UE. Invalid configuration The UE thinks the content of active set update for RNC to add/delete links is invalid. This scenario seldom exists in commercial networks. No response from UE The RNC fails to receive response to active set update command for adding/deleting links. This is a major cause to SHO (or softer handover) failure. It occurs in areas with weak coverage and small handover area. RF optimization must be performed in the areas. y Perform DT to re-analyze problems. The traffic statistics data provides the trend and possible problems. Further location and analysis of problems involves DT and CHR to the cell. DT is usually performed on problematic cells and signaling flow at the UE side and of RNC is traced. For details, see 3.1.3. 3.2.2 Analysis Flow of HHO Traffic statistics The HHO traffic statistics includes outgoing HHO success rate and incoming HHO success rate: y Outgoing HHO Success Rate = Outgoing HHO Success Times/Outgoing HHO Times y Incoming HHO Success Rate = Incoming HHO Success Times/Incoming HHO Times Upon HHO failure, pay attention to indexes related to internal NodeB, between NodeBs, and between RNCs. 3.2.2 lists the HHO failure indexes.
  39. 39. 2. HHO failure indexes Failure cause Analysis HHO preparation failure Radio link setup failure Analyze RL setup failure. Other causes Analyze the problem further based on CHR logs. Internal NodeB/Between NodeBs/Between RNCs HHO failure Configuration nonsupport The UE thinks it cannot support the command for outgoing HHO, because it is incompatible with HHO. PCH failure The cause is probably weak coverage and strong interference. Synchronization reconfiguration nonsupport The UE feeds back HHO is incompatible with other consequent processes due to compatibility problems of UE. Cell update Cell update occurs upon outgoing HHO. These two processes lead to outgoing HHO failure. Invalid configuration The UE thinks the command for outgoing HHO as invalid. This is a compatibility problem of UE. Other causes Analyze the problem further based on CHR logs. 3.2.3 Traffic Statistics Analysis Flow for Inter-RAT Handover The inter-RAT handover success rate includes voice inter-RAT handover success rate and PS inter-RAT handover success rate. Voice Inter-RAT Outgoing Handover Success Rate = Voice Inter-RAT Outgoing Handover Success Times/Voice Inter-RAT Outgoing Handover Attempt Times Voice Inter-RAT Outgoing Handover Success Times: when the RNC sends a RELOCATION REQUIRED message. Voice Inter-RAT Outgoing Handover Attempt Times: during CS inter-RAT outgoing, when the RNC receives an IU RELEASE COMMAND message, with the reason value Successful Relocation, or Normal Release.
  40. 40. PS Inter-RAT Outgoing Handover Success Rate = PS Inter-RAT Outgoing Handover Success Times/PS Inter-RAT Outgoing Handover Implementation Times PS Inter-RAT Outgoing Handover Success Times: the RNC sends a CELL CHANGE ORDER FROM UTRAN message to UE. PS Inter-RAT Outgoing Handover Implementation Times: when the RNC receives an IU RELEASE COMMAND message, with the reason value Successful Relocation, or Normal Release. Voice Inter-RAT Outgoing Handover Success Rate The voice inter-RAT outgoing handover includes handover preparation process and implementation process. 3.2.3 shows the voice inter-RAT outgoing handover flow. 1. Voce inter-RAT outgoing handover flow During CS inter-RAT outgoing handover process, when the RNC sends a RELOCATION REQUIRED message to CN, if the current CS service is AMR voice service, count it as an inter-RAT handover preparation. When the RNC receives the IU RELEASE COMMAND message replied by CN, count it as inter-RAT outgoing handover success according to the SRNC cell being used by UE. If CS inter-RAT handover fails, check the failure statistics indexes listed in 3.2.3. 1. Traffic statistics indexes of CS inter-RAT handover
  41. 41. preparation failure Failure cause Analysis RNC-level inter-RAT outgoing handover preparation failure Expiration of waiting for SRNS relocation command The CN does not respond the corresponding command for handover preparation request, because the CN parameter configuration or the corresponding link connection is problematic. To solve this problem, analyze the causes according to CN and BSS signaling tracing. SRNS relocation cancellation After the RNC requests handover preparation, it receives the release command from CN. This includes the following two cases: y The inter-RAT handover request occurs during signaling process like location update, so the flow is not complete before location update is complete. Finally the CN sends a release message. y The subscribers that are calling hang UE before handover preparation, so the CN sends a release message. The previous two cases, despite incomplete handover, are normal nesting flows. SRNS relocation expiration It corresponds to incorrect configuration of CN, so you must analyze the causes according to CN and BSS signaling tracing. SRNS relocation failure in target CN/RNC/system It corresponds to incorrect configuration of CN or BSS nonsupport, so you must analyze the causes according to CN and BSS signaling tracing. Unknown target RNC It corresponds to incorrect configuration of MSC parameters without information like LAC of target cell, so you must check the parameter configuration. It occurs easily after adjustment of 2G networks. Unavailable resource It corresponds to incorrect configuration of MSC parameters or unavailable BSC resources, so you must analyze the causes according to CN and BSS signaling tracing. Other causes Analyze the causes according to CN and BSS signaling tracing. Cell-level inter-RAT outgoing handover preparation failure SRNS relocation expiration The CN parameter configuration or the corresponding link connection is problematic, so you must analyze the causes according to CN and BSS
  42. 42. signaling tracing. SRNS relocation failure in target CN/RNC/system It corresponds to incorrect configuration of CN or BSS nonsupport, so you must analyze the causes according to CN and BSS signaling tracing. SRNS relocation nonsupport in target CN/RNC/system The BSC fails to support some parameters of inter-RAT handover request, so you must analyze the causes according to CN and BSS signaling tracing. Other causes Analyze the causes according to CN and BSS signaling tracing. RNC-level/CELL-level inter-RAT outgoing handover failure Configuration nonsupport The UE fails to support the handover command in the network, so the UE is incompatible with the handover command. PCH failure The 2G signals are weak or the interference is strong so the UE fails to connect to the network. Other causes Analyze the problem further according to CHR logs and CN/BSS signaling tracing. PS Inter-RAT Handover Success Rate After the RNC sends the CELL CHANGE ORDER FROM UTRAN message, the PS inter- RAT outgoing handover fails if it receives the CELL CHANGE ORDER FROM UTRAN FAILURE message. You must check the indexes listed in 3.2.3. 1. Traffic statistics indexes of PS inter-RAT outgoing handover failure Failure cause Analysis RNC-level/CELL-level PS inter-RAT outgoing handover preparation failure
  43. 43. Configuration nonsupport The UE fails to support the handover command of the network, because the UE is incompatible with the command. PCH failure The 2G signals are weak or the interference is strong, so the UE fails to access the network. Radio network layer cause The UE is probably incompatible. The UE detects that the sequence number of SNQ in the AUTN message is correct, so the handover fails. The value is synchronization failure. Transport layer cause The corresponding transport link is abnormal. Other causes You must analyze the causes according to CN and BSS signaling tracing. 3.2.4 Traffic Statistics Analysis for HSDPA Handover HSDPA switch includes y H-H (HS-DSCH to HS-DSCH) intra-frequency serving cell update y H-H inter-frequency serving cell update y HSDPA-R99 intra-frequency switch y HSDPA-R99 inter-frequency switch y HSDPA-GPRS switch The traffic statistics indexes are defined as below: y Success rate of H-H intra-frequency serving cell update = (Times of successful update of serving cell)/(attempt times update of serving cell) When the RNC sends UE the PHYSICAL CHANNEL RECONFIGURATION message, if the serving cell is updated, engineers count the attempt times of serving cell in the original serving cell. When the RNC receives the PHYSICAL CHANNEL RECFG COMPLETE message, if the serving cell changes, the RNC counts the times of successful update of serving cells in the original serving cell when the UE is in the SHO mode not in the HHO mode. y Success rate of H-H inter-frequency serving cell update = Times of successful outgoing inter-frequency HHO from HS-DSCH to HS- DSCH/Times of requested outgoing inter-frequency HHO from HS- DSCH to HS-DSCH When the RNC sends UE the PHYSICAL CHANNEL RECONFIGURATION message, and the inter-frequency HHO is from HS-DSCH to HS-DSCH, the RNC counts the times of requested outgoing inter-frequency HHO from HS-DSCH to HS-DSCH. When the RNC receives the PHYSICAL CHANNEL RECFG COMPLETE message from UE, and the inter-frequency HHO is from HS-DSCH to HS-DSCH, engineers count the times of successful outgoing inter-frequency HHO from HS-DSCH to HS-DSCH.
  44. 44. y Success rate of H-H inter-frequency serving cell update = successful times of outgoing inter-frequency HHO from HS-DSCH to HS- DSCH/attempt times HHO from DCH to HS-DSCH in the cell When the RNC sends the UE the PHYSICAL CHANNEL RECONFIGURATION message, if the switch is the inter-frequency HHO from HS-DSCH to HS-DSCH, the RNC counts the successful times of inter-frequency HHO from HS-DSCH to HS-DSCH in the cell. y Success rate of H-to-R99 intra-frequency SHO = successful times of switch from HS-DSCH to DCH in multi-link mode in the cell/attempt times switch from HS-DSCH to DCH in multi-link mode in the cell. Success rate of R99-to-H intra-frequency SHO = successful times of switch from DCH to HS-DSCH in multi-link mode in the cell/attempt times switch from DCH to HS-DSCH in multi-link mode in the cell. In the DCCC or RAB MODIFY process, if the RNC decides to switch the channel in the cell, it sends the UE the RF RECONFIGURATION message. According to the channel state of the UE before and after reconfiguration, the RNC counts the previous indexes in the HSDPA serving cell. y Success rate of H-to-R99 intra-frequency HHO = successful times of outgoing intra-frequency HHO from HS-DSCH to DCH in the cell/attempt times outgoing intra-frequency HHO from HS-DSCH to DCH in the cell. When the RNC sends the UE the PHYSICAL CHANNEL RECONFIGURATION message, if the switch is the intra-frequency switch from HS-DSCH to DCH, the RNC counts the attempt times of inter-frequency HHO from HS-DSCH to DCH in the cell. When the RNC receives the PHYSICAL CHANNEL RECFG COMPLETE message from the UE, if the switch is the intra-frequency HHO from HS-DSCH to DCH, the RNC counts the successful times of outgoing intra-frequency HHO from HS-DSCH to DCH in the cell. Success rate of H-to-R99 inter-frequency switch update The RNC algorithm is unavailable now, so this index is unavailable. y Success rate of H-to-R99 inter-frequency switch update = successful times of outgoing HHO from HS-DSCH to DCH in the cell/attempt times outgoing inter-frequency HHO from HS-DSCH to DCH in the cell When the RNC sends the UE the PHYSICAL CHANNEL RECONFIGURATION message, if the switch is the inter-frequency switch from HS-DSCH to DCH, the RNC counts the attempt times inter-frequency HHO from HS-DSCH to DCH in the cell. When the RNC receives the PHYSICAL CHANNEL RECFG COMPLETE message from the UE, if the switch is the inter-frequency HHO from HS-DSCH to DCH, the RNC counts the successful times of outgoing inter-frequency HHO from HS-DSCH to DCH in the cell. Success rate of R99-to-H The RNC algorithm is unavailable now, so this index is unavailable.
  45. 45. y Success rate of R99-to-H switch = successful times of switch from DCH to HS-DSCH in the cell/attempt times of switch from DCH to HS-DSCH in the cell In the DCCC or RAB MODIFY process, if the RNC decides to switch the channel in the cell, it sends the UE the RF RECONFIGURATION message. According to the channel state of the UE before and after reconfiguration, the RNC counts the attempt times of switch from DCH to HS-DSCH in the HSDPA serving cell. In the DCCC or RAB MODIFY process, if the RNC receives the RB RECONFIGURATION COMEPLTE message from UE, and the reconfiguration enables UE to switch from the DCH to HS- DSCH in the same cell, the RNC counts the successful times of switch from DCH to HS- DSCH in the HSDPA serving cell. y Success rate of H-to-GPRS handover update The traffic statistics does not include the index, and the index will be supplemented later. The causes to failure and analysis methods will be summarized later. 3.2.5 Traffic Statistics Analysis for HSUPA Handover The traffic statistics indexes for HSUPA are defined as below: y Success rate of SHO between HSUPA cells (including adding, replacing, and deleting) = attempt times of active set update/complete times of active set update. y Success rate of SHO serving cell update between HSUPA cells = successful times of SHO serving cell update/attempt times of SHO serving cell update. y Success rate of reconfiguration from DCH to E-DCH in the cell (SHO, intra-frequency HHO, and inter-frequency HHO) = successful times of handover from DCH to E-DCH/attempt times of handover from DCH to E-DCH. y Success rate of reconfiguration from E-DCH to DCH in the cell (including adding and replacing) = successful times of handover from E-DCH to DCH in SHO mode/attempt times of handover from E-DCH to DCH in SHO mode. y Success rate of intra-frequency HHO serving cell between HSUPA cells = successful times of intra-frequency HHO serving cell between HSUPA cells/attempt times of intra-frequency HHO serving cell between HSUPA cells. y Success rate of intra-frequency HHO from E-DCH to DCH from a HSUPA cell to a non-HSUPA cell = successful times of intra- frequency HHO from E-DCH to DCH/attempt times of intra- frequency HHO from E-DCH to DCH. y Success rate of inter-frequency HHO serving cell update between HSUPA cells = successful times of inter-frequency HHO serving cell
  46. 46. update between HSUPA cells/attempt times of inter-frequency HHO serving cell update between HSUPA cells. y Successful times of inter-frequency HHO from a HSUPA cell to a non-HSUPA cell = successful times of inter-frequency HHO from E- DCH to DCH/request times of inter-frequency HHO from E-DCH to DCH.
  47. 47. 3.3 SHO Cost Optimization To be supplemented.
  48. 48. 4 CDR Index Optimization 4.1 Definition of Call Drop and Traffic Statistics Indexes 4.1.1 Definition of DT Call Drop According to the air interface signaling recorded at the UE side, during connection, DT call drop occurs when the UE receives: y Any BCH message (system information) y The RRC Release message with the release cause Not Normal. y Any of the CC Disconnect, CC Release Complete, CC Release message with the release cause Not Normal Clearing, Not Normal, or Unspecified. 4.1.2 Descriptions of Traffic Statistics Indexes A generalized CDR consists of CN CDR and UTRAN CDR. RNO engineers focus on UTRAN CDR, so the following sections focus on KPI index analysis at UTRAN side. The related index at UTRAN side is the number of RAB for each service triggered by RNC. It consists of the following two aspects: y After the service is set up, the RNC sends CN the RAB RELEASE REQUEST message. y After the service is set up, the RNC sends CN the IU RELEASE REQUEST message. Afterwards, it receives the IU RELEASE COMMAND sent by CN. Upon statistics, sort them by specific services. Meanwhile, traffic statistics includes the cause to release of RAB of each service by RNC. CS CDR is calculated as below: PS CDR is calculated as below: The failure cause indexes are sorted in 4.1.2.
  49. 49. 2. Types of CDR indexes CDR type Cause Corresponding signaling process Due to air interface RF RLC reset and RL Failure Expiration of process timer RB RECFG Expiration of PHY/TRCH/SHO/ASU HHO failure Not due to air interface Hardware failure The transport failure between RNC and NodeB. NCP reports failure. FP synchronization failure. Transport layer failure ALCAP report failure Subscribers are released by force by MML O&M intervention The definition of RAN traffic statistics call drop is according to statistics of lu interface signaling, including the times of RNC's originating RAB release request and lu release request. The DT call drop is defined according to the combination of messages at air interface and from non-access lay and cause value. They are inconsistent. 4.2 DT/CQT Optimization Flow 4.2 shows flow chart for analyzing call drop.
  50. 50. 2. Flow chart for analyzing call drop 4.2.1 Call Drop Cause Analysis Call drop occurs usually due to handover, which is described in chapter 3. The following sections describe the call drop not due to handover. Weak Coverage For voice services, when CPICH Ec/Io is greater than ±14 dB and RSCP is greater than ± 100 dBm (a value measured by scanner outside cars), the call drop is usually not due to weak coverage. Weak coverage usually refers to weak RSCP. 4.2.1 lists the thresholds of Ec/Io and Ec (from an RNP result of an operator, just for reference).
  51. 51. 1. Thresholds of EcIo and Ec Ser vic e Bit rat e of ser vic e D L E b N o EcIo thres holds Ec thres holds CS 12.2 12.2 8.7 ±13.3 ±103.1 CS 64 64 5.9 ±11.9 ±97.8 PS 64 64 5.1 ±12.7 ±98.1 PS 128 128 4.5 ±13.3 ±95.3 PS 384 384 4.6 ±10.4 ±90.6 Uplink or downlink DCH power helps to confirm the weak coverage is in uplink or downlink by the following methods. y If the uplink transmission power reaches the maximum before call drop, the uplink BLER is weak or NodeB report RL failure according to single subscriber tracing recorded by RNC, the call drop is probably due to weak uplink coverage. y If the downlink transmission power reaches the maximum before call drop and the downlink BLER is weak, the call drop is probably due to weak downlink coverage. In a balanced uplink and downlink without uplink or downlink interference, both the uplink and downlink transmit power will be restricted. You need not to judge whether uplink or downlink is restricted first. If the uplink and downlink is badly unbalanced, interference probably exists in the restricted direction. A simple and direct method for confirming coverage is to observe the data collected by scanner. If the RSCP and Ec/Io of the best cell is low, the call drop is due to weak coverage. Weak coverage might be due to the following causes: y Lack of NodeBs y Incorrectly configured sectors y NodeB failure due to power amplifier failure
  52. 52. The over great indoor penetration loss causes weak coverage. Incorrectly configured sectors or disabling of NodeB will occur, so at the call drop point, the coverage is weak. You must distinguish them. Interference Both uplink and downlink interference causes call drop. In downlink, when the active set CPICH RSCP is greater than ±85 dBm and the active set Ec/Io is smaller than ±13 dB, the call drop is probably due to downlink interference (when the handover is delayed, the RSCP might be good and Ec/Io might be weak, but the RSCP of Ec/Io of cells in monitor set are good). If the downlink RTWP is 10 dB greater than the normal value (±107 to ±105 dB) and the interference lasts for 2s±3s, call drop might occur. You must pay attention to this. Downlink interference usually refers to pilot pollution. When over three cells meets the handover requirements in the coverage area, the active set replaces the best cell or the best cell changes due to fluctuation of signals. When the comprehensive quality of active set is bad (CPICH Ec/Io changes around ±10 dB), handover failure usually causes SRB reset or TRB reset. Uplink interference increases the UE downlink transmit power in connection mode, so the over high BLER causes SRB reset, TRB reset, or call drop due to asynchronization. Uplink interference might be internal or external. Most of scenario uplink interference is external. Without interference, the uplink and downlink are balanced. Namely, the uplink and downlink transmit power before call drop will approach the maximum. When downlink interference exists, the uplink transmit power is low or BLER is convergent. When the downlink transmit power reaches the maximum, the downlink BLER is not convergent. It is the same with uplink interference. You can use this method to distinguish them. Abnormality Analysis If the previous causes are excluded, the call drop might due to problematic equipment. You need to check the logs and alarms of equipment for further analysis. The causes might be as below: y An abnormal NodeB causes failure of synchronization, so links keeps being added and deleted. y The UE does not report 1a measurement report so call drop occurs. You need to focus on the call drop due to abnormal testing UE, which occurs easily during CQT. Namely, the data recorded in DT does not contain the information reported by UE for a period. HSPA Call Drop Analysis For HSPA call drop analysis, refer to previous causes to R99 call drop. 4.2.2 Frequently-adjusted Non-handover Algorithm Parameters The frequently-adjusted non-handover algorithm parameters in call drop are as below: Maximum Downlink Transmit Power of Radio Link Configuring the transmit power of dedicated link to a great value helps to eliminate call drop points due to weak coverage, but it brings interference. The power of a single subscriber is
  53. 53. allowed to be great, so the subscriber might impact other subscribers or lower downlink capacity of system when the subscriber consumes great power at the edge of a cell. The configuration of downlink transmit power is usually provided by link budget. An increase or decrease of 1±2 dB has little impact on call drop in signal DT, but it can be seen from traffic statistics indexes. The CDR of some cells is high due to weak coverage, you can increase the maximum transmit power of DCH. The access failure probability of some cells is high due to over high load, you can lower the maximum downlink transmit power of radio link. Maximum Retransmission Times of Signaling and Services When the BLER of the channel is high, the signaling is reset because the retransmission reaches the maximum times. A reset of signaling causes call drop. The services using AM mode for service transmission will also retransmit signaling. If the retransmission reaches the maximum times, the signaling is reset. The system configures the maximum reset times. When the reset times reaches the maximum, the system starts to release the service, which causes call drop. The default configuration of system guarantees that burst blocks will not cause abnormal call drop, and call drop occurs when UE moves to an area with weak coverage and when the reset is time, so the system releases resources. In some scenarios, burst interference or needle effect exists, so 100% block error occurs during burst interference. If you want have less call drop, increase the retransmission times improper to resist burst interference. This parameter is configured for RNC. 4.2.3 Judgment Tree for Call Drop Causes Based on various causes to call drop, the judgment tree for analyzing call drop is as shown in 4.2.3.
  54. 54. 1. Judgment tree for call drop causes Preparing Data The data to be prepared include: y Data files collected by DT y Single subscriber tracing recorded by RNC y CHR recorded by RNC Obtaining Call Drop Location You need to use special software to process DT data. For example, the software Assistant helps to obtain call drop time and location, PICH data collected by scanner, information about active set and monitor set collected by UE, and the signaling flow. Analyzing Signal Variation of Best server From Scanner Analyze the signal variation of best server from scanner.
  55. 55. y If the signals of best server are stable, analyze RSCP and Ec/Io. y If the signals of best server fluctuate sharply, you must analyze the quick variation of best server signals and the situation without best server. Consequently you can analyze call drop due to ping-pong handover. Analyzing RSCP and Ec/Io of Best cell Observe the RSCP and Ec/Io of best cell according to scanner. y If both RSCP and Ec/Io are bad, call drop must be due to weak coverage. y If RSCP is normal but Ec/Io is bad (delayed handover is excluded, intra-frequency neighbor cell interference), call drop must be due to downlink interference. y If both RSCP and Ec/Io are normal, When the cell in UE active set is inconsistent with the best cell according to scanner, call drop must be due to missing neighbor cell and delayed handover. When the cell in UE active set is consistent with the best cell according to scanner, call drop must be due to uplink interference or must be abnormal. Re-perform DT to Solve Problems A DT might not help to collect all information needed to locate call drop problems, so further DTs are needed. In addition, you can confirm whether the call drop point is random or fixed by further DT. You must eliminate fixed call drop points, but you can choose to eliminate random call drop points. 4.3 Traffic Statistics Analysis Flow When analyzing traffic statistics indexes, you need to check RNC call drop indexes and master the overall situation of network operation. Meanwhile, you must analyze the cell concern for detailed call drop indexes. You can obtain call drop of different services and approximate causes to call drop by using traffic statistics analyzers. To analyze traffic statistics indexes, you must analyze the cells with obviously abnormal indexes. If the KPIs of the cell are good, there must be problems with version, hardware, transport, antenna-feeder, or data. Based on alarms, you can check these aspects. If there are no abnormalities, you can form a list of cells with bad KPIs by classifying sector carriers. Analyze traffic statistics indexes of these cells (such as more indexes related, analyzing the interval between two periods, indexes leading to call drop, and handover indexes), and check the causes to call drop based on CHR. When solving problems, you need to focus on one index and combine other indexes. When the traffic volume reaches a certain level, the traffic statistics indexes work. For example, a CDR of 50% does not indicate a bad network. Only when the absolute value of call times, call success times, and total times of call drop is meaningful in terms of statistics, the traffic statistics indexes work. The flow for analyzing traffic statistics is as below.
  56. 56. 4.3.1 Analyzing RNC CDR The RNC CDR involves the number of RAB of each service triggered by RNC, including two aspects: y After a service is established successfully, the RNC sends CN the RAB RELEASE REQUEST message. y After a service is established successfully, the RNC sends CN the IU RELEASE REQUEST message, and then receives the IU RELEASE COMMAND message sent by CN. AMR CDR = VS.RAB.Loss.CS.RF.AMR / VS.RAB.SuccEstab.AMR. VP CDR = VS.RAB.Loss.CS.Conv64K / VS.RAB.SuccEstCS.Conv.64. To analyze PS call drop of various rates, you can analyze the following indexes: y VS.RAB.Loss.PS.64K / VS.RAB.SuccEstPS.64 y VS.RAB.Loss.PS.128K / VS.RAB.SuccEstPS.128 y VS.RAB.Loss.PS.384K / VS.RAB.SuccEstPS.384 Based on analysis of previous indexes, you can obtain the performance of various services and rates in the network, as well as SHO/HHO call drop. More important, you can obtain the cells with bad indexes and periods. 4.3.2 Analyzing Causes to Call Drop In traffic statistics analysis, you must analyze the major causes to call drop. 4.3.2 lists the major indexes for analyzing traffic statistics. 1. Traffic statistics indexes for analyzing causes to call drop Failure cause Analysis OM interference The O&M tasks cause call drop. Causes due to RAB preemption High-priority preemption causes release of CS links. This kind of call drop occurs when the load and resources are limited. Performing expansion depends on the times of occurrence. Causes due to UTRAN The causes due to UTRAN in the cell lead to abnormal release of link. This corresponds to abnormal process, so you must further analyze it based on CHR.
  57. 57. Uplink RLC reset Uplink RLC reset causes release of links, because the coverage quality (including missing neighbor cell and over mall handover area) is bad. Downlink RLC reset Downlink SRB reset causes release of links, because the coverage quality (including missing neighbor cell and over mall handover area) is bad. Uplink synchronization failure Uplink synchronization failure causes abnormal release of links. The coverage quality (including missing neighbor cell and over mall handover area) is bad, so the UE powers off the transmitter abnormally or uplink demodulation is asynchronous. Downlink synchronization failure Downlink synchronization failure causes abnormal release of links. The coverage quality (including missing neighbor cell and over mall handover area) is bad, so the UE powers off the transmitter abnormally or uplink demodulation is asynchronous. No response of UU port The UE air interface fails to respond the command transmitted by system, because the coverage is bad. Other RF causes It is due to RF causes and the coverage quality is bad. Abnormal AAL2 link The RNC detects that AAL2 Path at CS lu interface is abnormal, so the system originates an abnormal release. The problem might be due to abnormal transport equipment. Immediate normal release during RB establishment is counted by statistics as abnormal release as the cause. Abnormal GTPU The RNC detects the GTPU at PS lu interface is abnormal, so the system originates an abnormal release. The problem is due to equipment failure. Other causes You need to analyze the abnormal call drop based on RNC logs. You can classify the previous indexes 4.3.2 by the classification of previous chapters. They fall into air interface causes (RF and flow expiration) and not due to air interface causes (hardware failure, transport failure, and subscribers' interference). Therefore you can have an overall master of network and obtain the major causes impacting the network. 4.3.3 Check Cells If the previous KPIs of the cell are normal, check the alarms. By this, you can exclude the causes due to abnormal cells. 4.3.4 Further DT for Relocating Problems Analyzing traffic statistics indexes helps to expose potential problems. To locate and analyze problems, you need to use DT and CHR. For problematic cells, the cell-oriented DT is performed to trace the signaling flow at UE side and of RNC. For details, see 3.1. 4.4 Optimization Flow for Tracing Data
  58. 58. Analysis traced data includes analyzing single subscriber tracing message and performance monitoring. Based on the combination of single subscriber message and data at UE side recorded by data collection tools, you can locate basic call drop problems. For more complex problems, you need to use CHR and performance monitoring. By single subscriber tracing data, you need to locate and analyze problems concerning commercial UEs or key subscribers which are not recorded at UE side. Single subscriber tracing involves recording the following information: y Signaling message (lu, lur, lub, and Uu) of single subscriber y Performance tracing of CPICH RSCP and Ec/Io y UE transmit power y Uplink SIR, SIRTarget y Uplink BLER y Downlink code transmit power y Uplink and downlink traffic and throughput (for data services) 4.4 shows the flow for analyzing call tracing.
  59. 59. 2. Flow for analyzing call tracing 4.4.1 Obtaining Single Subscriber Tracing Message You must first trace single subscriber tracing message on RNC or M2000 and then record the corresponding messages. For detailed tracing methods, see W-Equipment Room Operations Guide. Usually analyzing call drop problems by message for tracing IMSI is enough. 4.4.2 Obtaining Information about Call Drop Point According to single subscriber tracing messages, the call drop is defined as: y The RNC originates RAB release (the message is RANAP_RAB_RELEASE_REQ) y The RNC originates IU release (the message is RANAP_IU_RELEASE_REQ) The former corresponds to call drop caused by TRB reset. The latter corresponds to call drop caused by SRB reset. By searching for the previous two messages, you can obtain the call drop time and the signaling message before call drop for further analysis. 4.4.3 Analyzing Call Drop due to SRB Reset
  60. 60. The call drop due to SRB reset is that the UE or RNC fails to receive signaling transmitted in confirmation mode, and consequently SRT reset occurs, so the connection is released. SRB reset occurs probably if the UE fails to receive the following messages in downlink: y Security mode process y Authentication and encryption process y Measurement control y Active set update y Physical channel reconfiguration y Transport channel reconfiguration y RB reset y Handover command from 3G to 2G (HANDOVER FROM UTRAN COMMAND) Confirm that the UE receives these messages by tracing messages at UE side. SRB reset occurs probably if the UE fails to receive the following messages in uplink: y Measurement report y Active set update complete y Physical channel reconfiguration complete y Transport channel reconfiguration complete y RB reconfiguration complete Confirm that the UE receives these messages by tracing messaged at RNC side. 4.4.4 Analyzing Call Drop due to TRB Reset TRB reset usually occurs in PS services. It seldom occurs in voice and VP services. Confirm TRB reset by the UE transmit power upon call drop and downlink code transmit power. When only one link exists in active set, uplink asynchronization causes RL failure which consequently causes lu release originated by RNC. Downlink asynchronization causes UE to power off transmitter, which consequently causes uplink asynchronization. To judge whether uplink asynchronization or downlink asynchronization causes release, you must analyze the UE transmit power before call drop and downlink code transmit power monitored in real-time state. Weak downlink coverage, strong downlink interference or uplink interference causes TRB reset. If the retransmission times of data services are improperly configured, TRB reset occurs before SRB reset upon delayed handover. Pay attention to this. 4.4.5 Analyzing Abnormal Call Drop Abnormal call drop can neither be located from coverage and interference nor be explained by TRB reset or SRB reset. It is caused by abnormal equipment or UE. For example, it might be caused by the following factors: y Abrupt transmission failure y Abnormal NodeB equipment y Abrupt breakdown of UE
  61. 61. Analyze abnormal transmission by analyzing CHR or checking alarms. Confirm that the NodeB equipment is abnormal by querying NodeB state. Locate abnormal UE problems by analyzing data recorded by UE. 4.4.6 Performing CQT to Recheck Problems When the data is inadequate for locating call drop problems, you must start more detailed data tracing. The best method is to perform CQT at call drop points to recheck problems for further analysis. 4.5 Optimization Process for MBMS Call Drop Currently, the RNC V18 or V29 supports only the broadcast mode. In broadcast mode, the MBMS receives a control message from the MCCH to establish the MBMS service and radio bearer, without signaling interaction with the RNC. Therefore, we can substitute the MBMS session drop rate for the MBMS call drop rate. The MBMS session drop rate is defined as follows: MBMS session drop rate = number of MBMS session drop times/total number of successes of MBMS-on-demand x 100% Number of MBMS session drop times: One MBMS session drop time is counted once the MBMS service is exceptionally interrupted or the UE is in the buffering state for more than one minute. Total number of successes of MBMS on demand: Total number of successes of MBMS-on-demand originated by the UE. You can see from the terminal interface whether the MBMS service is exceptionally interrupted, and you need to use the drive test software to observe whether the UE is the buffering state for more than one minute. Currently, the software tool used for this purpose is Qualcomm drive test software QXDM. The possible causes for a high MBMS deactivation rate are as follows: The network coverage is poor. The RSCP and Ec/Io in the position where the UE is located are both low. In addition, a block error rate (BLER) of the FACH of the MBMS service also exists. The cell is in the preliminary congestion state and the channel power of the MBMS service is reset to the minimum; or the cell is in the over-congestion state and the MBMS service with a lower priority is released by force. The channel power can, however, be automatically recovered to the maximum or the service can be re-established through periodic detection. The UE is at the edge of the cells, and the neighboring cells are not configured for the cell in which the UE is located. As a result, the UE is unable to obtain a gain through soft combining or selective combining. Run the DSP CELLMBMSSERVICE command to query the status of the current MBMS service. If the MBMS service is not established successfully, the failure cause is displayed. You can improve the coverage rate by optimizing the RF, adding NodeBs, or adjusting the antennas. If the coverage does not improve, increase the maximum power of the MBMS traffic channel. If a neighboring cell is not configured, configure it.
  62. 62. 5 FAQs Analysis 5.1 SHO Problems 5.1.1 Over High SHO Rate due to Improper SHO Relative Threshold Description The SHO rate in traffic statistics indexes is over high. More than two cells exist in active set most of the time during DT and are in SHO state. Analysis Analyze the relative threshold of 1A and 1B event, namely, reporting range. 5.1.1 shows the SHO relative threshold 1. SHO relative threshold According to 5.1.1, the greater the reporting range is, the more easily a neighbor cell is listed into active set and the more difficult it is deleted from active set. This causes over high SHO rate.
  63. 63. A general method is to configure the threshold of 1A and 1B different. Configure the threshold of 1A event small (such as 3 dB) and keep the threshold of 1B threshold the same (5 dB). In this way, the cells with bad quality cannot be listed into active set easily and the cells with good quality can be listed into active set. Therefore the SHO rate is lowered based on normal SHO. 5.1.2 Delayed Handover due to Over Great Intra-frequency Filter Coefficient Description SHO hysteresis is serious in DT: though the signals of a neighbor cell are strong, the cell can be listed into active set after a long time. If the DT car moves quickly, call drop occurs due to delayed handover. Analysis Layer 3 filter reduces the impact by frequently-fluctuating signals and avoids ping-pong handover. The filter of measurement values is calculated as below: Wherein, Fn: the measurement resulted update after filter is processed. Fn-1: the measurement result of last point after filter is processed. Mn: the latest measurement value received in physical layer. a = (1/2)(k/2) . The k is from Filter coefficient, namely, FilterCoef. If K = 0 and a = 1, there is no layer 3 filter. The filter coefficient ranges from 0 to 6 (integers). The greater it is, the stronger the capability of smoothing burr is and the weaker the capability of tracing signals is. You must make a balance. According to simulation, 5.1.2 lists the relationship between the filter coefficient and the corresponding tracing time.
  64. 64. 1. Relationship between the filter coefficient and the corresponding tracing time Filter coefficient 0 1 2 3 4 5 6 7 8 9 11 Intra- frequency tracing time (s) 0.2 0.4 0.6 1 1.4 2 3 4.2 6 8.4 17 The distance between sites in dense urban areas is short and the handover time is short, so you must reduce the tracing time, namely, the filter coefficient. The value 2 is usually proper for filter coefficient of layer 3. 5.1.3 Missing Neighbor Cell Description The call drop point is related to signaling flow before call drop. 5.1.3 shows the signaling flow recorded by UE before call drop.
  65. 65. 1. Signaling flow recorded by UE before call drop Analysis Check the pilot test data from UE and scanner at call drop points. 5.1.3 shows the scrambles recorded by UE active set and scanner before call drop. In 5.1.3, the measurement result of UE active set and canner is inconsistent and the SC 170 of scanner does not exist in UE active set.
  66. 66. 1. Scrambles recorded by UE active set and scanner before call drop The cause might be missing neighbor cell or delayed handover. Check scrambles in UE active set. 5.1.3 shows the scrambles in UE active set before call drop. No SC 170 cell exists in UE monitor set, because this is possibly due to missing neighbor cell.
  67. 67. 2. Scrambles in UE active set before call drop Continue to check the neighbor cell list sent by RNC to UE before call drop, as shown in 5.1.3 and 5.1.3. According to the latest measurement control before call drop, no SC 170 exists in the neighbor cell list, because the call drop is due to missing neighbor cell of SC 6 and SC 170.
  68. 68. 3. UE intra-frequency measurement control point before call drop
  69. 69. 4. Analyzing signaling of UE intra-frequency measurement control before call drop If only the UE recorded information during test, without scanner information, confirm that call drop is due to missing neighbor cell by using the following method, as shown in 5.1.3: y Confirm the scrambles of all cells in active set and the scrambles of cells in monitor set measured by UE before call drop. y Compare the scramble information of the cell where the UE camps on after reselection after call drop and the scrambles in UE active set and monitor set before call drop. If the former scramble is not in the scramble list of active set and monitor set before call drop, the call drop is probably due to missing neighbor cell. y Check the neighbor cell list. This applies for solving call drop due to missing neighbor cell on site.
  70. 70. 5. Confirming missing neighbor cell without information from scanner Solution Add neighbor cells. Because the RNC updates measurement control according to the best cell which is obtainable by searching for intra-frequency measurement report with 1D event before measurement control is sent. Usually they are configured to bi-directional neighbor cells. 5.1.4 Redundant Neighbor Cells According to the protocol, the maximum number of neighbor cell is 32 and the host cell is also included in these cells, so the actual intra-frequency neighbor cell is 31 at most. The intra-frequency neighbor cells of S subject are based on data of 2G neighbor cells. In the dense urban areas, the densely-located sites and combine make the intra-frequency neighbor cell list large. If the intra-frequency neighbor cells reach or exceed 31, a necessary neighbor cell found during optimization fails to be listed as an inter-frequency neighbor cell. For this, you must delete some redundant neighbor cells. You must be cautious to delete abundant neighbor cells. Deleting necessary neighbor cells leads to call drop. Following the principles below: y Before deleting neighbor cells, check the revision record of neighbor cells. Check that the cells to be deleted are not the ones that were added during previous DT and optimization. y After deleting neighbor cells, perform comprehensive test, including DT and CQT in important indoor spots. From this, you can check the variation of traffic statistics result of the corresponding cells. The
  71. 71. traffic statistics result includes setup success rate, CDR, and handover success rate. Ensure there is no abnormality. Otherwise restore the configuration. If no reliable 3G handover times can serve as judgment at the network construction stage, you can estimate the handover probability by using the handover times of 2G neighbor cells. 5.1.4 lists the 2G handover times. 1. 2G handover times Assist_GSM_HO_Count SERVCELL NCELL HOCOUNT 12531 10121 417 12531 10161 3262 12531 10162 2070 12531 10301 381 12531 10321 265 12531 12061 9 12531 12101 961 12531 12111 16 12531 12251 2 12531 12291 4 12531 12292 0 12531 12330 1082
  72. 72. 12531 12391 1063 12531 12451 17019 12531 12532 16030 12531 12540 74 12531 12591 926 12531 12592 20994 12531 14051 2 12531 14072 2 12531 14091 211 12531 14111 1 12531 14460 321 12531 56361 16 12531 56362 0 12531 56820 0 12531 56910 206 Search for the neighbor cells with few handover times and even no handovers, such as cell 12531±12292. 5.1.4 shows the location relationship of 2G redundant neighbor cells.
  73. 73. 2. Location relationship of 2G redundant neighbor cells According to 5.1.4, multiple NodeBs are located between the cell 12531 and the cell 12292, so the handover probability is small. Therefore, delete the neighbor cell relationship. The judgment principles based on 2G statistics might have mistakes, so you must confirm that no call drop occurs after deleting the neighbor cell relationship. After network launch, the handover times in traffic statistics according to statistics reflects the real handovers, so deleting abundant neighbor cells by using the handover times in traffic statistics according to statistics is more reliable. You need to register the traffic statistics tasks of two cells on traffic statistics console of RNC. 5.1.5 Pilot Pollution Description and Analysis y Locating pilot pollution point 5.1.5 shows the pilot pollution point near Yuxing Rd. SC270 cell is planned to cover the area with pilot pollution.
  74. 74. 1. Pilot pollution near Yuxing Rd. y Analyzing signal distribution of cells near pilot pollution point 2. Best ServiceCell near Yuxing Rd.
  75. 75. 3. The 2nd best ServiceCell near Yuxing Rd. 4. The 3rd best ServiceCell near Yuxing Rd.
  76. 76. 5. The 4th best ServiceCell near Yuxing Rd. 6. Composition of pilot pollution near Yuxing Rd. From 5.1.5, 5.1.5, 5.1.5, 5.1.5, and 5.1.5, though SC20 cell is planned to cover the area, but the best ServiceCell is as listed in 5.1.5. 1. Best servers and other cells Best ServiceCell Primary Others 1st best ServiceCell SC220 SC260 and SC270
  77. 77. 2nd best ServiceCell SC270 SC260, SC220, and SC200 3 rd best ServiceCell SC200 SC270 and SC260 4 th best ServiceCell SC200 SC270 and SC260 y Analyzing RSSI distribution near pilot pollution point. 5.1.5 shows the RSSI near Yuxing Rd.. 7. RSSI near Yuxing Rd. 5.1.5 shows the RSCP of Best ServiceCell near Yuxing Rd..
  78. 78. 8. RSCP of Best ServiceCell near Yuxing Rd. As shown in 5.1.5, the RSSI of the areas with pilot pollution is not large, about ±100 dBm to ±90 dBm. As shown in 5.1.5, the RSCP of Best ServiceCell is between ±105 dBm to ± 100 dBm. The pilot pollution of the area is caused by no strong pilot, so you can solve the problem by strengthening a strong pilot. y Analyzing RSCP Distribution of Related Cells 5.1.5 shows the RSCP of SC270 cell near Yuxing Rd. 9. RSCP of SC270 cell near Yuxing Rd. The SC270 cell is planned to cover the area. 5.1.5 shows RSCP of RSCP distribution of SC270 cell. The signals from SC270 cell are weak in the area with pilot pollution.
  79. 79. Solution According to on-site survey, the residential area is densely distributed by 6-floor or 7-floor buildings. The test route fails to cover the major streets, and is performed in narrow streets with buildings around, so the signals are blocked. The suggestion is to adjust the azimuth of SC270 cell from 150° to 130° and the down tilt from 5° to 3°. This enhances the coverage of SC270 cell. After analysis of DT data, the expected result after adjustment is that the coverage area by SC270 cell increases and the coverage is enhanced. 5.1.5 shows the pilot pollution near Yuxing Rd. after optimization. 1. Pilot pollution near Yuxing Rd. after optimization 5.1.5 shows the best ServiceCell near Yuxing Rd. after optimization.
  80. 80. 2. Best ServiceCell near Yuxing Rd. after optimization 5.1.5 shows the RSCP of best ServiceCell near Yuxing Rd. after optimization. 3. RSCP of best ServiceCell near Yuxing Rd. after optimization 5.1.5 shows the RSCP of SC270 cell near Yuxing Rd. after optimization.
  81. 81. 4. RSCP of SC270 cell near Yuxing Rd. after optimization According to the DT data, the pilot pollution near Yuxing Rd. after optimization is eliminated, the signals from SC270 cell after optimization are stronger, and the SC270 becomes the best ServiceCell. This complies with the expected result. 5.1.6 Turning Corner Effect Description and Analysis The turning corner effect exists in the following situation: The signals of original cell attenuates sharply, and the signals of target cell increases sharply, so the UE cannot receive the active set update messages, and consequently call drop occurs. The variance of Ec/Io is shown in 5.1.6 (the interval between two points is 0.5s). 1. Turning corner effect- signals attenuation
  82. 82. According to 5.1.6, the signals of original cell attenuate 10 dB sharply within 1s, and the signals of target cell increase 10 dB. If the signals are weak before attenuation, and 1a event is configured to easily-triggered state, the measurement report is sent according to traced signaling of the UE, and the RNC receives the measurement report according to signaling traced by the RNC. When the RNC sends the active set update message, the UE cannot receive it due to weak signals of original cell, so the signaling is reset, and call drop occurs. If 1a event is slowly triggered (such as configuring great hysteresis or triggering time), TRB reset occurs before the UE sends the measurement report. 5.1.6 shows an example of turning corner effect. 2. Turning corner effect- signal attenuation recorded by the UE According to 5.1.6, before turning corner, the signals of active set scramble 104 and 168 attenuate to smaller than ±17 dB, but that of 208 is strong (±8 dB). According to the signaling traced by the RNC, and the UE reports the 1a event of the cell of scramble 208, and sends the active set update message. The UE does not receive the completion message, so the call drop occurs, as shown in 5.1.6.
  83. 83. 3. Turning corner effect- traced signaling recorded by the RNC Solution To solve turning corner effect problems, do as follows: y Configure 1a event parameter of a cell to enable handover to be triggered more easily. If you lower the triggering time to 200ms, you can reduce hysteresis. You must configure the triggering time for a specified cell, because the change of the parameter might lead to easily occurrence of handover between the cell and other cells without turning corner effect, or frequent ping-pong handover. y Configure the CIO between two cells with turning corner effect to add the target cell more easily. The CIO only affects the handover between two cells, with less impact, however, it impacts handover. The configuration leads to an increase of handover ratio. y Adjust antenna to enable the antenna of target cell cover the turning corner. This helps avoid fast variance of signals, and avoid call drop. Actually experiences help judge whether the adjustment of engineering parameters can cover the turning corner, so using this method is difficult. Based on previous analysis, the first method prevails. If it fails, use the second method. If the second method fails, use the third method (the third method is the best solution, especially in areas where you can adjust antenna easily).
  84. 84. 5.1.7 Needlepoint Effect Description and Analysis The needlepoint effect is that affected by the strong signals of target cell in a short time, the original cell attenuates sharply, and then increase. The variance of Ec/Io is shown in 5.1.7 (the interval between two points is 0.5s). 1. Needle point- signal variance The needlepoint effect cause call drop in the following situations: y If the needlepoint lasts for a short period, unable to meet the handover conditions and to affect call drop, it will lead to deterioration of quality of service (QoS), such as over great BLER exists in downlink. y If handover occurs in the target cell, and the signals of the original cell is over weak, so the UE cannot receive active set update messages, and consequently call drop occurs. y If the needlepoint lasts for a short period, and the handover conditions are difficult to meet, so the signaling or service RB reset occurs due to weak downlink signals before handover. Finally, call drop occurs. y If the target cell completes handover, and becomes a cell in the active set, call drop occurs because the cell can exit the active set before completing a handover with the needlepoint disappearing quickly. Compared with turning corner effect, the needlepoint effect is more risky due to two handovers, and failure of one of the two causes call drop. The needlepoint lasts for a short period, so call drop may not occur if QoS is lowered (for example, configure a greater retransmission times). The turning corner effect causes an absolute call drop because the signals of original cell will not recover after turning corner. Observe the needlepoint effect by scramble distribution diagram of the best cell recorded by Scanner. If two antennas cover two streets respectively, at the crossing point, needlepoint effect occurs easily.
  85. 85. 5.1.7 shows the call drop distribution of PS384K intra-frequency hard handover (it is the best cell). Wherein, call drop point drop4, drop5, drop6, drop7, drop15, and drop16 are caused by needlepoint effect. 2. Call drop distribution of PS384K intra- frequency hard handover Solution To solve problems caused by needlepoint effect, you can refer to the solution to turning corner effect. The key to adjust antenna is not to enable original signals attenuate sharply and not to enable target signals increase sharply. In addition, you can increase the retransmission times to resist to attenuation of signals so that CDR is lowered. 5.1.8 Quick Change of Best server Signal Description 5.1.8 shows signal distribution of cell52 vs. cell88 (signal fluctuation in handover areas).
  86. 86. 1. Signal distribution of cell152 vs. cell88 (signal fluctuation in handover areas) After the UE hands over from cell 152 to cell 88, the signals of cell 152 are stronger than that of cell 88. In 5.1.8, after the signals of cell 152 keep weaker than that of cell 88, the signals of cell 152 become stronger than that of cell 88 for continuous 2s. Analysis When the UE hands over from cell 152 to cell 88, and the signals of cell 152 become better than that of cell 88. This is similar to the needlepoint effect in 5.1.7. Therefore quick change of best server signals causes the same handover failures as the needlepoint effect causes, as follows: y Ho Req SRB Reset y Ho Failure y TRB Reset To sole the problem, optimize RF engineering parameters and 1D event parameters to avoid ping-pong handover.
  87. 87. 5.2 HHO Problems 5.2.1 Intra-frequency Ping-pong HHO due to Improperly Configured 1D Event Hysteresis Description The UE keeps performing intra-frequency HHO at the cell border, so the call quality declines and even call drop occurs. Analysis Reporting the 1D event triggers the inter-frequency HHO. The 1D event is reported when the best cell changes, as shown in 5.2.1. 1. Reporting 1D event The UE is at the border of two cells, so the signals from the two cells are equivalently strong. Signal fluctuation easily causes ping-pong handover to best cells. Frequent report 1D event triggers inter-frequency HHO. To avoid intra-frequency ping-pong HHO caused by 1D event triggered by frequent fluctuation of signals if the channels are similar, you can increase the hysteresis, as shown in 5.2.1.

×