W-Test Guide-20081215-A-3.4

WCDMA Test Guide For internal use only
Product Name Confidentiality Level
WCDMA RNP For internal use
Product Version
Total 173 pages
3.4
WCDMA Test Guide

(For Internal Use Only)
Prepared by: Gao Bo Date: 01-20-2006
Li Wenhui, Jin Yu, Hua

Yunlong, He Fengming, Pi
Kunbao, Ai Hua, Hu Wensu,
Reviewed by: Jin Xinjie, Xie Zhibin Date: 03-17-2006
Reviewed by: Wang Chungui Date: 03-28-2006
Approved by: Date:
Huawei Technologies Co., Ltd.

All Rights Reserved.
2008-12-15 Huawei Confidential Page 1 of 175

WCDMA Test Guide For internal use only
Revision History
Revision
Date Description Author
Version
2006-01-20 3.00 The first draft was completed. Gao Bo
The modification was completed according to comments of

the first review: Adjusting the structures of Chapter 2,
2006-02-27 3.00 Gao Bo
“Tests in the Network Optimization Phase” and Chapter 3,
“KPI Acceptance Test of UMTS Radio Network”.
The modification was completed according to comments of

the second review: detailing the KPI definitions, test
conditions and test methods, and adding detailed statistics
2006-03-03 3.00 Gao Bo
methods for each KPI, the section of the HSDPA drive test
and 14 test cases in Chapter 3, “KPI Acceptance Test of
UMTS Radio Network”.
2006-03-24 3.00 The modification was completed according to comments of Gao Bo

the third review: adding the test and statistics methods for
inter-frequency and inter-system handover, removing the
radio propagation test, and correcting the method for
Assistant-based BLER statistics.
The preparations before a DT were modified: adding such

contents as power supply on vehicles, test equipment
Yu
selection and version, adding the HSDPA test, modifying
Yongxian,
2006-5-27 3.10 the explanations of the parameters in the HSDPA window,
Zhang
adding the R99 and HSDPA test cases, adding the HSDPA
Youbin
DT acceptance, adding the CN test setting requirements,
ad adjusting some document structures.
2007-10-12 3.2 HSUPA-related contents were added. Throughput test Zhao Hao
cases of HSDPA cells were moved from section 3.2 to
section 3.3.
2007-11-28 3.3 The MBMS RF optimization and DT items of system tuning Wang Dekai
were added. The DT, CQT, traffic measurement index
definition, and test method were added for the MBMS KPI
acceptance.
2008-10-27 3.4 The types of terminals that Probe1.5 supports and the Song Xiaoli,
contents of the benchmark test were added. Zuo
Update was made on the basis of the review comments. Yanzhong
2008-12-15 3.41 Yearly review Hu Wensu

For internal use only
Table of Contents
Overview of WCDMA Tests........................................................................................................... 10
1 Drive Test..................................................................................................................................... 11
1.1 Preparation before the Drive Test.......................................................................................11
1.1.1 Test Tools and Vehicles............................................................................................ 11
1.1.2 Selection of DT Routes............................................................................................ 14
1.1.3 Confirmation of Test Conditions...............................................................................14
1.1.4 DT Personnel and Time Schedule...........................................................................15
1.1.5 CN Test Devices...................................................................................................... 15
1.2 DT Items............................................................................................................................. 16
1.3 PROBE DT Preparations.................................................................................................... 18
1.3.1 Probe Version.......................................................................................................... 18
1.3.2 Preparing Test Devices............................................................................................ 18
1.3.3 Hardware Configuration........................................................................................... 21
1.3.4 Importing BTS Information.......................................................................................24
1.3.5 Adjusting PC Time................................................................................................... 25
1.3.6 Making Test Plan for Each Test Item........................................................................26
1.4 Selecting a Test Window.................................................................................................... 37
1.4.1 Active Set and Neighbor Cell...................................................................................38
1.4.2 RRC Signaling......................................................................................................... 38
1.4.3 Map Setting and Displaying.....................................................................................39
1.4.4 Scanner TopN Pilot.................................................................................................. 39
1.4.5 Scanner Pilot Scan.................................................................................................. 39
1.4.6 HSDPA Window....................................................................................................... 40
1.4.7 HSUPA window........................................................................................................ 44
1.4.8 Other Windows........................................................................................................ 48
1.5 Rules for Storing Test Data................................................................................................ 48
1.6 Playing Back Test Data...................................................................................................... 48
2 Tests in the Network Optimization Phase.................................................................................50
2.1 Tests in the Single Site Verification Phase.........................................................................50
2.1.1 List of Single Site Verification Items.........................................................................50
2.1.2 Test Methods for Each Check Item..........................................................................51
2.2 Tests in the RF Optimization Phase...................................................................................51
2.2.1 List of RF Optimization Test Items/Tasks.................................................................51
2.2.2 Test Item or Task Description...................................................................................52
2.3 Tests and Data Collection in the Service Optimization Phase............................................57
2.3.1 List of Service Optimization Test Items....................................................................57
2.3.2 Collection of Other Data.......................................................................................... 59
2.3.3 Brief Introduction to Service Optimization Process..................................................61
2.4 Test Problem Analysis........................................................................................................ 62
2.4.1 List of Cases............................................................................................................ 63
2.4.2 Detailed Answers..................................................................................................... 64
3 KPI Acceptance Test of UMTS Radio Network.........................................................................84
3.1 Preparation before Acceptance Test...................................................................................84
3.1.1 Determining Acceptance Area and Route................................................................84
3.1.2 Selection of 2G and 3G Interoperability Scenarios..................................................86
3.1.3 Selection of Delay Test Scenario.............................................................................87
3.1.4 Description of Uplink and Downlink Load................................................................87
3.2 Standards and Methods of DT Acceptance Test.................................................................88
3.2.1 DT Acceptance Indexes........................................................................................... 88
3.2.2 Definitions and Test Methods of DT Acceptance Indexes........................................91

3.3 Standards and Methods of CQT Test Acceptance............................................................130

3.3.1 CQT Acceptance Indexes......................................................................................130
3.3.2 Definitions and Test Methods of CQT Acceptance Indexes...................................131
3.4 RAN Traffic Statistics Acceptance....................................................................................144
3.4.1 Traffic Statistics Acceptance Indexes.....................................................................145
3.4.2 Definitions and Statistics of Traffic Statistics Acceptance Indexes.........................146
4 UMTS radio network benchmark test......................................................................................159
4.1 Objective of a benchmark test.......................................................................................... 159
4.2 Test contents of a benchmark test....................................................................................159
4.3 Preparation for a benchmark test.....................................................................................160
4.4 Method of benchmark test................................................................................................ 161
5 Summary................................................................................................................................... 162
6 Appendix................................................................................................................................... 163
6.1 Method for Setting APN and QoS with Modem Initiation Command.................................163
6.2 BLER Analysis Method in the Assistant............................................................................164
6.2.1 Problem Description.............................................................................................. 164
6.2.2 Analysis Method..................................................................................................... 165
6.2.3 Experience Summary............................................................................................ 168
6.3 Manual Dialup Methods.................................................................................................... 169
6.3.1 Dialup Method of E620 Data Card.........................................................................169
6.3.2 Dialup Method of the Test Handset........................................................................170
6.4 Condition of PS Service Over HSDPA..............................................................................170
6.5 Common Windows and Corresponding Logmask............................................................171
7 References:................................................................................................................................ 173

List of Tables
Table 1 List of DT items.......................................................................................................... 16
Table 2 Single site verification items.......................................................................................50
Table 3 List of RF optimization test items/tasks......................................................................51
Table 4 List of service optimization test items........................................................................57
Table 5 List of test cases........................................................................................................ 63
Table 6 Load of cells in areas A and B of city x.......................................................................88
Table 7 DT acceptance indexes.............................................................................................88
Table 8 Scanner handover statistics.......................................................................................94
Table 9 CQT acceptance indexes.........................................................................................130
Table 10 Traffic statistics acceptance indexes......................................................................145
Table 11 Common windows and the corresponding packets................................................171

List of Figures
Figure 1 Recommended recharging method on a vehicle......................................................11
Figure 2 Connecting the DTI Scanner....................................................................................12
Figure 3 Receiver panel......................................................................................................... 13
Figure 4 Connecting the Agilent 7464....................................................................................13
Figure 5 Connecting a test handset (Qualcomm handset).....................................................13
Figure 6 Ports on the E620 data card....................................................................................21
Figure 7 Hardware configuration............................................................................................21
Figure 8 Manual configuration................................................................................................ 22
Figure 9 UE setting................................................................................................................ 22
Figure 10 DTI Scanner setting...............................................................................................23
Figure 11 Importing project parameters (1)............................................................................24
Figure 12 Importing project parameters (2)............................................................................25
Figure 13 Canceling PC time adjustment...............................................................................25
Figure 14 Data configuration for TopN Pilot Scan..................................................................26
Figure 15 Data configuration for voice (continuous call) test..................................................27
Figure 16 Data configuration for voice (call by call) test.........................................................28
Figure 17 Data configuration for VP (continuous call) test.....................................................29
Figure 18 Data configuration for VP (call by call) test............................................................30
Figure 19 Configuring PS dialup............................................................................................31
Figure 20 System Config > Other settings...........................................................................32
Figure 21 Configuring Ftp DownLoad...................................................................................33
Figure 22 Configuring Ftp UpLoad........................................................................................ 34
Figure 23 Configuring PDP activation....................................................................................34
Figure 24 Selecting an observation window...........................................................................37
Figure 25 A window for active set and neighbor cell test........................................................38
Figure 26 RRC message........................................................................................................ 38
Figure 27 Map........................................................................................................................ 39
Figure 28 WCDMA HSDPA link statistics...............................................................................40
Figure 29 WCDMA HSDPA physical channel.........................................................................41
Figure 30 HSDPA decoding statistics.....................................................................................42
Figure 31 Active set PSC strength.........................................................................................43
Figure 32 Indoor measurement..............................................................................................53
Figure 33 Selecting an automatic walking test.......................................................................54
Figure 34 Presetting a test route............................................................................................ 55
Figure 35 Selecting a manual walking test.............................................................................56
Figure 36 Selecting a vertical test.......................................................................................... 57
Figure 37 BLERs of the uplink transmission channel measured by the RNC.........................64
Figure 38 BLER analysis result..............................................................................................65

Figure 39 Comparing test results (using Huawei handset and Qualcomm handset)..............74
Figure 40 Comparing test results (using Huawei UE and Qualcomm UE) 2..........................75
Figure 41 Test point 1............................................................................................................. 76
Figure 44 Ec/Io collected by the scanner...............................................................................78
Figure 45 Distribution of SCs................................................................................................. 78
Figure 46 10603 Ec/Io distribution......................................................................................... 79
Figure 47 10841 Ec/Io coverage............................................................................................79
Figure 48 10664 Ec/Io coverage............................................................................................80
Figure 49 Code resource monitoring of cell channel (1).........................................................82
Figure 50 Acceptance route of area A and area B in city x.....................................................85
Figure 51 Acceptance route of area C and area D in city x....................................................86
Figure 52 Acceptance place of handover between 2G and 3G in area A of city x..................87
Figure 53 Delay test place..................................................................................................... 87
Figure 54 Setting based on 5 m geographical average..........................................................92
Figure 55 Statistics description of mileage call drop ratio......................................................92
Figure 56 Statistics description of coverage ratio...................................................................93
Figure 57 Scanner Setting..................................................................................................... 94
Figure 58 Statistics description diagram of pilot pollution ratio...............................................95
Figure 59 Statistics description diagram for call completion ratio of the caller.......................96
Figure 60 Statistics description diagram of PDP activation success ratio..............................99
Figure 61 Statistics description diagram of CS call drop ratio..............................................100
Figure 62 Statistics description diagram of PS call drop ratio..............................................101
Figure 63 Statistics description diagram of ratio of relatively high uplink BLERs.................102
Figure 64 Diagram for PS DialUp Test Plan making.............................................................104
Figure 65 Statistics description diagram (1) of downlink average throughput......................104
Figure 68 Statistics description diagram (1) of uplink average throughput...........................107
Figure 69 Statistics description diagram (2) of uplink average throughput...........................107
Figure 70 Tracing the CS 3G-to-2G handover messages on the RNC TRACER.................116
Figure 71 Tracing the UE CS 3G-to-2G handover messages on the Huawei Probe............117
Figure 72 Tracing the PS 3G-to-2G handover messages on the RNC TRACER.................118
Figure 73 Du Meter setting................................................................................................... 120
Figure 74 Du Meter statistics interface.................................................................................120
Figure 75 Flow of intra-frequency service cell update between H and H.............................122
Figure 76 Flow of HSDPA inter-frequency service cell update.............................................123
Figure 77 Flow of intra-frequency handover between H and R99........................................124
Figure 78 Flow of soft handover accompanied with DCH-to-H handover.............................125
Figure 79 Flow of HSDPA-to-GPRS handover.....................................................................127
Figure 80 Export the test report in the probe........................................................................140

Figure 81 Call setup delay (1) in the probe report................................................................140

Figure 82 Call setup delay (2) in the probe report................................................................142
Figure 83 Description diagram for using the CMD tool.........................................................142
Figure 84 Reading the delay of ping packet.........................................................................143
Figure 85 Soft handover overhead.......................................................................................147
Figure 86 Uplink interference............................................................................................... 148
Figure 87 Failure ratio of RRC setup....................................................................................149
Figure 88 CS RAB setup failure ratio...................................................................................149
Figure 89 CS RAB setup failure ratio...................................................................................150
Figure 90 CS AMR call drop ratio.........................................................................................150
Figure 91 CS VP call drop ratio............................................................................................151
Figure 92 PS call drop ratio.................................................................................................. 151
Figure 93 Downlink peak throughput....................................................................................152
Figure 94 Count of dynamic channel configuration success for dedicated channels with the
decreased uplink rate.................................................................................................... 152
Figure 95 Soft/softer handover failure ratio..........................................................................153
Figure 96 Failure ratio of outgoing CS inter-system handover.............................................154
Figure 97 Failure ratio of outgoing PS inter-system handover originated by the RNC.........155
Figure 98 Count of rejections due to admission failure........................................................156
Figure 99 Paging loss ratio caused by PCH channel congestion.........................................156
Figure 100 APN setting of the data card E620.....................................................................169
Figure 101 Method (2) of the UE performing PS service dialing automatically....................170

WCDMA Test Guide

Keywords
Single site verification test, RF optimization test, service optimization phase test,
network acceptance phase test, and HSDPA service test ， HSUPA test, network
performance improvement, Benchmark
Abstract
The test task is to collect the basic data throughout the whole process of the network
planning and optimization. Its lifecycle begins from network planning to the end of
network optimization. Continuous wave tests are mainly performed in the network
planning phase. The collected data serves as the sample point for the propagation
model adjustment. Network performance tests are fully performed in the network
optimization phase. The collected data serves as an indispensable basis for
engineers to shoot and remove network troubles.
List of Abbreviations
Abbreviations Full Spelling
CQT Call Quality Test
DT Driver Test
VP Video Phone
HSDPA High Speed Downlink Packet Access
HSUPA High Speed Uplink Packet Acccess

Overview of WCDMA Tests

Abstract: The test task is to collect the basic data throughout the whole process of the
network planning and optimization. Its lifecycle begins from network planning to the
end of network optimization. Continuous wave tests are mainly performed in the
network planning phase. The collected data serves as the sample point for the
propagation model adjustment. Network performance tests are fully performed in the
network optimization phase. The collected data serves as an indispensable basis for
engineers to shoot and remove network troubles. This document focuses on all test
tasks undertaken by network planning and optimization engineers in network
optimization phases. It consists of the following chapters.
Chapter 1 Describes the drive test methods and related parameters of the
GENEX Probe 1.3.
Chapter 2 Describes the tests and precautions in the single site verification, RF
optimization and service optimization phases, and collects 14 test
cases.
Chapter 3 Describes the tests in the network acceptance phase, covering the
acceptance KPI definitions and statistics methods for the DT, CQT and
RAN traffic statistics.
Chapter 4 introduce the benchmark test.
Chapter 5 Gives a summary.
Chapter 6 Describes the methods for setting the APN and QoS with the
initialization commands of the MODEM, for analyzing the BLER and for
dialing up with the data card, conditions for the HSDPA to carry PS
services, common Probe windows and required messages.
This document is a supplement to the Operation Manual and Vocal Training Series on
GENEX Tool. Please use them together.

1 Drive Test
1.1 Preparation before the Drive Test
1.1.1 Test Tools and Vehicles
1.1.1.1 Selection of Test Tools

It is recommended to use GENEX Probe + test UE + scanner/GPS for test and use
the GENEX Assistant for data analysis. Wherein, the test UEs can be Huawei
handsets and data cards, and Qualcomm handsets. Please choose the proper
models according to service test requirements. The DTI Scanner is often used. If the
scanner is not required, a general GARMIN series GPS can be used to record the
test tracks.
If special requirements are raised, for example, the customer requires using MOTO or
Nokia handsets or other DT tools such as Agilent and TEMS, choose the DT tool
software that is compatible to the used UEs and scanners and has the auxiliary data
analysis software or function meeting test requirements.
1.1.1.2 Recharging on Vehicles
The test laptops, handsets, scanners and GPS require recharging. Though laptops
and handsets can be recharged with batteries for a limited period of time, the
following recharging method is recommended on a vehicle.
SHAPE \* MERGEFORMAT
Car cigarette lighter 12V DC
12V DC
Car battery
Inverter Power socket
220V AC
Figure 1 Recommended recharging method on a vehicle
As shown in Figure 1, the battery and cigarette lighter are auxiliary equipment of a
common vehicle. The 12VDC/220VAC inverter (360 W~500 W) should be bought.
The power socket can be borrowed from hotels or dorms.
In this way, laptops and test handsets can be charged through the power socket, and
the DTI Scanner or GPS can be still powered through the car cigarette lighter.
Precautions:

1) Before refitting, make sure that the car battery and cigarette lighter work
normally.
2) Due to the limited current provided by the car battery (usually 3A), the inverter
provides the limited maximum power, and supports simultaneous recharging of
two laptops normally. But if three or more laptops are recharged at the same
time, the inverter may work abnormally. Moreover, due to the high power
consumption of the DTI Scanner, the inverter may alert until it fails to run
normally if too many devices are recharged simultaneously. Therefore, even
though the inverter and power socket are available on the vehicle, try to charge
the test laptops and handsets to full capacity before the test and recharge them
in turn during the test.
3) Due to the high power consumption for VP services, the speed of recharging is
much slower than power consumption. So, ensure that handsets are fully
recharged before the test.
4) When the car motor is switched on, the output voltage of the battery fluctuates
sharply. If the DTI Scanner is directly connected to the cigarette lighter, the DTI
Scanner is restarted when the car motor is switched on. If Probe 1.2 or an earlier
version is used, the test cannot be continued, and you have to stop the test, and
then start it again. If Probe 1.3 or a later version is used, the test can be
continued after the DTI Scanner is restarted. Yet, the better way is not to switch
off the motor at a short stop.
1.1.1.3 Preparing BTS Engineering Parameters and E-map

With the BTS engineering parameters, you can know the current location and serving
cell. For different DT tools, the BTS engineering parameters are imported with
different methods. You can determine the importing method according to refer to the
online help, operation manual and importing template of the specific DT tool.
However, the major basic contents of different DT tools are the same, such as the
BTS name, cell name, cell ID, cell longitude and latitude, antenna azimuth, frequency
point and scrambling code (SC). You can import the BTS engineering parameters into
an Excel file containing these contents in the DT tool.
The E-map MAPINFO is used in the DT tools. The paper registration can be bought,
scanned or converted from the E-map.
1.1.1.4 Connecting DT Devices

To avoid waste of time due to accidents, make sure that the test tool can be normally
used before testing.
Take the Probe and Agilent DT tools as an example. The following figures show the
connection between the scanner and the handset.

Figure 1 Connecting the DTI Scanner
Data port
Indicator
GPS antenna interface
Receiver antenna interface
Figure 2 Receiver panel

Figure 3 Connecting the Agilent 7464
Figure 4 Connecting a test handset (Qualcomm handset)
After the installation or connection is complete, check whether the device runs
normally. If no, check whether:
 The device is powered on properly. Normally, the switches should have been
enabled, and the power indicator should have been turned on.
 The serial port cable or network port cable are connected in a good contact.
 The serial port is connected to the correct serial port on the specified PC.
 The GPS information is received. If no, check whether the connection is normal
and the GPS antenna position is proper.
 The port is properly configured and related options are selected in the operating
system.
 The license is normal.
During the test, note the following items:

 Before testing, ensure that the handset is fully charged. If the handset is at low
volume, failures may occur in consumable VP service.

 Whether the handset and the PC are connected well with a data cable. To avoid
poor contact, do not pull the data cable rudely.
 Whether the test handset is connected to the USB port.
1.1.2 Selection of DT Routes

Be sure to select a route that covers all scenarios in the test area, such as overhead
roads, tunnels, freeways and density city or block streets. For a two-way road, ensure
that both directions can be tested to avoid any problem area left untested. In addition,
communicate with the customer on the test route to ensure that all concerns of the
customer have been covered.
Determine a fixed start point and a fixed end point in the test. Try to keep the same
sequence for the walking directions and routes in each test. In general, the maximum
speed of less than 60 Km/h is recommended for running vehicles.
Before the test, communicate fully with the driver on the test route, ensuring that the
driver can fully understand our intentions. This issue is particularly important in
foreign projects as language differences block the communication.
The test route requirements are different in different network optimization phases due
to the differences in focuses.
 For the test route requirements in the single site verification phase, refer to
Guide to WCDMA Single Site Verification.
 For the test route requirements in the RF optimization phase, refer to Guide to
WCDMA RF Optimization.
 For the test route requirements for the network KPI acceptance, refer to 3.1.1.
1.1.3 Confirmation of Test Conditions

Before a formal test, confirm the test conditions in view of test purposes.
 Check whether the uplink and downlink configurations meet test requirements.
For example, determine whether to load a service and the loading percentage.
 Check whether the switch is enabled. For example, check whether the switch for
intra-frequency hard handover is enabled before testing intra-frequency hard
handover, or whether the CELLHSDPA is activated before testing HSDPA.
 Check whether frequency points meet requirements. For example, to compare
the operations of two carriers with the Probe, check whether the settings of two
frequency points are correct.
 Check whether the test items are selected properly. For example, to test the
HSDPA with the Probe, check whether the Layer1 and Layer2 test items of
HSDPA are added to the logmask.
 Record the pilot RSCP and Ec/Io for the scanner.
 At the RNC side, record the upper Tx power, uplink SIR, uplink SIRtarget and
downlink BLER of the UE selectively, and trace a single user of the testing IMSI.
Before testing, make clear the equipment room personnel, and roughly
determine the items to be tested and traced at the RNC side. Before a DT, check
with the equipment room personnel the PC time and BAM time to keep data
recording synchronous (refer to section 1.3.5, “Adjusting PC Time”). Notify the
equipment room personnel of the IMSI and items to be traced. After a test is
finished, notify them to stop tracing the test item and trace the file again for the
test data analysis.
For a HSDPA test, confirm the following items in addition to those listed above.
 The HSDPA feature of a cell is activated.

 Try to perform the HSDPA in a good coverage area, and enable multi-thread
downloading to check whether the normal rate can be reached (depending on
the UE capability level, subscription rate and CQI).
 Check whether the R99 load or OCNS load meets test conditions.
 To test the state changes of H, check whether the state change switches for the
SP BE service and Hare enabled.
For the HSUPA test, the following need to be confirmed:

 The HSUPA feature is activated in the cell.
 The RTWP the cell is normal before the access of an HSUPA user.
 Access an HSUPA terminal in a well-covered area to check whether the
uploading rate is normal.
For the MBMS test, the following need to be confirmed:

 The MBMS is activated in the cell.
 The MBMS switch is enabled.
 The MBMS serving area and the mapping between cells and the serving area
are configured.
 The MCCH, MTCH, MSCH, MICH, FACH, and SCCPCH are configured
correctly.
1.1.4 DT Personnel and Time Schedule

Do not carry out tests in the peak hours for the flow of people. If necessary, consider
arranging the test after 10p.m. The personnel arrangement depends on the test
workload. Each team of two persons is quite suitable.
1.1.5 CN Test Devices
1.1.5.1 AMR Trunk

In previous AMR tests, the called was placed in a fixed location and watched by
specific personnel, and a laptop or handset was used to play tones continuously to
make service channels reach the proper voice activation factors. This method is
difficult to realize. Therefore, you can request carriers to deploy the automatic answer
back devices in the core network to realize AMR tests more efficiently.
The detailed requirements are as follows:
1) Have a fixed phone number can be accessed by test mobile in eMobile 3G
network
2) Auto answer the incoming calls
3) Continuously play recorded voice or music after connected, for at least 2 hours
4) Support at least 10 call connections simultaneously
1.1.5.2 FTP Server

For a PS test, there are many NEs in digital transmission channels, and route and
inter-NE bandwidth affect PS performances such as the throughput and delay.
Therefore, a FTP Server directly connected with the core network is prerequisite to
the test. The detailed requirements are as follows:
1) Have a fixed ip address can be accessed by test mobile in eMobile 3G network
2) Have direct high speed connection to GGSN, to avoid any bandwidth or round
trip time limitation in fixed network side
3) support multi-thread downloading (at least 5 threads per connection)

4) support auto resume after downloading interrupted

5) support at least 10 connections simultaneously
1.2 DT Items
Table 1 List of DT items
Test Item Not Loaded Loaded
SCANNER 3G ONLY test 3G ONLY test
1. 3G ONLY continuous call test 1. 3G ONLY continuous call test
2. Automatic continuous call test 2. Automatic continuous call test
Voice 3. 3G ONLY continuous dial-up 3. 3G ONLY continuous dial-up

test test
4. Automatic continuous dial-up 4. Automatic continuous dial-up

test test
1. 3G ONLY continuous call test 1. 3G ONLY continuous call test

VP 2. 3G ONLY continuous dial-up 2. 3G ONLY continuous dial-up
test test
1. 3G ONLY continuous download 1. 3G ONLY continuous download

test test
2. 3G ONLY continuous upload 2. 3G ONLY continuous upload

PS 64K
test test
3. 3G ONLY continuous PDP 3. 3G ONLY continuous PDP

activation test activation test

test test

PS 128K
test test


test test

PS 384K
test test

1. HSDPA 3G ONLY continuous 1. HSDPA 3G ONLY continuous

download test download test
2. HSDPA 3G ONLY 2. HSDPA 3G ONLY download

HSDPA
discontinuous download test dial-up test
3. HSDPA 3G ONLY continuous 3. HSDPA 3G ONLY continuous

PDP activation test PDP activation test

Test Item Not Loaded Loaded
1.HSUPA 3G ONLY continuous 1.HSUPA 3G ONLY continuous

uploading test uploading tes
2.HSUPA 3G ONLY discontinuous 2.HSUPA 3G ONLY discontinuous

HSUPA
uploading test uploading test
3.HSUPA 3G ONLY continuous 3.HSUPA 3G ONLY continuous

PDP activation test PDP activation test
1.MBMS 3G ONLY continuous 1.MBMS 3G ONLY continuous

MBMS test test
2.MBMS 3G ONLY call test 2.MBMS 3G ONLY call test
 Note:
 In each test, do not load any service before problems are discovered and solved.
But the results of the loading test are taken as the optimization measurement
standards. It is recommended not to load the services on the uplink and load 50%
of the services on the downlink.
 Determine the call duration and interval for dialup tests after discussions with the
customer. The recommended value is 80 s for the call duration and 15 s for the
call interval. Generally, the calling and called handsets are used for the dialup test
in vehicles. But in a formal test with the customer, the called handset should be
placed in a fixed location.
 3G ONLY means that the test handsets are locked in 3G mode and does not
support inter-system reselection or handover.
 Automatic means that the test handsets are set to the automatic mode and can
support inter-system reselection or handover when conditions are met.
For the HSDPA test, loading the downlink OCNS is to simulate the HSDPA
performances such as throughput at a certain R99 load. that can be the actual
R99 load of the AMR, VP or PS64 according to test case requirements.
Their difference is that the load for OCNS loading is not changed during the test,
while the actual R99 load of the AMR or VP raises the required power and may
preempt the HSDPA power in the coverage.
 When the HSDPA feature of a cell is activated, loading OCNS may fail due to code
resource conflicts. To solve this problem, load the OCNS first and then activate the
H feature, or reserve Ch(8,7) code for OCNS loading. Refer to section 2.4.
 HSUPA test. If the system requires an uplink test, the desensitization operation of
a physical R99 load or NodeB can be applied. Operation command: SET DESENS
(refer to the NodeB LMT Help file)
 The MBMS loading test method is the same as that of the HSDPA. An OCNS
simulated load or a physical R99 load can be applied.

1.3 PROBE DT Preparations

1.3.1 Probe Version
1.3.1.1 Software Version

The latest Probe version released at the support website is recommended for R99
tests.
For HSDPA tests, be sure to use Probe 1.3 or a later version.
When conducting an HSUPA test, you need to upgrade the Probe software and
confirm whether the License of the dongle supports the HSUPA test function. If the
License does not support the function, perform relevant upgrade operations
The Probe does not support the MBMS test temporarily. If the MBMS needs to be
tested, the drive test tool OXDM manufactured by Qualcomm can be used.
1.3.1.2 Dongle
No special dongle is required for R99 tests.
For HSDPA tests, the dongle license must support the HSDPA function. Otherwise,
you cannot observe and record HSDPA measurement data. Network planning
engineers can contact Ma Qinqin (ID: 94110, Email: maqinqin@huawei.com) to
upgrade the license.
Note: In upgrading the dongle license, do not install multiple dongles but the dongle to
be upgraded only. Refer to online help of the Probe software.
1.3.2 Preparing Test Devices
1.3.2.1 Selecting Test UE

The Probe supports the test UEs using Qualcomm chip series. Therefore, in selection
of test UEs, you just need to consider their service support features.
Huawei U626 and U636, as well as Qualcomm TM6250, can be used in R99 tests.
But the UEs and SIM cards used in HSDPA tests should be selected carefully.
1. Selecting test UE for the HSDPA test
For HSDPA tests, the selection of UEs is based on capabilities of the UEs, such as
the UE capability level (whether the UE is required to support the AMR + HSDPA and
VP + HSDPA tests).
The following UEs are applicable to HSDPA tests.
1) Huawei E620 data card: capability level 12 (supporting five HS-PDSCH codes,
QPSK modulation, and the maximum physical layer rate of 1.8 Mbps); support
AMR + HSDPA test; not support VP + HSDPA test
2) Qualcomm TM6275: capability level 12 (supporting five HS-PDSCH codes,
QPSK modulation, and the maximum physical layer rate of 1.8 Mbps); support
AMR + HSDPA and VP + HSDPA tests
3) TM6280 test handset: capability level 6 (supporting five HS-PDSCH codes,
QPSK and 16QAM modulation, and the maximum physical layer rate of 3.6
Mbps); support AMR + HSDPA and VP + HSDPA tests
4) Huawei E630: capability level 6; support AMR + HSDPA test; not support VP +
HSDPA test
You can view the UEs supported by the current Probe in the Device model pull-down
list in the Hardware Config window. But the latest UEs such as Huawei E630 are
unavailable in the Device model pull-down list of Probe 1.3. In this case, use a
similar device model instead. Generally, for the handsets using Qualcomm chip, the

format of most messages is identical, but that of few messages is changed, thus
resulting in no output in some windows.
2. Selection of HSUPA test UE

The selection of an HSUPA test UE is similar to that of an HSDPA test UE. When
conducting an HSUPA test, pay attention to the requirements of test cases for the UE,
for example, terminal capability level and support for concurrent services.
Currently, the types of HSUPA test UEs include:
1) Qualcomm 7200 handset, with the HSDPA capability level being 8 and the HSUPA
capability level being 5 (support for 2 * SF2, 10 ms TTI)
2) Huawei E270, with the HSDPA capability level being 8 and the HSUPA capability
level being 5.
3. Preparing USIM cards for HSDPA test

For the UE, there is no much difference to originate the HSDPA data service or the
R99 PS service. Whether a data service is transferred on the R99 or HSDPA depends
on the decision at the RAN side. The related factors are as follows.
 Whether the cell supports the HSDPA feature and the HSDPA feature is activated
 Type and request rate of the data service originated by the user
 User (USIM card) subscription rate
 Minimum rate threshold for transferring BE service on the HSDPA configured by
the RNC
If the cell supports the HSDPA feature, the requested service type is BE, and the Min
value (this request rate and subscription rate) exceeds the minimum rate threshold of
the HSDPA configured by RNC, the data service is transferred on HSDPA.
For the HSUPA, the factors related to whether the service is carried on an E-DCH
channel include:
 Whether the cell and the terminal support the HSUPA.
 Whether all cells in the active set support the HSUPA. If one cell does not
support the HSUPA, the service is carried on a DCH.
 Whether all cells in the active set belong to the SRNC. If a cell belongs to the
DRNC, the service is carried on a DCH.
 Whether the uplink subscription rate of the terminal is higher than the threshold
rate of the HSUPA.
4. Selection of an MBMS test UE

Currently, only the Qualcomm 7200 supports the MBMS service.
1.3.2.2 Selecting the Scanner/GPS

The frequently used scanner is the DTI Scanner. It is often used in the following tests.
1) CW test, to adjust the propagation model in the network planning phase.
2) TOPN scanning test, to optimize the coverage and neighbor cells in the network
optimization.
3) TOPN scanning for multiple frequency point comparison, to compare the
coverage of multiple frequency points in the same network, optimize inter-
frequency handover, or compare the coverage of different carriers in the same
area.

In addition, the DTI Scanner has the GPS receiver that can be used to test the GPS
longitude and latitude (place the GPS antenna on the top of the vehicle in tests).
If the above items are involved, the scanner must be used. If only the test track need
be recorded, the ordinary GARMIN series GPS can be used.
 Note:
The GARMIN GPS reports the longitude and latitude every two seconds, while the
DTI Scanner reports every second. Moreover, the track recorded by the GARMIN
GPS offsets largely from the MAPINFO map, while that recorded by the DTI Scanner
is quite accurate. Therefore, use the DTI Scanner for tests when conditions permit.
1.3.2.3 Connecting UEs

Connect such devices as the test UE and scanner with the test laptop. For details,
refer to “Connecting DT Devices.”
For vehicle power supply, refer to “Recharging on Vehicles.”
1.3.2.4 Installing Interface Drivers of the Data Card and Test Handset
 Installing the driver of E620 data card
You just need to run the Setup.exe in the setup package of the E620 data card, and
the driver can be installed automatically. First, run the Setup.exe. Then, connect the
data card with the computer. The computer automatically identifies the new hardware
and asks you to install the driver. In this case, you can need to follow the system
instructions to let the OS detect and install the driver automatically. After the driver is
installed, the system automatically identifies the three ports used by the data card.
The first port is used by the MODEM during dialup (right-click the node and select
Properties. The MODEM tab displays the port number mapped from the data card to
the Modem). The second port, namely the COM5 shown below, is used by test tools
such as the Probe and QXDM. The third port, namely the COM6 shown below, is
used by AT commands and background software (this port can be regarded as a trial
port for internal product debugging, and we do not need to use this port). Note that
the background software and the third port cannot be enabled at the same time.

Figure 1 Ports on the E620 data card
 Installing the driver of the test handset

Connect the test handset (such as Huawei U626, U636, Qualcomm TM6275 or
TM6280) to a computer with the USB cable. The system automatically asks you to
install the USB driver for the handset. After the driver is installed, you can view the
handset driver identified and installed by the system in the Modem and Port nodes
through the device manager.
1.3.3 Hardware Configuration
Start the Genex Probe 1.3. Select Configuration > Hardware Config > Manual
Config, as shown in Figure 1.
EMBED Visio.Drawing.6
Automatic
configuration
Manual configuration
Figure 1 Hardware configuration
Configure the hardware devices in the Manual Config window, as shown in Figure 2

EMBED Word.Picture.8
Figure 2 Manual configuration
1.3.3.2 Setting the UE

1) Connect the data card or handset with the USIM inserted to a computer. Refer to
Figure 4.
2) Set the port and baud rate of the UE.
In the Manual Config window, add a UE, and set the device model and baud rate
according to the UE model, and set the Modem port if you want to use the Probe for
automatic dial-up of the PS service. The Com Port and Modem Port can be found
through the device manager.
Figure 1 UE setting
For PS service tests (including the tests of the PS service transferred on the HSDPA),
the Modem port must be configured. Otherwise, the Probe can neither originate the
automatic PS tests nor record the App layer throughput and service statistics
information.

 Note:
When the configured device model is different from the actual UE used, the hardware
may be still found, but the test items provided in Test Plan and the parameters
displayed in the Department window may be incorrect.
For example, if Huawei U626 is used, but TM6200 is set in Device Model, the VP
test is not available in the Test Plan as the TM6200 does not support VP test.
Therefore, when the used UE model is available in the Device Model, select the
correct model; when the used UE is not available, select a most similar UE model.
1.3.3.3 Setting the DTI Scanner

To set the DTI Scanner hardware, proceed as follows:
1) Connect the data line of the DTI Scanner to the serial port of a computer. Refer
to Figure 1.
2) Connect the RF antenna to the Scanner, and place the RF antenna on the top of
the vehicle. Refer to Figure 1.
3) Connect the GPS antenna to the Scanner, and place the GPS antenna on the
top of the vehicle.
4) Connect the power cable of the scanner to the vehicle power supply (often the
cigarette lighter).
5) After the power supply is switched on, the scanner is started automatically.
During the startup, observe the indicators. First, the scanner performs a self-test,
and the yellow indicator flashes. After the self-test, the scanner begins to run
normally, and the green indicator is always on.
6) In the Manual Config window, add the scanner, and set the Device Model to
DTI, Baud Rate to 115200, and Com Port to the serial port on the computer
connected with the data cable of the scanner.
Figure 1 DTI Scanner setting
1.3.3.4 Testing the Port
After the port is configured, click (test port) to test whether the port is available or
connected properly. If the state indicator on the lower right corner is green, the device
runs normally. Each port of each device has a state indicator. Move the cursor to the
state indicator, and the port information is displayed in a floating window.

You need to set the proper device type, port number and baud rate in the Hardware
Configuration window of the Probe. For the GARMIN GPS and Anritsu scanner, you
also need to set the interface type and baud rate at the device side. For the GARMIN
GPS, set the interface to NMEA0183. For hardware configuration and port detection,
refer to related device connection information of the Help or User Manual of the
Probe.
1.3.4 Importing BTS Information

Only after the BTS parameter table is configured, the BTS information and connection
lines can be displayed on the map during the test or playback. The system supports
the WCDMA and GSM BTS configuration files. When you save a project, the system
saves the BTS configuration as a project file for later uses. To import the BTS
information, proceed as follows:
1) Select Configuration > BTS Information > WCDMA, as shown below.
Import by format
Figure 1 Importing project parameters (1)
2) Click . The BTS Information window appears. Select a BTS information file
and click Open. If you find some imported parameters incomplete or incorrect,
edit them in the BTS Information window shown in Figure 1. After modification,
click to save the modified information as a BTS information file (*.CSV). Click
to apply the BTS information to the map window.

After opening the project parameter

file, click this button to confirm.
Otherwise, BTS information is not
imported into the map.
Open the project

parameter file.
Note: The tables to

be imported shall
be in the same
format as this table.
Before importing,
prepare the BTS
information table
according to this
format.
Figure 1 Importing project parameters (2)
1.3.5 Adjusting PC Time

To adjust PC time, proceed as follows:
1) Select Configuration > System Config > other. Uncheck the option of Using
GPS time to adjust PC time, as shown below.
Figure 1 Canceling PC time adjustment
2) Use BAM time to adjust PC time

Phone the RNC personnel to adjust PC time according to BAM time.
Method: RNC personnel read out seconds of the BAM, and one person adjusts PC
time accordingly.

 Note:
 In the measurement tracing file on the LMT at the RNC side, the recorded time is
BAM time other than LMT time. Therefore, PC time and BAM time are checked
here.
 When the option of Using GPS time to adjust PC time of the Probe is checked,
the test PC time is changed automatically with GPS time if the scanner or GPS is
connected and the GPS longitude and latitude can be obtained. Therefore, to
adjust PC time according to BAM time, you need to uncheck the option of Using
GPS time to adjust PC time first.
1.3.6 Making Test Plan for Each Test Item

To make a test plan, select Configuration > System Config > Test Plan. This
section details how to make a test plan for each test item.
1.3.6.1 SCANNER 3G ONLY test (Return)

 TopN Pilot scanning
Measure and report top N pilots (32 at most). They are sorted by the Ec/Io. The
configuration window is shown in Figure 1.
Figure 1 Data configuration for TopN Pilot Scan
 Description of configuration items:

Set Enable to True and set Channel to five times of the WCDMA frequency
points to be tested. Reserve the default values for other parameters.
 Enable: whether to run a test item after the test starts. The available values
are True and False. Set the value to True.
 Channel: number of the tested frequency point. The channel number is
equal to the frequency point multiplied by 5. For example, if the frequency
point of the carrier is 2132.8 MHz, Channel is 10664 (2132.8 MHz x 5). Up
to six frequency points can be tested at a time. In this case, the frequency
points should be divided with commas.
 PilotNumber(N): quantity of the top pilots scanned. The value ranges from 1
to 32. The default value 6 is recommended.
 Chip Window Size: the size of the pilot chip window. The value ranges from
1 to 64. Use the default value 32.

 TopN PN Threshold (dB): the minimum threshold of Top N pilots. That is, the
pilots with the Ec/Io lower than this threshold are not reported. Use the
default value -20.5 dB.
 Scan Rate (ms): the test period. The value ranges from 2 to 9999. Use the
default value 10 ms.
 Measure Ec/Io: whether to measure the Ec/Io index of the pilot. The
available values are True and False. Set the value to True.
 Measure TimeOffset: whether to measure the time offset of the pilot. The
available values are True and False. Set it to False.
 Measure Aggregate Ec/Io: whether to measure the total Ec/Io index. The
 Measure Eps/Io: whether to measure the Eps/Io index of the pilot. The
 Measure Delay Spread: whether to measure the transmission delay. The
 Measure Ess/Io: whether to measure the Ess/Io index of the pilot. The
 Measure Rake Finger Count: whether to measure the quantity of the
multipath of the Rake receiver. The available values are True and False.
Set it to False.
 Measure SIR: whether to measure the SIR index. The available values are
True and False. Set the value to True.
 Test application:
For network optimization services, the scanner is often used in pilot coverage tests to
obtain important network coverage performance indexes, such as the mileage call
drop ratio, pilot pollution percentage, soft handover percentage and coverage ratio. In
addition, the collected data provides important bases to solve unconfigured neighbor
cells and some complex network problems. The common test form is scanner + a
service.
1.3.6.2 Voice 3G ONLY Continuous Call Test (Return)
Figure 1 Data configuration for voice (continuous call) test

 Enable: whether to test the item after the test starts. The available values
 Call Number: the called number.
 Call Type: type of a call. The available values are Continuous Call and Call
by Call.

Continuous Call: The call is not interrupted by the software unless other
events happen (for example, the call drops due to network problems or is
terminated by the user). If the call cannot be set up, or drops or terminated
during conversation, the Probe starts the next call after the preset interval
time.
 Vocoder Rate(bps): AMR. The available values are 4750, 5150, 5900, 6700,
7400, 7950, 10200 and 12200. For a voice test, use the value 12200.
 Setup Time(S): the maximum time for setting up a call. The value ranges
from 5 to 60. If a call cannot be set up successfully within the setup time, the
call is regarded as failed. Use the default value 25.
 Interval Time(S): interval of calls. After the last call is ended, the next call is
originated after the interval time. Use the default value 10.
The voice continuous call test is an important service test used to verify the voice
service retainability, integrity and mobility of the network. The collected data is the
important basis to locate and solve common network troubles such as call drop, too
high BLER and soft handover failure.
1.3.6.3 Voice 3G ONLY Continuous Dial-Up Test (Return)
Figure 1 Data configuration for voice (call by call) test
 Configuration items:
 Call Type: type of a call. The available values are Continuous Call and Call
by Call.
Call by Call: The Probe controls the terminals to make calls, and carries out
call tests repeatedly based on the calling time and interval time. The
quantity of tests can be set in Call Count.
 Vocoder Rate(bps): AMR. The available values are 4750, 5150, 5900, 6700,
7400, 7950, 10200 and 12200. For a voice test, use the value 12200.
 Calling Time(s): the duration of a single call, namely, the duration from setup
to normal termination of a call. This parameter is used for call by call only.
The default value is 50. You can set it according to test requirements.

 Interval Time(S): interval of calls. After the last call is ended, the next call is
originated after the interval time. Use the default value 10.
 Count Mode: call times are restricted. Finite indicates that call times are
restricted, and the quantity of calls can be set in Call Count. Infinite
indicates that call times are not restricted.
 Call Count: quantity of calls. The call count can be estimated according to
the actual test route length and test time. Try to set the value higher. Stop
the test after the test route is covered or after the test time. For the network
acceptance, the call count cannot be less than 200.
The voice continuous dial-up test is an important service test used to test the voice
service accessibility of the network. The collected data is the important basis to locate
and solve voice access failure problems.
1.3.6.4 VP 3G ONLY Continuous Call Test (Return)
Figure 1 Data configuration for VP (continuous call) test
to normal termination of a call. The VP test item distinguishes the VP
continuous call and call by call based on call duration only. You can
calculate this value according to the test time. For example, in a continuous
call test lasting for half a day, use the value 15000 (about four hours,
15000/3600 = 4.17).
 Interval Time(s): interval of calls. After the last call is ended, the next call is
originated after the interval time. Use the experiential value 15.
 Call Count: quantity of calls. Calls may drop during the test. The call count
must be higher than 1. The default value 30 is often used.
The VP continuous call test is an important service test used to verify the VP service
retainability, integrity and mobility of the network. The collected data is the important
basis to locate and solve common network problems such as call drop, too high
BLER and soft handover failure.

1.3.6.5 VP 3G ONLY Continuous Dialup Test (Return)
Figure 1 Data configuration for VP (call by call) test
to normal termination of a call. The VP continuous call and call by call are
differentiated by call durations only. Use the value 50 unless the call hold
duration is clearly specified.
 Interval Time(s): interval of calls. After the last call is ended, the next call is
originated after the interval time. Use the experiential value 15.
 Call Count: quantity of calls. This parameter is used for call by call only. The
call count can be estimated according to the actual test route length and test
time. Try to set the value higher. Stop the test after the test route is covered
or after the test time. For the network acceptance, the call count cannot be
less than 200.
The VP continuous dial-up test is an important service test used to test the VP service
accessibility of the network. The collected data is the important basis to locate and
solve VP access failure problems.
1.3.6.6 PS 3G ONLY Continuous Download Test (Return)
If the APN is required, the PS Dialup and FTP Download should be tested. If the
APN is not required, only the FTP Download should be tested.
1. Configuring the PS Dialup test item

Figure 1 Configuring PS dialup
 PDP Type: type of the PDP, such as IP and PPP. Set the value to Default.
 PDP APN: name of the access point, such as cmwap for China Mobile.
 Traffic Class: type of the service, including Conversational, streaming,
interactive, background and subscribed. If no specific service type is
required for the test, select background class. Otherwise, set the service
type according to the test item.
UL Max V(kbit/s): maximum uplink bit rate. If the uplink subscription rate of
the UE is used for testing, you do not need to set this value If you want to
make the maximum uplink rate smaller than the uplink subscription rate, set
this value according to actual test requirements.
 DL Max V(kbit/s): maximum downlink bit rate. If the downlink subscription
rate of the UE is used for testing, you do not need to set this value. If you
want to make the maximum downlink rate smaller than the downlink
subscription rate, set this value according to actual test requirements.
 UL Ensure V(kbit/s)1: guaranteed uplink bit rate. Set it to Default.
 DL Ensure V(kbit/s): guaranteed downlink bit rate. Set it to Default.
1
The BE service rate is not guaranteed. If you do not set this parameter to Default, the UE may
fail to be connected.

Note:
 The PS Dialup item is to set up a PS service connection.
 If the values of APN and QoS are null, the Probe does not send related commands
to the UE, and the original settings of the UE are used.
 If you do not set the PS Dialup and set the FTP Download only, the Probe also
tries to set up a PS dialup connection without APN settings. To modify the APN,
you have to run the AT command of MODEM or use the last APN setting of the
UE.
 If AT commands for the APN and QoS are set in MODEM initialization commands,
they will prevail. That is, the settings in the Probe are invalid. This is because the
AT commands in the MODEM initialization commands are sent to the UE lastly in
the dialup connection setup, and overwrite the commands sent to the UE
previously.
 Similar cases exist in other PS test items.
Except the APN and QoS settings in PS Dialup, the Dial Up Connection setting in
System Config > Other menu affects the automatic dialup connection setting of the
Probe. The Dial Up Connection setting covers the dialed number (*99#), user name,
password (configured according to requirements) and timeout duration (60 s by
default), as shown below.
Figure 2 System Config > Other settings

2. Configuring FTP Download item
Figure 3 Configuring Ftp DownLoad

 Port: port number of the target host. Use the default value 21.
 USER: account used to access the destination host. If the FTP server
adopts the anonymous access mode, set the value to anonymous.
 Password: password used to access the destination host.
 Remote File: the path of the destination file on the host. The input format is
[ftp://] + IP address + ”/” + filename (with the path), such as
10.0.0.1/download/test.dat.
 Local File: the path of the file downloaded and saved locally, such as
c:\test.dat.
 Interval Time(s): the interval between two download tests. Use the default
value 5.
 Test Times: total quantity of tests. Set the value according to the source file
package size, downloading rate and test duration. The suggested value is
10.
 Disconnect: whether to disconnect a PS connection. Three modes are
available:
 Keep connect: After the destination file is downloaded, the system
does not deactivate the PDP (while holding the RRC connection) but
originates the next FTP download after the interval time.
 By Time: The system deactivates PDP periodically. The period is the
disconnect time. If the file is not fully downloaded within the preset
time, the downloading result is “timeout” and counted as download
failure. In addition, the PDP is deactivated after expiry.
 After Transfer Complete: The PDP is deactivated each time when a
file is downloaded.
You can choose a proper mode according to actual test requirements. For a
continuous download test, you can set it to keep connect. However, you
still want to access the FTP server for some period though no data is
transferred. Therefore, if you want to associate the downloading, the remote
file must be large enough to keep data transfer along the DT track.

The FTP downloading test is an important PS test used to verify the PS service
retainability, integrity and mobility of the network. The collected data is the important
basis to locate and solve common network problems such as call drop, too high
BLER and soft handover failure.
1.3.6.7 PS 3G ONLY Continuous Upload Test (Return)
Figure 1 Configuring Ftp UpLoad
For test item descriptions, refer to 1.3.6.6.

Before testing, ensure that you have the upload privilege to the FTP server.
1.3.6.8 PS 3G ONLY Continuous PDP Activation Test (Return)
Figure 1 Configuring PDP activation
 PDP Type: type of the PDP, such as IP and PPP. Set the value to Default.
 PDP APN: name of the access point, such as cmwap for China Mobile.
 Traffic Class: type of the service, including Conversational, streaming,
interactive, background and subscribed. Select background class.
 UL Max V(kbit/s): maximum uplink bit rate. The value 64 is often used.

 DL Max V(kbit/s): maximum downlink bit rate. The value 128 is often used.
 UL Ensure V(kbit/s)2: guaranteed uplink bit rate. Set it to Default.
 DL Ensure V(kbit/s): guaranteed downlink bit rate. Set it to Default.
 Need Dialup: whether to set up a service channel. If it is set to False, only a
signaling plane connection is set up for requesting and accepting PDP
activation but not for carrying services. If it is set to True, both a signaling
plane connection and a service plane connection are set up, that is,
channels that can carry services are set up between the PC and handset
and between the handset and CN. You can set the value according to test
requirements. The default value is False.
 Activate Time(sec): the interval from the completion of activating PDP to the
beginning of deactivating PDP. Use the default value 2.
 Activate Time(sec): the interval from the completion of deactivating PDP to
the beginning of activating PDP. Use the default value 3.
 Test Time(sec): times of the paired implementation of PDP activation and
PDP deactivation. The value depends on the actual test route length and
test time. For the network acceptance, the call count cannot be less than
200.
The PS continuous PDP deactivation test is an important PS test used to test the PD
service accessibility of the network. The collected data is the important basis to locate
and solve PS access failure problems.
1.3.6.9 HSDPA 3G ONLY Continuous Download Test (Return)

The HSDPA continuous download test can be performed automatically (through the
Test Plan setting of the Probe) or manually.
To control automatic downloading of the UE through Test Plan setting of the Probe,
refer to “PS 3G ONLY Continuous Download Test (Return).” The operation methods
of the HSDPA download test are the same as PS continuous download test of the
R99. However, some problems exist when the Probe is used for the HSDPA
automatic and continuous download.
1) For Probe 1.3 or an earlier version, single-threshold downloading is adopted for
automatic FTP download. For a HSDPA test, multi-threshold download is
preferred to keep the download rate stable.
2) For Probe 1.3, only one remote file is set in Test Plan. If a continuous and high-
speed download is required in a test lasting for two to three hours, a source file
of a considerable size is required.
Therefore, for present HSDPA continuous download tests, the Probe software is
recommended for automatic dialup, but multi-thread download of the FlashGet should
be enabled manually.
That is, only one test item, namely PS Dialup, is set in Test Plan.
Start the test. After the Probe sets up a PS service connection automatically, use the
FlashGet and set five threads for downloading.
Record APP throughput and HSDPA parameters through the Probe.
2
Qualcomm chip does not support the maximum guaranteed PS rate on the UE. If you do not
set the value to Default, the UE may fail to be connected.

1.3.6.10 HSDPA 3G ONLY Download and Dialup Test (Return)

This test is a dialup test with the automatic FTP download function of the Probe. Its
operation methods are similar to 1.3.6.6. Two operation methods are available.
1) In the FTP Download, configure small files to be downloaded in the remote file
field, and select Disconnected after transfer completed in the Disconnect
mode field. In this way, after the file is downloaded, the Probe controls the UE to
deactivate PDP and end a PS call.
2) In the FTP Download, configure large-sized files to be downloaded destination
file in the remote file field, and select by time in the Disconnect mode field. In
this way, a timing dialup test can be realized.
1.3.6.11 HSDPA 3G ONLY Continuous PDP Activation Test (Return)

If the cell supports the HSDPA feature, the BE service is requested, and the Min value
(this requested rate and subscription rate) exceeds the HSDPA minimum rate
threshold of the RNC, the data service is transferred on the HSDPA.
The test method is the same as that of the R99. The Test Plan setting is the same as
that for the continuous PDP activation test of the R99. Refer to 1.3.6.8.
1.3.6.12 HSUPA 3G ONLY continuous uploading test (Return)

The HSUPA continuous uploading test can be performed in two ways: Set automatic
uploading through Testplan of the Probe or manually upload.
There is no difference between automatic uploading through Testplan of the Probe
and R99 PS continuous uploading test in terms of operations. For details, see section
1.3.6.7.
In the case of manual uploading, first open the Probe software, prepare for the test,
access the network through a dialup connection, upload a file through the FTP, and
observe the parameter change in different windows of the HSUPA.
1.3.6.13 HSUPA 3G ONLY uploading call test (Return)

The HSUPA 3G ONLY uploading call test is similar to the HSUPA 3G ONLY
downloading call test. For details, refer to the test plan in the Probe User Manual.
1.3.6.14 HSUPA 3G ONLY continuous PDP activation test (Return)

The test method is similar to R99.
1.3.6.15 MBMS 3G ONLY continuous test (Return)

Currently, the Probe does not support the MBMS test and the related test plan will be
supplemented when it supports the MBMS test.
If data record is required, use the QXDM tool manufactured by Qualcomm to conduct
the test manually.
1.3.6.16 MBMS 3G ONLY call test (Return)

Currently, the Probe does not support the MBMS test and the related test plan will be
supplemented when it supports the MBMS test.
If data record is required, use the QXDM tool manufactured by Qualcomm to conduct
the test manually.

1.4 Selecting a Test Window

After the test plan is made, open the window where you can observe messages and
prepare for the test.
The parameters displayed in each window are reported as messages by the UE. The
UE can report many messages. If all messages are reported, the test file is of a large
size and requires a high USB data channel bandwidth. Therefore, the UE should be
controlled to report the required messages only through the logmask. The default
logmask of the Probe has been set to report the messages to be observed.
Select System Config > Logmask. In the popup window, you can modify the
logmask. An item with a tick will be reported. For the common windows and
corresponding Logmask Item of the messages, refer to 6.5. Generally, do not delete
the default configurations.
In the Probe, windows are arranged in a tree format, as shown below. Double-click a
node. The corresponding window appears.
Figure 1 Selecting an observation window

1.4.1 Active Set and Neighbor Cell
Figure 1 A window for active set and neighbor cell test
This window is used to observe information (such as the downlink frequency, SC,
Ec/Io and Ec) and charts of the active set, monitor set and inter-frequency monitor
set.
1.4.2 RRC Signaling
Figure 1 RRC message
This window shows the RRC information traced by the UE.

1.4.3 Map Setting and Displaying
Figure 1 Map
The map parameters cannot be imported or configured after the test starts. Therefore,
be sure to configure the map before the test. To import and set a map, proceed as
follows:
1) Click map in Figure 1. The Map window appears, as shown in Figure 1.
2) Click . Select a mapinfo file (*.gst), and click Open.
3) Click to save the layer (not the temporary layer) of the map to the Geoset file.
4) Click to set the layer, mainly to add, delete, move the layer, and set the layer
to visible, selectable, editable or display labels automatically.
5) The buttons in the toolbar indicates to set
legend, zoom in, zoom out, pan, center map, select NE, measure distance,
locate, undo and rotate respectively.
1.4.4 Scanner TopN Pilot
When the DTI Scanner is used as a test device and set to TopN Scan in the test plan,
this window is valid. This window shows the top N SCs detected at the current
location and such information as Io, Ec, Ec/Io, ToffsetOrDelay, Aggregate Ec/Io,
Epslo, EssIo, DelaySpread and SIR. The display can be switched by right-clicking.
The SCs and their Ec and Ec/Io are our concerns.
The TopN Scan of the DTI Scanner supports multiple frequency points. Right click in
the window, and you can select the frequency points to be observed.
1.4.5 Scanner Pilot Scan
This window shows the Io, Ec, Ec/Io, ToffsetOrDelay, Aggregate Ec/Io, Epslo, EssIo,
DelaySpread and SIR of the pilot scan. The display can be switched by right-clicking.
The Ec and Ec/Io are our concerns.

1.4.6 HSDPA Window
1.4.6.1 HSDPA Link Statistics
Figure 1 WCDMA HSDPA link statistics
Parameter Description:
 Scheduled Rate-Delta: the transient scheduling rate at the MAC layer (the
average transient rate within 200 ms, the same below)
 Scheduled Rate – Average: the average scheduling rate at the MAC layer (the
average rate of all data above; the same below)
 Served Rate – Delta: the transient transmission rate at the MAC layer, involving
transmission failures and retransmissions
 Served Rate –Average: the average transmission rate at the MAC layer,
involving transmission failures and retransmissions
 MAC Layer Rate – Delta: the transient transmission rate at the MAC layer, not
 MAC Layer Rate – Average: the average transmission rate at the MAC layer, not
 HS-SCCH Success Rate – Delta: the transient scheduling success rate of the
HS-SCCH
 HS-SCCH Success Rate –Average: the average scheduling success rate of the
HS-SCCH
 HS-DSCH SBLER – Delta: the transient block error rate (BLER) of the HS-DSCH
(block errors / total blocks)
 HS-DSCH SBLER – Average: the average BLER of the HS-DSCH
 HS-DSCH Res. SBLER – Delta: the transient residual SBLER of the HS-DSCH
(the transient BLER at the RLC layer. That is, after several retransmission
attempts fail at the MAC layer, the RLC layer originates retransmission)
 HS-DSCH Res. SBLER –Average: the average residual SBLER of the HS-DSCH
 CQI: the average channel quality indication (the average value of all CQIs within
200 ms)
 Number of HS-PDSCH Codes: quantity of the occupied HS-PDSCH codes (the
average value within 200 ms)
 Note:
 Delta indicates the transient value, namely the average value within 200 ms.
 Average indicates the average value, namely the mean value of all above data.
Served Rate = Scheduled Rate * HS-SCCH Success Rate
Mac Layer Rate = Served Rate * (1-SBLER)

1.4.6.2 HSDPA Channel Configuration
Figure 1 WCDMA HSDPA physical channel
1) HS-DSCH Configuration
 HS Serving Cell PSC: the SC of the HSDPA serving cell
 H-RNTI UE ID: HSDPA Radio Network Temporary Identifier. It identifies a
UE with the RRC connection in the UTRAN.
 DL DPCH to HS-SCCH Timing Offset: the time offset of the DL DPCH in
opposite to the HS-SCCH
 HARQ Processes: quantity of the HARQ processes. An HARQ entity can
process multiple HARQ processes of a user.
2) Uplink HS-DPCCH Configuration

 CQI Feedback Cycle(SubFrame): the period for CQI feedback. The unit is
SubFrame.
 CQI Repetition Factor
 Ack/Nack Repetition Factor
 UL DPCH to HS-DPCCH Timing Offset: the time offset of the HS-DPCCH
relative to the UL DPCH
 PO-ACK: the ACK power offset relative to the UL DPCCH
 PO-NACK: the NACK power offset relative to the UL DPCCH
 PO-CQI: the CQI power offset relative to the UL DPCCH
3) HS-SCCH Configuration
 HS-SCCH: number and validity of an HS-SCCH. A UE can monitor up to
four HS-SCCHs at the same time.
 OVSF: the OVSF of an HS-SCCH
4) MAC-d Flow Mapping List

 MAC-d Flow ID: the ID of the MAC-d flow
 CCTrCH ID: the ID of a code combined transmission channel
 QUEUE ID List: the list of queue IDs. Each queue ID is displayed in the
Recording QUEUE Parameters area.

5) Reordering QUEUE Parameters

 QUEUE ID: the ID of a queue
 Receive Windows size: the size of the MAC-hs window
 Reordering Release Time: the duration of the resorting release timer of the
MAC-hs
 MAC-d PDU Sizes: the size of the MAC-d PDU
1.4.6.3 HSDPA Decoding Statistics
Figure 1 HSDPA decoding statistics
1) HS-SCCH Decode Statistics
 HS-SCCH Attempts: the total number of HS-SCCHs
 HS-SCCH Success: the quantity of the HS-SCCH frames scheduled to the
UE
 HS-SCCH Success Rate: HS-SCCH scheduling success rate
 ACK-->NACK/DTX(Duplicate SB+)(%): the percentage of the NACK frames
that are decoded by NodeB from the ACK sent by the UE
2) HS-DPCCH Decode Statistics

 TBS(bits): the transmission block size. Each frame transmits one TB only.
 QPSK: the quantity of the frames mdouled with the QPSK
 16QAM: the quantity of the frames mdouled with the 16QAM
 SB-: the quantity of the frames transmitted unsuccessfully at the MAC layer
 SB+: the quantity of the frames transmitted successfully at the MAC layer
 Dup. SB+: the quantity of the NACK frames that are decoded by NodeB
from the ACK sent by the UE
 Other: the quantity of the abnormal frames, such as the successfully
retransmitted TBS frames inconsistent with those transmitted latestly
 SBLER(%): transmission failures / total transmissions, indiating the BLER at
the MAC layer
 1st SBLER(%): the ratio of the block errors resent for the first time

 Block-: the quantity of the frames failing to be sent at the RLC layer. That is,
the RLC layer resends the frames after several successful attempts at the
MAC layer. In this case, this value should plus one.
 Block+: the quantity of the frames transmitted successfully at the RLC layer,
which is equal to SB+.
 Res.BLER: the BLER at the RLC layer. That is, the RLC layer resends the
frames after several successful attempts at the MAC layer.
 1: the quantity of the frames transmitted successfully at the MAC layer in the
first attempt
second attempt. That is, the frames are resent successfully.
third attempt
fourth attempt
fifth attempt
 >=6: the quantity of the frames transmitted successfully at the MAC layer
after more than five attempts
1.4.6.4 Active Set PSC Strength
Figure 1 Active set PSC strength
This window shows the main SCs and their Ec/Io of the active set. Through the
legends of any part of a curve, you can know the current state of a cell: idle, non-
HSDPA or HSDPA. Idle cells are indicated by disperse points. Non-HSDPA cells in a
call are indicated by connected lines. HSDPA main serving cells are indicated by
curves with small blocks.

1.4.7 HSUPA window
1.4.7.1 HSUPA DL Channel Configuration
HSUPA DL Channel Configuration window

Parameter description:
(1) HSUPA DL All Channel Configuration
SERV_CELL_INDEX: Indicates which cell is the serving cell (cell where the AGCH
lies)
TTI: Transmission time interval, 2 ms or 10 ms.
SG_SEL: Service grant selection
P_ERNTI: Primary E-RNTI of the UE
S_ERNTI: Secondary E-RNTI of the UE
AGCH_ACTION: Access grant channel (AGCH) actionOptions include No operation,
Enable, Disable, Timing maintained reconfiguration, and Timing changed
reconfiguration
AGCH_VALID: Indicates whether the AGCH information field is valid
AGCH_OVSF: Code word applied by the AGCH
AGCH_START: Start EUL frame number or subframe number for AGCH. Value range:
0 to 255 when TTI=10 ms, and 0 to 1279 when TTI= 2 ms.
AGCH_END: End EUL frame number or subframe number for AGCH. Value range: 0
to 255 when TTI=10 ms, and 0 to 1279 when TTI= 2 ms.
AGCH_DPCH_OFFSET: The offset into DPCH’s timeline where the first AGCH TTI
begins. Unit: 256 chips, value range: 0 to 129.
STTD_AGCH: Indicates whether the AGCH applies STTD or not
(2) HSUPA DL Each Cell Configuration in the EUL Active Set

CELL_IDX: Cell IDs in the E-DCH active set, at most four cell IDs whose value range
is 1 to 6
PSC: Primary scrambling code
SERV_CeLL: Indicates whether the cell is the serving cell
RLS_IDX: RLS Index
REF_FINGER: Reference finger index, in the range of 0 to 31
TPC_INDEX: Index for HICH RLS, cells belonging to the same HICH RLS have the
same index
RGCH_ACTION: Including No operation, Enable, Disable, Timing maintained
reconfiguration, and Timing changed reconfiguration
RGCH_VALID: Indicates whether the RGCH information field is valid
HICH_ACTION: Including No operation, Enable, Disable, Timing maintained
reconfiguration, and Timing changed reconfiguration
HICH_VALID: Indicates whether the HICH information field is valid
HICH_OVSF: OVSF code word applied by HICH and RGCH
HICH_START: Start EUL frame number or subframe number for HICH. Value range: 0
HICH_END: End EUL frame number or subframe number for HICH. Value range: 0 to
255 when TTI=10 ms, and 0 to 1279 when TTI= 2 ms.
HICH_DPCH_OFFSET: Offset into DPCH’s timeline where the first HICH TTI begins.
TAU_HICH: Tau HICH in units of slots.
HICH_SIGNATURE: Signature sequence ID of Hadamard code for HICH. Value
range: 0 to 39
HICH_STTD: Indicates whether HICH uses STTD or not
RGCH_START: Start EUL frame number of subframe number for RGCH. Value range:
0 to 255 when TTI=10 ms, and 0 to 1279 when TTI= 2 ms.
RGCH_END: End EUL frame number or subframe number for RGCH. Value range: 0
RGCH_DPCH_OFFSET: Offset into DPCH’s timeline where the first RGCH TTI
begins. Unit: 256 chips, in the range of 0 to 149
RGCH_SIGNATURE: Signature sequence ID of Hadamard code for RGCH, in the
range of 0 to 39.
DPCH_CHANNEL: Channel number of DL DPCH, in the range of 0 to 7.

1.4.7.2 HSUPA UL Channel Configuration
HSUPA UL Channel Configuration window

(1) HSUPA UL Channel Configuration
TTI: Transmission time interval in ms, Value: 2 or 10
IR_CC: Value: Increment redundancy or Chase combining
DPDCH_PRES: Indicates whether there is any R99 DPDCH
HS-DPCCH_PRES: Indicates whether there is any HS-DPCCH
SLOT_FORMAT: DPCCH slot format, in the range of 0 to 3
ACTION_TYPE: Value: Disable, Enable, or Reconfigurations
MAX_EUL_SF: Signaled max EUL spreading factor; highest supported spreading
factor.
START_FRAME_NUM: Start EUL frame number or subframe number for E-DPCH.
END_FRAME_NUM: End EUL frame number or subframe number for E-DPCH.
PL_NON_MAX: Indicates the puncturing limit for nonmaximum number of codes.
MAX_TX_PWR: Maximum transmit power of the UE
IQ_MAP: E-DPDCH I/Q mapping
SERVING_GRANT: Initial SG value
GRANT_SEL: Value: Primary or Secondary
2IDX_STEP_T: ETFCI threshold switching from 1-step to 2-step ETFCI increments
due to RGCH command, in the range of 0 to 37
3IDX_STEP_T: ETFCI threshold switching from 2-step to 3-step ETFCI increments
due to RGCH command, in the range of 0 to 37
EDPCCH_PO: Power offset for E-DPCCH relative to DPCCH, in the range of 0 to 8.

(2) HSUPA UL Channel Each Reference Power Offset

TFCI_CONFIG: Indicates whether Ref E-TFCI configured
REF_TFCI: Reference E-TFCI, in the range of 1 to 127
REF_PWR_OFFSET: Reference Power offset, in the range of 0 to 29
1.4.7.3 HSUPA Link Statistics
HSUPA Link Statistics window

Parameter description:
(1) HSUPA Link Throughput Statistics
MAC-e PDU Non-DTX Rate: Non-discontinuous transmission rate
=sum of all TB sizes in the case of non-DTX/(number of non-DTXs * TTI)
Actual rate of MAC-e (excluding DTX, but including the rate of retransmitted blocks)
MAC-e PDU Served Rate: Served rate
=sum of all TB sizes in the case of non-DTX/(NUM_SAMPLES * TTI)
Served rate of MAC-e (including DTX and the block error rate)
MAC-e PDU Available Rate: Available rate
=sum of TB sizes when COMB_HICH is ACK or ACK_NS in the case of non-DTX/
(NUM_SAMPLES*TTI)
MAC-e PDU Available Rate (including DTX but excluding the block error rate)
(2) HSUPA Link Quality Statistics
Non-DTX Probability:
Ratio of the number of TTIs of non-DTX to the total number of TTIs
SBLER: Sub-block error rate.
Ratio of the number of error blocks to the total number of transmission blocks. Error
blocks include the cases that the UE sends signals but the NodeB fails to receive
signals or the UE receives signals but incorrectly decodes them into DTX.

1st SBER:
Ratio of the number of failed transmission blocks to the total number of transmission
blocks transmitted for the first time
Power limited rate:
Ratio of the number of TTIs of the limited maximum power to the total number of TTIs
SG limited rate:
Ratio of the number of limited SGs to the total number of SGs
Buffer limited rate:
Ratio of the number of limited buffers to the total number of buffers
Happy rate:
Ratio of the number of HAPPY TTIs to the number of non-DTX TTIs
(3) HSUPA Grant Statistics
Average AG:
=Sum of all AG-VALUEs when AGCH_FLAG is 1/number of AGCH_FLAGs equal to 1
Combined RG:
=Accumulation of UP times + (accumulation of DOWN times *–1)
Average SG:
=Sum of valid SG_INDEX/(NUM_SAMPLES – number of invalid SG_INDEX)
1.4.8 Other Windows

You can select other windows according to requirements. For details, refer to GENEX
Probe User Manual.
1.5 Rules for Storing Test Data
After the window is opened, click . The test data should be stored according
to some rules.
1) Classify the test data according to the test services.
2) Name the folder for the test data for the same service based on test time.
3) Keep the test log every day. Store this log to the same folder as the test data of
the day.
1.6 Playing Back Test Data

The system supports playback the stored log files. Playing back the stored data in a
test helps engineers to observe the network performances and problems carefully,
thus facilitating troubleshooting.
In the Logfile menu, select Open Logfile to open a project. You can control the log
playback with menus or the log playback toolbar.
You can use the following buttons for playback control.

 Click , and select the log file to be opened.

 Click to start playback.
 Click to pause playback. Click to continue playback.
 Click to stop playback.
 Drag the progress bar.
 Click to control the playback direction (backward).
 Click to control the playback speed (1x/2x/4x/8x).

2 Tests in the Network Optimization Phase

This chapter details the tests in the single site verification phase, RF optimization
phase and service optimization phase based on the DT.
2.1 Tests in the Single Site Verification Phase

The single site verification is to check the device functions, laying a sound foundation
for subsequent RF optimization and service optimization. This test focuses on
verifying and solving device function and engineering installation problems. In the
single site verification, network optimization engineers need to cooperate with product
support personnel and engineering installation personnel to ensure high-quality
accomplishments.
The test contents and KPIs for the single site verification should be determined with
the carrier based on actual network operations. Ensuring the progress and
discovering problems effectively is prerequisite to the determination of test contents.
For details about the single site verification flow, preparations and test tasks, refer to
Guide to WCDMA Single Site Verification.
2.1.1 List of Single Site Verification Items
Table 1 Single site verification items
Trigger
No. Action/Process Owner
Condition
Engineering Mandatory in
1 Frequency configuration
personnel all areas
2 SC configuration
personnel all areas
Idle mode 3 LAC/RAC data configuration
personnel all areas
Site nearby CPICH_RSCP > Engineering Mandatory in

4
-xx dBm personnel all areas
Site nearby CPICH_EcIo > Engineering Mandatory in

5
-x dB personnel all areas
Caller and callee dialup of Engineering Mandatory in

6
voice service personnel all areas
Connection Caller and callee dialup of Engineering Mandatory in

7
mode VP service personnel all areas
8 PS service connection
personnel all areas
Confirm that the overall QoS Network

Coverage Mandatory in
9 and coverage reach the optimization
DT all areas
expectations through DT personnel

Trigger
No. Action/Process Owner
Condition
Network
Mandatory in
HSDPA 10 HSDPA access optimization
all areas
personnel
Network
Mandatory in
HSUPA 11 HSUPA access optimization
all areas
personnel
Network
Mandatory in
MBMS 12 MBMS access optimization
all areas
personnel
Network
Specified by
13 Antenna subset check optimization
customer
personnel
Other
Network
Specified by
14 NodeB RTWP check optimization
customer
personnel
2.1.2 Test Methods for Each Check Item

Refer to Guide to GU Single Site Verification.
2.2 Tests in the RF Optimization Phase

The RF optimization is a phase in the network optimization. RF optimization is to
optimize radio RF signals, aiming to optimize signal coverage, control pilot pollution
and DT soft handover percentage, solve unconfigured neighbor cell problems and
ensure normal radio signal distribution in next service parameter optimization. This
section details the test tasks and test data processing in the RF optimization phase.
For the solutions to such problems as coverage and pilot pollution, refer to Guide to
WCDMA RF Optimization.
2.2.1 List of RF Optimization Test Items/Tasks
Table 1 List of RF optimization test items/tasks
Test Item/Task Description Section
Provide data sources to solve

Scanner + 3G ONLY continuous such problems as coverage,
call test without VP loaded pilot pollution and unconfigured
neighbor cell. 2.2.2.1
After the no-loading test, carry
Scanner + 3G ONLY continuous
out the loading test for
call test with VP loaded
optimization.

Test Item/Task Description Section
Collect plane signals at places

where DT does not cover, such
Walking test 2.2.2.2
as small streets that cars
cannot go through and indoors.
Vertical test Collect signals inside buildings. 2.2.2.3
2.2.2 Test Item or Task Description
2.2.2.1 Scanner + 3G ONLY Continuous Call Test without VP Loaded (Return)

Test condition:
 Perform a test in no load or load. Determine the load according to the planned
simulation results. For the load methods, refer to Guide to Operations in
WCDMA Equipment Room.
 The test route for a round-trip test must cover the KPI test route. For details,
refer to Guide to WCDMA RF Optimization.
 At the RNC side, record the downlink transmit code power, uplink SIR, uplink
SIRt and downlink BLER selectively, and perform the single user tracing on the
IMSI. For details, refer to Guide to Operations in WCDMA Equipment Room.
Test flow:
1) Preparations
2) Probe software setting: Hardware setting -> Import BTS information -> System
setting (Scanner 3G ONLY Test + VP 3G ONLY continuous call test)
2.2.2.2 Walking Test (Return)
Test flow: After hardware setting and system setting are finished, perform the
following operations.
The walking test can be divided into the automatic and manual walking tests.
1. The procedure of an automatic walking test is as follows:
1) Open the Indoor Measurement window.

Figure 1 Indoor measurement
2) Select Walking Test > Automatic to import the plane chart.

Figure 1 Selecting an automatic walking test

3) Click on the map to indicate the test route by dots.
Start point
End point
Figure 1 Presetting a test route
4) Click Start to start the test.

5) Travel according to the test route.
6) When reaching a preset position, press the space key to display the obtained
test data on the map.
7) Finish the data collection along the test route. The test is finished.
2. The procedure of a manual walking test is as follows:

1) Open the indoor map window, as shown in Figure 1.
2) Select Walking Test > Manual to import the plane chart, as shown below.

Figure 1 Selecting a manual walking test
4) Click on the map to determine the current location by a dot. 5) Finish the
test data collection. The test is finished.
 Note:
 If you select the automatic walking test, you are required to be familiar with the
tested area environment and know well about the dotted locations.
 If you select the manual walking test, you must stop at the dot location, and click
to dot on the map manually. This method is not so convenient. If necessary,

you can use the carts in tests.
2.2.2.3 Vertical Test (Return)
Test flow: After hardware setting and system setting are finished, perform the
following operations.
1) Open the indoor measurement map, as shown in Figure 1.
2) Select Vertical Test.

Figure 1 Selecting a vertical test

4) During the test, you can press the direction key  or  to switch between floors.
The test results are displayed according to floors.
5) Finish the vertical test data collection. The test is finished.
2.3 Tests and Data Collection in the Service Optimization

Phase
After the RF optimization, it comes the service optimization phase. The service
optimization is to solve network performance problems and make the network indexes
satisfy acceptance requirements mainly by adjusting network parameters and project
parameters. The test route in the service optimization phase complies with the KPI
test route defined in the RF optimization phase.
2.3.1 List of Service Optimization Test Items
Table 1 List of service optimization test items
No. Test Item Condition Purpose
Scanner + VP 3G ONLY Continuous

1 Loaded
Call Test
Scanner + PS128K 3G ONLY

2 Loaded
Continuous Download Test Call drop rate
Scanner + PS384K 3G ONLY decrease
3 Loaded
Continuous Download Test
Scanner + Voice 3G ONLY Continuous

4 Loaded
Dialup Test
5 Scanner + VP 3G ONLY Continuous Loaded Call completion

Dialup Test rate optimization

No. Test Item Condition Purpose

6 Loaded
Continuous PDP activation Test

7 Loaded
Continuous PDP activation Test
Call drop rate

R99 or
Scanner + HSDPA 3G ONLY decrease,
8 OCNS
Continuous Download Test throughput
loaded
optimization
R99 or
Scanner + HSDPA 3G ONLY Call completion
9 OCNS
Discontinuous Download Test rate optimization
loaded
Call drop
R99 load or
Scanner + HSUPA 3G ONLY optimization,
10 OCNS load
continuous uploading test throughput
is added
optimization
R99 load or
Scanner + HSUPA 3G ONLY Call completion
11 OCNS load
discontinuous uploading test rate optimization
is added
R99 load or
Scanner + MBMS broadcast service
12 OCNS load Dropping rate
continuous test (IDLE)
is added
R99 load or MBMS-on-demand

Scanner + MBMS broadcast service
13 OCNS load success ratio and
call test (IDLE)
is added delay

Note:
 To optimize a service, carry out the continuous call test to solve the call drop
problems, and then the call by call test to solve access problems. For details, refer
to 2.3.3.
 Choose the proper test items listed in Table 1 according to actual project
requirements.
 Before testing, confirm that:
The WCDMA system runs normally, and the APN server runs normally.
Simulate the load on the uplink, and load the OCNS on the downlink (the load
percentage should be determined according to the simulation outputs).
Test the PS subscription rate: UL 64 K/DL 128 K. (At present, the maximum uplink
and downlink subscription rate is 384 Kbps. You need to use the extra initialization
commands of Qualcomm handset to request 64 K uplink service and 128 K
downlink service. For details, refer to 6.1)
 The RNC background records the uplink service throughput in PS service tests.
 Loading is not required if the network has traffics.
 In the HSDPA optimization test, test the throughput that can be provided by the
HSDPA at a planned load of the R99 in the hybrid networking. If OCNS load is
used, be sure to reserve the last code with the SF being 8 (namely C ch,8,7) for
OCNS load, and then activate the HSDPA feature and OCNS load. Otherwise,
loading OCNS may fail.
2.3.2 Collection of Other Data
2.3.2.1 Collecting Call Tracing Data

The DT is to record the data at the UE side only. To realize problem analysis, you also
need to collect the call tracing data at the network device side, such as user signaling
information tracing, cell signaling message tracing, standard interface signaling
message tracing, testability log, signaling message tracing at the transmission
network layer, IOS tracing, signaling tester tracing, and real-time state monitor.
If all call tracing data collection tasks are enabled at the network device side, a great
amount of data is reported, which increases signaling transmission and system
processing overheads and affects the CPU usage. Therefore, only the user signaling
message tracing, uplink channel BLER, downlink transmit code power and uplink SIRt
are enabled in a DT. Enabling of other items depends on the problem analysis
requirements.
In an HSDPA test, trace the following items:
 carrier Tx power and non-HSDPA carrier Tx power, for checking the R99 load
and HSDPA load
Cell performance measurement: downlink carrier Tx power. Turn on the HSDPA
measurement switch with the following command: MOD CELLALGOSWITCH:
CellId=XXXX, NBMSwitch=HSDPA_MEAS-1;
Note: After the HSDPA measurement switch is enabled, guarantee the enough
NCP bandwidth.
 DL Throughput & Bandwidth, and DL traffic
Connection performance measurement: DL throughput and bandwidth, and DL
traffic
 HSDPA throughput
Cell performance measurement: the bit rate provided by the HS-DSCH. The
word indicates the total throughput of the cell HSDPA. However, the actual

statistics result is different from this meaning. HS-DSCH is an accumulation of

the HSDPA rates of different service types and at different rates. If there are
users of different service types and different requested rates, this value does not
measure the HSDPA throughput of the cell.
 Single user signaling tracing
 Focusing on uplink impacts, trace the UL throughput and bandwidth, UL traffic
and UL channel power control (UL BLER and whether UL SIR is close).
Connection performance measurement: UL throughput and bandwidth, UL traffic,
UL channel BLER, UL SIR and UL SIRtarget
For HSUPA tests, besides the power, signaling, and throughput, the uplink load
(namely, the RTWP) needs to be traced.
To shoot troubles such as data transfer interruption, use the Probe or other tools to
discover problems first, and then perform single user tracing through the CDT and
NodeB debugging console. The problems can be located.
 The IOS is similar to common single user tracing. The difference is that the IOS
supports tracing multiple users without having to input the IMSI. It helps to locate
common user problems in existing networks. For the DT, single user tracing or
CDT is applicable.
 The CDT can be used to trace layer 2 signaling, set up and delete AAL2 and lub
flow control information. In addition, if transparent transmission function is
enabled, the CDT can be also used to trace the number of the received layer 2
packets and ACK information.
 The NodeB debugging console can be used for single user tracing.
For the data collection methods, refer to Guide to Operations in Equipment Room for
WCDMA Network Planning and Optimization.
2.3.2.2 Traffic Statistics Data Collection

You can obtain the test UE information in the KPI test route by means of DT data
collection + call tracing data collection. This can be completed in one or several
milliseconds, but the radio performance problems of the cells or networks cannot be
fully reflected.
The RAN traffic statistics comes from the RNC performance measurement data,
focusing on radio performances. The RNC performance measurement data refer to
the data of the overall RNC performance measurement, lu interface measurement, lur
interface measurement, cell measurement, GTPU measurement, SCCP
measurement, SAAL measurement, MTP3B link/linkset/DSP measurement, QAAL2
measurement, CPU measurement, DSP measurement and undefined neighbor cell
measurement. For network optimization, focus on the data of the RNC overall
performance measurement, lu interface measurement, cell measurement and
undefined neighbor cell measurement.
From the aspect of performance indexes, the RAN traffic statistics fall into the
following categories:
 Access
 Call drop
 Handover
 Traffic
Related traffic statistics items of the HSDPA:
For the RNC 1.5B065 to RNC 1.6B064, the HSDPA traffic statistics are centered at
the cell level, HSDPA.Cell. The method for collecting traffic statistics data is the same

as that of the R99. But note that the full-index traffic statistics file is required for
Nastar data analysis. This file is saved in the \BAM\FTP\NastarResult directory on
the BAM server by default.
For collection method details, refer to Guide to Operations in Equipment Room for
2.3.2.3 Configuration data collection

Network planning and optimization personnel often need to know the actual running
parameters in the RNC, to check whether the RNC parameters are consistent with
that defined for network planning and optimization and to analyze and solve
problems. Therefore, the data configuration file, namely CFGMML.txt, can be
exported from the RNC for these purposes.
For collection method details, refer to Guide to Operations in Equipment Room for
2.3.3 Brief Introduction to Service Optimization Process

In the RF optimization phase, mainly the call drops due to network coverage and
unconfigured neighbor cell are eliminated. The unconfigured neighbor cells are quite
obvious when you load the VP service or PS 384 K services. Therefore, loading the
VP service is recommended for the first DT, focusing on solving the unconfigured
neighbor cell problems. In the service optimization phase, tests focus on network
performance problems, such as call drop and low call completion rate.
2.3.3.1 Call drop rate decrease

 VP call drop: After the unconfigured neighbor cell problem is solved, most call
drops can be eliminated, and only several calls drop when you drive along the
KPI route once. In this case, analyze the signal changes at the call drop points,
provide related solutions, and test along the corresponding routes for these call
drop points to find out whether call drop happens again. Arrange at least three
tests at each call drop point to exclude the occasional call drops.
 Call drop in 128 K soft handover: The call drops easily recur when 128 K
services are used at the points where calls drop at some probability. When 128 K
services are used, you can start the test when 50% of the service is loaded,
which can reduce the call drop points.
The pilot experiences show that call drops are often centered in some areas. You are
suggested to measure the distribution of the call drop points by area for later antenna
adjustment.
2.3.3.2 Call completion rate optimization

After the call drop rate and coverage optimization in combination with antenna
adjustment, there is no problem on the coverage of a cluster area. In this case, you
need to test the call completion rate further (covering the RRC setup success rate
and paging success rate). The optimization method is to adjust project parameters,
cell selection and reselection parameters or power distribution rate of common
channels.
Meanwhile, try to obtain more data during a run. To realize this, release the call
immediately and set up a new connection once a call is set up. You also need to
record the calling and called signaling flows for call failure cause analysis.
During the optimization, solve call failure problems first, and then the problem of
sending paging requests or RRC requests several times in the call setup process in
the problem areas.

After the first-round optimization of the voice call completion rate, test the VP call
completion rate and activation success rate of the PS 384 K service.
2.3.3.3 Inter-system Handover Optimization

Huawei 3G/2G handover policy is to provide 3G services in 3G and 2G signal
coverage, and try to avoid residing at or handover to 2G network; realize reselection
or handover to the 2G network without any disconnection or call drop in 2G signal
coverage..
The 3G/2G handover focus on the handover and reselection in 2G indoor coverage
only (such as in office buildings, hotels, cells and 3G area edges), the reselection and
handover quality of the 2G indoor distribution system and 3G cell, and the handover
and reselection in 2G coverage areas. In addition, the default parameters are used to
observe whether the MS can reside at 3G networks stably on the test route.
Test item: Automatic voice continuous call test
PS FTP download test
2.3.3.4 HSPA Service Optimization

The coverage is properly adjusted and the unconfigured neighbor cell problem is
nearly eliminated after optimizations in the RF, VP call drop ratio and call completion
rate. Now, you can start the HSDPA service optimization.
The HSPA service optimization is mainly reflected in the HSPA service throughput,
call drop rate, handover and call completion rate. Test item: Scanner + HSDPA 3G
ONLY continuous download test, Scanner + HSDPA 3G ONLY download and dialup
test, Scanner + HSDPA 3G ONLY continuous PDP activation test, Scanner + HSUPA
3G ONLY continuous upload test, Scanner + HSUPA 3G ONLY upload and dialup
test, Scanner + HSUPA 3G ONLY continuous PDP activation test.
For optimization method details, refer to Guide to WCDMA Access Optimization,
Guide to WCDMA Handover and Call Drop Rate Optimization and Guide to WCDMA
PS Service Optimization.
2.3.3.5 MBMS service optimization

After the coverage is well adjusted and the problem about absent neighboring cells is
solved through the RF optimization and the optimization in call drop rate and call
completion rate of the VP, optimize the MBMS service.
The optimization tasks of the MBMS service should ensure that the MBMS service is
smooth, that no mosaic or long pause exists, and that the MBMS-on-demand success
ratio, MBMS dropping rate, MBMS-on-demand delay, and BLER all meet the
requirements. The test items include Scanner + MBMS broadcast service continuous
test (IDLE) and Scanner + MBMS broadcast service call test (IDLE)
2.3.3.6 KPI Acceptance Optimization and Pretest in the Whole Network

Carry out tests and optimizations in time according to standard test case
requirements. Pretest the KPI test route and prepare for the network KPI acceptance
test.
2.4 Test Problem Analysis

This section collects some test related answers and cases from the Answers to
WCDMA Technical Support Questions in Network Planning and WCDMA Network
Planning and Optimization Cases. This section is for your reference.

2.4.1 List of Cases
2.4.1.1 List of R99 Cases

Table 1 List of test cases
Source Title Section
Cases How to obtain the BLER value correctly? 2.4.2.1
Wrong conclusions are drawn when an optimized

Cases 2.4.2.2
PC is used for a PS test.
The SC information at the measurement point is not

Cases 2.4.2.3
displayed in the Assistant tool.
The wrong compression mode results in inter-

Cases 2.4.2.4
frequency hard handover failure.
The display on the Statistic tab in the Information

Cases 2.4.2.5
window of the Probe is abnormal.
The handset setting problem makes the PS rate fail

Cases 2.4.2.6
to reach the subscribed rate.
The Qualcomm handset fails to support 384 K

Answers 2.4.2.7
service.
How to distinguish and configure a Huawei U626

Answers 2.4.2.8
handset.
Answers The maximum Tx power of the mobile terminal 2.4.2.9
Comparison between the EcIo of the UE and the

Answers 2.4.2.10
scanner
Answers Can Huawei UE support PS384 + VP? 2.4.2.11
Differences in the tests with Huawei handset and

Answers 2.4.2.12
Qualcomm handset
Why the signal quality varies greatly before and after

Answers 2.4.2.13
the test?
Answers Some questions during the test 2.4.2.14
Cases The Probe cannot detect the ports of Huawei U626. 2.4.2.15
The PDP cannot be activated as the handset
Cases 2.4.2.16
initialization commands are set on the computer.
2.4.1.2 List of HSDPA Cases
Source Title Section
How to handle when the HSDPA cell loading test

Cases 2.4.2.17
fails
No CQI data is available in the air interface data

Cases 2.4.2.18
collection test of the HSDPA.

2.4.2 Detailed Answers
2.4.2.1 How to obtain the BLER value correctly (Return)

 Phenomenon:
Whether the measured BLER of the transmission channel is close to the target value
is used to measure the performance of the outer loop power control. Therefore,
measuring the BLER with a proper method is very important.
The average value of the BLERs measured in the whole test is used as the statistics
value of the BLER. However, this result is not always correct in any case as the BLER
of each transmission channel equals the block errors at the measurement interval
divided by the total blocks each time. If the total number of blocks is 0, the BLER is
still reported as 0. Therefore, if any transmission channel has no block and its BLER
is used in the average BLER calculation, the result is smaller than the actual one.
However, a channel without any block is a common case for both real-time and non
real-time services, and for both signaling transmission channels and service
transmission channels.
The following figure shows the measured BLERs of the uplink transmission channel
during the PS 384K test.
Figure 1 BLERs of the uplink transmission channel measured by the RNC
From the figure above, you can easily find the differences in the results. The correct
result should be 0.0686 other than 0.0416.

Figure 2 BLER analysis result
 Handling process:
Of course, you can filter the BLERs of the transmission channels without any block
before calculating the average value. However, due to the large amount of the
collected BLER data, the method shown in Figure is recommended. That is, divide
the accumulated value of ErrBlockNum by that of TotalBlockNum.
 Suggestion and summary:
A great amount of test data is to be dealt with in the network optimization. You can
make correct judgments only with correct statistics results.
2.4.2.2 Wrong conclusions are drawn when an optimized PC is used for the PS test.
(Return)
 Phenomenon:
In locating a PS rate problem, a laptop optimized in the download feature is used,
achieving the same download rates with one and multiple threads. In addition, the
single-thread download speed is much higher than the combination of a computer
and a common handset. This phenomenon misleads to a wrong troubleshooting.
 Cause analysis:
1) Use the Moto A835 test handset on a PC to test the PS service. A stable
download rate of 384 Kbps with a single thread is achieved. Then, use a
common Moto A835 on another PC. The single-thread download rate is
about 200 Kbps only.
2) Moto A835 test handset and common handset use different drivers, and the
driver setup files are unavailable on both PCs. Therefore, without any
crossing tests, the conclusion is drawn that the test handset has higher
performance and download rate, while the common handset has version
problems limiting the download rate. Such a conclusion nearly leads the
problem locating to a wrong direction. In fact, the problem lies in Moto
common handset other than the PS download rate. You need to contact
Moto vendor to update the software version of the handset.
3) However, the PC connecting with Moto test handset was actually optimized
a few days ago, two keys were added in the registry and the TCP receiver
window of the computer was modified (refer to appendix). So, multiple
threads other than a single thread are used to download a file when click
Save As is clicked in the IE. In the multi-thread download mode, the whole
download rate of 384 Kbps can be ensured so long as two threads realize a
download rate of 200 Kbps. Cancel the optimization settings. The download
rate of the PC is similar to that of the other PC. Therefore, the optimization
setting cover up the problem causes.
4) Without any other handset model used for test or crossing tests performed
on the PCs due to limitations, a wrong conclusion is drawn that PC settings
are similar, and the differences in download rates are caused by handsets.
After the optimization setting is approved as the reason of the high download rate,
give up the original conclusion and continue troubleshooting from other aspects.


1) Try to carry out crossing tests so far as possible to exclude some problems.
Do not draw a conclusion simply from the phenomenon.
2) Do not use an optimized PC for PS problem locating.
3) The PCs can be optimized effectively by modifying the registry and TCP
receiver window.
 Supplementary Instructions:
To support the multi-thread download in IE 6.0 (or a later version):
Open the registry and navigate to
HKEY_CURRENT_USET\Software\Microsoft\Windows\CurrentVersion\Internet
Settings.
Add two keys in the right window.
 Add a Dword named MaxConnectionsPerServer, and change its value to
a numeral between 5 and 8.
 Add a Dword named MaxConnectionsPer1_0Server, and set a value for it
(suggested value: 2~5).
After that, IE 6.0 adopts multiple threads to download and make full use of the
network bandwidth.
Use the tool for modifying the TCP receive window of the PC. This tool can be used
on Windows 98, 2000 and XP systems. After running the file, there is no value in the
Tcp Receive Window field. The system uses the default value. You can set it to
65535 at most. After saving, restart your computer to validate the changes. In this
case, the reason is that the delay jitters arising from BLER are suppressed after the
window is bigger.
2.4.2.3 The SC information at the measurement point is not displayed in the Assistant
tool. (Return)
 Phenomenon:
When you use the Assistant tool for DT data analysis, the data bar for the main SCs
of the active set and monitor set at each DT point cannot be displayed if you drag the
window. Select View > Properties, and check the UE and SCANNER. The problem
still exists. Then, uninstall the Assistant tool and then reinstall it. But the problem still
exists.
 Cause analysis:
The data bar can be displayed or hidden normally after you open or close a window
by selecting View > Properties. In this case, the data bar window may have been
hidden by mistake during the data analysis.
Right-click in the task bar on the lower part, and select Properties. In the popup
window, check or uncheck the automatic hiding option. Then, check the Assistant
window, and you can find the data bar is displayed.
Few can really solve such a simple problem due to its seldom occurrence, inclination
to neglect and relevance to Windows operation. Such a problem affects DT data
analysis and is still troublesome.

2.4.2.4 The wrong compression mode setting results in inter-frequency hard handover
failure. (Return)
 Phenomenon:
The WCDMA pilot office has two RNCs, each having two NODEBs. The NODEB1 of
RNC1 is the indoor coverage site of Mobile center building with O2 configuration. The
cell SCs are 96 and 88 (the cell with the SC 96 is an inter-frequency cell for other
cells under NODEB). In the CQT, dial a 64 K VP call after the mobile center building
occupies the cell with the SC 96. However, inter-frequency handover fails even you
walk a long distance from the building. But you can make 12.2 K voice calls normally.
 Cause analysis:
If the inter-frequency hard handover of 12.2 K voice calls is normal, the neighbor cell
configuration is correct, and the inter-frequency hard handover switch at the RNC
side is enabled. The measurement control messages meet protocol requirements and
the contained information is compliant. As the compression mode should be enabled
to measure frequencies for inter-frequency hard handover, the cause may be the
handset does not support the inter-frequency measurement.
Check the connection-oriented algorithm switch and the handover algorithm switch.
The compression mode supports the dot switch. If this switch is enabled, disable it,
and then test again. You can find the handover is normal.
Therefore, the cause is that the compression mode can be enabled for the inter-
frequency measurement with two methods: spread factor halving and dotting. The
current test handsets support the spread factor halving method only. Therefore, if the
dotting mode switch is enabled but the handset does not support it, the inter-
frequency measurement cannot be performed, and inter-frequency hard handover
thus cannot be realized. This switch does not affect 12.2 K voice services that use the
spread factor halving mode for measurement, so voice calls are normal.
 Suggestion and summary: None
2.4.2.5 The display on the Statistic tab in the Information window of the Probe is
abnormal. (Return)
 Phenomenon:
The dongle is not required when you use the Probe 1.2 (Probe 1.2-20050714-
V100R001C02B020) for DT data playback. After the playback is finished, open the
Information window to check the statistics information in the whole test. However, no
related statistics information is displayed on the Statistic tab in the Information
window. But the information on the Log File tab is complete.
 Cause analysis:
This problem may be caused by:
1) The software design problem. The statistics information on the Statistic tab
is valid only during the playback, so it is no longer displayed after the
playback is finished.
2) A software bug. The statistics information on the Statistic tab can be
displayed only when the Information window is opened before the playback
is finished.
To verify the possible causes, proceed as follows:
1) Open the Information window before playback. In this case, the statistics
information on the Statistic tab is complete and updated with the playback.

2) Open the Information window before playback. Close the window during
the playback. Then, open the window again before the playback is finished.
In this case, no information is displayed on the Statistic tab.
3) Open the Information window before playback. So long as the window is
reopened before the playback is finished no matter it is closed in the
halfway, all statistics information can be displayed without any interruption.
4) If you locate the playback time by dragging the progress bar or entering
time in the time input box, the statistics information on the Statistic tab is
disorder. That is to say, the statistics information on this tab reflects the
events happened during the playback other than the events contained in the
test file. It is related to the playback operation.
As the above tests show, to display the statistics information on the Statistic tab
during the playback, you have to open the Information window before the playback is
finished. If you open the Information window after playback, no information is
displayed on the Statistic tab. This problem does not occur to the Log File tab.
In addition, if you change the order during the playback, the statistics information on
the Statistic tab may be different from the actual situations as the events happened
during the playback are measured here.
Note these items when you use the Probe 1.2 for test data playback.
This problem may be caused by software designed and not indicated in the user
manual. Therefore, some unexpected problems may occur during the playback.
Note: The corresponding GENEX Shared setup file for Probe 1.2 is the Genex
Shared (Jul 04,2005).
2.4.2.6 The handset setting makes the PS rate fail to reach the subscribed rate. (Return)
 Phenomenon:
When MOTO A835 and the SIM card subscribed to 384 Kbps service are used to
download data from Internet, the actual downlink rate is about 100 to 130 Kbps even
in good signal coverage.
 Cause analysis:
1) The DCCC algorithm switch of the network is disabled, and the soft
handover rate is 384 Kbps.
2) Insert the same SIM card to other handset. Carry out the same test at the
same location. The rate can reach 384 Kbps.
3) Therefore, the problem cause is addressed to the handset setting. After
check, the cause is that the handset rate is set to 128 Kbps by use of
commands or mis-operations.
Modify the handset rate manually.
1) Connect the handset with a computer. The port number used by the handset
can be displayed in the device manager or MODEM window on the
computer, or in the property or MODEM window of the handset.
2) Set up a connection *99# with the HyperTerminal of the Windows system.
Then, input the corresponding command (AT+CGEQREQ=1, 3, 64, 384) to
change the handset rate to 384. Carry out the test again and you can find
the problem is solved. The details are listed below (refer to protocol 27.007):
in "START->PROGRAM->ACCESSORY->COMMUNICATION->HYPER STREAM", you
can use some command to change the data rate.
COMMAND: AT+CGEQREQ=<CID>, <TRAFFIC CLASS>, <Maximum bit rate UL>,
<Maximum bit rate DL>
<CID>: (PDP Context Identifier) a numeric parameter which
specifies a particular PDP context definition. The parameter is
local to the TE-MT interface and is used in other PDP context-

related commands. The range of permitted values (minimum value =

1) is returned by the test form of the command.
<TRAFFIC CLASS>: a numeric parameter that indicates the type of
application for which the UMTS bearer service is optimized.
0 - conversational,
1 - streaming,
2 - interactive,
3 - background,
4 - subscribed value,
Other values are reserved.
<Maximum bitrate UL>: a numeric parameter that indicates the
maximum number of kbits/s delivered to UMTS (up-link traffic) at a
SAP. As an example a bitrate of 32kbit/s would be specified as
'32' (e.g. AT+CGEQREQ=......,32, ......).
<Maximum bitrate DL>: a numeric parameter that indicates the
maximum number of kbits/s delivered by UMTS (down-link traffic) at
a SAP. As an example a bitrate of 32kbit/s would be specified as
'32' (e.g. AT+CGEQREQ=......,32, ......). If the parameter is set
to '0' the subscribed value will be requested.
E.g. if we need to set Maximum bitrate DL as 384kbps, then the
command is: AT+CGEQREQ=1,3,64,384.
Note: This command can be also used to test different rate levels of the 384 Kbps
SIM card.
2.4.2.7 The Qualcomm handset does not reach 384 K service rate. (Return)
 Description:
When Qualcomm handset is used to test the 384 Kbps service, the data service rate
is always 64 Kbps though the subscription data of the SIM card is changed to DL 384
Kbps and the SIM card used in other handsets can realize 384 Kbps. Therefore, the
Qualcomm handset setting should be the cause of this problem. Trace the user.
When the SIM card is used in the Qualcomm handset, the request of max bit rate
down: 0x40 (64) is sent. But when the SIM card is used in other handset, the request
of max bit rate down: 0x0 is sent.
Question: How to set the Qualcomm handset to realize 384 Kbps services?
 Answer:
The Qualcomm handset can control request rates with the AT command through the
HyperTerminal. Run the following command:
AT+CGEQREQ=1, 3, 64, 384 (1 stands for the contxt ID, corresponding to the HLR
subscription; 3 for interactive service; 64 for uplink rate; 384 for downlink rate)
Supplementary instructions: HyperTerminal setting:
To set the UE hardware, proceed as follows (take the Qualcomm 6200 as an
example):
1) Connect the USB connector of a data line to the USB port of a PC.
2) Connect the other connector of the data line to the test handset.
3) Start the test handset.
4) Set the transmission baud rate of the test handset.
Select Menu > 5 Setting > 7 Extras > 1 SIO Config > 1 Port Map > 2 DS
BAUD, and select 230400 (USB)/115200 (serial) as the rate.
5) Set the connection ports of the test handset.
Connect to the USB interface: Menu > 5 Setting > 7 Extras > 1 SIO Config > 1
Diag > 1 Diag > USB DIAG
Connect to the serial interface: Menu > 5 Setting > 7 Extras > 1 SIO Config > 1
Diag > 1 Diag > UART

2.4.2.8 How to distinguish and configure Huawei U626 handset? (Return)

 Description:
How can I distinguish Huawei U626 test handset (engineering handset)
 Answer:
 Brief introduction to the engineering handset
Huawei U626 engineering handset (hereinafter referred to as U626EM) is
an engineering handset developed by Huawei. It can realize large-scale
network data collection, network optimizations and independent network
tests. The U626EM can be used independently or together with Huawei
GENEX Probe. In addition, the U626EM has the complete functions of U626
commercial handset.
 How to distinguish an engineering handset?
For an engineering handset, Huawei GENEX logo is displayed at the
startup. This logo distinguishes an engineering handset from the common
U626 handset. If the logo is not displayed, the handset cannot be used for
some purposes. Or, press * + # + mode key (under the Ok key). If the test
mode window is displayed after you release the keys, the handset is an
engineering handset.
 How to set an engineering handset?
Mode 1: Connect to GENEX Probe.
a) About the Probe software
Huawei GENEX Probe is a solution mainly used in network optimization and
planning. Huawei GENEX Probe and Huawei U626EM comprise the radio
network test solution of Huawei.
Connect the U626EM to a PC and run the Probe. Then, you can control the
handset to test network services, collect the radio parameters and data
reported (such as RF information and signaling information) through the
Probe software. The information can be displayed in real time or recorded
into a file for further analysis with the network data. For details about how to
use the Probe software for test, refer to Probe Software User Manual.
b) Handset setting
By default, the output port of the U626EM is the USB port and can meet
normal use requirements. You can also set the port manually. After startup,
press * + # + address book key (on the left side of the Ok key). After you
release the keys, the engineering mode setup window appears. Press #,
Up, or Down key to select the last option Other. Select DIAG Port Setup,
and select USB port. The setting is finished.
If the port setting is correct, you can collect the output data of the U626EM
with the Probe software.
If the handset cannot be detected with the Probe, check whether:
The handset and PC are connected normally; the handset port is displayed
in the device manager; the correct baud rate 230400 is used; the handset
model is correctly selected; the port number is correctly set (you can check
the port number of the handset and the MODEM through the device
manager).
c) Probe setting
Add the hardware. Select the handset type to U626, set the baud rate to
230400, and select the correct port number (for details, refer to related
information of the device manager of Windows system). The Windows 98

system is not supported. You just need to carry out the hardware detection.
For details, refer to Hardware Connection in Probe 1.2 User Manual.
Mode 2: Use the U626EM independently.
The U626EM has the function of displaying network parameters and
indexes. You can use the U626EM independently, observe the network KPIs
on the screen, and carry out tests easily.
a) Use method
Enable the independent test function of the U626EM. After startup, press * +
# + mode key (under the Ok key) in the main window. After you release the
keys, the test mode window is displayed. You can check parameters and
KPIs by pressing Up or Down.
b) The KPIs provided by the U626EM are applicable to the WCDMA network
only.
Power information:
Rx, Tx, SIR, DL TPC and UL TPC. This window displays the accumulated
values of the Rx, Tx, SIR, DL TPC and UL TPC within the statistics period.
Network information:
This window displays network parameters (frequency points, inclusive),
such as MCC, MNC, LAC, RAC, Cell ID, URA ID, UL UARFCN and DL
UARFCN.
Active set/monitor set/detected set information:
This window displays the contents of the active set, monitor set and
detected set (such as the frequency point, SC, Ec/Io and Ec) of the UE in an
idle serving cell (viewed in the active set information).
Transmission channel information:
This window displays the number and BLER of each transmission channel
when the UE is in the connection mode.
RLC layer throughput information:
This window displays the uplink and downlink RLC throughput, uplink
resend rate and downlink BER in the data service implementation mode,
helping you to understand data service performances.
IMSI information:
This window displays the IMSI of the UE.
c) Menu setting
In the engineering mode window, press Menu on the lower left corner.
Three options are available.
Set refresh period:
The default refresh interval is 500 ms. You can set the value freely. This
option is to adjust the data refresh rate.
VP auto answer:
Enable or disable VP auto answer. This option is to answer a call
automatically without interventions when the phone is unfolded in the
automatic VP call tests with the Probe software.
Value:
Average or random. It refers to the parameter value display mode.
You can press * + # + mode key (under the Ok key) to switch between the
test mode window and normal window.

2.4.2.9 The maximum Tx power of the mobile terminal (Return)

 Description:
1) What are the rules for setting the maximum Tx power of the mobile
terminal? How to set the maximum Tx power of the UE TCH and the
downlink TCH?
2) The Tx power of the Qualcomm TM6250-21 exceeds the maximum Tx
power configured in the RNC, 24 dBm. How to set the maximum uplink Tx
power of on the handset?
 Answers:
1) The UEs with four power classes are stipulated in section 6.2.1 of TS
25.101 v3.7.0 (2001-06).
Power Class Nominal maximum output power Tolerance
1 +33 dBm +1/-3 dB
2 +27 dBm +1/-3 dB
3 +24 dBm +1/-3 dB
4 +21 dBm 2 dB
Considering that not all handsets support a Tx power of 24 dBm, the

maximum Tx power of the UE is often set to 21 dBm in pilot and commercial
deployment. However, in domestic pre-planning, the maximum Tx power of
the UE is set to 21 dBm for CS12.2 K voice services, and 24 dBm for CS64
VP and PS services. No matter which maximum Tx power of the UE is
adopted, the maximum downlink Tx power of the TCH is required to balance
the uplink and downlink. The suggested maximum downlink Tx powers for
different services are given according outside plant tests. Where, the
downlink Tx power for 384 K service cannot exceed 37 dBm.
Note: The commercial handsets using Qualcomm chips (such as
Qualcomm, Huawei and Samsung handsets) and Sony Eriksson handsets
support a maximum Tx power of 24 dBm. Moto and Nokia handsets support
a maximum Tx power of 21 dBm.
2) The maximum uplink Tx power setting of the RNC is not applicable to
Qualcomm handsets.
In this case, you need to modify the setting with the QPST tool (often
contained in Qualcomm program CD).
(The following example shows how to set the maximum power of
Qualcomm handset to 18 dBm.)
>Please set it according following procedures:
>1) OPEN QXDM and connect with FFA
>2) One icon “ view” in the tool bar
>3) Select “NV items”
>4) Select “WCDMA” in the right column
>5) Find two item “WCDMA_MAX_TX_POWER” and
“WCDMA_TX_LIM_VS_TEMP”
> 6) When want to change the NV value, Click the key “Off line”
in the TOP, which make FFA to enter write operation state
> 7) write the value:
> for 18dbm:
> set NV_WCDMA_MAX_TX_POWER_I to 18
> set NV_WCDMA_TX_LIM_VS_TEMP_I[8] to 0x84 (All 8 value set
to 0X84 )
>8) After set the value, power off FFA.

Note: For other handsets using Qualcomm chip (such as Huawei handset),
you can modify the maximum Tx power in the same way.
2.4.2.10 Comparison between the EcIo of the UE and the scanner (Return)
 Description:
The attachment below shows the comparison between the DT data of the scanner
and the UE. The test data is the outdoor test data as the antenna of the scanner is
placed on the top of the vehicle and that of the UE is placed in the vehicle.
Considering the car body loss, the RSCP of the UE is about 8 dB less than the
scanner. But the car body loss for useful signals and interference signals should be
the same. Then, why is the EcIo of the UE also 2 dB less than the scanner?
SCANNER VS UE.xls
 Answers:
 The Io involves both white Gaussian noises and interference signals. There
exists a car body penetration loss for both useful signals and interference
signals inside the vehicle. But white Gaussian noise inside and outside the
vehicle is not changed. So the EcIo inside the vehicle is weaker than that
outside the vehicle.
 Examples
Suppose that the useful signal power outside the vehicle is -90 dBm, the
interference signal power outside the vehicle is -85 dBm, the floor noise is
-100 dBm, and the car body loss is 8 dB. Then,
Ec/Io outside the vehicle = (-90 dBm) / ((-85 dBm) + (-100 dBm)) = (-90
dBm) / (-84.9 dBm) = -5.1 dB
Ec/Io inside the vehicle = (-90 dBm – 8 dB) / ((-85 dBm – 8 dB) + (-100
dBm)) = (-98 dBm) / ((-93 dBm) + (-100 dBm)) = (-98 dBm) / (-92.2 dBm) =
-5.8 dB
That is, when the floor noise is unchanged, the Ec/Io inside the vehicle is a
little smaller than outside.
Actually, the Ec/Io is also related with the processing capability of the
handset. For example, when the RAKE receive window size of the handset
is restricted, some useful multipath may be discarded. Whereas, the
scanner supports a higher precision, so it can receive more useful signals
than the handset. Thus, the Ec/Io inside the vehicle is smaller than that
outside, and the EcIo of the UE is often 2 dB smaller than the scanner.
2.4.2.11 Is Huawei UE support PS384 + VP? (Return)
 Description:
The RNC will be upgraded to V100R005C01B065 at the end of December. Will this
new version support PS384 + VP? If Huawei product supports PS384 + VP, which
KPI will be affected? And How is it affected?
 Answers:
The V100R002C03B092PS0 can
support VP + PS384k. If the UE capability is not enough, the service rate decreases
to the negotiated rate. The RNC will be upgraded to V100R005C01B065 at the end of
December. This version will support VP + PS384k. If the UE capability is not enough,
the service rate will decrease to the negotiated rate. If VP + PS384k support is not

needed, the maximum rate threshold of the combined services can be modified to
PS64k to obtain better KPIs.
At present, only few commercial handsets support VP + PS384k, such as Qualcomm
TM6250 and Nokia 6630 (note the software versions of the handsets, which are
CFMNA4262/CGMQG6030 for Qualcomm TM6250, and wk 03_d02 for Nokia 6630).
V100R002C03B092PS0:
KPIs are unnecessarily affected when the RNC supports PS384 + VP. Whether to use
such services is the key point. Due to the high downlink power consumption, the
concurrent use of PS384 and VP services impacts the network load, and deteriorates
the network performances particularly at the network edge. Moreover, only some
handsets support PS384 + VP, and we do not know the performances in such cases.
All these factors may degrade network KPIs, such as the call drop rate, call setup
success rate and handover success rate.
2.4.2.12 Differences in the results of tests where Huawei handset and Qualcomm
handset are used (Return)
 Description:
When the Probe is used, the results of the tests using Huawei handset and
Qualcomm handset are quite different, as shown below (UE1 is a Huawei handset,
and UE2 is a Qualcomm handset).
Figure 1 Comparing test results (using Huawei handset and Qualcomm handset)
 Answers:
As my test shows, the test results are nearly identical. The following are some
possible causes.
1) Related to UE position. The following figure shows my test results. The UE2
is a Huawei handset, and UE1 is a Qualcomm handset. They are placed in
parallel. When UE2 is placed on the left while UE1 on the right, the EcIo of

UE2 is about 3 dB higher than UE1 (0-1000 sector). Exchange their

positions, the EcIo of UE1 is about 3 dB higher than UE2 (1000-2000
sector). The results are still the same in next two tests. From these tests,
you can know that the EcIo of two handsets is greatly different due to fast
fading though they are placed in the same position.
Figure 2 Comparing test results (using Huawei UE and Qualcomm UE) 2
2) Related to the performance of a single handset. Place two handsets in

parallel and keep a call between them. Record the EcIo and test for two
seconds. Exchange the positions of the handsets. Record the EcIo and test
for two minutes. Calculate the average value of the EcIo. If the EcIo of a
handset is obviously higher than the other one, one handset may be
abnormal. In this case, replace the handset, or at least, do not use it in
acceptance tests.
2.4.2.13 Why the signal quality varies greatly before and after the test? (Return)
 Description:
The figure below shows part of the download rates in the data service DT for XX
project. The download rate here ranges from 8 Kbps to 64 Kbps. We often meet a
strange case: signals are strong and the Ec/Io is good before and after a test point,
but the Ec/Io degrades abruptly at the test point, and only the monitor set and
detected set are available. Such a case occurs several times in this test. As shown in
the figure below, the signals are strong at test points 1 and 2, but there is no active
set in test point 2. What is the matter?
The tools used in this test are HP laptop, GPS and Huawei U626. The DT software is
the Probe.

Test point 1 (the previous test point)
Figure 1 Test point 1
Test point 2 (the middle test point)

Test point 3 (the next test point)
 Answers:
1) Use the chart or table tool in the Assistant to check whether the active set
data is available at that moment. If yes, the UE Pilot Measurement display is
abnormal. You can use the chart display mode instead.
2) If no active set data is found with the chart, play back in the Probe to check
whether the handset or scanner fails to report data in time or completely
(due to the too large data amount). This problem is common. If the problem
affects the test greatly, replace the handset and try again. Do not measure
the unnecessary data such as finger information. Otherwise, the data is
easily lost due to too much data reported. In addition, do not perform the
operations affecting computer performances (such as data analysis) when
the test data is being recorded.
2.4.2.14 Some questions during the test (Return)

 Description:
1) Why is the Ec/Io of a cell with many SCs found in the DT (SC ranging from 0
to 511)? The channel number of the DTI configured in the Probe is 10664.
The following figure shows the DT results.

Figure 1 Ec/Io collected by the scanner
2) In the DT with the Probe software, a cell with two SCs being 29 is detected
with the scanner. The data configuration is confirmed as correct. Why?
The scanner
detected a cell
with two Signals were previously
scrambles 29! received normally here.
Figure 2 Distribution of SCs
3) Only the frequency point 2132.8 (10664) is configured in the pilot

deployment. No other frequency points are displayed in the UE active set
detected with the Probe, but three frequency points are detected with the
Assistant. Why? Even other competitors’ pilot networks are available in the
coverage, cell signals of other frequency points cannot be added to the
active set. See the following figure.

Figure 3 10603 Ec/Io distribution
Figure 4 10841 Ec/Io coverage

Figure 5 10664 Ec/Io coverage
 Answers:
1) This problem is most likely caused by the DTI. Normally, the DTI cannot find
so many SCs, and each SC has only few points. In this case, enable the
playback function of the Probe to check whether these SCs. If SCs are
unavailable during the playback, the Assistant does not run normally.
Otherwise, replace the DTI and try again.
2) The similar case ever happened in X city. The DTI locks a channel, but the
SCs of other frequency points still can be obtained in actual tests. To solve
such a rare problem, you just need to replace the DTI.
3) Lock the frequency of Huawei test handset, and then test again. To lock the
frequency, press * + # + left key, select the frequency point to be locked,
input the frequency point number (such as 10664), and press Ok. The
frequency locking is finished after the handset is restarted. An engineering
handset is recommended as it can check whether the frequency is locked
after startup. If the operation fails, try again according to the above
procedure.
2.4.2.15 The Probe cannot detect the ports of Huawei U626 (Return)
 Description:
The USB port of Huawei U626 is connected to a PC. The port number is configured in
the Hardware Config window with the Probe. But the port of Huawei U626 is not
detected.
 Cause analysis:
The Probe cannot detect Huawei U626. The possible causes are as follows:
1) Port and baud rate setting in the Probe
2) USB driver installation
3) Handset setting

1) Check whether the USB driver is installed normally. Right-click May
Computer, and select Properties. On the Hardware tab, click Device
Manager. Check the U626 driver state under Port (COM and LPT). The
driver is found normal.
2) Check the port configuration and baud rate in the Probe.
3) Check the port of the U626 handset. Press * + # + left key to enter the
engineering mode. Press Other. Set 3: USB DIAG again. Check the
handset port again. The detection succeeds.
2.4.2.16 The PDP cannot be activated as the handset initialization commands are set on
the computer (Return)
 Description:
In a DT, connect Huawei U626 handset to the PC. Run the Probe software and
configure it. But the handset cannot access Internet by manual dialup. The system
prompts that a connection with the remote computer cannot be set up and the
connection used for this port is closed.
 Cause analysis:
Check whether the PC cannot identify the handset first. Open the device manager.
But the hardware device has been detected.
Check whether the account and Modem of the handset are set correctly. Open the
handset setup window. But the access point and Modem are set correctly.
Then, check whether the dialup connection is set up correctly. The dialed number
*99# and the used Modem (huawei3G) are correct.
At last, an initialization command configured for previous domestic tests is found,
which results in the setup failure.
On the control panel, select Telephone and Modem options. In the popup window,
select the corresponding Modem on the MODEM tab, and click Properties. The
Advanced window is opened. Delete the extra initialization command. The problem is
solved. The handset can access Internet and the PDP is activated successfully.
Some settings are applicable to domestic tests only and cannot be used in overseas
tests. For example, the initialization command configured on the PC can change the
data account of the handset forcibly. The extra initialization command is
at+cgdcont=1,"IP","cmwap";+cgeqreq=1,3,64,128. In this command,
at+cgdcont=1,"IP","cmwap"/”cmnet” is used to set the APN address. You do not need
to set the APN address on the handset once it is configured on the PC.
cgeqreq=1,3,64,128 is used to set the service type and requested uplink and
downlink rates. Here, 3 stands for interactive service, 64 for the 64 K requested uplink
rate, and 128 for 128 K requested uplink rate. However, it is not the same case in
Malaysia, so the connection fails.
2.4.2.17 How to handle when the HSDPA cell load test fails (Return)
 Description:
The cell load test in the WCDMA is a very applicable test function for current domestic
pilot deployment. For an HSDPA cell, run the same command as a common cell, STR
DLSIM. If the operation fails, different error prompts are displayed for different loads.
When the load is smaller than or equal to 37%, the prompt of exceeding system
capacity is displayed. When the load is equal to or higher than 38%, the prompt of
downlink channel code conflict is displayed.

 Cause analysis:
If the load fails, check the cell resource usage first. Through the code resource
monitoring in cell performance monitoring, you can check the usage of each channel
code in a cell, as shown below.
Figure 1 Code resource monitoring of cell channel (1)
From Figure 1, you can find that:

1) The CCH occupies Cch,256,0 to Cch,256,3, and Cch,64,1.
2) The HSSCCH of HSDPA occupies Cch,128,4 to Cch,128,7.
3) The HSPDSCH of HSDPA occupies Cch,16,11 to Cch,16,15.
In addition, by checking the help information of the command, you can find that the
SF 128 channel codes from 112 to 127 are used for downlink load simulation.
However, these channel codes are used by the HSDPA by default in an HSDPA cell.
So, the load fails.
1) Disable the HSDPA feature of a cell.
+++ HW-BSC6800 2006-04-05 19:18:59;
O&M #27363;
%%DEA CELLHSDPA: CELLID=47;%%;
RETCODE = 0 The operation succeeds.
2) Add the reserved channel codes to non HSDPA users:

+++ HW-BSC6800 2006-04-05 19:34:30;
O&M #27369;
%%ADD RESERVEOVSF: CELLID=47, DLOVSFSF=SF8, DLCODENO=7;
%%;
3) Activate the HSDPA feature of the cell:

+++ HW-BSC6800 2006-04-05 19:38:07
O&M #27373

%%ACT CELLHSDPA: CELLID=47;%%

4) Loading succeeds.

1) In the HSDPA cell load test, the cell can be loaded successfully after the
HSDPA function of the cell is disabled. However, to reduce the impacts on
HSDPA users, the recommended sequence is as follows: deactivating the
HSDPA function, reserving channel code resources to non HSDPA users,
activating the HSDPA function, and then loading the cell.
2) The HSDPA cell is loaded directly without nay other operations. But different
error prompts are displayed when 37% to 38% is loaded. The cause is that
the HSDPA channels and public overhead channels have occupied 96 out of
SF256 channel codes, equaling about 37.5% (96/256).
2.4.2.18 No CQI data is available in the air interface data collection test of the HSDPA
 Description:
Use the Probe 1.3 and E620 data card for the HSDPA test. After the data connection
is set up, carry out the FTP test. But you can find that other data except CQI is
updated dynamically in the HSDPA Link Statistics window. There is still no CQI data
after you import the log data into the Assistant.
 Description:
1) Use the QXDM for test immediately on the same laptop. But there is still no
CQI data.
2) The CQI value is displayed on other laptops in the same environment
(network).
3) Remove the E620 data card and then install it again. Use the Probe and
QXDM to test again. The CQI value can be displayed.
If data transfer and other parameters are displayed normally, and only the CQI value
is not displayed in the HSDPA test, the recommended method is to remove and
reinstall the E620 data card.

3 KPI Acceptance Test of UMTS Radio Network

The network acceptance phase generally refers to the phase when the network
optimization is end and the network is to be used. The test items and methods are
identical with those evaluated before network optimization. The detailed indexes
should be confirmed with the customer through negotiation. The test route is the KPI
acceptance route or its sub-set determined in the RF optimization phase. At least one
formal pre-test is required when you formally perform the acceptance test with the
customer, to ensure the result of the formal test. If the test index requirements cannot
be met, you need to optimize the network again. For the solutions, refer to the
relevant special guide. To ensure the acceptance result, you need to select a handset
with a high sensitivity and stable performance to test.
When analyzing the data, refer to the result analyzed by tool and the actual record
data on paper. After each test, both Huawei and the customer need to sign the test
result.
This section emphasizes on descriptions of the meaning and the test method of each
performance index in the network acceptance phase. The detailed reference value of
each index is not involved.
For basic operation on the GENEX series tool, refer to Operation Manual and Vocal
Training Series on GENEX Tool.
3.1 Preparation before Acceptance Test

Before network acceptance, specify basic requirements and the operation mode to be
followed in the network acceptance, such as determining the acceptance range (by
areas), DT specifications, start time of the acceptance, evaluation mode for traffic
statistics indexes, and evaluation mode for DT indexes.
To ensure the network acceptance progress and smooth acceptance, divide the entire
project into several areas. After each area meets the basic condition, start the
acceptance, and monitor the DT and traffic statistics indexes. The areas are
independent and without any mutual interference. For the division of acceptance
areas, refer to the cluster of the RF and parameter optimization phase, and determine
the division through negotiation with the customer. According to the actual condition,
divide areas into key areas and non-key areas. Discuss each area to determine
whether to evaluate the DT and traffic statistics indexes, and whether to load and the
load percentage. Perform the CQT test acceptance for key areas (see section 3.3).
After each index within the corresponding area meets the requirements, perform the
DT acceptance (see section 3.2). After each index meets the requirements and is
kept for seven days, perform the traffic statistics index acceptance (see section 3.4).
Before network acceptance, check states and alarms of all sites in the area, and
confirm that cells in the area are normal without an alarm. Check board fault alarms
and transport fault alarms of the relevant NEs (RNC and NODEB) through LMT or the
M2000. Check the cell state by running DSP CELL of the MML command of RNC
LMT.
3.1.1 Determining Acceptance Area and Route
Perform the KPI DT route test in dialing test mode with few WCDMA terminals on the
preset test route. Perform the round trip test according to the route. The principle is to
traverse main streets in the coverage areas of the test network.

Note:
1. For the division of acceptance areas, refer to the cluster in the RF and parameter
optimization phase, and determine the division through negotiation with the customer.
Take city x as an example, and the acceptance areas are divided into A, B, C, and D.
See the following figure.
2. The acceptance route need cover main roads of acceptance areas, and roads
adjacent to main residential areas, and buildings. Take cite x as an example, and the
detailed acceptance route is as the following figure (forward direction route map):
Figure 1 Acceptance route of area A and area B in city x

Figure 2 Acceptance route of area C and area D in city x
3.1.2 Selection of 2G and 3G Interoperability Scenarios

Note: The inter-system handover and reselection scenarios are as follows:
 2G has the indoor distribution system, while 3G does not.
 3G coverage edge moves to the 2G coverage area at a low speed of 30 km/h.
 2G covers with repeaters, while 3G does not cover with repeaters.
The CS adopts the unidirectional WCDMA-to-GSM handover route, and the PS
adopts the bi-directional handover route between WCDMA and GPRS.
Select three scenarios mentioned above to perform the acceptance test in areas A, B,
C, and D of city x. The test scenario of area A is as follows:

Figure 1 Acceptance place of handover between 2G and 3G in area A of city x
3.1.3 Selection of Delay Test Scenario

Note: Select an area with good network coverage for the delay test.
Figure 1 Delay test place
3.1.4 Description of Uplink and Downlink Load

The acceptance test is based on the load situation determined by the plan simulation
result. Take load of cells in areas A and B of city x as an example. See the following
table:

Table 1 Load of cells in areas A and B of city x
UL Load DL Load UL Load UL Load (dB) DL Load (%)

Transmitter
(%) (dBm) (dB) Round up Round up
Banzhanghu_1 13.5 37.18 0.6 1 26
Banzhanghu_2 12.8 37.23 0.6 1 26
Banzhanghu_3 11.5 37.29 0.5 1 27
Baoziwang_1 12.9 37.34 0.6 1 27
Baoziwang_2 11.0 37.37 0.5 1 27
Baoziwang_3 11.0 37.37 0.5 1 27
3.2 Standards and Methods of DT Acceptance Test

3.2.1 DT Acceptance Indexes
Table 1 DT acceptance indexes
Category Index Section
Mileage call drop ratio Mileage Call Drop Ratio (Return)
Coverage ratio Coverage Ratio (Return)

Coverage
Soft handover ratio Soft Handover Ratio (Return)
Pilot pollution ratio Pilot Pollution Ratio (Return)
Call completion ratio of

Call Completion Ratio of the Caller (Return)
the caller
Call completion ratio of

Accessibility Call Completion Ratio of the Callee (Return)
the callee
PDP activation success

PDP Activation Success Ratio (Return)
ratio
CS call drop ratio CS Call Drop Ratio (Return)
Retainability PS call drop ratio PS Call Drop Ratio (Return)
MBMS dropping rate MBMS dropping rate
Service integrity Ratio of relatively high

Ratio of Relatively High Uplink BLERs (Return)
uplink BLERs
Ratio of relatively high

Ratio of Relatively High Downlink BLERs (Return)
downlink BLERs
Downlink average
Downlink Average Throughput (Return)
throughput
Uplink average Uplink Average Throughput (Return)

throughput

Downlink average
Downlink Average Throughput of HSDPA Single User
throughput of HSDPA
(Return)
single user
HSDPA cell throughput HSDPA Cell Throughput (Return)
Uplink average
Uplink average throughput per
throughput per HSUPA
HSUPA user
user
MBMS BLER MBMS BLER
MBMS RLC layer frame

MBMS RLC layer frame loss rate
loss rate
Objective voice
Objective Voice Evaluation (MOS) (Return)
evaluation (MOS)
Soft handover success

Soft Handover Success Ratio (Return)
ratio
Success ratio of intra-

Success Ratio of Intra-Frequency Hard Handover
frequency hard
(Return)
handover
Success ratio of inter-

Success Ratio of Inter-Frequency Hard Handover
frequency hard
(Return)
handover
Inter-System Handover Success Ratio (Return)

Inter-system handover
success ratio Inter-System Handover Success
Ratio (Return)
Success ratio of HSDPA

Success Ratio of HSDPA Intra-Frequency Service Cell
Mobility intra-frequency service
Update (Return)
cell update
Success ratio of HSDPA

Success Ratio of HSDPA Inter-Frequency Service Cell
inter-frequency service
Update (Return)
cell update
Success ratio of intra-

Success Ratio of Intra-Frequency Handover Between H
frequency handover
and R99 (Return)
between H and R99
Success ratio of inter-

Success Ratio of Inter-Frequency Handover Between H
frequency handover
and R99 (Return)
between H and R99
Success ratio of
handover from H to H-to-GPRS Handover Success Ratio (Return)
GPRS
Delay Delay Delay of Deleting Soft Handover

Link (Return)

Delay of Deleting Soft Handover

Link (Return)
Intra-Frequency Hard Handover

Delay (Return)
3.2.2.23Inter-Frequency Hard
Handover Delay (Return)
Inter-System Handover Delay

(CS) (Return)
Inter-System Handover Delay

(PS) (Return)
Delay of HSDPA Intra-Frequency

Service Cell Update (Return)
Delay of HSDPA Inter-Frequency

Service Cell Update (Return)
Delay of Intra-Frequency
Handover Between HSDPA and
R99 (Return)
Delay of Inter-Frequency
Handover Between HSDPA and
R99 (Return)
Delay of Inter-System Handover

Between HSDPA and GPRS
Note: Test cases related to the HSUPA need to be supplemented after the test
department outputs the HSUPA test baseline.
The DT acceptance refers to performing a DT in the predefined areas, analyzing data

after the DT, and evaluating CPICH Ec/Io, CPICH RSCP, UE Tx Power, Pilot
Pollution, service call completion ratio, and call drop ratio according to the
corresponding acceptance standard.
When preparing the acceptance standard, for a pilot, you can reasonably evaluate the
effect after the network is ready by referring to each index of the previous network, or
based on the latest performance baseline of Huawei. You can work out the
reasonable standard through sufficient communication and negotiation, to ensure that
the network can pass the acceptance smoothly. For a commercial office, the standard
subjects to the contract. If the customer has no special requirements, the standard is
based on the performance baseline of Huawei. In addition, to make the acceptance
smooth, it is recommended to divide areas according to the actual geographical
condition, and work out different standards for different areas.
The DT test indexes involved in the network acceptance include:
 Coverage: mileage call drop ratio, coverage ratio, soft handover ratio, pilot
pollution ratio
 Accessibility: call completion ratio of the caller, call completion ratio of the
callee, PDP activation success ratio
 Retainability: call drop ratio

 Service integrity: ratio of relatively high uplink BLERs, ratio of relatively high
downlink BLERs, download average throughput, uplink average throughput,
objective voice evaluation (mean opinion score (MOS))
 Mobility: soft handover success ratio, success ratio of intra-frequency hard
handover, success ratio of inter-frequency hard handover, inter-system handover
success ratio
 Delay: flow delay, etc.
After introduction of HSDPA, the test and statistics indexes of the PS service over
HSDPA are added from the aspects of accessibility, retainability, service integrity, and
mobility. For details, refer to DT acceptance indexes mentioned above.
3.2.2 Definitions and Test Methods of DT Acceptance Indexes
3.2.2.1 Mileage Call Drop Ratio (Return)

 Definition:
Mileage call drop ratio = (mileage of test road sections with Ec/Io ≥ -14 dB & reverse
Tx_Power ≤ 21 dbm & forward RSCP ≥ -100 dbm)/total count of call drops of road
sections that meet the condition mentioned above
 Service: voice/VP/PS.
 Test conditions:
The test is mainly used for the expressway.
The test is performed when the traffic is low. The uplink and downlink loads cannot
exceed the planned loads. Access failure caused by admission failure is eliminated.
Access failure caused by non-access network problems or the handset is eliminated.
 Test method:
1) Adopt the scanner + voice 3G ONLY continuous call test (continuous call).
2) Make the statistics after 5 m geographical average.
3) Adopt the planned full coverage service.
 Detailed statistics procedure:

1) Use the planned full coverage service to perform the continuous call test
according to the test route. If the call drop occurs during the test, set up the
service again and resume the test, till the test of all routes is complete.
2) Import the UE and the scanner test data in the Assistant, set Binning Type
and Binning Param Distance of the Dataset property to Distance Binning
and 5 respectively. See the following figure:

Figure 2 Setting based on 5 m geographical average
3) Drag Ec/Io for 1th Best ServiceCell, RSCP for 1th Best ServiceCell, UE
Tx Power, and UE Call Droped to the same table, and export them to an
Excel file.
Figure 3 Statistics description of mileage call drop ratio
4) Filter the data of the exported Excel file according to Ec/Io ≥ -14 dB & RSCP
≥ -100 dbm & UE Tx_Power ≤ 21 dbm & UE Tx_Power = NULL (The
sampling frequency time of the UE and the scanner is not consistent
completely). You can filter the data in customized filtering mode.
5) Make statistics of the total number A of record points and count B of call
drops, and the mileage call drop ratio is A x 5/(1000 x B).
3.2.2.2 Coverage Ratio (Return)
 Definition:
Coverage ratio = mileage of road sections that meet CPICH Ec/Io ≥ -12 dB & CPICH
RSCP ≥ -95 dbm/total mileage of test road sections x 100%
 Service: N/A
 Test condition:
The test is performed on the acceptance route. The uncovered areas are not
contained on the acceptance route.

 Test method:
1) Adopt the scanner 3G ONLY continuous test.
2) Make statistics after 5 m geographical average in the actual network.
3) Adopt the scanner to test CPICH Ec/Io and RSCP.

1) Use the planned full coverage service to perform the continuous call test
according to the test route. If the call drop occurs during the test, set up the
service again and resume the test, till the test of all routes is complete.
2) Import the UE and the scanner test data in the Assistant, set Binning Type
and Binning Param Distance of the Dataset property to Distance Binning
and 5 respectively. See Figure 2.
3) Drag Ec/Io for 1th Best ServiceCell, RSCP for 1th Best ServiceCell, and UE
Tx Power to the same table, and export them to an Excel file. Make
statistics of total number A of records in the exported Excel file.
Figure 1 Statistics description of coverage ratio
4) Filter the data of the exported Excel file according to Ec/Io ≥ -12 dB & RSCP
≥ -95 dbm. You can filter the data in customized filtering mode.
5) Make statistics of the total number B of records in the Excel file after the
data filter, and the coverage ratio is (B/A) x 100%.
3.2.2.3 Soft Handover Ratio (Return)

 Definition:
Soft handover ratio = (number of points that the number of the active set cells is 2 +
number of points that the number of the active set cells is 3)/total point number x
100%
 Service: N/A
1) The scanner data is used for analysis.
2) Report Range and Delay of the soft handover are set to 5dB and 2dB
respectively.
3) The test and statistics are performed in an area of Ec/Io > -11 dB and RSCP
> -90 dBm.
 Test method:
2) Perform the test on the acceptance route, and analyze the scanner
recorded data through 5m geographical average.
3) Start the DT tool to record the DT data.
4) Analyze the numbers A1, A2, and A3 of points that the numbers of active set
cells is 1, 2, and 3 respectively in the DT data.

5) The soft handover ratio is (A2 + A3)/(A1 + A2+A3).

1) Import the scanner data in the Assistant.
2) Modify relevant parameters of 1A, 1B, 1C, and 1D events for Scanner
Setting of the Dataset property as actual network configuration values. See
the following figure:
Figure 1 Scanner Setting
3) Export the Analysis Report: WCDMA Scanner Handover Analysis. See the
following table:
Table 1 Scanner handover statistics
Handover Statistic
Handover State Ratio
Single Sector Service 72.86%
2-way Softer Handover 14.67%
2-way Soft Handover 5.43%
3-way Softer Handover 1.04%
3-way Soft Handover 6.00%
Soft-softer Handover 0.00%
4) The soft handover ratio is 1-Single Sector Service.

3.2.2.4 Pilot Pollution Ratio (Return)
 Definition:

Pilot pollution ratio = number of points that the pilot signals accessing the active set ≥
4/total DT data point number x 100%.
 Note:
To access the active set, set the added threshold to 3 dB; the deleted threshold to 6
dB; the delay to 0; and the trigger time to 640 ms.
 Service: N/A
The scanner data is adopted for analysis.
The test and the statistics are performed in an area of Ec/Io > -11 and RSCP > -90
dBm.
 Test method:
2) Adopt the scanner data to make statistics after 5 m geographical average.

1) Import the scanner data in the Assistant.
2) Display the Whole PP parameter in geographical mode. Click in the
map toolbar to open the legend window. Make statistics of the total number
A of pilot pollution points. Then display RSCP for 1th Best ServiceCell in
geographical mode. Make statistics of the total test point number B.
Figure 1 Statistics description diagram of pilot pollution ratio
3) The pilot pollution ratio is (A/B) x 100%.

3.2.2.5 Call Completion Ratio of the Caller (Return)
 Definition:
Call completion ratio of the caller = count of caller call completion/count of caller
requests x 100%

 Note:
 The count of caller requests is the number of the CM service requests originated
by the handset of the caller.
 The count of caller call completion is the number of the Alerting messages
received on the handset of the caller receives the Alerting message.
 Service: voice/VP
The test is performed in an area of Ec/Io > -11 and RSCP > -90 dBm.
exceed the planned loads. Access failure caused by admission failure is eliminated.
Access failure caused by non-access network problems or the handset is eliminated.
 Test method:
Make statistics for the voice service and the VP service separately. The test
method is as follows:
1) Adopt scanner + voice 3G ONLY continuous dialing test (call by call).
2) The callee uses a fixed-line phone, or a handset in an area with good signal
coverage.
3) When the caller originates a call, add the count of caller requests to 1.
When the ringing tone is heard, the call is successfully connected, and add
the count of caller call completion to 1. Otherwise, the call fails.
4) After call completion, keep the call for 15 s, and then hang up the phone.
Wait for 10 s, and then originate another call.
5) If the call fails, wait for 30 s, and then originate another call.
6) Repeat the test for at least 200 times.

1) Import the UE data in the Assistant.
2) Display OutgoingCallAttempt in geographical mode. Click in the map
toolbar to open the legend window. Make statistics of the total count B of
caller requests. Then display OutgoingCallAlerting in geographical mode.
Click in the map toolbar to open the legend window. Make statistics of
the total count A of caller requests.
Figure 1 Statistics description diagram for call completion ratio of the caller
3) The call completion ratio of the caller is (A/B) x 100%.

3.2.2.6 Call Completion Ratio of the Callee (Return)
 Definition:

Call completion ratio of the callee = count of callee call completion/ count of callee
requests x 100%
 Note:
 The count of callee requests is the count that the handset of the caller originates
the service reqUEst.
 The count of callee call completion is the count that the handset of the caller
receives the Alerting message.
1) The test is performed in an area of Ec/Io > -11 and RSCP > -90 dBm.
2) The test is performed when the traffic is low. The uplink and downlink loads
cannot exceed the planned loads. Access failure caused by admission
failure is eliminated.
3) Access failure caused by non-access network problems or the handset is
eliminated.
4) Paging failure caused by handset power-off is eliminated.
5) Paging failure caused by the callee busy is eliminated.
6) Paging failure caused by that the callee is not in the service area is
eliminated.
 Test method:
Make statistics for the voice service and the VP service separately:
1) Adopt the scanner + voice 3G ONLY continuous dialing test (call by call).
2) The caller uses a fixed-line phone, or a handset in an area with good signal
coverage. The caller cannot use a fixed-line phone for the VP service.
3) When the caller originates a voice call, add the count of callee requests to 1.
the count of callee call completion to 1. Otherwise, the call fails.

1) Import the UE (placed in an area with good signal coverage) data of the
caller in the Assistant.
callee call completion. Then display OutgoingCallAlerting in geographical
mode. Click in the map toolbar to open the legend window. Make
statistics of the total count A of callee requests. See Figure 1.
3) The call completion ratio of the callee is (A/B) x 100%.
3.2.2.7 PDP Activation Success Ratio (Return)

 Definition:
PDP activation success ratio = count of PDP activation success/count of PDP
activation requests x 100%

 Note:
 The count of PDP activation requests is the number of the PDP Activation
ReqUEsts originated by the handset.
 The count of PDP activation success is the number of the PDP Activation Accept
messages received by the handset.
 Service: For the PDP activation success ratio of R99, the PS service is set up on
the DCH; for the PDP activation success ratio of HSDPA, the PS service is set
up on the HSDPA.
1) The test is performed in an area of Ec/Io > -11 and RSCP > -90 dBm.
2) The test is performed when the traffic is low. The uplink and downlink loads
3) Access failure caused by non-access network problems or the handset is
eliminated.
4) The activation success ratios with different rates are different. The success
ratio of a high-rate service is low.
 Test method:
1) For the PS service that is set up on the DCH, adopt the scanner + PS 128K
3G ONLY continuous PDP activation test (call by call); for the PS service
that is set up on the HSDPA, adopt the scanner + HSDPA 3G ONLY
continuous PDP activation test.
2) Perform the test or the statistics according to the typical subscription rate.
3) Perform the PDP activation test.
4) If PDP activation is successful, wait for 10s, and then deactivate the PDP.
5) If PDP activation fails, wait for 30s, and then activate the PDP again.
6) Make statistics of the counts of activation success and activation requests.

2) Display PDPActivationReq in geographical mode. Click in the map
PDP activation requests. Then display PDPActivationSuc in geographical
statistics of the total count A of PDP activation success.

Figure 1 Statistics description diagram of PDP activation success ratio
3) The PDP activation success ratio is (A/B) x 100%.

3.2.2.8 CS Call Drop Ratio (Return)
 Definition:
CS call drop ratio = count of service call drops/count of service connection x 100%
 Note:
Differentiate the CS call drop ratio for different services, such as voice, VP, and PS at
different rates.
Count of service connection: The number of the Alerting messages received on the
handset after sending the service request.
Count of service call drops: In terms of air interface signaling recorded at the UE side,
if any of the following messages is received on the air interface during the call (in the
connection state):
 Any BCH message (system message).
 RRC Release message where the released cause value is Not Normal.
 Any of the CC Disconnect, CC Release Complete, and CC Release messages
where the released cause value is Not Normal Clearing, Not Normal, or
Unspecified.
Add the count of call drops to 1.
 The test is performed in an area of Ec/Io > -11 and RSCP > -90 dBm.
 The test is performed when the traffic is low. The uplink and downlink loads
cannot exceed the planned loads. The call drops caused by congestion is
eliminated.
 The call drops caused by non-access network problems or the handset is
eliminated.
 Test method:
Make statistics for the voice service and the VP service separately. The DT

1) Adopt the scanner3 + voice 3G ONLY continuous call test (continuous call).
2) The called voice and VP are placed in an area with good signal coverage,
RSCP > -80 dBm, and Ec/Io > -8 dB.
3) Set the call time of the handset to 90 s, and the waiting time after call
completion to 15 s.
4) If the call drop occurs, wait for 30 s, and then originate another call.
5) Make statistics of the counts of call completion and call drops.

service connection. See the following figure. Then display CallDropped in
geographical mode. Click in the map toolbar to open the legend
window. Make statistics of the total count A of CS call drops.
Figure 1 Statistics description diagram of CS call drop ratio
3) The CS call drop ratio is (A/B) x 100%.

3.2.2.9 PS Call Drop Ratio (Return)
 Definition:
PS call drop ratio = count of PS service call drops/count of PDP activation success x
100%
 Note:
Differentiate the PS call drop ratio for different services, such as voice, VP, and PS
with different rates.
connection state):
3
The scanner is not necessary for each service test. But one test with the scanner must be ensured, and
similarly hereinafter.


Unspecified.
 Service: For the PS call drop ratio of R99, the service is PS, and the rate is the
planned full coverage rate. For the PS call drop ratio of HSDPA, the service is
over HSDPA, and the rate is the planned HSDPA cell edge rate.
eliminated.
eliminated.
 Test method:
1) For the PS call drop ratio of R99, adopt the 3G ONLY periodic download
test (call by call) of scanner + PS full coverage rate; for the PS call drop
ratio of HSDPA, adopt scanner + HSDPA 3G ONLY periodic download test
(call by call).
2) Perform the test or the statistics according to the planned full coverage rate.
3) Perform PDP activation. If the activation is successful, add the count of PDP
activation success to 1.
4) Start the FTP to download. Perform deactivation after 90 s. If the call drop
occurs during download, add the count of PS call drops to 1.

2) Display PDPActivationSuc in geographical mode. Click in the map
toolbar to open the legend window. Make statistics of the count B of PDP
activation success. See the following figure. Then display CallDropped in
geographical mode. Click in the map toolbar to open the legend
window. Make statistics of the total count A of PS call drops.
Figure 1 Statistics description diagram of PS call drop ratio

3) The PS call drop ratio is (A/B) x 100%.
3.2.2.10 Ratio of Relatively High Uplink BLERs (Return)

 Definition:
Ratio of relatively high uplink BLERs = number of points that the uplink BLER is
greater than the threshold/total number of uplink test points x 100%
 Note:
The thresholds of the voice service and the VP service are 30% and 20%
respectively.
 The BLER target value of the voice service is 1%.
 The BLER target value of the VP service is 0.2%.
 Test method:
2) Make statistics of uplink BLERs in the RNC. Set the statistics interval to 1 s.

1) Trace the connection performance of the single user in the RNC (See Guide
to WCDMA Equipment Room).
2) Process the traced text data by Excel, and make statistics according to the
acceptance requirements. The number of points that the uplink BLER is
greater than the threshold is A, and the total number of uplink test points is
B. Note: Make statistics of No. 1–31 channels. The signaling channel (No.
32) is beyond statistics.
Figure 1 Statistics description diagram of ratio of relatively high uplink BLERs
3) The ratio of relatively high uplink BLERs is (A/B) x 100%.

3.2.2.11 Ratio of Relatively High Downlink BLERs (Return)

 Definition:
Ratio of relatively high downlink BLERs = number of points that the downlink BLER is
greater than the threshold/total number of downlink test points x 100%
 Note:
respectively.
 Test method:
2) Make statistics after 5m geographical average.
3) The thresholds of the voice service and the VP service are 30% and 20%
respectively.

1) Import the UE and the scanner test data in the Assistant. Before import, set
Binning Type and Binning Param Distance of the Dataset property to
Distance Binning and 5 respectively. See Figure 2:
2) Determine the transport channel ID of the voice service (see 6.2 for the
method).
3) Display BLER for Transport Channel ID (The ID is a number from 0 to 5) in
table mode. Export the table as an Excel file. Filter and make statistics of
the number A of points that the downlink BLER is greater than the threshold
in the Excel, and the total number B of downlink test points.
4) The ratio of relatively high downlink BLERs is (A/B) x 100%.
3.2.2.12 Downlink Average Throughput (Return)

 Definition:
Downlink throughput = ∑ downloaded data traffic/statistics time
 Note:
 The downloaded data traffic is counted from the application layer.
 The downlink BLER Target of the PS service is set to 1%.
 Service: PS UL 64K/DL 64K, PS UL 64K/DL 128K, PS UL 64K/DL 384K.

 The test is performed when the traffic is low. The call drops caused by
congestion is eliminated.
 The FTP server is placed in the CN.
 The 5-thread is used to download.

 The throughput drops caused by non-access network problems or the

handset are eliminated.
 Test method:
1) Adopt the scanner + PS (64K/128K/384K) 3G ONLY continuous download
test (continuous call).
2) Prepare the data source: The download rate of the FTP data source can
exceed 384 kbit/s in the case of cable connection. Set the size of the data
source. Ensure that the data source is not interrupted by download
completion.
3) Activate the PS UL 64K/DL 64K service. Perform the test in the specified
place or on the acceptance route.
4) Adopt the download tool to start download. Adopt 5-thread to download.
5) Record actual downloaded data source quantity and the download time
during the test.
 Detailed statistics procedure 1 (Assistant):

1) When making the probe “test plan -> PS DialUp”, set both UL Ensure V
(Kbit/s) (maximum uplink assurance rate) and DL Ensure V (Kbit/s)
(maximum download assurance rate) to Default (default value).
Figure 1 Diagram for PS DialUp Test Plan making
2) Import the UE test data in the Assistant. The App Receive Rate, Best Ec/Io
InActiveSet, and Best RSCP In ActiveSet are displayed in a table. Export
the table in Excel format.
Figure 2 Statistics description diagram (1) of downlink average throughput

3) Filter all points in the Excel table according to the condition of Ec/Io > -11,
and RSCP > -90 dBm. Add up App Receive Rate (Byte/s) corresponding to
points that meet the condition as A. Make statistics of the total number of
points that meet the condition as B.
Filter of Ec/Io > -11 Filter of Ec/Io > -90
4) The downlink average throughput is A/B (Byte/s).
 Detailed statistics procedure 2 (DU Meter):

1) The test area must meet the basic coverage condition of Ec/Io>-11, and
RSCP>-90 dBm.
2) Make statistics of the whole test course by using the DU Meter tool. The
downlink average throughput is Average Receive rate/Download (kbit/s).

3.2.2.13 Uplink Average Throughput (Return)

 Definition:
Uplink throughput = ∑ uploaded data traffic/statistics time
 Note:
 The uplink BLER Target of the PS service is set to 1%.
 Service: PS UL 64K/DL 64K

eliminated.
 The FTP server is placed in the CN.
 The 5-thread is adopted to upload.
 Test method:
1) Adopt the scanner + PS (64K /128K/384K) 3G ONLY continuous download
test (continuous call).
exceed 64 kbit/s in the case of cable connection. Set the size of the data
source. Ensure that the data source is not interrupted by download
completion.
3) Activate the PS UL 64K/DL 64K service, and perform the test in the
specified place or on the acceptance route.
4) Adopt the download tool to start download, and adopt 5-thread to upload.
5) Record actual uploaded data source quantity and the upload time during the
test.
 Detailed statistics procedure 1 (Assistant):

1) When making the probe “test plan -> PS DialUp”, set both UL Ensure V
(Kbit/s) (uplink maximum assurance rate) and DL Ensure V (Kbit/s)
(downlink maximum assurance rate) to Default (default value)4. See Figure
1.
2) Import the UE test data in the Assistant. Display App Transmit Rate, Best
Ec/Io InActiveSet, and Best RSCP In ActiveSet in a table in table mode.
Export the table in Excel format.
4
The Qualcomm chip does not support that the UE sets the maximum assurance rate for the PS service. If
Default (default value) is not set, the UE may not be dialed.

Figure 1 Statistics description diagram (1) of uplink average throughput
3) Filter5 all points in the Excel table according to the condition of Ec/Io>-11,
and RSCP>-90 dBm. Add up App Transmit Rate (Byte/s) corresponding to
points that meet the condition as A. Make statistics of the total points that
meet the condition as B.
Filter of Ec/Io > -11 Filter of Ec/Io > -90
Figure 2 Statistics description diagram (2) of uplink average throughput
4) The uplink average throughput is A/B (byte/s).
 Detailed statistics procedure 2 (DU Meter):

1) The test area must meet the basic coverage condition of Ec/Io > -11, and
RSCP > -90 dBm.
2) Make statistics of the whole test course by using the DU Meter tool. The
uplink average throughput is Average transfer rate/Upload (kbit/s). See
Figure 4.
3.2.2.14 Objective Voice Evaluation (MOS) (Return)

 Definition: A test instrument measures the MOS.
5
The test condition strictly stipulates that a test area must meet the basic coverage condition of EcIo > -11,
and RSCP > -90 dBm. Due to certain uncertainty factors of the DT, the points that cannot meet the basic
coverage condition may be collected. To not affect the statistics accuracy of performance acceptance
indexes, it is recommended to filter the data before statistics.

 Note:
Generally the voice quality is measured by the MOS.
The obvious characteristics of the AMR voice:
 In the case of a certain load (that corresponds to the CIR of the UE), the MOS
tasted by users is not linearly increased with the increase of the voice rate used by
the UE. That is, in the case of a certain load, to obtain the maximum MOS, the
most appropriate AMR voice rate is not the maximum rate, but a proper
intermediate rate.
 The maximum transmitting power of the UE restricts the coverage range of the
uplink AMR voice. To expand the uplink coverage range of the AMR voice, it is
required to properly reduce the uplink rate without affecting the call quality of the
UE. The curve that the voice quality MOS changes with the C/I is as the following
figure:
 Service: The AMR is 12.2 K.

 Fixed outside point or DT result
 The voice adopts 12.2K code.
 The Trfo function is enabled.
 The test is performed in the office.
 Test method 1:
1) Perform the DT on the specified route.
2) Adopt Psytechnics Artificial Speech Test Stimulus (ASTS) to obtain the
MOS.
3) The test result is the average MOS of 10 minutes or so.
 Test method 2:
When a handset calls another handset or a handset calls a fixed-line phone, input the
reference voice source (can be played by a PC or in other mode) in one terminal
(handset or fixed-line phone), and (use a digital recorder to) record signals that are
processed by the system in another terminal (handset or fixed-line phone). Process
original and processed signals through the PESQ software or the VQT instrument (in
offline mode), and output the MOS.

Advantage: simple and convenient operation, with strong operability. The analysis can
be performed in offline mode. The end-to-end voice quality of the system can be
obtained.
Disadvantage: This test method is greatly affected by the terminal. If the call is
between different networks, the test method is affected by the quality of other
network.
 Test method 3:
Replace a fixed telephone with the VQT tester, and access the tester to the tested
system through the PSTN. The VQT tester calls a fixed-line phone. From the handset
(if it can loop back), BTS, BSC EVC or MSC to loop back to the VQT tester towards
the PSTN side. The VQT tester automatically provides the MOS test result.
Advantage: simple and convenient operation, with strong operability .This test method
can perform the segment voice quality test, to facilitate fault isolation and analysis.
Disadvantage: This test method is affected by the fixed network quality.
 Test method 4:
The BSC EVC board supports voice play and record (refer to the help file of the
commissioning console). This test method is similar to test method 2. The difference
is the test point. This function can be used to play the original voice on the EVC
through the commissioning console. The bi-directional play is supported, and you can
play the voice to the BTS side or to the MSC side. The original voice can be looped
back in the BTS or other places. The looped signals can be recorded on the EVC,
and be analyzed through the PESQ software or an instrument in offline mode.
Advantage: simple and convenient operation, with strong operability. This test method
can perform the segment voice quality test, to facilitate fault isolation and analysis.
Disadvantage: This test method cannot fully reflect the voice quality of the system. It
can reflect the voice quality between the test point and the loop point.
3.2.2.15 Soft Handover Success Ratio (Return)

 Definition:
Soft handover success ratio = ∑ count of soft handover completion/∑ count of soft
handover attempts x 100%
 Note:
 Count of soft handover attempts: the count that the RNC sends the Active Set
Update message.
 Count of soft handover failure: the count that the RNC receives the Active Set
Update Complete message.
 Service: CS & PS
cannot exceed the planned loads. The added handover link failure caused
by congestion is eliminated.
 Handover failure caused by user plane setup failure is eliminated.
 Handover failure caused by the handset is eliminated.
 Test method:
1) Adopt the voice or the VP 64K service to perform the long time call test. The
callee is placed in an area with good signal coverage.

2) The RNC starts the single user signaling tracing for testing the handset.
3) The handset records the RRC signaling flow.
4) Make statistics of the counts of the Active Set Update message sent by the
RNC and the Active Set Update Complete message received by the RNC.
5) During the test, if the call is interrupted, set up another call.

1) Import the single user tracing signaling of the RNC in the Assistant.
2) Make statistics of the count A of the Active Set Update message sent by the
RNC, and the count B of the Active Set Update Complete message received
by the RNC.
3) The soft handover success ratio is B/A x 100%.
3.2.2.16 Success Ratio of Intra-Frequency Hard Handover (Return)

 Definition:
Success ratio of intra-frequency hard handover = ∑ count of intra-frequency hard
handover completion/∑ count of intra-frequency hard handover attempts x 100%
 Note:
 The count of intra-frequency hard handover completion is the count of messages
that are received by the RNC and used for physical channel reconfiguration
complete of the intra-frequency hard handover.
 The count of intra-frequency hard handover attempts is the count of messages
that are sent by the RNC and used for physical channel reconfiguration of the
intra-frequency hard handover.
 Service: voice, VP, PS UL 64K/DL 64K, PS UL 64K/DL 128K, and PS UL 64K/DL

384K
cannot exceed the planned loads. Added handover link failure caused by
 Test method:
1) Perform the 128K/384K service download test.
5) Repeat the test for at least 20 times in each handover scenario.

1) Analyze the information recorded by the DT tool. Make statistics of the
count A of the Physical Channel Reconfiguration requests sent by the RNC,
and the count B of Physical Channel Reconfiguration Complete message send by
the handset.
2) The soft handover success ratio is B/A.
3) Note: Differentiate the physical channel reconfiguration of the start
compression mode during the statistics.

3.2.2.17 Success Ratio of Inter-Frequency Hard Handover (Return)

 Definition:
Success ratio of inter-frequency hard handover = ∑ count of inter-frequency hard
handover completion/∑ count of inter-frequency hard handover attempts x 100%
 Note:
 The count of inter-frequency hard handover completion is the number of the
messages that are received by the RNC and used for physical channel
reconfiguration completion of the inter-frequency hard handover.
 The count of inter-frequency hard handover attempts is the number of the requests
that are sent by the RNC and used for physical channel reconfiguration request of
the inter-frequency hard handover.
 Service: voice, VP, PS UL 64K/DL 64K, PS UL 64K/DL 128K, and PS UL 64K/DL

384K
cannot exceed the planned loads. Adding handover link failure caused by
 Test method:
1) Perform the CS continuous call test or the PS download test.

1) Analyze the information recorded by the DT tool. Make statistics of the
count A of the Physical Channel Reconfiguration requests sent by the RNC,
and the count B of the Physical Channel Reconfiguration Complete message
send by the handset.
2) The hard handover success ratio is B/A.
3.2.2.18 Inter-System Handover Success Ratio (Return)
 Definition:
Voice inter-system handover success ratio (outgoing handover) = ∑ count of inter-
system handover success/∑ count of inter-system handover attempts x 100%
 Note:
 The count of inter-system handover success is the number of the Handover
Complete messages received by the RNC from the UE.
 The count of inter-system handover attempts is the number of the Handover from
UTRAN Command messages from the RNC.
 Service: outgoing voice handover

 The drop speed of 3G network signals in 3 s cannot be 30 dB.
 The handover scenario of entering an elevator is excluded.
 During the handover, RxLex of 2G signals should be greater than -85 dBm.
 Handover failure caused by 2G network congestion is eliminated.
 Handover failure caused by 2G network reason is eliminated.
 Handover failure caused by handset reason is eliminated.
 During the handover, that the handset returns to the 3G network is not
counted as failure.
 Test method:
1) Determine 3–5 WCNMA-to-GSM handover scenarios (see 3.1.2). For
example, the environments that 2G has the indoor distribution system, and
3G does not have the indoor distribution system.
2) Adopt the voice continuous call to perform the call test in the area. Move the
handset from the WCDMA coverage area to the GSM coverage area.
3) Confirm that the handset is handed over from 3G to 2G. Record the
signaling messages at the handset side and the RNC side.
 Detailed statistics procedures:

1) According to the single user tracing messages recorded in the RNC, make
statistics of the count A that the RNC sends the Handover from UTRAN
Command message to the UE. Make statistics of the count B that the RNC
receives the IU RELEASE COMMAND message from the CN, and the
cause value of the message is Successful Relocation, Normal Release,
or Network Optimization.
2) The success ratio of WCDMA-to-GSM handover (voice) is B/A.
3.2.2.19 Inter-System Handover Success Ratio (Return)

 Definition:
PS inter-system handover success ratio (outgoing handover) = ∑ count of outgoing
PS inter-system completion/∑ count of outgoing PS inter-system handover attempts x
100%
 Note:
 The count of outgoing PS inter-system completion is the count of the Routing Area
Update Complete messages.
 The count of outgoing PS inter-system handover attempts is the count that the UE
receives the CELL CHANGE ORDER FROM UTRAN message.
 Service: outgoing PS handover

 The drop speed of 3G network signals in 3 s cannot be 30 dB.
 The handover scenario of entering an elevator is excluded.
 During the handover, RxLex of 2G signals should be greater than -85 dBm.
 Handover failure caused by 2G network congestion is eliminated.
 Handover failure caused by 2G network reason is eliminated.
 Handover failure caused by the handset reason is eliminated.

 During the handover, that the handset returns to the 3G network is not
counted as failure.
 Test method 1:
1) Place the handset in an area of inter-system handover. The handset is in a
WCDMA cell.
2) Adopt PS UL 64K/DL 64K to perform the ping packet test, with the
command: ping "target IP address” -l 20 -t 200. Move the handset to the
GPRS coverage area. Add the count of PS handover requests to 1.
3) Observe the screen of the handset, and ensure that the handset is handed
over to the GPRS. Observe whether ping is recovered after the interruption.
If it cannot be recovered in one minute, this test fails; otherwise, add the
count of PS handover success to 1. Return to the WCDMA coverage area.
Execute the forced rerouting to stay the handset to the WCDMA cell.
5) Change to another handover area, and continue to test.
 Test method 2:
1) The RNC starts the single user tracing messages, and records the signaling
messages of the handset.
2) The handset performs PDP activation (PS Interactive UL 64K/DL 64K).
Download a 50M file in FTP mode through WS_FTP to the handset. Move
the handset from the WCDMA coverage area to the GSM coverage area.
3) After the handset is handed over to 2G, keep the consistency of the service.
Move the handset to the 3G coverage area, and observe whether the 2G-to-
3G handover is successful.
5) Change to another handover area, and continue to test.
 Detailed statistics procedure 1:

1) Make statistics of the count A of PS handover requests, and the count B of
PS handover success.
2) The PS handover success ratio is B/A.
Detailed statistics procedure 2:
1) According to the single user tracing messages recorded by the RNC, make
statistics of the count A that the RNC sends the CELL CHANGE ORDER
FROM UTRAN message to the UE. During the outgoing PS inter-system
handover, if the RNC receives the IU RELEASE COMMAND message, the
cause value of the message is Successful Relocation, Normal Release, or
Network Optimization, and the RNC sends the RANAP IU RELEASE
COMPLETE message, the outgoing PS inter-system handover is
successful. Make statistics of the index as B.
2) The handover success ratio (PS) from WCDMA to GPRS is B/A.
3.2.2.20 Delay of Deleting Soft Handover Link (Return)

 Definition:
Added soft handover link delay: the time between the UE reporting the measurement
report of 1A events and the RNC receiving the ActiveSet Update Complete message
from the UE.
 Service: adding the soft handover link
 Test condition:
RSCP > -90 dBm, and EcIo > -11 dB
 Test method:
1) Adopt the voice or the VP 64K service to perform the long time call test. The
callee is placed in an area with good signal coverage (Ec/Io > -9 dB).

2) Place the handset of the caller in an area with good signal coverage.
Connect the test equipment.
4) Repeat the test for at least 20 times. Obtain the average value.

2) Make statistics of the time A1, A2, A3… Ab (s) between the RNC receiving
the measurement report of 1A events and the RNC receiving the Active Set
Update Complete message. The count of soft handovers is b.
3) The delay of adding soft handover link is (A1 + A2 + A3 + … + Ab)/b.
3.2.2.21 Delay of Deleting Soft Handover Link (Return)

 Definition:
Deleted soft handover link delay: the time between the UE reporting the
measurement report of 1B events and the RNC receiving the ActiveSet Update
Complete message from the UE.
 Service: deleting the soft handover link
 Test condition:
 Test method:
1) Adopt the voice or the VP 64K service to perform the long time call test.
Place the handset of the callee in an area with good signal coverage (Ec/Io
> -9 dB).
2) Place the handset of the caller in an area with good signal coverage.
Connect the test equipment.

2) Make statistics of the time A1, A2, A3… Ab (s) between the RNC receiving
the measurement report of 1B events and the RNC receiving the ActiveSet
Update Complete message. The count of the soft handovers is b.
3) The delay of deleting soft handover link is (A1 + A2 + A3 + … + Ab)/b.
3.2.2.22 Intra-Frequency Hard Handover Delay (Return)

 Definition:
Intra-frequency hard handover delay: the time from the RNC sending the radio link
setup request of the target cell to the RNC receiving the response of deleting the
original radio link.
 Service: intra-frequency hard handover
 Test condition:
 Test method:
1) Perform the 128K/384K service download test.
2) Place the handset to an area with good signal coverage. Connect the test
equipment. Ec/Io > -9 dB.


2) Make statistics of the time A1, A2, A3… Ab (s) between the RNC sending
the Physical Channel Reconfiguration request and the RNC receiving the
Physical Channel Reconfiguration Complete message. The count of intra-
frequency hard handovers is b.
3) The intra-frequency hard handover delay is (A1 + A2 + A3 + … + Ab)/b.
3.2.2.23 Inter-Frequency Hard Handover Delay (Return)

 Definition:
Inter-frequency hard handover delay: the time between the RNC sending the radio
link setup request of the target cell and the RNC receiving the response of deleting
the original radio link.
 Service: inter-frequency hard handover
 Test condition:
 Test method:
1) Perform the CS continuous call test or the PS download test.

2) Make statistics of the time A1, A2, A3… Ab (s) between the RNC sending
the Physical Channel Reconfiguration request and the RNC receiving the
Physical Channel Reconfiguration Complete message. The count of inter-
frequency hard handovers is b.
3) The inter-frequency hard handover delay is (A1 + A2 + A3 + … + Ab)/b.
3.2.2.24 Inter-System Handover Delay (CS) (Return)

 Definition:
CS inter-system handover delay: the time between the RNC sending the
UEHANDOVER FROM UTRAN COMMAND message and the RNC receiving the IU
RELEASE COMMAND message.
 Service: outgoing inter-system handover (CS)
 Test condition:
2G ReLex RSCP > -85 dBm
 Test method:
1) Adopt the voice continuous call to perform the call test in the area. Move the
handset from the WCDMA coverage area to the GSM coverage area.
2) Place the handset in an area with inter-system handovers, and in an area
without inter-system handovers.
4) When the RNC receives the IU RELEASE COMMAND message where the
cause value is Successful Relocation, Normal Release, or Network
Optimization, the handover is successful. Perform the statistics.

6) The UE records the RRC signaling flow.
 Detailed statistics procedure 1 (based on the messages at the RNC side)

1) The test method for signaling plane delay of each phase in CS 3G-to-2G
handover is obtained through tracing the messages at the RNC side,
confirming the time of the start message and the end message of the
signaling plane handover, and then calculation.
2) During the test of signaling plane delay in CS 3G-to-2G handover, originate
a voice call within the 3G signal coverage range. Move the handset
according to the requirements of the test scenario after the call is set up, till
the handover occurs. After the handover, the 2G flag appears in the
handset, and the call lasts. This indicates that the handover is successful.
Record the handover time during each test, to facilitate finding the signaling
at the RNC side. Repeat the procedure mentioned above for several (more
than 20) times, to complete the test of one scenario.
3) After the test, open the tracing messages at the RNC side. Find out the start
and end signaling points of each handover. Record the signaling time and
calculate the signaling plane delay.
In terms of the messages in the tracing handover execution phase of the
RNC single user, there are the following results:
Start point of
Start time of signaling
signaling plane plane
End point of
End time of signaling
signaling plane plane
Figure 1 Tracing the CS 3G-to-2G handover messages on the RNC TRACER
4) The signaling plane delay in the execution phase of CS 3G-to-2G handover

is the time difference of the two messages mentioned above.
Detailed statistics procedure 2 (based on the messages at the UE side)
In addition, adopt Huawei terminal and foreground test software GENEX Probe
to trace signaling at the UE side. Record the time that the UE receives the
Handover From UTRAN Command message and the time that the UE sends the
Handover Complete message after handing over to the GSM. This period of time
is the processing delay for the UN to hand over to 2G. In the handover principle,
this delay is segmented separately during the handover delay segmentation, to
assist analyzing the signaling plane delay. See the following figure:

Figure 2 Tracing the UE CS 3G-to-2G handover messages on the Huawei Probe
3.2.2.25 Inter-System Handover Delay (PS) (Return)

 Definition:
PS inter-system handover delay: the time between the RNC sending the CELL
CHANGE ORDER FROM UTRAN message and the RNC receiving the IU RELEASE
COMMAND message from the SGSN.
 Service: outgoing inter-system handover (PS)
 Test condition:
2G ReLex RSCP > -85 dBm
 Test method:
3) When the RNC receives the IU RELEASE COMMAND message, and the
cause value of the message is Successful Relocation, Normal Release, or
Network Optimization, the handover is successful. Perform the statistics.
5) The UE records the RRC signaling flow.


1) The signaling plane handover delay is obtained by calculating the difference
between the time that the RNC sends the
CELL_CHANGE_ORDER_FROM_UTRAN message to the UE and the time
that the RNC receives the IU RELESE COMMAND message from the
SGSN.
2) The test method for signaling plane delay is obtained through tracing the
messages at the RNC side, confirming the time of the start message and
the end message of the signaling plane handover, and then calculation.
3) During the test of the signaling plane delay in PS 3G-to-2G handover,
originate PDP activation within the 3G signal coverage range, continue to
ping packets to ensure that the air interface has data transfer. After
activation, move the handset according to the requirements of the test
scenario, till the handover occurs. After the handover, the 2G flag appears in
the handset, and continue to ping packets. Record the handover time during
each test, to facilitate finding the signaling at the RNC side. Repeat the
procedure mentioned above for ten times, to complete the test of one
scenario. After the test, open the tracing messages at the RNC side. Find
out the start and end signaling points of each handover. Record the
signaling time and calculate the signaling plane delay.
In terms of the tracing messages of the RNC single user, there are the following
results:
Start point of
Start time of signaling
signaling plane
plane
End time of
signaling
plane
End point
of signaling
plane
Figure 1 Tracing the PS 3G-to-2G handover messages on the RNC TRACER

The signaling plane delay of the PS 3G-to-2G handover is the time difference of the
two messages mentioned above.
3.2.2.26 Downlink Average Throughput of HSDPA Single User (Return)

 Definition:
 Note:
 NodeB LMT sets the initial downlink BLER target of the HSDPA to 10%.
 Two test scenarios, cell center and cell edge, are available. For example, test
condition 1, and test condition 2.
 Test condition 1: cell center

 The power, code resources and the Iub bandwidth are not restricted.
 The test is performed in the case of no load.
 The single HSDPA user is used to test in the cell center. The average CQI of
the test place is 18.
 MTU is set to 1500. For the setting method, refer to Guide to PS Problem
Optimization.
 The subscription rate is 2 Mbit/s. The subscription service type is
Background or Interactive.
 Test condition 2: cell edge
 Except the power, other resources are not restricted.
 The single HSDPA user is used to test in the cell edge. The average CQI of
the test place is 10.
Optimization.
 The subscription rate is 2 Mbit/s. The subscription service type is
Background or Interactive.
 Test method:
1) Adopt the HSDPA 3G ONLY continuous download test.
exceed 1.8 Mbit/s in the case of cable connection. Set the size of the data
source. Ensure that the data source is not interrupted due to download
completion during the test.
3) Activate the HSDPA service. Perform the test at the specified place or on
the acceptance route.
4) Adopt the download tool to start the download. Adopt 5-thread to download.
5) Record the actual downloaded data source quantity and the download time
during the test.
 Detailed statistics procedure (DU Meter):

 Note:
The DU Meter is non-standard software. Apply for and then use it.
1) Use the DU Meter tool to make statistics of the whole test course. Set the
following items first. Set Display Units to Kilobits per Second (kbit/s), and
set Network interface to monitor to Dial-Up Connections Only.
Figure 1 Du Meter setting
2) After the download rate is stable, select New Stopwatch -> Start from the
shortcut menu to start the statistics. If the test time is reached, or the set
test route driving is complete, stop the statistics, and then end the
download. Copy the screen. The downlink average throughput is equal to
Average transfer rate.
Figure 2 Du Meter statistics interface
3.2.2.27 HSDPA Cell Throughput (Return)

 Definition:

 Note:
 NodeB LMT sets the initial downlink BLER target of the HSDPA to 10%.
 Test condition 1: cell center

 For the UE test of four Category 12, 14 HS-PDSCH codes and four HS-
SCCH channels are configured.
 The Iub bandwidth is not restricted.
 The average CQI of the test place is 18.
Optimization.
 The subscription rate is 2M bit/s. The subscription service types of four UE
are identical. Their subscription service type is Background or Interactive.
 Test condition 2: cell edge
 For the UE test of four Category 12, 14 HS-PDSCH codes and four HS-
SCCH channels are configured.
 The Iub bandwidth is not restricted.
 The average CQI of the test place is 10.
Optimization.
 The subscription rate is 2M bit/s. The subscription service types of four UE
are identical. Their subscription service type is Background or Interactive.
 Test method:
1) Adopt the HSDPA 3G ONLY continuous download test.
exceed 15 Mbit/s in the case of cable connection. Set the size of the data
source. Ensure that the data source is not interrupted due to download
completion during the test.
4) Adopt the download tool to start the download. Adopt 5-thread to download.
5) Record the actual downloaded data source quantity and the download time
during the test.
 Detailed statistics procedure (DU Meter):

1) The use and the statistics procedure of DU Meter are the same as those of
the downlink average throughput of single user.
2) Make statistics when the rate of each test UE is stable. Release the UE
after the statistics of all UE are complete.
3) Record the downlink average throughput of single user of each UE. Add up
all downlink average throughputs to obtain the cell average throughput.

3.2.2.28 Success Ratio of HSDPA Intra-Frequency Service Cell Update (Return)

 Definition:
Success ratio of intra-frequency service cell update between H and H = count of intra-
frequency service cell update success between H and H/count of intra-frequency
service cell update attempts between H and H x 100%.
Reporting 1A events
The active set updates,
and adds cell 2.
Reporting 1D events, and
triggering the H-H service
cell update flow.
H-H service cell
update (cell 0-cell 2)
Figure 1 Flow of intra-frequency service cell update between H and H
The flow of intra-frequency service cell update between H and H is as the figure
above, and is triggered by 1D events. The statistics point of success count is Physical
channel reconfiguration complete, and that of the attempt count is Physical channel
reconfiguration.
 No R99 traffic, or the R99 traffic is set according to the planned load.
 Test method:
1) Adopt the HSDPA continuous FTP download test.
2) Set the size of the data source. Ensure that the data source is not
interrupted due to download completion during the test.
3) Activate the HSDPA service. Perform the test on the test route where the
handover can occur.
5) Probe + UE + scanner/GPS record the DT data.
 Statistics procedure 1:
2) Export the single user tracing signaling of the RNC to the Excel table. Make
statistics of and calculate the success ratio based on the index definition.
3.2.2.29 Success Ratio of HSDPA Inter-Frequency Service Cell Update (Return)

 Definition:
Success ratio of HSDPA inter-frequency service cell update = count of HSDPA inter-
frequency service cell update success/count of HSDPA inter-frequency service cell
update attempts x 100%.

Message 21: The UE reports

the measurement report of
2D events to the RNC.
Messages 22-28: The UE

and the NodeB start the
compression mode.
Messages 37-54: The UE reports

the measurement report. When
the value of the measurement
report meets the requirement of
the inter-frequency hard handover
threshold, the physical channel
reconfiguration flow is triggered
to complete the hard handover
and the HS-PDSCH service cell
update.
Figure 1 Flow of HSDPA inter-frequency service cell update
The flow of HSDPA inter-frequency service cell update is as the figure above. After a
2D event triggers the start compression mode, the UE reports the test report that
meets the requirements of inter-frequency hard handover threshold. The UE then
triggers the physical channel reconfiguration flow, to complete the hard handover and
H service cell update.
The statistics point of success count is the Physical channel reconfiguration complete
message for inter-frequency service cell update received by the RNC. The statistics
point of request count is the Physical channel reconfiguration message for inter-
frequency service cell update sent by the RNC. Note: Differentiate the physical
channel reconfiguration of the start compression mode during the statistics.
 The UE of Category 12 is adopted, such as Huawei E620, and TM6275.
 Test method:
6) Make statistics of the count that the RNC sends the physical channel
reconfiguration message for completing inter-frequency hard handover and
service cell update between H and H, and the count that the RNC receives

the physical channel reconfiguration complete message for inter-frequency

hard handover and service cell update between H and H.

3.2.2.30 Success Ratio of Intra-Frequency Handover Between H and R99 (Return)

 Definition:
Success ratio of intra-frequency handover between H and R99 = (count of H-to-R99
intra-frequency handover success + count of R99-to-H intra-frequency handover
success)/(count of H-to-R99 intra-frequency handover requests + R99-to-H intra-
frequency handover requests) x 100%.
The detailed index statistics points are provided according to the following flow.
Reporting 1A events
RL-ADD is within the NodeB;

RL-SETUP is between NodeBs.
The active set updates, and
adds the R99 cell.
Reporting 1B events
Channel handover: H-to-DCH
Deleting the original H cell
Figure 1 Flow of intra-frequency handover between H and R99
The flow of the HSDPA-to-R99 intra-frequency handover is as the figure above. After
reporting 1B events of the HSDPA service cell, the UE triggers the HSDPA-to-DCH
handover. The UE deletes the HSDPA feature through the RB reconfiguration
message. The UE then deletes the original HSDPA cell in the active set.
For the count of H-to-R99 handover success, the statistics point is Active Set Update
Complete of the deleted original HSDPA cell.
For the count of H-to-R99 handover requests, the statistics point is the RB
Reconfiguration message sent by the RNC.

Reporting 1A events
RL-SETUP is between NodeBs.
The active set updates, and
adds H cell 10.
Reconfiguring RL resources
Reconfiguring RB resources,
indicating the information at the
TrCH and PHY layers and the
activation time, and handing
services from the DCH over to
the HS-DSCH
Figure 2 Flow of soft handover accompanied with DCH-to-H handover
The flow of the soft handover accompanied with the DCH-to-HSDPA handover is as
the figure above. After reporting 1A events of the HSDPA service cell, the UE triggers
the DCH-to-HSDPA handover.
For the count of R99-to-HSDPA handover success, the statistics point is the RB
Reconfiguration complete message received by the RNC.
For the count of R99-to-HSDPA handover requests, the statistics point is the Active
Set Update message sent by the RNC.
 Test method:
3) Activate the HSDPA service. Perform the test on the acceptance route. An
HSDPA cell and a R99 cell are on the test route.
6) Make statistics of the count of the RB reconfiguration message of the soft
handover accompanied with the handover between H and DCH sent by the
RNC, and the count of the RB reconfiguration messages received by the
RNC.


3.2.2.31 Success Ratio of Inter-Frequency Handover Between H and R99 (Return)

 Definition:
Success ratio of inter-frequency handover between H and R99 = (count of H-to-R99
inter-frequency handover success + count of R99-to-H inter-frequency handover
success)/count of H-to-R99 inter-frequency handover requests + R99-to-H inter-
frequency handover requests) x 100%.
For the count of H-to-R99 inter-frequency handover success, the statistics point is the
count of physical channel reconfiguration complete of the inter-frequency hard
handover completed after the HSDPA feature is deleted.
For the count of H-to-R99 inter-frequency handover requests, the statistics point is
RB Reconfiguration that originates deleting the HSDPA feature.
For the count of R99-to-H inter-frequency handover success, the statistics point is the
RB Reconfiguration complete message received by the RNC.
For the count of R99-to-H inter-frequency handover requests, the statistics point is
the physical channel reconfiguration request for the inter-frequency hard handover
sent by the RNC.
 Test method:
3) Activate the HSDPA service. Perform the test on the acceptance route. An
HSDPA cell and a R99 cell are on the test route.
6) Make statistics of the count of the RB reconfiguration message of the soft
handover accompanied with the H-to-R99 handover sent by the RNC, and
the count of the RB Reconfiguration complete messages received by the
RNC.

3.2.2.32 H-to-GPRS Handover Success Ratio (Return)

 Definition:
H-to-GPRS handover success ratio = count of H-to-GPRS handover success/count of
H-to-GPRS handover attempts

Reporting 2D events
Configuring the physical

channel in compression
mode
Starting the
compression mode
Indicating the UE to
perform the inter-system
handover
Figure 1 Flow of HSDPA-to-GPRS handover
The flow of the HSDPA-to-GPRS handover is similar to that of the DCH-to-GPRS

handover. The difference is the PH_CH_RECFG message of the start compression
mode of the HSDPA-to-GPRS handover flow describes the physical channel type
before the handover.
For detailed test conditions and the index calculation, refer to section 3.2.2.19“Inter-
System Handover Success Ratio (Return).”
3.2.2.33 Delay of HSDPA Intra-Frequency Service Cell Update (Return)

 Definition: the time between the RNC receiving the measurement report of UE
1D events and the SRNC receiving the Physical channel reconfiguration
complete message from the UE, which is counted at the RNC side.
 Test operation:
The handover delay is tested with the corresponding test items of handover success
ratio. For detailed test operation, refer to the test of the corresponding handover
success ratio.
 Data statistics:
2) According to the index definition mentioned above, make statistics of each
delay of HSDPA intra-frequency service cell update. Obtain the average
value.
3.2.2.34 Delay of HSDPA Inter-Frequency Service Cell Update (Return)

 Definition:
the time between the SRNC sending the RL Setup Request message to the target
NodeB and the SRNC receiving the Radio Link Deletion Response message from the
source NodeB, which is counted at the RNC side.
 Test operation:
success ratio.
delay of HSDPA inter-frequency service cell update. Obtain the average
value.

3.2.2.35 Delay of Intra-Frequency Handover Between HSDPA and R99 (Return)

 Definition:
the time between the SRNC sending the RL Reconfig Prepare message to the target
NodeB and the SRNC receiving the RB Recfg CMP message from the UE, which is
counted at the RNC side.
 Test operation:
success ratio.
delay of intra-frequency handover between HSDPA and R99. Obtain the
average value.
3.2.2.36 Delay of Inter-Frequency Handover Between HSDPA and R99 (Return)

 Definition: the time between the SRNC sending the RL Reconfig Prepare
message to the target NodeB and the SRNC receiving the RB Recfg CMP
message from the UE, which is counted at the RNC side.
 Test operation:
success ratio.
delay of inter-frequency handover between HSDPA and R99. Obtain the
average value.
3.2.2.37 Delay of Inter-System Handover Between HSDPA and GPRS

 Definition:
the time between the RNC sending the Cell Change Order From UTRAN message to
the CN and the RNC receiving the IU Release Command message from the CN with
the cause value of Successful Relocation or Normal Release, which is counted at the
RNC side.
the time between the UE receiving the Cell Change Order From UTRAN message in
a WCDMA cell and the UE sending the Route Update Complete message in a GPRS
cell, which is counted at the UE side.
 Test operation:
success ratio.
1) Import the probe DT tracing file and single user tracing signaling of the RNC
in the Assistant.
delay of HSDPA-to-GPRS handover at the RNC side or the UE side. Obtain
the average value.

3.2.2.38 MBMS dropping rate ( Return)

 Index definition:
MBMS dropping rate = number of MBMS dropping times/total number of successes of
MBMS-on-demand x 100%
Number of MBMS dropping times: One MBMS dropping 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
Conduct the test in an area where the Ec/Io is greater than –11 and the RSCP is
greater than –90 dBm.
 Test method:
After the MBMS-on-demand starts, if the MBMS-on-demand service is exceptionally
interrupted or it is learned from the QXDM that the UE is in the buffering state for
more than one minute, an MBMS dropping time is counted.
3.2.2.39 MBMS BLER (Return)

Downlink average BLER of the MBMS service
Perform the test in an area where the Ec/Io is greater than –11 and the RSCP is
 Test method:
Average BLER of the FACH recorded by the UE in a long period of MBMS-on-
demand
3.2.2.40 MBMS RLC layer frame loss rate ( Return)

RLC layer frame loss rate = number of lost RLC layer frames/total number of RLC
layer frames x 100%
Number of lost RLC layer frames: Number of lost RLC layer frames during MBMS-on-
demand
Total number of RLC layer frames: Number of RLC layer frames that should be
received during MBMS-on-demand
 Test method:
The number of lost frames can be obtained through the statistics of the number of lost
frames between inconsecutive frame Nos. at the RLC layer by the QXDM.
The total number of frames can be calculated according to the start RLC layer frame
No. and the end RLC layer frame No.

3.3 Standards and Methods of CQT Test Acceptance

3.3.1 CQT Acceptance Indexes
Table 1 CQT acceptance indexes
Call completion Call Completion Ratio of the Caller (Return)

ratio of the caller
Call completion Call Completion Ratio of the Callee (Return)

rate of the callee
Accessibility
PDP activation PDP Activation Success Ratio (Return)
success ratio
MBMS-on-demand MBMS-on-demand success ratio

success ratio
CS Call Drop Ratio (Return)

Retainability Call drop ratio
PS Call Drop Ratio (Return)
Ratio of relatively Ratio of Relatively High Uplink BLERs (Return)

high uplink BLERs
Ratio of relatively Ratio of Relatively High Downlink BLERs (Return)

high downlink
BLERs
Service
Objective voice Objective Voice Evaluation (MOS) (Return)
integrity
evaluation (MOS)
HSUPA cell
HSUPA cell throughput
throughput
HSUPA cell
HSUPA cell throughput
throughput
Call Setup Delay (UE to UE/UE to PSTN) (Return)
Call setup delay Call Setup Delay (PSTN to UE) (Return)
Call Setup Delay (PS) (Return)
RTD delay of ping RTD Delay of Ping Packet (Return)
Delay packet
Service interruption Service Interruption Delay (Return)

delay
MBMS-on-demand delay
MBMS-on-demand
delay
Note: Test cases related to the HSUPA need to be supplemented after the test
department outputs the HSUPA test baseline.

The CQT is mainly used to test the network performance. Before the formal test, the
two test parties have definite requirements for the test result.
The CQT acceptance refers to performing the dialing test for the predefined key
areas, to feel actual service conditions, and evaluate service connection, call drops,
and the QoS according to the corresponding acceptance standard. In comparison
with the DT test, the CQT test acceptance indexes depend more on the subjective
taste of the acceptance personnel.
Generally the CQT test is performed for different services in intermittent call mode.
One call is disconnected after keeping certain time, and another call is resumed.
As a finial result of the network optimization, the CQT test result must meet the
customer’s requirements. If the CQT test result cannot meet the requirements of test
indexes, the network is required to be optimized again. For the solutions, refer to the
related special guide.
The CQT test indexes involved in the network acceptance include:
 Accessibility: call completion ratio of the caller, call completion ratio of the
callee, PDP activation success ratio
 Service integrity: ratio of relatively high uplink BLERs, ratio of relatively high
downlink BLERs, objective voice evaluation (MOS), objective taste
 Delay: call setup delay, PDP activation delay, UE-to-UE user plane delay, UE-to-
PSTN user plane delay, RTD delay of ping packet, service interruption delay
3.3.2 Definitions and Test Methods of CQT Acceptance Indexes
3.3.2.1 Call Completion Ratio of the Caller (Return)

 Definition:
Call completion ratio of the caller = count of caller call completion/count of caller
requests x 100%
 Note:
 The count of caller requests is the count that the handset of the caller originates
the service request.
 The count of caller call completion is the count that the handset of the caller
receives the Alerting message.
 Access failure caused by non-access network problems or the handset is
eliminated.
 Test method:
1) The callee uses a fixed-line phone, or a handset in an area with good signal
coverage.

2) When the caller originates a call, add the count of caller requests to 1.
the count of caller call completion to 1. Otherwise, the call fails.

caller requests. Then display OutgoingCallAlerting in geographical mode.
Click in the map toolbar to open the legend window. Make statistics of
the total count A of caller requests. See Figure 1.
3) The call completion ratio of the caller is (A/B) x 100%.
3.3.2.2 Call Completion Ratio of the Callee (Return)

 Definition:
Call completion ratio of the callee = count of callee call completion/count of callee
requests x 100%
 Note:
 The count of callee requests is the number of the service requests originated by
the handset of the caller.
 The count of callee call completion is the number of the Alerting messages
received by the handset of the caller.
eliminated.
 Paging failure caused by handset power-off is eliminated.
 Paging failure caused by the callee busy is eliminated.
 Paging failure caused by that the callee is not in the service area is
eliminated.
 Test method:
Make statistics for the voice service and the VP service separately:
1) The caller uses a fixed-line phone, or a handset in an area with good signal
coverage. The caller cannot use a fixed-line phone for the VP service.
2) When the caller originates a voice call, add the count of callee requests to 1.
the count of callee call completion to 1. Otherwise, the call fails.


1) Import the UE (placed in an area with good signal coverage) data of the
caller in the Assistant.
callee call completion. Then display OutgoingCallAlerting in geographical
statistics of the total count A of callee requests. See Figure 1.
3) The call completion ratio of the callee is (A/B) x 100%.
3.3.2.3 PDP Activation Success Ratio (Return)

 Definition:
PDP activation success ratio = count of PDP activation success/count of PDP
activation requests x 100%
 Note:
 The count of PDP activation requests is the number of the PDP Activation
ReqUEsts originated by the handset.
 The count of PDP activation success is the number of the PDP Activation Accept
messages received by the handset.
 Service: The PS service is set up on the DCH.

eliminated.
 The activation success ratios of different rates are different. The success
ratio of a high-rate service is low.
 Test method:
1) Perform the test or the statistics according to the typical subscription rate.
2) Perform the PDP activation test.
3) If PDP activation is successful, wait for 10 s, and then deactivate the PDP.
4) If PDP activation fails, wait for 30 s, and then activate the PDP again.
5) Make statistics of the counts of activation success and activation requests.

2) Display PDPActivationReq in geographical mode. Click in the map
PDP activation requests. Then display PDPActivationSuc in geographical
statistics of the total count A of PDP activation success. See Figure 1.
3) The PDP activation success ratio is (A/B) x 100%.
3.3.2.4 CS Call Drop Ratio (Return)

 Definition:

CS call drop ratio = count of service call drops/count of service connection x 100%
 Note:
Differentiate the CS call drop ratio for different services, such as voice, VP, and PS at
different rates.
Count of service call drops: In terms of air interface signaling recorded at the UE, if
any of the following messages is received on the air interface during the call (in the
connection state):
Unspecified.
The test is performed in an area of Ec/Io > -11 and RSCP > -90 dBm.
exceed the planned loads. The call drops caused by congestion is eliminated.
The call drops caused by non-access network problems or the handset is eliminated.
 Test method:
1) The called voice and VP are placed in an area with good signal coverage,
RSCP > -80dBm, and Ec/Io > -8 dB.
2) Set the call time of the handset to 90 s, and the waiting time after call
completion to 15 s.
3) If the call drop occurs, wait for 30 s, and then originate another call.
4) Make statistics of the counts of call completion and call drops.

service connection. Then display CallDropped in geographical mode. Click
in the map toolbar to open the legend window. Make statistics of the
total count A of CS call drops. See Figure 1.
3) The CS call drop ratio is (A/B) x 100%.
3.3.2.5 PS Call Drop Ratio (Return)

 Definition:
PS call drop ratio = count of PS service call drops/count of PDP activation success x
100%

 Note:
Differentiate the PS call drop ratio for different services, such as voice, VP, and PS at
different rates.
connection state):
Unspecified.
 Service: PS, and the rate is the planned full coverage rate
eliminated.
eliminated.
 Test method:
1) Perform the test or the statistics according to the planned full coverage rate.
2) Perform the PDP activation. If the activation is successful, add the count of
PDP activation success to 1.
3) Start the FTP to download. Perform deactivation after 90 s. If the call drop
occurs during download, add the count of PS call drops to 1.

2) Display PDPActivationSuc in geographical mode. Click in the map
toolbar to open the legend window. Make statistics of the count B of PDP
activation success. Then display CallDropped in geographical mode. Click
in the map toolbar to open the legend window. Make statistics of the
total count A of PS call drops. See Figure 1.
3) The PS call drop ratio is (A/B) x 100%.
3.3.2.6 Ratio of Relatively High Uplink BLERs (Return)

 Definition:
Ratio of relatively high uplink BLERs = number of points that the uplink BLER is
greater than the threshold/total number of uplink test points x 100%
 Note:
respectively.

 Test method:
1) Perform the call holding call for the voice or the VP service.
2) Make statistics of uplink BLERs in the RNC. Set the statistics interval to 1 s.

1) Trace the connection performance of the single user in the RNC (See Guide
to WCNMA Equipment Room).
2) Process the traced text data by Excel, and make statistics according to the
acceptance requirements. The number of points that the uplink BLER is
greater than the threshold is A, and the total number of uplink test points is
B. The signaling channel (No. 32) is beyond statistics. See Figure 1.
3) The ratio of relatively high uplink BLERs is (A/B) x 100%.
3.3.2.7 Ratio of Relatively High Downlink BLERs (Return)

 Definition:
Ratio of relatively high downlink BLERs = number of points that the downlink BLER is
greater than the threshold/total number of downlink test points x 100%
 Note:
respectively.
 Test method:
1) Make statistics after 5m geographical average.
2) The thresholds of the voice service and the VP service are 30% and 20%
respectively.

1) Import the UE and the scanner test data in the Assistant. Before import, set
Binning Type and Binning Param Distance of the Dataset property to
Distance Binning and 5 respectively. See Figure 2.
2) Determine the transport channel ID of the voice service (see Appendix 2 for
the method).
3) Display BLER for Transport Channel ID (The ID is a number from 0 to 5) in
table form. Export the table as an Excel file. Filter and make statistics of the
number A of points that the downlink BLER is greater than the threshold in
the Excel, and the total number B of downlink test points.
4) The ratio of relatively high downlink BLERs is (A/B) x 100%.
3.3.2.8 Objective Voice Evaluation (MOS) (Return)

 Definition: A test instrument measures the MOS.

 Note:
Generally, the voice quality is measured by the MOS.
The remarkable characteristics of the AMR voice:
 In the case of a certain load (corresponding to the CIR of the UE), the MOS felt by
users is not linearly increased with the increase of the voice rate used by the UE.
That is, in the case of a certain load, to obtain the maximum MOS, the most
appropriate AMR voice rate is not the maximum rate, but a proper intermediate
rate.
 The maximum Tx power of the UE restricts the coverage range of the uplink AMR
voice. To expand the uplink coverage range of the AMR voice, it is required to
properly reduce the uplink rate without affecting the call quality of the UE. The
curve that the voice quality MOS changes with the C/I is as the following figure:
 Service: The AMR is 12.2K.

 Fixed outside point or DT result
 The voice adopts 12.2K code.
 The Trfo function is enabled.
 The test is performed in the office.
 Test method 1:
1) Perform the DT on the specified route.
2) Adopt Psytechnics Artificial Speech Test Stimulus (ASTS) to obtain the
MOS.
3) The test result is the average MOS of 10 minutes or so.
 Test method 2:
When a handset calls another handset or a handset calls a fixed-line phone, input the
reference voice source (can be played by a PC or in other mode) in one terminal
(handset or fixed-line phone), and (use a digital recorder to) record signals that are
processed by the system in another terminal (handset or fixed-line phone). Process
original and processed signals through the PESQ software or the VQT instrument (in
offline mode), and output the MOS.

Advantage: simple and convenient operation, with strong operability. The analysis can
be performed in offline mode. The end-to-end voice quality of the system can be
obtained.
Disadvantage: This test method is greatly affected by the terminal. If the call is
between different networks, the test method is affected by the quality of other
network.
 Test method 3:
Replace a fixed-line telephone with the VQT tester, and access the tester to the
tested system through the PSTN. The VQT tester calls a fixed line phone. From the
handset (if it can loop back), BTS, BSC EVC or MSC to loop back to the VQT tester
towards the PSTN side. The VQT tester automatically provides the MOS test result.
Advantage: simple and convenient operation, with strong operability. This method can
perform the segmented VQT, to facilitate fault isolation and analysis.
Disadvantage: The test method is affected by the fixed network quality.
 Test method 4:
The BSC EVC board supports voice play and record (refer to the help file of the
commissioning console). This test method is similar to test method 2. The difference
is the test point. This function can be used to play the original voice on the EVC
through the commissioning console. The bi-directional play is supported, and you can
play the voice to the BTS side or to the MSC side. The original voice can be looped
back in the BTS or other places. The looped signals can be recorded on the EVC,
and be analyzed through the PESQ software or an instrument in offline mode.
Advantage: simple and convenient operation, with strong operability. This test method
can perform the segmented VQT, to facilitate fault isolation and analysis.
Disadvantage: This test method cannot fully reflect the voice quality of the system. It
can reflect the voice quality between the test point and the loop point.
3.3.2.9 Call Setup Delay (UE to UE/UE to PSTN) (Return)

 Definition:
Call setup delay = Average (T (CC_Alerting) – T (RRC Connection ReqUEst))
 Note:
The protocol stipulates that the UE can originate N300 RRC Connection ReqUEst
during one RRC setup. The time is counted from the first RRC Connection ReqUEst.
 Service: voice (UE to UE), voice (UE to PSTN), VP ringing (UE to UE)
Service Test Conditions
1) Static test, RSCP > -90 dBm,
EcIo > -11 dB.
2) The extra-long access delay
caused by non-network reason is eliminated.
Voice (UE to UE) 3) The test result is obtained
when the authentication is disabled. It may take 600 extra
ms when the authentication is enabled.
4) The test result is for RNC
V15. It may take one extra second for the test result of RNC
V13.


EcIo > -11 dB.
Voice (UE to 3) The test result is obtained
PSTN) when the authentication is disabled. It may take 700 extra
V13.
EcIo > -11 dB.
VP ringing (UE to 3) The test result is obtained
UE) when the authentication is disabled. It may take 700 extra
V13.
 Test method:
1) Place the calling or the called handset to an area with good signal
coverage. Connect the test equipment. Set the callee to automatic answer.
Both the caller and the callee are in the local office.
2) Disable the authentication.
3) Record the call message of the handset, namely, the time between the UE
sending the RRC Connection ReqUEst message and receiving the Alerting
message. If the peer ringing message cannot be heard, this call fails. This
delay is not counted.


1) Set the following items in the probe. Click Export to export the test report.
Figure 1 Export the test report in the probe
2) The call setup delay (UE to UE/UE to PSTN) is Average call setup time
delay. See the following figure:
Figure 1 Call setup delay (1) in the probe report
3.3.2.10 Call Setup Delay (PSTN to UE) (Return)

 Definition:
Call setup delay = Average (T (hear the ring back tone) – T (press the call number))
 Note:
Perform the test by using a stop-watch.
 Service: voice (PSTN to UE)


 Static test, RSCP > -90 dBm, and EcIo > -11 dB.
 The extra-long access delay caused by non-network reason is eliminated.
 The test result is obtained when the authentication is disabled. It may take
600 extra ms when the authentication is enabled.
 The test result is for RNC V15. It may take one extra second for the test
result of RNC V13.
 Test method:
1) Place the calling or the called handset to an area with good signal coverage.
Connect the test equipment. Both the caller and the callee are in the local
office.
2) Press the call key to count the time T0. The callee presses the receive key
after the first ringing, and records the required time T1. The caller records
the current time T2 when seeing the first frame of the image. T1-T0 is the
ringing time. T2-T0 is the time for seeing the image.
3) Repeat the test for at least 20 times. Obtain the average value of T2-T0.
3.3.2.11 Call Setup Delay (PS) (Return)

 Definition:
Call setup delay = Average (T (Activate PDP Context Accept) – T (RRC Connection
ReqUEst))
 Note:
The protocol stipulates that the UE can originate N300 RRC Connection ReqUEst
during one RRC setup. The time is counted from the first RRC Connection ReqUEst.
 Service: PS
 Static test, RSCP > -90 dBm, and EcIo > -11dB.
 The extra-long access delay caused by non-network reason (such as
handset fault) is eliminated.
 The test result is obtained when the authentication is disabled. It may take
1200 extra ms when the authentication is enabled.
 The test result is for RNC V15.
 Test method:
1) The caller and the callee do not enable the authentication and encryption
during a call.
equipment.
3) Start the PDP activation test. Record the time that the handset sends the
PDP Activation ReqUEst message and the time that the handset receives
the PDP Activation Accept message from the network. The difference of the
two time is the PDP activation delay.
4) Repeat the test for at least 20 times. Count the average values respectively.

1) Set the following items in the probe. Click Export to export the test report.
See Figure 1.
2) The call setup delay (PS) is Average DataService setup time delay. See the
following figure:

Figure 1 Call setup delay (2) in the probe report
3.3.2.12 RTD Delay of Ping Packet (Return)

 Definition: the time between sending the ping request and receiving the
response.
 Service: DCH: ping 20byte, DCH: ping 100byte, DCH: ping 500byte
 Static test, RSCP > -90 dBm, and EcIo > -11 dB.
 The extra-long access delay caused by non-network reason is eliminated.
 The server directly connected with the GGSN is pinged.
 During the ping delay test, no other application program periodically sends
packets in the portal computer.
 The test is performed in the case of enabling the DCCC algorithm.
 During the ping delay test, no other application program periodically sends
packets in the portal computer.
 Test method:
Repeat the test for at least 100 times. Obtain the average value.
1) Connect the hardware equipment well. Huawei U626 handset serves as the
modem.
Open Main Menu -> Data Connection-> Data Account in turn. Check the
IP address of the data account, to ensure that the APN (name of the access
point) is set accurately. For example, the APN of the Monternet of China
Mobile is cmwap.
2) Create a new connection in the PC, and select Connect to the Internet ->
Set up my connection manually -> Connect using a dial-up modem -> At the
telephone number enter *99# in turn.
3) Perform the PING test by using the CMD tool after successful connection.
 Enter the following command:
-L packet size: define the size of the data packet. Unit: byte. The size of
the packet in the figure is 100 byte.
-N count: define the count of ping. The count in the figure is 10.
IP address: enter the target IP address. Such as 10.161.144.100 in the
figure.
> File name. format: define the name and format of the test file. The file
name in the figure is pingtest, and the format is .xls.
Figure 1 Description diagram for using the CMD tool

 View the test result: enter the command “type file name. format”. Enter
type pingtest.xls in the figure, and read that the RTD delay of ping
packet is Average.
Figure 2 Reading the delay of ping packet
3.3.2.13 Service Interruption Delay (Return)

 Definition: the interruption time of user plane voice, image, or data transfer
during the hard handover, or the inter-system handover.
 Service: intra-frequency hard handover, inter-frequency hard handover, inter-
system handover (CS), inter-system handover (PS)
Service Test Conditions
Intra-frequency
hard handover
Inter-frequency
hard handover
Inter-system 3G-to-2G handover: 2G ReLex RSCP > -85 dBm,

handover (CS) 2G-to-3G handover: 3G RSCP > -90 dBm, EcIo>-11 dB
Inter-system
handover (PS)
 Test method:
1) The interruption delay of the voice or the image is tested through special
instruments.
2) The interruption time of the PS data transfer can be analyzed through the
packet grasping tool or in ping packet mode.
 Detailed statistics procedure (by ping packets)
1) Activate the PS UL 64K/DL 64K service in the WCDMA coverage area.
Perform the ping [“target IP address” -1 packet size –n count] test. See
Figure 1.
2) Move the handset in the handover area to trigger the handover.

3) Observe ping failure and recovery, and record the time of first failure and the
time of first recovery. The difference of them is the interruption time. The
statistics in the Assistant is as the following figure:
4) Repeat the test for at least 20 times. Obtain the average value of the
interruption time.
3.3.2.14 MBMS-on-demand success ratio (Return)

MBMS-on-demand success ratio = Number of MBMS-on-demand successes/total
number of MBMS-on-demands x 100%
Number of MBMS-on-demand successes: The UE is in the buffering state for no more
than one minute after the user presses a key to start MBMS-on-demand.
Total number of MBMS-on-demands: Total number of MBMS-on-demands originated
by the UE
 Test method:
After pressing a key to start MBMS-on-demand, use the QXDM to observe the time
when the UE is in the buffering state. If the buffering state ends and the UE receives a
data frame within one minute, the MBMS-on-demand is successful. Otherwise, it has
failed.
3.3.2.15 MBMS-on-demand delay (Return)

Time from when the user presses a key to start the MBMS-on-demand to when a
picture is played
 Test method:
Use a stopwatch to conduct the test. Start the watch when you press the key to start
MBMS-on-demand and stop the watch when a picture appears.
3.4 RAN Traffic Statistics Acceptance

For the collection methods of traffic statistics data, refer to Guide to WCDMA
Equipment Room.

3.4.1 Traffic Statistics Acceptance Indexes

Table 1 Traffic statistics acceptance indexes
Soft handover overhead Soft Handover Overhead (Return)

Coverage Ratio of uplink Ratio of Uplink Interference Cell
interference cells (Return)
RRC setup success ratio RRC Setup Success Ratio (Return)
RAB setup success ratio RAB Setup Success Ratio (Return)

Access
MBMS setup success MBMS setup success ratio on Iu
ratio on Iu interface interface
Retainability Call drop ratio Call Drop Ratio (Return)
Throughput of downlink Downlink Peak Throughput

peak value (Return)
Service integrity Average downspeeding Average Downspeeding Count
count based on Based on Coverage (Return)
coverage
Soft handover success Soft Handover Success Ratio

ratio (Return)
Inter-System Handover Success

Ratio (Outgoing Voice Handover)
Inter-system handover (Return)
success ratio Inter-System Handover Success
Mobility
Ratio (Outgoing PS Handover)
(Return)
HSDPA handover HSDPA Handover Success Ratio

success ratio (Return)
HSUPA handover
HSUPA handover success ratio
success ratio
Worst cell ratio Worst Cell Ratio (Return)
Admission rejection ratio Admission Rejection Ratio (Return)
Paging congestion ratio Paging Congestion Ratio (Return)
Availability Congestion cell ratio Congestion Cell Ratio (Return)
Downlink transmission Utilization Ratio of Downlink

resource utilization Transmission Resources (Return)
Uplink transmission Utilization Ratio of Uplink

resource utilization Transmission Resources (Return)

For a predefined area, the traffic statistics index acceptance refers to acceptance and
evaluation for each traffic statistics index according to the corresponding acceptance
standard.
During the acceptance standard preparation, the indexes to be evaluated by this
acceptance should be consistent. In addition, different networks have different
definition modes for the same index. Therefore, the definitions of traffic statistics
indexes should be consistent.
In the course of acceptance standard preparation, refer to each traffic statistics index
value of the previous network, and reasonably evaluate the effect after the network is
ready; based on the consistence of evaluation indexes and each index definition,
prepare the corresponding acceptance standard through sufficient communication
and negotiation, and thus to ensure that the network can smoothly pass the
acceptance. In addition, to ensure the smooth acceptance, it is recommended to
divide areas according to actual geographical conditions, and work out different
standards according to different areas.
The traffic statistics indexes may be involved in the network acceptance include:
 Coverage: soft handover overhead, uplink interference cell ratio
 Access: RRC setup success ratio, RAB setup success ratio
 Service integrity: throughput of downlink peak value, average downspeeding
count based on coverage.
 Mobility: cell update success ratio, soft handover success ratio, inter-system
handover success ratio, soft handover between H and H, soft handover between
H and R, intra-frequency hard handover between H and R, inter-frequency hard
handover between H and R, H-to-2G handover.
 Availability: Worst cell ratio, admission rejection ratio, paging congestion ratio,
congestion cell ratio, utilization ratio of downlink transmission resources,
utilization ratio of uplink transmission resources.
3.4.2 Definitions and Statistics of Traffic Statistics Acceptance Indexes
3.4.2.1 Soft Handover Overhead (Return)

 Definition:
Soft handover overhead = {(ACTIVESET_1_UE_MEAN +
ACTIVESET_2_2SOFTER_UE_MEAN x 2 + ACTIVESET_2_2SOFT_UE_MEAN x 2
+ ACTIVESET_3_3SOFTER_UE_MEAN x 3 + ACTIVESET_3_3SOFT_UE_MEAN x
3 + ACTIVESET_3_2SOFTER_UE_MEAN x3)/(ACTIVESET_1_UE_MEAN +
ACTIVESET_2_2SOFTER_UE_MEAN + ACTIVESET_2_2SOFT_UE_MEAN +
ACTIVESET_3_3SOFTER_UE_MEAN + ACTIVESET_3_3SOFT_UE_MEAN +
ACTIVESET_3_2SOFTER_UE_MEAN)} -1

 Note:
 ACTIVESET_1_UE_MEAN: average count of UE that owns one radio link.
 ACTIVESET_2_2SOFTER_UE_MEAN: average count of UE that owns two
merged radio links.
 ACTIVESET_2_2SOFT_UE_MEAN: average count of UE that owns two
unmerged radio links.
 ACTIVESET_3_3SOFTER_UE_MEAN: average count of UE that owns three
merged radio links.
 ACTIVESET_3_3SOFT_UE_MEAN: average count of UE that owns three
unmerged radio links.
 ACTIVESET_3_2SOFTER_UE_MEAN: average count of UE that owns three radio
links in which two links are merged.
 Service: N/A
 Impact factor and deviation suggestion:
 Detailed statistics method: soft handover overhead = VS. SHO. Factor. RL. See
the following figure:
Soft handover Soft handover

Average ratio based on
number of ratio based on IUB
cell resource transmission
service RAB resource
allocation allocation
Figure 1 Soft handover overhead
3.4.2.2 Ratio of Uplink Interference Cell (Return)

 Definition:
Calculate all data in a day. If the average RTWP value of a cell in half an hour
exceeds -98 dBm, the cell is defined as an interference cell, and add the sum of
interference cells to 1.
The number of cells that the average value of total bandwidth power received in half
an hour exceeds -98 dBm/total cell number x 100%
 Service: N/A
 For engineering installation and network planning
 For a dense urban area, the ratio can be slightly flexible.

 Detailed statistics method: ratio of uplink interference cell is VS.

MeanRTWP/total cell number x 100%. See the following figure:
Average Maximum
RTWP RTWP
Figure 1 Uplink interference
3.4.2.3 RRC Setup Success Ratio (Return)

 Definition:
RRC setup success ratio = count of RRC connection setup success/count of RRC
connection requests received by the RNC x 100%
 Note:
The count of RRC connection requests refers to the number of service requests
originated. RRC connection setup success indicates that the RNC receives the RRC
setup complete message from the UE.
 Service: N/A
 Make statistics of the RRC setup success ratio based on the originated
service only.
 Exclude the success ratio index of cells at the coverage edge of 3G
network.
 Eliminate RRC setup failure caused by network congestion.
 Detailed statistics method: RRC setup success ratio = 1-VS. RRC.
FailConnEstab. Cell. Rate. See the following figure:

Count of RRC Count of RRC Failure ratio

connection connection of RRC
setup failure setup connection
requests setup
Figure 1 Failure ratio of RRC setup
3.4.2.4 RAB Setup Success Ratio (Return)

 Definition:
RAB setup success ratio = count of RB setup complete message of the CS, the PS or
the HSDPA service received from the UE/count of RAB assignment requests of the
CS, the PS or the HSDPA service sent by the CN x 100%
 Service: voice/VP/PS/HSDPA
 Exclude the success ratio index of cells at the coverage edge of 3G
network.
 Eliminate RAB setup failure caused by network congestion.
 Detailed statistics method:
CS RAB setup success ratio = 1-VS. RAB. FailEstabCS. Rate. Cell. See the following
figure:
Count of CS Count of CS Failure

RAB setup RAB setup ratio of CS
failure requests RAB setup
Figure 1 CS RAB setup failure ratio

PS RAB setup success ratio = 1-VS. RAB. FailEstabPS. Rate. Cell. See the following
figure:
Count of PS Count of PS Failure

RAB setup RAB setup ratio of PS
failure requests RAB setup
Figure 2 CS RAB setup failure ratio
3.4.2.5 Call Drop Ratio (Return)

 Definition:
CS call drop ratio = count of CS service releases originated by the RNC/count of CS
service setup success
PS call drop ratio = count of PS service releases originated by the RNC/count of PS
service setup success
HSDPA call drop ratio = count of HSDPA service releases originated by the
RNC/count of HSDPA service setup success
 Service: voice/VP/PS/HSDPA
 Eliminate equipment faults.
 Eliminate too high loads.
CS AMR call drop ratio = VS. CS. AMR. Call. Drop. Rate. Cell
Count of CS Count of CS CS AMR

AMR call AMR setup call drop
drops success ratio
Figure 1 CS AMR call drop ratio

CS VP call drop ratio = VS. CS. VP. Call. Drop. Rate, Cell. See the following figure:
Count of CS Count of CS CS VP call

VP call VP setup drop ratio
drops success
Figure 2 CS VP call drop ratio
PS call drop ratio = VS. PS. Call. Drop. Rate. Cell. See the following figure:
Count of PS Count of PS PS call drop

call drops RAB setup ratio
success
Figure 3 PS call drop ratio
3.4.2.6 Downlink Peak Throughput (Return)

 Definition: data traffic downloaded in one minute
 Service: PS UL 64K/DL 64K, PS UL 64K/DL 128K, PS UL 64K/DL 384K.
 Analyze the maximum rate of the cell user in a good condition through traffic
statistics. If peak rates of certain cells are lower than other cells, the data
service performances of these cells may have problems, and are required to
be further optimized.
 Set the BLER target value to 1%.
 Make statistics of the RLC rates, and deduct the throughput change caused
by retransmission.
Downlink peak throughput = DL. Throughput(RLC). Kbps. Rate. See the following
figure:

Downlink RLC Uplink RLC

average average
throughput of throughput of
the cell (kbit/s) the cell (kbit/s)
Figure 1 Downlink peak throughput
3.4.2.7 Average Downspeeding Count Based on Coverage (Return)

 Definition:
Average downspeeding count based on coverage = sum of coverage-based
downspeeding counts of RABs with different maximum downlink bit rates in the PS
domain of a cell/count of RAB assignment request set success of maximum downlink
bit rate with different PS domain in a cell
 Service: PS
The index is related to the detailed coverage, and is used to guide the optimization of
data service.
Average downspeeding count based on coverage = VS. DCCC. D2D.
SuccRateDown. UE/(VS. RRC. AttConnEstab. Cell – VS. RRC. FailConnEstab. Cell)
Count of dynamic
channel
RB configuration
reconfiguration success for
dedicated
count channels with
the decreased
downlink rate
Figure 1 Count of dynamic channel configuration success for dedicated channels

with the decreased uplink rate

3.4.2.8 Soft Handover Success Ratio (Return)

 Definition:
Soft handover success ratio = count of soft handover success/count of soft handover
decision
 Note:
 Count of soft handover success: the number of the Activeset Update Complete
messages from the UE received by the RNC.
 Count of soft handover decision: the number of the Activeset Update messages
sent to the UE by the RNC.
 Service: CS & PS
Soft handover success ratio = 1-VS. SHOSoHO. Fail. Cell. Rate. See the following
figure:
Count of soft/ Count of soft/ Soft/softer

softer handover softer handover handover
failure execution failure ratio
Figure 1 Soft/softer handover failure ratio
3.4.2.9 Inter-System Handover Success Ratio (Outgoing Voice Handover) (Return)

 Definition:
Success ratio of outgoing CS inter-system handover = count of outgoing CS inter-
system handover success/count of outgoing CS inter-system handover attempts x
100%

 Note:
 Count of outgoing CS inter-system handover attempts: the number of the
RELOCATION REQUIRED messages sent by the RNC to the CN.
 Count of outgoing CS inter-system handover success: the count when the RNC
receives the IU RELEASE COMMAND message, and the cause value of the
message is Successful Relocation or Normal Release during the outgoing CS
inter-system handover..
 Service: outgoing voice handover


Success ratio of outgoing CS inter-system handover = 1-VS. IRATHO. FailCSOut.
RNC. Rate. See the following figure:
Count of
Count of outgoing CS Failure ratio of
outgoing CS inter-system outgoing CS
inter-system handover inter-system
handover failure attempts handover
Figure 1 Failure ratio of outgoing CS inter-system handover
3.4.2.10 Inter-System Handover Success Ratio (Outgoing PS Handover) (Return)

 Definition:
Success ratio of outgoing PS inter-system handover = count of outgoing PS inter-
system handover success/count of outgoing PS inter-system handover execution
 Note:
 Count of outgoing PS inter-system handover execution: the number of the CELL
CHANGE ORDER FROM UTRAN messages sent to the UE by the RNC.
 Count of outgoing PS inter-system handover success: the number of the IU
RELEASE COMMAND messages, received by the RNC, where the cause value is
Successful Relocation or Normal Release.
 Service: outgoing PS handover



Success ratio of outgoing PS inter-system handover is 1-VS. IRATHO.
FailPSOutUTRAN. RNC. Rate. See the following figure:
Count of
Count of outgoing CS Failure ratio of
outgoing CS inter-system outgoing CS
inter-system handover inter-system
handover failure attempts handover
Figure 1 Failure ratio of outgoing PS inter-system handover originated by the RNC
3.4.2.11 Worst Cell Ratio (Return)

 Definition:
Worst cell ratio = number of cells that the traffic of the voice and the VP services is
greater than 0.1 erl, and the call drop ratio is greater than 3% or the call completion
rate is less than 95%/number of cells that the traffic of the voice and the VP services
is less than 0.1 erl.
 Service: all services
Sum of the traffic of the voice and the VP services
3.4.2.12 Admission Rejection Ratio (Return)
 Definition:
Admission rejection ratio = count of the rejected uplink or downlink cell resource
requests/total count of resource requests
 The reasons for rejecting resource requests include that CE resources,
code resources, power resources, and transmission resources are not
enough.
 Make statistics of uplink and downlink cell resource requests separately.
Admission rejection ratio = VS. RAC. NoAdm/ CELL_DCH_APPLY

Count of
rejections due
to admission
failure
Figure 1 Count of rejections due to admission failure
3.4.2.13 Paging Congestion Ratio (Return)

 Definition:
Paging congestion ratio = count of paging discard caused by PCH channel
congestion/total paging counts
Paging congestion ratio = VS. RRC. Paging1. Loss. PCHCong. Cell. Rate
Count of paging Count of type Ratio of paging

loss caused by 1 paging sent loss caused by
PCH channel by the cell PCH channel
congestion of the congestion
cell
Figure 1 Paging loss ratio caused by PCH channel congestion
3.4.2.14 Congestion Cell Ratio (Return)

 Definition:
Congestion cell ratio = total numbers of busy hour uplink or downlink congestion
cells/total cell numbers

3.4.2.15 Utilization Ratio of Downlink Transmission Resources (Return)

 Definition:
Utilization ratio of downlink transmission resources = current allocated transmission
resources for the downlink Iub interface/current configured downlink transmission
bandwidth
If the utilization ratio of downlink transmission resources exceeds 95%, the admission
can be rejected. You need to make statistics of the busy hour data.
3.4.2.16 Utilization Ratio of Uplink Transmission Resources (Return)

 Definition:
Utilization ratio of uplink transmission resources = current allocated transmission
resources for the uplink Iub interface/current configured uplink transmission
bandwidth
If the utilization ratio of uplink transmission resources exceeds 95%, the admission
can be rejected. You need to make statistics of the busy hour data.
3.4.2.17 HSDPA Handover Success Ratio (Return)

 Definition:
Success ratio of intra-frequency service cell update between Hs = count of service
cell update success in a cell/count of service cell update attempts in a cell
Success ratio of inter-frequency service cell update between Hs = count of successful
outgoing inter-frequency hard handover between HS-DSCHs in a cell/count of
requested outgoing inter-frequency hard handover between HS-DSCHs in a cell
Success ratio of update of intra-frequency handover between H and R99 = (count of
handover success from a HS-DSCH to a DCH in a cell + count of handover success
from a DCH to a HS-DSCH in a cell)/(count of handover attempts from a HS-DSCH to
a DCH in a cell + count of handover attempts from a DCH to a HS-DSCH in a cell)
Success ratio of update of inter-frequency handover between H and R99: Due to the
realization of the RNC algorithm, the index is to be supplemented later.
H-to-GPRS handover update success ratio: The index is to be supplemented later.
 Service: HSDPA
3.4.2.18 HSUPA handover success ratio (Return)

Index definition:
1) Soft handover success ratio between HSUPA cells (including addition, substitution,
and deletion) = number of added/deleted EDCH links owing to successful soft
handovers in a cell/number of EDCH links to be added/deleted by soft handover
requests in the cell
2) Update success ratio of the serving cell involved in a soft handover between
HSUPA cells = number of EDCH serving link update successes owing to a soft
handover or multiple links in a cell/number of times the EDCH serving link is
requested to update owing to a soft handover or multiple links

3) Reconfiguration success ratio from DCH to E-DCH in a cell (including

reconfigurations caused by a soft handover, intra-frequency hard handover, or inter-
frequency hard handover) = number of successful handovers from DCH to E-
DCH/number of attempts to hand over from DCH to E-DCH
4) Reconfiguration success ratio from E-DCH to DCH in a cell (including addition and
substitution) = number of successful handovers from E-DCH to DCH in the soft
handover state/number of attempts to hand over from E-DCH to DCH
5) Update success ratio of the serving cell involved in an intra-frequency hard
handover between HSUPA cells = number of update successes of the serving cell
involved in an intra-frequency hard handover between HSUPA cells/number of
serving cell update attempts
6) Success ratio of intra-frequency hard handovers from E-DCH in an HSUPA cell to
DCH in a non-HSUPA cell = number of successful intra-frequency hard handovers
from E-DCH to DCH/number of attempts to hand over from E-DCH to DCH
7) Update success ratio of the serving cell involved in an inter-frequency hard
handover between HSUPA cells = number of update successes of the serving cell
involved in an inter-frequency hard handover between HSUPA cells/number of
serving cell update attempts
8) Success ratio of inter-frequency hard handovers from an HSUPA cell to a non-
HSUPA cell = number of successful inter-frequency hard handovers from E-DCH to
DCH/number of attempts to hand over from E-DCH to DCH
Service: HSUPA
Suggestions on the influential factors and deviations:
1) Remove all device faults.
2) Remove overload.
3.4.2.19 MBMS setup success ratio on Iu interface (Return)

Index definition:
MBMS setup success ratio on Iu interface = number of MBMS setup successes on Iu
interface/number of MBMS setup attempts on Iu interface
Service: MBMS
Suggestions on the influential factors and deviations:
1) Remove all device faults.
2) Remove overload.

4 UMTS radio network benchmark test

A benchmark test is a competitive test. For a UMTS network, a benchmark test
includes two types. The first type is a competitive test of a network between pre-
swapping and post-swapping, and the other type is a competitive test of the same
standard between different network operators.
4.1 Objective of a benchmark test

 Benchmark test oriented to network swapping
The objective of a benchmark test oriented to network swapping is to observe the
change of signal coverage (RSCP and Ec/Io) after network swapping, analyze
whether the KPIs of are improved, and even make a comparative analysis of the
mean opinion score (MOS) for some networks.
Generally, a benchmark test requires that the number of sites after swapping should
be approximately similar to the number of sites before swapping. If there is a great
difference in the number of sites, there is no point in conducting a benchmark test.
Some sites in a network are not swapped for various reasons. Before a benchmark
test, the test area and test route need to be designed reasonably to mitigate the
effects of the sites that are not swapped.
 Benchmark test for network quality comparison between different network

operators
A benchmark test for network quality comparison between different network operators
mainly involves two levels. The primary level includes signal coverage quality (RSCP
and Ec/Io), network KPIs, and QoS. The advanced level analyzes and compares the
network planning (including scrambling code planning, interference control, power
distribution rate planning, location area planning, and channel Nos. planning) and
algorithm parameters between different network operators. Through the comparison
and analysis of the similarities and differences of processes and parameters of
different manufacturers, you can have an in-depth understanding of the
characteristics of the radio performance and better utilize the planning and
optimization fruits in the industry to improve the network performance.
4.2 Test contents of a benchmark test

The test contents of a benchmark test depend on its objective. Test contents should
be reasonably selected or organized for each benchmark test according to the test
objective and the customer requirements. The common test contents include the
following parts:
Signal coverage quality test: Use a scanner and GPS to capture radio signals.
Analyze the signal coverage quality (RSCP and Ec/Io) between pre-swapping and
post-swapping scenarios, and between different network operators.
Radio network KPI test: Compare and analyze the network KPIs (including call setup
success rate, PDP activation success rate, CS call drop rate, PS call drop rate, PS
throughput, and soft handover) between pre-swapping and post-swapping, and
between different network operators. With the service development, test contents, for
example, HSUPA throughput and MBMS, may be added accordingly.

MOS test: By means of a special MOS measurement tool, evaluate the pre-swapping
and post-swapping MOS of the voice service as well as the MOS of the voice service
of different network operators.
Service capability test: Compare and analyze the pre-swapping and post-swapping
bearer capability of the 3G service as well as that of the 3G service of different
network operators.
Study test of the planning and optimization parameters: This test is mainly used for a
benchmark test between different network operators. Through the analysis of pilot
signals, system information, or Layer 3 signaling, studies the setting of planning and
optimization parameters of different network operators.
4.3 Preparation for a benchmark test

The specific execution procedure for a benchmark test is similar to the test execution
at other phases of network optimization. For details, see the previous chapters in this
guide. At the test preparation phase, different types of benchmark tests have different
concerns.
 Benchmark test oriented to network swapping
Formulate test cases according to the network analysis requirements and the
customer requirements. Test cases usually involve the test of signal coverage quality
and network KPIs. For test cases, see the previous chapters in this guide.
Preparation of test tools and test vehicle: It is similar to that for other phases of the
network optimization. For details, see the previous chapters in this guide.
Selection of test area and test route: Ensure that the number of sites, test area, and
test route after swapping are consistent with those before swapping. In areas where
sites are not swapped, a reasonable test route should be designed to mitigate the
effects of these sites. Therefore, the site information should be fully obtained at the
test preparation phase.
Arrangement of test time: A benchmark test should ensure the comparability of the
test time. It is not allowed to conduct the test in workdays before swapping, but in
weekends after swapping.
Consideration of the traffic model: If the number of users increases greatly or the
traffic model changes significantly because the customer adjusts the tariff policy after
swapping, a benchmark test has no comparability. The KPI deterioration caused by
this should be pointed out to the customer.
 Benchmark test for network quality comparison between different network

operators
Prepare test cases according to the test requirements. If you want to compare and
analyze the service bearer capabilities (such as HSUPA, MBMS, multi-service bearer,
and HSPA handover between Iur interfaces) of different network operators, you
should design test cases according to the requirements. If you want analyze the
algorithm parameters of different manufacturers, you should design test cases to
capture system information or Layer 3 messages.
Preparation of test tools, test terminal, and test vehicle: Benchmark tests for new
services may be involved. Therefore, you need to prepare new types of terminals
accordingly. During a benchmark test, ensure the consistency between the test
terminals and the test tools as much as possible.
Selection of the test area and test route: Obtain the number of sites of different
network operators. If the quantities of sites in the test area are quite different, the

product performance evaluation of different manufacturers based on the signal quality

and the network KPIs are not objective.
Arrangement of test time: Ensure that tests are performed in the same time segment.
4.4 Method of benchmark test

For common methods, see the previous chapters (drive test, network optimization
test, and network KPI acceptance test). Besides, ensure the following consistencies.
 Consistency of the test area, test route, and driving direction.
 Consistency of test tools, test terminal, and test measurement: Use the same set
of test devices, including the same test software, software version, computer,
and handset. Use the same test vehicle or the same type of vehicle. For
example, you should not first use a dual-row car and later a vehicle with a high
trunk such as a Pickup car. Otherwise, the test results may cause unexpected
aftermaths.
 Consistency of the position of the test terminal: If the mobile handset is equipped
with an external antenna during tests, ensure that the position of the antenna is
the same and hold the mobile handset steadily. If no external antenna is used
and the mobile handset is put in the vehicle, the position of the mobile handset is
strictly controlled. It is recommended that you place the mobile handset on the
handset-fixing slot in the test box and fasten the test box, or fasten the mobile
handset to the platform in front of the co-driver seat or the co-driver seat. Ensure
that the mobile handset direction and the antenna angle are consistent during
tests. Note: Do not place the mobile handset horizontally. Place it vertically to
agree with the actual condition.
 Consistency of test samples, including number of tests, number of calls, and
vehicle speed in the test area or along test route: Ensure that the test samples
consistent as much as possible.
 Consistency of test time: Ensure that the traffic models for two tests in the test
time are equivalent and have the comparability. You must not conduct one test in
workdays and the other test on weekends or holidays.

5 Summary
Based on the GENEX Probe software platform, the guide presents an overall
introduction to the test tasks of each WCDMA network optimization phase from the
aspects of test conditions, test methods, statistics methods, and precautions. In
addition, for your reference, this guide collects typical cases related to the test from
Collection of Answers to Questions and Case Collection of the UMTS Network
Planning Department since 2004.
In comparison with WCDMA Special Guide Drive Test, this guide focuses on the
operability and practicality on the basis of fractionalized test tasks of each network
optimization phase. This guide highlights descriptions of each index meaning, test
conditions, test methods, and statistics methods in the network acceptance phase.
This guide includes test contents of inter-frequency, and inter-system handover.
Guide to WCDMA Test V3.1 adds the HSDPA contents based on Guide to WCDMA
Test V3.0. The part of preparation before DT test adds the contents of vehicle power
supply, test equipment selection, and version, adds the HSDPA test items, modifies
the explanation of HSDPA window parameters, and adds R99 and HSDPA test cases.
For the standard and method of HSDPA network acceptance, the DT verification
indexes and test statistics methods of the HSDPA are added. The HSDPA traffic
statistics is under improvement for the current RNC version.
Guide to WCDMA Test 3.2 The contents about the HSUPA are added in the guide on
the basis of section 3.1. The HSUPA test requires Probe 1.4 or a later version.
Guide to WCDMA Test 3.4 The contents about benchmark tests are added in the
guide. Since the HSUPA was put into commercial operation recently, few test cases
about the HSUPA are available and need to be supplemented in future
I hope you will find this guide both informative and entertaining. If you have
suggestions on how to make it better, please let us know. In addition, if you have
different test methods or statistics methods for test items mentioned in this guide,
please let us know.

6 Appendix
6.1 Method for Setting APN and QoS with Modem Initiation
Command
1) Open the Control Panel, and select Telephone and Modem options.
2) Select a corresponding modem from the Modem menu.

3) After selecting the corresponding modem, click Properties, to access the

Advanced menu.
Enter at+cgdcont=1, "IP","cmwap";+cgeqreq = 1, 3, 64, 128 in the Additional

Initialization Command box.
Additional initialization command description: at+cgdcont=1, "IP", "cmwap" is used to
set the APN address. Thus it is not required to set the APN in the handset.
cgeqreq=1, 3, 64, 128 is used to set the service type and the applied uplink and
downlink rates, in which 3 indicates the interaction service, 64 indicates that the
applied uplink service rate is 64K, and 128 indicates the applied downlink service rate
is 128K.
6.2 BLER Analysis Method in the Assistant

6.2.1 Problem Description
During network optimization, you usually need to make statistics of BLERs of the XX
service. But the UE reports BLERs of multiple transport channels. The BLER
information of multiple transport channels is displayed in the Assistant. Most of
BLERs are irrespective of the tested service. You need not to analyze them during
statistics and graphic display. You need to make statistics of BLERs of the XX service
only.


6.2.2 Analysis Method

The method for determining the transport channel ID of the XX service is as follows:
1) Double-click L3 Message in the project navigation tree. The L3 signaling window
appears. Double-click the Radio Bearer Setup message in the L3 signaling
window.

2) View the details of the Radio Bearer Setup message, and focus on the DL
AddReconfTransChInformation part.

3) Check the downlink transport channel ID (dl transportChannelIdentity), and

check the corresponding BLER target value (bler QualityValue) in the DL
AddReconfTransChInformation list. Judge whether the transport channel is the
one of the service to be focused on.
Transport channel ID = 1

4) Analyze the BLER of the queried transport channel ID.
6.2.3 Experience Summary
1) You can obtain the transport channel ID by finding the RB Setup signaling. The
transport channel ID of a certain service remains unchanged during the test.
2) Some of BLERs of other multiple transport channels are BLERs of the signaling
DCH (For example, the transport channel ID is 32), or BLERs of the signaling
FACH. The BLERs are bad in general.
3) If the test service changes, you need to check the RB Setup message again. In
general, the IDs of the voice/VP transport channel, the PS transport channel, and
the signaling transport channel are 1, 21, and 32 respectively.
4) The method that identifies the service type of a transport channel can be used to
check the transport format. The difference of different services is as follows:
 Signaling: BLER = 1%, with CRC check, 1/3 convolutional code.
 Language: includes three sub-basic flows. For A sub-basic flow, BLER =
1%, with CRC check, 1/3 convolutional code. For B sub-basic flow, no CRC
check, 1/3 convolutional code. For C sub-basic flow, no CRC check, 1/2
convolutional code.
 VP: BLER = 0.2%, with CRC check, 1/3 convolutional code.
 PS: BLER = 1%, 5%, 6%, or 10%, with CRC check, 1/3 Turbo code.

6.3 Manual Dialup Methods

6.3.1 Dialup Method of E620 Data Card
6.3.1.1 Dialup with the Background Software

1) Set the APN in the background software.
After the background software is started, click in the main interface. The Data
Connection tab appears. Click New to edit the APN. Enter the number, user name,
and password. Click Save, and then click OK.
Figure 1 APN setting of the data card E620
2) Click in the main interface of the background software to dial.
6.3.1.2 Dialup with New Dialing Connection

Create a connection in Start -> All Programs -> Accessories -> Communications
-> Network Connection of the Windows. Select HUAWEI Mobile Conect-3G
Modem as the modem, and dial HUAWEI Mobile Conect-3G Modem directly.

Figure 1 Method (2) of the UE performing PS service dialing automatically
6.3.2 Dialup Method of the Test Handset
The dialup method is the same as that of creating network connection. Refer to
section 6.3.1.2.
6.4 Condition of PS Service Over HSDPA

1) For the UE, there is no much difference to originate the HSDPA data service or
the R99 PS service. Whether a data service is transferred on the R99 or HSDPA
depends on the decision at the RAN side.
2) The related factors are as follows.
3) Whether the cell supports the HSDPA feature and the HSDPA feature is activated
4) Type and request rate of the data service originated by the user
5) User (USIM card) subscription rate
6) Minimum rate threshold for transferring BE service on the HSDPA configured by
the RNC
If the cell supports the HSDPA feature, the requested service type is BE, and the Min
value (this request rate and subscription rate) exceeds the minimum rate threshold of
the HSDPA configured by RNC, the data service is transferred on HSDPA.
Whether the cell supports HSDPA can be queried by using LST CELLHSDPA, and
activated by using ACT CELLHSDPA.
If the automatic dialing uses Test Plan of the Probe, the service type and the
requested rate are the settings of QoS in the test items of PS Dialup, FTP Download,
or PDP. If the setting is null, the service type and the requested rate are the
subscribed service type and rate of the HLR.
Ask the engineer at the CN side to query the subscription rate of the user (USIM card)
if necessary.
For the lowest HSDPA rate threshold configured by the RNC, refer to Guide to
WCDMA Parameter Configuration.

6.5 Common Windows and Corresponding Logmask

The corresponding Logmask items of packets used by common windows are as
follows:
Table 1 Common windows and the corresponding packets
Application
Window Logmask Item Main Parameter
Scenario
Scramble list of the

Active set R99, HSDPA
active set
Service/
Scramble list of the
Active set& Neighbor Set R99, HSDPA
neighbor set
Neighbor
cell RSCP and Ec/Io
List Search measurement values of R99, HSDPA
each scramble
Layer 1
AGC Rx, Tx Power R99, HSDPA
Power The R99 test is

L1_Power_contro
Control mandatory;
l_with_compress SIR, TPC
The HSDPA
ed_mode
test is optional.
Block error rate of each Downlink

WCDMA
BLER downlink transport BLERs of R99
BLER
channel and A-DCH
Layer 1
HSDPA configura
HSDPA
tion
HSDPA
Channel configuration
Physical
parameter
Channel
Layer 2
MAC HS
HSDPA
configuration
Rate of the MAC layer,

HSDPA Link HS decode
scheduling success ratio, HSDPA
Statistic status with data
Layer 1
and CQI
HSDPA Decoding statistics: size

UL hs-dpcch
Decoding of the transport block, HSDPA
debug
Statistic modulation mode
Scramble of ADCH
Active Set, List channel active set,
Active Set
Search, Finger scramble of the H HSDPA
Strength
TA with HS info service cell, and Ec/Io in
the active set

Application
Window Logmask Item Main Parameter
Scenario
All packets in the

MAC/RLC layer 2 are
Packets in each layer 2 R99, HSDPA
Message displayed in
packet mode.
Layer 2 WCDMA RLC UL Uplink throughput of the

R99, HSDPA
AM Statistics RLC layer
RLC
Throughput
WCDMA RLC DL Downlink throughput of
R99, HSDPA
AM Statistics the RLC layer
APP No (count from Throughput of the

R99, HSDPA
Throughput the modem port) application layer
RRC state of the UE:

RRC state Cell_DCH/CELL_PCH/C R99, HSDPA
ELL_FACH, IDEL
UE state
Layer 3
Observing the RNC ID

Cell ID and Cell ID of the UE R99, HSDPA
service cell
RRC
RRC Message RRC Message R99, HSDPA
Messages
UMTS
NAS Message of non-access R99, HSDPA,

NAS Signaling
Messages layer GSM

7 References:
 Pan Zhen, WCDMA Special Guide Drive Test-20041104-A-2.0.doc, 2004/11.
 WCDMA Test Methods for Ratio Voice Quality-20041101-A-1.0.doc, 2003/12.
 GENEX Probe User Manual.
 3G and 2G Interoperability Group, Special Study Report on 3G-to-2G
Interoperability Handover Delay.doc, 2006/01.

W-Test Guide-20081215-A-3.4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

W-Test Guide-20081215-A-3.4

Uploaded by

Copyright:

Available Formats

WCDMA Test Guide For internal use only

Product Name Confidentiality Level

WCDMA RNP For internal use

WCDMA Test Guide

Prepared by: Gao Bo Date: 01-20-2006

Li Wenhui, Jin Yu, Hua

Reviewed by: Wang Chungui Date: 03-28-2006

Approved by: Date:

Huawei Technologies Co., Ltd.

2008-12-15 Huawei Confidential Page 1 of 175

2006-01-20 3.00 The first draft was completed. Gao Bo

The modification was completed according to comments of

The modification was completed according to comments of

2006-03-24 3.00 The modification was completed according to comments of Gao Bo

The preparations before a DT were modified: adding such

2008-12-15 3.41 Yearly review Hu Wensu

2008-12-15 Huawei Confidential Page 2 of 175

2008-12-15 Huawei Confidential Page 3 of 175

3.3 Standards and Methods of CQT Test Acceptance............................................................130

2008-12-15 Huawei Confidential Page 4 of 175

2008-12-15 Huawei Confidential Page 5 of 175

2008-12-15 Huawei Confidential Page 6 of 175

2008-12-15 Huawei Confidential Page 7 of 175

Figure 81 Call setup delay (1) in the probe report................................................................140

2008-12-15 Huawei Confidential Page 8 of 175

WCDMA Test Guide

Abbreviations Full Spelling

CQT Call Quality Test

HSDPA High Speed Downlink Packet Access

HSUPA High Speed Uplink Packet Acccess

2008-12-15 Huawei Confidential Page 9 of 175

Overview of WCDMA Tests

2008-12-15 Huawei Confidential Page 10 of 175

1.1.1.1 Selection of Test Tools

Car cigarette lighter 12V DC

Figure 1 Recommended recharging method on a vehicle

2008-12-15 Huawei Confidential Page 11 of 175

1.1.1.3 Preparing BTS Engineering Parameters and E-map

1.1.1.4 Connecting DT Devices

2008-12-15 Huawei Confidential Page 12 of 175

Figure 1 Connecting the DTI Scanner

Figure 2 Receiver panel

2008-12-15 Huawei Confidential Page 13 of 175

Figure 3 Connecting the Agilent 7464

Figure 4 Connecting a test handset (Qualcomm handset)

During the test, note the following items:

2008-12-15 Huawei Confidential Page 14 of 175

1.1.2 Selection of DT Routes

1.1.3 Confirmation of Test Conditions

2008-12-15 Huawei Confidential Page 15 of 175

For the HSUPA test, the following need to be confirmed:

For the MBMS test, the following need to be confirmed:

1.1.4 DT Personnel and Time Schedule

1.1.5 CN Test Devices

1.1.5.1 AMR Trunk

1.1.5.2 FTP Server

2008-12-15 Huawei Confidential Page 16 of 175

4) support auto resume after downloading interrupted

Test Item Not Loaded Loaded

SCANNER 3G ONLY test 3G ONLY test

1. 3G ONLY continuous call test 1. 3G ONLY continuous call test

2. Automatic continuous call test 2. Automatic continuous call test

Voice 3. 3G ONLY continuous dial-up 3. 3G ONLY continuous dial-up