Вы находитесь на странице: 1из 85

UMTS Optimization Guideline

Page 1 of 85

UMTS Optimization Guideline

  • 1. BASIC TUNING...................................................................................................................................2

    • 1.1 KPIS AND SERVICE REQUIREMENTS..............................................................................................2

      • 1.1.1 IRAT Performance....................................................................................................................2

      • 1.1.2 CS Performance.......................................................................................................................2

        • 1.1.2.1 CS Requirements......................................................................................................................3

      • 1.1.3 PS Performance.......................................................................................................................4

        • 1.1.3.1 PS Requirements......................................................................................................................5

  • 1.2 TOOLS............................................................................................................................................8

    • 1.2.1 Tools Requirements..................................................................................................................8

      • 1.2.1.1 RF Measurements...................................................................................................................11

      • 1.2.1.2 Throughput Measurements....................................................................................................12

      • 1.2.1.3 Call Performance....................................................................................................................13

  • 1.2.2 Tools Currently Available to Capture / Process data.............................................................15

    • 1.2.2.1 Drive Test Equipment and Software.....................................................................................18

    • 1.2.2.2 Post-Processing Software......................................................................................................22

  • 1.3 PRE-LAUNCH OPTIMIZATION PROCESS........................................................................................24

    • 1.3.1 Database Verification.............................................................................................................25

    • 1.3.2 Drive Test Route Selection.....................................................................................................26

    • 1.3.3 Drive Test Data Collection.....................................................................................................28

    • 1.3.4 Data Post-processing and Root-Cause Analysis....................................................................29

    • 1.3.5 Root Cause Analysis and Recommendation...........................................................................30

      • 1.3.5.1 High Downlink Interference....................................................................................................30

      • 1.3.5.2 Pilot Pollution...........................................................................................................................32

      • 1.3.5.3 Out of Pilot Coverage.............................................................................................................33

      • 1.3.5.4 Insufficient received UL DPCH power..................................................................................33

      • 1.3.5.5 High UE TX Transmit Power..................................................................................................34

      • 1.3.5.6 Swapped feeders....................................................................................................................35

      • 1.3.5.7 Low data throughput...............................................................................................................37

      • 1.3.5.8 Handover Event Detection Failure........................................................................................39

      • 1.3.5.9 No Suitable Cell.......................................................................................................................40

  • 1.3.6 Assessing Success of Recommended Change.........................................................................41

    • 2 OMC STATISTICS BASED TUNING.............................................................................................42

      • 2.1 KPIS.............................................................................................................................................42

        • 2.1.1 IRAT - Inter Radio Access Technology (IRAT) performance.................................................50

        • 2.1.2 CS Performance additional information................................................................................51

        • 2.1.3 PS Performance additional information................................................................................51

  • 2.2 TOOLS..........................................................................................................................................51

    • 2.2.1 Tools Requirements................................................................................................................52

    • 2.2.2 Tools Currently Available to Capture / Process Data............................................................53

  • 2.3 POST-LAUNCH OPTIMIZATION PROCESS......................................................................................55

    • 2.3.1 Data Post-processing and Root-Cause Analysis....................................................................56

    • 2.3.2 Optimization Strategy per Root-cause and/or Problem Category/Type/Area........................66

    • 2.3.3 Assessing Success of Recommended Change.........................................................................82

  • inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 2 of 85

    1. Basic Tuning

    1.1 KPIs and Service Requirements

    1.1.1

    IRAT Performance

    Handover between WCDMA and GSM allows the GSM technology to be used to give fallback coverage for WCDMA technology. This means subscribers can experience seamless services even with a phased build-out of WCDMA. The IRAT performance is evaluated under the following test cases.

    IDLE mode to GERAN (3G to 2G cell reselection).

    Cell FACH state to Cell PCH state (3G PS state transition)

    URA PCH state (3G PS state transition)

    3G to 2G with PDP context activation (PS test; 3G to 2G cell reselection)

    2G to 3G with PDP context activation (PS test; 2G to 3G cell reselection)

    3G to 2G CS Handover (CS-only test)

    2G to 3G CS Handover (CS-only test)

    3G to 2G CS Handover with PDP context activation; Multi-RAB handover

    (CS + PS test) Event 3A measurement activation / deactivation

    1.1.2

    CS Performance

    Call Event Success Rate

    Call Block Rate

    Drop Call Rate

    SHO Event Success Rate

    Location Update success rate

    Channel Utilization

    Call Completion Success Rate

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 3 of 85

    Signaling Load

    Inter Cell Handover Success Rate

    Handover Success Ratio

    Paging and Routing Area Updates

    Connection Setup Success and Dropped

    Call Setup Rate

    Bad Quality Call Rate %

    DL Power Outage %

    SHO Overhead

    Bs TXP

    RAB establishment success rate

    • 1.1.2.1 CS Requirements

    These two KPI’s RRC setup complete rate and RRC Establishment complete rate combine to give us another key KPI, accessibility, which is a measure of the origination success rate.

    Accessibility

    The network operator should target an Accessibility rate greater than 98 % for circuit switched voice conversations and packets switched data sessions.

    UMTS Optimization Guideline Page 3 of 85  Signaling Load  Inter Cell Handover Success Rate
    UMTS Optimization Guideline Page 3 of 85  Signaling Load  Inter Cell Handover Success Rate

    Retainability

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 4 of 85

    Retainability is a measure of the Radio networks ability to maintain an active mobile session until the user terminates. It indicates the percentage of active calls dropped.

    UMTS Optimization Guideline Page 4 of 85 Retainability is a measure of the Radio networks ability

    A typical retainability requirement for a network is Drop Call Rate < 1.5% for voice conversations.

    1.1.3 PS Performance

    RLC DL throughput: Total RLC downlink throughput.

    RLC UL throughput: Total RLC uplink throughput.

    Session App. Mean Throughput DL (kbit/s): Mean throughput, calculated

    over the whole of the current session, for data received at the application level (mean downlink throughput). Session App. Mean Throughput UL (kbit/s): Mean throughput, calculated

    over the whole of the current session, for data sent at the application level (mean uplink throughput). Ping Delay (ms): Delay for an individual Ping Response during the current

    Ping session. Success Rate of internet connections

    Variable data rate performance

    End to end packet delay transfers

    Throughput at the edge of the cell

    PS and CS Bearers

    Attach / Context

    Blocked Error Rate %

    Packet Bad Quality %

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 5 of 85

    PDP Context Activation success ratio

    Attach success ratio

    PDP context drop ratio

    Data Transfer drop ratio

    Attach setup time

    PDP context activation time

    Service Access time

    End to end access time

    Mean user data rate

    Round trip time

    Packet loss ratio

    Initial Service Response

    Transfer interruption time

    End to end accessibility success ratio

    Service Access Success Ratio

    1.1.3.1

    PS Requirements

    HSDPA DL Application Layer Throughput > 400 kbps

    R’99 DL Application Layer Throughput > 133 kbps

    HSDPA Ping Round trip Latency < 150ms

    R’99 Ping Round trip Latency < 150ms

    OCNS with 20% of Minimum Design capacity.

    Optimization Insights

    Optimizing the Network

    The optimization process should start in the so-called pilot network, an intermediate stage of the network rollout where only the common channels

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 6 of 85

    for signaling and synchronization are use. While carrying no traffic itself, this pilot network provides a useful representation of the traffic flow in the future operational WCDMA network. Many aspects of optimization activities can be done in this phase.

    Some other aspects of optimization such as adjusting the Soft Handover ratio must wait until the user equipment (UE) is in operation.

    Basic Tuning to be done early phase of roll out

    Coverage Optimization

    • 1. Since each Node Bs continuously transmits CPICH, scanning the

    CPICH using a Drive test system enables a quick and effective examination of the network RF Coverage, as well as a means to identify

    the Node Bs. It is important to detect high CPICH levels from too many cells as this causes interference.

    • 2. Lack of RF Coverage - Can cause calls to drop or be blocked due to

    lack of coverage at the edge of the cell site coverage or coverage hole in the area.

    Missing Neighbors and Pilot Pollution

    • 1. Missing Neighbor in the neighbor list - Neighbor condition occurs when

    a high level pilot (i.e one whose measured value is above T_Add (Threshold to Add)) that does not appear in the neighbor list is sent to a

    phone. This condition adds interference, resulting in a low quality connection, and possible causing dropped calls.

    • 2. Pilot Pollution and Interference - Pilot Pollution occurs when there are

    an excessive number of pilot signals. In such a situation a subscriber

    could notice interference on an active call.

    Balancing of Channel Transmission Powers:

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 7 of 85

    The relative output powers of various channels in WCDMA can be freely adjusted, and should be since they have different requirements. Signaling channels need less power than the channels that carry user data. Particularly important to ensure that Synchronization channels are transmitted strongly enough to be reliably detected. Cells in the vicinity of one another must use different offsets for the synchronization burst in order for the synchronization channel to work properly.

    Type of test call in drive-test:

    Short voice call: Each voice call is made to a PSTN number and held for duration of 100 seconds and waited for 10 seconds between calls. Long Voice call: Voice call is made to a PSTN number and held until the end of the cluster drive test, or until the call dropped. Short CS Data Call: CS data call is made to another mobile or to a CS ftp server and held for a duration of 100 seconds then wait for 10 seconds before making the next call. Long CS Data Call: CS data call is made to another mobile or to a CS ftp server and held until the end of the cluster drive test, or the call dropped. Short PS Call: About 100 seconds worth of data transfer DL or DL FTP a 2.5 MB file (approximately). Long PS Call: About 1 hr worth of data transfer DL or multiple DL FTP files of size about 10MB.

    KPIs:

    CPICH RSCP: Received signal code power, the received power on one code measured on the primary CPICH. DL RSSI: Received signal strength indicator, the wide-band received power within the relevant channel bandwidth. CPICH Ec/No: The received energy per chip divided by the power density

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 8 of 85

    in the band. UE UL TxPwr: The total UE transmitted power on one carrier. Transport CH BLER: Estimation of the transport channel block error rate.

    Call event success rate: Formula:

    # Call Ends / (# Call Ends + # Blocked

    Calls + # Dropped Calls) SHO event success rate: Formula: (# add + # remove + # replace) / # all SHO

    1.2 Tools

    1.2.1 Tools Requirements

    Different tools are required to accomplish basic tuning in UMTS network.

    Cell Planning Tools

    Route Planning Tools

    Drive Testing Tools

    Data Processing and Report Generation Tools

    RF Test Tools

    Cell Planning Tools During basic tuning, Cell Planning Tool is used to:

    Plan and design UMTS network,

    Analyze coverage and interference,

    Design neighbor cell relationships and define handover margins,

    Analyze traffic,

    Review network capacity planning for voice and data services.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 9 of 85

    Route Planning Tools

    Often Mapinfo is used to plan drive routers before drive-tests. Mapinfo is a commercial application working on PC. In route planning process, Mapinfo can be used to plan route, sites and spatial data visualization and printing.

    A digital map is required with Mapinfo format including raster and vector information of terrain.

    Besides Mapinfo, maps or map software such as Microsoft Street and Trips, can be used to plan routes.

    Driver Testing Tools During the basic tuning for a pre-launch UMTS network, drive-testing is the most important way to collect the network performance data, since there are limited subscribers using the UMTS pre-launch network and accurate network statistics is not available from OSS. Drive testing tools are used to:

    Record UE and scanner measurement data, Visualize UE and scanner measurement data during drive testing (synchronized maps, tables, graphs and text information). To do the drive test in UMTS network, the following components are required. Test UE

    With Test UE, drive testing tools can capture RF measurements on the UE side, like UE transmit power, DL CPICH Eb/No, DL RSSI, etc. Further more, to get a full picture (both downlink and uplink information) of the problem, it is possible to use UE trace function during the drive test, if the RAN and OSS can support this function.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 10 of 85

    Since UMTS can support voice, CS data and PS data, usually we need more test UEs during the drive test. To get all RAB performances in UMTS network, the following call type is necessary to do a drive test:

    Short voice call: Each voice call is made to a PSTN number and held for duration of 100 seconds and waited for 10 seconds between calls.

    Long Voice call: Voice call is made to a PSTN number and held until the end of the cluster drive test, or until the call dropped.

    Short CS Data Call: CS data call is made to another mobile or to a CS ftp server and held for a duration of 100 seconds then wait for 10 seconds before making the next call.

    Long CS Data Call:

    CS data call is made to another mobile or to a CS ftp

    server and held until the end of the cluster drive test, or the call dropped.

    Short PS Call: About 100 seconds worth of data transfer DL or DL FTP a 2.5 MB file (approximately).

    Long PS Call: About 1 hr worth of data transfer DL or multiple DL FTP files of size about 10MB.

    Pilot Scanner

    A pilot scanner is a tool to measure the CPICH Eb/No and CPICH RSCP regardless the neighbor list setting, correlated with GPS positioning data. It is useful to determine a handover relationship and to evaluate radio wave propagation characteristics, pilot channel qualities, soft handover area locations and downlink interference contributions.

    GPS

    GPS can provide position information during drive tests. With GPS we can get the result that abnormal RF problem can be connected to geographical information.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 11 of 85

    FTP Server

    In order to transfer data stably without any unexpected problem from Internet, a dedicated FTP server should be set up before doing drive tests.

    Different size files on a FTP server should be put so as to perform short PS

    data

    calls or long

    PS data calls. For example: 1MB,

    2

    MB,

    5

    MB,

    10MB,

    100MB, etc. Data Processing and Report Generation Tools

    To analyze drive test log file, post data processing tools can be used to display a plot, which includes radio measurement results and geographic information on MapInfo. In addition, this post data processing tools can provide the statistics of call events and radio measurement data, often used in our customer reports.

    RF Testing Tools

    A spectrum analyzer is a tool to monitor spectrum characteristics. It is useful to track external interference inside or outside of the operational band. In the initial deployment phase (coverage limited system), it can be used to survey the level of adjacent channel interference from other operators.

    • 1.2.1.1 RF Measurements

    The following is the key RF performance indication in UMTS drive tests. Test UE

    Scrambling codes of active set cells and monitored set cells

    CPICH_Ec/No of active set cells and monitored set cells (dB)

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 12 of 85

    CPICH_RSCP of active set cells and monitored set cells (dBm)

    DL RSSI (dBm)

    DL transport BLER (%)

    DL SIR target and estimated DL SIR (dB)

    UE transmitted power (dBm)

    All UE sent and received L3 messages

    Pilot Scanner Scrambling codes of all CPICHs

    Ec/No of all CPICHs (dB)

    RSCP of all CPICHs (dBm)

    DL RSSI (dBm)

    • 1.2.1.2 Throughput Measurements

    During the drive test in UMTS network, it is important to measure and monitor wireless data service performance, since wireless data service is the significant characteristic of UMTS technology. PS performance measurements can be obtained as follows:

    RLC DL throughput: Total RLC downlink throughput.

    RLC UL throughput: Total RLC uplink throughput.

    Session App. Mean Throughput DL (kbit/s): Mean throughput, calculated over the whole of the current session, for data received at the application level (mean downlink throughput).

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 13 of 85

    Session App. Mean Throughput UL (kbit/s): Mean throughput, calculated over the whole of the current session, for data sent at the application level (mean uplink throughput).

    Application Throughput DL(kbit/s): Current throughput for data received at the application level (current downlink throughput).

    Application Throughput UL(kbit/s): Current throughput for data received at the application level (current uplink throughput).

    Ping Delay (ms): Delay for an individual Ping Response during the current Ping session.

    • 1.2.1.3 Call Performance

    Often the drive test tools can provide some call events statistics that can be used to evaluate radio network performance. These call performance statistics can be categorized into four groups.

    Accessibility RRC connection setup successful rate from the UE point of view

    Number of sent RRC connection setup complete Number of sent RRC connection request

    100%

    RB establishment successful rate per RB from the UE point of view

    Number of sent radio bearer setup complete Number of received radio bearer setup

    100%

    Retainability Average RRC connection drop rate when the UE is in cell_DCH mode

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 14 of 85

    Number of abnormal drops in which the UE state is from Cell_DCH to idle

    Total time of the whole drive test

    s

    -1

    Average RRC connection drop rate when the UE is in cell_FACH mode

    Number of abnormal drops in which the UE state is from Cell_FACH to idle

    Total time of the whole drive test

    s

    -1

    Mobility Soft handover success rate

    (# add + # rem + # repl) / # all Where add = Radio Link Addition events rem = Radio Link Removal events repl = Radio Link Replacement events all = all Radio Link events, including failures

    IRAT hard handover success rate From UMTS to GSM:

    Number of HO from UTRAN Complete Number of HO from UTRAN command

    100%

    From GSM to UMTS:

    Number of

    HO to UTRAN Complete

    100%

    Number of HO to UTRAN command

    Quality Downlink transport channel BLER Best serving cell CPICH Ec/No, i.e. pilot channel quality

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 15 of 85

    1.2.2 Tools Currently Available to Capture / Process data

    At present many drive test software and analyze software are available to capture and post-process measurement data. Basically these software can be categorize into two groups based on the provider of these software.

    Software developed by Mobile Infrastructure Equipment Vendor

    An advantage of this kind of software is that vendors can add some additional test functions to let these software work well with their infrastructure network. For example, Ericsson adds SQI measurement function in their drive test tools – Tems Investigation, this function can evaluate voice quality during drive tests. Also in Ericsson infrastructure network, same function is used in performance statistic.

    Two major drive test and post-process tools listed below are commonly used in different operators.

    Nemo

    Nemo is a Finland company which dedicates to develop drive test and post-process software for mobile networks. The former of this company is a branch of Nokia. Nemo is used commonly by operators who use Nokia system, like T-Mobile.

    Nemo Outdoor™

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 16 of 85

    Nemo Outdoor™ is a portable engineering tool designed for measuring and monitoring the air interface of wireless networks. Fast and accurate measurement data provides detailed information in real time for 2G, 2.5G, 2.75G, and 3G networks.

    For more detail information about Nemo Outdoor, please read his web site. http://www.nemotechnologies.com/index.php?249

    Nemo Analyze™

    Nemo Analyze™ is a front-line analysis tool for quick and easy data review. It can be used on the field or in the office for immediate problem solving and report generation. Nemo Analyze is designed to be the analysis tool for measurement files produced with the Nemo measurement tools: Nemo Outdoor and Nemo Handy.

    For more detail information about Nemo Analyze, please read his web site. http://www.nemotechnologies.com/index.php?267

    Tems

    Tems products are developed by a branch of Ericsson Corporation. Tems products portfolio includes radio network planning, radio network optimization, benchmarking, indoor coverage testing.

    Tems Investigation

    TEMS Investigation is a portable air-interface tool for troubleshooting, verification, optimization, and maintenance of mobile networks. The tool collects all the data needed to keep the network running smoothly and to plan for future improvements. The collected data is presented in real time, and can be used together with site information to improve troubleshooting capability. The flexible interface allows the user to filter network data and focus on relevant information for truly in-depth analysis

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 17 of 85

    For more detail information about Tems Investigation, please read his web site.

    Tems DeskCat

    TEMS DeskCat is advanced post-processing software. It enables users to easily mine drive test data, visualize air interface problems, and drill down into the data for easy analysis and problem resolution. It also provides the unique System Quality Report for comprehensive network comparison. Designed to support experienced RF engineers and network optimization specialists, but able to provide managerial reports as well.

    For more detail information about Tems DeckCat, please read his web site.

    ml

    Software developed by Testing and Measurement Company

    Developed by companies dedicating to develop sophisticated equipments, these drive test tools have a common characteristic on RF testing function.

    For example:

    Rohde-Schwarz TS9951+ ESPI+ROMES3

    Rohde-Schwarz TS9951 is a drive test hardware used to support up to 4 mobile phones. Rohde-Schwarz ESPI is a test scanner to accomplish the PN scan and CW measurement. These two tools should be run on the drive test software Rohde-Schwarz ROMES3.

    For more detail information about Rohde-Schwarz products, please read their web site. http://www.rohde-schwarz.com

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 18 of 85

    Agilent E6474A

    The E6474A Agilent Wireless Network Optimization Platform provides true cross technology scalability and allows early verification of network deployments for 2G, 2.5G and 3G wireless networks. Its optimization platform enables wireless service providers and network equipment manufacturers to proactively address challenges with wireless voice and data networks by quickly and accurately identifying problems.

    • 1.2.2.1 Drive Test Equipment and Software

    The field measurement equipment usually consists of:

    A laptop, which

    store the measurements data and run

    the drive

    test

    software. A GPS, to record the exact location of the measured parameters.

    Mobile phones and scanners to be used as measurement devices.

    UMTS Optimization Guideline Page 18 of 85 Agilent E6474A The E6474A Agilent Wireless Network Optimization Platform
    Scanner
    Scanner
    UMTS Optimization Guideline Page 18 of 85 Agilent E6474A The E6474A Agilent Wireless Network Optimization Platform
    UMTS Optimization Guideline Page 18 of 85 Agilent E6474A The E6474A Agilent Wireless Network Optimization Platform

    HUB

    UMTS Optimization Guideline Page 18 of 85 Agilent E6474A The E6474A Agilent Wireless Network Optimization Platform

    Three phones can used to provide a flexible test configuration and test both data and voice calls (short and long calls). Using both mobile and scanner simultaneously in WCDMA measurements enables the measuring

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 19 of 85

    of all pilots available in the area and the comparison of the results to the view seen by the user equipment (UE). The UE reports values based on a neighbor list received through signaling and makes cell reselections and handovers based on the planned neighbor list. However, there can be pilots available that are not defined in the neighbor list and these can be spotted with a scanner. In other words, measurements together with scanner and mobile would also identify missing or interfering pilots.

    Effective UMTS drive test software should be able to measure and perform the following tasks:

    Evaluate call-processing operations

     

    Perform selected call processing functions

    Measure and report the amplitude of the received base station signal

    Measure and report the signal quality of the received base station

    signal Read and report the neighbor cell list from the broadcast messages

    Report the amplitude of neighbor list base stations

    View and

    log

    protocol

    messages

    in

    decoded

     

    form

    for

    easy

    interpretation

    Quantify

    wireless

    data

    user’s

    quality

    of

    service

    (with

    data

    measurement options). Perform integrated analysis using the phone and receiver at the same

    time Correlate call drops within the RF environment

    Show current

    position and the

    route

    traveled

    on

    a

    map as

    data is

    collected.

    The following is a list of some of the parameters measures.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 20 of 85

    Interlayer Messages

    • UMTS Layer 3 Messages • GSM Layer 3 Messages • GSM Acknowledged Mode

    Messages Layer 2

    • GPRS RLC/MAC Messages • GPRS GMM/SM Messages

    QoS Indicators

    • Real-Time Data Throughputs • RLT Counter Radio link timeout • FER • Vocoder State • DTX State • Retransmitted RLC Block Rate • RLC/MAC Real-Time Data Throughputs • RLP Report • Handover Counter

    UMTS Measurement Information

    • UL/DL ARFCN • ARFCN RxLev • Each CPICH in the Active List • Ec/No of each CPICH in the Active List • Composite and per finger RSCP • Each CPICH in the Candidate List • Ec/No of each CPICH in the Neighbor List • Cell ID of each CPICH in the Active and Neighbor Lists • BSIC • Power Control

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 21 of 85

    – UE Tx Power – DPCH SIR

    HSDPA Measurement Information

    • CQI • DCH BLER • DCH Retransmissions • DSCH Throughput (kbit/s) • SCCH OVSF Code Info • HS Session

    GSM/GPRS/EDGE Layer State and Measurement Information

    • Layer 1 Information • RR Information • MM Information • MAC Information • RLC Information − Downlink Coding Scheme − Uplink Coding Scheme • LLC Information • GMM Information • SM Information • SNDCP Information • Service State

    Data and service testing

    • Streaming Video • IP Protocol Trace • Data throughput UL/DL • Ftp, http, and ping test applications.

    • MMS and SMS testing

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 22 of 85

    • New Command sequence • Roundtrip delay

    • 1.2.2.2 Post-Processing Software

    Post processing forms a key counterpart to data collection in the verification of infrastructure performance, automated calculation of performance metric analyses and troubleshooting.

    Key features of a data analysis and post processing tool for UMTS is the ability to:

    Support multiple technologies i.e. GSM, GPRS and WCDMA on one platform simultaneously. Provide maps, histograms and cumulative distribution charts and statistical analyses of key packet data and radio link performance metrics. Correlate WCDMA scanner and UMTS UE measurements from independent log files.

    Support interfaces to a variety of vendors of drive test equipment, protocol analyzers and measurement programs. Access to radio interface messaging, including message counters and cause value breakdown for failure, error and reject messages. Correlate abnormal data performance with radio link parameters.

    Assess Subscriber-perceived performance analysis for IP and data applications (e.g. HTTP, UDP)

    Provide support for open interfaces, which can typically be used to collect performance data well in advance of proprietary data sources, like test mobile and peg counter data.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 23 of 85

    Reduce data through binning and standard database type querying and filtering capabilities. Synchronize data collected from different network elements and sources to remove timing discrepancies. Provide interfaces into databases for storing collected data statistics and provide web-enabled reporting interfaces for extracting data. Embed engineering expertise into the software to automate the process of analyzing large amounts of data.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 24 of 85

    1.3 Pre-Launch Optimization Process

    An overview of the radio network optimization process will be briefly presented.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 25 of 85

    Basic Tuning Database Verification
     

    Basic Tuning

    Basic Tuning
    Basic Tuning Database Verification

    Database Verification

    Database Verification
    Basic Tuning Database Verification
    Performance Monitor Drive Test Performanc Test User e Report Complain Performance Analysis Parameters Mechanical Tuning Tuning
    Performance Monitor
    Drive Test
    Performanc
    Test User
    e Report
    Complain
    Performance Analysis
    Parameters
    Mechanical
    Tuning
    Tuning
    Performance Review
    Meet
    Project
    No
    Target
    Yes
    Finish

    1.3.1 Database Verification

    Purpose

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 26 of 85

    The purpose of the database verification activity is to verify that the radio network has been properly configured, meaning that the actual system parameter settings correspond to the recommended values, and RF parameter settings correspond to the radio network design results.

    RAN database verification is the first step of basic tuning. By implementing the verification, unnecessary troubleshooting will be avoided and further investigations can be carried out focusing on problems other than parameter configuration mistakes.

    Database verification includes two parts of work- RF Parameters Verification and System Parameters Verification.

    RF Parameters Verification

    The RF parameter settings that are implemented in the live network and the original radio network design results are the base to conduct basic tuning. These RF parameter settings contain PN code plan, neighbor list plan, antenna height, antenna direction and tilt. Make sure that the RF parameter settings in the live network are exactly the same with the radio network design results.

    Meanwhile, conducting drive test for each site can ensure that no antenna swap mistakes exist in the live network.

    Often missing neighbors and antenna swaps are the most common mistakes in the pre-launch network, resulting in serious radio network performance problems in UMTS networks, e.g. high drop call rate in some cells, bad quality area (with low Ec/No) etc.

    System Parameters Verification

    In order to avoid abnormal system

    parameter setting in live network,

    verifying the parameter settings in the live network correspond to the

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 27 of 85

    recommended values is important. These recommended values are based on lots of testing and simulations results, which are optimal values in most networks.

    The procedure to implement system parameters verification is as below:

    • 1. Retrieve current parameter settings from systems

    • 2. Check current versus recommended parameter values

    • 3. Apply the consistency check rules to current parameter values

    • 4. Produce a list of parameters to be changed and generate the change requests for clients

    • 5. Get approval from clients and load changes to the systems

    A parameter dump should be created from the live network to retrieve current parameter settings, following by a conversion of the system dump file into readable Microsoft Excel file with script developed by Excel Macro or VB.

    Equipments from different vendors often provide different recommended system parameter setting values, which may require to be modified when new software version is released. Therefore, it is important to get recommended parameter setting values for current software version from clients before implementing system parameter setting verification.

    1.3.2 Drive Test Route Selection

    Drive testing is done to verify the coverage and the service requirement KPI’s i.e. availability, Retentivity etc or for pin pointing and resolution of any network related issue. The Drive route criteria for both the scenarios are different.

    Baseline drive route

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 28 of 85

    The main purpose of baseline drive testing is to find the problem areas of the network. Using field measurement, coverage holes, interference areas, and handoff regions.

    The primary drive route consists mainly of freeways, highways and high traffic areas (like downtown). The high traffics areas are also define in the coverage and capacity objective, part of the Wireless System Design (and Implementation) Report. Both directions of travel need to be considered. If the three primary types of road do not cover problem areas, secondary road should be considered. If time and resource permit, selected secondary streets can be included in the drive routes.

    For baseline drive test, the drive routes need to cover farther than good coverage areas. For example, route will include roads covered lower than Ec/Io=-16dB.

    The route should cover all the sectors included in the test.

     

    Avoid

    the

    area

    with

    known

    coverage

    problem

    because

    of

    the

    unavailability or hardware problems of cells covering the area.

    Problem Resolution Drive route

    When problem area is identified, a punctual drive route should be design

    to verify and quantify the extent of the problem.

    The route should be driven both directions to verify if the problem exists in one direction or both directions. E.g. To verify handovers from any sector from a site we need to check the outgoing and incoming handovers for which we need to drive in both directions of the drive route.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 29 of 85

    If we do encounter any problem/ issue we should repeat the route so as to repeat the problem.

    If

    in

    the

    network

    there

    are

    a

    couple

    of

    problem

    areas,

    it

    is

    recommended to have separate spot drives for each of the problem areas.

    1.3.3 Drive Test Data Collection

    Before we start data collection we need to make sure that the hardware is connected and configured properly.

    Make sure all the Phones, Scanners, Scanner Antenna’s, GPS, Hubs and Laptop are connected properly. Make sure all the devices are connected to the appropriate COM port, and the COM ports are configured accordingly. Set up the Autocall settings to set up the phones for Long Call and Short call with the appropriate set up times, number to call, Max Idle time and Connect time. Make sure the appropriate Mapinfo workspace for the drive test area is configured in the Drive Test tool. Import the most current Cell site database which has information on the Sites, their PN’s and the Antenna orientations. Set up the FTP server with a suitable file for testing of Data Download and upload speeds. Set up the Scanner configurations as a Pilot Scanner with the appropriate Scan lists, Avg Ec/Io and Correlation taps. Open at least one window for the Map, The phone data, Scanner Data, and the Summary data for all the devices.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 30 of 85

    Connect all the devices, the Data collection software shows the connected devices. Run a test call to confirm that the Autocall, Scanners, GPS and the phones working fine. If everything is working fine, start logging and save the log files with suitable identifiers like <<Date>><<Time>><<Log File>>. Save the log files in the appropriate directory.

    1.3.4 Data Post-processing and Root-Cause Analysis

    Data Post-Processing

    To optimize the pre-launch network, various input data is needed:

    Performance statistics

    Performance recording

    Fault logs from RNC and Node B

    Parameter data

    Performance statistics

    Performance statistics is generated from the live, and is made up of a number of predefined counters. Combining these counters into formulas, we can get statistical reports which are useful for performance monitoring and optimization. During the basic tuning for a pre-launch network, since there are limited test users in the network, the performance statistics are not so accurate like the performance statistics in live network.

    Performance recording

    Performance recording includes two parts, log-file from drive-test tools and UE trace log-file from OSS with UE tracing function. UE tracing function provides UL information received by Node B side and signaling between

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 31 of 85

    Node B and RNC. Performance recording is the important input when performing a basic tuning in pre-launch network.

    Fault logs from RNC and Node B

    Fault logs are useful to identify abnormal system behavior caused by node faults

    Parameter data

    Parameter setting reviews are useful to understand the intention of the original radio plan and to determine how the parameter changes should be.

    1.3.5 Root Cause Analysis and Recommendation

    • 1.3.5.1 High Downlink Interference Phenomena During the drive test, following phenomena might be observed through drive testing tools:

    Received E c /N o of the pilot channel is less than –16dB and

    Received RSCP of the pilot channel is high enough to maintain the connection, e.g. > -100dBm and

    DL RSSI is very high and

    The connection drops eventually

    Reason 1 – Non Dominant Cell

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 32 of 85

    Many overlapping cells exist in the problematic areas and received signal strengths of the pilots in these overlapping cells are almost the same.

    Recommendation

    A direct and effective solution is to increase the pilot channel power – Primary CPICH power of the desired cell.

    Reason 2 – Dominant Interferer

    An undesired cell is identified because of its high signal strength,

    causing missing neighbor problem.

    Recommendation 1

    The simplest solution is to convert the interferer to a useful radio

    link by including the overshooting cell into the neighboring cell list.

    Recommendation 2

    The second solution to solve this problem is to decrease the pilot power - Primary CPICH power of the overshooting cell.

    With the pilot power decreasing, the total downlink power for the common channels of the interferer decreases. At the mean time, the power of all other common channel decreases because their parameter settings are related to the pilot power value.

    Recommendation 3

    The third solution is to change the antenna configuration of the overshooting cell. The possible practices include tilting down the antenna, re-directing the antenna orientation, reducing the antenna height and so on.

    This solution will not lead to UL/DL coverage imbalance problem in the interferer because UL/DL path-loss is changed simultaneously.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 33 of 85

    Reason 3 – Low Best Serving PPilot/PTot

    The third possible reason is that the pilot power setting is not large

    enough to fulfill existing downlink load, because low received E c /N o of the best serving pilot channel (near or less than –16dB) can be observed even if there is no other cell

    Recommendation

    To add a new site with “good coverage control” in the problematic area is a common practice.

    1.3.5.2

    Pilot Pollution

    Phenomena

    In cell_DCH mode, pilot pollution refers to the phenomenon that a UE at one location alters its active set cells frequently (e.g. active set update rate is very high) because many received pilot channels have similar quality (or signal strength) such as E c /N o (or RSCP).

    Reason – No Dominant Cell

    Due to poor cell planning, a large number of overlapping cells exist at a particular area

    Recommendation 1

    To change the antenna configurations or reduce the pilot power of the undesired cells is a common practice to remove the cells overlapping.

    Recommendation 2

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 34 of 85

    An alternative solution to remove the cell overlapping is to increase the pilot channel power – Primary CPICH power of the desired cells.

    • 1.3.5.3 Out of Pilot Coverage Phenomena During the drive test, following phenomena might be observed. Received E c /N o of the pilot channel is less than –16dB and Received RSCP of the pilot channel is very low, e.g. <-100dBm and DL RSSI is very low and The connection drops eventually Reason – low pilot channel power To set the low pilot channel power can lead coverage holes. Recommendation 1 The most common solution to overcome this problem is to add a new site in the problematic area. Recommendation 2 To increase the pilot channel power is an alternative solution.

    • 1.3.5.4 Insufficient received UL DPCH power Phenomena During the drive test, following phenomena might be observed through drive test tools and UE tracing function:

    Received E c /N o of the pilot channel is larger than –16dB and

    UE Tx power does not reach the maximum allowed value and

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 35 of 85

    UL SIR target of the radio connection reaches to the maximum allowed SIR target and

    UL BLER of the radio connection increases and

    The connection drops eventually

    Reason

    The possible reason that the base station cannot receive high enough power from the uplink dedicated physical channel is because the parameter - maximum allowed UL SIR Target is set too low.

    Recommendation

    The maximum allowed UL SIR Target should be justified to allow

    UEs to transmit with higher power.

    • 1.3.5.5 High UE TX Transmit Power Phenomena During the drive test, following phenomena might be observed though drive test tools and UE tracing function.

    Received E c /N o of the pilot channel is larger than –14dB and

    Received RSCP of the pilot channel is good, e.g. <-85dBm and

    UE Tx power reaches the maximum UE allowed value (23dB) and

    UL BLER of the radio connection increases

    UL RSSI is high.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 36 of 85

    Reason – Uplink Interference

    The possible reason that UE transmit with very high power even if with good the downlink quality (Ec/No) and high downlink signal strength (RSCP) is because of UL interference.

    The UL interference could be internal interference (generate by

    other

    UEs)

    or

    external

    interference (repeater or industry

    interference).

     

    Recommendation

    Check cell UL loading in nearby cells to determine whether the

    interference is coming from internal. Check external interference with spectrum analyzer if there is external interference exsiting.

    • 1.3.5.6 Swapped feeders Phenomena Due to swapped feeders, many problems will occur such as no downlink coverage, no uplink coverage or high UL/DL interference. The following are some (but not limited to) examples of swapped feeders:

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 37 of 85

    A C B
    A
    C
    B

    Case 1: Cell B Tx feeder is swapped with the cell A Tx feeder The following symptoms might be observed:

    Scrambling codes cover wrong directions.

     

    Handover fails from other cells to Cell A/Cell B because

     

    of

    improper

    handover

    relationship

    or uplink DPCH

    synchronization problem.

     
     

    Connection setup will fail during random access or uplink

     

    DPCH synchronization procedures.

    Connection

    setup

    fails during

    random

    access

    or

    uplink

    DPCH

    synchronization procedures.

     

    Case 2: Cell B Tx feeder is swapped with one of the cell A Rx feeder. The following symptoms might be observed.

    There is no downlink coverage. (Cell B desired coverage area)

    Downlink interference is high. (Cell A desired coverage area)

    Scrambling code covers wrong direction.

    When the UE tries to connect to cell B in cell A area, connection setup fails during random access or uplink DPCH synchronization procedures.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 38 of 85

    If the UE tries to handover to cell B in cell A area, the UE may always send addition handover events to UTRAN but handover function always fails due to uplink DPCH synchronization problem.

    The UE connected to cell A transmits with higher UE Tx power than that in normal feeder case because of higher UL interference (e.g. UL RSSI).

    Connection drops when the UE moves to the planned cell B area

    Case 3: One of the cell B Rx feeder is swapped with another cell A Rx feeder. The following symptoms might be observed:

    The UE connected to cell A or/and cell B transmits with higher UE Tx power than that in normal feeder case because of higher UL interference (e.g. UL RSSI).

    Recommendation

    The direct solution to remove this problem is to ensure no crossed feeders and correct scrambling codes for the all cells in the site.

    • 1.3.5.7 Low data throughput Phenomena During the drive test, following phenomena might be observed when downloading files to/from the operator’s server (or the known public server) by FTP and pinging that server simultaneously.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 39 of 85

    Average UL or DL throughput of the radio access bearer is much lower than the data rate of the known source or

    Long round trip time or

    Many missing packets.

    Reason 1 – Poor Radio Link Quality

    Poor radio links introduce error bits in packets. To keep integrity of the packets received, system retransmits the error packets. However, this may results in longer RTT and lower data throughput.

    Recommendation

    Refer to “High Downlink Interference”

    Reason 2 - Many Down-Switches Due To Coverage Triggering

    The imbalance between PS64/384 or PS64/128 radio bearer and pilot coverage can trigger channel switching function to switch its radio bearer to the next lower bit rate when it reaches to the coverage border. This results in lower overall throughput of the connection.

    Recommendation

    Improve the network coverage.

    Reason 3 - Many Down-Switches Due To Congestion Control

    Because of congestion, the connection might be switched down to the common channel, causing the low overall throughput of connection.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 40 of 85

    Recommendation

    The problem that low data throughput due to congestion control is rarely happened in pre-launch network. If it happens, changing handover parameter to move traffic to other neighbor cells, or decreasing the CPICH power to reduce the coverage of the congestion cell.

    • 1.3.5.8 Handover Event Detection Failure The handover event detection failure defined in this guide is that the network side does not receive “measurement reports” when the UE enters (or leaves) the desired (or undesired) cell coverage area. Phenomena During the drive test, following phenomena might be observed through drive test tools and UE tracing function.

    The UTRAN fails to receive “measurement reports” from UE or

    The UE does not generate “measurement reports” when it enters the desired cell coverage area or

    The UE does not generate “measurement reports” when it leaves the undesired cell coverage area.

    Reason 1 – Poor Uplink Quality

    UTRAN does not receive “measurement reports” from UE, which implies the quality of poor uplink is poor.

    Recommendation

    Refer to High UE Transmit Power (Uplink Interference)

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 41 of 85

    Reason 2 - Missing Neighboring Relationship

    Missing neighboring cell relationship is another possible reason. Neighboring cell relationship can be checked by monitoring the neighboring cell window during the drive test.

    Recommendation

    To add the desired cell to the neighboring cell lists of the cells in the active set is a common practice. However, too many neighboring cell relationship may make the process for searching pilot channel slow.

    Reason 3 – pilot pollution in dedicated mode

    The third possible reason is pilot pollution in dedicated mode.

    Recommendation

    Refer to solutions about pilot pollution.

    Reason 4 – slow searching or fast UE

    Handover events may be neglected because:

    Many cells in the monitored set slow down the search for pilot channel

    The UE is in fast moving.

    Recommendation

    The usefulness of the handover relationships should be reviewed and the unnecessary relationships should be removed

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 42 of 85

    • 1.3.5.9 No Suitable Cell Phenomena During the drive test, the UE in the idle mode can not camp on any cell and the display of the UE shows “no coverage”. Reason 1 – High Downlink Interference High downlink interference is the possible reason causing no suitable cell. Please refer to “High Downlink Interference” Reason 2 - high restriction on cell (re)-selection parameters The second possible reason causing no suitable cell is high restriction on cell (re)-selection parameters, even though the actual quality and signal strength of the pilot are good enough to provide coverage. The parameters for the cell (re)-selection are:

    QqualMin: Minimum quality for selection/reselection

    QrxlevMin: Minimum level for Selection/Reselection

    UE Max Transmission Power

    Recommendation

    The cell (re)-selection parameters (i.e. QqualMin, QrxlevMin, UE Max Transmission Power) should be reviewed and adjusted to suitable values.

    1.3.6 Assessing Success of Recommended Change

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 43 of 85

    Drive test and performance statistics are often used to assess success of the recommended changes. Drive test conducted in the same problematic area can verify whether these changes improve the performance in the problematic area. Performance statistic in the following few days can be used to check whether there is any side effect to other areas or other cells.

    • 2 OMC Statistics Based Tuning

    2.1 KPIs

    Differentiated Performance Monitoring

    The QoS of differentiated packet switched (PS) and circuit switched (CS) services can be assessed through counters collected and classified in the RNS. The analytical approach assumes that the network topology where the service performances are analysed is already defined (or selected within a wider scope) together with the measurement period (history), and user satisfaction criteria.

    The identified area may encompass radio network controllers (RNC), base stations (BSs) or Node Bs, cells and the interface between the base station and the radio network controller (Iub). Our target is to define essential counters and key performance indicators (KPIs) that need to be retrieved, and/or derived from measurements in NEs, for a capacity and QoS status view in the RNS and/or a detailed performance analysis. In the latter case, for example, performance results may be compared directly to the target values or, since only the QoS perceived by end-user matter, expressed in terms of satisfied users. The network administrator may then compare the number of satisfied users to the related target thresholds defined a priority.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 44 of 85

    Classification of Counters

    CS Conversational

    Call type: Speech or Transparent (T) data Guaranteed bit rate Transport channel type: e.g. DCH

    CS Streaming

    Non Transparent (NT) data Guaranteed bit rate Transport channel type: e.g. DCH

    PS Conversational

    Guaranteed bit rate Allocation Retention Priority (ARP) Transport channel type: e.g. DCH

    PS Streaming

    Guaranteed bit rate Allocation Retention Priority (ARP) Transport channel type: e.g. HS-DSCH, DCH

    PS Interactive

    Maximum bit rate Traffic Handling Priority (THP) Allocation Retention Priority (ARP) Transport channel type: e.g. HS-DSCH, DCH, FACH, RACH

    PS Background

    Maximum bit rate Allocation Retention Priority (ARP) Transport channel type: e.g. HS-DSCH, DCH, FACH, RACH

    Cell, RNC, URA, RA and LA identifiers

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 45 of 85

    QoS Monitoring

    Uplink Eb/N0, BLER and BER

    In the UMTS system the QoS is typically defined in terms of the BLER that the system must provide for the specific application. The required BLER is maintained through the combined operation of several different mechanisms. Among these, power control is unique in terms of its short latency and ability to compensate for large changes in propagation and interference conditions.

    BLER: This is long-time average block error rate calculated from transport blocks.

    A transport block is considered to be erroneous if a CRC error is indicated by appropriate information element of Framing Protocol for uplink data. Unfortunately there is not good downlink BLER report specified yet that could be sent by user equipment. Only RRC measurement report with event-ID e5a indicates that downlink BLER exceeded a defined threshold.

    BER: Bit error rate (BER) can either be measured as Transport Channel BER or Physical Channel BER. Reports are sent by Node B to RNC for uplink data. The uplink BER is encoded in Framing Protocol Quality Estimate value.

    SIR Error: This shows the gap between the assigned SIR target and measured SIR. Analysis of SIR error per connection shows how good the SRNC is able to adjust uplink transmission power of UE, which means accuracy of Open Loop Power Control.

    Downlink BLER Computation The downlink transport channel block error rate (BLER) is based on evaluating the CRC of each transport block associated with the

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 46 of 85

    measured transport channel after RL combination. The BLER is computed over the measurement period as the ratio between the numbers of received transport blocks resulting in a CRC error and the number of received transport blocks. The mobile when explicitly ordered by the network may report such a measurement periodically on event based

    Throughput Computation The throughput relates only to the correctly received bits during a predefined measurement period (observation time), denoted by S in the following, where RLC buffers are not empty.

    RLC Retransmission Rate

    This indicator relates to number of retransmissions required to transmit an RLC PDU when the first transmission was not successful through the radio interface. The metric can be used to set the maximum number of allowed link layer retransmissions without compromising the load of the cell for the global quality of service requirements

    Service Data Unit Error Ratio The SDU error ratio is defined as the fraction of SDUs lost or detected as erroneous

    Downlink Transfer Delay Computation The transfer delay is defined as maximum delay for 95th percentile of the distribution of delay for all delivered SDUs during the lifetime of a bearer service, where delay for an SDU is defined as the time from a request to transfer an SDU at one SAP to its delivery at the other SAP. In practice, in these terms, the statistical measurement of the transfer delay would require to measure the delay of all delivered SDUs during the lifetime of one bearer service and save the corresponding values separately so that the distribution of delay could be derived. The

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 47 of 85

    transfer delay would then be the delay that is greater than or equal to the delays of 95% of the delivered SDUs during the lifetime of the bearer service. Hence, the transfer delay measurement may become an issue when a statistical analysis is required.

    Downlink Jitter Computation The jitter of a specific bearer service is defined as the difference between the one-way delays of the selected packet pair, e.g. consecutive packets.

    QoS Accessibility and Retainability Monitoring

    Accessibility and retainability measurements are based on the success/failure of procedures needed to setup, modify or maintaining a certain bearer service or signalling connection. Hence, the proposed measurements are attached either to the successful or the unsuccessful issue of a procedure for RAB or signalling connection management.

    RAB Management

    Five measurement types may be defined for CS and PS domains

    Number of RAB assignment attempts: On receipt by the RNC of a RANAP RAB ASSIGNMENT REQUEST message for CN, each RAB assignment request is added to RAB.AttEstab.m counter.

    Number of successfully established RABs: On transmission by the RNC of a RANAP RAB ASSIGNMENT RESPONSE message to the CN, each successfully established RAB is added to RAB.SuccEstab.m counter.

    Number of RAB establishment failures: On transmission by the RNC of a RANAP RAB ASSIGNMENT RESPONSE message to the CN, each

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 48 of 85

    RAB failed to establish is added to RAB.FailEstab.Cause.m counter according to the failure cause.

    RAB connection set-up time (mean): This measurement is obtained by accumulating the time intervals RAB.SuccEstabSetupTimeMean.m for each successful RAB establishment, which is then divided by the number of successfully established RABs observed in the granularity period to give the arithmetic mean.

    RAB connection set-up time (maximum): This measurement may be obtained by the high tide mark RAB.SuccEstabSetupTimeMax.m of the monitored time intervals for each successful RAB establishment.

    Number of RAB releases: On transmission by the RNC of a RANAP RAB RELEASE REQUEST message, each RAB requested to be released is added to the relevant per cause measurement RAB.Rel.Cause.m.

    KPI may be derived from above:

    Bearer Accessibility

    UMTS Optimization Guideline Page 48 of 85 RAB failed to establish is added to RAB.FailEstab.Cause.m counter

    Bearer Reliability

    UMTS Optimization Guideline Page 48 of 85 RAB failed to establish is added to RAB.FailEstab.Cause.m counter

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 49 of 85

    Both Bearer Accessibility and Reliability product of the two KPIs above result in RAB Success Ratio

    UMTS Optimization Guideline Page 49 of 85 Both Bearer Accessibility and Reliability product of the two

    Signalling Connection Management

    • Attempted signalling connection establishments: This measurement provides the number of attempts SIG.AttConnEstab.m by RNC to establish an Iu control plane connection with the CN. In this case, m may simply denote the PS or CS domain. The trigger point is the transmission of a RANAP Initial UE message by the RNC to the CN, which is sent by the RNC on receipt of an RRC Initial Direct Transfer message from the UE.

    Attempted RRC connection establishments: This measurement provides the number of RRC connection establishment attempts for each establishment cause. On receipt of an RRC Connection Request message by the RNC from the UE, each received RRC Connection Request message is added to the relevant per cause measurement RRC.AttConnEstab.Cause.

    Failed RRC connection establishments: This measurement provides the number of RRC establishment failures for each rejection cause. On transmission of an RRC Connection Reject message by the RNC to the UE, or an expected RRC CONNECTION SETUP COMPLETE message not received by the RNC, each RRC Connection Reject message received is added to the relevant per cause measurement RRC.FailConnEstab.Cause.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 50 of 85

    Successful RRC connection establishments: This measurement provides the number of successful RRC establishments for each establishment cause. On receipt by the RNC of a RRC CONNECTION SETUP COMPLETE message following a RRC establishment attempt, each RRC Connection Setup Complete message received is added to the relevant per cause measurement RRC. SuccConnEstab. Cause.

    • RRC connection set-up time (mean): This measurement is obtained by accumulating the time intervals for every successful RRC connection establishment per establishment cause between the receipt by the RNC from the UE of a RRC CONNECTION REQUEST and the corresponding RRC CONNECTION SETUP COMPLETE message over a granularity period. The end value of this time, denoted as RRC.AttConnEstabTimeMean.Cause, is then divided by the number of successful RRC connections observed in the granularity period to give the arithmetic mean. The measurement is split into sub counters per establishment cause.

    • RRC connection set-up time (max): This measurement is obtained by monitoring the time intervals for each successful RRC connection establishment per establishment cause between the receipt by the RNC from the UE of a RRC CONNECTION REQUEST and the corresponding RRC CONNECTION SETUP COMPLETE message. The high tide mark of this time, RRC.AttConnEstabTimeMax.Cause, is the collected value.

    • Attempted RRC connection releases: This measurement provides the number of RRC connection release attempts per release cause sent from UTRAN to the UE. On transmission of an RRC CONNECTION RELEASE message by the RNC to the UE, each RRC Connection Release message

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 51 of 85

    sent

    is

    added

    to

    the

    RRC.AttConnRel.Cause.

    relevant

    per

    cause

    measurement

    UMTS Optimization Guideline Page 51 of 85 sent is added to the RRC.AttConnRel.Cause. relevant per cause
    UMTS Optimization Guideline Page 51 of 85 sent is added to the RRC.AttConnRel.Cause. relevant per cause
    UMTS Optimization Guideline Page 51 of 85 sent is added to the RRC.AttConnRel.Cause. relevant per cause
    UMTS Optimization Guideline Page 51 of 85 sent is added to the RRC.AttConnRel.Cause. relevant per cause
    • 2.1.1 IRAT - Inter Radio Access Technology (IRAT) performance Handover between WCDMA and GSM allows the GSM technology to be used to give fallback coverage for WCDMA technology. This means subscribers can experience seamless services even with a phased build- out of WCDMA. The IRAT performance is evaluated under the following test cases.

    IDLE mode to GERAN (3G to 2G cell reselection).

    Cell FACH state to Cell PCH state (3G PS state transition)

    URA PCH state (3G PS state transition)

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 52 of 85

    3G to 2G with PDP context activation (PS test; 3G to 2G cell

    reselection) 2G to 3G with PDP context activation (PS test; 2G to 3G cell

    reselection) 3G to 2G CS Handover (CS-only test)

    2G to 3G CS Handover (CS-only test)

    3G to 2G CS Handover with PDP context activation; Multi-RAB

    handover (CS + PS test) Event 3A measurement activation / deactivation

    • 2.1.2 CS Performance additional information

    Customer demand

    Indicator

    Measure

    Service accessability

    Availability & Coverage Blocked calls Call setup delay

    Ec/No, RSCP Admission control RAB assignment

    Service integrity

    Voice quality

    Noisy frames (FER), MOS

    Service retainability

    Dropped calls

    Handover failure No coverage Interference

    • 2.1.3 PS Performance additional information

    Customer demand

    Indicators

    Measures

    Service accessability

    Availability & Coverage Blocked service access Service access delay

    Ec/No, RSCP Admission control Attach, PDP context activation, IP service setup

    Service integrity

    Video quality Audio quality Web page download time E-mail sending time, etc.

    BLER, FER, throughput, delay, jitter

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 53 of 85

    Service retainability

    Dropped data connection Connection timeouts

    Dropped PDP context/attach No coverage Handover failure

    2.2 Tools

    This section gives an overview of the standard Tool setup in collecting, monitoring and analyzing UMTS performance counters and Key Performance Indicators. It discusses briefly the requirements and will mention some known tools in the market today.

    2.2.1 Tools Requirements

    OMC/OSS Configuration

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 54 of 85

    PM Server Citrix Server PM Client Mun Core Network OSS Iu Mur RNC Iur Mub Mub
    PM
    Server
    Citrix
    Server
    PM Client
    Mun
    Core Network
    OSS
    Iu
    Mur
    RNC
    Iur
    Mub
    Mub
    RNC
    Iub
    Router
    OSS PM
    Node B
    Node B
    Client
    UE

    OSS/OMC Setup

    OSS / OMC Server - is an integrated service and management system

    for GSM, GPRS, EDGE and 3G networks. It has 3 main features –

    Configuration Management, Performance Management

    and

    Management.

    Fault

    Performance Management Server – is 3 rd party Application Server

    capable of generating Performance Reports. Client/s can be setup to

    access this application through CITRIX.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 55 of 85

    OSS Performance Management Application – is a third party

    application supported by the OSS. It can query the Performance

    database from the OSS, create and generate Performance Reports and

    customized KPI and formulas. Users or clients can connect and access

    this application through CITRIX.

    Some common features:

    User defined KPI’s

    User defined reports

    Real time reporting

    Trending and Historical reports

    Library of pre-configured calculations and KPI’s

    Export to excel or any database format

    Alarm monitoring

    2.2.2 Tools Currently Available to Capture / Process Data

    NetworkAssure by Vallent (formerly Watchmark Prospect)

    NetworkAssure is a high performance management (PM) solution that pulls

    together OSS data to manage the most complex multi-vendor, multi-

    technology networks. It provides a seamless aggregation and correlation of

    data from multi-vendor, multi technology networks and pre-built network

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 56 of 85

    interfaces for technologies, including UMTS, GSM, GPRS, IP, CDMA,

    ATM/FR, transmission, switched voice and others.

    Metrica / NPR data management systems (DMR)

    Metrica/NPR gets you up and running quickly, with preconfigured solutions for

    major network technologies. These Technology Layers include GSM, GPRS,

    UMTS, IP and Voice Switching. With Metrica/NPR you get all the benefits of a

    configurable, modular solution that you can easily extend and modify. It

    interprets and manages large volumes of data at high performance, provides

    comprehensive and easy to view performance information for business and

    operational users, identifies problem areas and discovers underlying trends

    before service-affecting problems occur and provides historical reporting and

    forecasts performance trends and helps to predict effects of network change.

    OPTIMA by Aircom

    Provides historical reporting and forecasts performance trends and helps to

    predict effects of network change.

    Some

    typical

    uses

    of

    Optima

    for

    network

    operation

    and

    performance

    management are:

    Daily reporting of cell, site, BSC, MSC and transmission network

    performance.

    Daily reporting of any cluster of cell sites or network elements covering

    particular cities, roads or other geographical regions.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 57 of 85

    Identification of performance anomalies across network regions.

     

    Overall monitoring of alarms and equipment operational status.

    Identification and strategic reporting of traffic hotspots and network

    locations generating high traffic and revenues.

     

    Nokia Netact

    Integrated

    network

    and

    service

    management

    system

    for

    GSM/GPRS/EDGE/3G networks

    Modular, scalable and open solution for operating mobile networks

    Supports operator processes

    Provides smooth management evolution towards a more service

    oriented world

    Multi vendor

    Ericsson OSS

    Ericsson’s OSS-RC provides fault, performance and configuration

    management of Radio and Core networks.

    Configuration Methods

    Export configuration data then import configuration changes

    through the OSS. Enter configuration changes via the OSS Graphical User Interface

    (GUI). Make configuration changes in the UTRAN via a ChangeAll script.

    Use EMAS (Element Manager Software).

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 58 of 85

    Call Trace Capability

    Ericsson OSS supports three different types of call trace namely UETR, CTR and GPEH.

    UETR – User Equipment Traffic Recording

    CTR – Cell Traffic Recording

    GPEH – General Performance and Event Handling

    2.3 Post-Launch Optimization Process

    Testing and monitoring QoS in the UMTS network requires several kinds of analysis actions and network monitoring through the whole life cycle of the UMTS network, starting from the network element development and ending with the operation of the network. The protocol layers carrying signaling and user plane data have to be accessed and verified to ensure proper network performance. Protocol analysis and tracing of protocol messages are required for troubleshooting purposes and for finding the origins of any problems. For long term monitoring, the signaling and user plane traffic on the protocol layers must be recorded and analyzed with post-processing tools as well as with applications capable of visualizing real-time metrics and following certain Key Performance Indicators. Real time analysis is usually done using several of the OSS tools which help in recording and scheduling real time reports. These reports contain several KPIs which help in understanding any key problems in the network and also enable us to implement quick changes in the network in a very time efficient manner. Most reports provide key statistical reports such as traffic and RF measurements which enable to rectify problems and help in troubleshooting process without the need of any extra resources.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 59 of 85

    OMC Reports Recording Definition OSS Applications Recording Node B RNC Data
    OMC
    Reports
    Recording
    Definition
    OSS Applications
    Recording
    Node B
    RNC
    Data

    2.3.1 Data Post-processing and Root-Cause Analysis

    Statistical measurements play an important and more traditional role in the operative networks when QoS is controlled. Moreover, statistical measurements can be utilized right after rollouts to validate the UMTS network’s ability to provide satisfactory QoS level.

    For performing QoS measurements, a monitoring tool is needed. It explores characteristics of a UMTS network in the field or in the laboratory by analyzing and monitoring both signaling and user plane traffic captured with probes from the network interfaces. The QoS monitoring system consists of network probes and sophisticated software for analyzing the captured traffic.

    QoS monitoring software consists of two main software components: the GUI (graphical user interface) for operating the QoS monitoring system

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 60 of 85

    and showing the results of the QoS measurements, and the QoS server software for processing the gathered information. The QoS server software performs all the analysis of the information captured from the UMTS interfaces.

    Current setup in the network has a built-in QoS Monitoring in the OSS/OMC or as a third party application supported by the OSS/OMC vendor. Raw data from the counter measurement tables are fetched and converted in database or text format by a Mediation application. These data are then available for the OSS Performance application and third party Performance Monitoring application.

    QoS Statistics Call Trace Capacity Statistics Call Trace Capacity Measurement Measurement GUI Measurement Measurement QoS Monitor
    QoS
    Statistics
    Call Trace
    Capacity
    Statistics
    Call Trace
    Capacity
    Measurement
    Measurement
    GUI
    Measurement
    Measurement
    QoS Monitor
    QoS
    Software
    DB
    Probe Probe Probe
    Probe
    Probe
    Probe

    QoS Monitor Structure

    The basic features of the QoS Monitoring system are for statistics measurements, capacity measurements and call tracing.

    Root Cause Analysis.

    As the amount of UMTS subscribers quickly increases, operators and equipment vendors are facing big challenges in maintaining and troubleshooting their networks.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 61 of 85

    We may raise the question of how one can efficiently narrow down the root causes of the problems when there is a huge amount of subscribers and traffic in a live UMTS network.

    What are the principles of examination of the fault scenarios and

    narrowing

    down

    the

    problem

    manageable pieces?

    investigation

    into

    logical

    MT Call MO Call RRC RRC Paging Connection RAB User-Plane Paging Connection RAB Establishment User-Plane Establishment
    MT Call
    MO Call
    RRC
    RRC
    Paging
    Connection
    RAB
    User-Plane
    Paging
    Connection
    RAB
    Establishment
    User-Plane
    Establishment
    Data Flow
    Establishment
    Establishment
    Data Flow

    Overview of UMTS Call Setup

    Before investigating and solving KPI triggered faults, make sure the following has been performed:

    • 1. The general alarm status of the network has been checked. No clear network alarms pointing to the root cause of the fault can be detected.

    • 2. Traces from external interfaces of RNC have been taken with a protocol analyser in order to record the fault scenario. Also RNC internal trace has been taken when the fault took place.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 62 of 85

    Troubleshooting Process Flowchart:

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 63 of 85

    New SW, HW, parameters, UE model or feature introduced?
    New SW, HW,
    parameters, UE
    model or feature
    introduced?
    UMTS Optimization Guideline Page 63 of 85 New SW, HW, parameters, UE model or feature introduced?
    UMTS Optimization Guideline Page 63 of 85 New SW, HW, parameters, UE model or feature introduced?

    Network troubleshooting means to detect problems, and then find and eliminate the root causes of these problems. The fewer problems one finds, the higher quality of services can be guaranteed.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 64 of 85

    The KPIs are useful because they give a first overview of network quality and behavior and they may also be helpful to identify possible problems in defined areas of the network. However, simple counters and simple ratio formulas are often not enough. For instance, if the already defined GRPS Attach Failure Ratio is calculated per SGSN, it can be used to indicate whether there is an extremely high rate of rejected GPRS Attach Requests in a defined SGSN area. However, such a high Attach Failure Ratio does not need to indicate a network problem by itself. Always a further analysis is necessary to find the root cause of network behavior. Based on the root cause analysis it can be determined whether there are problems or not. This procedure is also called drill-down analysis.

    In case of rejected GPRS attach, the first step of analysis will always be to check the reject cause value of the Attach Reject message. A value that is often seen here is the cause “network failure.” From 3GPP 24.008 (Mobility Management, Call Control, Session Management) it is known that the cause value “network failure” is used “if the MSC or SGSN cannot service an MS generated request because of PLMN failures, e.g. problems in MAP.” A problem in MAP may be caused by transmission problems on Gr interface between SGSN and HLR. The address of a subscriber’s HLR is derived from IMSI and the best way to analyze the procedure is to follow up the MAP signaling on Gr interface after GRPS Attach Request arrives at SGSN. On Gr it can be seen whether there is a response from HLR or not and how long does it take until the response is received.

    Common reasons why GPRS attach attempts are rejected with cause “network failure” are expiry of timers while waiting for answer from HLR, because of too much delay on signaling route between SGSN and HLR

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 65 of 85

    abortion of MAP transactions because of problems with

    different software versions (application contexts) in SGSN and HLR invalid IMSI (e.g., if a service provider does not exist anymore,

    but its USIM cards are still out in the field) routing of MAP messages from foreign SGSN to home HLR of subscriber impossible, because there is no roaming contract between foreign and home network operators

    The first two reasons indicate network problems that shall be solved to improve the general quality of network service. The latter two reasons show a correct behavior of the network that prevents misusage of network resources by unauthorized subscribers.

    This example shows how difficult it is to distinguish between “good cases” (no problem) and “bad cases” (problem) in case of a single reject cause value. In general, four main features can be identified as main requirements of good KPI analysis:

    Intelligent multi-interface call filtering

    Provision of useful event counters

    Flexible presentation of measurement results from different points of view(sometimes called dimensions), e.g., show first Attach Rejects messages by cause values and then show IMSI of rejected subscribers related to one single cause value (to find out if they are roaming subscribers or not) Latency measurement to calculate time differences, e.g., between request and response messages

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 66 of 85

    Failure Cause-Type Per Measurement.

    RAB Assignment Failures

    RAB Release Cause Type

    Protocol

    Cause type

    Description

    RANAP

    Radio layer network cause

    Relocation Triggered

    RANAP

    Radio layer network cause

    Unable to Establish During Relocation

    RANAP

    Radio layer network cause

    Requested Ciphering and/or Integrity Protection algorithms not Supported

    RANAP

    Radio layer network cause

    Failure in the Radio Interface Procedure

    RANAP

    Radio layer network cause

    Requested Traffic Class not available

    RANAP

    Radio layer network cause

    Invalid RAB Parameters Value

    RANAP

    Radio layer network cause

    Invalid RAB Parameters Combination

    RANAP

    Radio layer network cause

    Condition Violation for SDU Parameters

    RANAP

    Radio layer network cause

    Invalid RAB ID

    RANAP

    Radio layer network cause

    Interaction with other procedure

    RANAP

    Radio layer network cause

    Request superseded

    RANAP

    Transport layer cause

    Iu Transport Connection Failed to Establish

    RANAP

    Protocol cause

    Transfer Syntax Error

    RANAP

    Protocol cause

    Semantic Error

    RANAP

    Protocol cause

    Message not compatible with receiver state

    RANAP

    Protocol cause

    Abstract Syntax Error (Reject)

    RANAP

    Protocol cause

    Abstract Syntax Error (Ignore and Notify)

    RANAP

    Protocol cause

    Abstract Syntax Error (Falsely Constructed Message)

    RANAP

    Miscellaneous cause

    No Resource Available

    RANAP

    Miscellaneous cause

    Unspecified Failure

    Internal

    Other causes

    RANAP

    Radio layer network cause

    Requested guaranteed bit rate not available

    Radio Link Setup Failures

    RAB Release Cause Type

    Protocol

    Cause type

    Description

    NBAP

    Radio layer network cause

    Unknown C-ID

    NBAP

    Radio layer network cause

    Cell not available

    NBAP

    Radio layer network cause

    Power level not supported

    NBAP

    Radio layer network cause

    DL radio resources not available

    NBAP

    Radio layer network cause

    UL radio resources not available

    NBAP

    Radio layer network cause

    RL Already Activated/allocated

    NBAP

    Radio layer network cause

    Node B Resources unavailable

    NBAP

    Radio layer network cause

    Requested configuration not supported

    NBAP

    Radio layer network cause

    Unspecified

    NBAP

    Radio layer network cause

    Invalid CM setting

    NBAP

    Radio layer network cause

    Number of DL codes not supported

    NBAP

    Radio layer network cause

    Number of UL codes not supported

    NBAP

    Radio layer network cause

    UL SF not supported

    NBAP

    Radio layer network cause

    DL SF not supported

    NBAP

    Radio layer network cause

    Dedicated Transport Channel Type not sup-

    NBAP

    Radio layer network cause

    CM not supported

    NBAP

    Transport layer network cause

    Transport resource unavailable

    NBAP

    Transport layer network cause

    Unspecified

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 67 of 85

    NBAP

    Protocol cause

    Protocol error

    NBAP

    Miscellaneous cause

    Control processing overload

    NBAP

    Miscellaneous cause

    OAM intervention

    NBAP

    Miscellaneous cause

    Hardware failure

    NBAP

    Miscellaneous cause

    Not enough user plane processing resources

    NBAP

    Miscellaneous cause

    unspecified

    Internal

    Cause type not applicable

    No Reply

    Outgoing Hard Handover

    Hard Handover Failure Causes

    Protocol

    Cause type

    Description

    RRC

    Failure cause (RRC)

    Configuration unsupported

    RRC

    Failure cause (RRC)

    Physical channel failure

    RRC

    Failure cause (RRC)

    Incompatible simultaneous reconfigurations

    RRC

    Failure cause (RRC)

    Protocol error

    RRC

    Failure cause (RRC)

    Compressed mode runtime error

    RRC

    Failure cause (RRC)

    Cell update occurred

    RRC

    Failure cause (RRC)

    Invalid configuration

    RRC

    Failure cause (RRC)

    Configuration incomplete

    Internal

    Cause type not applicable

    No Reply

    Hard Handover Failure per Adjacent Cell Pair Causes

    Protocol

    Cause type

    Description

    RRC

    Failure cause (RRC)

    Configuration unsupported

    RRC

    Failure cause (RRC)

    Physical channel failure

     

    Incompatible simultaneous

    RRC

    Failure cause (RRC)

    reconfigurations

    RRC

    Failure cause (RRC)

    Protocol error

    RRC

    Failure cause (RRC)

    Compressed mode runtime error

    RRC

    Failure cause (RRC)

    Cell update occurred

    RRC

    Failure cause (RRC)

    Invalid configuration

    RRC

    Failure cause (RRC)

    Configuration incomplete

    Internal

    Cause type not applicable

    NoReply

    Inter-RAT Hard Handover

    Inter-RAT Hard Handover Failure Causes

    Protocol

    Cause type

    Description

     

    Configuration

    RRC

    Inter-RAT handover failure

    unacceptable

    RRC

    Inter-RAT handover failure

    Physical channel failure

    RRC

    Inter-RAT handover failure

    Protocol error

    RRC

    Inter-RAT handover failure

    Inter-RAT Protocol error

     

    Configuration

    RRC

    Inter-RAT change failure (RRC)

    unacceptable

    RRC

    Inter-RAT change failure (RRC)

    Physical channel failure

    RRC

    Inter-RAT change failure (RRC)

    Protocol error

    Hard Handover Failure per Adjacent Cell Pair Causes

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 68 of 85

    Protocol

    Cause type

    Description

     

    Configuration

    RRC

    Inter-Rat handover failure cause

    unacceptable

    RRC

    Inter-Rat handover failure cause

    Physical channel failure

    RRC

    Inter-Rat handover failure cause

    Protocol error

    RRC

    Inter-RAT handover failure cause (RRC)

    Inter-RAT Protocol error

     

    Configuration

    RRC

    Inter-RAT change failure (RRC)

    unacceptable

    RRC

    Inter-RAT change failure (RRC)

    Physical channel failure

    RRC

    Inter-RAT change failure (RRC)

    Protocol error

    Iu Release

    Iu release request causes

    Protocol

    Cause type

    Description

    RANAP

    Radio layer network cause

    Failure in the Radio Interface Procedure

    RANAP

    Radio layer network cause

    Release due to UTRAN Generated Reason

    RANAP

    Radio layer network cause

    User inactivity

    RANAP

    Radio layer network cause

    Iu UP failure

    RANAP

    Radio layer network cause

    Repeated Integrity Checking Failure

    RANAP

    Radio layer network cause

    Release due to UE generated signaling connection re-

    RANAP

    Radio layer network cause

    Directed retry

    RANAP

    Radio layer network cause

    Radio Connection With UE Lost

    RANAP

    Miscellaneous cause

    OAM intervention

    Iu release command causes

     

    Protocol

    Cause type

    Description

    RANAP

    Radio layer network cause

    Relocation Cancelled

    RANAP

    Radio layer network cause

    Successful Relocation

    RANAP

    Radio layer network cause

    Release due to UTRAN Generated Reason

    RANAP

    Radio layer network cause

    User inactivity

    RANAP

    Radio layer network cause

    Iu UP failure

    RANAP

    Radio layer network cause

    No Remaining RAB

    RANAP

    Radio layer network cause

    Release due to UE generated signaling connection release

    RANAP

    Radio layer network cause

    Directed retry

    RANAP

    NAS Cause

    Normal Release

    RANAP

    Miscellaneous cause

    Unspecified Failure

    Internal

    Other causes

    RANAP

    Radio layer network cause

    Failure in the Radio Interface Procedure

    RANAP

    Radio layer network cause

    Repeated Integrity Checking Failure

    RANAP

    Radio layer network cause

    Radio Connection With UE Lost

    RANAP

    Miscellaneous cause

    OAM intervention

    Admission Control

    Causes for admission control rejections

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 69 of 85

    Protocol

    Cause type

    Description

    Internal

    Non-standard cause

    Maximum uplink load

    Internal

    Non-standard cause

    Maximum downlink load

    Internal

    Non-standard cause

    Code allocation failure

     

    Congestion Control is

    Internal

    Non-standard cause

    ongoing

    2.3.2 Optimization Strategy per Root-cause and/or Problem Category/Type/Area

    The root cause for degradation of network performance can be summed up into two different categories.

    Drop calls due to abnormal RAB release

     

    Failures due to Intrafrequency mobility

    handovers

    triggered

    by

    radio

    conditions,

    Interfrequency coverage

    Handovers

    triggered

    by

    capacity

    and

    Intersystem Handovers (ISHO) triggered limited UMTS coverage

    by mobility and

    The raw counters can be classified into three types according to the interval in which it is updated.

    1) Cumulative Counter :

    Measurement data is incremented every time a message is received from the monitored object or every time an event occurs in the monitoring object.

    2) Gauge Counter:

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 70 of 85

    The data of the monitoring object changes during the granularity period, and the measurement data in that period are calculated in the end of that period. 3) Suspect Flag:

    Set to ON when regular measurement data cannot be properly collected in the granularity period.

    Some measurements are not really related to one dedicated cell, but to an active linkset, which in case of soft handover comprises more than one cell. There are different approaches for these measurements:

    • a) “All cells” approach: measurement is considered for every cell of the

    active link set.

    • b) “Newest cell” approach: measurement is considered for the most

    recently added

    cell of the active link set only.

     

    The

    diagram

    below

    shows

    the

    counters

    classified

    according

    to

    measurements.

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 71 of 85

    UMTS Optimization Guideline Page 71 of 85 There are vendor specific raw counters which can be

    There are vendor specific raw counters which can be formulated for

    different

    KPIs

    and

    that

    gives

    a

    statistical

    insight

    of

    the

    network

    performance.

     

    Drop Call

    The un-normal release of a connection UTRAN originated is indicated either by the RAB RELEASE REQUEST message or the IU RELEASE REQUEST message transmitted from the RNC to the CN. The RAB RELEASE REQUEST message will be used when the failure occurs in the RAB management as e.g. “firmware failure PRLC, DHT”. In any case the UE is still reachable via a RRC connection. The IU RELEASE REQUEST message is used in case the UE is lost at the air interface. The CN will

    inCode CONFIDENTIAL and PROPIETARY

    UMTS Optimization Guideline

    Page 72 of 85

    re