UMTS Optimization Guideline
BASIC TUNING ... 2
KPISAND SERVICE REQUIREMENTS ... 2
IRAT Performance ... 2 CS Performance ... 2 CS Requirements ... 3 PS Performance ... 4 PS Requirements ... 5 TOOLS ... 8 Tools Requirements ... 8 RF Measurements ... 11 Throughput Measurements ... 12 Call Performance ... 13
Tools Currently Available to Capture / Process data ... 15
Drive Test Equipment and Software ... 18
Post-Processing Software ... 22
PRE-LAUNCH OPTIMIZATION PROCESS ... 24
Database Verification ... 25
Drive Test Route Selection ... 27
Drive Test Data Collection ... 29
Data Post-processing and Root-Cause Analysis ... 30
Root Cause Analysis and Recommendation ... 31
High Downlink Interference ... 31
Pilot Pollution ... 33
Out of Pilot Coverage ... 34
Insufficient received UL DPCH power ... 34
High UE TX Transmit Power ... 35
Swapped feeders ... 36
Low data throughput ... 38
Handover Event Detection Failure ... 40
No Suitable Cell ... 42
Assessing Success of Recommended Change ... 42
OMC STATISTICS BASED TUNING ... 43
KPIS ... 43
IRAT - Inter Radio Access Technology (IRAT) performance ... 51
CS Performance additional information ... 52
PS Performance additional information ... 52
TOOLS ... 53
Tools Requirements ... 53
Tools Currently Available to Capture / Process Data ... 54
POST-LAUNCH OPTIMIZATION PROCESS ... 57
Data Post-processing and Root-Cause Analysis ... 58
Optimization Strategy per Root-cause and/or Problem Category/Type/Area ... 68
Basic Tuning
KPIs and Service Requirements
IRAT Performance
Handover between WCDMA and GSM allows the GSM technology to be used to give fallback coverage for WCDMA technology. This means subscribers can experience seamless services even with a phased build-out of WCDMA. The IRAT performance is evaluated under the following test cases.
• IDLE mode to GERAN (3G to 2G cell reselection).
• Cell FACH state to Cell PCH state (3G PS state transition)
• URA PCH state (3G PS state transition)
• 3G to 2G with PDP context activation (PS test; 3G to 2G cell reselection)
• 2G to 3G with PDP context activation (PS test; 2G to 3G cell reselection)
• 3G to 2G CS Handover (CS-only test)
• 2G to 3G CS Handover (CS-only test)
• 3G to 2G CS Handover with PDP context activation; Multi-RAB handover (CS + PS test)
• Event 3A measurement activation / deactivation CS Performance
• Call Event Success Rate
• Call Block Rate
• Drop Call Rate
• SHO Event Success Rate
• Location Update success rate
• Channel Utilization
• Call Completion Success Rate
• Inter Cell Handover Success Rate
• Handover Success Ratio
• Paging and Routing Area Updates
• Connection Setup Success and Dropped
• Call Setup Rate
• Bad Quality Call Rate %
• DL Power Outage %
• SHO Overhead
• Bs TXP
• RAB establishment success rate CS Requirements
These two KPI’s RRC setup complete rate and RRC Establishment
complete rate combine to give us another key KPI, accessibility, which is a measure of the origination success rate.
Accessibility
The network operator should target an Accessibility rate greater than 98 % for circuit switched voice conversations and packets switched data
sessions.
Retainability
Retainability is a measure of the Radio networks ability to maintain an active mobile session until the user terminates. It indicates the percentage of active calls dropped.
A typical retainability requirement for a network is Drop Call Rate < 1.5% for voice conversations.
PS Performance
• RLC DL throughput: Total RLC downlink throughput.
• RLC UL throughput: Total RLC uplink throughput.
• Session App. Mean Throughput DL (kbit/s): Mean throughput, calculated over the whole of the current session, for data received at the application level (mean downlink throughput).
• Session App. Mean Throughput UL (kbit/s): Mean throughput, calculated over the whole of the current session, for data sent at the application level (mean uplink throughput).
• Ping Delay (ms): Delay for an individual Ping Response during the current Ping session.
• Success Rate of internet connections
• Variable data rate performance
• End to end packet delay transfers
• Throughput at the edge of the cell
• PS and CS Bearers
• Attach / Context
• Blocked Error Rate %
• Packet Bad Quality %
• PDP Context Activation success ratio
• Attach success ratio
• Data Transfer drop ratio
• Attach setup time
• PDP context activation time
• Service Access time
• End to end access time
• Mean user data rate
• Round trip time
• Packet loss ratio
• Initial Service Response
• Transfer interruption time
• End to end accessibility success ratio
• Service Access Success Ratio PS Requirements
• HSDPA DL Application Layer Throughput > 400 kbps
• R’99 DL Application Layer Throughput > 133 kbps
• HSDPA Ping Round trip Latency < 150ms
• R’99 Ping Round trip Latency < 150ms
• OCNS with 20% of Minimum Design capacity.
Optimization Insights
Optimizing the Network
The optimization process should start in the so-called pilot network, an intermediate stage of the network rollout where only the common channels for signaling and synchronization are use. While carrying no traffic itself, this pilot network provides a useful representation of the traffic flow in the future operational WCDMA network. Many aspects of optimization activities can be done in this phase.
Some other aspects of optimization such as adjusting the Soft Handover ratio must wait until the user equipment (UE) is in operation.
Basic Tuning to be done early phase of roll out Coverage Optimization
1. Since each Node Bs continuously transmits CPICH, scanning the CPICH using a Drive test system enables a quick and effective examination of the network RF Coverage, as well as a means to identify the Node Bs. It is important to detect high CPICH levels from too many cells as this causes interference.
2. Lack of RF Coverage - Can cause calls to drop or be blocked due to lack of coverage at the edge of the cell site coverage or coverage hole in the area.
Missing Neighbors and Pilot Pollution
1. Missing Neighbor in the neighbor list - Neighbor condition occurs when a high level pilot (i.e one whose measured value is above T_Add (Threshold to Add)) that does not appear in the neighbor list is sent to a phone. This condition adds interference, resulting in a low quality connection, and possible causing dropped calls.
2. Pilot Pollution and Interference - Pilot Pollution occurs when there are an excessive number of pilot signals. In such a situation a subscriber could notice interference on an active call.
Balancing of Channel Transmission Powers:
The relative output powers of various channels in WCDMA can be freely adjusted, and should be since they have different requirements.
Signaling channels need less power than the channels that carry user data.
Particularly important to ensure that Synchronization channels are transmitted strongly enough to be reliably detected.
Cells in the vicinity of one another must use different offsets for the synchronization burst in order for the synchronization channel to work properly.
Type of test call in drive-test:
Short voice call: Each voice call is made to a PSTN number and held for duration of 100 seconds and waited for 10 seconds between calls.
Long Voice call: Voice call is made to a PSTN number and held until the end of the cluster drive test, or until the call dropped.
Short CS Data Call: CS data call is made to another mobile or to a CS ftp server and held for a duration of 100 seconds then wait for 10 seconds before making the next call.
Long CS Data Call: CS data call is made to another mobile or to a CS ftp server and held until the end of the cluster drive test, or the call dropped. Short PS Call: About 100 seconds worth of data transfer DL or DL FTP a 2.5 MB file (approximately).
Long PS Call: About 1 hr worth of data transfer DL or multiple DL FTP files of size about 10MB.
KPIs:
CPICH RSCP: Received signal code power, the received power on one code measured on the primary CPICH.
DL RSSI: Received signal strength indicator, the wide-band received power within the relevant channel bandwidth.
CPICH Ec/No: The received energy per chip divided by the power density in the band.
UE UL TxPwr: The total UE transmitted power on one carrier.
Call event success rate: Formula: # Call Ends / (# Call Ends + # Blocked Calls + # Dropped Calls)
SHO event success rate: Formula: (# add + # remove + # replace) / # all SHO
Tools
Tools Requirements
Different tools are required to accomplish basic tuning in UMTS network.
• Cell Planning Tools
• Route Planning Tools
• Drive Testing Tools
• Data Processing and Report Generation Tools
• RF Test Tools
Cell Planning Tools
During basic tuning, Cell Planning Tool is used to:
• Plan and design UMTS network,
• Analyze coverage and interference,
• Design neighbor cell relationships and define handover margins,
• Analyze traffic,
Route Planning Tools
Often Mapinfo is used to plan drive routers before drive-tests. Mapinfo is a commercial application working on PC. In route planning process, Mapinfo can be used to plan route, sites and spatial data visualization and printing. A digital map is required with Mapinfo format including raster and vector information of terrain.
Besides Mapinfo, maps or map software such as Microsoft Street and Trips, can be used to plan routes.
Driver Testing Tools
During the basic tuning for a pre-launch UMTS network, drive-testing is the most important way to collect the network performance data, since there are limited subscribers using the UMTS pre-launch network and accurate network statistics is not available from OSS. Drive testing tools are used to:
• Record UE and scanner measurement data,
• Visualize UE and scanner measurement data during drive testing (synchronized maps, tables, graphs and text information).
To do the drive test in UMTS network, the following components are required.
• Test UE
With Test UE, drive testing tools can capture RF measurements on the UE side, like UE transmit power, DL CPICH Eb/No, DL RSSI, etc. Further more, to get a full picture (both downlink and uplink information) of the problem, it is possible to use UE trace function during the drive test, if the RAN and OSS can support this function.
Since UMTS can support voice, CS data and PS data, usually we need more test UEs during the drive test. To get all RAB performances in UMTS network, the following call type is necessary to do a drive test:
Short voice call: Each voice call is made to a PSTN number and held for duration of 100 seconds and waited for 10 seconds between calls.
Long Voice call: Voice call is made to a PSTN number and held until the end of the cluster drive test, or until the call dropped. Short CS Data Call: CS data call is made to another mobile or to a CS ftp server and held for a duration of 100 seconds then wait for 10 seconds before making the next call.
Long CS Data Call: CS data call is made to another mobile or to a CS ftp server and held until the end of the cluster drive test, or the call dropped.
Short PS Call: About 100 seconds worth of data transfer DL or DL FTP a 2.5 MB file (approximately).
Long PS Call: About 1 hr worth of data transfer DL or multiple DL FTP files of size about 10MB.
• Pilot Scanner
A pilot scanner is a tool to measure the CPICH Eb/No and CPICH RSCP regardless the neighbor list setting, correlated with GPS positioning data. It is useful to determine a handover relationship and to evaluate radio wave propagation characteristics, pilot channel qualities, soft handover area locations and downlink interference contributions.
• GPS
GPS can provide position information during drive tests. With GPS we can get the result that abnormal RF problem can be connected to geographical information.
• FTP Server
In order to transfer data stably without any unexpected problem from Internet, a dedicated FTP server should be set up before doing drive tests.
Different size files on a FTP server should be put so as to perform short PS data calls or long PS data calls. For example: 1MB, 2 MB, 5 MB, 10MB, 100MB, etc.
Data Processing and Report Generation Tools
To analyze drive test log file, post data processing tools can be used to display a plot, which includes radio measurement results and geographic information on MapInfo. In addition, this post data processing tools can provide the statistics of call events and radio measurement data, often used in our customer reports.
RF Testing Tools
A spectrum analyzer is a tool to monitor spectrum characteristics. It is useful to track external interference inside or outside of the operational band. In the initial deployment phase (coverage limited system), it can be used to survey the level of adjacent channel interference from other operators.
RF Measurements
The following is the key RF performance indication in UMTS drive tests. Test UE
Scrambling codes of active set cells and monitored set cells CPICH_Ec/No of active set cells and monitored set cells (dB)
CPICH_RSCP of active set cells and monitored set cells (dBm)
DL RSSI (dBm)
DL transport BLER (%)
DL SIR target and estimated DL SIR (dB) UE transmitted power (dBm)
All UE sent and received L3 messages
Pilot Scanner
Scrambling codes of all CPICHs Ec/No of all CPICHs (dB)
RSCP of all CPICHs (dBm) DL RSSI (dBm)
Throughput Measurements
During the drive test in UMTS network, it is important to measure and monitor wireless data service performance, since wireless data service is the significant characteristic of UMTS technology. PS performance measurements can be obtained as follows:
RLC DL throughput: Total RLC downlink throughput. RLC UL throughput: Total RLC uplink throughput.
Session App. Mean Throughput DL (kbit/s): Mean throughput, calculated over the whole of the current session, for data received at the application level (mean downlink throughput).
Session App. Mean Throughput UL (kbit/s): Mean throughput, calculated over the whole of the current session, for data sent at the application level (mean uplink throughput).
Application Throughput DL(kbit/s): Current throughput for data received at the application level (current downlink throughput). Application Throughput UL(kbit/s): Current throughput for data received at the application level (current uplink throughput).
Ping Delay (ms): Delay for an individual Ping Response during the current Ping session.
Call Performance
Often the drive test tools can provide some call events statistics that can be used to evaluate radio network performance. These call performance statistics can be categorized into four groups.
Accessibility
RRC connection setup successful rate from the UE point of view % 100 request connection RRC sent of Number complete setup connection RRC sent of Number ×
RB establishment successful rate per RB from the UE point of view % 100 setup bearer radio received of Number complete setup bearer radio sent of Number × Retainability
Average RRC connection drop rate when the UE is in cell_DCH mode
[ ]
s
-1test
drive
w hole
the
of
tim e
Total
idle
to
C ell_D CH
from
is
state
U E
he
t
in w hich
drops
abnorm al
of
N um ber
Average RRC connection drop rate when the UE is in cell_FACH mode
[ ]
s
-1test
drive
w hole
the
of
tim e
Total
idle
to
C ell_FA C H
from
is
state
U E
he
t
in w hich
drops
abnorm al
of
N um ber
Mobility Soft handover success rate (# add + # rem + # repl) / # all
Where
add = Radio Link Addition events rem = Radio Link Removal events repl = Radio Link Replacement events all = all Radio Link events, including failures
IRAT hard handover success rate From UMTS to GSM: % 100 command UTRAN from HO of Number Complete UTRAN from HO of Number × From GSM to UMTS: % 100 command UTRAN to HO of Number Complete UTRAN to HO of Number ×
Quality
Downlink transport channel BLER
Best serving cell CPICH Ec/No, i.e. pilot channel quality
Tools Currently Available to Capture / Process data
At present many drive test software and analyze software are available to capture and post-process measurement data. Basically these software can be categorize into two groups based on the provider of these software.
Software developed by Mobile Infrastructure Equipment Vendor
An advantage of this kind of software is that vendors can add some additional test functions to let these software work well with their infrastructure network. For example, Ericsson adds SQI measurement function in their drive test tools – Tems Investigation, this function can evaluate voice quality during drive tests. Also in Ericsson infrastructure network, same function is used in performance statistic.
Two major drive test and post-process tools listed below are commonly used in different operators.
Nemo
Nemo is a Finland company which dedicates to develop drive test and post-process software for mobile networks. The former of this company is a branch of Nokia. Nemo is used commonly by operators who use Nokia system, like T-Mobile.
Nemo Outdoor™
Nemo Outdoor™ is a portable engineering tool designed for measuring and monitoring the air interface of wireless networks. Fast and accurate measurement data provides detailed information in real time for 2G, 2.5G, 2.75G, and 3G networks.
For more detail information about Nemo Outdoor, please read his web site. http://www.nemotechnologies.com/index.php?249
Nemo Analyze™
Nemo Analyze™ is a front-line analysis tool for quick and easy data review. It can be used on the field or in the office for immediate problem solving and report generation. Nemo Analyze is designed to be the analysis tool for measurement files produced with the Nemo measurement tools: Nemo Outdoor and Nemo Handy.
For more detail information about Nemo Analyze, please read his web site. http://www.nemotechnologies.com/index.php?267
Tems
Tems products are developed by a branch of Ericsson Corporation. Tems products portfolio includes radio network planning, radio network optimization, benchmarking, indoor coverage testing.
Tems Investigation
TEMS Investigation is a portable air-interface tool for troubleshooting, verification, optimization, and maintenance of mobile networks. The tool collects all the data needed to keep the network running smoothly and to plan for future improvements. The collected data is presented in real time, and can be used together with site information to improve troubleshooting
capability. The flexible interface allows the user to filter network data and focus on relevant information for truly in-depth analysis
For more detail information about Tems Investigation, please read his web site.
http://www.ericsson.com/solutions/tems/realtime_diagnostics/investigation .shtml
Tems DeskCat
TEMS DeskCat is advanced post-processing software. It enables users to easily mine drive test data, visualize air interface problems, and drill down into the data for easy analysis and problem resolution. It also provides the unique System Quality Report for comprehensive network comparison. Designed to support experienced RF engineers and network optimization specialists, but able to provide managerial reports as well.
For more detail information about Tems DeckCat, please read his web site.
http://www.ericsson.com/solutions/tems/realtime_diagnostics/deskcat.sht ml
Software developed by Testing and Measurement Company
Developed by companies dedicating to develop sophisticated equipments, these drive test tools have a common characteristic on RF testing function.
For example:
Rohde-Schwarz TS9951+ ESPI+ROMES3
Rohde-Schwarz TS9951 is a drive test hardware used to support up to 4 mobile phones. Rohde-Schwarz ESPI is a test scanner to accomplish the PN scan and CW measurement. These two tools should be run on the drive test software Rohde-Schwarz ROMES3.
For more detail information about Rohde-Schwarz products, please read their web site. http://www.rohde-schwarz.com
Agilent E6474A
The E6474A Agilent Wireless Network Optimization Platform provides true cross technology scalability and allows early verification of network deployments for 2G, 2.5G and 3G wireless networks. Its optimization platform enables wireless service providers and network equipment manufacturers to proactively address challenges with wireless voice and data networks by quickly and accurately identifying problems.
Drive Test Equipment and Software
The field measurement equipment usually consists of:
• A laptop, which store the measurements data and run the drive test software.
• A GPS, to record the exact location of the measured parameters.
• Mobile phones and scanners to be used as measurement devices.
HUB Scanner
Three phones can used to provide a flexible test configuration and test both data and voice calls (short and long calls). Using both mobile and scanner simultaneously in WCDMA measurements enables the measuring of all pilots available in the area and the comparison of the results to the view seen by the user equipment (UE). The UE reports values based on a neighbor list received through signaling and makes cell reselections and handovers based on the planned neighbor list. However, there can be pilots available that are not defined in the neighbor list and these can be spotted with a scanner. In other words, measurements together with scanner and mobile would also identify missing or interfering pilots.
Effective UMTS drive test software should be able to measure and perform the following tasks:
• Evaluate call-processing operations
• Perform selected call processing functions
• Measure and report the amplitude of the received base station signal
• Measure and report the signal quality of the received base station signal
• Read and report the neighbor cell list from the broadcast messages
• Report the amplitude of neighbor list base stations
• View and log protocol messages in decoded form for easy interpretation
• Quantify wireless data user’s quality of service (with data measurement options).
• Perform integrated analysis using the phone and receiver at the same time
• Show current position and the route traveled on a map as data is collected.
The following is a list of some of the parameters measures. Interlayer Messages
• UMTS Layer 3 Messages • GSM Layer 3 Messages • GSM Acknowledged Mode Messages Layer 2 • GPRS RLC/MAC Messages • GPRS GMM/SM Messages QoS Indicators
• Real-Time Data Throughputs • RLT Counter Radio link timeout • FER
• Vocoder State • DTX State
• Retransmitted RLC Block Rate
• RLC/MAC Real-Time Data Throughputs • RLP Report
• Handover Counter
UMTS Measurement Information • UL/DL ARFCN
• ARFCN RxLev
• Each CPICH in the Active List
• Ec/No of each CPICH in the Active List • Composite and per finger RSCP
• Each CPICH in the Candidate List
• Ec/No of each CPICH in the Neighbor List
• Cell ID of each CPICH in the Active and Neighbor Lists • BSIC
• Power Control – UE Tx Power – DPCH SIR
HSDPA Measurement Information
• CQI
• DCH BLER
• DCH Retransmissions • DSCH Throughput (kbit/s) • SCCH OVSF Code Info • HS Session
GSM/GPRS/EDGE Layer State and Measurement Information • Layer 1 Information
• RR Information • MM Information • MAC Information • RLC Information
− Downlink Coding Scheme − Uplink Coding Scheme • LLC Information
• GMM Information • SM Information • SNDCP Information • Service State
• Streaming Video • IP Protocol Trace • Data throughput UL/DL
• Ftp, http, and ping test applications. • MMS and SMS testing
• New Command sequence • Roundtrip delay
Post-Processing Software
Post processing forms a key counterpart to data collection in the verification of infrastructure performance, automated calculation of performance metric analyses and troubleshooting.
Key features of a data analysis and post processing tool for UMTS is the ability to:
• Support multiple technologies i.e. GSM, GPRS and WCDMA on one platform simultaneously.
• Provide maps, histograms and cumulative distribution charts and statistical analyses of key packet data and radio link performance metrics.
• Correlate WCDMA scanner and UMTS UE measurements from independent log files.
• Support interfaces to a variety of vendors of drive test equipment, protocol analyzers and measurement programs.
• Access to radio interface messaging, including message counters and cause value breakdown for failure, error and reject messages.
• Assess Subscriber-perceived performance analysis for IP and data applications (e.g. HTTP, UDP)
• Provide support for open interfaces, which can typically be used to collect performance data well in advance of proprietary data sources, like test mobile and peg counter data.
• Reduce data through binning and standard database type querying and filtering capabilities.
• Synchronize data collected from different network elements and sources to remove timing discrepancies.
• Provide interfaces into databases for storing collected data statistics and provide web-enabled reporting interfaces for extracting data.
• Embed engineering expertise into the software to automate the process of analyzing large amounts of data.
Pre-Launch Optimization Process
Database Verification
Purpose
Yes No Basic Tuning Database Verification Performance MonitorDrive Test Performanc e Report Test User Complain Performance Analysis Parameters Tuning Mechanical Tuning Meet Project Target Finish Performance Review
The purpose of the database verification activity is to verify that the radio network has been properly configured, meaning that the actual system parameter settings correspond to the recommended values, and RF parameter settings correspond to the radio network design results.
RAN database verification is the first step of basic tuning. By implementing the verification, unnecessary troubleshooting will be avoided and further investigations can be carried out focusing on problems other than parameter configuration mistakes.
Database verification includes two parts of work- RF Parameters Verification and System Parameters Verification.
RF Parameters Verification
The RF parameter settings that are implemented in the live network and the original radio network design results are the base to conduct basic tuning. These RF parameter settings contain PN code plan, neighbor list plan, antenna height, antenna direction and tilt. Make sure that the RF parameter settings in the live network are exactly the same with the radio network design results.
Meanwhile, conducting drive test for each site can ensure that no antenna swap mistakes exist in the live network.
Often missing neighbors and antenna swaps are the most common mistakes in the pre-launch network, resulting in serious radio network performance problems in UMTS networks, e.g. high drop call rate in some cells, bad quality area (with low Ec/No) etc.
System Parameters Verification
In order to avoid abnormal system parameter setting in live network, verifying the parameter settings in the live network correspond to the
recommended values is important. These recommended values are based on lots of testing and simulations results, which are optimal values in most networks.
The procedure to implement system parameters verification is as below: 1. Retrieve current parameter settings from systems
2. Check current versus recommended parameter values
3. Apply the consistency check rules to current parameter values
4. Produce a list of parameters to be changed and generate the change requests for clients
5. Get approval from clients and load changes to the systems A parameter dump should be created from the live network to retrieve current parameter settings, following by a conversion of the system dump file into readable Microsoft Excel file with script developed by Excel Macro or VB.
Equipments from different vendors often provide different recommended system parameter setting values, which may require to be modified when new software version is released. Therefore, it is important to get recommended parameter setting values for current software version from clients before implementing system parameter setting verification.
Drive Test Route Selection
Drive testing is done to verify the coverage and the service requirement KPI’s i.e. availability, Retentivity etc or for pin pointing and resolution of any network related issue. The Drive route criteria for both the scenarios are different.
• The main purpose of baseline drive testing is to find the problem areas of the network. Using field measurement, coverage holes, interference areas, and handoff regions.
• The primary drive route consists mainly of freeways, highways and high traffic areas (like downtown). The high traffics areas are also define in the coverage and capacity objective, part of the Wireless System Design (and Implementation) Report. Both directions of travel need to be considered. If the three primary types of road do not cover problem areas, secondary road should be considered. If time and resource permit, selected secondary streets can be included in the drive routes.
• For baseline drive test, the drive routes need to cover farther than good coverage areas. For example, route will include roads covered lower than Ec/Io=-16dB.
• The route should cover all the sectors included in the test.
• Avoid the area with known coverage problem because of the unavailability or hardware problems of cells covering the area.
Problem Resolution Drive route
When problem area is identified, a punctual drive route should be design to verify and quantify the extent of the problem.
• The route should be driven both directions to verify if the problem exists in one direction or both directions. E.g. To verify handovers from any sector from a site we need to check the outgoing
and incoming handovers for which we need to drive in both directions of the drive route.
• If we do encounter any problem/ issue we should repeat the route so as to repeat the problem.
• If in the network there are a couple of problem areas, it is recommended to have separate spot drives for each of the problem areas.
Drive Test Data Collection
Before we start data collection we need to make sure that the hardware is connected and configured properly.
• Make sure all the Phones, Scanners, Scanner Antenna’s, GPS, Hubs and Laptop are connected properly.
• Make sure all the devices are connected to the appropriate COM port, and the COM ports are configured accordingly.
• Set up the Autocall settings to set up the phones for Long Call and Short call with the appropriate set up times, number to call, Max Idle time and Connect time.
• Make sure the appropriate Mapinfo workspace for the drive test area is configured in the Drive Test tool.
• Import the most current Cell site database which has information on the Sites, their PN’s and the Antenna orientations.
• Set up the FTP server with a suitable file for testing of Data Download and upload speeds.
• Set up the Scanner configurations as a Pilot Scanner with the appropriate Scan lists, Avg Ec/Io and Correlation taps.
• Open at least one window for the Map, The phone data, Scanner Data, and the Summary data for all the devices.
• Connect all the devices, the Data collection software shows the connected devices.
• Run a test call to confirm that the Autocall, Scanners, GPS and the phones working fine.
• If everything is working fine, start logging and save the log files with suitable identifiers like <<Date>><<Time>><<Log File>>. Save the log files in the appropriate directory.
Data Post-processing and Root-Cause Analysis Data Post-Processing
To optimize the pre-launch network, various input data is needed:
• Performance statistics
• Performance recording
• Fault logs from RNC and Node B
• Parameter data Performance statistics
Performance statistics is generated from the live, and is made up of a number of predefined counters. Combining these counters into formulas, we can get statistical reports which are useful for performance monitoring and optimization. During the basic tuning for a pre-launch network, since there are limited test users in the network, the performance statistics are not so accurate like the performance statistics in live network.
Performance recording
Performance recording includes two parts, log-file from drive-test tools and UE trace log-file from OSS with UE tracing function. UE tracing function provides UL information received by Node B side and signaling between
Node B and RNC. Performance recording is the important input when performing a basic tuning in pre-launch network.
Fault logs from RNC and Node B
Fault logs are useful to identify abnormal system behavior caused by node faults
Parameter data
Parameter setting reviews are useful to understand the intention of the original radio plan and to determine how the parameter changes should be.
Root Cause Analysis and Recommendation
High Downlink Interference Phenomena
During the drive test, following phenomena might be observed through drive testing tools:
• Received Ec/No of the pilot channel is less than –16dB and
• Received RSCP of the pilot channel is high enough to maintain the connection, e.g. > -100dBm and
• DL RSSI is very high and
• The connection drops eventually
Many overlapping cells exist in the problematic areas and received signal strengths of the pilots in these overlapping cells are almost the same.
Recommendation
A direct and effective solution is to increase the pilot channel power – Primary CPICH power of the desired cell.
Reason 2 – Dominant Interferer
An undesired cell is identified because of its high signal strength, causing missing neighbor problem.
Recommendation 1
The simplest solution is to convert the interferer to a useful radio link by including the overshooting cell into the neighboring cell list. Recommendation 2
The second solution to solve this problem is to decrease the pilot power - Primary CPICH power of the overshooting cell.
With the pilot power decreasing, the total downlink power for the common channels of the interferer decreases. At the mean time, the power of all other common channel decreases because their parameter settings are related to the pilot power value.
Recommendation 3
The third solution is to change the antenna configuration of the overshooting cell. The possible practices include tilting down the antenna, re-directing the antenna orientation, reducing the antenna height and so on.
This solution will not lead to UL/DL coverage imbalance problem in the interferer because UL/DL path-loss is changed simultaneously.
Reason 3 – Low Best Serving PPilot/PTot
The third possible reason is that the pilot power setting is not large enough to fulfill existing downlink load, because low received Ec/No of the best serving pilot channel (near or less than –16dB) can be observed even if there is no other cell
Recommendation
To add a new site with “good coverage control” in the problematic area is a common practice.
Pilot Pollution
Phenomena
In cell_DCH mode, pilot pollution refers to the phenomenon that a UE at one location alters its active set cells frequently (e.g. active set update rate is very high) because many received pilot channels have similar quality (or signal strength) such as Ec/No (or RSCP).
Reason – No Dominant Cell
Due to poor cell planning, a large number of overlapping cells exist at a particular area
Recommendation 1
To change the antenna configurations or reduce the pilot power of the undesired cells is a common practice to remove the cells overlapping.
An alternative solution to remove the cell overlapping is to increase the pilot channel power – Primary CPICH power of the desired cells.
Out of Pilot Coverage Phenomena
During the drive test, following phenomena might be observed.
• Received Ec/No of the pilot channel is less than –16dB and
• Received RSCP of the pilot channel is very low, e.g. <-100dBm and
• DL RSSI is very low and
• The connection drops eventually Reason – low pilot channel power
To set the low pilot channel power can lead coverage holes. Recommendation 1
The most common solution to overcome this problem is to add a new site in the problematic area.
Recommendation 2
To increase the pilot channel power is an alternative solution.
Insufficient received UL DPCH power Phenomena
During the drive test, following phenomena might be observed through drive test tools and UE tracing function:
• Received Ec/No of the pilot channel is larger than –16dB and
• UE Tx power does not reach the maximum allowed value and
• UL SIR target of the radio connection reaches to the maximum allowed SIR target and
• UL BLER of the radio connection increases and
• The connection drops eventually
Reason
The possible reason that the base station cannot receive high enough power from the uplink dedicated physical channel is because the parameter - maximum allowed UL SIR Target is set too low.
Recommendation
The maximum allowed UL SIR Target should be justified to allow UEs to transmit with higher power.
High UE TX Transmit Power Phenomena
During the drive test, following phenomena might be observed though drive test tools and UE tracing function.
• Received Ec/No of the pilot channel is larger than –14dB and
• Received RSCP of the pilot channel is good, e.g. <-85dBm and
• UE Tx power reaches the maximum UE allowed value (23dB) and
• UL BLER of the radio connection increases
Reason – Uplink Interference
The possible reason that UE transmit with very high power even if with good the downlink quality (Ec/No) and high downlink signal strength (RSCP) is because of UL interference.
The UL interference could be internal interference (generate by other UEs) or external interference (repeater or industry interference).
Recommendation
Check cell UL loading in nearby cells to determine whether the interference is coming from internal. Check external interference with spectrum analyzer if there is external interference exsiting.
Swapped feeders
Phenomena
Due to swapped feeders, many problems will occur such as no downlink coverage, no uplink coverage or high UL/DL interference. The following are some (but not limited to) examples of swapped feeders:
Case 1: Cell B Tx feeder is swapped with the cell A Tx feeder The following symptoms might be observed:
Scrambling codes cover wrong directions.
Handover fails from other cells to Cell A/Cell B because of improper handover relationship or uplink DPCH synchronization problem.
Connection setup will fail during random access or uplink DPCH synchronization procedures. Connection setup fails during random access or uplink DPCH synchronization procedures.
Case 2: Cell B Tx feeder is swapped with one of the cell A Rx feeder. The following symptoms might be observed. There is no downlink coverage. (Cell B desired coverage
area)
Downlink interference is high. (Cell A desired coverage area)
Scrambling code covers wrong direction.
When the UE tries to connect to cell B in cell A area, connection setup fails during random access or uplink DPCH synchronization procedures.
A
C
B
If the UE tries to handover to cell B in cell A area, the UE may always send addition handover events to UTRAN but handover function always fails due to uplink DPCH synchronization problem.
The UE connected to cell A transmits with higher UE Tx power than that in normal feeder case because of higher UL interference (e.g. UL RSSI).
Connection drops when the UE moves to the planned cell B area
Case 3: One of the cell B Rx feeder is swapped with another cell A Rx feeder. The following symptoms might be observed:
The UE connected to cell A or/and cell B transmits with higher UE Tx power than that in normal feeder case because of higher UL interference (e.g. UL RSSI).
Recommendation
The direct solution to remove this problem is to ensure no crossed feeders and correct scrambling codes for the all cells in the site.
Low data throughput Phenomena
During the drive test, following phenomena might be observed when downloading files to/from the operator’s server (or the known public server) by FTP and pinging that server simultaneously.
• Average UL or DL throughput of the radio access bearer is much lower than the data rate of the known source or
• Long round trip time or
• Many missing packets.
Reason 1 – Poor Radio Link Quality
Poor radio links introduce error bits in packets. To keep integrity of the packets received, system retransmits the error packets. However, this may results in longer RTT and lower data throughput. Recommendation
Refer to “High Downlink Interference”
Reason 2 - Many Down-Switches Due To Coverage Triggering The imbalance between PS64/384 or PS64/128 radio bearer and pilot coverage can trigger channel switching function to switch its radio bearer to the next lower bit rate when it reaches to the coverage border. This results in lower overall throughput of the connection.
Recommendation
Improve the network coverage.
Reason 3 - Many Down-Switches Due To Congestion Control Because of congestion, the connection might be switched down to the common channel, causing the low overall throughput of connection.
Recommendation
The problem that low data throughput due to congestion control is rarely happened in pre-launch network. If it happens, changing handover parameter to move traffic to other neighbor cells, or decreasing the CPICH power to reduce the coverage of the congestion cell.
Handover Event Detection Failure
The handover event detection failure defined in this guide is that the network side does not receive “measurement reports” when the UE enters (or leaves) the desired (or undesired) cell coverage area. Phenomena
During the drive test, following phenomena might be observed through drive test tools and UE tracing function.
• The UTRAN fails to receive “measurement reports” from UE or
• The UE does not generate “measurement reports” when it enters the desired cell coverage area or
• The UE does not generate “measurement reports” when it leaves the undesired cell coverage area.
Reason 1 – Poor Uplink Quality
UTRAN does not receive “measurement reports” from UE, which implies the quality of poor uplink is poor.
Recommendation
Reason 2 - Missing Neighboring Relationship
Missing neighboring cell relationship is another possible reason. Neighboring cell relationship can be checked by monitoring the neighboring cell window during the drive test.
Recommendation
To add the desired cell to the neighboring cell lists of the cells in the active set is a common practice. However, too many neighboring cell relationship may make the process for searching pilot channel slow.
Reason 3 – pilot pollution in dedicated mode
The third possible reason is pilot pollution in dedicated mode. Recommendation
Refer to solutions about pilot pollution.
Reason 4 – slow searching or fast UE Handover events may be neglected because:
• Many cells in the monitored set slow down the search for pilot channel
• The UE is in fast moving. Recommendation
The usefulness of the handover relationships should be reviewed and the unnecessary relationships should be removed
No Suitable Cell
Phenomena
During the drive test, the UE in the idle mode can not camp on any cell and the display of the UE shows “no coverage”.
Reason 1 – High Downlink Interference
High downlink interference is the possible reason causing no suitable cell. Please refer to “High Downlink Interference”
Reason 2 - high restriction on cell (re)-selection parameters The second possible reason causing no suitable cell is high restriction on cell (re)-selection parameters, even though the actual quality and signal strength of the pilot are good enough to provide coverage.
The parameters for the cell (re)-selection are:
• QqualMin: Minimum quality for selection/reselection
• QrxlevMin: Minimum level for Selection/Reselection
• UE Max Transmission Power Recommendation
The cell (re)-selection parameters (i.e. QqualMin, QrxlevMin, UE Max Transmission Power) should be reviewed and adjusted to suitable values.
Drive test and performance statistics are often used to assess success of the recommended changes. Drive test conducted in the same problematic area can verify whether these changes improve the performance in the problematic area. Performance statistic in the following few days can be used to check whether there is any side effect to other areas or other cells.
OMC Statistics Based Tuning
KPIs
Differentiated Performance Monitoring
The QoS of differentiated packet switched (PS) and circuit switched (CS) services can be assessed through counters collected and classified in the RNS. The analytical approach assumes that the network topology where the service performances are analysed is already defined (or selected within a wider scope) together with the measurement period (history), and user satisfaction criteria.
The identified area may encompass radio network controllers (RNC), base stations (BSs) or Node Bs, cells and the interface between the base station and the radio network controller (Iub). Our target is to define essential counters and key performance indicators (KPIs) that need to be retrieved, and/or derived from measurements in NEs, for a capacity and QoS status view in the RNS and/or a detailed performance analysis. In the latter case, for example, performance results may be compared directly to the target values or, since only the QoS perceived by end-user matter, expressed in terms of satisfied users. The network administrator may then compare the number of satisfied users to the related target thresholds defined a priority.
Classification of Counters
• CS Conversational
Call type: Speech or Transparent (T) data Guaranteed bit rate
Transport channel type: e.g. DCH
• CS Streaming
Non Transparent (NT) data Guaranteed bit rate
Transport channel type: e.g. DCH
• PS Conversational
Guaranteed bit rate
Allocation Retention Priority (ARP) Transport channel type: e.g. DCH
• PS Streaming
Guaranteed bit rate
Allocation Retention Priority (ARP)
Transport channel type: e.g. HS-DSCH, DCH
• PS Interactive
Maximum bit rate
Traffic Handling Priority (THP) Allocation Retention Priority (ARP)
Transport channel type: e.g. HS-DSCH, DCH, FACH, RACH
• PS Background
Maximum bit rate
Allocation Retention Priority (ARP)
Transport channel type: e.g. HS-DSCH, DCH, FACH, RACH
QoS Monitoring
• Uplink Eb/N0, BLER and BER
In the UMTS system the QoS is typically defined in terms of the BLER that the system must provide for the specific application. The required BLER is maintained through the combined operation of several different mechanisms. Among these, power control is unique in terms of its short latency and ability to compensate for large changes in propagation and interference conditions.
• BLER: This is long-time average block error rate calculated from transport blocks.
A transport block is considered to be erroneous if a CRC error is indicated by appropriate information element of Framing Protocol for uplink data. Unfortunately there is not good downlink BLER report specified yet that could be sent by user equipment. Only RRC measurement report with event-ID e5a indicates that downlink BLER exceeded a defined threshold.
• BER: Bit error rate (BER) can either be measured as Transport Channel BER or Physical Channel BER. Reports are sent by Node B to RNC for uplink data. The uplink BER is encoded in Framing Protocol Quality Estimate value.
• SIR Error: This shows the gap between the assigned SIR target and measured SIR. Analysis of SIR error per connection shows how good the SRNC is able to adjust uplink transmission power of UE, which means accuracy of Open Loop Power Control.
• Downlink BLER Computation
The downlink transport channel block error rate (BLER) is based on evaluating the CRC of each transport block associated with the
measured transport channel after RL combination. The BLER is computed over the measurement period as the ratio between the numbers of received transport blocks resulting in a CRC error and the number of received transport blocks. The mobile when explicitly ordered by the network may report such a measurement periodically on event based
• Throughput Computation
The throughput relates only to the correctly received bits during a predefined measurement period (observation time), denoted by S in the following, where RLC buffers are not empty.
• RLC Retransmission Rate
This indicator relates to number of retransmissions required to transmit an RLC PDU when the first transmission was not successful through the radio interface. The metric can be used to set the maximum number of allowed link layer retransmissions without compromising the load of the cell for the global quality of service requirements
• Service Data Unit Error Ratio
The SDU error ratio is defined as the fraction of SDUs lost or detected as erroneous
• Downlink Transfer Delay Computation
The transfer delay is defined as maximum delay for 95th percentile of the distribution of delay for all delivered SDUs during the lifetime of a bearer service, where delay for an SDU is defined as the time from a request to transfer an SDU at one SAP to its delivery at the other SAP. In practice, in these terms, the statistical measurement of the transfer delay would require to measure the delay of all delivered SDUs during the lifetime of one bearer service and save the corresponding values separately so that the distribution of delay could be derived. The
transfer delay would then be the delay that is greater than or equal to the delays of 95% of the delivered SDUs during the lifetime of the bearer service. Hence, the transfer delay measurement may become an issue when a statistical analysis is required.
• Downlink Jitter Computation
The jitter of a specific bearer service is defined as the difference between the one-way delays of the selected packet pair, e.g. consecutive packets.
QoS Accessibility and Retainability Monitoring
Accessibility and retainability measurements are based on the success/failure of procedures needed to setup, modify or maintaining a certain bearer service or signalling connection. Hence, the proposed measurements are attached either to the successful or the unsuccessful issue of a procedure for RAB or signalling connection management.
• RAB Management
Five measurement types may be defined for CS and PS domains • Number of RAB assignment attempts: On receipt by the RNC of a RANAP RAB ASSIGNMENT REQUEST message for CN, each RAB assignment request is added to RAB.AttEstab.m counter.
• Number of successfully established RABs: On transmission by the RNC of a RANAP RAB ASSIGNMENT RESPONSE message to the CN, each successfully established RAB is added to RAB.SuccEstab.m counter.
• Number of RAB establishment failures: On transmission by the RNC of a RANAP RAB ASSIGNMENT RESPONSE message to the CN, each
RAB failed to establish is added to RAB.FailEstab.Cause.m counter according to the failure cause.
• RAB connection set-up time (mean): This measurement is obtained by accumulating the time intervals RAB.SuccEstabSetupTimeMean.m for each successful RAB establishment, which is then divided by the number of successfully established RABs observed in the granularity period to give the arithmetic mean.
• RAB connection set-up time (maximum): This measurement may be obtained by the high tide mark RAB.SuccEstabSetupTimeMax.m of the monitored time intervals for each successful RAB establishment.
• Number of RAB releases: On transmission by the RNC of a RANAP RAB RELEASE REQUEST message, each RAB requested to be released is added to the relevant per cause measurement RAB.Rel.Cause.m.
KPI may be derived from above: Bearer Accessibility
Both Bearer Accessibility and Reliability product of the two KPIs above result in RAB Success Ratio
• Signalling Connection Management
• Attempted signalling connection establishments: This measurement provides the number of attempts SIG.AttConnEstab.m by RNC to establish an Iu control plane connection with the CN. In this case, m may simply denote the PS or CS domain. The trigger point is the transmission of a RANAP Initial UE message by the RNC to the CN, which is sent by the RNC on receipt of an RRC Initial Direct Transfer message from the UE.
• Attempted RRC connection establishments: This measurement provides the number of RRC connection establishment attempts for each establishment cause. On receipt of an RRC Connection Request message by the RNC from the UE, each received RRC Connection Request message is added to the relevant per cause measurement RRC.AttConnEstab.Cause.
• Failed RRC connection establishments: This measurement provides the number of RRC establishment failures for each rejection cause. On transmission of an RRC Connection Reject message by the RNC to the UE, or an expected RRC CONNECTION SETUP COMPLETE message not received by the RNC, each RRC Connection Reject message received is added to the relevant per cause measurement RRC.FailConnEstab.Cause.
• Successful RRC connection establishments: This measurement provides the number of successful RRC establishments for each establishment cause. On receipt by the RNC of a RRC CONNECTION SETUP COMPLETE message following a RRC establishment attempt, each RRC Connection Setup Complete message received is added to the relevant per cause measurement RRC. SuccConnEstab. Cause.
• RRC connection set-up time (mean): This measurement is obtained by accumulating the time intervals for every successful RRC connection establishment per establishment cause between the receipt by the RNC from the UE of a RRC CONNECTION REQUEST and the corresponding RRC CONNECTION SETUP COMPLETE message over a granularity period. The end value of this time, denoted as RRC.AttConnEstabTimeMean.Cause, is then divided by the number of successful RRC
connections observed in the granularity period to give the arithmetic mean. The measurement is split into sub counters per establishment cause.
• RRC connection set-up time (max): This measurement is obtained by monitoring the time intervals for each successful RRC connection establishment per establishment cause between the receipt by the RNC from the UE of a RRC CONNECTION REQUEST and the corresponding RRC CONNECTION SETUP COMPLETE message. The high tide mark of this time, RRC.AttConnEstabTimeMax.Cause, is the collected value.
• Attempted RRC connection releases: This measurement provides the number of RRC connection release attempts per release cause sent from UTRAN to the UE. On transmission of an RRC CONNECTION RELEASE message by the RNC to the UE, each RRC Connection Release message
sent is added to the relevant per cause measurement RRC.AttConnRel.Cause.
IRAT - Inter Radio Access Technology (IRAT) performance
Handover between WCDMA and GSM allows the GSM technology to be used to give fallback coverage for WCDMA technology. This means subscribers can experience seamless services even with a phased build-out of WCDMA. The IRAT performance is evaluated under the following test cases.
• IDLE mode to GERAN (3G to 2G cell reselection).
• Cell FACH state to Cell PCH state (3G PS state transition)
• URA PCH state (3G PS state transition)
• 3G to 2G with PDP context activation (PS test; 3G to 2G cell reselection)
• 2G to 3G with PDP context activation (PS test; 2G to 3G cell reselection)
• 3G to 2G CS Handover (CS-only test)
• 2G to 3G CS Handover (CS-only test)
• 3G to 2G CS Handover with PDP context activation; Multi-RAB handover (CS + PS test)
• Event 3A measurement activation / deactivation
CS Performance additional information
Customer demand Indicator Measure
Service accessability Availability & Coverage Blocked calls
Call setup delay
Ec/No, RSCP Admission control RAB assignment
Service integrity Voice quality Noisy frames (FER), MOS Service retainability Dropped calls Handover failure
No coverage Interference
PS Performance additional information
Customer demand Indicators Measures
Service accessability Availability & Coverage Blocked service access Service access delay
Ec/No, RSCP Admission control
Attach, PDP context activation, IP service setup
Service integrity Video quality Audio quality
Web page download time E-mail sending time, etc.
BLER, FER, throughput, delay, jitter
Service retainability Dropped data connection Connection timeouts
Dropped PDP context/attach No coverage
Tools
This section gives an overview of the standard Tool setup in collecting, monitoring and analyzing UMTS performance counters and Key Performance Indicators. It discusses briefly the requirements and will mention some known tools in the market today.
Tools Requirements OMC/OSS Configuration Core Network UE Node B Node B RNC RNC Router PM Server OSS Citrix Server PM Client OSS PM Client Iub Mub Mub Mun Mur Iur Iu
OSS/OMC Setup
OSS / OMC Server - is an integrated service and management system
for GSM, GPRS, EDGE and 3G networks. It has 3 main features – Configuration Management, Performance Management and Fault Management.
Performance Management Server – is 3rd party Application Server
capable of generating Performance Reports. Client/s can be setup to access this application through CITRIX.
OSS Performance Management Application – is a third party
application supported by the OSS. It can query the Performance database from the OSS, create and generate Performance Reports and customized KPI and formulas. Users or clients can connect and access this application through CITRIX.
Some common features:
User defined KPI’s
User defined reports
Real time reporting
Trending and Historical reports
Library of pre-configured calculations and KPI’s
Export to excel or any database format
Alarm monitoring
NetworkAssure by Vallent (formerly Watchmark Prospect)
NetworkAssure is a high performance management (PM) solution that pulls together OSS data to manage the most complex vendor, multi-technology networks. It provides a seamless aggregation and correlation of data from multi-vendor, multi technology networks and pre-built network interfaces for technologies, including UMTS, GSM, GPRS, IP, CDMA, ATM/FR, transmission, switched voice and others.
Metrica / NPR data management systems (DMR)
Metrica/NPR gets you up and running quickly, with preconfigured solutions for major network technologies. These Technology Layers include GSM, GPRS, UMTS, IP and Voice Switching. With Metrica/NPR you get all the benefits of a configurable, modular solution that you can easily extend and modify. It interprets and manages large volumes of data at high performance, provides comprehensive and easy to view performance information for business and operational users, identifies problem areas and discovers underlying trends before service-affecting problems occur and provides historical reporting and forecasts performance trends and helps to predict effects of network change.
OPTIMA by Aircom
Provides historical reporting and forecasts performance trends and helps to predict effects of network change.
Some typical uses of Optima for network operation and performance management are:
• Daily reporting of cell, site, BSC, MSC and transmission network performance.
• Daily reporting of any cluster of cell sites or network elements covering particular cities, roads or other geographical regions.
• Identification of performance anomalies across network regions.
• Overall monitoring of alarms and equipment operational status.
• Identification and strategic reporting of traffic hotspots and network locations generating high traffic and revenues.
Nokia Netact
• Integrated network and service management system for GSM/GPRS/EDGE/3G networks
• Modular, scalable and open solution for operating mobile networks
• Supports operator processes
• Provides smooth management evolution towards a more service oriented world
• Multi vendor
Ericsson OSS
Ericsson’s OSS-RC provides fault, performance and configuration management of Radio and Core networks.
Configuration Methods
• Export configuration data then import configuration changes through the OSS.
• Enter configuration changes via the OSS Graphical User Interface (GUI).
•Make configuration changes in the UTRAN via a ChangeAll script.
• Use EMAS (Element Manager Software). Call Trace Capability
Ericsson OSS supports three different types of call trace namely UETR, CTR and GPEH.
• UETR – User Equipment Traffic Recording
• CTR – Cell Traffic Recording
• GPEH – General Performance and Event Handling
Post-Launch Optimization Process
Testing and monitoring QoS in the UMTS network requires several kinds of analysis actions and network monitoring through the whole life cycle of the UMTS network, starting from the network element development and ending with the operation of the network. The protocol layers carrying signaling and user plane data have to be accessed and verified to ensure proper network performance. Protocol analysis and tracing of protocol messages are required for troubleshooting purposes and for finding the origins of any problems. For long term monitoring, the signaling and user plane traffic on the protocol layers must be recorded and analyzed with post-processing tools as well as with applications capable of visualizing real-time metrics and following certain Key Performance Indicators. Real time analysis is usually done using several of the OSS tools which help in recording and scheduling real time reports. These reports contain several KPIs which help in understanding any key problems in the network and also enable us to implement quick changes in the network in a very time efficient manner. Most reports provide key statistical reports such as traffic and RF measurements which enable to rectify problems and help in troubleshooting process without the need of any extra resources.
