Actix Overview

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 2 INTRODUCTION............................................................................................................3 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 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
September 2005
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
Page 2
September 2005
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 10year 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.
Page 3
September 2005
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 10year 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 Trials Initial Rollout Immature Buildout Mature 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.
Page 4
September 2005
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 & Planning
Initial Rollout
Immature Buildout
Mature Growth
Phases
Site Calibration Initial Testing
Initial Coverage Analysis
Processes
Subscriber Perceived Performance Radio Link Performance
On-going Optimization
Network Growth
Power Measurements
Site Integration and Optimization Event Detections
Service Coverage Availability
Throughput and Rates Calculation
Tasks
Scanner and Drive Tests Analysis
Benchmarking
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
Page 5
September 2005
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
Page 6
September 2005
Figure 3: Charts and graphs for UMTS site integration and infrastructure testing
Page 7
September 2005
2.2

Detailed Call Sequence Analysis

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
RVS provides these analyses of call sequence and call setup procedures:
Figure 4: Statistical summaries of call setup procedures and failure causes
Figure 5: Detailed call sequence analysis
Page 8
September 2005
2.3

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
RVS provides the following features for benchmarking and statistical analysis:
Figure 6: Charts and graphs representing different call statistics
Page 9
September 2005
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
Page 10
September 2005
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
Page 11
September 2005
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
Page 12
September 2005
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) value is 8000ms (8Sec) and value should vary between 0 and 15000 enable this feature. Coverage Problems Recommended
Note: Zero dis
2.5.2
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
Page 13
September 2005
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 Actix Confidential and Proprietary Page 14
September 2005
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
Page 15
September 2005
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
Page 16
September 2005
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
Page 17
September 2005
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.
Page 18
September 2005
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.
Page 19
September 2005
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)
Page 20
September 2005
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
3.2.1.1
CS domain-related events
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 o With Uu_RRC_RRCConnectionRequest_establishmentCause equals to: RRC_OriginatingConversationalCall GSM_Um_Msg_Type == CC Setup GSM_Um_Msg_Type == CC Alerting OR CC Connect OR CC Connect Acknowledge
(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) o With Uu_RRC_RRCConnectionRequest_establishmentCause equals to: RRC_TerminatingConversationalCall Uu_RRC_MsgType == RRC Connection Setup Uu_RRC_MsgType == RRC Connection Setup Complete GSM_Um_Msg_Type == RR Paging response (2) GSM_Um_Msg_Type == MM Authentication Request (*) Page 21
September 2005
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
(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)
Uu_RRC_MsgType == RRC Connection Request o With Uu_RRC_RRCConnectionRequest_establishmentCause equals to: RRC_OriginatingConversationalCall RRC_ EmergencyCall GSM_Um_Msg_Type == MM CM Service Request
OR
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 Setup Uu_RRC_MsgType == RRC Connection Release OR OR Any BCCH messages or Release during the call setup Uu_RRC_MsgType == RRC Connection Request o With Uu_RRC_RRCConnectionRequest_establishmentCause not equal to the starting establishmentCause.
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.
Page 22
September 2005
3.2.1.4
Incoming Call Setup Fail (attribute Uu_IncomingCallSetupFail)
Uu_RRC_MsgType == RRC Connection Request o With Uu_RRC_RRCConnectionRequest_establishmentCause equals to: TerminatingConversationalCall
OR GSM_Um_Msg_Type == RR Paging response
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 Setup Uu_RRC_MsgType == RRC Connection Release OR OR
3.2.1.5
Uu_RRC_MsgType == RRC Connection Request o With Uu_RRC_RRCConnectionRequest_establishmentCause not equal to the starting establishmentCause. Any BCCH messages or Release during the call setup
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.
Page 23
September 2005
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. Actix Confidential and Proprietary Page 24
September 2005
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)
Page 25

3.2.1.8 Dropped Call Cause (attribute Uu_ CSCallDroppedCause)
September 2005
This attribute indicates the method by which the Dropped call was detected
3.2.1.9
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
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
Page 26
A-RVS-UM2 Rollout Verification Solution Overview o RRC_OriginatingSubscribedTrafficCall
September 2005
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
A typical case is where a RB is setup either in DCH without configuring physical resources (Ch.Code) or in FACH
Page 27
September 2005
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
Outgoing Call Setup Fail PS (attribute Uu_OutgoingCallSetupFail_PS)
3.2.2.3
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:
3.2.2.4
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 A ctivation Reject (without RB Setup Failure) RRC: Radio Bearer Reconfiguration Failure RRC: Transport channel Reconfiguration Failure
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:
2
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)
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
Page 28

3.2.2.5
September 2005
RRC: Radio Bearer Reconfiguration Failure RRC: Transport channel Reconfiguration Failure
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
Drop call (attribute Uu_CallDropped_PS )
3.2.2.6
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. RRC Connection Setup -related events
RRC Connection ID (attribute Uu_RRC_ID)
3.2.3
3.2.3.1
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.
Page 29
September 2005
Uu_RRC_ID
Start Of File
RRC Counter is set to 1 Uu_RRC_ID is set to 0
RRC Connection
Request
1 1
Uu_RRC_ID is set to RRC Counter RRC Counter is set to RRC Counter +1 Thus RRC Coun ter now 2
RRC Connection Setup
1
RRC Connection complete
1 1 0
Uu_RRC_ID is set to 0
RRC Connection
Release
RRC Connection
Request
Uu_RRC_ID is set to RRC Counter RRC Counter is set to RRC Counter +1 Thus RRC Counter now 2
RRC Connection
Request
If still within the N300 & T300 time frame
3.2.3.2
RRC Connection Completed Outgoing Call (attribu te Uu_OutgoingRRC_ConnectionOk )
Uu_RRC_MsgType == RRC Connection Request o With Uu_RRC_RRCConnectionRequest_establishmentCause equals any of the following: RRC_OriginatingConversationalCall RRC_OriginatingStreamingCall RRC_OriginatingInteractiveCall RRC_OriginatingBackgroundCall RRC_OriginatingSubscribedTrafficCall RRC_emergencyCall RRC_interRAT_CellReselection RRC_interRAT_CellChangeOrder RRC_Registration RRC_detach RRC_OrignatingHighPrioritySignalling Page 30
A-RVS-UM2 Rollout Verification Solution Overview RRC_OrignatingLowPrioritySignalling Uu_RRC_MsgType == RRC Connection Setup Uu_RRC_MsgType == RRC Connection Setup Complete
September 2005

3.2.3.3
RRC Connection Completed Incoming Call (attribu te Uu_IncomingRRC_ConnectionOk)

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

3.2.3.5
Uu_RRC_MsgType == RRC Connection Request o With Uu_RRC_RRCConnectionRequest_establishmentCause of any type Uu_RRC_MsgType == RRC Connection Reject
RRC Connection Abort (attribute Uu_RRC_Abort)
Uu_RRC_MsgType == RRC Connection Request o With Uu_RRC_RRCConnectionRequest_establishmentCause of any type
Then any of the following options: Uu_RRC_MsgType == RRC Connection Request o With Uu_RRC_RRCConnectionRequest_establishmentCause not equal to the starting establishmentCause OR Timer Expiry based on 3GPP standards 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 Uu_RRC_MsgType == RRC Connection Setup Uu_RRC_MsgType == RRC Connection Request
Page 31

3.2.3.6 RRC ReEstablishment (attribute Uu_ RRC_ReEstablishment)
September 2005
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
3.2.4.1
CS domain Mobility Management (MM) -related events

Location Update OK (attribute Uu_LocationUpdateOK)

3.2.4.2
GSM_Um_Msg_Type == MM Location Updating Request GSM_Um_Msg_Type == MM Location Updating Accept

Location Update Fail (atteibute Uu_LocationUpdateFail)
GSM_Um_Msg_Type == MM Location Updating Request GSM_Um_Msg_Type == MM Location Updating Reject OR GSM_Um_Msg_Type == MM Location Updating Request Any BCCH messages during the Update Request process 3.2.5
3.2.5.1
Handover-related events
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
Page 32
A-RVS-UM2 Rollout Verification Solution Overview 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)
September 2005
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 Uu_RRC_MsgType == RRC Connection Request 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 Uu_RRC_MsgType == RRC Connection Request
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.
Page 33
September 2005
3.2.6
3.2.6.1
RAB-related events
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)

Page 34

3.2.6.4 RadioBearerRelease Failure (attribute Uu_RadioBearerRelease Fail)
September 2005
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 RRC_originatingconversationalCall RRC_originatingStreamingCall RRC_originatingInteractiveCall RRC_originatingBackgroundcall RRC_originatingSubscribedCall terminatingConversationalCall terminatingStreamingCall terminatingInactiveCall terminatingBackgroundCall RRC_emergencyCall RRC_interRAT_CellReselection RRC_interRAT_CellChangeOrder RRC_registration RRC_detach RRC_originatingHighPrioritySignalling RRC_originatingLowPrioritySignalling RRC_callRe_establishment terminatingHighPrioritySignalling terminatingLowPrioritySignalling terminatingCauseUnknown
Uu_RRC_ID Increment Increment Increment Increment Increment Increment Increment Increment Increment Increment Increment Increment Increment Increment Increment Increment Increment Increment Increment Increment
Uu_Call_ID Increment
Uu_Call_ID_PS Increment Increment Increment
Uu_RRC_Call_type CS PS PS PS Other CS PS PS PS CS IRAT IRAT REG DET CS/PS SMS Other CS/PS SMS Other
Uu _Call_type CS PS PS PS Other CS PS PS PS CS Other Other Other Other Other Other Other Other Other Other
Increment Increment Increment Increment Increment
Page 35
September 2005
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.
Page 36
September 2005
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 o o o Neighbor List Analysis Module Handoff State Analysis Module CPICH Pollution Module Emulated Active Set Module
UMTS CPICH Level Analysis o o o o CPICH before RRC Connection Request Module CPICH before call end or drop Module CPICH during call Module CPICH after call end or drop Module
UMTS Call Setup Analysis o o Call Setup Status Module Call Sequence Analysis Module
UMTS Call Statistics o o o o Call Statistics Module Call Statistics PS Module Call Sustainability Module Call Timing Analysis Module
UMTS Drive Test Summary o o File Summary Module Coverage Summary Module
UMTS Handoff Analysis o o Handoff Breakdown Analysis Module SHO per event 1a-1b-1c Module
UMTS Quality Analysis o o o Overall BLER Module BLER Per call Module BLER during SHO Module
Page 37
September 2005
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
Page 38
September 2005
C
Neighbour 2
D
Not a Neighbour
A Best Server B
Neighbour 1
Drive Test 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 A B C D 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
Page 39
A-RVS-UM2 Rollout Verification Solution Overview Results are presented in the following application reports: o Neighbor List Summary o Neighbor List Audit o Recommended Neighbor Lists
September 2005
Figure 20: A sample Recommended Neighbor Lists report
Page 40
September 2005
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 userdefinable 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
Page 41
September 2005
D C
Active Set Pollution Source
A
Active Set
B
Active Set
Drive Test 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 A B C D
Pollution Count 0 150 45 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.
Page 42
September 2005
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.
Page 43
September 2005
Single -sector
3-way Softer
3 sectors same node B Softer handoff Soft 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
Page 44
September 2005
Figure 24: A report showing the percentage of drive test in each handoff state for scanner data
Page 45
September 2005
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
Page 46
A-RVS-UM2 Rollout Verification Solution Overview 3.3.5 CPICH before RRC Connection Request Module
September 2005
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
Page 47
A-RVS-UM2 Rollout Verification Solution Overview 3.3.6 CPICH before call end or drop Module
September 2005
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 Site, SC, Ec/Io and RSCP of the Monitored Set if applicable End result of that particular call
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
Page 48
A-RVS-UM2 Rollout Verification Solution Overview 3.3.7 CPICH during call Module
September 2005
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 End result of that particular 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
Page 49
A-RVS-UM2 Rollout Verification Solution Overview 3.3.8 CPICH after call end or drop Module
September 2005
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 Site, SC, Ec/Io and RSCP of the Monitored Set if applicable End result of that particular call
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
Page 50
A-RVS-UM2 Rollout Verification Solution Overview 3.3.9 Call Setup Status Module
September 2005
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. B. C. D. E. F. G. H. I. J. K. L. M. N. O. RRC Connection Request (MOC) or Paging Type1 (MTC) RRC Connection Setup RRC Connection Complete MM CM Service Request (MOC) or Paging Response (MTC) MM CM Service Accept Authentication Request Authentication Accept Security Mode Command Security Mode Complete CC Setup CC Call Proceeding Radio Bearer Setup Radio Bearer Setup Complete CC Alert 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
Page 51
A-RVS-UM2 Rollout Verification Solution Overview 3.3.10 Call Sequence Analysis Module
September 2005
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
Page 52
A-RVS-UM2 Rollout Verification Solution Overview 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
September 2005
Figure 33: Example of a log file analyzed by the Call Statistics Module
Page 53
A-RVS-UM2 Rollout Verification Solution Overview 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.
September 2005
Figure 34: Example of a log file analyzed by the call sustainability module
Page 54
A-RVS-UM2 Rollout Verification Solution Overview 3.3.13 Call Timing Analysis Module
September 2005
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
Page 55
September 2005
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
Page 56
A-RVS-UM2 Rollout Verification Solution Overview 3.3.15 Coverage Summary Module
September 2005
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.
Figure 37: Example of a log file analyzed by the coverage summary module
Page 57
A-RVS-UM2 Rollout Verification Solution Overview 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
September 2005
The Actual SHO Overhead represents 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.
Figure 38: Example of a log file analyzed by the handoff state analysis for handset
Page 58
September 2005
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.
Figure 39: Example of a log file analyzed by the soft-handover performance module
Page 59
A-RVS-UM2 Rollout Verification Solution Overview 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.
September 2005
Figure 40: Example of a log file analyzed by the 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
Figure 41: Example of a log file analyzed by the BLER per call module
Page 60
A-RVS-UM2 Rollout Verification Solution Overview 3.3.20 BLER during SHO Module
September 2005
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.
Figure 42: Example of a log file analyzed by the 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
Page 61
A-RVS-UM2 Rollout Verification Solution Overview Poor Ec/No CPICH_EcNo_in_ActiveSet[0] < -15 dB High Ec/No CPICH_EcNo_in_ActiveSet[0] > -8 dB
September 2005
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 Data Session UMTS Throughput UMTS Top 10 Scan Measurements UMTS UE Active + Monitored Set UMTS UE Call Information UMTS UE Measurements Charts UMTS UE Radio Parameters UMTS UE Transport Channel Info 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_PDPContextDeact_Successful GPRS_Attach_Successful GPRS_Detach_Successful GPRS_PDPContextAct_Failure GPRS_RAU_Successful Event_Task_Start
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.
Figure 43: Example of a log file analyzed by the UMTS Data Event Navigator Stateform
Page 62
A-RVS-UM2 Rollout Verification Solution Overview 3.5.2 UMTS Data Session
September 2005
The UMTS Data Session stateform allows the engineer to view the data testing information collected during a data session.
Figure 44: Example of a log file analyzed by the UMTS Data Session Stateform
Page 63
September 2005
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.
Figure 45: Example of a log file analyzed by the UMTS Throughput Stateform
Page 64
A-RVS-UM2 Rollout Verification Solution Overview 3.5.4 UMTS Top 10 Scan Measurements
September 2005
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
Figure 46: Example of a log file analyzed by the UMTS Top 10 Scan Measurements Stateform
Page 65
A-RVS-UM2 Rollout Verification Solution Overview 3.5.5 UMTS UE Active + Monitored Set
September 2005
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.
Figure 47: Example of a log file analyzed by the UMTS UE Active + Monitored Set Stateform
Page 66
A-RVS-UM2 Rollout Verification Solution Overview 3.5.6 UMTS UE Call Information
September 2005
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
Page 67
A-RVS-UM2 Rollout Verification Solution Overview Figure 48: Example of a log file analyzed by the UMTS UE Call Information Stateform 3.5.7 UMTS UE Measurements Charts
September 2005
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
Figure 49: Example of a log file analyzed by the UMTS UE Measurements Charts Stateform
Page 68
A-RVS-UM2 Rollout Verification Solution Overview 3.5.8 UMTS UE Radio Parameters
September 2005
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
Figure 50: Example of a log file analyzed by the UMTS UE Radio Parameters Stateform
Page 69
A-RVS-UM2 Rollout Verification Solution Overview 3.5.9 UMTS UE Transport Channel Info
September 2005
The UMTS UE Transport Channel Info allows the engineer to visualize the BLER per channel and also the aggregate BLER.
Figure 51: Example of a log file analyzed by the 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_IncomingCallOK Uu_OutgoingCallSetupFail Uu_IncomingCallSetupFail Uu_CallDropped 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
Page 70
September 2005
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 and Scanner
IP Sniffer
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.
Page 71
September 2005
3.7
Supported protocol interfaces for UMTS

Uu
The following network interface is currently supported for RVS, subject to technical feasibility: 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 .
Page 72
September 2005
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. Actix Confidential and Proprietary Page 73
September 2005
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.
Page 74

Actix Overview

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Actix Overview

Enviado por

Direitos autorais:

Formatos disponíveis

Overview

Actix RVS for UMTS version 2.3 September 2005

A-RVS-UM2 Rollout Verification Solution Overview

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

2 Operational Tasks and Processes

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

R&D / Trials & Planning

Site Calibration Initial Testing

Initial Coverage Analysis

Site Integration and Optimization Event Detections

Service Coverage Availability

Throughput and Rates Calculation

Scanner and Drive Tests Analysis

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

Site Integration and Infrastructure Testing

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

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

A-RVS-UM2 Rollout Verification Solution Overview

Benchmarking and Statistical Analysis

Figure 6: Charts and graphs representing different call statistics

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

Figure 7: Various call statistics filtered by cells

Radio Link Performance Troubleshooting

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

Figure 9: Charts and graphs for a handoff state analysis

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

Event Detection and Drive Test Analysis

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

Figure 10: Example of system interference before a dropped call

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

A-RVS-UM2 Rollout Verification Solution Overview

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

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

Figure 14: Example of handover problems before a dropped call

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

Figure 15: Example of missing neighbor before a dropped call

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

Actix Confidential and Proprietary

A-RVS-UM2 Rollout Verification Solution Overview

Actix Confidential and Proprietary