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

Actix Confidential and Proprietary Page 1

Contents

1 INTRODUCTION............................................................................................................3

2 OPERATIONAL TASKS AND PROCESSES...............................................................4 2.1 SITE INTEGRATION AND INFRASTRUCTURE TESTING ...................................................6 2.2 DETAILED CALL SEQUENCE ANALYSIS........................................................................8 2.3 BENCHMARKING AND STATISTICAL ANALYSIS .............................................................9 2.4 RADIO LINK PERFORMANCE TROUBLESHOOTING......................................................10 2.5 EVENT DETECTION AND DRIVE 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 DEFINITIONS .................................................................................................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 LAYERS ..............................................................................................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



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 1990’s. Technological advances in software and hardware usually enable these productivity improvements, 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 1980’s 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.

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.

R&D Trials

Initial Rollout

Immature Buildout

Mature Growth

Rollout Verification

Solution



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.

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

Benchmarking

R&D / Trials & Planning

Initial Rollout

Immature Buildout

Mature Growth

Scanner and Drive Tests

Analysis

Event Detections

Service Coverage

Availability

Site Calibration Initial Testing

Throughput and Rates

Calculation

Initial Coverage Analysis

Processes

Phases

Tasks

Subscriber Perceived Performance

Radio Link Performance

On-going Optimization

Network Growth

Power Measurements

Site Integration and

Optimization



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 SC’s 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) <> (SC’s 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 Actix’s 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 Actix’s 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 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 (*)



• 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)


§ RRC_OriginatingConversationalCall § 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 Setup • Uu_RRC_MsgType == RRC Connection Release OR

• Uu_RRC_MsgType == RRC Connection Request 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 Then any of the following options:

• Uu_RRC_MsgType == RRC Connection Reject OR


• Uu_RRC_MsgType == RRC Connection Setup • Uu_RRC_MsgType == RRC Connection Release OR

• Uu_RRC_MsgType == RRC Connection Request o With Uu_RRC_RRCConnectionRequest_establishmentCause not equal to the

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 detected1 • 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 already 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 does 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 Connection Request

RRC Connection Setup

RRC Connection complete

Start Of File

RRC Counter is set to 1 Uu_RRC_ID is set to 0

Uu_RRC_ID is set to RRC Counter RRC Counter is set to RRC Counter +1 Thus RRC Counter now 2

0

1

RRC Connection Release

1

1



1

1

0

Uu_RRC_ID is set to RRC Counter RRC Counter is set to RRC Counter +1 Thus RRC Counter now 2

2

2

Uu_RRC_ID is set to 0

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



§ RRC_OrignatingLowPrioritySignalling • Uu_RRC_MsgType == RRC Connection Setup • Uu_RRC_MsgType == RRC Connection Setup Complete

3.2.3.3 RRC Connection Completed Incoming Call (attribu te Uu_IncomingRRC_ConnectionOk)

• Uu_RRC_MsgType == RRC Connection Request o With Uu_RRC_RRCConnectionRequest_establishmentCause equals any of the

following: § TerminatingConversationalCall § TerminatingStreamingCall § TerminatingInteractiveCall § TerminatingBackgroundCall § TerminatingHighPrioritySignalling

• Uu_RRC_MsgType == RRC Connection Setup • Uu_RRC_MsgType == RRC Connection Setup Complete

3.2.3.4 RRC Connection Reject (attribute Uu_RRC_Reject)

• Uu_RRC_MsgType == RRC Connection Request o With Uu_RRC_RRCConnectionRequest_establishmentCause of any type

• Uu_RRC_MsgType == RRC Connection Reject

3.2.3.5 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


• Uu_RRC_MsgType == RRC Connection Setup

• Uu_RRC_MsgType == RRC Connection Request

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 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 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 • 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.



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 it’s 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



Figure 19: Cell A is the best server by CPICH Ec/Io. Cells B and C are within a user-specified threshold of Cell A’s 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

Drive Test Route

A Best Server

B Neighbour 1

C Neighbour 2

D Not a Neighbour

E Excluded from Analysis



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 analysis 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



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 Set’s 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.

D Pollution Source

A Active Set

B Active Set

C Active Set

Drive Test Route E

Not a Pollution Source, or in Active Set



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.



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

Single-sector

Softer handoff

Soft handoff

3-way Softer

3 sectors

same node B

Soft-softer handoff

2 sectors

same node B

3-way soft

2 sectors

same node B



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 doesn’t 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 sequence 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 Sustainability = 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.

Figure 34: Example of a log file analyzed by the 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.

Figure 37: Example of a log file analyzed by the 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

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



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



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.

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



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.

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



• 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 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



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.

Figure 44: Example of a log file analyzed by the 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.

Figure 45: Example of a log file analyzed by the 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

Figure 46: Example of a log file analyzed by the 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.

Figure 47: Example of a log file analyzed by the 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 – Mobile’s 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



Figure 48: Example of a log file analyzed by the 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

Figure 49: Example of a log file analyzed by the 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

Figure 50: Example of a log file analyzed by the 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.

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



3.6 Supported data sources for UMTS

UMTS A-RVS 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

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.

Test Mobile and Scanner

IP Sniffer

Node B UE

Uu COM



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 Actix—the 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.

actix overview

Documents

radio bearer

full detailed

log file analyzed

rb setup procedure

ps radio bearer

typical analysis

network element

pdp context