Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Page 1 of 85
BASIC TUNING...................................................................................................................................2
1.1
KPIS AND SERVICE REQUIREMENTS..............................................................................................2
1.1.1
IRAT Performance....................................................................................................................2
1.1.2
CS Performance.......................................................................................................................2
1.1.2.1
1.1.3
CS Requirements......................................................................................................................3
PS Performance.......................................................................................................................4
1.1.3.1
PS Requirements......................................................................................................................5
1.2
TOOLS............................................................................................................................................8
1.2.1
Tools Requirements..................................................................................................................8
1.2.1.1
1.2.1.2
1.2.1.3
1.2.2
RF Measurements...................................................................................................................11
Throughput Measurements....................................................................................................12
Call Performance....................................................................................................................13
1.2.2.1
1.2.2.2
1.3
PRE-LAUNCH OPTIMIZATION PROCESS........................................................................................24
1.3.1
Database Verification.............................................................................................................25
1.3.2
Drive Test Route Selection.....................................................................................................26
1.3.3
Drive Test Data Collection.....................................................................................................28
1.3.4
Data Post-processing and Root-Cause Analysis....................................................................29
1.3.5
Root Cause Analysis and Recommendation...........................................................................30
1.3.5.1
1.3.5.2
1.3.5.3
1.3.5.4
1.3.5.5
1.3.5.6
1.3.5.7
1.3.5.8
1.3.5.9
1.3.6
2
Page 2 of 85
1. Basic Tuning
1.1 KPIs and Service Requirements
1.1.1 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.
1.1.2 CS Performance
Channel Utilization
Page 3 of 85
Signaling Load
DL Power Outage %
SHO Overhead
Bs TXP
1.1.2.1
CS Requirements
These two KPIs 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
Page 4 of 85
A typical retainability requirement for a network is Drop Call Rate < 1.5%
for voice conversations.
1.1.3 PS Performance
Ping Delay (ms): Delay for an individual Ping Response during the current
Ping session.
PS and CS Bearers
Attach / Context
Page 5 of 85
1.1.3.1
PS Requirements
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
Page 6 of 85
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
(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:
Page 7 of 85
Page 8 of 85
in the band.
UE UL TxPwr: The total UE transmitted power on one carrier.
Transport CH BLER: Estimation of the transport channel block error rate.
Call event success rate: Formula: # Call Ends / (# Call Ends + # Blocked
Calls + # Dropped Calls)
SHO event success rate: Formula: (# add + # remove + # replace) / # all
SHO
1.2 Tools
1.2.1 Tools Requirements
Different tools are required to accomplish basic tuning in UMTS network.
RF Test Tools
Analyze traffic,
Page 9 of 85
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.
Page 10 of 85
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.
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.
Page 11 of 85
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.
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.
1.2.1.1
RF Measurements
Page 12 of 85
DL RSSI (dBm)
Pilot Scanner
DL RSSI (dBm)
1.2.1.2
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
Page 13 of 85
Ping Delay (ms): Delay for an individual Ping Response during the
current Ping session.
1.2.1.3
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
Retainability
Page 14 of 85
Mobility
Quality
Page 15 of 85
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.
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
Page 16 of 85
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
Page 17 of 85
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
Page 18 of 85
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.
1.2.2.1
A laptop, which store the measurements data and run the drive test
software.
Scanner
HUB
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
inCode CONFIDENTIAL and PROPIETARY
Page 19 of 85
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:
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
Quantify
wireless
data
users
quality
of
service
(with
data
measurement options).
Perform integrated analysis using the phone and receiver at the same
time
Page 20 of 85
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
Page 21 of 85
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
Data and service testing
Streaming Video
IP Protocol Trace
Data throughput UL/DL
Ftp, http, and ping test applications.
MMS and SMS testing
Page 22 of 85
1.2.2.2
Post-Processing Software
Page 23 of 85
Page 24 of 85
Page 25 of 85
Basic Tuning
Database Verification
Performance Monitor
Drive Test
Performanc
e Report
Test User
Complain
Performance Analysis
Parameters
Tuning
Mechanical
Tuning
Performance Review
No
Meet
Project
Target
Yes
Finish
Purpose
inCode CONFIDENTIAL and PROPIETARY
Page 26 of 85
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.
Page 27 of 85
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.
Page 28 of 85
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.
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.
Page 29 of 85
Make sure all the Phones, Scanners, Scanner Antennas, 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 PNs and the Antenna orientations.
Set up the FTP server with a suitable file for testing of Data Download
and upload speeds.
Open at least one window for the Map, The phone data, Scanner Data,
and the Summary data for all the devices.
Page 30 of 85
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.
Performance statistics
Performance recording
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
Page 31 of 85
1.3.5.1
Page 32 of 85
Page 33 of 85
1.3.5.2
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).
Page 34 of 85
1.3.5.3
1.3.5.4
Page 35 of 85
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.
1.3.5.5
UL RSSI is high.
Page 36 of 85
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.
1.3.5.6
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:
Page 37 of 85
A
C
during
random
access
or
uplink
DPCH
synchronization procedures.
Page 38 of 85
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.
1.3.5.7
Page 39 of 85
Page 40 of 85
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.
1.3.5.8
Page 41 of 85
Many cells in the monitored set slow down the search for pilot
channel
Recommendation
The usefulness of the handover relationships should be reviewed
and the unnecessary relationships should be removed
1.3.5.9
Page 42 of 85
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.
Recommendation
The cell (re)-selection parameters (i.e. QqualMin, QrxlevMin, UE
Max Transmission Power) should be reviewed and adjusted to
suitable values.
Page 43 of 85
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.
Page 44 of 85
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
PS Background
Maximum bit rate
Allocation Retention Priority (ARP)
Transport channel type: e.g. HS-DSCH, DCH, FACH, RACH
Page 45 of 85
QoS Monitoring
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
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.
Page 46 of 85
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.
Page 47 of 85
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.
RAB Management
Page 48 of 85
Bearer Reliability
Page 49 of 85
Both Bearer Accessibility and Reliability product of the two KPIs above
result in RAB Success Ratio
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
RRC.FailConnEstab.Cause.
cause
measurement
Page 50 of 85
The
end
value
of
this
time,
denoted
as
sent
is
Page 51 of 85
added
to
the
relevant
per
cause
measurement
RRC.AttConnRel.Cause.
Page 52 of 85
Indicator
Measure
Service accessability
Ec/No, RSCP
Admission control
RAB assignment
Service integrity
Voice quality
Service retainability
Dropped calls
Handover failure
No coverage
Interference
Indicators
Measures
Service accessability
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.
Service retainability
Page 53 of 85
2.2 Tools
This section gives an overview of the standard Tool setup in collecting,
monitoring
and
analyzing
Performance Indicators.
UMTS
performance
counters
and
Key
Page 54 of 85
PM
Server
PM Client
Citrix
Server
Mun
Core Network
OSS
Iu
Mur
RNC
Iur
Mub
RNC
Mub
Iub
Router
Node B
OSS PM
Client
Node B
UE
OSS/OMC Setup
Management,
Performance
and
Fault
Management.
Page 55 of 85
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:
Alarm monitoring
Page 56 of 85
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
Page 57 of 85
Nokia Netact
Integrated
network
and
service
management
system
for
GSM/GPRS/EDGE/3G networks
Multi vendor
Ericsson OSS
Ericssons
OSS-RC
provides
fault,
performance
and
configuration
Configuration Methods
Page 58 of 85
Page 59 of 85
OMC
Reports
Recording
Definition
Node B
RNC
OSS Applications
Recording
Data
Moreover, statistical
It
Page 60 of 85
and showing the results of the QoS measurements, and the QoS server
software for processing the gathered information.
software performs all the analysis of the information captured from the
UMTS interfaces.
Current setup in the network has a built-in QoS Monitoring in the
OSS/OMC or as a third party application supported by the OSS/OMC
vendor. Raw data from the counter measurement tables are fetched and
converted in database or text format by a Mediation application. These
data are then available for the OSS Performance application and third
party Performance Monitoring application.
QoS
GUI
Statistics
Statistics
Measurement
Measurement
Call Trace
Call Trace
QoS
DB
Probe
Capacity
Capacity
Measurement
Measurement
QoS Monitor
Software
Probe
Probe
The basic features of the QoS Monitoring system are for statistics
measurements, capacity measurements and call tracing.
Root Cause Analysis.
As the amount of UMTS subscribers quickly increases, operators and
equipment vendors are facing big challenges in maintaining and
troubleshooting their networks.
Page 61 of 85
down
the
problem
investigation
into
logical
manageable pieces?
MT Call
Paging
Paging
MO Call
RRC
RRC
Connection
Connection
Establishment
Establishment
RAB
RAB
Establishment
Establishment
User-Plane
User-Plane
Data
Flow
Data Flow
Before investigating and solving KPI triggered faults, make sure the
following has been performed:
1. The general alarm status of the network has been checked. No
clear network alarms pointing to the root cause of the fault can be
detected.
2. Traces from external interfaces of RNC have been taken with a
protocol analyser in order to record the fault scenario. Also RNC
internal trace has been taken when the fault took place.
Page 62 of 85
Page 63 of 85
Page 64 of 85
The KPIs are useful because they give a first overview of network quality
and behavior and they may also be helpful to identify possible problems in
defined areas of the network. However, simple counters and simple ratio
formulas are often not enough. For instance, if the already defined GRPS
Attach Failure Ratio is calculated per SGSN, it can be used to indicate
whether there is an extremely high rate of rejected GPRS Attach Requests
in a defined SGSN area. However, such a high Attach Failure Ratio does
not need to indicate a network problem by itself. Always a further analysis
is necessary to find the root cause of network behavior. Based on the root
cause analysis it can be determined whether there are problems or not.
This procedure is also called drill-down analysis.
In case of rejected GPRS attach, the first step of analysis will always be to
check the reject cause value of the Attach Reject message. A value that is
often seen here is the cause network failure. From 3GPP 24.008
(Mobility Management, Call Control, Session Management) it is known
that the cause value network failure is used if the MSC or SGSN cannot
service an MS generated request because of PLMN failures, e.g.
problems in MAP. A problem in MAP may be caused by transmission
problems on Gr interface between SGSN and HLR. The address of a
subscribers HLR is derived from IMSI and the best way to analyze the
procedure is to follow up the MAP signaling on Gr interface after GRPS
Attach Request arrives at SGSN. On Gr it can be seen whether there is a
response from HLR or not and how long does it take until the response is
received.
Common reasons why GPRS attach attempts are rejected with cause
network failure are
Page 65 of 85
The first two reasons indicate network problems that shall be solved to
improve the general quality of network service. The latter two reasons
show a correct behavior of the network that prevents misusage of network
resources by unauthorized subscribers.
This example shows how difficult it is to distinguish between good cases
(no problem) and bad cases (problem) in case of a single reject cause
value. In general, four main features can be identified as main
requirements of good KPI analysis:
Page 66 of 85
Cause type
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Transport layer cause
Protocol cause
Protocol cause
Protocol cause
Protocol cause
Protocol cause
Protocol cause
Miscellaneous cause
Miscellaneous cause
Radio layer network cause
Description
Relocation Triggered
Unable to Establish During Relocation
Requested Ciphering and/or Integrity Protection algorithms not Supported
Failure in the Radio Interface Procedure
Requested Traffic Class not available
Invalid RAB Parameters Value
Invalid RAB Parameters Combination
Condition Violation for SDU Parameters
Invalid RAB ID
Interaction with other procedure
Request superseded
Iu Transport Connection Failed to Establish
Transfer Syntax Error
Semantic Error
Message not compatible with receiver state
Abstract Syntax Error (Reject)
Abstract Syntax Error (Ignore and Notify)
Abstract Syntax Error (Falsely Constructed Message)
No Resource Available
Unspecified Failure
Other causes
Requested guaranteed bit rate not available
Cause type
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Transport layer network cause
Transport layer network cause
Description
Unknown C-ID
Cell not available
Power level not supported
DL radio resources not available
UL radio resources not available
RL Already Activated/allocated
Node B Resources unavailable
Requested configuration not supported
Unspecified
Invalid CM setting
Number of DL codes not supported
Number of UL codes not supported
UL SF not supported
DL SF not supported
Dedicated Transport Channel Type not supCM not supported
Transport resource unavailable
Unspecified
NBAP
NBAP
NBAP
NBAP
NBAP
NBAP
Internal
Page 67 of 85
Protocol cause
Miscellaneous cause
Miscellaneous cause
Miscellaneous cause
Miscellaneous cause
Miscellaneous cause
Cause type not applicable
Protocol error
Control processing overload
OAM intervention
Hardware failure
Not enough user plane processing resources
unspecified
No Reply
Cause type
Failure cause (RRC)
Failure cause (RRC)
Failure cause (RRC)
Failure cause (RRC)
Failure cause (RRC)
Failure cause (RRC)
Failure cause (RRC)
Failure cause (RRC)
Cause type not applicable
Description
Configuration unsupported
Physical channel failure
Incompatible simultaneous reconfigurations
Protocol error
Compressed mode runtime error
Cell update occurred
Invalid configuration
Configuration incomplete
No Reply
Cause type
Failure cause (RRC)
Failure cause (RRC)
RRC
RRC
RRC
RRC
RRC
RRC
Internal
Description
Configuration unsupported
Physical channel failure
Incompatible simultaneous
reconfigurations
Protocol error
Compressed mode runtime error
Cell update occurred
Invalid configuration
Configuration incomplete
NoReply
Cause type
RRC
RRC
RRC
RRC
RRC
RRC
RRC
Description
Configuration
unacceptable
Physical channel failure
Protocol error
Inter-RAT Protocol error
Configuration
unacceptable
Physical channel failure
Protocol error
Protocol
Page 68 of 85
Cause type
RRC
RRC
RRC
RRC
RRC
RRC
RRC
Description
Configuration
unacceptable
Physical channel failure
Protocol error
Inter-RAT Protocol error
Configuration
unacceptable
Physical channel failure
Protocol error
Iu Release
Iu release request causes
Protocol
RANAP
RANAP
RANAP
RANAP
RANAP
RANAP
RANAP
RANAP
RANAP
Cause type
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Miscellaneous cause
Description
Failure in the Radio Interface Procedure
Release due to UTRAN Generated Reason
User inactivity
Iu UP failure
Repeated Integrity Checking Failure
Release due to UE generated signaling connection reDirected retry
Radio Connection With UE Lost
OAM intervention
Cause type
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
NAS Cause
Miscellaneous cause
Radio layer network cause
Radio layer network cause
Radio layer network cause
Miscellaneous cause
Description
Relocation Cancelled
Successful Relocation
Release due to UTRAN Generated Reason
User inactivity
Iu UP failure
No Remaining RAB
Release due to UE generated signaling connection release
Directed retry
Normal Release
Unspecified Failure
Other causes
Failure in the Radio Interface Procedure
Repeated Integrity Checking Failure
Radio Connection With UE Lost
OAM intervention
Admission Control
Causes for admission control rejections
Protocol
Internal
Internal
Internal
Cause type
Non-standard cause
Non-standard cause
Non-standard cause
Internal
Non-standard cause
Page 69 of 85
Description
Maximum uplink load
Maximum downlink load
Code allocation failure
Congestion Control is
ongoing
Failures due to
Intrafrequency handovers triggered by radio conditions,
mobility
Interfrequency Handovers triggered by
capacity and
coverage
Intersystem Handovers (ISHO) triggered
by mobility and
2) Gauge Counter:
inCode CONFIDENTIAL and PROPIETARY
Page 70 of 85
Page 71 of 85
There are vendor specific raw counters which can be formulated for
different KPIs and that gives a statistical insight of the network
performance.
Drop Call
The un-normal release of a connection UTRAN originated is indicated
either by the RAB RELEASE REQUEST message or the IU RELEASE
REQUEST message transmitted from the RNC to the CN. The RAB
RELEASE REQUEST message will be used when the failure occurs in the
RAB management as e.g. firmware failure PRLC, DHT. In any case the
UE is still reachable via a RRC connection. The IU RELEASE REQUEST
message is used in case the UE is lost at the air interface. The CN will
Page 72 of 85
is incremented by the
Page 73 of 85
About 70% of the drops occur in the UTRAN side and the remaining
occurs in interfaces between CN and UTRAN. Major reasons for drop calls
is abnormal RAB release due to
1) Unknown C-ID
The Node B is not aware of the cell with provided C-ID. This can
happen when a foreign cell is using the network. The switch database
must be data filled with this ID to prevent future drops.
2) Radio Resources not Available
The Node B does not have sufficient radio resources available. This
needs an increase in node capacity.
Page 74 of 85
DL coverage
DL interference
High DL BLER
High UL Tx Power
No Data
Not Classified
Handover Failures
There are three types of handover performed by UMTS network,
1. Intrafrequency triggered by radio conditions, mobility
2. Interfrequency Handovers triggered by capacity and coverage
3. Intersystem Handovers (ISHO) triggered
UMTS coverage
The common failure reasons are,
Page 75 of 85
Configuration Unsupported
If UTRAN instructs the UE to use a configuration that it does not
support, the UE shall set the IE failure cause to configuration
unsupported. This usually happens when UE goes from UMTS
coverage area to GSM area.
Page 76 of 85
The counters used for intra RNC and inter RNC handovers are:
Page 77 of 85
Paging Load
Basic Rule
Page 78 of 85
Same RA as LA
UL / DL Power Balancing
Output Power of common control channels
Code Planning
Parameter Tuning
O & M Aspects
Parameter consistency
Software status
Detecting Crossed Feeders
Measurement Principles
Some Optimization examples done on live UMTS network:
1 Optimization of ISHO Thresholds
There is a main parameter in the ISHO procedure that determines whether to
leave the 3G network for the 2G network (connected mode) on RSCP or
EcNo. Even if these parameters are link (through the RSSI), there are rather
independent and it is difficult to guaranty a certain level of RSCP by a
level of EcNo and vice versa.
On IDF, we noticed that at RSCP levels of -100dBm the quality of the radio
links was rather poor and therefore it was difficult to correctly keep the
connection alive till the ISHO operation successes.
Page 79 of 85
There are 3 events involved in the ISHO procedures namely e2d, e2f and
e3a.
ed2 compressed mode activation UE starts measuring 2G cells based
on the 3G2G neighbors list
e2f compressed mode deactivation
e2f @ -97dBm
C
M
e2f @ -96dBm
e3a @ -97dBm
e3a @
-103dBm
BEFORE
e2d @ -98dBm
AFTER
The UE goes into CM 2dB early thus it guaranty a better quality of the RL.
The main modification is that e3a is higher than e2d which mean that
the UE is allowed to go on GSM has soon as the best suitable 2G cell is
found.
Remark: The procedure works correctly only and only if the 3G2G neighbor
plan is optimized
Page 80 of 85
FDD_Qmin
Qqualmin + Ssearch-RAT
Page 81 of 85
behavior is due to the fluctuating radio conditions. The actual margin of 4dB is
considered wide enough to regulate this effect.
Parameter modification: Qrxlevmin
It was noticed on the measurements made in connected mode that there are
situations where the UE goes back and forth between the 2G and 3G
networks. The 3G-2G reselection is necessary to control when the UE is
allowed to go (or should go) on the 3G network but the ping-pong is a side
effect of this procedure: the UE is in an undetermined state.
Hence, it is important to reduce this effect because:
- It reduces the availability of the UE (especially for video calls)
- It decreases the life time of the battery of the UE
- It loads the RNC with signalling for network selection management in
IDLE mode.
The proposition is to modify the Qrxlevmin 3G from -111dBm to the minimal
value of -115dBm
Remark: T0 is the 17th of February 2005. The period of observation is from
the 31st of January 2005 to the 6th of March 2005
Interpretations:
The inter-RAT cell reselection is a good criterion to know the rate of network
switching between 3G and 2G.
A low inter-RAT cell reselection rate means that you stay whether on the 3G
or the 2G network.
In our case we stay longer on the 3G network because the minimum level of
3G cell eligibility is lowered giving easier access to 3G cells
Page 82 of 85
Conclusions:
Page 83 of 85
EcNo
P CPICH 1 Best Active cell
Reporting
Range
P CPICH 2
Monitored cell
Event 1A
Event 1A'
Time
SHO
area
When e1a is received the RNC performs a last try: if the procedure fails
then all the RL are released.
If there is a procedure e1a in progress when the e1a is received then all
the RL are released also if the procedure fails
e1a is triggered every reporting interval several attempts are allowed
since the radio links are not released after SHO failure
If the UE goes too deep inside the service area of cell 2 (with cell 2 as
neighbour and cell 1 as serving cell) then if the SHO attempt fails the
procedure asks to release the RL to avoid interferences on cell 2
The settings of event e1a are sent in the second measurement control
message right after the definition of SHO events e1a, e1b and e1c. To
distinguish the 2 measurement report types the measurement identity is
Page 84 of 85
set to 9 for e1a and to 14 for e1a. The event e1a inherits the settings of
event e1a except for the triggering threshold defined as follow:
Re1a = Re1a Roffset, with Re1a 0
Description of the problem
The parameter Roffset was initially set to 0dB such that e1a and e1a have
the same triggering threshold.
With this original setting events e1a and e1a are sent at the same time
resulting in a release of the radio links in case of SHO addition failure.
Indeed, as the e1a is sent to release the call in case of SHO failure.
Therefore, all e1a are pre-empted by e1a events.
Lower CDR
Page 85 of 85