A-RVS-UM2 Overview v2 3 PDF

Overview
Actix RVS for UMTS version 2.3
September 2005
Confidential and Proprietary
Copyright 1998-2005 Actix Ltd. All Rights Reserved.
No part of this publication may be copied, photocopied, reproduced, transmitted, transcribed, or

reduced to any electronic medium or machine-readable form without the prior written consent of
Actix Ltd.
All brand names and product names included in this book are trademarks, registered
trademarks, or trade names of their respective holders.
A-RVS-UM2 Rollout Verification Solution Overview September 2005
Contents
1 INTRODUCTION............................................................................................................3
2 OPERATIONAL TASKS AN D PROCESSES...............................................................4

2.1 SITE INTEGRATION AND INFRASTRUCTURE TESTING ...................................................6
2.2 DETAILED C ALL SEQUENCE ANALYSIS ........................................................................8
2.3 BENCHMARKING AND STATISTICAL ANALYSIS .............................................................9
2.4 RADIO L INK PERFORMANCE TROUBLESHOOTING......................................................10
2.5 EVENT D ETECTION AND D RIVE TEST ANALYSIS ........................................................12
2.5.1 Threshold Options......................................................................................12
2.5.2 Coverage Problems ...................................................................................13
2.5.3 Handover Problems ...................................................................................16
2.5.4 Missing Neighbours ...................................................................................17
2.5.5 Pilot Pollution .............................................................................................18
2.5.6 Too Many Servers......................................................................................18
3 FEATURE OVERVIEW................................................................................................20
3.1 ACTIX A PLATFORM .................................................................................................20
3.2 EVENT D EFINITIONS .................................................................................................20
3.2.1 CS domain-related events .........................................................................21
3.2.2 PS domain-related events .........................................................................26
3.2.3 RRC Connection Setup -related events ....................................................29
3.2.4 CS domain Mobility Management (MM) -related events ...........................32
3.2.5 Handover-related events ...........................................................................32
3.2.6 RAB-related events....................................................................................34
3.2.7 ID and Call Type Attributes ........................................................................35
3.2.8 UMTS Neighbour List (attributes Uu_UE_NbrList, Uu_UE_NbrListCount)36
3.3 APPLICATION L AYERS ..............................................................................................37
3.3.1 Neighbor List Analysis Module ..................................................................38
3.3.2 CPICH Pollution Analysis Module .............................................................41
3.3.3 Handoff State Analysis Module (for scanner)............................................43
3.3.4 Emulated Active Set Module......................................................................46
3.3.5 CPICH before RRC Connection Request Module.....................................47
3.3.6 CPICH before call end or drop Module .....................................................48
3.3.7 CPICH during call Module .........................................................................49
3.3.8 CPICH after call end or drop Module ........................................................50
3.3.9 Call Setup Status Module ..........................................................................51
3.3.10 Call Sequence Analysis Module ................................................................52
3.3.11 Call Statistics Module (CS or PS)..............................................................52
3.3.12 Call Sustainability Module..........................................................................54
3.3.13 Call Timing Analysis Module......................................................................55
3.3.14 File Summary Module................................................................................56
3.3.15 Coverage Summary Module......................................................................57
3.3.16 Handoff Breakdown Analysis Module (Handset).......................................58
3.3.17 SHO per event 1a-1b-1c Module...............................................................59
3.3.18 Overall BLER Module ................................................................................60
3.3.19 BLER Per call Module................................................................................60
Actix Confidential and Proprietary Page 1

3.3.20 BLER during SHO Module.........................................................................61

3.4 FILTERS ...................................................................................................................61
3.5 STATEFORMS ...........................................................................................................62
3.5.1 UMTS Data Event Navigator .....................................................................62
3.5.2 UMTS Data Session ..................................................................................63
3.5.3 UMTS Throughput .....................................................................................64
3.5.4 UMTS Top 10 Scan Measurements ..........................................................65
3.5.5 UMTS UE Active + Monitored Set.............................................................66
3.5.6 UMTS UE Call Information ........................................................................67
3.5.7 UMTS UE Measurements Charts ..............................................................68
3.5.8 UMTS UE Radio Parameters.....................................................................69
3.5.9 UMTS UE Transport Channel Info.............................................................70
3.5.10 UMTS Voice Event Navigator (CS Only)...................................................70
3.6 SUPPORTED DATA SOURCES FOR UMTS ..................................................................71
3.7 SUPPORTED PROTOCOL INTERFACES FOR UMTS.....................................................72
3.7.1 Uu Interface................................................................................................72
4 RVS BENEFITS AND ROI ..........................................................................................72

4.1 INCREASED EFFICIENCY ...........................................................................................72

1 Introduction
It is widely recognized that increasing productivity fuelled much of the global economic
expansion of the 1990s. Technological advances in software and hardware usually enable
these productivity improvem ents, although there is often a lag between the availability of the
new technology, and its widespread acceptance and deployment by industry. This gap is
sometimes called the productivity lag factor.
Some examples of this include the introduction of automated bank teller technology in the
1980s in the US. When the technology initially became available, it was only sparingly
deployed, and the units were often placed inside bank buildings where the productivity
enhancements they offered were limited. Likewise, unattended gasoline pump technology has
been slow to roll out in Europe, but as the technology has become widely adapted, huge
efficiency gains have been realized.
The wireless industry is now at a similar point. It understands that the traditional labor-intensive
techniques for maximizing performance and capacity in wireless infrastructure are
fundamentally limited by a lack of structured algorithms to determine improvements.
Actix Rollout Verification Solution (RVS) offers the possibility to look at drive test data and
scanner data to fully optimize a UMTS network. It allows the engineer to understand the causes
and reasons for drop calls and access failures.
RVS offers an unprecedented capability to execute a detailed examination of message flows
and automating statistical analyses of performance. RVS significantly accelerates the rollout,
troubleshooting and optimization of the UMTS network. Actix has embedded intelligence in the
software to allow the RF engineer to visualize specific events and understand real problems
occurring in the network.
Actix Solutions embody our extensive experience as the market leader in optimization solutions
for CDMA, UMTS and GSM. All of the lessons learned and the techniques developed over a 10-
year period have been incorporated into these powerful, vendor-independent solutions for
UMTS infrastructure.
RVS is part of the Actix A Platform family of solutions, a set of data-analysis software solutions
for streamlining the introduction of new wireless technologies and optimizing the performance of
both existing and new technologies.
This document provides an overview of the key benefits, applications and features of RVS. For
additional information on Actix Solutions, including white papers and other literature, please
refer to www.actix.com.

2 Operational Tasks and Processes

Actix Solutions embody our extensive experience as the market leader in optimization solutions
for CDMA, UMTS and GSM. All of the lessons learned and the techniques developed over a 10-
year period have been incorporated into these powerful, vendor-independent solutions for
cdma2000, GPRS and UMTS infrastructure.
The Actix Rollout Verification Solution is a novel solution to the challenge of rolling out,
troubleshooting and optimizing real UMTS networks. RVS may be used in field trial,
benchmarking and operational settings to automate the process of quantifying network
performance, thereby mitigating the risk of performance problems during commercial operation.
RVS offers an unprecedented capability to execute a detailed examination of message flows
and automating statistical analyses of performance. RVS significantly accelerates the rollout,
troubleshooting and optimization of the UMTS network. Actix has embedded intelligence in the
software to allow the RF engineer to visualize specific events and understand real problems
occurring in the network.
Applications addressed by RVS first become pertinent during the new technology rollout, as
shown in Figure 1. Then, as first-generation technology is rolled out for soft or commercial
launches, RVS continues to address a number of critical challenges. As new sites are coming
on air and more customers are accessing the network, the real challenge for the RF engineer is
to maximize the coverage, capacity and quality of service. RVS offers a number of applications
applicable to these ongoing challenges.
Rollout
Verification
Solution
R&D Initial Immature Mature

Trials Rollout Buildout Growth
Figure 1: Applicability of RVS begins in the Initial Rollout and continues throughout the lifecycle
of the network deployment
RVS is a powerful tool designed to help the RF engineer analyze data from scanner and
handset sources. It gives a detailed analysis during the whole drive route. From missing
neighbor to pilot pollution detection, the different embedded events give an absolute advantage
to the RF engineer in understanding the source of different problems.

Figure 2 depicts some of the major processes performed by engineering teams during the initial
rollout, immature buildout and mature growth phases ; and indicates the key radio-link
configuration tasks that are common across these processes. The following sections provide an
outline (plus additional details) of the processes and tasks typically performed during those
phases.
R&D / Trials Initial Immature Mature Phases

& Planning Rollout Buildout Growth
Site Calibration Initial Coverage

Initial Testing Analysis
Processes
Subscriber Perceived Radio Link

Performance Performance
On-going Network
Optimization Growth
Power Site Integration

Measurements and
Optimization
Service Throughput Event

Coverage and Rates
Tasks
Detections
Availability Calculation
Scanner and
Drive Tests Benchmarking
Analysis
Figure 2: Scanner and Drive tests analysis, Site Integration and Optimization are performed as
part of critical processes in the Initial Rollout, Immature Buildout and Mature Growth phases

RVS for UMTS allows the user to focus on the following tasks for site integration and testing,
coverage analysis, troubleshooting and optimization:
Site Integration and Infrastructure Testing
Detailed Call Sequence Analysis
Benchmarking and Statistical Analysis
Radio Link Performance Troubleshooting
Event Detection and Drive Test Analysis
The following sections describe the high-level capabilities of RVS for each of these applications.
Because RVS is based on an open architecture platform,which includes user-definable query
and open data import capabilities it may be used for many ad-hoc troubleshooting and
performance analysis tasks beyond those covered in this document.
2.1 Site Integration and Infrastructure Testing

Part of the process in rolling out a network is to be able to test and integrate new sites. RVS
provides the following features for site integration and infrastructure testing:
The file summary report allows the engineer to have a quick look at the overall
performance during the entire drive test.
Embedded charts and graphs help to visualize key parameters like Ec/No or RSCP in
the active set.
Detailed reports on call statistics on cell by cell basis
User-definable queries allow creation of customized statistical analysis
Automated report generation containing statistical summaries of key performance
indicator

Figure 3: Charts and graphs for UMTS site integration and infrastructure testing

2.2 Detailed Call Sequence Analysis

RVS provides these analyses of call sequence and call setup procedures:
Detailed call sequence analysis on a message by message basis
Automated report generation for visualization of call sequence messages
Automated report generation statistical summaries of call setup problems
Figure 4: Statistical summaries of call setup procedures and failure causes
Figure 5: Detailed call sequence analysis

2.3 Benchmarking and Statistical Analysis

RVS provides the following features for benchmarking and statistical analysis:
Automated report generation for quick visualization of call statistics such as drop calls,
access failures, call sustainability, etc.
Working with different sources of data to create homogeneous set of reports for
benchmarking
User-defined queries allowing easy access to different statistics
Figure 6: Charts and graphs representing different call statistics

Figure 7: Various call statistics filtered by cells
2.4 Radio Link Performance Troubleshooting

RVS may be used to diagnose and determine remedial action for key radio-link configuration
problems, including:
Distant servers
Too many servers
Unnecessarily large neighbor lists
Excessive soft handoff area
Figure 8: Identify problems for UMTS radio networks by visualizing

pilot signals as lines drawn to serving cells on a map

Radio Link Performance Metrics available from RVS will include the following attributes,
depending on the specific vendor and specific source (handset or scanner):
Mobile Transmit Power, Mobile Receive Power, BLER
CPICH Ec/No, Ec/Io and RSCP per scrambling code
Chip Offset and Delay Spread per SC
Ec/Io, RSCP and Pathloss for Nth best SCs
CPICH Ec/No and SC in Active and Monitored set
Handoff State, Call ID
Figure 9: Charts and graphs for a handoff state analysis

2.5 Event Detection and Drive Test Analysis

RVS has embedded intelligence that helps the engineer to detect problems in the UMTS
network. The event detection capabilities of RVS allow the engineer to visualize quickly a series
of problems. These problems include:
Coverage Problems
Handover Problems
Missing neighbors
Pilot Pollution
Too many servers
2.5.1 Threshold Options

RVS has thresholds allowing the engineer to define the levels of RSCP, Ec/No, Time Delay, etc.
necessary to peg events. The following thresholds are available:
Uu_EcNoInterferenceThreshold (Used in System Interference Section 2.5.2)

Recommended value is -15 dB and value should vary between -10 and -18 dB
Uu_RSCP_InterferenceThreshold (Used in System Interference Section 2.5.2)

Recommended value is -80 dBm and value should vary between -60 and -90 dBm
Uu_Poor_EcNoThreshold (Used in Coverage Limited, Poor Downlink and Poor Uplink

Coverage Section 2.5.2) Recommended value is -15 dB and value should vary
between -10 and -18 dB
Uu_Poor_RSCP_Threshold (Used in Coverage Limited, Poor Downlink and Poor Uplink

Coverage Section 2.5.2) Recommended value is -95 dBm and value should vary
between -85 and -105 dBm
Uu_HighUE_TxPower (Used in Poor Uplink Coverage Section 2.5.2) Recommended

value is 15 dBm and value should vary between 0 and 25 dBm
Uu_LowUE_TxPower (Used in Poor Downlink Coverage Section 2.5.2) Recommended

value is -15 dBm and value should vary between 0 and -30 dBm
Uu_CoverageLimitedUE_TxPowerThreshold (Used in Coverage Limited Section 2.5.2)

Recommended value is 10 dBm and value should vary between 0 and 25 dBm
Uu_PilotPollutionThreshold (Used in Pilot Pollution Section 2.5.5) Recommended

value is -15 dB and value should vary between -10 and -18 dB
Uu_CallSetupFailure_Num_RRCConnReq (Used in Call Setup Failure event - Section

3.2) Recommended value is 3 and value should vary between 1 and 5
Uu_CallSetupFailure_TimeDelay (Used in Call Setup Failure event - Section 3.2)

Recommended value is 2 and value should vary between 1 and 45 seconds

Uu_TooManyServersThreshold (Used in Too Many Server event Section 2.5.6

Recommended value is 5 dB and value should vary between 1 and 10 dB
Uu_t309_wait_timer (Used in CellChangeOrderfromUTRAN process)

Recommended value is 5000ms (5Sec) and value should vary between 5000 and
10000.
Uu_ReEstablishment_wait_timer (Used in ReEstablishment process) Recommended

value is 0ms and value should vary between 0 and 15000 Note: Zero dis enable this
feature.
Uu_wait_timer_complete (Used in Change Reconfig process) Recommended

value is 8000ms (8Sec) and value should vary between 0 and 15000 Note: Zero dis
enable this feature.
2.5.2 Coverage Problems

RVS has event detection that allows the engineer to visualize coverage problems based on
specific criteria. Here are the different events and the way they are detected:
System Interference:
The system interference event occurs when the CPICH_EcNo_in_ActiveSet is less than
Uu_EcNoInterferenceThreshold (in dB) and the CPICH_RSCP_in_ActiveSet is greater than
Uu_RSCP_InterferenceThreshold (in dBm).
Figure 10: Example of system interference before a dropped call

Poor Uplink Coverage:

The poor uplink coverage event occurs when the CPICH_EcNo_in_ActiveSet is greater than
Uu_Poor_EcNoThreshold and the CPICH_RSCP_in_ActiveSet is greater than
Uu_Poor_RSCP_Threshold and UeTransmittedPower is greater than Uu_HighUE_TxPower
threshold.
Figure 11: Example of poor uplink coverage before a dropped call
Poor Downlink Coverage:

The poor downlink coverage event occurs when the CPICH_EcNo_in_ActiveSet is less than
Uu_Poor_EcNoThreshold and the CPICH_RSCP_in_ActiveSet is less than
Uu_Poor_RSCP_Threshold and the UeTransmittedPower is less than Uu_LowUE_TxPower
threshold.
Figure 12: Example of poor downlink coverage before a dropped call

Coverage Limited:
The coverage limited event occurs when the CPICH_EcNo_in_ActiveSet is less than
Uu_Poor_EcNoThreshold and the CPICH_RSCP_in_ActiveSet is less than
Uu_Poor_RSCP_Threshold and the UeTransmittedPower is greater than
Uu_CoverageLimitedUE_TxPowerThreshold.
Figure 13: Example of coverage limited problem before a dropped call

2.5.3 Handover Problems

RVS has event detection that allows the engineer to visualize handover problems on a map with
drive test data. The handover problem event works as follows:
Event detection looks for a dropped call
It counts the number of times when the first best SC in the Monitored set is stronger than
the first best SC in the Active set, within an 8-second window leading up to the drop.
If that number is greater than the number of times the Active set is stronger than the
Monitored set, it sets a Handover problem (assuming we have no Active set update
messages)
Figure 14: Example of handover problems before a dropped call

2.5.4 Missing Neighbours

RVS has event detection that allows the engineer to visualize missing neighbour on a map with
drive test data. The missing neighbour event occurs when a particular SC is not in the
neighbour lis t and forces the call to drop. The following procedure is followed to trigger the
event.
When the drop call occurs, a specific function looks for the next origination and gets the value of
the new SC in the active set. If the new SC is different from the SCs in the active set before the
call dropped, the function looks for the last neighbour list before the call dropped. If that same
neighbour list does not contain the new SC, it is a possible missing neighbour.
So, in other words:
If (SC in active set after drop call) <> (SCs in active set before drop call and Neighbour list
before drop call) then missing neighbour
Of course, in this case, the engineer needs to understand the coverage issues. If the new SC is
not meant to cover the specific area, optimization is probably the best solution and the engineer
should not add the specific neighbour.
Figure 15: Example of missing neighbor before a dropped call

2.5.5 Pilot Pollution

RVS has event detection that allows the engineer to visualize pilot pollution on a map with drive
test data. The pilot pollution event occurs when 4 or more pilots with Ec/No greater than
Uu_PilotPollutionThreshold are in the active or monitored set.
The engineer needs to look at each SC and try to find out what is the best way to optimize the
area. See the training document for a full detailed description on optimization techniques.
Figure 16: Example of pilot pollution before a dropped call
For more information on optimizing a UMTS network, please visit Actixs web site at
www.actix.com or download the following document Optimization principles and antenna
patternsV3.doc from the whitepaper section.
2.5.6 Too Many Servers

Because UMTS uses relative levels to evaluate additions/removals to the active set, RVS has a
different event that allows the engineer to visualize pilot pollution relative to the best server.
The Too Many Servers event acts like the pilot pollution event except with relative levels. The
event occurs when 4 or more pilots with Ec/No within Uu_TooManyServersThreshold dB of the
best server (Uu_ActiveSet_EcNo_0) are in the active or monitored set.
The engineer needs to look at each SC and try to find out what is the best way to optimize the
area. See the training document for a full detailed description on optimization techniques.

Figure 17: Example of too many servers around a dropped call
For more information on optimizing a UMTS network, please visit Actixs web site at
www.actix.com or download the following document Optimization principles and antenna
patternsV3.doc from the whitepaper section.

3 Feature Overview
3.1 Actix A Platform

RVS is part of the A Platform family of solutions, and as such, cdma2000, GPRS and UMTS
solutions are fully compatible with each other and with GSM, IS-136 and EDGE solutions from
Actix. The A Platform provides a core set of capabilities to analyze network performance data:
Interfaces to a large number of network performance data sources
Support for a wide variety of wireless protocols from the air-interface to the core network
Filtering and binning module
Finite state event detection engine
Time-series and multi-dimensional statistical query module
Data merging and synchronization / correlation module
Mapping, charting, and reporting modules
Messaging and protocol stack browsers
Network element database
Open data import and export module
RVS includes all the flexibility of the A Platform, and so can be configured for a wide range of
network performance-data analysis tasks.
3.2 Event Definitions

The RF engineer can view the flow of messages through the Event Diagram Viewer. The figure
below shows an example of a diagram used to generate some of those events:
Figure 18: The Event Engine Viewer allows a user to follow

the flow of messages that leads to a specific event (Depicted is RRC layer & Outgoing CS)

In the following chapters, there are numerous events that are mentioned and used by one or
many application layers. The definitions of those events and how they are pegged within RVS
is provided over the next few pages. Please note that RVS now has separate event detection
for RRC Layer (Radio Resource Control), CS Incoming/Outgoing (Circuit Switch) and PS
(Packet Switch) calls. The messages marked with the symbol star (*) are usually present but
are not mandatory.
Note that an Annex has also been produced for use with this document: Additional Radio
Events for the PS domain in UMTS.
3.2.1 CS domain-related events
3.2.1.1 Outgoing Call OK (attribute Uu_OutgoingCallOk)

Uu_RRC_MsgType == RRC Connection Request (1)
o With Uu_RRC_RRCConnectionRequest_establishmentCause equals to:
RRC_OriginatingConversationalCall
RRC_ EmergencyCall
Uu_RRC_MsgType == RRC Connection Setup
Uu_RRC_MsgType == RRC Connection Setup Complete
GSM_Um_Msg_Type == MM CM Service Request (1)
GSM_Um_Msg_Type == MM Authentication Request (*)
GSM_Um_Msg_Type == MM Authentication Response (*)
Uu_RRC_MsgType == Security Mode Command (*)
Uu_RRC_MsgType == Security Mode Complete (*)
GSM_Um_Msg_Type == CC Setup (*)
GSM_Um_Msg_Type == CC Call Proceeding (*)
Uu_RRC_MsgType == Radio Bearer Setup (*)
Uu_RRC_MsgType == Radio Bearer Setup Complete (*)
GSM_Um_Msg_Type == CC Alerting OR CC Connect OR CC Connect Acknowledge
Also Outgoing OK is flag with the following

Uu_RRC_MsgType == RRC Connection Request
GSM_Um_Msg_Type == CC Setup
(1) At least one of those messages (RRC Connection Request, MM CM Service Request) needs to be present to initiate the call
setup.
3.2.1.2 Incoming Call OK (attribute Uu_IncomingCallOk)

Uu_RRC_MsgType == RRC Connection Request (2)
RRC_TerminatingConversationalCall
GSM_Um_Msg_Type == RR Paging response (2)
GSM_Um_Msg_Type == MM Authentication Request (*)

GSM_Um_Msg_Type == MM Authentication Response (*)

Uu_RRC_MsgType == Security Mode Command (*)
Uu_RRC_MsgType == Security Mode Complete (*)
GSM_Um_Msg_Type == CC Setup (*)
GSM_Um_Msg_Type == CC Call Proceeding (*)
Uu_RRC_MsgType == Radio Bearer Setup (*)
Uu_RRC_MsgType == Radio Bearer Setup Complete (*)
(2) At least one of those messages (RRC Connection Request, RR Paging Response) needs to be present to initiate the call setup.
3.2.1.3 Outgoing Call Setup Fail (attribute Uu_OutgoingCallSetupFail)

RRC_ EmergencyCall
OR
GSM_Um_Msg_Type == MM CM Service Request
Then any of the following options:

Uu_RRC_MsgType == RRC Connection Reject
OR
Timer Expiry based on 3GPP standards
OR
Uu_RRC_MsgType == RRC Connection Release
OR
o With Uu_RRC_RRCConnectionRequest_establishmentCause not equal to the
starting establishmentCause.
OR
Any BCCH messages or Release during the call setup
Note that the call flow diagram in the next section explains in more detail the call setup failures
and the different causes associated with them.

3.2.1.4 Incoming Call Setup Fail (attribute Uu_IncomingCallSetupFail)

TerminatingConversationalCall
OR
GSM_Um_Msg_Type == RR Paging response

OR
OR
Uu_RRC_MsgType == RRC Connection Release
OR
starting establishmentCause.
OR
Any BCCH messages or Release during the call setup
3.2.1.5 Call Setup Fail Cause (attribute Uu_CSCallSetupFailureCause)

This attribute indicates the method by which the Call Setup failure was detected
UE drop to Idle, indicates that RRC layer was drop
UE Forced to Idle, indicates that RRC released the RRC layer
NAS Release, the call was released by NAS layer
This attribute is only set if the is a RRC connected state, not during RRC Setup.
Note: The call flow diagram in the next section explains into more details the call setup failures
and the different causes associated with them.

3.2.1.6 CS Call Setup Diagram

Following 3GPP specifications (TS 25.331), during the RRC Connection phase, if expiry of timer
T300 (see threshold Uu_CallSetupFailure_TimeDelay) before RRC Connection Setup and V300
(Number of RRC Connection Requests) is greater than N300
(Uu_RRC_CallSetupFailure_Num_RRCConnReq), refer to point 1 and 2.
If V300 is less than or equal to N300, then reset timer T300 and V300 = V300 + 1.
If RRC Connection Setup or Setup Complete was received and the call fails to proceed after
that point, it would be considered as a call setup failure during the RRC Connection Setup.
Note: RRC Connection Setup & RRC Connection Reject message must have the same UE Identity as
the RRC Connection Request .
If the
call fails between the CM Service Request (or GPRS MM Serv ice Request for PS Calls) and the
CC Setup (or the end of the Security Mode Command Complete for PS calls), it would be
considered as a call setup failure during security procedures.

If the call fails between the CC Call Proceeding and the Radio Access Bearer Setup Complete,
it would be considered as a call setup failure during the RAB Setup procedure.
When any of the following messages is received, the call is considered as successful.
CC Alert
CC Connect
CC Connect Acknowledge
3.2.1.7 Drop call (attribute Uu_CallDropped)

When in Call (Outgoing Call Ok or Incoming Call Ok), you get any of the following
options:
o Any BCCH Message
OR
o Uu_RRC_MsgType == RRC Connection Release
OR
One of the following messages for CS Calls:
o (GSM_Um_Msg_Type == CC Disconnect) OR
o (GSM_Um_Msg_Type == CC Release Complete) OR
o (GSM_Um_Msg_Type == CC Release)
o AND any of the above messages with NOT a normal cause for ending the call
(CauseCodeCC is greater than 31)

3.2.1.8 Dropped Call Cause (attribute Uu_ CSCallDroppedCause)

This attribute indicates the method by which the Dropped call was detected
UE drop to Idle, indicates that RRC layer was drop
UE Forced to Idle, indicates that RRC released the RRC layer
NAS Release, the call was released by NAS layer
3.2.1.9 Call complete (attribute Uu_CallCompleted)

When in Call (Outgoing Call Ok or Incoming Call Ok), you get one of the following
messages:
o GSM_Um_Msg_Type == CC Disconnect (1) OR
o GSM_Um_Msg_Type == CC Release Complete OR
o GSM_Um_Msg_Type == CC Release
1. AND any of the above messages with a normal cause for ending the call
(CauseCodeCC is equal or less than 31)
3.2.2 PS domain-related events

Unlike in the CS domain, the definition of Call in the PS domain is subject to different
interpretations.
This paper explains the criteria used by Actix for the classification of a PS Call and the definition
of the related events.
It should be noted that besides PS Call related events and statistics Actix provides analysis of
other NAS specific procedures that are sometimes linked to the PS Call concept, like PDP
Context Activation/Deactivation.
The main criterion adopted by Actix for the definition of PS Call is:
There needs to be actual transfer of PS data
In fact in UMTS it is possible to establish a PDP Context without actually transfer any data (this
is typical of Always-on network). So the main trigger for the detection of PS Call is the attempt
to setup a PS Radio Bearer with rate greater than 0 kbps (some networks allow to establish a
dummy bearer of 0 kbps).
However, because many operators tend to identify a PS Call with the setup of a PDP context,
whenever it is applicable Session Management messages are used as trigger for setting
attributes like Successful/Failed PS Call Setup.
An Originating PS Call attempt is detected by one of the following triggers:
RRC: RRC Connection Request with Establishment Cause equal to any of the following:
o RRC_OriginatingStreamingCall
o RRC_OriginatingInteractiveCall
o RRC_OriginatingBackgroundCall

o RRC_OriginatingSubscribedTrafficCall
RRC: Radio Bearer Setup message with assignment of physical resources to that PS
Radio Bearer (PS Rate in DCH > 0 kbps) if PS call attempt not already detected 1
RRC: Radio Bearer Reconfiguration, with assignment of physical resources to that PS
Radio Bearer (PS Rate in DCH > 0 kbps) if PS call attempt not already detected 1
RRC: Transport Channel Reconfiguration, with assignment of physical resources to the
related PS Radio Bearer (PS Rate in DCH > 0 kbps) if PS call attempt not already
detected1
A Terminating PS Call attempt is detected with one of the following triggers:
RRC: RRC Connection Request with Establishment Cause equal to any of the following:
o RRC TerminatingStreamingCall
o RRC TerminatingInteractiveCall
o RRC TerminatingBackgroundCall
GMM: Service Request with Service Type equal to Paging Response
It should be noted that in the likely case that more than one of the above events occur during
the setup sequence only the first event (in time) is valid for the detection of the PS Call attempt.
In ther words if a PS Call attempt has been alre ady detected subsequent triggers do not detect
the PS call again.
3.2.2.1 Outgoing Call OK PS (attribute Uu_OutgoingCallOk_PS)
During the Originating PS Call Setup phase (i.e. an Originating PS Call Attempt has been
detected) each of the following events denotes a successful PS call setup:
RRC: Radio Bearer Setup Complete if PS Rate in DCH > 0 kbps and a PDP Context is
already active for that Radio Bearer
SM: Activation PDP Context Accept and the PS rate assigned during the RB Setup
procedure is greater than zero (NOTE: during the PDP Context activation a PS Radio
Bearer Setup procedure always occurs)
RRC: Radio Bearer Reconfiguration Complete, with assignment of physical resources to
that PS Radio Bearer (PS Rate in DCH > 0 kbps) if not already in call
RRC: Transport Channel Reconfiguration Complete, with assignment of physical
resources to the related PS Radio Bearer (PS Rate in DCH > 0 kbps) if not already in
call
1
A typical case is where a RB is setup either in DCH without configuring physical resources (Ch.Code) or in FACH

3.2.2.2 Incoming Call OK PS (attribute Uu_IncomingCallOk_PS )

During the Terminating PS Call Setup phase (i.e. a Terminating PS Call Attempt has been
detected) each of the following events denotes a successful PS call setup:
RRC: Radio Bearer Setup Complete if PS Rate in DCH > 0 kbps and a PDP Context is
already active for that Radio Bearer
SM: Activation PDP Context Accept and the PS rate assigned during the RB Setup
procedure is greater than zero (NOTE: during the PDP Context activation a PS Radio
Bearer Setup procedure always occurs)
RRC: Radio Bearer Reconfiguration Complete, with assignment of physical resources to
that PS Radio Bearer (PS Rate in DCH > 0 kbps) if not already in call
RRC: Transport Channel Reconfiguration Complete, with assignment of physical
resources to the related PS Radio Bearer (PS Rate in DCH > 0 kbps) if not already in
call
3.2.2.3 Outgoing Call Setup Fail PS (attribute Uu_OutgoingCallSetupFail_PS)

During the Originating PS Call Setup phase (i.e. an Originating PS Call Attempt has been
detected) and before reaching a PS Call successful Setup, each of the following events
denotes a PS call setup failure:
RRC: RRC Connection Reject (eg. Congestion)

RRC Connection Setup fails due to timer expiry (T300 x N300)
RRC: RRC Connection Release with cause other than Normal Release
UE drops to idle2
RRC: Radio Bearer Setup Failure
SM: PDP Context Activation Reject (without RB Setup Failure)
RRC: Radio Bearer Reconfiguration Failure
RRC: Transport channel Reconfiguration Failure
3.2.2.4 Incoming Call Setup Fail PS (attribute Uu_IncomingCallSetupFail_PS)

During the Terminating PS Call Setup phase (i.e. a Terminating PS Call Attempt has been
detected) and before reaching a PS Call successful Setup, each of the following events
denotes a PS call setup failure:
RRC: RRC Connection Reject (eg. Congestion)

RRC Connection Setup fails due to timer expiry (T300 x N300)
RRC: RRC Connection Release with cause other than Normal Release
UE drops to idle2
RRC: Radio Bearer Setup Failure
SM: PDP Context Activation Reject (without RB Setup Failure)
2
The algorithm use to detect a UE dropping to idle is based on one of the following events:
- SystemInfo messages from UE in Cell_DCH. The event is actually detected after an internal configurable
timer expires, in order to handle RRC re-establishment procedures
- RRC Connection Request from UE in Cell_FACH/Cell_PCH

RRC: Radio Bearer Reconfiguration Failure

RRC: Transport channel Reconfiguration Failure
3.2.2.5 Call complete PS (attribute Uu_CallCompleted_PS)

When in Call (Outgoing Call Ok PS or Incoming Call Ok PS), each of the following
events denotes a successfully completed PS call:
o Uu_RRC_MsgType == RRCConnectionRelease with cause Normal Release or
User inactivity
o Deactivation PDP Context Request with cause Regular deactivation
3.2.2.6 Drop call (attribute Uu_CallDropped_PS )

When in Call (Outgoing Call Ok PS or Incoming Call Ok PS), each of the following
events denotes a PS Call drop:
o Uu_RRC_MsgType == RRCConnectionRelease with cause other than Normal
Release and User inactivity
o UE drops to idle and do es not re-establish via RRC Connection re-establishment
procedure.
o Deactivation PDP Context Request with cause other than Regular deactivation
3.2.2.7 PS Call known issues in the current release

This is a list of PS Calls known issues that will be fixed in the next RVS release.
As described in the PS Call Attempt definition, the RB Setup message detects an
Originating Call if physical resources are allocated for that PS Radio Bearer. However in
the case of Service Type Data a Call Id is always assigned even when there are not
physical resources assigned (ie PS Rate = 0 kbps); this results in identifying possible PS
Call Setup failures even when PS Rate = 0kbps.
One of the triggers for a Call Successful completion or Call Drop is the RRC Connection
Release message sent by the RNC. It has been observed that if the UE does not release
the radio resources and complete a previously initiated procedure (maintaining the call
up) after the RRC Connection release the call is considered released/dropped anyway.
If during PDP Context Activation the logging tool skip the RB Setup message, the
message sequence stalls and restarts only when UE returns to idle, unless the network
sends a PDP context Reject.
3.2.3 RRC Connection Setup -related events
3.2.3.1 RRC Connection ID (attribute Uu_RRC_ID)

Uu_RRC_ID is a unique number asserted to a RRC connection. The Uu_RRC_ID is given a
number on the first RRC Connection Request this number is then maintained for the duration of
the connection.
Once the RRC is released or dropped the Uu_RRC_ID is set to zero on the next message.

Uu_RRC_ID
RRC Counter is set to 1
Start Of 0 Uu_RRC_ID is set to 0
File
Uu_RRC_ID is set to RRC Counter

RRC Connection Request 1 RRC Counter is set to RRC Counter +1
Thus RRC Coun ter now 2
1
RRC Connection Setup
1
RRC Connection complete
1
RRC Connection Release
Uu_RRC_ID is set to 0
0
Uu_RRC_ID is set to RRC Counter

2 RRC Counter is set to RRC Counter +1
RRC Connection Request
Thus RRC Counter now 2
RRC Connection Request 2 If still within the N300 & T300 time frame
3.2.3.2 RRC Connection Completed Outgoing Call (attribu te Uu_OutgoingRRC_ConnectionOk )

o With Uu_RRC_RRCConnectionRequest_establishmentCause equals any of the
following:
RRC_OriginatingStreamingCall
RRC_OriginatingInteractiveCall
RRC_OriginatingBackgroundCall
RRC_OriginatingSubscribedTrafficCall
RRC_emergencyCall
RRC_interRAT_CellReselection
RRC_interRAT_CellChangeOrder
RRC_Registration
RRC_detach
RRC_OrignatingHighPrioritySignalling

RRC_OrignatingLowPrioritySignalling
3.2.3.3 RRC Connection Completed Incoming Call (attribu te Uu_IncomingRRC_ConnectionOk)

o With Uu_RRC_RRCConnectionRequest_establishmentCause equals any of the
following:
TerminatingConvers ationalCall
TerminatingStreamingCall
TerminatingInteractiveCall
TerminatingBackgroundCall
TerminatingHighPrioritySignalling
3.2.3.4 RRC Connection Reject (attribute Uu_RRC_Reject)

o With Uu_RRC_RRCConnectionRequest_establishmentCause of any type
3.2.3.5 RRC Connection Abort (attribute Uu_RRC_Abort)

o With Uu_RRC_RRCConnectionRequest_establishmentCause of any type

starting establishmentCause
OR
OR
OR
Where the UE identity is set to default value
Uu_RRC_TMSI_and_LAI_GSM_MAP_tmsi[0],
Uu_RRC_P_TMSI_and_RAI_GSM_MAP_p_TMSI[0]
Uu_RRC_IMSI
Uu_RRC_IMEI_Digit
Uu_RRC_ESN_DS_41
Default is -1

3.2.3.6 RRC ReEstablishment (attribute Uu_ RRC_ReEstablishment)

When a Radio Link is determined dropped (See Above), you enter a state Wait for
ReEstablistment. A Reestablishment Attribute is set if you get one of the following within
the time period set by threshold Uu_ReEstablishment_wait_timer:
o Uu_RRC_MsgType == PhysicalChannelReconfigurationComplete
o Uu_RRC_MsgType == RadioBearerReconfigurationComplete
o Uu_RRC_MsgType == TransportChannelReconfigurationComplete
3.2.4 CS domain Mobility Management (MM) -related events
3.2.4.1 Location Update OK (attribute Uu_LocationUpdateOK)
GSM_Um_Msg_Type == MM Location Updating Request

GSM_Um_Msg_Type == MM Location Updating Accept
3.2.4.2 Location Update Fail (atteibute Uu_LocationUpdateFail)

GSM_Um_Msg_Type == MM Location Updating Reject
OR
Any BCCH messages during the Update Request process
3.2.5 Handover-related events
3.2.5.1 Handoff OK (attribute Uu_HandoffOk)

ActiveSetUpdate message (Uu_RRC_MsgType == ActiveSetUpdate)
ActiveSetUpdateComplete message (Uu_RRC_MsgType == ActiveSetUpdateComplete)
Note : This attribute is only incremented if the RRC event Diagram is in the RRC Connected State.
3.2.5.2 Handoff Failure (attribute Uu_HandoffFail)
ActiveSetUpdate message (Uu_RRC_MsgType == ActiveSetUpdate)

ActiveSetUpdateFailure message (Uu_RRC_MsgType == ActiveSetUpdateFailure)
3.2.5.3 Handover to GSM event OK (attribute Uu_Handover_toGSM)

HandoverfromUTRANcommand
Uu_RRC_MsgType == HandoverfromUTRANcommand-GSM
And then
GSM_Um_Msg_Type == RR Handover Complete
OR
GSM_Um_Msg_Type == RR Measurement Report for 10 concessive message

CellChangeOrderfromUTRAN
Uu_RRC_MsgType == CellChangeOrderfromUTRAN
And then
GSM_Um_Msg_Type == RR Channel Request
OR
GSM_Um_Msg_Type == RR Immediate Assignment
OR
GSM_Um_Msg_Type == RR Immediate Assignment Extended
Note : One of the above must be received before the expiry of the timer Uu_t309_wait_timer
3.2.5.4 Handover to GSM event Failure (attribute Uu_Handover_toGSM_Failure)

HandoverfromUTRANcommand
Uu_RRC_MsgType == HandoverfromUTRANcommand-GSM
And then
Uu_RRC_MsgType == HandoverFromUTRANFailure
OR
Any GSM or UMTS BCCH messages.
OR
GSM_Um_Msg_Type == RR Channel Request
OR
CellChangeOrderfromUTRAN
Uu_RRC_MsgType == CellChangeOrderfromUTRAN
And then
Uu_RRC_MsgType == CellChangeOrderFromUTRANFailure
OR
Any UMTS BCCH messages.
OR
Timer Expiry, which is configured by threshold Uu_T309_Wait_Timer
OR
3.2.5.5 Handover to UMTS event (attribute Uu_Handover_toUTRAN)

Handover to UMTS message
o Uu_RRC_MsgType == HandovertoUTRANcomplete
Note: that if a call is completed in GSM mode (after the handover from UTRAN to GSM), the call event will appear in
the GSM section of the Workspace Explorer window.

3.2.6 RAB-related events
3.2.6.1 RadioBearerSetup OK (attribute Uu_RadioBearerSetupOK)

RadioBearerSetup message (Uu_RRC_MsgType == RadioBearerSetup)
Then
RadioBearerSetupComplete message (Uu_RRC_MsgType ==
RadioBearerSetupComplete)
Also Uu_RadioBearerSetupOK if the following
RadioBearerSetup message (Uu_RRC_MsgType == RadioBearerSetup)

Then
UplinkDirectTransfer message (Uu_RRC_MsgType == UplinkDirectTransfer)
OR
DownlinkDirectTransfer message (Uu_RRC_MsgType == DownlinkDirectTransfer)
3.2.6.2 RadioBearerSetup Failure (attribute Uu_ RadioBearerSetupfFail)

RadioBearerSetup message (Uu_RRC_MsgType == ActiveSetUpdate)
Then
RadioBearerSetupFailure message (Uu_RRC_MsgType == ActiveSetUpdateFailure)
OR
RRC Layer has dropped.
3.2.6.3 RadioBearerRelease OK (attribute Uu_RadioBearerReleaseOK)

RadioBearerRelease message (Uu_RRC_MsgType == RadioBearerRelease)
Then
RadioBearerReleaseComplete message (Uu_RRC_MsgType ==
RadioBearerReleaseComplete)

3.2.6.4 RadioBearerRelease Failure (attribute Uu_RadioBearerRelease Fail)

RadioBearerSetup message (Uu_RRC_MsgType == RadioBearerRelease)
Then
RadioBearerSetupFailure message (Uu_RRC_MsgType ==
RadioBearerReleaseFailure)
OR
RRC Layer has dropped.
3.2.7 ID and Call Type Attributes

The table below give information on how the ID and Type attributes are set
RRC Request Cause Type Uu_RRC_ID Uu_Call_ID Uu_Call_ID_PS Uu_RRC_Call_type Uu _Call_type

RRC_originatingconversationalCall Increment Increment CS CS
RRC_originatingStreamingCall Increment Increment PS PS
RRC_originatingInteractiveCall Increment Increment PS PS
RRC_originatingBackgroundcall Increment Increment PS PS
RRC_originatingSubscribedCall Increment Other Other
terminatingConversationalCall Increment Increment CS CS
terminatingStreamingCall Increment Increment PS PS
terminatingInactiveCall Increment Increment PS PS
terminatingBackgroundCall Increment Increment PS PS
RRC_emergencyCall Increment Increment CS CS
RRC_interRAT_CellReselection Increment IRAT Other
RRC_interRAT_CellChangeOrder Increment IRAT Other
RRC_registration Increment REG Other
RRC_detach Increment DET Other
RRC_originatingHighPrioritySignalling Increment CS/PS Other
RRC_originatingLowPrioritySignalling Increment SMS Other
RRC_callRe_establishment Increment Other Other
terminatingHighPrioritySignalling Increment CS/PS Other
terminatingLowPrioritySignalling Increment SMS Other
terminatingCauseUnknown Increment Other Other

3.2.8 UMTS Neighbour List (attributes Uu_UE_NbrList, Uu_UE_NbrListCount)

These attributes are generated from Measurement Control signalling within file.
The Measurement Control messages are sent from the network to the UE during a RRC
connection. They can contain the list of the available neighbors (Scrambling codes) a UE should
consider in its measurement procedures. The first of these Measurement Control messages
usually is the setup Mode, meanwhile the concessive ones are modify mode (ie changing the
list).
After the RRC connection procedure the algorithm, considers the first Measurement Control
message to be the Setup and builds up a internal array of Scrambling Code with their
corresponding index numbers (from attributes Uu_RRC_NewIntraFreqCell_intraFreqCellID and
Uu_RRC_PrimaryCPICH_Info_primaryScramblingCode). This information is then used to populate
attributes Uu_UE_NbrList and Uu_UE_NbrListCount (ie the number of SCs in the array)
Concessive Measurement Control messages then modify this list, this continues until a new
RRC Setup procedure is deteched at which point the array is reset.
Note: If there are any missing Measurement Control message, this NBR list will become out of sync with the true
nbrlist being measured by the UE.

3.3 Application Layers

Application Layers are added to the A Platform to implement task or application specific
functionality. RVS includes the following application layers:
UMTS Accelerated Network Rollout Solution

o Neighbor List Analysis Module
o Handoff State Analysis Module
o CPICH Pollution Module
o Emulated Active Set Module
UMTS CPICH Level Analysis

o CPICH before RRC Connection Request Module
o CPICH before call end or drop Module
o CPICH during call Module
o CPICH after call end or drop Module
UMTS Call Setup Analysis

o Call Setup Status Module
o Call Sequence Analysis Module
UMTS Call Statistics

o Call Statistics Module
o Call Statistics PS Module
o Call Sustainability Module
o Call Timing Analysis Module
UMTS Drive Test Summary

o File Summary Module
o Coverage Summary Module
UMTS Handoff Analysis

o Handoff Breakdown Analysis Module
o SHO per event 1a-1b-1c Module
UMTS Quality Analysis

o Overall BLER Module
o BLER Per call Module
o BLER during SHO Module

3.3.1 Neighbor List Analysis Module

The Neighbor List Analysis provides an automated approach for generating optimal neighbor
lists and overcoming major service-degrading problems such as missing neighbors.
The key components of the neighbor-list analysis module are:
o Generation of recommendations for optimal neighbor list settings based on
UMTS/WCDMA scanner drive test data.
o Integration with Network Element Database to audit existing neighbor lists and suggest
changes, and to correlate non-unique measured data attributes such as Scrambling
Code with unique identifiers such as Sector ID.
The Neighbor List Module implements the following algorithm:
o Ec/Io measurements below a noise floor are filtered out of the data set before analysis.
o User definable binning is used to reduce the number of measurements points in each bin
to create one value per bin optionally, no binning at all can be applied and the analysis
will run on the full data set.
o At each point along the drive test, a list of prospective neighbors is accumulated as
indicated in Figure 19. If a neighbor signal is within a user-definable threshold of the best
server in the active set, then it is considered as a potential neighbor.
o Using the geographic information in the log file and the SC, the network element
database is searched to identify the Sector and Cell IDs of the SC.
o A symmetrical neighbor array is created in memory which records the number of times
each sector ID is seen as a prospective neighbor of another sector ID as shown in Table
1.
o Once all bins in the log file have been compiled into the symmetrical matrix, the results
are compared against actual neighbor lists contained in the network element database
and the following are calculated:
o a list of sector IDs included in the matrix, but not the actual neighbor list
o a list of sector IDs included in the actual list but not in the matrix

C D
Neighbour 2 Not a Neighbour
A
Best Server
B Drive Test
Neighbour 1
Route E
Excluded from Analysis
Figure 19: Cell A is the best server by CPICH Ec/Io. Cells B and C are within a user-specified
threshold of Cell As Ec/Io, and so are counted as potential neighbors of A. Cell D is not within
the required threshold and so is not counted as a prospective neighbor, nor is Cell E which did
not have a measurable signal contribution at this point in the drive test.
A B C D
A N/A 10 2 15
B 10 N/A 40 0
C 2 40 N/A 12
D 15 0 12 N/A
Table 1: A sample symmetric prospective neighbor array using sector IDs A, B, C, and D
Limitations of the algorithm:

o Results are only produced in areas that have been tested, so the test areas should be
carefully considered before removing any Sectors from the neighbor lists
o Drive tests do not necessarily emulate the radio environment encountered by pedestrian
and in-building users; however, walk tests and in-building tests may be included in the
analysis as desired

Results are presented in the following application reports:

o Neighbor List Summary
o Neighbor List Audit
o Recommended Neighbor Lists
Figure 20: A sample Recommended Neighbor Lists report

3.3.2 CPICH Pollution Analysis Module

The CPICH or Pilot Pollution Analysis uses an emulated Active Set to estimate which pilots
would have been actively demodulated by the UE, and then detects other pilots above a user-
definable threshold that cause excessive interference. Please see the Emulated Active Set
Module section for more details on how the Active Set is estimated based on WCDMA scanner
measurements.
The pilot pollution algorithm has these components:
o Ec/Io measurements below a noise floor are filtered out of the data set prior to analysis
o User definable binning is used to reduce the number of measurements points in each bin
to create one value per bin optionally, no binning at all can be applied and the anal ysis
will run on the full data set
o At each point along the drive test, CPICH Ec/Io data for each Scrambling Code is used
to assign SCs to an Active Set or a Pollution Set (please see the Emulated Active Set
Module section for more details)
o The Pollution Set consists of all SCs that are not in the Active Set, and have a CPICH
Ec/Io within a user specified pollution threshold of the strongest CPICH Ec/Io in the
Active Set (see Figure 21)
o Using the geographic information in the log file and the SC, the network element
database is searched to identify the Sector and Cell IDs of the SC
o A pollution array is created in memory which records the number of times each sector ID
is seen as a source of pilot pollution as shown in Table 2
o All bins in the log file are then processed into the pollution matrix

D
Pollution Source
C
Active Set
A
Active Set
B Drive Test
Active Set Route E
Not a Pollution Source, or in
Active Set
Figure 21: Cell A, B and C are part of the Active Set, as determined by the Emulated Active Set
module. Cell D has a CPICH Ec/Io within a user-specified pollution threshold of the Active Sets
best server Ec/Io, and so is counted as a contributor to pilot pollution at this point in the drive
test. Cell E has a CPICH Ec/Io that is not within this threshold and so is not a pollution source.
Sector ID Pollution
Count
A 0
B 150
C 45
D 12
Table 2: A sample pollution array indicating the number of points at which each sector caused
pilot pollution for sector IDs A, B, C, and D
Results are presented in the Pilot Pollution Analysis application report as shown in Figure 22. In
addition, Pilot Pollution may be geographically analyzed for each SC by accessing the
Pollution_for_SC attribute in the workspace view.

Figure 22: The Pilot Pollution Analysis report indicates the worst interferers sorted by
Scrambling Code
3.3.3 Handoff State Analysis Module (for scanner)

The Handoff State Analysis module uses the emulated Active Set to determine the handoff state
at each point along a drive test. Statistics on handoff state may then be calculated and
presented in a report format. Excessive handoff state reduces capacity and increase
infrastructure costs for a given traffic level. Please see the Emulated Active Set Module section
for more details on how the Active Set is estimated based on WCDMA scanner measurements.
The handoff state algorithm has the following components:
The Active Set of pilots is determined using the Emulated Active Set module
Using the geographic information in the log file and the SC, the network element
database is searched to identify the Sector and Cell IDs of the SC
Handoff state is calculated by determining the configuration of the sectors in the Active
Set as shown in Figure 23
All bins in the log file are then processed into the handoff state matrix
Reports showing the percentage of handoff state for each sector and for the total drive test may
then be calculated as shown in Figure 24.

Single -sector 3-way Softer
3 sectors
same node B
Softer Soft
handoff handoff
2 sectors
same node B
3-way soft Soft-softer

handoff
2 sectors
same node B
Figure 23: The Handoff State Analysis examines Sector IDs involved in call at a given drive test
point and determines which of the above states applies, based on UMTS scanner data

Figure 24: A report showing the percentage of drive test in each handoff state for scanner data

3.3.4 Emulated Active Set Module

CPICH Pollution Analysis and Handoff Analysis are both based on a calculated Active Set,
which is determined by the Emulated Active Set module. The Emulated Active Set module
implements the 3GPP handoff algorithm and uses scanner Ec/Io measurements in conjunction
with user-specific 3GPP handoff thresholds to emulate the Active Set at each point along a drive
test. Figure 25 shows a sample set of scanner data for three individual SCs with color and
vertical lines indicating transitions of pilots into and out of the Active Set.
Figure 25: Using Scanner Ec/Io measurements to implement 3GPP handoff algorithms for the
Active Set
Figure 26 shows the list of attributes available for modification by the user, as indicated in the
3GPP specifications:
Figure 26: Setting 3GPP handoff algorithm attributes including Reporting Range: Hysteresis
Event and Time to Trigger Event

3.3.5 CPICH before RRC Connection Request Module

The CPICH before RRC Connection Request module helps the engineer to understand the
environment right before the call started or to be more precise, before the first RRC connection
request happens. For every call in the log file, the report can show the following parameters:
Call Identification, based on the attribute Uu_Call_id
Time of the first RRC Connection Request for a specific call
Site the call was placed, based on the attribute ServingCellid
Scrambling Code the call originated on, based on the attribute Uu_ActiveSet_SC_0
Ec/Io of that same Scrambling Code, based on the attribute Uu_ActiveSet_EcNo_0
RSCP of that same Scrambling Code, based on the attribute Uu_ActiveSet_RSCP_0
or the calculated RSCP if the regular RSCP values are not present or were not logged.
Site, SC, Ec/Io and RSCP of the Monitored Set if applicable
End result of that particular call
For any of these parameters, the module searches 5 seconds before the first RRC Connection
Request for the specific details. If it cannot find the parameters during those 5 seconds, the
value No Data is shown.
Figure 27 shows a typical analysis executed by the CPICH before RRC Connection Request
module. For the engineer, it is an easy way to look at the conditions before the call started and
the end result.
Figure 27: Example of a log file analyzed by the CPICH before RRC Connection Request
module

3.3.6 CPICH before call end or drop Module

The CPICH before call end or drop module helps the engineer to understand the environment
right before the call ended or dropped. For every call in the log file, the report can show the
following parameters:
Call Identification, based on the attribute Uu_Call_id
Time when the call ended or dropped (see event definitions)
Site ID of the active site when the call ended or dropped (attribute ServingCellid)
Scrambling Code of the 1st finger in the Active Set
Ec/Io of that same Scrambling Code
RSCP of that same Scrambling Code
Figure 28 shows a typical analysis executed by the CPICH before call end or drop module. For
the engineer, it is an easy way to look at the conditions right before the call ended.
Figure 28: Example of a log file analyzed by the CPICH before call end or drop module

3.3.7 CPICH during call Module

The CPICH during call module helps the engineer to understand the environment during a
particular call. For every call in the log file, the report can show the following parameters:
Call Identification
Site ID of the most common active site (site associated with the scrambling code of the
first finger in the active set)
Most common Scrambling Code of 1st finger in the Active Set
Average Ec/Io during the entire call
Average RSCP during the entire call
Site ID of the most common monitored site (site associated with the scrambling code of
the first finger in the monitored set)
Most common Scrambling Code in the Monitored Set
Average Ec/Io during the entire call
Average RSCP during the entire call
Figure 29 shows a typical analysis executed by the CPICH during call module. For the engineer,
it is an easy way to look at the average conditions during the call.
Figure 29: Example of a log file analyzed by the CPICH during call module

3.3.8 CPICH after call end or drop Module

The CPICH after call end or drop module helps the engineer to understand the environment
right after the call ended or dropped. For every call in the log file, the report can show the
following parameters:
Call Identification
Time when the call ended or dropped
Site ID of the active site when the call ended or dropped
Scrambling Code of the 1st finger in the Active Set
Ec/Io of that same Scrambling Code
RSCP of that same Scrambling Code
Figure 30 shows a typical analysis executed by the CPICH after call end or drop module. For
the engineer, it is an easy way to look at the conditions right after the call ended.
Figure 30: Example of a log file analyzed by the CPICH after call end or drop module

3.3.9 Call Setup Status Module

The Call Setup Status module offers a general overview on how and when the call failed. The
normal call sequence should go like this:
A. RRC Connection Request (MOC) or Paging Type1 (MTC)
B. RRC Connection Setup
C. RRC Connection Complete
D. MM CM Service Request (MOC) or Paging Response (MTC)
E. MM CM Service Accept
F. Authentication Request
G. Authentication Accept
H. Security Mode Command
I. Security Mode Complete
J. CC Setup
K. CC Call Proceeding
L. Radio Bearer Setup
M. Radio Bearer Setup Complete
N. CC Alert
O. CC Connect
If all messages are received properly, the call is a success. If it fails to reach the CC Connect, it
should be pegged as a call failure and this module should give the reason for it. Refer to section
3.2 Event Definitions for more details.
Figure 31 shows a typical analysis executed by the call setup status module.
Figure 31: Example of a log file analyzed by the call setup status module

3.3.10 Call Sequence Analysis Module

The Call Sequence Analysis module offers a general overview on how call failed and when they
failed. This module has the same structure and analysis as the call setup status module except
for a few differences. It doesnt summarize as what is the cause of the failure. On the other
hand, it gives the call sequence with detailed information on every call and the outcome of it. It
gives the engineer the possibility to look at individual calls on a message by message basis.
Figure 32: Example of a log file analyzed by the call sequence analysis module
3.3.11 Call Statistics Module (CS or PS)

The Call Statistics Module helps the engineer to have a quick look at the overall performance
during a specific drive test. The following parameters ' statistics are defined in each file:
Total Number of calls: Number of Mobile Originated Calls (MOC) + Number of Mobile
Terminated Calls (MTC). This includes all calls, even failures.
Successful Incoming Calls: Number of successful Mobile Terminated Calls (MTC). To be
successful, a call needs to follow the call sequenc e as mentioned in section 3.2
Successful Outgoing Calls: Number of successful Mobile Originated Calls (MOC). To be
successful, a call needs to follow the call sequence as mentioned in section 3.2

Total Successful Calls: Successful

Incoming Calls + Successful
Outgoing Calls
Connected Percentage: Total
Successful Calls/Total number of
calls * 100
Call Failures Incoming: Access
Failure for a Mobile Terminated
Call (MTC) as defined in section
3.2
Call Failures Outgoing: Access
Failure for a Mobile Originated Call
(MOC) as defined in section 3.2
Access Failure Rate: Total Access
Failures/Total number of calls * 100
Total Drops: Total number of
dropped calls. A dropped call is
defined as one of the following:
Drop Rate percentage: Total
Drops/Total Successful Calls * 100
Total Completed Calls: Total
number of completed calls. A
completed call is defined as the
following:
Success Rate: Total completed
calls/Total Successful Calls * 100
Figure 33: Example of a log file analyzed by the

Call Statistics Module

3.3.12 Call Sustainability Module

The call sustainability module helps the
engineer to have a quick view at the
call duration for all calls during the drive
route. The statistic is calculated on a
per call basis and is the difference in
time when the call ends and when the
call starts. More precisely:
Call Sus tainability = Time when RRC
Connection request happens (or paging
type 1) Time when call drops or ends.
Figure 34 shows the call sustainability
statistics and the call duration
distribution.

call sustainability module

3.3.13 Call Timing Analysis Module

The Call Timing Analysis gives various time statistics on differences between specific
messages. In cases where the RRC Connection Request terminology is used, it relates to the
first RRC Connection Request message transmitted.
Figure 35: Example of a log file analyzed by the call timing analysis module

3.3.14 File Summary Module

The file summary module helps the
engineer to visualize quickly the content of
a file. The thresholds for the coverage and
quality charts are:
Coverage:
Good: RSCP > -80 dBm
Fair: -80 dBm >= RSCP >= -95
dBm
Poor: -95 dBm > RSCP
Quality:
Good: Ec/Io > -8 dB
Fair: -8 dB >= Ec/Io >= -15 dB
Poor: -15 dB > Ec/Io
Figure 36: Example of a log file analyzed

by the file summary module

3.3.15 Coverage Summary Module

The file summary module helps the engineer to visualize quickly the statistics related to the
strongest RSCP and the strongest Ec/No for a particular file.

coverage summary module

3.3.16 Handoff Breakdown Analysis Module (Handset)

The Handoff State Analysis module for
handset uses the Real Active Set from
the handset to determine the handoff
state at each point along a drive test.
Statistics on handoff state may then be
calculated and presented in a report
format. Excessive handoff state reduces
capacity and increase infrastructure
costs for a given traffic level. Please see
section 3.2.3 for more details on the
Handoff State Analysis for scanner.
The handoff state algorithm has the
following components:
Using the geographic
information in the log file and the
SC, the network element
database is searched to identify
the Sector and Cell IDs of the
SC
Handoff state is calculated by
determining the configuration of
the sectors in the Active Set as
shown in Figure 23 Section
3.3.3
All bins in the log file are then
processed into the handoff state
matrix Figure 38: Example of a log file analyzed by
The Actual SHO Overhead represents the handoff state analysis for handset
the sum of all soft-handoff
configurations
Reports showing the percentage of
handoff state for each sector and for the
total drive test may then be calculated
as shown in Figure 38.

3.3.17 SHO per event 1a-1b-1c Module

The SHO per event 1a-1b-1c module gives a brief summary about the different types of handoff
that occur in a file. It shows quickly the number of:
Addition: Event 1a
Removal: Event 1b
Replacement: Event 1c
Also, it reports the number of completion for each of those events and calculates a percentage
of success.

soft-handover performance module

3.3.18 Overall BLER Module

The overall BLER (Block Error Rate)
module gives a brief summary about the
distribution and statistical analysis of BLER
for an entire file.

Overall BLER module
3.3.19 BLER Per call Module

The BLER per call module gives a
summary of the main statistics associated
with the BLER on a call-by-call basis.
The maximum value
The minimum value
The average value for that
particular call

BLER per call module

3.3.20 BLER during SHO Module

The BLER during SHO (soft handover) module provides statistics on the downlink transport
channel BLER aggregated across all SHOs and on a call-by-call basis (note that only the calls
with BLER measurements during the SHO procedure will be included in this report.

BLER during SHO module
3.4 Filters
Filters are added to the A Platform to implement task or application-specific functionality. RVS
includes the following pre-defined filters:
Poor Mobile Receive Power
CPICH_RSCP_in_ActiveSet[0] < -95 dBm
High Mobile Transmit Power

UeTransmittedPower > 0 dBm
Low Mobile Transmit Power

UeTransmittedPower < -30 dBm
High Mobile Receive Power

CPICH_RSCP_in_ActiveSet[0] > -80 dBm

Poor Ec/No
CPICH_EcNo_in_ActiveSet[0] < -15 dB
High Ec/No
CPICH_EcNo_in_ActiveSet[0] > -8 dB
3.5 Stateforms
Stateforms are added to the A Platform to implement task or application-specific functionality.
RVS includes the following stateforms:
UMTS Data Event Navigator UMTS UE Call Information
UMTS Data Session UMTS UE Measurements Charts
UMTS Throughput UMTS UE Radio Parameters
UMTS Top 10 Scan Measurements UMTS UE Transport Channel Info
UMTS UE Active + Monitored Set UMTS Voice Event Navigator
3.5.1 UMTS Data Event Navigator

The UMTS Data Event Navigator stateform allows the engineer to view the entire drive test with
just one quick look. During a data session, it is possible to keep track of the following events:
GPRS_PDPContextAct_Successful GPRS_PDPContextAct_Failure
GPRS_PDPContextDeact_Successful GPRS_RAU_Successful
GPRS_Attach_Successful Event_Task_Start
GPRS_Detach_Successful
While keeping track of the current SC in the active set. Figure 42 shows an example of those
different events at different moments in time with the track at the top showing the SC.

UMTS Data Event Navigator Stateform

3.5.2 UMTS Data Session

The UMTS Data Session stateform allows the engineer to view the data testing information
collected during a data session.

UMTS Data Session Stateform

3.5.3 UMTS Throughput

The UMTS Throughput stateform chart allows the engineer to view the application and IP
downlink throughput graphically for the entire drive test. This information comes from the data
testing information collected during the drive test.

UMTS Throughput Stateform

3.5.4 UMTS Top 10 Scan Measurements

The UMTS Top 10 Scan Measurements stateform allows the engineer to view important details
regarding the scanner measurements. The following parameters are displayed at any specific
moment during the drive test replay:
Top 10 Scrambling Code based on their Ec/Io
Top 10 Ec/Io for these respective SC
Top 10 RSCP for these respective SC
Global RSSI

UMTS Top 10 Scan Measurements Stateform

3.5.5 UMTS UE Active + Monitored Set

The UMTS UE Active + Monitored Set stateform allows the engineer to visualize rapidly the
content of the active and monitored sets at any specific moment during the drive test. The
following parameters are represented for both the active and the monitored sets.
The Scrambling Code
The Ec/No for each of those scrambling code
The RSCP for each of those scrambling code
The Pathloss if applicable
It is a very quick way for the engineer to follow the active and monitored sets. Using the replay
tool, the engineer can follow the drive test and analyze very quickly any particular events.

UMTS UE Active + Monitored Set Stateform

3.5.6 UMTS UE Call Information

The UMTS UE call information stateform allows the engineer to have a quick view at the
following events:
IMSI Mobiles Identification number used for testing
Called Party Number called for that particular test/call
Calling Party In case of mobile terminated calls, the number of the party that called
Call id The call identification based on the UMTS call tracker
Call State The state the mobile is on. Different states are:
o Init
o Idle
o RRC Con Request
o RRC Con Setup
o RRC Setup Complete
o Outgoing Call Setup
o Incoming Call Setup
o Paging
o In Call
o Security Mode Command
o Security Complete
o CC Setup
o Authentication Request
o Authentication Response
o CC Call Proceeding
o RAB Setup
o RAB Complete
o Channel Reconfig
o Radio Bearer Reconfig
o GSM Mode
LAC
RAC


UMTS UE Call Information Stateform
3.5.7 UMTS UE Measurements Charts

The UMTS UE Measurements Charts stateform allows the engineer to look at the most
important information in a log file. It is very easy to visualize rapidly the following parameters:
EcNo Uu_ActiveSet_EcNo
RSSI UTRA_UE_CarrierRSSI
TxPower UE_TxPow
SIR Uu_SIR
SIR_Target Uu_TargetSIR

UMTS UE Measurements Charts Stateform

3.5.8 UMTS UE Radio Parameters

The UMTS UE Radio Parameters stateform allows the engineer to view radio parameters at a
specific moment during the drive test. The available parameters are:
TxPower
RSSI
SIR
SIR Target
UTRA_ARFCN_DL

UMTS UE Radio Parameters Stateform

3.5.9 UMTS UE Transport Channel Info

The UMTS UE Transport Channel Info allows the engineer to visualize the BLER per channel
and also the aggregate BLER.

UMTS UE Transport Channel Info Stateform
3.5.10 UMTS Voice Event Navigator (CS Only)

The UMTS Voice Event Navigator stateform allows the engineer to view the entire drive test
with just one quick look. During a session, it is possible to keep track of the following events:
Uu_OutgoingCallOK Uu_IncomingCallSetupFail
Uu_IncomingCallOK Uu_CallDropped
Uu_OutgoingCallSetupFail Uu_CallCompleted
While keeping track of the current SC in the active set. Figure 51 shows an example of those
different events at different moments in time with the colored track at the top showing the SC.
Figure 52: Example of a log file analyzed by the UMTS Voice Event Navigator Stateform

3.6 Supported data sources for UMTS

UMTS A-R VS is designed to support the following performance data sources for a wide variety
of test equipment vendors:
User Equipment (Test and Commercial)
CPICH Scanners
UE Trace Programs
IP Sniffer
Uu COM
Node B UE
Test Mobile IP Sniffer

and Scanner
Figure 53: Data sources for performance information

from UMTS Radio Networks in RVS.
Please refer to www.actix.com for a white paper entitled 3G Radio Network Performance
Measurement and Analysis Basics, which provides background information on UMTS
performance data sources.

3.7 Supported protocol interfaces for UMTS

The following network interface is currently supported for RVS, subject to technical feasibility:
Uu
Data may be obtained from the network interfaces using the test equipment specified in Section
3.6. Initial support is for 3GPP Release 1999 specifications, with support for later versions
(Version 4 and 5) to follow. If you are using a later version of one of these, please note that
Actix can provide upgrades for the UMTS interface support.
3.7.1 Uu Interface
The 3G air interface uses the following specifications in order to decode each protocol stack
layer:
3GPP Uu L3 TS24008-371 (Release 99 June 2001)
3GPP Uu RRC TS25331-370 (Release 99 June 2001)
L1 measurements vendor-specific
4 RVS Benefits and ROI

RVS streamlines and de-risks the rollout of UMTS networks during the critical launch phase and
optimization. Some of the key benefits of RVS are that it:
Assesses commercial readiness of infrastructure by quantifying performance, minimizing
the risk of delayed commercial service launches and major post-launch service problems
Supports early-availability test equipment to allow infrastructure performance
measurement before commercial user equipment becomes widely available
Reduces time and resources required to quantify network performance and to
troubleshoot abnormal performance issues during optimization
Works with all 2G, 2.5G and 3G solutions from Actixthe availability of an update
service for the latest standards revisions allows ongoing use of a single platform for
rollout verification
4.1 Increased efficiency

In 2000, the UK government put up for auction five licenses for Third Generation mobile
telephones that were sold for about 22.5 billion. This is a huge investment before even buying
infrastructures or equipments. However, with the growth that UK has had in the past few years
in mobile telephony (see figure 53), there are still plenty of opportunities for deploying 3G, in the
UK or many other countries .

Figure 54: Growth of UK mobile telephony
The optimization during such rapid growth can be a nightmare for some operators. The initial
network will definitely be different after a few months. The number of customers will increase
dramatically. It is very important for the operators to understand the value of a good optimization
tool. RVS helps the engineers in understanding the problems and recognizing faults that occur
throughout the network.
In the fast-moving world of 3G, making the right decision at the right moment is a key factor in
developing a reliable network. New technologies are driving the digital world; people are asking
for more services and more quality. So it is mandatory to rely on the best people and the best
tools. RVS helps reduce the time to market without compromising the performance and the
quality of your network.
Assuming that an operator expects one million new customers in the first year, a delay of three
months in the launch date can represent up to 250,000 customers. With an Average Revenue
Per User of 75 euros and a growth of 80,000 customers per month, this represents a loss of 36
million euros. As these are customers that might sign up with another company, actual losses
may be higher than this.
RVS allows the engineer to optimize the network with some detailed anaysis and embedded
intelligence. By finding and solving problems quickly, operators can save time and money,
beating the competition in a fierce environment.
With the deployment of new technology like UMTS in Europe and Asia, there are always a
number of factors that are out of an operator's control, such as the availability of user
equipment. However, with the presence of test equipment and the quick turnaround of RVS
decodes, engineers can visualize problems as they come and test the network without
compromising quality and performance.

With profitability being a key component of any business plan, any processing tool that helps
reduce costs is a considerable asset. Rolling out new networks can involve expensive
consultancy overheads, but by standardizing the processes and creating a common work
envrionment, it is easier to transmit knowledge and ensure you retain important acquired skills.
With the easy-to-use open architecture of RVS, engineers can create queries, graphs, statistics
and reports and share them throughout the company, saving time and money and bringing
positive value to any internal development.
Where the global economy is redefining the way of doing business, RVS provides a solution for
positioning operators in a commanding position for the future.

A-RVS-UM2 Overview v2 3 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A-RVS-UM2 Overview v2 3 PDF

Uploaded by

Copyright:

Available Formats

Overview

Actix RVS for UMTS version 2.3

Copyright 1998-2005 Actix Ltd. All Rights Reserved.

No part of this publication may be copied, photocopied, reproduced, transmitted, transcribed, or

2 OPERATIONAL TASKS AN D PROCESSES...............................................................4

Actix Confidential and Proprietary Page 1

3.3.20 BLER during SHO Module.........................................................................61

4 RVS BENEFITS AND ROI ..........................................................................................72

Actix Confidential and Proprietary Page 2

Actix Confidential and Proprietary Page 3

2 Operational Tasks and Processes

R&D Initial Immature Mature

Actix Confidential and Proprietary Page 4

R&D / Trials Initial Immature Mature Phases

Site Calibration Initial Coverage

Subscriber Perceived Radio Link

Power Site Integration

Service Throughput Event

Actix Confidential and Proprietary Page 5

2.1 Site Integration and Infrastructure Testing

Actix Confidential and Proprietary Page 6

Actix Confidential and Proprietary Page 7

2.2 Detailed Call Sequence Analysis

Figure 4: Statistical summaries of call setup procedures and failure causes

Figure 5: Detailed call sequence analysis

Actix Confidential and Proprietary Page 8

2.3 Benchmarking and Statistical Analysis

Figure 6: Charts and graphs representing different call statistics

Actix Confidential and Proprietary Page 9

Figure 7: Various call statistics filtered by cells

2.4 Radio Link Performance Troubleshooting

Figure 8: Identify problems for UMTS radio networks by visualizing

Actix Confidential and Proprietary Page 10

Figure 9: Charts and graphs for a handoff state analysis

Actix Confidential and Proprietary Page 11

2.5 Event Detection and Drive Test Analysis

2.5.1 Threshold Options

Uu_EcNoInterferenceThreshold (Used in System Interference Section 2.5.2)

Uu_RSCP_InterferenceThreshold (Used in System Interference Section 2.5.2)

Uu_Poor_EcNoThreshold (Used in Coverage Limited, Poor Downlink and Poor Uplink

Uu_Poor_RSCP_Threshold (Used in Coverage Limited, Poor Downlink and Poor Uplink

Uu_HighUE_TxPower (Used in Poor Uplink Coverage Section 2.5.2) Recommended

Uu_LowUE_TxPower (Used in Poor Downlink Coverage Section 2.5.2) Recommended

Uu_CoverageLimitedUE_TxPowerThreshold (Used in Coverage Limited Section 2.5.2)

Uu_PilotPollutionThreshold (Used in Pilot Pollution Section 2.5.5) Recommended

Uu_CallSetupFailure_Num_RRCConnReq (Used in Call Setup Failure event - Section

Uu_CallSetupFailure_TimeDelay (Used in Call Setup Failure event - Section 3.2)

Actix Confidential and Proprietary Page 12

Uu_TooManyServersThreshold (Used in Too Many Server event Section 2.5.6

Uu_t309_wait_timer (Used in CellChangeOrderfromUTRAN process)

Uu_ReEstablishment_wait_timer (Used in ReEstablishment process) Recommended

Uu_wait_timer_complete (Used in Change Reconfig process) Recommended

2.5.2 Coverage Problems

Figure 10: Example of system interference before a dropped call

Actix Confidential and Proprietary Page 13

Poor Uplink Coverage:

Figure 11: Example of poor uplink coverage before a dropped call

Poor Downlink Coverage:

Figure 12: Example of poor downlink coverage before a dropped call

Actix Confidential and Proprietary Page 14

Figure 13: Example of coverage limited problem before a dropped call

Actix Confidential and Proprietary Page 15

2.5.3 Handover Problems