3G Optmising, Mainitaining, Troubleshooting

Metadata on the cover page and rendition header and footer are automatically generated from the ShareNet-IMS application. For the actual document metadata please see the first page of the actual document.

Optmising, mainitaining, troubleshooting

NSN Document Number

D400556184

Version Number

1.0

Confidentiality Confidential

Document Type

Unspecified

Document Owner

Vepsalainen, Tarja Leena Annikki

Document Created By

Vepsalainen, Tarja Leena Annikki

Document Creation Date

09/26/2006 10:23 AM

Version Created By

IMS Content Management, NSN

Document Modify Date

11/08/2011 12:34 PM

Reviewers

Date Reviewed

Approver

Actual approval date

Lifecycle Status

Document Location

Enterprise:NSN:NWS - Network Systems:NWS Archive:Former RA Archive:PI_400_745_Archive_Completed Programs and Projects_WCDMA RAN:WCDMA RAN System Programs:RAS05 System Program:PILS:Customer Documentation Masters RAN05:Performance Monitoring

Document ID 400556184

Document Overview URL

https://sharenet-ims.inside.nokiasiemensnetworks.com/livelink/livelink/overview/D400556184

Optmising, mainitaining, troubleshootingD400556184 1.0

Confidential



Optimising, Maintaining andTroubleshooting WCDMA RAN

dn02241406Issue 7 en

# Nokia CorporationNokia Proprietary and Confidential

1 (176)


Confidential

R: 1/176

The product described in this document is still under development by Nokia Networks. However,in the interest of offering early possibility to our customers to evaluate the documentation, thisdocumentation is provided in draft form. Therefore the customer understands that theinformation in this document is subject to change without notice and describes only the prototypeproduct defined in the introduction of this documentation in its current state of development.Nokia Networks welcomes customer comments as part of the process of continuousdevelopment and improvement of its products and the documentation.

This document is not a final customer document and Nokia Networks does not takeresponsibility for any errors or omissions in this document. No part of it may be reproduced ortransmitted in any form or means without the prior written permission of Nokia Networks. Thedocument has been prepared to be used by professional and properly trained personnel, and thecustomer assumes full responsibility when using it.

The information or statements given in this document concerning the suitability, capacity, orperformance of the mentioned hardware or software products cannot be considered binding butshall be defined in the agreement made between Nokia Networks and the customer.

Nokia Networks WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THISDOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDINGMONETARY LOSSES), that might arise from the use of this document or the information in it.UNDER NO CIRCUMSTANCES SHALL NOKIA BE RESPONSIBLE FOR ANY LOSS OF USE,DATA, OR INCOME, COST OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES,PROPERTY DAMAGE, PERSONAL INJURY OR ANY SPECIAL, INDIRECT, INCIDENTAL,PUNITIVE OR CONSEQUENTIAL DAMAGES HOWSOEVER CAUSED.

THE CONTENTS OF THIS DOCUMENT ARE PROVIDED "AS IS". EXCEPT AS REQUIREDBY APPLICABLE MANDATORY LAW, NO WARRANTIES OF ANY KIND, EITHER EXPRESSOR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT,ARE MADE IN RELATION TO THE ACCURACY, RELIABILITY OR CONTENTS OF THISDOCUMENT. NOKIA RESERVES THE RIGHT TO REVISE THIS DOCUMENT ORWITHDRAW IT AT ANY TIME WITHOUT PRIOR NOTICE.

This document and the product it describes are protected by copyright according to theapplicable laws.

NOKIA and Nokia Connecting People are registered trademarks of Nokia Corporation. Otherproduct names mentioned in this document may be trademarks of their respective companies,and they are mentioned for identification purposes only.

Copyright © Nokia Corporation 2005. All rights reserved. Reproduction, transfer, distribution orstorage of part or all of the contents in this document in any form without the prior writtenpermission of Nokia is prohibited.

2 (176) # Nokia CorporationNokia Proprietary and Confidential


Optimising, Maintaining and Troubleshooting WCDMA RAN


Confidential

R: 2/176

Contents

Contents 3

1 Changes in Optimising, Maintaining and Troubleshooting betweenRAN04 and RAS05 5

2 Optimising WCDMA RAN 72.1 Optimising and expanding WCDMA RAN 72.2 Principles of optimising GSM/WCDMA interworking 132.3 Network element management unit 152.4 Parameters for optimising WCDMA RAN 16

3 Monitoring WCDMA RAN 17

4 Managing faults in WCDMA RAN 214.1 Troubleshooting a radio access network 214.2 Troubleshooting WCDMA RAN 254.3 Tracing and correcting faults in WCDMA RAN 28

5 Measuring WCDMA RAN 31

6 Maintaining WCDMA RAN 376.1 Checklist for proactive maintenance 376.2 Checklist for daily maintenance routines 376.3 Checklist for weekly maintenance routines 386.4 Checklist for biannual maintenance routines 39

7 Monitoring use cases 417.1 Use cases 417.1.1 Use cases for monitoring services 417.1.2 Use cases for monitoring resource availability 417.1.3 Use cases for throughput and load monitoring 427.1.4 Use cases for mobility 427.1.5 Use cases for quality 427.2 Service set-up monitoring use cases 437.2.1 RRC connection set-up monitoring 437.2.2 RAB set-up monitoring 497.2.3 HS-DSCH set-up monitoring 547.3 Service release monitoring use cases 597.3.1 RRC connection release monitoring 597.3.2 RAB AMR release monitoring 657.3.3 HSDPA (HS-DSCH) availability monitoring 717.4 Logical resource availability monitoring use cases 717.4.1 Common channel (CCH) availability monitoring 717.4.2 Dedicated channel (DCH) availability monitoring 767.4.3 HSDPA (HS-DSCH) availability monitoring 817.5 Resource availability and blocking monitoring use cases 817.5.1 IMA group availability monitoring 817.5.2 SDH path availability monitoring 85



3 (176)

Contents


Confidential

R: 3/176

7.5.3 AAL2 path Iub resource monitoring (non-HSDPA) 887.5.4 AAL2 path Iub resource monitoring (HSDPA enabled) 937.6 Throughput and load monitoring use cases 997.6.1 Total load monitoring 997.6.2 Noise rise monitoring 1067.6.3 Traffic amounts of RBs 1107.6.4 Traffic amounts for cells 1147.6.5 HSDPA Iub traffic load monitoring 1187.6.6 Iu-PS traffic load monitoring 1227.7 Mobility use cases 1267.7.1 Soft handover monitoring 1267.7.2 Hard handover monitoring 1317.8 Quality use cases 1377.8.1 Radio connection quality 1377.9 Radio connection quality use cases 1417.9.1 NBAP ATM connection quality monitoring 141

8 Troubleshooting use cases 1458.1 Use cases for troubleshooting services 1458.2 Sleeping cell troubleshooting 1458.3 Repetitive alarms troubleshooting 1498.4 Degraded service due to unavailable resources troubleshooting 1538.5 Coverage verification troubleshooting 1608.6 RAN quality troubleshooting 167

Related Topics 173





Confidential

R: 4/176

1 Changes in Optimising, Maintaining andTroubleshooting between RAN04 andRAS05

Use cases for monitoring and troubleshooting have been added.



5 (176)

Changes in Optimising, Maintaining and Troubleshooting between RAN04 and RAS05


Confidential

R: 5/176





Confidential

R: 6/176

2 Optimising WCDMA RAN

2.1 Optimising and expanding WCDMA RAN

Purpose

The main objectives of WCDMA RAN optimisation are to enable betteravailability of network services (coverage criteria) and to provide a pre-definedservice quality and performance (quality of service, QoS, criteria).

Optimisation based on coverage criteria:

. Coverage for different data rate services and maximum loading based ontraffic forecasts and margins set for load variation. The cell breathing effectallows the cell size to vary with the load: the smaller the load, the greaterthe coverage and vice versa.

. Pilot channel coverage

. Soft handover areas and probabilities

The coverage criteria is ensured by pre-planning as well as continuos measuringand monitoring of a roll-out and running network.

Optimisation based QoS criteria (KPIs):

. Total data throughput in a cell

. End user data throughput (application throughput)

. Delays

. Call setup success rates for different services

. Call drop rates

. Handover performance

The quality of service criteria are verified by following up KPIs.



7 (176)

Optimising WCDMA RAN


Confidential

R: 7/176

The scope and pace of launch optimisation is determined by pre-defined networkquality and performance targets and the roll-out scope and schedule. The mainfocus of pre-launch optimisation is on troubleshooting:

1. locate problem areas

2. prioritise them and

3. fix them accordingly.

The problem solving capabilities and the processes of the network operator'spersonnel should also be in the scope of launch optimisation.

Continuous optimisation aims to maintain network quality and performance whenthe network environment complexity is multiplied due to new features andservices and network expansions and due to increasing traffic in the network.Adapt a systematic approach in upgrading, expanding and improving the networkand set management systems to monitor and improve the network quality andperformance continuously.

Before you start

Note

Change only one parameter at a time so that you can see what kind of influencethat parameter has on the network.

Note

Keep track of all the changes that you make, so that you can restore the networkto the previous configuration if the changes have undesired side effects.

Networks are typically optimised in clusters. Since the frequency is the same, theoptimisation should be conducted simultaneously for the whole cluster. Cellbased optimisation produces the best performance, but in homogeneousenvironment and traffic scenarios it is not much better than cluster basedoptimisation which, however, takes less effort. Geographically isolated clusters,for example clusters that are separated by a hill, will not cause excessiveinterference between each other. However, in practice the rollout plan will havean effect on the initial selection of clusters.





Confidential

R: 8/176

In launch optimisation, pay special attention to:

. interference and noise control (pilot pollution). This exists if received codepower is high but Ec/I0 is very low. Pilot pollution can be optimised by, forexample, reducing the signal of the neighbouring cells and by optimisingantennas' tilts for the neighbouring cells.

. weak coverage. Low mobile receiver power leads to the degradation ofservice quality due to, for example, fading, low Ec/I0, poor FER and it canbe improved by adding a site, a better antenna, or adjusting parameters.

. call functionality problems, for example, call setup fail or call drop

. system performance degradations due to unbalanced control channel, forexample, capacity degradation.

Continuous optimisation is area wide parameter tuning, based on long-termstatistics and trends. Network statistics are usually used to get information fromthe problem spots. If the problem cannot be solved, additionally, fieldmeasurements can be taken into consideration. The aim is to find future problemsin fast growing traffic areas in order to react in time and to be prepared fornetwork expansions. Try to

. locate the problem spots geographically and by network elements bymonitoring the network

. prioritise actions with the help of KPIs

. identify reasons for non-performance by analysing information on variousstatistical indicators and network history.

Summary

The following procedure gives an example of the radio network optimisation.

Steps

1. Agree about master plan.

Decide what new services and features will be introduced in the networkand what kind of capacity and service area expansions will be made.Consider both short and long term modifications. This will clarify whichtargets to set for the network and gives input for future actions, for bothhardware and software, in the plan.

2. Set key performance indicators.



9 (176)



Confidential

R: 9/176

After you have decided on long and short term plans, you can set thetargets for network performance in terms of capacity, coverage, andquality. The key performance indicators are network specific and depend,for example, on the life stage and the needs of the network.

3. Prepare measurement test plan and tool guidelines.

In optimisation, two major measurement types can be defined:

a. drive (or field) test measurements and

b. network management measurements (Nokia NetAct Framework).

Drive test measurements focus on coverage and call related parameters. Itshould be possible to drive the route in 1-2 hours. Otherwise themeasurement data files will be too large and analysing them will be morecomplicated. The measurement routes should include urban, suburban andrural roads, streets and highways but also special areas, for example,shopping centres and airports. The main focus should be on area types withthe tightest requirements for network performance in terms of quality,capacity, and coverage, typically urban regions or traffic hot spots with thedensest penetration of mobile subscribers. The measurement time periodshould be 3-5 working days and cover at least network busy hours.

Network management measurements focus on quality. Activate the neededmeasurements, such as traffic, resource availability, resource access,handover, power control and quality on the RNC level to get the rawcounters needed to build up key performance indicators on networkmanagement and service management level.

Define which tools will be used for making the measurements. Decide howthe reports are presented including what format and template will be used.

4. Run drive test measurements.

Drive according to the predefined routes and make several 2 minute testcalls in the cell cluster area. Store the results into properly named files.

Note

If network configuration changes, repeat the measurements along the sameroutes. Otherwise it is not possible to compare the results for evaluating potentialperformance improvements.

5. Run measurements with NetAct.





Confidential

R: 10/176

Before you start

Note

NetAct statistics are not reliable in the early stage of a network's life due to thesmall number of subscribers. Typically there should be at least 50 calls duringbusy hour per cell.

Run the measurements on the RNC level according to the predefined list ofmeasurements. The raw counters in the NetAct database can be grouped oneach network element level to build up formulas to describe the network interms of performance indicators. The performance indicators can bepredefined or tailored to meet the requirements.

6. Analyse and process measurements.

Use post-processing tools to analyse the network performance.

7. Identify problem.

Check if the resolution database contains descriptions of any similarproblems.

8. Find solution.

Before you start

Note

Missing a site means nonperformance in the area and exclusion zones inacceptance.

Note

Adding a site later will affect neighbouring sites and a re-optimisation in the areais necessary.



11 (176)



Confidential

R: 11/176

Problems can be solved either with hardware changes or parameteroptimisation.

File all optimisation actions into the resolution database for futurereference.

Examples of different solutions are:

. adding or deleting radio network objects

You can use system defaults or a reference site. You can create anew BTS site with a number of cells or new cells to a given site.

When you delete a radio network object, all objects beneath thedeleted object are deleted as well. For example, if you delete a BTSsite, all cells under it are deleted.

. modifying adjacencies

Modifying adjacencies is necessary when BTSs are added to ordeleted from the network.

. RNC split (3G rehosting)

RNC split, which is also known as 3G rehosting, meansreconfiguring and expanding the network by rehosting a BTS site toanother RNC or by adding a new BTS under an RNC using anexisting site as a reference site. For further information about RNCsplit/ 3G rehosting, see the NetAct document Rehosting WCDMABTS Sites.

a. Configure the BTS under the target RNC.

b. Connect the cables from the RNC to the BTS.

c. Unlock the new site under the target RNC.. modifying parameters

Consider whether modifications will affect the services. If they do,plan a date and time for the task and inform the organisation aboutthe plans. If an element has to be locked for modification, it cannottransmit traffic. By planning and preparing for service loss you canminimise the unavailability of services.

Expected outcome

After optimisation, the network should be well balanced.

Verification

Verify the performance against the changes in the network.





Confidential

R: 12/176

Further information

See WCDMA RAS05 Parameter Dictionary, RNC counter documentation (RadioNetwork Controller and Transport and HW counter documents), Radio NetworkAdministration document by RNC and AXC counter documentation forinformation on parameters and counters.

In NetAct documentation see the following documents: Implementing ParameterPlans for WCDMA, Creating WCDMA BTS sites, Rehosting WCMDA BTSsites.

2.2 Principles of optimising GSM/WCDMA interworking

The purpose of optimising GSM/WCDMA interworking is to enhance effectiveutilisation of both GSM and WCDMA networks and by doing so, obtain thelargest possible capacity and coverage still maintaining a good quality of service.

Optimising GSM/WCDMA handover means tuning the parameters that triggerand make inter-system handover between GSM and WCDMA possible. Whenplanning GSM/WCDMA interworking, cell reselection and inter-systemhandover parameters for GSM and WCDMA were planned. In the optimisationphase, those parameters are tuned to meet the needs of the operator.

Handovers from WCDMA to GSM are performed mainly for coverage reasons,whereas handovers from GSM to WCDMA are carried out for load and servicereasons. In other words, WCDMA can be used to relieve GSM overload andGSM extends WCDMA coverage area. GPRS calls are switched to WCDMAwhenever possible.

The possibility to perform an inter-system handover is enabled in WCDMA bycompressed mode. When the mobile station uses the Uu interface in compressedmode, the contents of the Uu interface frame is compressed to open a timewindow through which the mobile station is able to peek and decode the GSMBCCH information.

In RAS05, all dual-mode users in idle mode and call setup phase are kept inWCDMA. In call active phase, the following handovers and cell reselections canbe performed:

. GSM-WCDMA: load based handover

. GPRS-WCDMA: network controlled cell reselection

. WCDMA-GSM: coverage based handover

. WCDMA-GPRS: coverage based network initiated cell reselection



13 (176)



Confidential

R: 13/176

For more information on handovers, refer to Handover Control in NokiaWCDMA RNC Product Documentation.

Coverage based handover

The following triggers in the RNC can initiate the coverage based handover:

. inter-system handover due to Uplink DCH quality

. inter-system handover due to MS Tx power

. inter-system handover due to Downlink DPCH power

. inter-system handover due to CPICH RSPC

. inter-system handover due to CPICH Ec/No

The parameters that trigger WCDMA - GSM handovers can be found in theparameter dictionary. The counters for the triggering and the actual performing ofeach WCDMA - GSM handover can be found in the RNC Counters document.

Load based handover

Optimise load based handover to avoid ping-ponging between systems, that is,unnecessary handovers. Take interference from surrounding cells into account.Set a certain threshold, for example 80%, for the load of a GSM cell. In high loadsituations speech calls are directed to WCDMA to ensure sufficient speechcapacity. If the target cell load seems to be high, that is, there are many rejectedhandovers, set penalty timer to prevent inter-system handover for a certain time.

Service based handover

Direct data calls to WCDMA regardless of GSM load to ensure higher bit ratesfor data users and keep speech calls in GSM, except in high load situations.GPRS calls are shifted to WCDMA whenever possible.

Idle mode of GPRS mobile stations can be controlled by packet BCCH. Thismeans that GPRS mobile stations can be pushed to WCDMA in idle mode.

Dedicated mode GPRS mobile stations can be controlled by network controlledcell reselections for load reasons. Inter-system cell reselections GSM-WCDMAforce a particular mobile station to WCDMA, for example for load reason orinter-system directed retry.





Confidential

R: 14/176

2.3 Network element management unit

Network element management unit (NEMU) is a Windows NT basedmanagement server which is connected to the Telecommunications ManagementNetwork. NEMU is used for running measurements, storing measurement dataand viewing measurement results.

Use NEMU when you want to make local, RNC level changes. Use NokiaNetAct Framework for network level changes.

The main functions of Network element management unit

NEMU provides:

. a platform for different network management applications and tools

. redundant, expandable hard disk capacity for storing, for example,measurement and configuration data and database backups

. scalable hardware to support new applications

. an easy to use graphical user interface

. a mediation functionality between DX/IPA2800 network element andNetAct that can be used, for example, to filter and buffer collected data

. common network element management tools and interfaces for 2G and 3Gnetwork elements

For more information, see Administrative interfaces specification.

Performance management in NEMU

NEMU performs the post-processing of the statistics data required forperformance management in RNC and MGW. In RNC, the radio networkmeasurement timing and handling is located in NEMU, which providesmeasurement timing, starting, and stopping, as well as data handling, storing, andforwarding. For MGW and RNC platform, measurement (ATM and NEperformance) handling is located in the network element and NEMU provides thepost-processing for the ATM module data.

The prerequisite for NEMU performance management is that RNC mustimplement a performance management function. NEMU has several graphicaluser interfaces (GUI):



15 (176)



Confidential

R: 15/176

. RNW Measurement Management for managing radio networkmeasurements

. RNW Measurement Presentation for creating graphical and textualpresentations of radio network measurement data

. NE Measurement Explorer for viewing transmission and NE performancemeasurement data

. NE Threshold Management GUI for managing KPIs and thresholdmonitoring parameters in RNC

. RNW Online Monitoring GUI for viewing the online monitoring data inreal time in either textual or graphical form

Refer to NEMU documentation for more information on NEMU.

2.4 Parameters for optimising WCDMA RAN

For an exhaustive list of parameters, refer to RN WCDMA RAN ParameterDictionary in WCDMA RNC Product Documentation.





Confidential

R: 16/176

3 Monitoring WCDMA RAN

All Nokia radio access network elements have an integrated managementfunction that monitors each element. If any problems occur in the equipment, theelement management function will automatically send an alarm notification to theNokia NetAct Framework. The Nokia NetAct Framework shows the active alarmsituation in the network in real time.

The monitoring of Nokia RAN also includes possibilities to combineconfiguration, counter and alarm data for step by step analysing to find and/orexclude potential problem sources. The possibilities are later presented as usecases in respective sections in the Monitor and Troubleshooting sections.

In the RNC, it is also possible to monitor critical resources, mobility actions, andconnection quality in real time in selected areas. This can be done with the NokiaOnline Monitoring tool.

Monitor capacity

Table 1. Monitoring capacity

Check More information Checkmark

Monitor network capacity. Capacity monitoring helps avoid too high blocking levelsby indicating beforehand if more capacity is needed.

Monitor speech channelcapacity.

Monitor signalling link capacity.

Monitor capacity and load of allinterfaces during busy hours.

Check Cell Load Monitoring type from Online monitoringenhancements.



17 (176)

Monitoring WCDMA RAN


Confidential

R: 17/176

Monitor alarms

Table 2. Monitoring alarms


Check active alarms. . Alarms marked with three asterisks *** requireimmediate actions.

. Alarms marked with two asterisks ** require actionsduring working hours.

. Alarms marked with one asterisk * normally requireno actions.

Monitor connection quality

Table 3. Monitoring connection quality

Check More InformationCheckmark

Monitor dedicated channelquality.

Check Outer Loop Power Control Monitoring type fromOnline monitoring enhancements.

Monitor signalling link quality. Check Outer Loop Power Control Monitoring type fromOnline monitoring enhancements.

Monitor mobility

Table 4. Monitoring mobility

Check More InformationCheckmark

Monitor soft handovers. Check Handover Monitoring type from Online monitoringenhancements.

Monitor hard handovers. Check Handover Monitoring type from Online monitoringenhancements.





Confidential

R: 18/176

Monitor services

Table 5. Monitoring services


Calculate service quality. Criteria for defining service quality are, for example,speed, accuracy, and availability of service.

Priorise fault investigation. Faults that have a greater impact on service qualityshould have a higher priority.

Provide customer careinformation.

Monitoring the use of services gives valuable informationfor various user groups.

Track important customersegments.

It is important to monitor services. that bring the most revenue. are otherwise a cornerstone to business. are used by key subscribers.

Monitor planned work activities

Table 6. Monitoring planned work activities


Follow planned work activities. Planned work activities on some network element maycause service outage.

Filter alarms that are generatedfrom planned work activities.

Filter all alarms that the network element generatesduring the planned work activity.

Normalise monitoring status orescalate problems.

When the planned work activity has been completed,normalise status or escalate possible problems.



19 (176)



Confidential

R: 19/176





Confidential

R: 20/176

4 Managing faults in WCDMA RAN

4.1 Troubleshooting a radio access network

Purpose

Troubleshooting a radio access network is sometimes complicated due to the factthat the system itself is not as simple as, for example, a standard stand-alone PCsince the network elements form a complex whole. To be able to troubleshootnetwork elements you need to understand how the network element works andhow the radio access network is structured, as well as, how the network elementsin the surrounding network interact with your network element.

Troubleshooting is a fault locating process that is needed when a system does notperform as it should or as it does normally. The aim of troubleshooting is to findthe cause of a problem and correct it. To be able to correct problems, you need tobe able to detect and analyse the symptoms of the problem. You also need toknow what is normal performance of a system and what is not. In most cases, asystematic approach works best - study, test and plan before you act.

Before you start

The operators should have clear instructions for their operation and maintenancepersonnel on what to do in abnormal situations. There are several ways to preparefor error situations:

. disaster recovery plan

Establish a disaster recovery plan to help personnel deal with emergencysituations. Remember that emergency situations can be best avoided bydetecting abnormal conditions early. A disaster recovery plan should covervarious disaster scenarios and disaster recovery procedures for personnel.The operation and maintenance personnel should also be able to contactthe persons who are capable of dealing with the problem in question.Therefore, each site should have an escalation plan available withappropriate contact information.

. escalation plan



21 (176)

Managing faults in WCDMA RAN


Confidential

R: 21/176

An escalation plan offers contact lists of internal and external supportpersonnel and services available to tackle problems. It should containinformation on who to contact and in what kind of situations.

. preventive maintenance

Perform preventive maintenance routines on a regular basis. For example,carry out regular alarm and unit state surveillance. For more information,see Checklist for proactive maintenance.

. safecopying

Taking regular safecopies of the software and databases of the radio accessnetwork ensures that you have a functional copy of the software which youcan use if there are problems with the software or hardware of a networkelement. How often you need to take safecopies depends on the size andtype of the radio access network and the network elements.

Safecopying is recommended before any major database changes.

. performance monitoring

The purpose of performance monitoring is to measure the overall quality ofthe system. Performance monitoring can help you to detect very low rate orintermittent problems and possible degradation of some part of the system.The performance monitoring parameters for network elements of differentkinds and sizes vary.

. documentation

Establish a procedure for keeping the documentation up-to-date and makesure that the operation and maintenance personnel have access to allrelevant external and internal documents.

. network element diary

The operator should maintain a network element diary. The diary should benetwork element specific, but you can store it in the Operation andMaintenance Centre if the network element is not usually manned. Startfilling in the network element diary already when the network element isbeing set up and installed. You should record the following events in thenetwork element diary:

- hardware changes

- software and hardware updates (change notes, correction deliveries,and so on)

- essential modifications to the configuration or routing in the networkelement

- safecopying





Confidential

R: 22/176

- operational failures

- any other relevant information

A network element diary can provide useful information on the system'sperformance in the past and hints on what might cause the currentproblems.

. configuration management

After installing and integrating network elements or software into thenetwork, enter information on the hardware and/or software into a systemwhich keeps track of all the network equipment.

Caution

When handling plug-in units, it is important to use Electrostatic Precautions(ESP). This means that you must be earthed to equipment racks using anapproved wrist strap and connecting lead. Approved ESP equipment makes aresistive connection to ensure the safety of the personnel and to prevent a suddenstatic discharge during connection to the earthing point.

Note

Remember that random actions can make the problems worse. Generally, youshould not take any radical corrective actions, if you are not sure what theproblem is and what the consequences of the corrective actions are. However,even though you may not be able to analyse the cause of the problem, you cancarry out general maintenance to eliminate some trivial causes of problems, suchas loose cables and bad connections.

Steps

1. Evaluate how serious the consequences of the problem are.

If the problem has very serious consequences, you may have to call forexpert help or apply an emergency plan immediately.

2. Identify the problem and describe it clearly.



23 (176)



Confidential

R: 23/176

Make an accurate description of the symptoms. You may not be able tosolve the problem yourself. A detailed description of the situation wherethe symptoms occurred can help an expert solve the problem. A symptomdescription should contain all the basic facts, such as:

. date, name of the person who detected the problem, phone number,e-mail

. details of the system; for example, what equipment and software isin use

For software, identify the software build in use and, if possible, theversions of the program blocks/processes that you suspect to befaulty.

For hardware, if you suspect that a plug-in unit is faulty, include theinterchangeability information of the hardware.

. What the symptoms are (alarms, error messages, clear codes, faultystates of the units and links, and so on).

. When the symptoms occurred for the first time. In which situationthe symptoms occurred (were some changes carried out prior to thesymptoms).

. Any other relevant information, for example, log writings, messagemonitorings. All data may be valuable; take the alarm history fromthe day the fault appeared and as much log writings and otherinformation as possible, even if they seem irrelevant at the time. Youshould store this information preferably in electronic format.

3. Study the symptoms of the problem.

Analyse and categorise symptoms and list possible causes for thesymptoms. Sometimes there can be several related or isolated problemsactive at the same time. Study whether the symptoms relate to each other ornot. Prioritise symptoms and collect further facts if needed.

4. Narrow down the possible causes of the problem.

Based on tests and your knowledge of the system, eliminate symptoms thatare not relevant to the problem you are trying to solve. This way you canfocus on symptoms and causes that are more likely to produce a solution tothe problem. Examine what works and what does not.

5. Carry out corrective actions.

If you have ended up with more than one probable and possible cause forthe problem, change only one thing at a time - otherwise you cannot besure what change corrected the failure or problem.

6. Make sure that the fault has been corrected.





Confidential

R: 24/176

4.2 Troubleshooting WCDMA RAN

Purpose

In WCDMA RAN both RNC and BTS attempt to keep all their units and networkconnections up and running to ensure the highest possible service level. Bothnetwork elements supervise Iub interface, handle network element's own alarmsand do required recovery actions if needed and when possible. In addition RNCalso collects alarms detected in BTS or in units that are under BTS supervision.

The recovery process in BTS hardware failure goes as follows:

1. BTS detects hardware fault.

2. BTS disables corresponding logical object and generates an alarm.

3. BTS sends disabling information and alarm to RNC.

4. RNC disables resources and marks object disabled in radio networkdatabase.

5. In case of hardware faults, recovery mechanism tries to minimise theeffects that the lost resource causes on the service load.

6. Update status information into RNC.

7. When the fault has been corrected, BTS takes the resources back into useand cancels the alarm.

Steps

1. Manage network faults.

a. Problems with overall unavailability of service are in some wayssimpler to repair because they would point to a particular part of thenetwork.

b. Problems in the performance of the network can be seen as thedegradation of service and problems can be verified by generatingstatistics and reports.

Further information

Examples of network faults are broken connections.

2. Manage configuration faults.

Since configuration faults are common and expected, troubleshooting canfocus on configuration faults.



25 (176)



Confidential

R: 25/176

Further information

Sometimes a configuration fault may not generate any alarms, andtherefore it is important to examine all information related to the faultsituation. Generally speaking, solving configuration faults requiresprofound knowledge of the interfaces involved.

Examples of configuration faults are wrongly configured configurationtables.

3. Manage software faults.

a. Narrow down the possible fault circumstances.

b. Establish the scenario needed to reproduce the fault.

c. Correct the fault.

Further information

Software faults are perhaps the most difficult ones to solve because it isusually assumed that the equipment is working. All other fault types mustbe ruled out before determining that a fault is software related. Generallyspeaking, software faults are corrected with change notes or changedeliveries from Nokia.

4. Manage hardware faults.

Problems with hardware are usually indicated by the alarms that arereceived from a network element.

If you suspect a hardware fault in the RNC, check that diagnostic testshave been run. If not, run the tests before proceeding with thetroubleshooting.

a. Track potential faulty units using diagnostic reports (in RNC), activealarm list or alarm history.

If RNC hardware is faulty, the unit goes into SE-OU (separated - outof use) state and has a FLTY flag indicating the fault. The unitgenerates alarms as well.

b. Change the faulty unit, if necessary.

c. Verify the correction by running a diagnostics test for the changedRNC unit.

5. Manage transport faults.





Confidential

R: 26/176

a. Check the status of synchronisation for every network element andtransport nodes. If there are configuration problems in thesynchronisation network, correct them first. If you still cannot getevery network element properly synchronised, concentrate on thisnetwork element and the element giving synchronisation to thisnetwork element. Improper synchronisation will cause transporterrors and other problems.

b. Determine which network element is generating the alarm. Theremay be several network elements that are generating alarms. Thefaulty connection can be determined with the help of alarms andtransmission topology information.

Transport faults can occur in all radio access network transport, thatis, in transport between

. BTS and BTS

In chain and loop transmission connections the AXC connectstwo BTSs with each other.

. BTS and RNC

AXC connects the BTS to the RNC.. RNC and RNC. RNC and 3G MSC. RNC and SGSN. RNC and Nokia NetAct Framework

c. Focus troubleshooting on the network element that is generating thealarms.

Analyse the problem using resolution databases and detailedtroubleshooting instructions from network element documentation.Alarm history can provide information that can be applied to aparticular fault situation and clarify if the problem is an existing oneor a newly discovered problem.

d. Examine pulse code modulation (PCM) statistics.

Determine whether there is a particular history surrounding thisparticular fault.

Further information

Transport faults are the most common type of faults in the network but theycan also mask the symptoms of other faults.

The RNC supervision detects when transport connections between RNCand BTS fail. In that case RNC disables the corresponding logical BTSresources.

For more information, see Nokia WCDMA transport.



27 (176)



Confidential

R: 27/176

Verification

Verify network performance by testing the correction, for example, in a testbed.

4.3 Tracing and correcting faults in WCDMA RAN

Purpose

The following performance management features can be used as tools fortroubleshooting WCDMA RAN:

. Threshold based PM notification triggering

. Subscriber trace

Threshold based PM notification triggering makes it easier to detect faults,identify bottlenecks and optimise the network. Using Element Manager GUI,appropriate performance thresholds are determined for each important variable sothat exceeding these thresholds indicates a problem worth of attention. Thesevariables can be either single counters or key performance indicators (KPIs)which are a combination of several counters. When performance data is gatheredon variables of interest from the measured objects in the network, their values arecompared against any active threshold limits. When a performance threshold isexceeded, an alarm is generated and sent to the network management system. Inaddition to this, a threshold event log is being saved in the network element forfurther study of the events which have occurred in that NE during a certain periodof time.

Subscriber trace allows operators to set a trace on a call using the IMSI number tospecify the mobile user. The feature collects useful data on the mobile subscriber.The data can include detailed radio interface data for a particular subscriber orradio link, and besides troubleshooting the trace data can also be used for legalinterception purposes and for network optimisation.

Subscriber trace is an efficient way to find spots in the cell where the powerrequirements are under or over specifications.

Summary

You can either use threshold based PM notification triggering or subscriber tracefor WCDMA RAN troubleshooting. Select the method that applies best for yoursituation.





Confidential

R: 28/176

Figure 1. Using threshold based PM notification triggering and subscribertrace in troubleshooting

Set trace

Trace datacollected

Analysetrace data

Isthere afault?

Identify&describeproblem

Evaluateconsequencesof the fault

Studysymptoms

Narrow downpossiblecauses

Correctproblem

yes

no

Setperformancethreshold

Datacomparedagainstthr. limits

Thresholdexceeded?

Alarmgenerated andsent to NetAct

Do yoususpecta fault?

yes

no

OK



29 (176)



Confidential

R: 29/176

Steps

1. Determine appropriate performance thresholds using ElementManager GUI.

Performance data is gathered and compared against any active thresholdlimits in the RNC.

If performance thresholds are exceeded, an alarm is generated and athreshold event log is saved. The alarm is sent to Nokia NetAct.

2. Analyse the event log.

Threshold based PM notification triggering can be used to predict possibleproblems in the network before they actually occur. The operator candefine threshold rules based on performance indicators that react toabnormal behaviour in the network in time. The threshold monitoringapplication sends an alarm and/or creates a log entry when a threshold rulehas been exceeded.

In case you find a fault, continue troubleshooting as instructed inTroubleshooting a radio access network.

If you use subscriber trace for troubleshooting:

3. Set a trace on subscriber or a mobile station.

The trace is activated in core network.

The subscriber is specified by the IMSI or MSISDN number in HLR, in thelocal MSC/VLR or in the 3G-SGSN depending on the network elementwhere the trace was set.

The mobile station is specified by its IMEI number in the local MSC/VLRor in the 3G-SGSN.

The trace data provided by the RNC is automatically transferred to NokiaNetAct for further processing. Trace data includes detailed informationfrom the traced subscriber's or equipment's radio interface.

4. Analyse trace data.

In case you find a fault, continue troubleshooting as instructed inTroubleshooting a radio access network.





Confidential

R: 30/176

5 Measuring WCDMA RAN

Measurements are used to identify normal network operation and also conditionsthat indicate configuration faults. The measurement results are input for networkplanning and optimisation tasks.

All measurements mentioned here are provided by Information Service. For moreinformation, see section List of active measurements in UTRAN InformationServices overview.

Check network integrity

Table 7. Checking network integrity


Check that parameters havebeen defined according toconsistency rules.

Inform network planning personnel about missingparameters, so that a new parameter plan can begenerated and activated.

Check that all essentialparameter information exists.

If not, inform planning personnel about missing parameterinformation.

Check operational states ofnetwork elements.

Modify parameters and check site again.

Check whether networkparameters are the same asthose defined by networkplanning.

Inform network planning personnel about missingparameters, so that a new parameter plan can begenerated and activated.



31 (176)

Measuring WCDMA RAN


Confidential

R: 31/176

Analyse network reports

Table 8. Analysing network reports


Check measurement results. Service Level Measurement (Radio Access Bearermeasuring), measurements for Radio ResourceUtilisation, (handover control, admission control, loadcontrol, and power control measuring), measurements forTransport Resource Reservations (Connection AdmissionControl measuring), measurements for connection quality(STM and IMA interface related measurements) andmeasurements (RRC, NBAP, RNSAP, and RANAPinterface related measurements) for external signalling.

View radio resources online. Online monitoring of radio resources (cell load, handovercontrol, and outer loop power control).

Measure quality of service

The referred RAN measurements are found in the UltraSite SW documentationset (HSDPA in BTS measurement) and RNC documentation (all othermeasurements).

Table 9. Measuring quality of service

Check Related RANKPIs

Related RANmeasurements

Parameters used inmeasurements

Check mark

ServiceAccessibility

Accessibility KPIsfor RAN1.5

Accessibility KPIsfor RAN04

Accessibility KPIsfor RAS05

Check Servicelevelmeasurement.

Relations to radio accessbearer parameters (seePlanning parameters forradio network)

ServiceRetainability

Retainability KPIsfor RAN1.5

Retainability KPIsfor RAN04

Retainability KPIsfor RAS05

Check Servicelevelmeasurement.

Relations to radio accessbearer parameters(seePlanning parametersfor radio network)





Confidential

R: 32/176

Table 9. Measuring quality of service (cont.)




Check mark

NetworkAvailability

Usage KPIs forRAN1.5

Usage KPIs forRAN04

Usage KPIs forRAS05

Check CellResourceMeasurement.

Check UnitAvailabilityMeasurement.

Relations to RANparameters

Network Load Usage KPIs forRAN1.5

Usage KPIs forRAN04

Usage KPIs forRAS05


Check DSPperfomance inRNS and Unit Loadmeasurements.

Check HSDPA inWBTSmeasurement.

Relations to load controland admission controlparameters, Planningparameters for radionetwork

Relations to ATM layerparameters

Network AllocatedResources


Usage KPIs forRAN04

Usage KPIs forRAS05

Check Trafficmeasurement.

Check AAL2signalling at UNIprotocol and AAL2signalling at NNImeasurements.

Check ServiceLevelmeasurement.

Check AAL2resourcereservationmeasurement.

Relations to admissioncontrol parameters,Planning parameters forradio network

Relations to AAL layerparameters,Interdependencies ofperfomance managementfeatures



33 (176)

Measuring WCDMA RAN


Confidential

R: 33/176





Check mark

NetworkThroughput


Usage KPIs forRAN04

Usage KPIs forRAS05


Check RadioConnectionPerformance forRLC AM.

Check ATM VP/VCconnectionmeasurements.

Check HSDPA inWBTSMeasurement.


Mobility Mobility KPIs forRAN1.5

Mobility KPIs forRAN04

Check SoftHandover, IntraSystem HardHandover and IntraSystem HardHandoverMeasurements.

Relations to Handovercontrol parameters,Planning parameters forradio network

Integrity Integrity KPIs Check the qualityof L1 transmissionconnections; STMand IMA interfacerelatedmeasurements.

Check RadioConnectionPerformance forRLC AMMeasurement.

Check HSDPA inWBTSMeasurement.

Relations to TransmissionInterfaces Transporttechnologies

External signalling Check the RRC,NBAP, RNSAP,and RANAPinterface relatedmeasurements.

Relations to RANInterfaces, see Reference/Interfaces





Confidential

R: 34/176





Check mark

Online: Cell Load Check Cell LoadMonitoring Type.


Online: Handover Check HandoverMonitoring Type.

Relations to Handovercontrol parameters,Planning parameters forradio network

Online: OuterLoop PowerControl

Check Outer LoopPower ControlMonitoring Type.

Relations to admissioncontrol parameters,Planning parameters forradio network

For more information on parameters, please refer to RAN Parameter dictionary.



35 (176)

Measuring WCDMA RAN


Confidential

R: 35/176





Confidential

R: 36/176

6 Maintaining WCDMA RAN

6.1 Checklist for proactive maintenance

In proactive maintenance, possible network faults are actively sought andrevealed to ensure the future network quality and performance criteria.

Using the RAN04 performance management features subscriber trace andthreshold based PM notification triggering can give useful information forproactive maintenance.

Use the standard procedures to collect data and analyse trends.


Monitor radio network. Monitor

Produce key performanceindicator (KPI) trends.

See Key performance indicators

Analyse KPI trends. Look for possible network faults.

Analyse and escalate suspectedproblems.

Fill out a check list or a log book and use it as a referenceto verify whether the maintenance tasks are beingperformed too frequently or not frequently enough.

Perform a visual inspectionwhenever visiting the site forpreventive maintenance.

6.2 Checklist for daily maintenance routines



37 (176)

Maintaining WCDMA RAN


Confidential

R: 37/176


Check alarms. Display active and blocked alarms.

Check performance indicators.

Check radio network status.

Check I/O-devices' status.

Check signalling links.

Check circuit groups.

Backup files into a fallbackpackage and make a copy of thefallback package.

Taking backup copies ensures that you have a functionalcopy of the software that you can use in case of problemswith the software.

Follow backup management process.

6.3 Checklist for weekly maintenance routines


Monitor signalling, for exampleamount of traffic, trafficdistribution and failure situations.

Check performance indicators.

Check the working states. Make necessary changes.

Print and save the working statesof computer units.

The status of the radio network can be checked with RNCObject Browser.

Check blocked alarms, alarmobjects and alarm indicationinstances.

Remove blocking if it is no longer needed.

Monitor use of memory. The amount of memory needed for short periodallocations, such as timers and messages, depends ontraffic and load. Long period memory usage can bemeasured by creating a memory usage measurement.





Confidential

R: 38/176


Check that time is correct. Adjust time if necessary.

If the time needs adjustment, report and open the troubleticket.

Monitor load sharing of IProuters.

Adjust load sharing if necessary.

Check computer unit logs. Analyse reason if the same problem is reported regularly.

6.4 Checklist for biannual maintenance routines


Set daylight saving time. Note that time adjustments may affect charging andperformance measurement.

Check that the antenna lights ofthe base station are working.

If the light is broken, report and open trouble ticket. Thistype of fault always requires planned work. Maybe thewhole site must be shut down while working on the top ofthe tower or mast.

Check that the door alarmsystem is working.

Report and open trouble ticket. One of the wired alarms.Door alarm is a wired alarm.

Check that fire sensors areworking.

Replace fire sensors or their batteries if necessary. Followmanufacturer's instructions. Report and open troubleticket. One of the wired alarms. Fire alarm is a wiredalarm.

Check the batteries and powerbackup system

Replace batteries, if necessary. Follow manufacturer'sinstructions. Report and open trouble ticket.

In case of a shelter site, check airconditioning.

Repair air conditioning, if necessary. Followmanufacturer's instructions. Report and open troubleticket. Escalate problem to 3rd party or its representative.Requires planned work.

Check that wired alarms areconnected.

If the alarms are not working, report and open troubleticket.

Check the generator tank of thebase station or RNC.

Fill the tank, if necessary.

Perform a visual inspectionwhenever you visit the site.

Repair all faults that you notice.



39 (176)

Maintaining WCDMA RAN


Confidential

R: 39/176


Test external equipment (notsupplied by Nokia).

Follow manufacturer's instructions.





Confidential

R: 40/176

7 Monitoring use cases

7.1 Use cases

7.1.1 Use cases for monitoring services

The services to be monitored are:

. radio resource control (RRC)

. radio access bearer (RAB)

. radio bearer (RB)

The RRC is described in the Uu interface.

The RAB and RB are described in Radio access network in the 3G system.

The resources related to the use cases are found in UTRAN Resource Modeloverview.

7.1.2 Use cases for monitoring resource availability

The resources to be monitored are:

. transport channels (CCH, DCH, HS-DSCH)

. IMA group

. SDH path

. AAL2 path (non-HSDPA, HSDPA)




41 (176)

Monitoring use cases


Confidential

R: 41/176

7.1.3 Use cases for throughput and load monitoring


. WCELL

. radio bearer (non-HSDPA, HSDPA)

. interface (ATM VCC for Iu-PS


7.1.4 Use cases for mobility


. WCELL


7.1.5 Use cases for quality


. transport channel (DCH, HS-DSCH)

. IMA group

. ATM VCC (C-NBAP, D-NBAP)






Confidential

R: 42/176

7.2 Service set-up monitoring use cases

7.2.1 RRC connection set-up monitoring

Purpose

The RRC connection set-up procedure is used by user equipment (UE) foraccessing the RAN. The service access point is the WCELL in RAN. For moreinformation, see UTRAN Resource Model overview.

Information Service related to the use case is found in Defined UTRANinformation services.

The impact of not having a connection to RAN means that no services can beasked by a UE from RAN.

The use case is executed on the RNC level. It is usually executed at regularmaintenance intervals, but it can also be used during roll-out.

Before you start

Table 10. Network element software requirements

Network element Release

RNC RN1.5

BTS n/a

AXC n/a

NetAct OSS3.2

SGSN n/a

MSC n/a

MGW n/a

UE n/a

Related network performance parameters, statistics and alarms:

The performance statistics should be available for at least a 24-hour period (oneweek recommended) for the following measurements:



43 (176)



Confidential

R: 43/176

. Service Level

Table 11. Related counters and KPIs

Related counters/KPIs

Recommended values Monitoring interval

RAN_KPI_0005 See Targets for WCDMARAN key performanceindicators

60 min, daily busy hour

Relevant failure countersthat are listed in theinstructions

Should not be updated inan ideal case


The alarm 7771 WCDMA CELL OUT OF USE must not be active.

Summary

Table 12. Use case information

ID RAN_USE_CASE_MON_1

Use case name RRC Connection Release Monitoring

RAN releases All RAN releases

Actors Network planner, operation engineer

Summary The RRC connection (normal) releasesuccess is monitored and verified withperformance statistics reports on a dailybasis. It can also be monitored in real timein a limited part of the network.

Reasons to perform the use case . Regular monitoring. problems with RAN_KPI_0005 values

Triggers for utilised service/resourceinformation

/TS 25.331/ and /TS 25.413/

Limitations and restrictions The required counters are currently notavailable in real time measurements.





Confidential

R: 44/176

Table 12. Use case information (cont.)

Preconditions . The UTRAN cell state must bechecked.

. The report information service mustbe available.

. The Service Level measurement mustbe activated.

Postconditions The RRC set-up rate is verified. Thetarget level is found in Targets forWCDMA RAN key performanceindicators.

If the target level is not fulfilled, theresource utilisation situation in the RNCand BTS most be checked.

Steps

1. Before executing the use case, check that the service access point isavailable.

If the service access point is not available, go to Troubleshooting UseCases -> End of the Service Monitoring Use Case.

2. Check that there are no active alarms.

If there are active alarms, go to Troubleshooting Use Cases -> End of theService Monitoring Use Case.

If everything is correct, collect the performance statistics from the ServiceLevel measurement in RNC for at least a one-hour period, and continue tothe next step.

3. Evaluate the statistics.

The recommended KPI value is found in Targets for WCDMA RAN keyperformance indicators.

If the values are correct, the use case is complete.

If the KPIs show the drop ratio is too high, continue to the next step.

4. If the drop rate is too high, check the following counters in the ServiceLevel measurement indicating possible reasons for the rejected set-ups.



45 (176)



Confidential

R: 45/176

. · M1001C16

RRC ACTIVE FAIL DUE TO RADIO INTERFACE

The counter indicates that the air interface is causing drops, go tostep 4.

. · M1001C17,C21

RRC ACTIVE FAIL DUE TO BTS REASONS, RRC ACTIVEFAIL DUE TO RNC INTER REASONS

The counters indicate that there are problems in resources thatcauses drops. Go to step 5.

. · M1001C15,C18

RRC ACTIVE FAIL DUE TO IU INT, RRC ACTIVE FAIL DUETO THE IUR INT

The counters indicate that there are problems related to interfacesthat causes drops. Go to step 6.

5. Check if the drop rate is too low because of the radio interface.

If the drop rate is too low because of the radio interface, there can besynchronisation problems in the network.

Check the L3 Signalling Measurement counters:

. M1005C68 and/or M1005C74

RL DEL ON SRNC DUE TO ACT RL SYN FAIL, RL DEL ONDRNC DUE TO ACT RL SYN FAIL

The counter indicates that the RL is deleted due to synchronisationloss.

If there are no active synchronisation losses then go the troubleshootingUse Cases -> End of the Service Monitoring Use Case.

6. Check if the drop rate is high because of resource problems.

If the drop rate is high because of resource problems, there can be ahardware overload or other equipment problems.

Check the L3 Signalling Measurement at Iub counters:

. M1005C69, C70 and/or M1005C75, C76

RL DEL ON SRNC DUE TO BTS HW OVERL, RL DEL ONSRNC DUE TO BTS EQUIP FAIL, RL DEL ON DRNC DUE TOBTS HW OVERL, RL DEL ON DRNC DUE TO BTS EQUIPFAIL





Confidential

R: 46/176

The counters indicate that RL is deleted because of resourceproblems.

If there are no RL deletions because of resource problems, go thetroubleshooting Use Cases -> End of the Service Monitoring Use Case.

7. Check if the drop rate is high because of interface problems.

If the drop rate is high because of interface problems, there can be CN-indicated problems.

Check the L3 Signaling Measurement at Iu counters:

. M1003C04, C5, C6, C7

SIGN CONN REL REQ DUE TO TR LAYER CAUSE, SIGNCONN REL REQ DUE TO NAS CAUSE, SIGN CONN REL REQDUE TO PROT CAUSE, SIGN CONN REL REQ DUE TO MISCCAUSE, SIGN CONN REL REQ DUE TO NON STAN CAUSE

The counters indicate that the Iu connection is released due to a CN-indicated cause.

If there are no signaling connection releases because of CN-indicatedproblems, go the troubleshooting Use Cases -> End of the ServiceMonitoring Use Case.

Expected outcome

The use case is complete.



47 (176)



Confidential

R: 47/176

Further information

Figure 2. RRC connection set-up monitoring

Activatereporting

Serviceif needed

Check that the ServiceAccess Point and thereporting serviceneeded are available.Check the alarmsituation.

Too high airinterface loadGo to LoadMonitoring UseCases

RRC setup successrate for the ServiceAccess Point

What are thecauses for RRCrejection (checkdetailed counters)

If OK,collectstatistics

1.

2.3. 4.

Go to TroubleshootingUse Cases

Use Case complete!


Resouce Monitoring Use CasesIf resource situation undercontrol, start troubleshooting

Load Monitoring Use CasesIf load is reasonable limits,start troubleshooting

Check that no alarms forrelated resources are active.If not, start troubleshooting

Check that parameter isaccording to default.If not, start troubleshooting

AdmissionControlFailure

No

ServiceAccessPointOut of use

RelatedActiveAlarmsFound

7.


Troubleshootingneeded

Yes

BTS FailureTransmissionFailureRNC internalFailure

SynchronizationFailureFailure due to UE


6.

5.





Confidential

R: 48/176

7.2.2 RAB set-up monitoring

Purpose

The RAB assignment procedure is used by CN for accessing the RAN servicesand to set-up a radio access bearer service between the user equipment (UE) andthe Service Domain (CN). The impact of not getting a RAB means that noservices can be given to the UE by the network.

The AMR service is selected. The service access point (WCELL) must beavailable. For more information, see UTRAN Resource Model overview.



Before you start



RNC RN1.5

BTS n/a

AXC n/a

NetAct OSS3.2

SGSN n/a

MSC n/a

MGW n/a

UE n/a


The are no distinguished parameters for this use case.



49 (176)



Confidential

R: 49/176


. Service Level






Relevant failure countersthat are listed in theinstructions.



The alarm 7771 WCDMA CELL OUT OF USE must not be active

Summary



Use case name RAB AMR Setup monitoring


Summary The RAB AMR set-up success ismonitored and verified with performancestatistics reports on a daily basis. It canalso be monitored in real time in a limitedpart of the network.



The RAB Assignment Request and RABAssignment Complete messages.

Limitations and restrictions The required counters are currently notavailable in real time measurements. Ifthe RNC is in overload, the use casecannot be performed.





Confidential

R: 50/176





Postconditions The RAB AMR set-up rate is verified. Thetarget level is found in Targets forWCDMA RAN key performanceindicators.


Steps

1. Before executing the use case, check that there are no active alarms.


If there are no active alarms, collect the performance statistics from theService Level measurement in RNC for at least a one-hour period, andcontinue to step 2.



If the values are OK, the use case is complete.

If the KPIs show too high a rejection ratio, continue to step 3.

3. In case of too high a rejection ratio, check the following counters in theService Level measurement indicating the possible reasons for rejectedset-ups.

. · M1001C80

RAB VOICE SETUP FAIL DUE TO AC

The counter indicates that the air interface load is to high. Go to step4.



51 (176)



Confidential

R: 51/176

. · M1001C81,C82,C83, C531, C535,C535

RAB SETUP FAIL DUE TO BTS REASONS, RAB SETUP FAILDUE TO TRANS, RAB SETUP FAIL DUE TO RNC INTERREASONS, RAB SETUP FAIL DUE TO IUB AAL2 TRANS,RAB SETUP FAIL DUE TO IUR AAL2 TRANS, RAB SETUPFAIL DUE TO IU CS AAL2 TRANS

The counters indicate that there are problems in resource accessing.Go to step 5.

. · M1001C122

RAB ACC FAIL DUE TO UU INT

The counter indicates problems in the air interface. Go to step 6.

4. Check if the set-up success rate is too low because of high air interfaceload.

If the set-up success rate is too low because of high air interface load, gothe Load Monitoring Use Cases -> End of the Service Monitoring UseCase.

5. Check if the set-up success rate is too low because of resourceutilisation problems.

If the set-up success rate is too low because of resource utilisationproblems, go to Resource Monitoring Use Cases -> End of the ServiceMonitoring Use Case.

6. Check if the set-up success rate is too low because of air interfaceproblems.

If the set-up success rate is too low because of air interface problems, firstcheck if there are known problems with UEs. Go to step 7.

7. Check if there are known problems with UEs.

If there are known problems with UEs, go to step 2.

If there are no known problems with UEs, go to troubleshooting Use Cases-> End of the Service Monitoring Use Case.

Expected outcome






Confidential

R: 52/176

Further information

Figure 3. RAB set-up monitoring

Activatereporting

Serviceif needed

Check that thereporting serviceneeded is available.Check the alarmsituation.

Too high airinterface loadGo to LoadMonitoring UseCases

RAB AMR setupSuccess rate

What are thecauses for RABrejection (checkdetailed counters)


1.

2.3.

4.


Use Case complete!




Check if there are knownUE problems.If not, start troubleshooting

AdmissionControlFailure

No



8.



Yes


Failure due to UE


6.

5.

7.

Check that no alarms forrelated resources are active.If not, go to ResourceMonitoring

Known UEproblem



53 (176)



Confidential

R: 53/176

7.2.3 HS-DSCH set-up monitoring

Purpose

The RAB assignment procedure is used by CN for accessing the RAN servicesand to set up a radio access bearer service between the user equipment (UE) andthe service domain (CN).

If an RAB is not obtained, then no services can be received by the UE from thenetwork. For HSDPA, an interactive or background RAB is first set up, butwithout any traffic carrying capabilities. Therefore, a transport channel must alsobe used. For HSDPA, the transport channel is HS-DSCH. For more information,see UTRAN Resource Model overview and UTRAN Information Service Modeloverview.



Before you start



RNC RN2.1

BTS n/a

AXC n/a

NetAct OSS4.2

SGSN n/a

MSC n/a

MGW n/a

UE n/a


The parameter HSDPA enabled must have the value 1.





Confidential

R: 54/176


. Traffic









The alarms 7771 WCDMA CELL OUT OF USE and 7776 HSDPA FAILURE INWCEL must not be active.

Summary



Use case name HS-DSCH Setup monitoring


Summary The HS-DSCH set-up success ismonitored and verified with performancestatistics reports on a daily basis. It canalso be monitored in real time in a limitedpart of the network.

Reasons to perform the use case . Regular monitoring. Problems with RAN_KPI_0038 values


UE capacity request or MAC-d capacityrequest

Limitations and restrictions The required counters are currently notavailable in real time measurements. Ifthe RNC is in overload, the use case cannot be performed.



55 (176)



Confidential

R: 55/176



. Report information service must beavailable.

. Traffic Measurement must beactivated.

Postconditions The HS-DSCH set-up rate is verified. Thetarget level is found in Targets forWCDMA RAN key performanceindicators.


Steps



If there are no active alarms, collect the performance statistics from ServiceLevel measurement in RNC for at least a one-hour period, and continue tostep 2.




If the KPIs show too high a rejection ratio, continue to step 3.

3. In the case the of too high a rejection ratio, check the followingcounters in Traffic measurement indicating possible reasons for therejected set-ups.

. · M1001C475, C476

DCH SELECTED FOR INTERACTIVE DUE TO MAX HSDPAUSERS, DCH SELECTED FOR BACKGROUND DUE TO MAXHSDPA USERS





Confidential

R: 56/176

These counters indicate that there are too many users trying toaccess HSDPA. Go to step 4.

. · M1001C416, C417, C418,C419,C420,C424, C425, C426,C427,C428

HS-DSCH SETUP FAILURE DUE TO BTS FOR INTERACTIVE,HS-DSCH SETUP FAILURE DUE TO BTS FORBACKGROUND, HS-DSCH TOTAL IUB TRANSPORT SETUPFAIL FOR INTERACTIVE, HS-DSCH TOTAL IUB TRANSPORTSETUP FAIL FOR BACKGROUND HS-DSCH 64/128/384 KBPSRETURN CH IUB TRANSPORT SETUP FAILURE FORINTERACTIVE, HS-DSCH 64/128/384 KBPS RETURN CH IUBTRANSPORT SETUP FAILURE FOR BACKGROUND

These counters indicate that there are problems in resourceaccessing. Go to step 5.

. · M1001C415, C423

HS-DSCH SETUP FAILURE DUE TO UE FOR INTERACTIVE,HS-DSCH SETUP FAILURE DUE TO UE FOR BACKGROUND

These counters indicate problems in the air interface. Go to step 6.

4. Check the set-up success rate and whether the air interface load is toohigh.

If the set-up success rate is too low because of high air interface load, gothe Load Monitoring Use Cases -> End of the Service Monitoring UseCase.

5. Check if the set-up success rate is too low because of resourceutilisation problems.

If the set-up success rate is too low because of resource utilisationproblems, go to Resource Monitoring Use Cases -> End of the ServiceMonitoring Use Case.

6. Check the set-up success rate and check whether there are problemswith the air interface.

If the set-up success rate is too low because of air interface problems, firstcheck if there are known problems with UEs. Go to step 7.

7. Check if there are known problems with UEs.

If there are known problems with the UEs, go to step 2.

If there are no known problems with the UEs, go to troubleshooting UseCases -> End of the Service Monitoring Use Case.



57 (176)



Confidential

R: 57/176

Expected outcome


Further information

Figure 4. HS-DSCH set-up monitoring

Activatereporting

Serviceif needed


Too manyHSDPA usersServiceAccess Point

HS-DSCH setupSuccess rate


1.

2.3.

4.


Use Case complete!




Check if there are knownUE problems.If not, start troubleshooting

DCH selectedinstead ofHS-DSCH

No



8.



Yes


Failure due to UE


6.

5.

7.

Check that no alarms forrelated resources are active.If not, go to ResourceMonitoring

Known UEproblem

What are thecauses forHS-DSCHrejection (checkdetailed counters)





Confidential

R: 58/176

7.3 Service release monitoring use cases

7.3.1 RRC connection release monitoring

Purpose

The RRC connection release procedure is used to release a user equipment (UE)connection to RAN. The release in done through the current service access pointfor the UE, that is, a WCELL RAN. For more information, see UTRAN ResourceModel overview.


The purpose of this use case is to see the proportion of wanted (normal) RRCconnection releases compared to abnormal releases.

The use case is usually executed at regular maintenance intervals, but it can alsobe used during roll-out.

Before you start



RNC RN1.5

BTS n/a

AXC n/a

NetAct OSS3.2

SGSN n/a

MSC n/a

MGW n/a

UE n/a


No parameters are involved in this use case.



59 (176)



Confidential

R: 59/176

The performance statistics should be available for at least for a 24-hour period(one week recommended) for the following measurements:

. Service Level






Relevant failure countersthat are listed in theinstructions




Summary



Use case name RRC Connection Release Monitoring


Actors Network planner, operation engineer

Summary The RRC connection (normal) releasesuccess is monitored and verified withperformance statistics reports on a dailybasis. It can also be monitored in real timein a limited part of the network.



/TS 25.331/ and /TS 25.413/






Confidential

R: 60/176





Postconditions The RRC set-up rate is verified. Thetarget level is found in Targets forWCDMA RAN key performanceindicators.

If the target level is not fulfilled, theresource utilisation situation in the RNCand BTS must be checked.

Steps



2. Check that there are no active alarms.


If everything is correct, collect the performance statistics from the servicelevel measurement in RNC for at least a one-hour period, and continue tostep 3.




If the KPIs show too high a drop ratio, continue to step 4.

4. If the drop rate is too high, check the following counters in ServiceLevel measurement indicating possible reasons for the rejected set-ups.



61 (176)



Confidential

R: 61/176

. · M1001C16

RRC ACTIVE FAIL DUE TO RADIO INTERFACE

The counter indicates that the air interface is causing drops. Go tostep 4.

. · M1001C17,C21

RRC ACTIVE FAIL DUE TO BTS REASONS, RRC ACTIVEFAIL DUE TO RNC INTER REASONS

The counters indicate that there are problems in resources thatcauses drops. Go to step 5.

. · M1001C15,C18

RRC ACTIVE FAIL DUE TO IU INT, RRC ACTIVE FAIL DUETO THE IUR INT

The counters indicate that there are problems related to interfacesthat causes drops. Go to step 6.



Check the L3 Signaling Measurement counters:

. M1005C68 and/or M1005C74


The counters indicate that the RL is deleted due to synchronisationloss.

If there are no active synchronisation losses, go to troubleshooting UseCases -> End of the Service Monitoring Use Case.

6. Check if the drop rate is high because of resource problems.


Check the L3 Signaling Measurement at Iub counters:

. M1005C69, C70 and/or M1005C75, C76






Confidential

R: 62/176

The counters indicate that the RL is deleted due to resourceproblems.



If the drop rate is high due to interface problems, there can be CN-indicated problems.

Check the L3 Signaling Measurement at Iu counters:

. M1003C04, C5, C6, C7


The counters indicate that the Iu connections released due to a CN-indicated cause.

If there are no signaling connection releases due to CN-indicated problems,go the troubleshooting Use Cases -> End of the Service Monitoring UseCase.

Expected outcome




63 (176)



Confidential

R: 63/176

Further information

Figure 5. RRC connection release monitoring

Activatereporting

Serviceif needed


Check the L3Signaling at Iubcounters. If notupdated go StartTroubleshooting

RRC droprate for the ServiceAccess Point

What are thecauses for RRCdrop (checkdetailed counters)


1.

2.3. 4.


Use Case complete!



Check the L3 Signaling atIu countersIf not updated go toStart Troubleshooting

Failure dueto radiointerface

No



7.


Yes

BTS FailureRNC internalFailure

Failure due to IuFailure due to Iur

6.

5.

Check the L3 Signaling atIub countersIf not updated go toResource Monitoring Troubleshooting

needed

Iub Counterupdates


Iub Counterupdates






Confidential

R: 64/176

7.3.2 RAB AMR release monitoring

Purpose

The RAB assignment procedure is used by CN for releasing the accessed RANservices. The release in done through the service access points, that is, WCELLs.For more information, see UTRAN Resource Model overview.

The Information Service related to the use case is found in Defined UTRANinformation services.

The purpose of this use case is to see the proportion of wanted (normal) RABrelases compared to abnormal releases.

The use case is executed on the RNC-level and is usually exceuted at regularmaintenance intervals but can also be used at roll-out.

The AMR service is selected.

Before you start



RNC RN1.5

BTS n/a

AXC n/a

NetAct OSS3.2

SGSN n/a

MSC n/a

MGW n/a

UE n/a


There are no parameters involved in this use case.



65 (176)



Confidential

R: 65/176


. Service Level

. L3 Signaling Measurement at Iub

. L3 Signaling Measurement at Iu










Summary



Use case name RAB (AMR) Connection ReleaseMonitoring

RAN Releases All RAN releases

Actor(s) Network planner, operation engineer

Summary The RAB (normal) release success ismonitored and verified with performancestatistics reports on a daily basis and canalso be done in real time for a limited partof the network.






Confidential

R: 66/176


Triggers for utilized service / resourceinformation

-

Limitations and restrictions The needed counters are currentlyavailable only in non-real timemeasurements.




Postconditions The RAB release rate is verified. Thetarget level is found in WCDMA RAN KeyPerformance Indicators.


Steps



2. Check that there are no active alarms


If there are no active alarms, collect the performance statistics from theService Level measurement in the RNC for at least a one-hour period, andcontinue to step 2.



If the values are OK, continue to step 8.



67 (176)



Confidential

R: 67/176

If the KPIs show too high a drop ratio, continue to step 3.

4. In the case off to high drop rate, check the following counters in theService Level measurement indicating the possible reasons for therejected set-ups.

. M1001C146

RAB ACTIVE FAILURES DUE TO RADIO INT FOR CS VOICE

This counter indicates that the air interface is causing drops. Go tostep 4.

. M1001C147,C150

RAB ACTIVE FAILURES DUE TO BTS FOR CS VOICE, RABACTIVE FAILURES DUE TO RNC FOR CS VOICE

These counters indicate that there are problems in resources thatcauses drops. Go to step 5.

. M1001C145,C148

RAB ACTIVE FAILURES DUE TO IU FOR CS VOICE, RABACTIVE FAILURES DUE TO IUR FOR CS VOICE

These counters indicate that there are problems related to interfacesthat causes drops. Go to step 6.



Check the following L3 Signaling Measurement in Iub counters:

. M1005C68 and/or M1005C74


The counters indicate that RL is deleted due to synchonisation loss.

If there are no active synchronisation losses, go the troubleshooting UseCases -> End of the Service Monitoring Use Case.

6. Check if the frop rate is high because of resource problems.


Check the following L3 Signaling Measurement in Iub counters:

. M1005C69, C70 and/or M1005C75, C76





Confidential

R: 68/176


The counters indicate that RL is deleted due to resource problems.



If the drop rate is high because of interface problems, there can be CN-indicated problems.

Check the followingL3 Signaling Measurement in Iu counters:

. M1003C04, C5, C6,C7


These counters indicate that the Iu connection is released due to aCN-indicated cause.

If there are no signaling connection releases caused by CN-indicatedproblems, go to troubleshooting Use Cases -> End of the ServiceMonitoring Use Case.

Expected outcome




69 (176)



Confidential

R: 69/176

Further information

Figure 6. RAB AMR release monitoring

Activatereporting

Serviceif needed


Check the L3Signaling at Iubcounters. If notupdated go StartTroubleshooting

RAB AMR droprate for the ServiceAccess Point

What are thecauses for RABAMR drop (checkdetailed counters)


1.

2.3. 4.


Use Case complete!



Check the L3 Signaling atIu countersIf not updated go toStart Troubleshooting

Failure dueto radiointerface

No



7.

Yes

BTS FailureRNC internalFailure

Failure due to IuFailure due to Iur

6.

5.

Check the L3 Signaling atIub countersIf not updated go toResource Monitoring Troubleshooting

needed

Iub Counterupdates


Iub Counterupdates






Confidential

R: 70/176

7.3.3 HSDPA (HS-DSCH) availability monitoring

The radio bearer reconfiguration procedure is used by the RNC for allocating auser equipment (UE) to the shared channel (HS-DCH). For more information, seeUTRAN Resource Model overview.


If the HS-DSCH is not allocated, then no traffic capabilities can be given for a UEthat is requesting the capacity or is the subject of the request.

This use case is considered to be equal to HS-DSCH set-up monitoring. Forinstructions, see HS-DSCH set-up monitoring.

7.4 Logical resource availability monitoring use cases

7.4.1 Common channel (CCH) availability monitoring

Purpose

The common channels are used for delivering messages and data. The commonchannels defined for this use case are RACH, FACH and PCH. For moreinformation on common channels, see UTRAN Resource Model overview.


If a common channel is not available in RAN, it means that user equipment (UE)cannot be set up (PCH channel), RRC connections cannot be set up (RACH andFACH) and/or no data can be delivered using the common channels (RACH andFACH).




71 (176)



Confidential

R: 71/176

Before you start



RNC RN1.5

BTS n/a

AXC n/a

NetAct OSS3.2

SGSN n/a

MSC n/a

MGW n/a

UE n/a


There are no adjustable parameters related to this use case. The related CCHmeasurement reporting period is 2000 ms.


. Cell Resource




M1000C55 Should equal the numberof CCH reports during themonitoring interval








Confidential

R: 72/176

Table 26. Related counters and KPIs (cont.)





Summary



Use case name Common channel (CCH) availabilitymonitoring


Actor(s) Network planner, operation engineer

Summary The CCH availability is monitored andverified with performance statisticsreports on a daily basis. It can also bemonitored in real time in a limited part ofthe network.

Reasons to perform the use case . Regular monitoring. Problems with paging delivery. RAN_KPI_0001A problems


CCH measurement




. Cell Resource measurement must beactivated.

Postconditions The CCH availability is verified.

Steps



73 (176)



Confidential

R: 73/176

1. Before starting the use case, check that the service access point isavailable.

If the service access point is not available, go to Troubleshooting UseCases -> End of the Monitoring Use Case.

Check that there are no active alarms. If there are active alarms, go toTroubleshooting Use Cases -> End of the Monitoring Use Case.

If all of the above mentioned are OK, collect the performance statisticsfrom Cell Resource measurement in RNC, for at least a one-hour period,and continue to step 2.


The RACH channel availability can be seen by counter M1000C55(RACH DENOM 0)

The FACH channel availability can be seen by counter M1000C65(SCCPCH LOAD DENOM 0)

The PCH channel availability can be seen by counter M1000C71 (PCHTHROUGHPUT DENOM 0)

The values of each counter should equal 180 (360000 ms/2000 ms). If thisis true, continue to step 6.

If the any of the counters shows lower values than expected, continue tostep 3.

3. In the case of found unavailability of Common Channels, check thestatus of each channel through MML.

If the statuses are OK, go to troubleshooting Use Cases -> End of theService Monitoring Use Case.

Expected outcome

Use case is complete.





Confidential

R: 74/176

Further information

Figure 7. CCH availability monitoring

Activatereporting

Serviceif needed


M1000C55M1000C65M100071


1.

2.3.


Use Case complete!

No



5.

Valuesequal180

4.

Check the statusof the CCH

OPEN

Status NOK

Status OK



75 (176)



Confidential

R: 75/176

7.4.2 Dedicated channel (DCH) availability monitoring

Purpose

The radio bearer set-up or reconfiguration procedures are used by the RNC forsetting up or modifying a dedicated channel (DCH). For more information, seeUTRAN Resource Model overview.


If there is no DCH, then no traffic capabilities can be given for a user equipment(UE) that is requesting the capacity or is the subject of the request.

The use case is different for RT and NRT services. For RT services, the radiobearer set-up procedure is used, meaning that the DCH is allocated at the RABset-up, and for the RT part the RAB set-up monitoring use case is used. For theNRT part the radio bearer reconfiguration procedure is used to allocate the DCH,which means that the RAB related KPIs cannot be utilised.

The use case is executed on the RNC-level. It is usually executed at regularmaintenance intervals, but it can also be used during roll-out.

Before you start



RNC RN2.0

BTS n/a

AXC n/a

NetAct OSS4

SGSN n/a

MSC n/a

MGW n/a

UE n/a






Confidential

R: 76/176

The are no distinguished parameters for this use case.

The performance statistics should be available for at least a 24-hour period (oneweek recommended) for following measurements:

. Traffic

. L3 Signaling at Iub

. Service Level










M1002C92, C93 Should not be updated inan ideal case.


M1001C106, C111 Should not be updated inan ideal case.



Summary



Use case name DCH availability monitoring




77 (176)



Confidential

R: 77/176


Summary The DCH availability is monitored andverified with performance statisticsreports on a daily basis. It can also bemonitored in real time in a limited part ofthe network.

Reasons to perform the use case . Regular monitoring. Problems with RAN_KPI_0001-0002values


The radio bearer set-up and radio bearerreconfiguration messages


If the RNC is in overload, the use casecannot be performed.



. Traffic Measurement must beactivated.

Postconditions The DCH availability is verified.

Steps



If there are no active alarms, collect the performance statistics from theService Level measurement in the RNC for at least a one-hour period andcontinue to step 2.


For RT-related DCH allocations, go to RAB Setup Monitoring Use Case.

For NRT, check the following counters:





Confidential

R: 78/176

. M1002C92, C93

NRT DCH REQ FOR PS CALL INTERA CLASS REJECT IN ULIN SRNC, NRT DCH REQ FOR PS CALL BACKG CLASSREJECT IN UL IN SRNC

These counters indicate that there are problems in resources at theradio layer. Go to step 3.

. M1001C106, C111

DCH SETUP FAILURES DUE TO IUB AAL2 TRANS FOR PSDATA INTERA , DCH SETUP FAILURES DUE TO IUB AAL2TRANS FOR PS DATA BACKG

These counters indicate that there are problems in resources at theAAL2 layer. Go to step 4.

3. Check if the set-up success rate is too low because of a high airinterface load.

Go the Load Monitoring Use Cases -> End of the Service Monitoring UseCase.

4. Check if the set-up success rate is too low because of blocking at theIub.

Go the Blocking Monitoring Use Cases -> End of the Service MonitoringUse Case.

Expected outcome




79 (176)



Confidential

R: 79/176

Further information

Figure 8. DCH availability monitoring

Activatereporting

Serviceif needed


M1000C55M1000C65M100071


1.

2.3.


Use Case complete!

AirValuesNOK



5.

ValuesOK 4.

Check the statusof the CCH

Too high AAL2blocking rateGo to BlockingUse Cases

Use Case complete!

RT DCH case

AAL2ValuesNOK

AAL2 BlockingMonitoring Use Cases

Load MonitoringUse Cases





Confidential

R: 80/176

7.4.3 HSDPA (HS-DSCH) availability monitoring

The radio bearer reconfiguration procedure is used by the RNC for allocating auser equipment (UE) to the shared channel (HS-DCH). For more information, seeUTRAN Resource Model overview.


If the HS-DSCH is not allocated, then no traffic capabilities can be given for a UEthat is requesting the capacity or is the subject of the request.

This use case is considered to be equal to HS-DSCH set-up monitoring. Forinstructions, see HS-DSCH set-up monitoring.

7.5 Resource availability and blocking monitoring usecases

7.5.1 IMA group availability monitoring

Purpose

The IMA group interface combines several E1 or T1 connections (later referred toas IMA links) into one logical interface. The availability of an IMA group can bemonitored between endpoints (that is, RNC and AXC in the BTS) using relatedperformance statistics in RNC and AXC.

This use case is based on RNC statistics.


It is also possible that an IMA group is terminated somewhere between the RNCand the BTS, which may happen if the BTSs are in a chain or ring topology. Inthis case, the AXC statistics for the IMA group should be used for connectionswhich are not terminated in the RNC.



81 (176)



Confidential

R: 81/176

Before you start



RNC RN1.5

BTS -

AXC C2.0

NetAct OSS3.1

SGSN -

MSC -

MGW -

UE -


The performance statistics should be available over a monitoring period for thefollowing RNC measurement:

. M 514 IMA logical interface measurement

Summary



Use case name IMA group availability monitoring

RAN releases From RAS05 onwards

Actor(s) Transport network planner, operationengineer

Summary The IMA group service quality ismonitored using standard availability anderror counters.





Confidential

R: 82/176


Reasons to perform the use case Regular monitoring of transmissionperformance (for example once a monthfor leased lines service quality reportingpurposes).


-

Limitations and restrictions The IMA logical interface measurement inRNC provides statistics for a maximum of8 IMA links. If more IMA links areconfigured to an IMA group, theperformance statistics for those links arenot available.

The needed counters are currently notavailable in real time measurements.

Preconditions . Report information service must beavailable.

. The following RNC measurementsshould be active:

- M 514 IMA logical interfacemeasurement

. The AXC statistics are available forlast 24 hours from AXC ElementManager.

If a longer history is required, thecounters should be collected toNetAct. Currently, only IMA group-specific counters can be collected toNetAct, not IMA link counters.

Postconditions The availability of the IMA group interfaceand problems with related IMA links areknown.

Steps

1. Find out the IMA group identifiers used in RNC for monitoredconnections.

The identifiers can be found, for example, from network documentation orconfiguration tools.

2. Check the counter M514C0 GR_UAS_IMA values for monitoredconnections.



83 (176)



Confidential

R: 83/176

Check the counter to find out the periods when the whole IMA group hasbeen unavailable.

3. Check counters M514C6 UAS_IMA1 and M514C7 UAS_IMA_FE1.

The IMA link-specific availability is indicated through link-level countersM514C6 UAS_IMA1 and M514C7 UAS_IMA_FE1.

The first counter reflects the quality from the BTS to the RNC, and thesecond counter reflects the quality from the RNC to the BTS.

Note

The counter IDs and names given here are for IMA link ID 1. For other links, thecounter IDs and names are different, they are created by adding the IMA link IDnumber at the end of counter name.

4. Check counters M514C4 SES_IMA1 and M514C5 SES_IMA_FE1.

The IMA link-specific errors are indicated through the following link-levelcounters:

. M514C4 SES_IMA1

This counter reflects the quality from the BTS to the RNC.. M514C5 SES_IMA_FE1

This counter reflects the quality from the RNC to the BTS.

5. Calculate the total unavailability or errors for a certain period.

The total unavailability or errors in a given period of time (for example,one month) can be calculated by summarising the IMA group and link-specific counter(s) over the given period of time in the NetAct Reportertool.

6. Use statistics to measure transmission network service quality andunavailability to estimate L1 protection need.

Statistics can be used to measure the transmission network service quality,and unavailability can be used as input for transmission planning toestimate the L1 protection need.





Confidential

R: 84/176

Further information

Figure 9. IMA group service availability monitoring

7.5.2 SDH path availability monitoring

Purpose

The availability and quality of SDH connections can be monitored between SDHpath endpoints using standard ITU-T G.828 performance indicators.


Before you start



RNC RN1.5

BTS -

AXC -

NetAct OSS3.1

IMA group service availability monitoring

Monitor the wholeIMA group status

Find out the IMA groupand link ID:s

Monitor link levelperformance

Utilise results forquality reportingor planning

Summarizeresults inReporter tool

(1)(2)

(3&4)(6)

(5)



85 (176)



Confidential

R: 85/176

Table 33. Network element software requirements (cont.)


SGSN -

MSC -

MGW -

UE -


The performance statistics should be available over a monitoring period for thefollowing RNC measurement:

. M513 STM-1 interface measurement

Summary



Use case name SDH path availability monitoring



Summary The SDH path service quality ismonitored using standard availability anderror counters.

Reasons to perform the use case Regular monitoring of transmissionperformance (for example, once a monthfor leased lines' service quality reportingpurposes).


-





Confidential

R: 86/176


Limitations and restrictions Low order (VC-11/VC-12) paths can notbe monitored, since there are nodedicated performance statisticsavailable. Those are often used as a partof IMA group. If that is the case, refer toRAN_USE_CASE_MON_10.

The required counters are currently notavailable in real time measurements.

Preconditions . Report information service must beavailable.


- M 513 STM-1 interfacemeasurement

Postconditions The availability and quality of the SDHpath connection is known.

Steps

1. Find out the identifiers used in RNC for the monitored connections.

The SDH connections termination points are identified in RNC by theexchange terminal type (SET) and index. Find out the related identifiersused in RNC for monitored connections. The identifiers can be found, forexample, from network documentation or configuration tools.

If the VC-3 mapping is used, there are dedicated counters for the threepaths. Therefore, you also need to know the specific number for each path.

2. Check the counters M513C14 NE_PATH1_UAS and M513C30FE_PATH1_UAS to find out the periods when the path has beenunavailable.

The counters are for two transmission directions. The first counter refers toavailability detected at the near end (in the RNC) and the second counterrefers to the far (in the BTS or other neighbour network element).

3. Find out if there are periods with transmission errors.

After the unavailable periods are detected, use counters M513C16NE_PATH1_ES and M513C32 FE_PATH1_ES to find out if there areperiods with transmission errors. The counters are for near-end and far-endas in the case of availability counters.



87 (176)



Confidential

R: 87/176

4. Find out the total unavailable seconds or errored seconds duration fora specified period.

The total unavailable seconds (UAS) or errored seconds (ES) duration for,for example, a one-month period can be calculated by summarising thecounters over a one-month period in the NetAct Reporter tool.

5. Measure transmission network service quality.

The statistics can be used to measure the transmission network servicequality. The unavailability can also be used as an input for transmissionplanning to estimate the L1 protection needed.

Further information

Figure 10. SDH path availability monitoring

7.5.3 AAL2 path Iub resource monitoring (non-HSDPA)

Purpose

The AAL2 type ATM connections are used to transport all RAB, RRC andcommon channel connections between the RNC and BTS. The number of ATMVC connections dedicated for AAL2 traffic depends on the BTS configuration(baseband capacity), number of users, user profiles and whether the BTS AAL2multiplexing is enabled.

SDH path availability monitoring

Monitor theavailability fornear and far end

Find out the identifiersfor SDH path

Monitor errors fornear and far end

Utilise results forquality reportingor planning

Summarizeresults inReporter tool

(1)(2)

(3)

(4)





Confidential

R: 88/176

The capacity demand for Iub AAL2 connections has a major effect on the totalIub capacity need, since most of the traffic is AAL2 multiplexed.


Before you start



RNC RN2.1

BTS -

AXC -

NetAct OSS4

SGSN -

MSC -

MGW -

UE -

Note

This instruction is used only for AAL2 type VCCs, which are not used forHSDPA traffic. If there are also HSDPA users in one of the monitored VCCs, theperformance of those should be verified at the same time, usingRAN_USE_CASE_MON_13. See AAL2 path Iub resource monitoring (HSDPAenabled)

The ATM layer identifiers used for the monitored Iub connections can be foundfrom network configuration tools, documentation, or anywhere that theinformation is kept up to date.


The performance statistics should be available for at least a one-week period forthe related RNC measurements. The measurements are:



89 (176)



Confidential

R: 89/176

. M 550; AAL2 path CAC resource measurement

. M 800; AAL2 resource reservation measurement

. M 548; AAL2 signalling protocol at UNI

The range of target values for the following KPIs are network-dependent andshould be decided before starting this use case. The target values should be set fora daily busy hour period.

Table 36. Target values for AAL2 layer connections performance in Iub, duringbusy hour

RAN KPI ID KPI name Target values

RAN_KPI_0036 AAL2 resourcesavailability in RNC [%]

(In this case for Iub AAL2connections.)

[%]

RAN_KPI_0037 AAL2 path averagereserved bandwidth [%]

(In this case for Iub AAL2connections.)

[%]

Summary



Use case name AAL2 path Iub resource monitoring (noHSDPA)



Summary The AAL2 path accessibility is monitoredto find connection bottlenecks and otherreasons preventing transport resourcereservations for radio bearers.





Confidential

R: 90/176


Reasons to perform the use case . Regular monitoring of transportnetwork performance

. Radio network capacity of a certainBTS site is changed


Radio layer initiates Iub transportresource reservation.


Preconditions Report information service must beavailable. The following RNCmeasurements should be active:. M 550; AAL2 path CAC resourcemeasurement

. M 800; AAL2 resource reservationmeasurement

. M 548; AAL2 signalling protocol atUNI

Postconditions The AAL2 transport resource accessibilityis at a desired level.

Steps

1. Check that the AAL2 resource availability is equal to RAN_KPI_0036.

The target value for this KPI depends on the required transport networkaccessibility. It should be decided separately for each network. The AAL2accessibility criteria should be fulfilled for each monitored AAL2 typeVCC during busy hour. The busy hour is defined as an hour of day whenRAN_KPI_0037 has the highest value.

2. If the AAL2 resource availability is below the target range, check thefollowing counters in AAL2 resource reservation measurementindicating the cause(s) for rejected setups.

. M800C1 RES_EXT_CAP

This counter indicates that the AAL2 VCC capacity is too low. Goto step 6.

. M800C2 RES_INT_CAP

This counter indicates that the A2SP unit terminating the AAL2VCC has too high load. Go to step 4.

. M800C5 AAL2_REJECTED



91 (176)



Confidential

R: 91/176

This counter indicates that there is an AAL2 signalling problem. Goto step 5.

3. Check the capacity of the A2SP unit.

If there is not enough capacity in A2SP unit terminating the AAL2 VCC,the lack of capacity will block the set-up of new connections. Correct thesituation by moving some highly loaded connections to another A2SP unit.

4. Check for signalling failures indicating problems in the BTS ortransmission between RNC and BTS.

A more detailed reason for failed signalling can be found frommeasurement AAL2 signalling protocol at UNI. The BTS relatedfailures are indicated with the following counters:

. M548C4: REQ_CHAN 44: If the requested CID number is alreadyin use

. M548C5: RES_UNAVAIL: If there are not enough resources in BTSor in AAL2 path (uplink direction controlled by BTS AAL2 CAC).

5. Check the load of AAL2 VCC controlled by CAC.

The average CAC load can be calculated using RAN_KPI_0037. Thelimits for this KPI value are dependent on the required transport serviceaccessibility, expected network traffic growth rate and networkmanagement processes in general. The target value range for the Iur AAL2VCC load should be decided separately for each network (see Table Targetvalues for AAL2 layer connections performance in Iub, during busy hour).

6. Check if there is enough capacity in the Iub AAL2 VCC.

This may require increasing the transmission capacity between the RNCand node B. Inform network planning about the capacity need. Increasingthe ATM VCC capacity may require ordering new L1 capacity and couldtake some time to complete.

7. Check if the Iub ATM capacity is fully utilised.

It may be possible to swap the capacity to some other ATM connection,utilising the same transmission line. Inform network planning if there is alow utilisation connection.

Expected outcome

During busy hour, the transport resources availability and load are at anacceptable level.





Confidential

R: 92/176

Further information

Figure 11. Verifying Iub AAL2 connection performance (non-HSDPA)

7.5.4 AAL2 path Iub resource monitoring (HSDPA enabled)

Purpose

The AAL2 type connections are used to transport all RAB, RRC and commonchannel connections between the RNC and BTS. The number of ATM VCconnections dedicated for AAL2 traffic depends on the BTS configuration(baseband capacity), number of users, user profiles and whether the BTS AAL2multiplexing is enabled.


The capacity demand for Iub AAL2 connections has a major effect on the totalIub capacity need, since most of the traffic is AAL2 multiplexed. The HSDPAtraffic has lower priority and in a congestion situation, HSDPA traffic is alwaysdelayed or dropped first to maintain the RT and NRT DCH service quality.

List the ATM VCCrelated to Iub inquestion and checkthe identifiers in RNC

No

1.

Inform networkplanning

AAL2 transport qualityverification complete!

Check the AAL2 VCCload (estimated by CAC)

The AAL2 setupsuccess rate foreach VCC > target

What are the causesfor transport rejection(check detailed counters)

Check signallingcounters for rootcause, correctproblem

Change theAAL2 VCCterminatingA2SP unitin RNC

Inform networkplanning

2. 3.

5.

4.

9.

8. 7.

6.

Signallingfailure

Internal CACcapacity

External CACcapacity

Low loadedconnection High loaded

connection

Load is withintarget limits

Yes



93 (176)



Confidential

R: 93/176

Before you start

Note

This use case is used only for shared VCCs, which are used for both HSDPA andDCH traffic. If there are VCCs dedicated only for DCH traffic in same logical Iubinterface, the performance of those should be verified at the same time, using theuse case RAN_USE_CASE_MON_14.

The ATM layer identifiers used for the monitored Iub connections can be foundfrom network configuration tools, documentation, or anywhere that theinformation is kept up to date.



RNC RN2.1

BTS -

AXC -

NetAct OSS4

SGSN -

MSC -

MGW -

UE -


The performance statistics should be available for at least a one-week period forthe following RNC measurements:

. AAL2 path CAC resource measurement

. AAL2 resource reservation measurement

. AAL2 signalling protocol at UNI





Confidential

R: 94/176

. ATM Virtual Channel connection

. RCPM RLC

The range of target values for the KPIs in the following table are network-dependent and should be decided before starting this use case:

Table 39. Target values for AAL2 layer connection performance in Iub, ifHSDPA is enabled

RAN KPI ID or PIname

KPI name Target values

RAN_KPI_0036 AAL2 resourcesavailability in RNC [%]

(in this case for Iub AAL2connections)

[%]

RAN_KPI_0037 AAL2 path averagereserved bandwidth [%]

(in this case for Iub AAL2connections)

[%]

RAN_KPI_0041

RLC HSDPAretransmission rate

The HSDPA trafficretransmission ratio [%]

[%]

The performance statistics information can be handled using the NetAct Reportertool or RNC NEMU NE Measurement Explorer.

Summary



Use case name AAL2 path Iub resource monitoring(HSDPA enabled)





95 (176)



Confidential

R: 95/176


Summary The AAL2 path accessibility is monitoredto find connection bottlenecks and otherreasons preventing transport resourcereservations for radio bearers.

Reasons to perform the use case . Regular monitoring of transportnetwork performance

. Radio network capacity of a certainBTS site is changed


Radio layer initiates Iub transportresource reservation.


Preconditions Report information service must beavailable. The following RNCmeasurements should be active:. M 550; AAL2 path CAC resourcemeasurement

. M 800; AAL2 resource reservationmeasurement

. M 548; AAL2 signalling protocol atUNI

. M xxx; RCPM RLC

Postconditions The AAL2 transport resource accessibilityis at desired level.

Steps

1. Check that the AAL2 resources availability is equal toRAN_KPI_0036.

The target value for this KPI depends on the required transport networkaccessibility. It should be decided separately for each network (see TableTarget values for AAL2 layer connections performance in Iub, if HSDPA isenabled).

2. If the AAL2 resource availability is below the target range, check thefollowing counters in AAL2 resource reservation measurement whichindicate the cause(s) for rejected setups.

. M800C1

RES_EXT_CAP





Confidential

R: 96/176

This counter indicates that the AAL2 VCC capacity is too low. Goto step 4.

. M800C2

RES_INT_CAP

This counter indicates that the A2SP unit terminating the AAL2VCC has too high load. Go to step 5.

. M800C5

AAL2_REJECTED

This counter indicatesthat there is a AAL2 signalling problem. Go tostep 6.

3. Check if there is enough capacity dedicated for DCH traffic in AAL2VCC.

If there is not enough capacity, there are two alternatives to correct thisproblem:

a. Increase the VCC PCR parameter value.

b. Decrease the shared HSDPA AAL2 allocation

Increasing the VCC PCR is recommended, since decreasing the HSDPAallocation will decrease the HSDPA dedicated Iub part and may causedropping of HSDPA traffic. The shared HSDPA flow control allocationvalue should be adjusted accordingly to avoid dropping of HSDPA trafficin the ATM layer.

4. Check the capacity in A2SP unit terminating the AAL2 VCC.

If there is not enough capacity in A2SP unit that terminates the AAL2VCC, the lack of capacity will block the set-up of new connections.Correct the situation by moving some high loaded connections to anotherA2SP unit.

5. Check for signalling failures indicating problems in the BTS ortransmission between RNC and BTS.

A more detailed reason for failed signalling can be found frommeasurement AAL2 signalling protocol at UNI. The BTS relatedfailures are indicated with the following counters:

. M548C4: REQ_CHAN 44

This counter indicates that the requested CID number is already inuse.

. M548C5: RES_UNAVAIL



97 (176)



Confidential

R: 97/176

This counter indicates that there are not enough resources in BTS orin AAL2 path (uplink direction controlled by BTS AAL2 CAC).

The HSDPA return channel reservations may cause a situation where theuplink direction becomes a bottleneck and the BTS ATM CAC rejects theHSDPA or DCH resource reservation (in this case, the M548C5 counter isupdated).

6. Check the measured HSDPA RLC retransmission ratio(RAN_KPI_0041).

At this point, it has already been verified that DCH connections forcommon channels, and RT and NRT RABs are getting the desired qualityfrom the transport network.

The transport network quality for HSDPA is monitored by following theRLC layer retransmissions, which indicate missing HSDPA traffic in theIub. If HSDPA traffic is lost because of RLC retransmissions, but DCHtraffic is not suffering from retransmission at the same time, the reason forretransmissions is most likely the lack of Iub capacity.

Compare the measured HSDPA RLC retransmission ratio(RAN_KPI_0041) with target values in table Table Target values forAAL2 layer connections performance in Iub, if HSDPA is enabled.

7. Correct the blocking of HSDPA caused by transport.

There are two alternatives to correct the blocking of HSDPA because oftransport:

. Increase the Shared HSDPA AAL2 allocation size.

The AAL2 VCC size should be increased by same amount also. Thisis the recommended method.

. Decrease the Shared HSDPA flow control allocation parametervalue to limit the HSDPA traffic volume.

However, Iub becomes a bottleneck for HSDPA in this case.

Expected outcome

During busy hour, DCH traffic is not blocked because of Iub transport, HSDPAtraffic is not lost too much in Iub and the average load of VCC is at a desiredlevel.





Confidential

R: 98/176

Further information

Figure 12. Verifying Iub AAL2 connection performance (HSDPA enabled)

7.6 Throughput and load monitoring use cases

7.6.1 Total load monitoring

Purpose

To measure the load behavior for control purposes, the PrxTotal (UL),PtxTotal (DL) and their distribution need to be measured and calculated.PrxTotal means the total received (interference) power measured by the BTS.PtxTotal means the total transmitted power measured by the BTS. For moreinformation, see UTRAN Resource Model overview.


List theHSDPAcapable ATM VCCrelated to Iub inquestion and checkthe identifiers in RNC

No

1.

Increase AAL2 VCCcapacity for DCH traffic

The AAL2 setupsuccess rate foreach VCC > target

What are the causesfor transport rejection(check detailed counters)

Change theAAL2 VCCterminatingA2SP unitin RNC

Increase Iub capacityfor HSDPA or limitHDSPA throughput

2. 3.

6.

5.

4.

9. 8.

7.

Signallingfailure

Internal CACcapacity

Yes

Check signallingcounters for rootcause, correctproblem

Check the transportquality for HSDPA traffic

AAL2 transport qualityverification complete!

External CACcapacity

Traffic getslost in Iub



99 (176)



Confidential

R: 99/176

An overload situation restricts the establishing new connections by radio resourcemanagement.

Before you start



RNC RN1.5

BTS WN2.0

AXC n/a

NetAct OSS3.2

SGSN n/a

MSC n/a

MGW n/a

UE n/a


. PrxTotal

. PrxOffset

. L_RT

. L_NRT

. PtxTotal

. PtxRT

. PtxOffset

The parameters are used for building a histogram for the non-real counters toobtain a distribution chart of samples (obtained every RRIndPeriod) accordingthe following tables:





Confidential

R: 100/176

Table 42. Parameters

CLASS AREA INCREMENTED IF

CLASS 0 Unloaded (Lrt =< UnloadedRT) ANDLnrt =< UnloadedNRT)

CLASS 1 Feasible_Load_Area_1 PrxTarget - PrxOffset >=PrxTotal) AND ((Lrt >UnloadedRT) OR (Lnrt >UnloadedNRT))

CLASS 2 Feasible_Load_Area_2 PrxTarget > PrxTotal >PrxTarget - PrxOffset)AND ((Lrt > UnloadedRT)OR (Lnrt >UnloadedNRT))

CLASS 3 Marginal_Load_Area (PrxTarget + PrxOffset >PrxTotal >= PrxTarget)AND (Lrt > UnloadedRT)OR (Lnrt >UnloadedNRT))

CLASS 4 Overload_Area PrxTotal >= PrxTarget +PrxOffset) AND ((Lrt >UnloadedRT) OR (Lnrt >UnloadedNRT))



CLASS 0 Unloaded There are no UEs inCell_DCH state.

CLASS1 Feasible_Load_Area_1 PtxTotal < PtxTarget -PtxOffset AND (at leastone UE is in Cell_DCHstate)



101 (176)



Confidential

R: 101/176



CLASS 2 Feasible_Load_Area_2 PtxTarget - PtxOffset dPtxTarget AND (at leastone UE is in Cell_DCHstate)

CLASS 3 Marginal_Load_Area PtxTarget d PtxTotal <PtxTarget + PtxOffset AND(at least one UE is in Cell-DCH state)

CLASS 4 Overload_Area PtxTotal e PtxTarget +PtxOffset AND (at leastone UE is in Cell_DCHstate)

For real time counters, the parameters (all but the RRInperiod) are used tobuild an online view to visualise the received power levels in relation toparameter settings.


. Cell Resource








Online: PrxTotal Depends on planningtargets

Real-time snapshots in 5second intervals

Online: PrxNoise Depends on planningtargets






Confidential

R: 102/176




Online: PtxTotal Depends on planningtargets


Online: L_RT Depends on planningtargets


Online: L_NRT Depends on planningtargets



Summary



Use case name Total load monitoring

RAN releases RAN1.5

Actor(s) Radio network planner, operationengineer

Summary The total load is monitored and verifiedwith performance statistics reports on adaily basis.



In RAN1.5, the PrxTotal andPtxTotal are reported from BTS byusing Nokia's proprietary NBAP interfacein NBAP: RADIO RESOURSEINDICATOR message.

In the 3GPP NBAP specification, thePrxTotal and PtxTotal are reported inNBAP: COMMON MEASUREMENTREPORTING message or by using Nokiaproprietary Radio Resource Indication(RRI) function with private messagemechanism.



103 (176)



Confidential

R: 103/176


Limitations and restrictions The online monitoring can be done atmaximum for 11 cells.




- M1000; Cell Resource

For online monitoring purposes, theonline monitoring tool must be available.The following online measurement shouldbe active:. Cell Load

Postconditions The network load is at desired level.

Steps



If there are no active alarms, collect the performance statistics from CellResource measurement in RNC for at least a one-hour period, and continueto step 2.




If the KPIs show that the load ratio is too high, continue to step 3.

3. Evaluate the problem cell(s) further with the Online Monitoring tool.

After the evaluation is done, compare the results to what was planned inthe planning Use Cases and go to step (4).

4. Go to planning.





Confidential

R: 104/176

Expected outcome


Further information

Figure 13. Total load monitoring

Activatereporting

Serviceif needed


CheckRAN_KPI_0009, 0010


1.

2.

3.




5.

ValuesOK

4.

Check the PrxTotal,PtxTotal etc. valuesusing OnlineMonitoring tool

Use Case complete!

ValuesNOK

Compare toPlanning Use Cases



105 (176)



Confidential

R: 105/176

7.6.2 Noise rise monitoring

Purpose

The purpose of this use case is to collect information about the experienced noiserise in each selected service access point (WCELL) in the network. The noise risemeans the ratio of the total received power compared to system backgroundnoise.


The total received power is visible in the PrxTotal counters and the systembackground noise is visible in the PrXNoise counters.

Before you start



RNC RN1.5

BTS WN2.0

AXC n/a

NetAct OSS3.2

SGSN n/a

MSC n/a

MGW n/a

UE n/a


The following parameters are related to the use case:

. PrxTotal

. PrxOffset

. PrxNoise

. L_RT





Confidential

R: 106/176

. L_NRT

. RRIndPeriod

The usage for the parameters for non-real time counters is presented in the TotalLoad Monitoring Use Case.

For real time counters, the parameters PrxTotal, PrxOffset and PrxNoiseare used to build an online view displaying the received power levels in relationto the parameter settings.


. Cell Resource

The following Online Monitoring type should be active:

. Cell Load








Online: PrxTotal Depends on planningtargets

Real time snapshots in 5second intervals

Online: PrxNoise Depends on planningtargets


The alarm 7771 WCDMA CELL OUT OF USE should not be active.



107 (176)



Confidential

R: 107/176

Summary



Use case name Total load monitoring

RAN releases RAN1.5


Summary The total load is monitored and verifiedwith performance statistics reports on adaily basis.

Reasons to perform the use case . Regular monitoring. Problems with RAN_KPI_0009 andRAN_KPI_0032 values


In RAN1.5, the PrxTotal and PtxTotal arereported from the BTS by using the Nokiaproprietary NBAP interface in NBAP:RADIO RESOURSE INDICATORmessage.

In 3GPP NBAP specification, the PrxTotaland PtxTotal are reported in NBAP:COMMON MEASUREMENTREPORTING message or by using theNokia proprietary radio resourceindication (RRI) function with privatemessage mechanism.

Limitations and restrictions The online monitoring can be done for amaximum of 11 cells.



. The following RNC measurementshould be active:

- M1000; Cell Resource. For online monitoring purposes theonline monitoring tool must beavailable. The following onlinemeasurement should be active:

- Cell Load





Confidential

R: 108/176


Postconditions The network noise rise is at the calculatedlevel.

Steps



If there are no active alarms, collect the performance statistics from theCell Resource measurement in the RNC for at least a one-hour period andcontinue to step 2.




If the KPIs show too high a load ratio, continue to step 3.

3. Evaluate the problem cell(s) further with the Online Monitoring Tool.

After the evaluation is done, compare the results to what was planned inthe planning use cases and go to step 4.

4. Go to planning.

Expected outcome




109 (176)



Confidential

R: 109/176

Further information

Figure 14. Noise rise monitoring

7.6.3 Traffic amounts of RBs

Purpose

The purpose of this use case is to collect information about the traffic amounts fordifferent connection types, that is, RBs. The radio bearers can have either ashared or a dedicated transport channel.

Activatereporting

Serviceif needed




1.

2.

3.




5.

ValuesOK

4.

Check the PrxTotalvs. PtxTotal valuesusing OnlineMonitoring tool

Use Case complete!

ValuesNOK






Confidential

R: 110/176


The traffic amounts are calculated using RLC PDU net throughput values.

Before you start



RNC RN2.1

BTS WN3.0

AXC n/a

NetAct OSS3.2

SGSN n/a

MSC n/a

MGW n/a

UE n/a


There are no parameters related to this use case.


. RCPM RLC








111 (176)



Confidential

R: 111/176






The alarms 7771 WCDMA CELL OUT OF USE and 7776 HSDPA FAILURE INWCEL must not be active.

Summary



Use case name Traffic amounts of RBs

RAN releases RAN5


Summary The traffic amounts for selected RBs aremonitored and verified with performancestatistics reports on a daily basis.



Radio Bearer Reconfiguration message

Limitations and restrictions The needed counters are currentlyavailable only in non-real timemeasurements.




- M1017; RCPM RLC





Confidential

R: 112/176


Postconditions The RB traffic amounts are known.

Steps



If there are no active alarms, collect the performance statistics from theRCPM RLC measurement in RNC for at least a one-hour period, andcontinue to step 2.

2. Check the Traffic amounts.

The available KPIs are found in Targets for WCDMA RAN keyperformance indicators.

Expected outcome




113 (176)



Confidential

R: 113/176

Further information

Figure 15. RB traffic monitoring

7.6.4 Traffic amounts for cells

Purpose

The purpose of this use case is to collect information about the traffic amounts forWCELLs. For more information, see UTRAN Resource Model overview.


Activatereporting

Serviceif needed


Use RAN_KPI_0034,0040 to seeTraffic amounts


1.

2.




3.

Use Case complete!





Confidential

R: 114/176

The traffic amounts are calculated using the allocated DCH capacity in each cellfor RT traffic and RLC SDU amounts for NRT Traffic.

Before you start



RNC RN2.1

BTS WN3.0

AXC n/a

NetAct OSS3.2

SGSN n/a

MSC n/a

MGW n/a

UE n/a


There are no parameters related to this use case.


. RCPM RLC










115 (176)



Confidential

R: 115/176








M10017C30: UL RLC AMSDU PAYLOAD OF PSTRAFFIC

Updates according totraffic amounts


M1017C31: DL RLC AMSDU PAYLOAD OF PSTRAFFIC

Updates according totraffic amounts


The alarms 7771 WCDMA CELL OUT OF USE and 7776 HSDPA FAILUREIN WCEL must not be active.

Summary



Use case name Traffic amounts for cells

RAN releases RAN5


Summary The traffic amounts for WCELLs aremonitored and verified with performancestatistics reports on a daily basis.



Radio Bearer Setup and Reconfigurationmessages





Confidential

R: 116/176






- M1002 Traffic

- M1017; RCPM RLC

Postconditions The WCELL traffic amounts are known.

Steps




2. Check the traffic amounts.

The available KPIs and/or counters are found in Targets for WCDMA RANkey performance indicators.

Expected outcome




117 (176)



Confidential

R: 117/176

Further information

Figure 16. Cell traffic monitoring

7.6.5 HSDPA Iub traffic load monitoring

Purpose

The HSDPA traffic can utilise all capacity left from DCH connections andcommon channels in AAL2 ATM VCC. The purpose of this use case is toestimate the HSDPA throughput in the Iub.

Activatereporting

Serviceif needed



1. 2.




3.

Use Case complete!

Use RAN_KPI_0014,15, 16, 17 to see RTTraffic amountsUse M01017C30, C31to see NRT Trafficamounts





Confidential

R: 118/176


Before you start



RNC RN2.1

BTS -

AXC -

NetAct OSS4

SGSN -

MSC -

MGW -

UE -


The performance statistics should be available for at least a one-week period forthe following measurements:

. M 5000 HSDPA in WBTS

The range of target values for the following PIs are network-dependent andshould be checked from dimensioning documents before starting this use case.For more information, see Dimensioning and Configuring WCDMA RAN.

In the following table, the factor ATM_overhead is used to scale the result fromMAC-d PDU to ATM cell/s.



119 (176)



Confidential

R: 119/176

Table 57. Target values for Iub HSDPA traffic load

Performanceindicator

Definition Dimensioning values

HSDPA ATM throughput(downlink)

(M5000C7 / meas.periodlength [s]) *ATM_overhead

[cells/s]

Summary



Use case name HSDPA Iub traffic load monitoring



Summary The HSDPA throughput in Iub ismonitored using BTS MAC layercounters.

Reasons to perform the use case The HSDPA traffic throughput in Iubneeds to be know for network capacityplanning purposes.


-

Limitations and restrictions The throughput is measured for theWBTS object. If there is more than oneATM VCC used in Iub for HSDPA traffic,the traffic distribution between theseVCCs cannot be monitored.

The scaling from MAC-d PDU to ATMcells causes an error margin to the result(± 5%).

The needed counters are currentlyavailable only in non-real timemeasurements.





Confidential

R: 120/176


Preconditions . The report information service mustbe available.

. The following BTS measurementsshould be active:

- M 5000 HSDPA in WBTS

Postconditions None

Steps

1. Find out the BTS identifiers (BTS Id) for the Iub connections to bemonitored.

2. Compare the estimated ATM layer HSDPA throughput to the valuescalculated by dimensioning.

Compare the estimated throughput based on the target values in tableTarget values for Iub HSDPA traffic load.

3. Check if there is a difference between the dimensioned and realHSDPA ATM traffic throughput.

If there is difference between dimensioned and real HSDPA ATMthroughput, change the Iub parameters to be in line with real values.

There are some alternatives to balance the difference.

Change the shared HSDPA AAL2 allocation size to be in line with the realusage.

Note

The Shared HSDPA flow control parameter also has to be changed to keep theselected relation between these two parameters.

4. Check that the parameters values and real throughput are in line witheach other.



121 (176)



Confidential

R: 121/176

Further information

Figure 17. HSDPA Iub traffic load monitoring

7.6.6 Iu-PS traffic load monitoring

Purpose

The assumption in this use case is that the Iu-PS interface has been dimensionedand configured according to given instructions in document Dimensioning andConfiguring WCDMA RAN. The purpose of this use case is to ensure that theexceptions made in dimensioning the Iu-PS interface are correct, that is, thetraffic volumes are at an expected level.


The user plane traffic is transported over the Iu-PS interface using GTP over IP.Under the IP layer, ATM is used as the transport layer. One logical Iu-PSconnection utilises one ATM VCC, which is usually of type UBR.

In this use case, the load of the Iu-PS connections is monitored to give input fornetwork planning.

HSDPA Iub traffic load monitoring

Compare themeasured ATMthroughput estimateto dimensioning

Find out the BTS IDsfor Iub connections tobe monitored

Measured valuesare in line withparameters

(1)(2)

(4)

Change theparameter values

(3)





Confidential

R: 122/176

Before you start



RNC RN2.1

BTS -

AXC -

NetAct OSS4

SGSN -

MSC -

MGW -

UE -



. M 530 ATM Virtual Channel connection

The range of target values for following PIs are network dependent and should bechecked from dimensioning documents before starting this use case. For moreinformation, see Dimensioning and Configuring WCDMA RAN. The factor0.424 is just to scale the result from ATM cell/s to kbit/s.

Table 60. Target values for Iu-PS ATM connections traffic load


Definition Dimensioning values

ATM_VCC throughputingress

(M530C0 / meas. periodlength [s]) * 0.424

[kbit/s]

ATM_VCC throughputegress

(M530C1 / meas. periodlength [s]) * 0.424

[kbit/s]



123 (176)



Confidential

R: 123/176

Summary



Use case name Iu-PS traffic load monitoring



Summary The Iu-PS interface throughput ismeasured per ATM VCC to ensure thattraffic volumes are at an expected level.

Reasons to perform the use case Regular monitoring of transport networkperformance


-




- M 530 ATM Virtual Channelconnection


Steps

1. Find out the ATM VC identifiers (interface id / VPI / VCI) for Iu-PSATM connections to be monitored.

The delay-sensitive and non-sensitive PS traffic are using dedicated GTPUand dedicated ATM VCC.

2. Compare the measured ATM VCC utilisation ratio to the valuescalculated by dimensioning.





Confidential

R: 124/176

Compare the measured ATM VCC utilisation ratio based on the targetvalues in Table Target values for Iu-PS ATM connections traffic load.

Note

The ATM layer headers will cause an estimated 10% overhead to the IP layertraffic. The overhead is included in the measured ATM layer throughput but notin IP layer dimensioning.

3. Check it traffic is distributes to several VCCs.

If the traffic is distributed to several VCCs, summarise the results topresent same network topology as used for planning.

4. Check the measured traffic volumes.

If the measured traffic volumes are within target, there is enough capacityfor the Iu-PS connections and the estimations made in the dimensioningphase are correct.

If the traffic volume clearly exceeds the target value, the Iu-PS interfacecapacity requirements should be corrected. It may also be necessary tochange the Iu-PS transport configuration.



125 (176)



Confidential

R: 125/176

Further information

Figure 18. Iu-PS traffic load monitoring

7.7 Mobility use cases

7.7.1 Soft handover monitoring

Purpose

The purpose of this use case is to see that the mobility is in order for the RRCconnected state (CELL_DCH and CELL_FACH) UEs according to the targetvalues.

The follow up is done according to the source WCELL of the SHO. For moreinformation, see UTRAN Resource Model overview.


Iu-PS traffic load monitoring

Compare themeasured ATMVCC utilisation toplanning values

Find out the ATMidentifiers for Iu-PSconnections

Measured valuesare in line withdimensioning

(1)(2)

(3) (5)

If trafficdistributed toseveral VCC sumup the values

There issignificant errorbetweendimensioning andreal traffic

(4)





Confidential

R: 126/176

Before you start



RNC RN1.5

BTS WN2.0

AXC n/a

NetAct OSS3.2

SGSN n/a

MSC n/a

MGW n/a

UE n/a


Cell parameters:

. Antenna Coordinates

. Antenna Bearing

. Repeater exists

Radio link-specific parameters:

. Maximum DL TX Power level

. Initial SIR Target

. Minimum value of the SIR Target

. Maximum value of the SIR Target

Bearer-specific parameters for each dedicated channel:

. Initial planned Eb/No target

. BLER target (for low quality bearers)



127 (176)



Confidential

R: 127/176


. Soft Handover

The following online monitoring type should be active:

. Handover Monitoring






Online: NUMBER OFRECEIVED EC/NOVALUES CLASS 1, ...NUMBER OF RECEIVEDEC/NO VALUES CLASS12

Depends on planningtargets


Online: NUMBER OF 1A Depends on planningtargets


NUMBER OF 1B Depends on planningtargets


NUMBER OF 1C Depends on planningtargets



Summary




RAN releases RAN5





Confidential

R: 128/176






Active Set Update and Completemessages /TS 25.331/

Limitations and restrictions The online monitoring can be done atmaximum for 11 cells.




- M1007 Soft Handover. For online monitoring purposes theonline monitoring tool must beavailable. The following onlinemeasurement should be active:

- Handover Monitoring

Postconditions The SHO rates are verified.

Steps



If there are no active alarms, collect the performance statistics from SHOmeasurement in RNC for at least a one-hour period, and continue to step 2.


The recommended KPI values are found in Targets for WCDMA RAN keyperformance indicators.



129 (176)



Confidential

R: 129/176

If the values are ok, the use case is complete.

If the KPIs show that the load ratio is too high, continue to step 3.


. NUMBER OF RECEIVED EC/NO VALUES CLASS 1 , NUMBEROF RECEIVED EC/NO VALUES CLASS 2, &, NUMBER OFRECEIVED EC/NO VALUES CLASS 12

These are related to the parameters Addition Time, DeletionTime and Replacement Time.

. NUMBER OF 1A

This is related to the parameter Addition Time.. NUMBER OF 1B

This is related to the parameter Drop Time.. NUMBER OF 1C

This is related to the parameter Replacement Time.

4. Go to planning section for more instructions (link to planning).

Expected outcome






Confidential

R: 130/176

Further information

Figure 19. Soft handover monitoring

7.7.2 Hard handover monitoring

Purpose

The purpose of this use case is to see that the mobility is in order for RRCconnected state (CELL_DCH and CELL_FACH) UEs according to target values.

The follow up is done according to source cell of the SHO. For more information,see UTRAN Resource Model overview.

Activatereporting

Serviceif needed


CheckRAN_KPI_0020


1.

2.

3.




5.

ValuesOK

4.

Check the CPICH Ec/No,Values and number ofreceived 1A, 1B and 1Creports using OnlineMonitoring tool

Use Case complete!

ValuesNOK




131 (176)



Confidential

R: 131/176


Before you start



RNC RN1.5

BTS WN2.0

AXC n/a

NetAct OSS3.2

SGSN n/a

MSC n/a

MGW n/a

UE n/a


The following parameters affect this use case:

. Intra System HHO: FMCI and HOPS parameters

- IFHOcauseCPICHEcNo

- IFHOcauseCPICHrscp

- IFHOcauseTxPwrUL

- IFHOcauseTxPwrDL

- IFHOcauseTxPwrUL

. Inter System HHO: FMCG parameters:

- GSMcauseCPICHEcNo

- GSMcauseCPICHrscp

- GSMcauseTxPwrUL

- GSMcauseTxPwrDL

- GSMcauseTxPwrUL





Confidential

R: 132/176


. Intra System HHO

. Inter System HHO

The following Online Monitoring type should be active:

. Handover Monitoring








Online: COMPLETEDINTRA SYSTEM HHOSIN THE CELL



Online: NUMBER OF 1E Depends on planningtargets


Online: NUMBER OF 1F Depends on planningtargets


Online: COMPLETEDINTER SYSTEM HHOSIN THE CELL



Online: FAILED INTRASYSTEM HHOS IN THECELL



Online: FAILED INTERSYSTEM HHOS IN THECELL






133 (176)



Confidential

R: 133/176

Summary




RAN releases RAN5



Reasons to perform the use case . Regular monitoring. problems with RAN_KPI_0021-22value


Radio bearer set-up and radio bearerreconfiguration, physical channelreconfiguration, transport channel andcorresponding complete messages

Limitations and restrictions The online monitoring can be done for amaximum of 11 cells.




- M1008;Intra System HHO

- M1009;Inter System HHO

For online monitoring purposes, onlinemonitoring tool must be available. Thefollowing online measurement should beactive:. Handover Monitoring

Postconditions The HHO rates are verified.

Steps






Confidential

R: 134/176


If there are no active alarms, collect the performance statistics from HHOmeasurements in the RNC for at least a one-hour period, and continue tostep 2.




If the KPIs show too high a load ratio, continue to step 3.


These counters show the relationship between successful and unsuccessfulHHOs in the cell.

. NUMBER OF 1E

This is related to the parameters IFHOcauseCPICHEcNo andGSMcauseCPICHEcNo.

. NUMBER OF 1F

This is related to the parameters IFHOcauseCPICHrscp andGSMcauseCPICHrscp.

4. See Planning radio network for more instructions.

Expected outcome




135 (176)



Confidential

R: 135/176

Further information

Figure 20. Hard handover monitoring

Activatereporting

Serviceif needed




1.

2.

3.




5.

ValuesOK

4.

Check the CPICH Ec/No,Values and theproportion of failed HHOsusing OnlineMonitoring tool

Use Case complete!

ValuesNOK






Confidential

R: 136/176

7.8 Quality use cases

7.8.1 Radio connection quality

Purpose

The purpose of this use case is to collect information about the quality(retransmission rate) for different radio connection types, that is, RBs that utiliseretransmission (RLC AM). The radio bearers can have either a shared or adedicated transport channel.


The quality is estimated using RLC PDU gross and net throughput values.

Before you start



RNC RN2.1

BTS WN3.0

AXC n/a

NetAct OSS3.2

SGSN n/a

MSC n/a

MGW n/a

UE n/a


The BLER target parameters are related to this use case.




137 (176)



Confidential

R: 137/176

. RCPM RLC









Summary



Use case name Radio connection quality

RAN releases RAN5


Summary The quality for selected RBs is monitoredand verified with performance statisticsreports on a daily basis.



Radio Bearer Reconfiguration message






Confidential

R: 138/176





- M1017; RCPM RLC

Postconditions The RB quality, that is, the retransmissionrates are known.

Steps







If the KPIs show too low a quality ratio, continue to step 3.

3. Go to planning.

Expected outcome




139 (176)



Confidential

R: 139/176

Further information

Figure 21. Connection quality monitoring

Activatereporting

Serviceif needed




1.

2.

3.




ValuesOK

4.

Go toPlanning Use Cases

Use Case complete!

ValuesNOK





Confidential

R: 140/176

7.9 Radio connection quality use cases

7.9.1 NBAP ATM connection quality monitoring

Purpose

NBAP connections are used in the Iub interface to change the control planeinformation between the RNC and Node B. Both C-NBAP and D-NBAP havetheir own dedicated ATM VC connections.


This use case gives instructions to ensure that there is enough transport capacityavailable and that the (ATM) transport layer does not disturb the performance ofNBAP connections.

Before you start



RNC RN2.1

BTS -

AXC -

NetAct OSS4

SGSN -

MSC -

MGW -

UE -



. M 530 ATM Virtual Channel connection



141 (176)



Confidential

R: 141/176

The alarm 3102 indicates performance problems with NBAP connections, that is,there is not enough capacity to transport all NBAP traffic from the RNC to theBTS.

The range of target values for the following PIs are network-dependent andshould be decided before starting this use case.

Table 72. Target values for Iub NBAP dedicated ATM connections utilisation


Definition Target values

ATM_VCC utilisationingress

M530C0 / (ATMVCC_PCR * measurementperiod length [s])

[%]

ATM_VCC utilisationegress

M530C1 / (ATMVCC_PCR * measurementperiod length [s])

[%]

Summary



Use case name NBAP ATM connection quality monitoring



Summary NBAP connection performance ismonitored to ensure that there is enoughtransport capacity for proper operation.

Reasons to perform the use case A need to ensure the NBAP connectionperformance for certain BTS sites.


-





Confidential

R: 142/176


Limitations and restrictions The ATM VCC traffic measuring providesa 15-minute average throughput.

If the traffic volumes change rapidly, theshort peaks may vary a lot from averagevalue.

The required counters are currently notavailable in real time measurements.



- M 530 ATM Virtual Channelconnection


Steps

1. Find out the ATM VC identifiers (interface ID/VPI/VCI) for the NBAPconnections to be monitored.

2. Compare the measured ATM VCC utilisation ratio to the targetedvalues.

Based on the target values in table Target values for Iub NBAP dedicatedATM connections utilization, compare the measured ATM VCC utilisationratio to the targeted values.

3. Check the measured traffic volumes.

If the measured traffic volumes are within target, there is enough capacityfor the NBAP connections.

If the traffic volume exceeds the target value, inform network planningabout the needed capacity upgrade for ATM VCC capacity. The VCCcapacity increase may require ordering new L1 capacity and thus takesome time to complete.

If configuration changes are needed, repeat the steps from step 2 onwardsafter configuration changes are complete.



143 (176)



Confidential

R: 143/176

Further information

Figure 22. NBAP connection monitoring

NBAP connection monitoring

Compare themeasured ATMVCC utilisation totarget values

Find out the RNC ATMidentifiers for NBAPconnections

Measured valuesare in line withdimensioning

(1)(2) (3)

If traffic volumesare exceedingthe target informplanning

(4)





Confidential

R: 144/176

8 Troubleshooting use cases

8.1 Use cases for troubleshooting services

The services to be troubleshooted are:

. radio resource control (RRC)

. radio access bearer (RAB)

. radio bearer (RB)

The RRC is described in the Uu interface.

The RAB and RB are described in Radio access network in the 3G system.


8.2 Sleeping cell troubleshooting

Purpose

The UTRAN cell is the UTRAN access point defined by 3GPP. This means thatno RAN services can be accessed by a user equipment (UE) without having aconnection to a working UTRAN cell.

The UTRAN cell is defined in the UTRAN Resource Model overview.


The use case is executed whenever needed for a cell that is suspected not to beworking.



145 (176)

Troubleshooting use cases


Confidential

R: 145/176

Before you start



RNC RN1.5

BTS -

AXC -

NetAct OSS3.2

SGSN -

MSC -

MGW -

UE -


There are no parameters affecting the use case.

The performance statistics should be available for at least 24 h period (one weekrecommended) for the following measurements:

. Service Level

Table 75. Related KPIs and counters



M100C0 Updates must be found Usually 60 min

Alarm 7771 WCDMA CELL OUT OF USE must not be active.





Confidential

R: 146/176

Summary


ID RAN_USE_CASE_TROUBLE_001

Use case name -


Summary The sleeping cell searching is based onstate management, active alarms andservice reports information.

Reasons to perform the use case For example, suspected serviceinaccessibility in a distinguished part ofthe network or problems with some high-level KPI values.


. UTRAN access point state change

. Fault detection in the UTRAN accesspoint

. UE tries to access the UTRAN accesspoint

Limitations and restrictions . Limitations related to the accessibilityof data

. Effect of overload and other problemsituations

Preconditions Information Services (state management,alarm list and performance reports) areavailable.

Postconditions The cell is found working, or the cell wasfound not activated and was activated, orthe cell was reset.

Steps

1. Check that the service access point is available.

If not, go to step 5.

2. Check the Active Alarm list.

If alarm 7771 WCDMA CELL OUT OF USE is active, go to step 6.

3. Check the Service Level measurement.



147 (176)



Confidential

R: 147/176

If the counter M1001C0 RRC SETUP ATTEMPT shows no values, go tostep 7.

4. The cell is working and the use case is completed.

5. Activate the cell.

After activating the cell, the use case is completed.

6. If there are active alarms for the cell, check other available use cases.

After that, decide it the cell must be reset or not.

If the cell needs to be reset, go to step 7.

If the cell does not need to be reset, the use case is complete.

7. Reset the cell.

After resetting the cell, the use case is complete.

Expected outcome






Confidential

R: 148/176

Further information

Figure 23. Sleeping cell troubleshooting

8.3 Repetitive alarms troubleshooting

Purpose

In live networks, a large number of short-term or repetitive alarms may begenerated in certain situations. When large amounts of alarms are generated at theRAN-level, it soon becomes difficult for the user to monitor the network statuswith alarms. The number of alarms may also be too high in normal operation, butthe system recovers from minor faults automatically and no user actions areneeded.


The repetitive alarms are found through the Alarm History of the networkelements, where you can distinguish a certain alarm occurring repetitively.

This use case is needed at regular maintenance intervals.

Sleeping Cell Troubleshooting

Cellin use

No activealarms

Fulfilledservicerequests

Service AccessPointOut of use

RelativeActiveAlarmsFound

No servicerequests

Can be solved byan other use case

Needscell reset

Reset Cell byReset function

Check OtherTroubleshooting Use Cases

Check if the active alarmsfor the cell by usingAlarm List informationservice

Check the Service Requestsfor the cell by usingReport informationservice

No sleeping Cell!

Active Cell Use Case complete!

Check the cell status byusing statemanagement informationservice

(1) (2) (3) (4)

(6)

(5) (8)

(7)



149 (176)



Confidential

R: 149/176

Before you start



RNC All

BTS -

AXC -

NetAct -

SGSN -

MSC -

MGW -

UE -


There are no parameters or counters affecting the use case. This use case does notconcern any specific alarms. The procedure that is used to identify and correctrepetitive alarm behavior is generic and can be applied in all cases.

Depending of the network element that is producing the repetitive alarms, thereare different kind of adjustable alarm parameters. Repetitiveness can be affected,for example, by adjusting filtering delays (informing and cancellation delays).The adjustable parameters can be listed and managed with NE local userinterfaces.

Summary



Use case name -






Confidential

R: 150/176


Summary The repetitive alarm analysis is based onalarm history and service reportinformation.

Reasons to perform the use case . Suspected temporary and repetitiveservice inaccessibility in a specificpart of the network or problems withsome high-level KPI values.

. The repetitive alarms affect the totalamount of alarms significantly andproblems must therefore be solved.


A large amount of repetitive alarms in thenetwork but no relation to KPI values.

Limitations and restrictions This use case is valid for normaloperating conditions only.

In case of, for example, ongoingmaintenance tasks, the alarm situationmay be different from normal operation.

Preconditions Information Services (state management,alarm list and performance reports) areavailable.

Postconditions The repetitive alarm behaviour has beencorrected. The alarm is either not visiblein the list of alarms any more or the alarmbehaviour is more stable.

(The alarm stays active until the rootcause has been eliminated.)

Steps

1. Identify the repetitive fault (alarm number) with Alarm HistoryAnalysis.

The alarm is repetitive if it is triggered multiple times a day with identicalidentifying data (alarm number, target object and supplementaryinformation).

2. Check the target of the repetitive alarms.

If alarms indicate clear failures in the target, go to step 5.

3. Check the context of the repetitive fault (time wise), and find out whatwas happening when repetitive fault has occurred.



151 (176)



Confidential

R: 151/176

Some trigger(s) such as other alarms may be the reason for the repetitivefault behavior.

Other alarms and/or object state changes that indicate the root cause for therepetitive fault behavior can be identified.

Go to step 5.

4. Analyse the measurements and KPIs related to the repetitive fault.

If there is consistency in the degradation of measurement and KPI values,see if some external condition (for example, weather) affects the system. Ifsome external cause is identified for the repetitive fault (for example, intransmission), it is out of the scope of this use case.

5. Correct the failures according to instructions given for alarms.

After doing this, the use case is complete.

6. Check the infrastructure (hardware, transmission, and so on).

Analyse the alarms from neighbour NE or equipment that may be causingthe repetitive fault. Perform a diagnosis for the suspected faulty hardware ifneeded.

If alarms or faulty hardware are found, go to step 7.

Otherwise go to step 8.

7. Replace or repair possible defective equipment.

After doing this, the use case is complete.

8. To stabilise alarm behaviour, thresholds for triggering an alarm orfiltering parameters for certain alarm(s) need to be adjusted. Adjustthe fault trigger(s) or alarm parameters according to network elementdocumentation.

If there are large number of very short duration alarms, adjust theinforming delay to filter out these alarms.

If there are short, repetitive alarms from the same fault, adjust thecancellation delay to keep the alarm active and thus stabilise the alarmbehavior.





Confidential

R: 152/176

Expected outcome

The use case is complete. Either the reason for the repetitive fault has beenresolved or the parameters of the repetitive alarm have been adjusted to stabilisethe alarm behavior.

Further information

Figure 24. Repetitive alarms troubleshooting

8.4 Degraded service due to unavailable resourcestroubleshooting

Purpose

The purpose of this use case is to find cases where the unavailability of logical orphysical resources in the RAN network elements cause the level of services tobecome degraded or completely disabled.


1.2 Repetive alarms troubleshooting

Adjust alarmparameters tostabilize alarmbehavior

Check infrastructureMeasurement/KPIanalysis for externalcauses for the failure

Check the context ofrepetive faultsituation

Check the target ofthe repetive alarm

Identification ofrepetive alarm

Replace or repairdefective equipment

Use Case complete!Correct failuresshown via alarms

Cause found accordingto alarm instructions

Other alarmsidentified

External causefound

Faulty HW found

(1) (2) (3) (4) (6) (8)

(9)

(7)

(5)



153 (176)



Confidential

R: 153/176

The main purpose of this use case is to find out the availability of the UTRANcell or the availability of services/critical resources (radio resource control (RRC),radio access bearer (RAB) and radio bearer (RB)) in the cell area. The UTRANcell is the UTRAN access point defined by 3GPP. This means that no RANservices can be accessed by a user equipment (UE) without having a connectionto a working UTRAN cell.

This use case is executed for a cell that is not in working state or does not work inthe appropriate level according to KPI values. The operating level in this use caseis either UTRAN cell, WCDMA BTS or RNC.

Before you start

Note

This use case is performed in an iterative manner. Start from the first step andrepeat the scenario until the reason for the service degrading has been found andcorrected.



RNC RN2.1

BTS -

AXC -

NetAct OSS4

SGSN -

MSC -

MGW -

UE -

Related parameters, statistics and alarms:

The performance statistics should be available at least for 24 hours (one weekrecommended).





Confidential

R: 154/176


Relatedcounters/KPIs

KPI name Recommendedvalues

Monitoringinterval

RAN_KPI_0001A RRC AccessibilityRates

See Targets forWCDMA RAN keyperformanceindicators

Usually 60 min

RAN_KPI_0018 WCELL Availability See Targets forWCDMA RAN keyperformanceindicators

Usually 60 min

RAN_KPI_0036 AAL2 AccessibilityRates


Usually 60 min

RAN_KPI_0038 HSDPAAccessibility Rates


Usually 60 min

Table 81. Alarms related to transmission and connectivity

Alarm Issued by Affected area

2499 CONTROLCHANNEL FAILURE

RNC Single BTS

2900 INCOMING SIGNALMISSING

RNC One or more BTS sites

2909 AIS RECEIVED RNC One or more BTS sites

3100 SIGNALLING LINKOUT OF SERVICE

RNC Iu interface, whole RNC

3101 INTERNALFAILURE IN SAALSTACK


3117 FAILURE IN SAALUNI SIGNALLING LINKACTIVATION

RNC Single BTS



155 (176)



Confidential

R: 155/176

Table 81. Alarms related to transmission and connectivity (cont.)


3313 IU INTERFACESIGNALLING FAILURE


3314 CORE NETWORKSERVICEINTERRUPTION


Table 82. Failures in functional entities (RNC functional units)


1001 UNIT RESTARTED RNC Whole RNC

1010 NO RESPONSE TOUNIT SUPERVISIONMESSAGE

RNC Whole RNC

2692 INCORRECTWORKING STATE

RNC Whole RNC

Table 83. Alarms issued by the BTS


7650 BASE STATIONFAULTY

BTS Single BTS

7651 BASE STATIONOPERATIONDEGRADED

BTS Single BTS

7652 BASE STATIONNOTIFICATION

BTS Single BTS





Confidential

R: 156/176

Table 84. Radio network operation and maintenance


7761 RNW O&MSCENARIO FAILURE

RNC Single BTS or UTRAN cell

7771 WCDMA CELL OUTOF USE

RNC Single UTRAN cell

7772 PHYSICALSHARED CHANNELCONFIGURATION

RNC Single BTS HSDPAservice

Summary



Use case name Degraded service because of unavailableresources


Summary The service/critical resourcesunavailability analysis is based on statemanagement, alarms and service reportsinformation.

Reasons to perform the use case Suspected service/critical resourcesunavailability or low KPI values in certainpart of the network. The state of themanaged object is not working.



. fault detection in the UTRAN accesspoint

. The UE tries to access the UTRANAccess point.

Limitations and restrictions -

Preconditions Information services (state management,alarm list and performance reports) areavailable.



157 (176)



Confidential

R: 157/176


Postconditions The service level has been restored tonormal level. The reason for theunavailability of resources has beencorrected.

Steps

1. Check that the service access point is available.

If the service access point is not available, go to step 2.

2. Activate the cell and go to step 10.

3. Check the Active Alarm list.

Check if there are active alarms for the radio network objects (WBTS,WCEL) that are in the affected area.

If there are active alarms, go to step 4.

If there are no active alarms, go to step 6.

4. Check alarms targeted to WBTS object for possible HW failures inBTS.

Check both active alarms and alarm history.

If a failure indication is found from active alarms or alarm history, correctthe situation using the instructions given for each alarm.

5. Check alarms targeted to WCEL objects for possible failures due toresource unavailability or configuration.

Correct the alarms according to the given instructions. After making thecorrections, the use case is complete.

6. Check the alarm history for failures that have occurred when KPIvalues indicated the service degradation.

Search the alarms from the history according to the time when the servicedegradation was observed.

If the failure was only occasional, the use case is complete.





Confidential

R: 158/176

If the failure is of repetitive nature, proceed according to Repetitive alarmstroubleshooting.

7. Analyze the transmission network status between network elementsaccording to active alarms.

Iu interface failures affect a large area of radio network, whereas individualIub link failures affect a single BTS. The problems in transmission can beseen from RNC and BTS alarms. If there are problems such as broken linksin the radio network objects, refer to the list of transmission andconnectivity alarms listed in section Related parameters, statistics andalarms.

Also check the alarms related to AXC and other transmission equipment atRAN-level in the affected area.

Correct the possible failures according to alarm instructions. After makingthe corrections, the use case is complete.

8. Analyse the status of RNC functional units that are handling the dataflow towards the radio network objects in the affected area.

Check at least the signalling unit (ICSU) that is handling the signallingtowards certain BTS (seen from the connection configuration object in theRNC) and exchange terminals that handle the data transfer of certain ATMlinks. The correct exchange terminals can be found by checking whichATM interfaces are mapped to which exchange terminal units (forexample, via IMA groups).

If the status of these functional units is incorrect (that is, units in incorrectworking states), correct the situation according to instructions given forpossible alarms or run a unit diagnosis and replace possible faultyhardware.

Then the use case is complete.

9. Check the configuration in the RNC for the service.

Check that the transmission capacity configured in the RNC for a BTS iscorrect. If there is a configuration error, fix the configuration to completethe use case, or go to step 10 if the configuration change requires a cell orBTS reset.

10. Reset the cell or BTS using the reset function.



159 (176)



Confidential

R: 159/176

Expected outcome


Further information

Figure 25. Degraded service due to unavailable resources troubleshooting

8.5 Coverage verification troubleshooting

Purpose

Radio coverage has been planned according to:

. coverage regions requirements

. area type information

. propagation conditions

1.3 Degraded service due to unavailable resources troubleshooting

(1) (3)

(4)

(6)

(8)

(9)

(7)

(5)

Cellactive

Noactivealarms

Norepetitivealarms

Cell is not active

If resetrequired

Use Case complete!

Trensmission OK

Units OK

Alarms found

Check the active alarms forWBTS and WCEL objects

using list of alarmsinformation service

Check cell status byusing statemanagement

information service

Check alarm historyAnalyze transmission

status

Check and correctBTS faults accordingto alarm instructions

Check and correctWCEL alarms

according to alarminstructions

Activate cellReset Cell or BTS by

reset functionCheckconfigurationin RNC and BTS

See "Reducingrepetive faults" use

case

Analyze RNCfunctional units

(10)





Confidential

R: 160/176

The coverage verification use case verifies the actual coverage of (a part of)RAN. To verify actual coverage against the plan, Nokia tools offers:

. KPIs, and counters and alarms to detect and analyse problems caused bydeviations from planned coverage.

. subscriber and equipment trace

. NetAct Optimizer gives methods to visualise and tackle problems.

. NetAct Service Quality Monitoring offers tools to visualise and analyseproblems from a service point of view. This is mainly used when analysingfault cases, for example, how a certain fault in node B affects a certainservice.


Before you start



RNC RN1.5

BTS -

AXC -

NetAct OSS3.2

SGSN -

MSC -

MGW -

UE -

Related network performance parameters, statistics and alarms

Cell parameters:



161 (176)



Confidential

R: 161/176

. Antenna Coordinates

. Antenna Bearing

. Repeater exists

Radio link-specific parameters:

. Maximum DL TX Power level

. Initial SIR Target

. Minimum value of the SIR Target

. Maximum value of the SIR Target

Bearer-specific parameters for each dedicated channel:

. Initial planned Eb/No target

. BLER target (for low quality bearers)

The performance statistics should be available for at least 24 hours (one weekrecommended). The following measurements are needed:

. Service Level

. Subscriber Trace Basic report


Related KPIsand counters

KPI/countername

Recommendedvalues

Monitoringinterval

KPIs

RAN_KPI_0001A RRC Setup andAccess CompleteRatio from enduser perspective[%].

According to RNWplan

RAN_KPI_0004 RAB Setup andAccess CompleteRatio for NRTService fromNetworkperspective [%]






Confidential

R: 162/176

Table 87. Related KPIs and counters (cont.)

Related KPIsand counters

KPI/countername

Recommendedvalues

Monitoringinterval

RAN_KPI_0005 RRC Drop Ratiofrom networkperspective [%]


RAN_KPI_0005A RRC Drop Ratiofrom networkperspective [%]


Counters

M1800C123 Power Class

M1800C132 Mobile�s capabilityto support GSM

true

M1800C133 Mobile�s capabilityto support GSMMulticarriertechnology (CDMA2000)

true

M1800C222 Max DLtransmissionpower level

Match with RNWPlan

M1801C152 UE Tx power


7650 � 7655 Check site specific alarm status.

Summary



Use case name Checking RAN coverage




163 (176)



Confidential

R: 163/176


Summary Matching RAN coverage verification withthe RNW plan is based on testing duringthe RAN roll-out phase and a comparisonof RAN planning and KPI values frommeasurements.

Active alarms and service reports mayalso be studied.

Reasons to perform the use case . RNW plan roll-out. Suspected service inaccesibility in adistinguished part of the network orproblems with some high-level KPIvalues

. subscriber complaints

. RNW plan update and networkreconfiguration


The user equipment (UE) can not accessthe UTRAN access point.

Limitations and restrictions There are limitations how many UEs cansimultaneously be traced.

Some KPIs and counters require optionalfeatures to be activated.

Preconditions . Information services available (Trace,CM and PM information services)

. RNW planning data is available.

. Target coverage area is defined.

. The Subscriber and Equipment Tracefeature (part of application software) isavailable

Postconditions The coverage has been verified within adefined area to match the network plan.

A reason for a customer complaint ofRAN coverage has been found.

Steps

1. In case of a subscriber complaint, do the following:

. Activate Subscriber Trace for the subscriber in question.

. Check the counters which indicate that the reason for the weakcoverage is caused by the mobile phone.

2. Check that all service access points in the area are available.





Confidential

R: 164/176

If the service access points are not available, proceed to step 5.

3. Check that possible radio repeaters are available.

4. Check that all the cell and site configuration parameters are accordingto the radio network plan.

Check the following information:

. Location plan of node Bs and radio repeaters

. Antenna directions

. Cell structure for sectoring

. Mast heights

. TX power levels in cell and possible radio repeaters

. Radio channel structure

. Other configuration parameters

5. Check possible Sleeping cell verification use case.

6. End case.



165 (176)



Confidential

R: 165/176

Further information

Figure 26. Coverage verification troubleshooting

1.4 Coverage Verification troubleshooting

Check ServiceAccesspointsin target area

SubscriberComplaints ofcoverage

ActiveSubscriberTrace

Check possibleRadio Repeaters

Compare celland siteParameters withRNW Plan

CheckMobilecounters

Execute SleepingCell Use case

Trouble withinmobile

End Case





Confidential

R: 166/176

8.6 RAN quality troubleshooting

Purpose

The operating level for the use case needs to be clearly visible (for example, cell,RNC, ATM VCC). In practice, the case is always started from the RNC layer andcontinued to a lower layer if needed. The PM tools may change while switchingbetween layers.

The quality of RAN becomes more important when the number of subscribersincreases.

In WCDMA, different services have different quality requirements regarding biterror ratio and frame error ratio. Therefore, services have different receiversignal-to-interference ratio requirements. Consequently, the coverage depends onthe services used in cel.


In this use case, quality refers to the quality of radio access and the quality ofmobility.

Before you start



RNC RN1.5

BTS -

AXC -

NetAct OSS3.2

SGSN -

MSC -

MGW -

UE -




167 (176)



Confidential

R: 167/176



KPI Name Recommendedvalues

Monitoringinterval

KPIs

RAN_KPI_0001 RRC Setup andAccess CompleteRatio from thenetwork point ofview (%).

See Targets forWCDMA RAN keyperformanceindicators.

RAN_KPI_0002 RAB Setup andAccess CompleteRatio, Voice (%).


RAN_KPI_0003 RAB Setup andAccess CompleteRatio, RT ServiceOther Than Voice(%).


RAN_KPI_0004 RAB Setup andAccess CompleteRatio for NRTService fromNetworkperspective [%]


RAN_KPI_0005 RRC Drop Ratiofrom networkperspective [%]


RAN_KPI_0006 RAB Drop Ratio,AMR Voice fromnetworkperspective


RAN_KPI_0007 RAB Drop Ratio,RT Servicesexcluding voice


RAN_KPI_0008 RAB Drop Ratio,NRT Services fromnetworkperspective






Confidential

R: 168/176

Table 90. Related KPIs and counters (cont.)


KPI Name Recommendedvalues

Monitoringinterval

RAN_KPI_0009 Average UplinkLoad [dBm]


RAN_KPI_0010 Average DownlinkLoad [dBm]


RAN_KPI_0018 Cell Availability See Targets forWCDMA RAN keyperformanceindicators.

RAN_KPI_0020 Soft HandoverSuccess Ratio [%]


RAN_KPI_0021 Intra System HardHandover SuccessRatio


RAN_KPI_0022 Inter System HardHandover SuccessRatio


RAN_KPI_0034/0040

Average NRT DCHDL Throughput[kbit/s]


RAN_KPI_0044 HSDPA MAC-hsNet Throughput


Counters

Subsciber Tracecounters

Counters forconnection quality,service class

According toplanned values



169 (176)



Confidential

R: 169/176

Summary



Use case name Checking RAN Quality

RAN releases -

Summary RAN quality verification is based ontesting during the RAN roll-out phase anda comparison of RAN planning data andKPIs from measurements.

Active alarms and service reports mayalso be studied.

Reasons to perform the use case . Service quality decrease in adistinguished part of the network.

. Subscriber complaint

. Network reconfiguration

. New service launch



. Fault detection in the UTRAN accesspoint

. UE tries to access the UTRAN accesspoint

Limitations and restrictions Some KPIs may need the activation ofapplication software.

Preconditions . RAN planning data is available. Target network area and a qualitylevel have been defined

Postconditions . The quality status of (a part of) RAN isavailable.

. A reason is found for the customerquality complaint.

Steps

1. In case of a subscriber complaint, do the following:





Confidential

R: 170/176

. Check the subscriber service agreement and respectivemeasurements.

. Activate the Subscriber and Equipment Trace to get the necessarydedicated reports of counters.

2. Check RAN Quality KPIs.

3. If a deviation from the planned quality exists, do the following:

. Check the RAN Coverage verification use case (bad quality may beresult of some coverage area problem).

. Check RAN load in target area, NW.

. Check handover KPIs and counters.

Expected outcome




171 (176)



Confidential

R: 171/176

Further information

Figure 27. RAN quality troubleshooting

RAN quality Troubleshooting

Check RANquality KPI's

SubscriberComplaints ofcoverage

ActiveSubscriberTrace

In case of a deviationfrom planned quality

CheckRelevant counters,Compare withsubscriber agreement

Trouble withinmobile

End Case

Eexecute coverageverification use caseCheck RAN load intarget areaCheck handovercounters





Confidential

R: 172/176

Related Topics

Optimising and expanding WCDMA RAN

Instructions

Measuring WCDMA RAN

Dimensioning WCDMA RAN

Planning radio network

Descriptions

Nokia's services for operators

Reference

Key performance indicators

Principles of optimising GSM/WCDMA interworking

Instructions

Planning GSM/WCDMA interworking

Reference

Interdependencies of telecom features

Interdependencies of performance management features



173 (176)

Related Topics


Confidential

R: 173/176


Nokia NetAct Framework

Nokia element management tools

Online monitoring enhancements

Measuring WCDMA RAN

Troubleshooting a radio access network

Instructions

Troubleshooting WCDMA RAN

Tracing and correcting faults in WCDMA RAN

Checklist for proactive maintenance


Instructions




Instructions






Confidential

R: 174/176

Measuring WCDMA RAN

Key performance indicators

Transport technologies

Planning parameters for radio network

Interdependencies of perfomance management features

UTRAN Resource Model overview

UTRAN Information Services overview


Monitor

Checklist for daily maintenance routines

Checklist for weekly maintenance routines

Checklist for biannual maintenance routines





Monitor







175 (176)

Related Topics


Confidential

R: 175/176




Monitor








Monitor











Confidential

R: 176/176

3G Optmising, Mainitaining, Troubleshooting

Documents

Transcript of 3G Optmising, Mainitaining, Troubleshooting