troubleshooting wcdma ran

8/13/2019 Troubleshooting WCDMA RAN

http://slidepdf.com/reader/full/troubleshooting-wcdma-ran 1/43

Troubleshooting WCDMA RAN

DN70119433Issue 1-0 en draft

# Nokia Corporation 1 (43)



The information in this document is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This document is not an officialcustomer document and Nokia Networks does not take responsibility for any errors or omissionsin this document. No part of it may be reproduced or transmitted in any form or means without

the prior written permission of Nokia Networks. The document has been prepared to be used byprofessional and properly trained personnel, and the customer assumes full responsibility whenusing it. Nokia Networks welcomes customer comments as part of the process of continuousdevelopment and improvement of the documentation.

The information or statements given in this document concerning the suitability, capacity, or performance 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 considered protected by copyright according tothe applicable laws.

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

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

2 (43) # Nokia Corporation DN70119433Issue 1-0 en draft




Contents

Contents 3

1 Documentation changes in Troubleshooting WCDMA RAN 5

2 Managing faults in WCDMA RAN 72.1 Troubleshooting a radio access network 72.2 Troubleshooting WCDMA RAN 112.3 Tracing and correcting faults in WCDMA RAN 14

3 Troubleshooting use cases 173.1 Use cases for troubleshooting services 173.2 Sleeping cell troubleshooting 173.3 Repetitive alarms troubleshooting 21

3.4 Degraded service due to unavailable resources troubleshooting 253.5 Coverage verification troubleshooting 313.6 RAN quality troubleshooting 37

Related Topics 43



Contents



1 Documentation changes inTroubleshooting WCDMA RAN

This is a first (draft) issue of this document.

The information in this document was earlier included in the Optimising,

Maintaining and Troubleshooting WCDMA RAN document that has been split into five separate documents.

There have been no content changes in the information included in this document between releases RAS05 and RAS05.1 trial.



Documentation changes in Troubleshooting WCDMA RAN



2 Managing faults in WCDMA RAN

2.1 Troubleshooting a radio access network

Purpose

Troubleshooting a radio access network is sometimes complicated due to the fact that 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 troubleshoot network 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 not perform 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 to

be 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 maintenance personnel 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 cover various disaster scenarios and disaster recovery procedures for personnel.The operation and maintenance personnel should also be able to contact the 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



Managing faults in WCDMA RAN



An escalation plan offers contact lists of internal and external support personnel 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 network element. 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 of the system. Performance monitoring can help you to detect very low rate or intermittent problems and possible degradation of some part of the system.The performance monitoring parameters for network elements of different kinds 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. Start filling in the network element diary already when the network element is being 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 network element

. safecopying

. operational failures

. any other relevant information





A network element diary can provide useful information on the system's performance in the past and hints on what might cause the current problems.

. 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 the problem 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 can

carry 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 for expert help or apply an emergency plan immediately.

2. Identify the problem and describe it clearly.

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 is

in useFor 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 the

symptoms).. Any other relevant information, for example, log writings, message

monitorings. All data may be valuable; take the alarm history fromthe day the fault appeared and as much log writings and other information 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 problems

active at the same time. Study whether the symptoms relate to each other or not. 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 that are 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 for the 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.





2.2 Troubleshooting WCDMA RAN

Purpose

In WCDMA RAN both RNC and BTS attempt to keep all their units and network connections 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 network database.

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.






Further information

Sometimes a configuration fault may not generate any alarms, andtherefore it is important to examine all information related to the fault situation. Generally speaking, solving configuration faults requires profound 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 must be 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 - out of use) state and has a FLTY flag indicating the fault. The unit

generates alarms as well. b. Change the faulty unit, if necessary.c. Verify the correction by running a diagnostics test for the changed

RNC unit.

5. Manage transport faults.





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 get every network element properly synchronised, concentrate on thisnetwork element and the element giving synchronisation to thisnetwork element. Improper synchronisation will cause transport errors 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, that is, 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 a particular 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 this particular 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 .

Verification

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

2.3 Tracing and correcting faults in WCDMA RAN

Purpose

The following performance management features can be used as tools for troubleshooting 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 for further 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 or radio 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 power requirements 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 your situation.





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

Set trace

Identify&describeproblem

Evaluateconsequences

of the fault

Studysymptoms

Narrow downpossiblecauses

Correctproblem

yes

no

Setperformance

threshold

Datacompared

againstthr. limits

Thresholdexceeded?

Alarmgenerated andsent to NetAct

Do yoususpecta fault?

yes

no

OK

Trace datacollected

Analysetrace data

Is there afault?






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 possible problems 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 .

Or

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 element where the trace was set.

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

The trace data provided by the RNC is automatically transferred to Nokia NetAct 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 .





3 Troubleshooting use cases

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

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

3.2 Sleeping cell troubleshooting

Purpose

The UTRAN cell is the UTRAN access point defined by 3GPP. This means that no 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 .

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

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



Troubleshooting use cases



Before you start

Table 1. Network element software requirements

Network element Release

RNC RN1.5

BTS -

AXC -

NetAct OSS3.2

SGSN -

MSC -

MGW -

UE -

Related network performance parameters, statistics and alarms:

There are no parameters affecting the use case.

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

. Service Level

Table 2. Related KPIs and counters

Related counters/KPIs Recommended values Monitoring interval

M100C0 Updates must be found Usually 60 min

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

Summary

Table 3. Use case information

ID RAN_USE_CASE_TROUBLE_001

Use case name -

RAN releases All RAN releases

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





Table 3. Use case information (cont.)

Reasons to perform the use case For example, suspected service

inaccessibility in a distinguished part of the network or problems with some high-level KPI values.

Triggers for utilised service/resourceinformation

. 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 accessibility of 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, or the 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.

If the counter M1001C0 RRC SETUP ATTEMPT shows no values, go to step7.

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

Use case is complete.

Further information

Figure 2. Sleeping cell troubleshooting

Sleeping Cell Troubleshooting

Reset Cell byReset function

Check Other Troubleshooting

Use Cases

No sleepingCell!

Active Cell Use Casecomplete!

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

(6)

(5) (8)

(7)

Cellin use

Noactivealarms

Fulfilledservice

requests

RelativeActiveAlarmsFound

No servicerequests

Can be solved byan other use case Needs

cell reset

Check the ServiceRequests for the cell

by using Reportinformation service

Check if the activealarms for the cell

by usingAlarm List information

service

Service AccessPoint

Out of use

Check the cell statusby using statemanagement

information service





3.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, but the system recovers from minor faults automatically and no user actions areneeded.


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

This use case is needed at regular maintenance intervals.

Before you start



RNC All

BTS -

AXC -

NetAct -

SGSN -

MSC -

MGW -

UE -

Related network performance parameters, statistics and alarms:

There are no parameters or counters affecting the use case. This use case does not concern any specific alarms. The procedure that is used to identify and correct repetitive 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 user interfaces.

Summary



Use case name -


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 specific partof the network or problems with somehigh-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 alarm

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

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. If some 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 if needed.

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 alarm behavior.

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 3. Repetitive alarms troubleshooting

1.2 Repetive alarms troubleshooting

Adjust alarmparameters to

stabilize alarmbehavior

Checkinfrastructure

Measurement/KPI analysis for

external causesfor the failure

Check thecontext of

repetive faultsituation

Check thetarget of

the repetivealarm

Identification of repetive alarm

Replace or repair defective

equipment

Use Casecomplete!

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)





3.4 Degraded service due to unavailable resourcestroubleshooting

Purpose

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


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.


Network element ReleaseRNC RN2.1

BTS -

AXC -

NetAct OSS4

SGSN -

MSC -






Table 6. Network element software requirements (cont.)


MGW -

UE -

Related parameters, statistics and alarms:

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


Relatedcounters/KPIs

KPI name Recommendedvalues

Monitoringinterval

RAN_KPI_0001A RRC AccessibilityRates

See Targets for WCDMA RAN key performanceindicators

Usually 60 min

RAN_KPI_0018 WCELL Availability See Targets for WCDMA RAN key performanceindicators

Usually 60 min

RAN_KPI_0036 AAL2 AccessibilityRates


Usually 60 min

RAN_KPI_0038 HSDPA Accessibility Rates


Usually 60 min

Table 8. 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





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


3100 SIGNALLING LINKOUT OF SERVICE

RNC Iu interface, whole RNC

3101 INTERNAL FAILUREIN SAAL STACK


3117 FAILURE IN SAALUNI SIGNALLING LINK ACTIVATION

RNC Single BTS

3313 IU INTERFACESIGNALLING FAILURE


3314 CORE NETWORKSERVICE INTERRUPTION


Table 9. 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 10. Alarms issued by the BTS


7650 BASE STATIONFAULTY

BTS Single BTS

7651 BASE STATIONOPERATION DEGRADED

BTS Single BTS

7652 BASE STATIONNOTIFICATION

BTS Single BTS






Table 11. 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 PHYSICAL SHAREDCHANNELCONFIGURATION

RNC Single BTS HSDPA service

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 UTRAN Access point.

Limitations and restrictions -

Preconditions Information services (state management,

alarm list and performance reports) areavailable.

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 in

BTS.

Check both active alarms and alarm history.

If a failure indication is found from active alarms or alarm history, correct the 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.

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 and alarms .

Also check the alarms related to AXC and other transmission equipment at RAN-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 (for example, via IMA groups).

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

hardware.

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 or BTS reset.

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

Expected outcome

The use case is complete.





Further information

Figure 4. Degraded service due to unavailable resources troubleshooting

3.5 Coverage verification troubleshooting

Purpose

Radio coverage has been planned according to:

. coverage regions requirements

. area type information

. propagation conditions

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

1.3 Degraded service due to unavailable resources troubleshooting

(1) (3)

(4)

(6)

(8)

(9)

(7)

(5)

Cellactive

Noactivealarms

Norepetitive

alarms

Cell is not active

If resetrequired

Use Casecomplete!

Trensmission OK

Units OK

Alarms found

Check alarmhistory

Analyzetransmission

status

Check and correctBTS faults accordingto alarm instructions

Check and correctWCEL alarms

according to alarminstructions

Activate cell Reset Cell or BTS

by reset function

Checkconfiguration

in RNC and BTS

See "Reducingrepetive faults" use

case

Analyze RNCfunctional units

(10)

Check cell statusby using statemanagementinformation

service

Check the activealarms for WBTS andWCEL objects using

list of alarmsinformation service






. 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 analyse problems 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:

. 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 week recommended). The following measurements are needed:

. Service Level

. Subscriber Trace Basic report


Related KPIsand counters

KPI/counter name

Recommendedvalues

Monitoringinterval

KPIs

RAN_KPI_0001A RRC Setup and Access CompleteRatio from end user perspective [%].

According to RNWplan

RAN_KPI_0004 RAB Setup and Access CompleteRatio for NRTService fromNetwork perspective[%]


RAN_KPI_0005 RRC Drop Ratiofrom networkperspective [%]


RAN_KPI_0005A RRC Drop Ratiofrom network

perspective [%]


Counters

M1800C123 Power Class

M1800C132 Mobile ’ s capabilityto support GSM

true






Table 14. Related KPIs and counters (cont.)

Related KPIsand counters

KPI/counter name

Recommendedvalues

Monitoringinterval

M1800C133 Mobile ’ s capabilityto support GSMMulticarrier technology (CDMA2000)

true

M1800C222 Max DLtransmission power level

Match with RNWPlan

M1801C152 UE Tx power

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

7650 – 7655 Check site specific alarm status.

Summary



Use case name Checking RAN coverage


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 a

distinguished part of the network or problems 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 can

simultaneously 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 Trace feature (part of application software) isavailable

Postconditions The coverage has been verified within a

defined area to match the network plan. A reason for a customer complaint of RAN 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 weak coverage is caused by the mobile phone.

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

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.

Further information

Figure 5. Coverage verification troubleshooting

1.4 Coverage Verification troubleshooting

Check ServiceAccesspoints

in target area

Subscriber Complaints of

coverage

ActiveSubscriber Trace

Check possibleRadio Repeaters

Compare celland siteParameters withRNW Plan

CheckMobilecounters

Execute SleepingCell Use case

Trouble withinmobile

End Case





3.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 switching between layers.

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

In WCDMA, different services have different quality requirements regarding bit error ratio and frame error ratio. Therefore, services have different receiver

signal-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 of mobility.

Before you start



RNC RN1.5

BTS -

AXC -

NetAct OSS3.2

SGSN -

MSC -

MGW -

UE -

Related network performance parameters, statistics and alarms :








KPI Name Recommendedvalues

Monitoringinterval

KPIs

RAN_KPI_0001 RRC Setup and Access CompleteRatio from thenetwork point of view (%).

See Targets for WCDMA RAN key performance indicators .

RAN_KPI_0002 RAB Setup and Access CompleteRatio, Voice (%).


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


RAN_KPI_0004 RAB Setup and Access CompleteRatio for NRTService fromNetwork perspective[%]


RAN_KPI_0005 RRC Drop Ratio

from networkperspective [%]

See Targets for

WCDMA RAN key performance indicators .

RAN_KPI_0006 RAB Drop Ratio, AMR Voice fromnetwork perspective


RAN_KPI_0007 RAB Drop Ratio,RT Servicesexcluding voice


RAN_KPI_0008 RAB Drop Ratio,

NRT Services fromnetwork perspective

See Targets for

WCDMA RAN key performance indicators .

RAN_KPI_0009 Average UplinkLoad [dBm]






Table 17. Related KPIs and counters (cont.)


KPI Name Recommendedvalues

Monitoringinterval

RAN_KPI_0010 Average DownlinkLoad [dBm]


RAN_KPI_0018 Cell Availability See Targets for WCDMA RAN key performance indicators .

RAN_KPI_0020 Soft Handover Success 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]

See Targets for WCDMA RAN key

performance indicators .

RAN_KPI_0044 HSDPA MAC-hsNet Throughput


Counters

Subsciber Tracecounters

Counters for connection quality,service class

According toplanned values

Summary



Use case name Checking RAN Quality

RAN releases -







Summary RAN quality verification is based on

testing 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

Triggers for utilised service/resource

information


. Fault detection in the UTRAN accesspoint

. UE tries to access the UTRAN accesspoint

Limitations and restrictions Some KPIs may need the activation of application software.

Preconditions . RAN planning data is available. Target network area and a quality level

have been defined

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

. A reason is found for the customer quality complaint.

Steps

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

. 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

Use case is complete.

Further information

Figure 6. RAN quality troubleshooting

RAN quality Troubleshooting

Check RANquality KPI’s

Subscriber Complaints of

coverage

ActiveSubscriber Trace

In case of a deviationfrom planned quality

CheckRelevant counters,Compare withsubscriber agreement

Trouble withinmobile

End Case

Eexecute coverage

verification use caseCheck RAN load intarget areaCheck handover counters






Related Topics

Instructions


Tracing and correcting faults in WCDMA RAN

Checklist for proactive maintenance

Instructions

Troubleshooting a radio access network

Tracing and correcting faults in WCDMA RAN

Instructions


Related Topics

troubleshooting wcdma ran

Documents