nn-20500-033 (9300 product family - performance management) 09.06 preliminary september2008

NN-20500-033

Wireless Service Provider Solutions

W-CDMAAlcatel-Lucent 9300 W-CDMA Product FamilyPerformance ManagementNN-20500-033 09.06/EN Preliminary September 2008

Wireless Service Provider Solutions

W-CDMAAlcatel-Lucent 9300 W-CDMA Product FamilyPerformance Management

Document number: NN-20500-033Document issue: 09.06/ENDocument status: PreliminaryProduct release: OAM06.0Date: September 2008

Copyright © 2002-2008 Alcatel-Lucent, All Rights Reserved

ALCATEL-LUCENT CONFIDENTIAL

UNCONTROLLED COPY: The master of this document is stored on an electronic database and is "writeprotected"; it may be altered only by authorized persons. While copies may be printed, it is notrecommended. Viewing of the master electronically ensures access to the current issue. Any hardcopiestaken must be regarded as uncontrolled copies.

ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property ofAlcatel-Lucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep allinformation contained herein confidential, shall disclose the information only to its employees with a needto know, and shall protect the information from disclosure and dissemination to third parties. Except asexpressly authorized in writing by Alcatel-Lucent, the holder is granted no rights to use the informationcontained herein. If you have received this document in error, please notify the sender and destroy itimmediately.

Alcatel-Lucent, Alcatel, Lucent Technologies and their respective logos are trademarks and service marksof Alcatel-Lucent, Alcatel and Lucent Technologies.

The Alcatel-Lucent 9370 Radio Network Controller and the Alcatel-Lucent Point Of Concentration arebased on Nortel Multiservice Switch products.

All other trademarks are the property of their owners.

PUBLICATION HISTORYSYSTEM RELEASE: OAM06.0

September 2008

Issue 09.06/EN Preliminary

Update after internal review

August 2008

Issue 09.05/EN Draft

Up-issue for DR4

July 2008



May 2008


Update for Pre-DR4

April 2008



January 2008


Update for OAM06.0

SYSTEM RELEASE: OAM05.2

January 2008


Update after documentation reorganization

November 2007

Issue 08.03/EN Standard


Alcatel-Lucent Confidential Publication history i

Copyright © 2002-2008 Alcatel-Lucent Performance Management

September 2007



August 2007


Update for OAM05.2

SYSTEM RELEASE: UMTS 5.1

July 2007

Issue 07.04/EN Standard

Update for OAM 5.1 / UA 5.0 Channel Readiness

March 2007


Editorial update

January 2007



December 2006


Update for OAM 5.1 / UA 5.0

The Publication History information for the outdated releaseshas been deleted.Document creation date: December 2002

Alcatel-Lucent Confidential Publication history ii

NN-20500-033 09.06/EN Preliminary September 2008 Copyright © 2002-2008 Alcatel-Lucent

1 About this publication................................................................................................................................................... 1

2 UMTS Access Network Collection Roadmap...............................................................................................................4

3 New in this release.........................................................................................................................................................5

4 Performance management introduction...................................................................................................................... 6

4.1 Performance management purpose........................................................................................................................... 7

4.2 Performance management applications..................................................................................................................... 9

4.3 Counter observation benefits....................................................................................................................................10

4.4 Call Trace benefits....................................................................................................................................................11

5 Counter and Trace overview....................................................................................................................................... 12

5.1 UTRAN counter overview......................................................................................................................................... 13

5.1.1 Counter system architecture.............................................................................................................................. 14

5.1.2 RNC counter observation data........................................................................................................................... 16

5.1.3 MSS counter observation data........................................................................................................................... 18

5.1.4 Node B counter observation data.......................................................................................................................19

5.2 Call Trace overview.................................................................................................................................................. 20

5.2.1 Call Trace system architecture...........................................................................................................................21

5.2.2 Call Trace data flows..........................................................................................................................................24

6 Counter and Trace activation......................................................................................................................................25

6.1 Counter observation activation................................................................................................................................. 26

6.1.1 RNC observation activation................................................................................................................................27

6.1.2 Node B and microNode B observation activation...............................................................................................31

6.1.3 MSS observation activation................................................................................................................................32

6.2 Trace activation........................................................................................................................................................ 33

6.2.1 Trace session activity......................................................................................................................................... 34

6.2.2 Call trace and Object trace sessions..................................................................................................................35

6.2.3 XDR trace data files........................................................................................................................................... 40

7 Counter and Trace collection and mediation............................................................................................................ 43

7.1 Counter collection and mediation............................................................................................................................. 44

7.1.1 Counter collection...............................................................................................................................................45

7.1.2 Counter mediation.............................................................................................................................................. 46

7.1.3 RNC observation XML files................................................................................................................................ 49

7.1.4 Node B observation XML files............................................................................................................................ 51

7.1.5 XML observation file compression..................................................................................................................... 52

7.1.6 Counter data.......................................................................................................................................................53

7.1.7 Manual collection and mediation of counter files................................................................................................56

Alcatel-Lucent Confidential Table of contents iii


7.2 Trace data collection and mediation......................................................................................................................... 57

7.2.1 Call Trace data collection................................................................................................................................... 58

7.2.2 Call trace data mediation....................................................................................................................................59

8 Operational Alarm on thresholds for access observations..................................................................................... 86

8.1 Overview of Alarm on thresholds ............................................................................................................................87

8.2 Architecture of Alarm on thresholds.........................................................................................................................88

8.3 Syntax of alarm on thresholds................................................................................................................................. 90

8.4 Tools of alarm on threshold..................................................................................................................................... 96

8.5 Hysteresis................................................................................................................................................................98

8.6 Alarm management................................................................................................................................................. 99

9 Access Data Interface (ADI) and Management Data Provider (MDP) applications.............................................. 102

10 Wireless Quality Analyzer (WQA)........................................................................................................................... 103

11 Network Performance Optimizer (NPO)................................................................................................................. 106

12 Radio Frequency Optimizer (RFO)..........................................................................................................................108

13 Call Trace Configuration Wizard application.........................................................................................................109

13.1 The Call Trace configuration Wizard interface.....................................................................................................110

13.2 Using the Call Trace configuration Wizard ......................................................................................................... 112

14 Performance Management procedures..................................................................................................................114

14.1 Retrieving counter files further to a Node B IP address change...........................................................................115

14.2 Configuration of alarm thresholds for access observations.................................................................................. 116

14.2.1 Configuring a threshold definition file............................................................................................................. 117

14.2.2 Checking the syntax of the threshold definition file........................................................................................ 119

14.2.3 Loading the threshold definition file................................................................................................................120

14.2.4 Determining the identifier of a RNC................................................................................................................121

14.2.5 Determining the identifier of a Node B........................................................................................................... 122

14.3 Configuration of Call Trace sessions.................................................................................................................... 123

14.3.1 Launching the Call Trace Configuration Wizard.............................................................................................124

14.3.2 Creating one or more Access sessions on one RNC..................................................................................... 126

14.3.3 Creating an Access session on multiple RNCs.............................................................................................. 132

14.3.4 Creating a geographical session.................................................................................................................... 139

14.3.5 Creating a Neighbouring session................................................................................................................... 145

14.3.6 Creating a cell session................................................................................................................................... 152

14.3.7 Creating an IuCS, an IuPS, an IuR or an IuBC session................................................................................. 158

14.3.8 Deleting trace sessions.................................................................................................................................. 165

14.3.9 Creating a trace session template..................................................................................................................169

Alcatel-Lucent Confidential Table of contents iv


14.3.10 Deleting a trace session template................................................................................................................ 174

14.3.11 Listing and printing a call trace session report............................................................................................. 178

14.3.12 Listing and printing a trace session template report.....................................................................................181

15 Appendix: DTD 32.401.02........................................................................................................................................ 184

Alcatel-Lucent Confidential Table of contents v


Figure 1 - Functional view of the counter observation domain.............................................................. ............. ......... 14

Figure 2 - Architecture of the trace application................................................................................................... ......... 23

Figure 3 - Counter collection and mediation ...................................................................................................... ......... 46

Figure 4 - DTD versioning..................................................................................................................... ............. ......... 55

Figure 5 - Call trace data mediation...................................................................................................... ............. ......... 57

Figure 6 - Call trace DTD-first part........................................................................................................ ............. ......... 64

Figure 7 - Call trace DTD-second part.................................................................................................. ............. ......... 65

Figure 8 - Call trace DTD-third part....................................................................................................... ............. ......... 66

Figure 9 - Object trace DTD-part 1/4..................................................................................................... ............. ......... 66

Figure 10 - Object trace DTD-part 2/4................................................................................................... ............. ......... 67



Figure 13 - Management data DTD (Part 1/3).................................................................................................... ......... 69



Figure 16 - Threshold syntax DTD........................................................................................................ ............. ......... 91

Figure 17 - Example of alarm threshold syntax..................................................................................... ............. ......... 95

Figure 18 - Example of a Call Trace Wizard window ........................................................................... ............. ....... 110

Figure 19 - Call Trace Wizard for UMTS command.............................................................................. ............. ....... 124

Figure 20 - Call Trace Configuration Wizard main window................................................................... ............. ....... 125

Figure 21 - Example of window of multiple access session on a single RNC....................................... ............. ....... 127

Figure 22 - Parameter window of access session creation on a single RNC........................................ ............. ....... 128

Figure 23 - Summary window of an access session creation on a single RNC.................................... ............. ....... 130

Figure 24 - Result window of access session creation on a single RNC.............................................. ............. ....... 131

Figure 25 - Create single Access Session window .............................................................................. ............. ....... 133

Figure 26 - Parameter window of single access session creation on multiple RNCs ........................................ ....... 134

Figure 27 - Summary window of access session creation on multiple RNCs....................................... ............. ....... 136

Figure 28 - Result window of access session creation on multiple RNCs.......................................................... ....... 137

Figure 29 - Geographical session creation vindow............................................................................... ............. ....... 139

Figure 30 - RNC an NBAP parameter window of geographical session creation................................. ............. ....... 140

Figure 31 - Parameter window of geographical session creation....................................................................... ....... 141

Figure 32 - Summary window of geographical session creation........................................................... ............. ....... 143

Figure 33 - Result window of geographical session creation................................................................ ............. ....... 144

Figure 34 - Neighbouring creation session window............................................................................................ ....... 145

Figure 35 - ............................................................................................................................................ ............. ....... 146

Figure 36 - Parameter window of neighbouring session creation......................................................... ............. ....... 147

Figure 37 - Summary window of neighbouring session creation........................................................... ............. ....... 149

Figure 38 - Result window of neighbouring session creation................................................................ ............. ....... 150

Figure 39 - Cell session creation window.............................................................................................. ............. ....... 152

Figure 40 - Parametr wondow of cell session creation ...................................................................................... ....... 153

Figure 41 - Summary window of cell session creation.......................................................................... ............. ....... 155

Alcatel-Lucent Confidential List of figures vi


Figure 42 - Result window of cell session creation............................................................................... ............. ....... 156

Figure 43 - IuCS session creation window............................................................................................ ............. ....... 159

Figure 44 - Summary window of IuCS session creation..................................................................................... ....... 161

Figure 45 - Result window of IuCS session creation............................................................................. ............. ....... 163

Figure 46 - Trace session deletion window........................................................................................... ............. ....... 166

Figure 47 - Example of window of deletion confirmation....................................................................... ............. ....... 167

Figure 48 - Example of wizard status window....................................................................................... ............. ....... 167

Figure 49 - Result window of session deletion...................................................................................... ............. ....... 168

Figure 50 - Template session creation window..................................................................................... ............. ....... 169

Figure 51 - Summary of trace template creation................................................................................... ............. ....... 171

Figure 52 - Example of wizard status for template session creation..................................................... ............. ....... 172

Figure 53 - Result window of session template creation....................................................................... ............. ....... 173

Figure 54 - Deletion trace template window.......................................................................................... ............. ....... 174

Figure 55 - Window of template deletion confirmation.......................................................................... ............. ....... 175

Figure 56 - Wizard status window in template deletion......................................................................... ............. ....... 176

Figure 57 - Result window of session template deletion....................................................................... ............. ....... 177

Figure 58 - Window of session selection for printing............................................................................. ............. ....... 179

Figure 59 - Example of trace session report......................................................................................... ............. ....... 180

Figure 60 - Window of template selection for printing........................................................................... ............. ....... 182

Figure 61 - Example of template report................................................................................................. ............. ....... 183

Figure 62 - DTD 32.401.02 for observations......................................................................................... ............. ....... 185

Figure 63 - DTD versioning................................................................................................................... ............. ....... 188

Alcatel-Lucent Confidential List of figures vii


Table 1 - 3GPP 32.108 contribution tags.............................................................................................. ............. ......... 71

Table 2 - Tags specific to object traces................................................................................................. ............. ......... 75

Table 3 - List of Cause values for the <cause type = estabcause> (vendor specific)........................... ............. ......... 77

Table 4 - List of Cause values for the <cause type = RRCRelCause> (3GPP).................................... ............. ......... 78

Table 5 - List of Cause values for the <cause type = IuRelCause> (3GPP)......................................... ............. ......... 78

Table 6 - List of values for the <IE> attibute....................................................................................................... ......... 81

Table 7 - Mapping of object type names on object class names........................................................................ ......... 92

Table 8 - Mapping of object type names on object relative identifiers................................................................ ......... 93

Table 9 - WQA for WNMS documentation............................................................................................ ............. ....... 104

Alcatel-Lucent Confidential List of tables viii


1 About this publicationThe purpose of this publication is to provide information about the performance management of theUMTS Access Network, to describe the aim of this function, the involved applications and theassociated data collected.

It also describes how to launch the applications.

The Performance Management function in the OAM06.0 release is fully described in thisdocument.

However complementary information about detailed description (for example counters, 3GPPinterfaces) is given in the document lists of the Prerequisites and Related publications sections.

Full documentation of the applications involved in the Performance Management are listed in thereferred sections:

• NPO Documentation

• WQA Documentation

• RFO Documentation

Applicability

This publication applies to the OAM06.0 system release

Audience

This publication is intended for the personnel in charge of the Performance Management for theUMTS Access Network.

Prerequisites

Readers must be familiar with the following publications:

• Alcatel-Lucent 9353 Management System documentation

System Overview (NN-20500-031)

• Alcatel-Lucent 9300 W-CDMA Product Family documentation

Counters Reference Guide (NN-20500-028) composed of the following three volumes:

— Counters Reference Guide for RNC

— Counters Reference Guide for Node B

— Counters Reference Guide for MSS

Parameters Reference Guide (NN-20500-027) composed of the following volumes:

— Parameters Reference Guide: RAN Model

Alcatel-Lucent Confidential 1


— Parameters Reference Guide for C-Node

— Parameters Reference Guide for I-Node

— Parameters Reference Guide for Macro Node B and Compact Node B

— Parameters Reference Guide for Micro Node B and Pico Node B

— Parameters Reference Guide for POC 7K

— Parameters Dictionary for POC 15K

— Parameters Reference Guide for OAM

Related publications• Alcatel-Lucent 9313 Micro Node B and 9314 Pico Node B documentation

Operation and Maintenance Manual (NN-20500-058)

• Alcatel-Lucent 9313 Micro Node B and 9314 Pico Node B

Performance Measurement Manual (NN-20500-123)

• Alcatel-Lucent 9353 Management System documentation

Commands Reference Guide (WICL) (NN-20500-030)

User Guide (NN-20500-032)

How this publication is organized• Performance Management fundamentals:

— Performance management introduction

— Counter and Trace overview

— Counter and Trace activation

— Counter and Trace collection and mediation

— Alarm thresholds for access observations

— Access Data Interface (ADI) and Management Data Provider (MDP) applications

— WQA (Wireless Quality Analyzis)

— NPO (Network Performance Optimizer)

— Radio Frequency Optimizer (RFO)

— Call Trace Configuration Wizard application

• Performance Management procedures:

— Retrieving counter files further to a Node B IP address change

— Configuration of alarm thresholds for access observations

— Configuration of Call Trace sessions

• Appendix: DTD 32.401.02



Vocabulary conventions

For a definition of the UMTS terms used in this document, see Alcatel-Lucent 9300 W-CDMAProduct Family - Terminology (NN-20500-002).

The specific acronyms used in this publication include the following:

BDF Bulk Data Format

DHO Diversity HandOver

DTD Document Type Definition

OT Object Trace

XDR eXternal Data Representation standard

XML eXtensible Markup Language

NPO Network Performance Optimizer

WQA Wireless Quality Analyzer

RFO Radio Frequency Analyzer

GP Granularity Period

MO Managed Object

The specific terms used in this publication include the following:

GranularityPeriod (GP)

The time between two successive measurement results gatherings in the NE.

Managed Ob-ject (MO)

Component.

Centraltimestamp

Timestamp provided by the OMU card of the RNC

Proctimestamp

Timestamp provided by the TMU cards of the RNC

Session The session can be Observation or Trace. It identifies a data collection reques-ted by the user.

Tracekey The unique identifier of a mobile call

In the rest of this document and unless differently stated, the term RNC refers to RNC Cplanepart (also named C-Node) and the term MSS Platform refers both to RNC Uplane part (alsonamed I-Node) and POC.



2 UMTS Access Network Collection RoadmapFor a collection roadmap, see Alcatel-Lucent 9300 W-CDMA Product Family - DocumentCollection Overview and Update Summary (NN-20500-050).



3 New in this releaseThis section details what is new in Alcatel-Lucent 9300 W-CDMA Product Family - PerformanceManagement (NN-20500-033), for the OAM06.0 system release.

Features• FRS 33421 - Co-resident FCPS Main Servers

• FRS 33467 - OAM support of 15 mn granularity on Node B

• FRS 33602 - Node B counters at 15 mn

• FRS 32525 - UA06 UTRAN call trace developments

• FRS 34043 - NPO Kernel, HW and system administration functions for OAM6.0

• FRS 34269 - Per call trace analysis

• FRS 32000 - WQA: UTRAN CTx Analysis

• FRS 33046 - WQA : Call Failure Analysis module

• FRS 33562 - OAM support of UA6 counters enhancement

• FRS 34436 - RNC Counter volume control

• FRS 34266 - RNC Counter list management

• FRS 33282 - Manual collection and mediation of counter observation files

• FRS 34045 - Diagnosis option and Pre-Defined Scenarii in NPO for WDCMA

• FRS 26083 - Operational Alarm on thresholds Integration in Back up and restore and OAMupgrade processes

Other changes

New NPO document references.



4 Performance management introductionThe purpose of this chapter is to introduce the Performance Management concepts for the UMTSNetwork Access.

It is split into:

• Performance management purpose

• Performance management applications

• Counter observation benefits

• Call Trace benefits



4.1 Performance management purposeThis section describes the aim and the advantages of the Performance Management function.

The purpose of any Performance Management activity is to collect data that can be used to verify thephysical and logical configuration of the network and to locate potential problems as early aspossible. This leads to call drops reduction, better quality of service (QoS) and traffic increase.

The Performance Management portfolio focuses on:

• Access Network Performance monitoring

• Access Network Optimization

• Access Network Troubleshooting

Performance Management is based on data collection, then post-processing of this collected data.

The Performance Management data are:

• Counter observation data

• Call trace data

Counter observation data

The observation counters, collected from different NEs, are used to calculate the number ofoccurrences of an event.

The access network observation counters handled by the ADI application for the OAM06.0 releaseare:

• C-Node application counters

• I-Node application counters

• I-Node platform counters

• NodeB equipment counters

Counters are organized in families. A family is a collection of counters involved in performing thesame telecom function or service.

The access network counters are divided into the 3 following families:

• RNC counter families

• MSS counter families

• NodeB counter families

For further definitions of observation counters, please refer to the 3GPP TS 32.104 specifications.

Counters are defined in the following dedicated counter dictionaries: Alcatel-Lucent 9300 W-CDMAProduct Family - Counters Reference Guide (NN-20500-028).



Note that both counter and measurement wordings are equivalent.

Call trace data

Call Trace is a very powerful feature that allows the collection of very detailed information on one ormore mobiles and on one or more cells. It can assist with the optimization of the radio engineeringand the network engineering of the UTRAN. This feature provides improved capacity, dimensioningand traffic management of the networks.



4.2 Performance management applicationsThis section lists the main applications involved in Performance Management.

The access network Performance Management applications are in charge of the following actions:

• uploading the raw data from the Access Network Elements (Node B and RNC)

• mediating the raw data collected into the XML format defined by the OMC

• post-processing this translated data for viewing and creating tables, graph reports, GeographicalInformation System views and call trace analysis.

Data collection and mediation are performed by ADI (Access Data Interface) and MDP (ManagementData Provider).

The counter observation data post-processing is performed by NPO (Network PerformanceOptimizer), performance reporting application based on the internal platform.

The Call Trace data post-processing is performed by :

•WQA (Wireless Quality Analyzer), optional application post-processing the following tracesinformation issued from the Utran networks:

— neighboring call trace (CTn)

— CTx, which, is the whole of several types of Call Trace. In the OAM06 release CTx isAccess Invoked Call Trace (CTb) and Geographic Call Trace (CTg).

• RFO (Radio Frequency Optimizer), optional stand alone application for a "per call" traceanalysis.

Note: A day-to-day monitoring of Access networks is available through real-time views displayedfrom the main bar menu of NSP. Those views allow a close observation of the NE behavior andhealth. The physical & logical resources are displayed by selecting the Configuration/RadioAccess/physical & logical resources sub menu. For more information about this function seeAlcatel-Lucent 9353 Management System - User Guide (NN-20500-032).



4.3 Counter observation benefitsThis section describes the benefit of the counter observation in the access network PerformanceManagement.

The performance measurement data is required to be produced by NEs and made available to theoperator for the network performance monitoring and evaluation. The counters and metrics(indicators) combined with the network configuration data represent a valuable source of informationfor network optimization tasks. Engineering teams can use this source of information for:

• Traffic measurements and resource usage/availability evaluation

• Network configuration validation

• Quality of Service (QoS) monitoring (and troubleshooting to some extent)

Threshold rule sets and conditions are associated with the counters in order to monitor the overallhealth of the network in almost Near Time. Upon violation of these conditions the authorized userswill be notified through e-mail, paging, or alarms of the network performance degradation.

The user can browse these alarms either in the Alarm window or via the Historical Fault Browser.These alarms are also sent through the 3GPP Interface-N.

The Alarms on thresholds feature is not applicable on the 9313 Micro Node B counters in theOAM06 release.



4.4 Call Trace benefitsThis section describes the benefit of the call trace data collection in the access network PerformanceManagement.

Call Trace is a very powerful feature that allows the collection of very detailed information about theUTRAN resources and call management. The collection of detailed information can be tailored to thespecific need and can include one or more cells or interfaces and UEs.

Statistical analysis (analysis providing statistics based on volume tracing) or per call trace analysisare available after collecting call trace data.

It is the dominant source of information used by the engineering teams during:

• Trials:

— Detailed troubleshooting and performance analysis

• Deployment:

— Merge with mobile logs for optimization & testing

• Commercial Operation:

— Continued drive testing

— "Remote Optimization"

• All phases:

— Detailed troubleshooting

— Detailed performance analysis on certain calls/cells



5 Counter and Trace overviewThis section provides an overview of the principle and the architecture of the counter observation andcall trace data collecting.

It is split into:

• UTRAN counter overview

• Call Trace overview



5.1 UTRAN counter overviewThis section describes the following topics:

• Counter system architecture

• RNC counter observation data

• Node B counter observation data



5.1.1 Counter system architectureThis section describes the general architecture of the counter observation collecting principle.

The main phases of the counter observation are:

• Performance management parameter configuration

• Counter pegging in the network elements (NE) according to the performance managementparameter configuration

• Performance measurement result collection and mediation

• Performance measurement result post-processing

The following picture shows the functional split of the counter observation domain:

Figure 1 Functional view of the counter observation domain.

The functional split between sub-systems is as following:

• NEs are in charge of recording data according to a pre-defined Granularity Period (GP) and acounter list. One XDR file is generated at the end of every GP.



• WMS is in charge of collecting data files from the NEs and exporting them in XML format (thefiles from microNode B are already XML formatted). The WMS is also responsible for networkconfiguration export (CM.xml).

• NPO is responsible of XML files and CM.xml file import and post-processing. It is alsoresponsible for QoS data computation and storage for network performance monitoring.

The results of the counter observations are XML record files, which store the Access NetworkObservation data (counters). The DTD of this XML format is 3GPP-compliant. Each record filecontains the counters produced by a single collecting element (e.g. the C-node on RNC "N3" or theNode B equipment "NB502").

You can use Network Performance Optimizer (NPO) to perform reporting of observations. NPOis the performance reporting tool based on the internal platform and introduced in the OAM05.2release.

NPO polls regularly the counter observation directory, uploads the XML counter observationfiles and post-processes them. The post-processing mainly consists of:

• Mapping the NE counter observation object model onto the NPO topological model

• Loading the NE counter observation data into the NPO database

• Performing temporal and spatial aggregations

• Computing the indicators and generating QoS reports

See NPO documentation information in the following section: NPO (Network PerformanceOptimizer).



5.1.2 RNC counter observation dataThis section lists the RNC C-Node observation counter families handled by the ADI application.

A counter family is a collection of counters that are related to measuring the same telecom functionor service.

The RNC C-Node observation counter families available for this release are classified as follows:

• Radio link management

These observation counters report the number of events attached to NBAP radio link setups(successful/failed), additions (successful/failed), and deletions (successful/failed).

• Handovers

These observation counters report the number of events attached to hard handovers.

• Power management

These observation counters are related to the status of the cell power.

• RRC connection

These observation counters report the number of events related to RRC connections.

• Iu interface connection

These observation counters report the number of events attached to Iu connection(successful/failed) and to radio link releases (request/command).

• RAB and RB radio link management

These observation counters report the number of events attached to the RADIO-BEARERestablishments (successful/failed).

• Mobility

These observation counters report the number of RRC Cell Update procedures.

• Radio measurement

These observation counters report observations related to the radio measurements at both theUE and cell levels.

• QoS performance

These observation counters report the number of events attached to the downsizing/upsizingservice (successful/failed).

• User plane common channel

These observation counters are related to the traffic management.

• Iur interface connection

These observation counters report the number of events attached to the Iur radio link setups



(successful/failed), additions (successful/failed), deletions (successful/failed), andreconfigurations (successful/failed).

• User plane dedicated channel

These observation counters are related to the traffic management.

• CN platform observation

These observation counters are related to TMU processors.

In the UA06.0 release, the RNC counters are classified by priority in the range [0-9]. 1 is thehighest priority and 8 is the lowest one; 0 and 9 are unused in this version. Counter priorities areused for the RNC counters list management mechanism.

Some limitations exist concerning the number of counters associated to each RNC observation,due to the data rate available for each observation.

About the RNC C-Node counter observations, see Alcatel-Lucent 9300 W-CDMA ProductFamily - Counters Reference Guide for RNC (NN-20500-028).



5.1.3 MSS counter observation dataThis section lists the MSS (I-Node and POC ) observation counter families handled by the ADIapplication.

Each Nortel Multiservice Switch (RNC I-Node and POC) observation family is attached to ManagedObject instances.

RNC I-Node and POC observations available for this release are classified as follows:

• Logical Processor

These observations are related to the status of the Logical Processor (CP, STM, PSFP, MSA32).

• ATM Port

These observation counters are related to the status of the ATM Port.

For the Nortel Multiservice Switch platform observations, see Alcatel-Lucent 9300 W-CDMAProduct Family - Counters Reference Guide for MSS (NN-20500-028).



5.1.4 Node B counter observation dataThis section lists the Node B observation counter families handled by the ADI application.

The Node B observation counter families available for this release are classified as follows:

• PCM management.

These observation counters are related to the status of the PCM links.

• ATM management.

These observation counters are related to the status of the ATM protocols.

• IP.

These observation counters are related to the MIB for Management of the TCP/IP networks.

• Radio.

These observation counters are related to the status of the BTSCell power or the physical PowerAmplifier.

• CCM Callp management.

These observation counters are related to the status of the iBTS CCM Callp.

• EEC.

These observation counters are related to the status of the ISR.

• IMA.

These observation counters are related to the status of the inverse multiplexing over ATMprotocol.

Each Node B observation counter is attached to Managed Object instances.

About the Node B observations, see Alcatel-Lucent 9300 W-CDMA Product Family - CountersReference Guide for Macro Node B and Compact Node B (NN-20500-028).

About the 9313 Micro Node B and 9314 Pico Node B observations, see 9313 Micro Node B and9314 Pico Node B - Performance Measurement Manual (NN-20500-123).



5.2 Call Trace overviewThis section describes the following topics:

• Call Trace system architecture

• Call Trace data flows



5.2.1 Call Trace system architectureThis section describes the components of the Call Trace feature.

A Call Trace application is considered to be distributed between the RNC and the OMC actingas element manager. When a specification applies to the RNC alone, this is normally clearlymentioned.

For the OMC description and implementation, see Alcatel-Lucent 9353 Management System -System Overview (NN-20500-031).

The RNC supports the call processing application. Collecting points are located in the variousCall Processing applications to provide Call Processing events as Call Trace data according toconfigurable filters.

The Call Processing events may be RNC external or internal messages, snapshot of softwarecontexts on particular conditions.

The Call Trace application in the RNC:

• collects the Call Trace data according to rules configured by the OMC

• makes the Call Trace data available for upload to the OMC

The call trace data retrieved from the RNC is XDR coded. The ADI application is in charge ofcollecting this data and providing XML files. ADI also performs the necessary decoding andmediation to generate Trace files based on consistent formats and object identifications. Forinstance, some UTRAN messages traced by the RNC and coded in ASN.1 yet are decoded inASCII by ADI.

Trace data are then available for post-processing tools:

• RFO

This application processes the whole trace data, except the CTn ones, and provides addedvalue information covering the different Call Trace needs: RF optimization, Networkoptimization, troubleshooting.

• WQA

processes the CTn traces and provides hand over matrixes used for neighboringoptimization (CTn module of WQA).

It also offers post-processing facilities to help investigating dropped call issues (CFt moduleof WQA).

It also uses the CTx data, which are, in the OAM06 release, the data collected from CTgand CTb, to optimize the UTRAN sub system, mainly the radio aspects, without requirementof drive tests (CTx module of WQA).



5.2.2 Call Trace data flowsThis section describes the call trace data flows.

The following figure provides described data flows, which are shown as arrows and referred toby a number in a circle.

Figure 2 Architecture of the trace application

1. The user performs the Call Trace application management in the RNC on the OMC GUI. Adedicated Call Trace Configuration Wizard is offered by WMS.

2. The Call Trace configuration data is sent on the configuration management data flow fromthe OMC towards the RNC. This activates the Call Trace session on the RNC.2' TheC-Node transmits to the I-Node the configuration management data received from the WMSServer and concerning the I-Node.

3. The call processing events are collected as Call Trace data, according to configurablefilters, from the collecting points located in the various Call Processing applications.

4. The call trace data is stored in files on the RNC disk. Files are closed on timer expiration orfile size conditions. If the trace has to be continued, then another file is opened.When a filebecomes available for upload from the RNC to the OMC, a dedicated event is sent on theEvent data flow by the RNC to the OMC. 4' . Conversely the Control Node may receive



some events from the Interface Node as "Trace File ready" events and forward them on theFault Management data flow.

5. ADI downloads the call trace files from RNC using ftp session and purges the call trace datafiles from the RNC once it has uploaded the Call Trace data.

6. ADI decodes the received files in XDR format, mediates the Call Trace files, and convertsthem to XML format. Then RFO or WQA, depending on the session files, get thosefiles.Note that ADI is implemented to deliver Call Trace files to RFO and WQA tools. RFO,WQA and Call Trace application in the OMC, form a bundle that is mandatory for a CallTrace usage.

7. The RFO or WQA post-processing tasks can be performed on demand.



6 Counter and Trace activationThis section describes the mechanism of:

• Counter observation activation

• Trace activation



6.1 Counter observation activationThis section explains how to activate the observation data collection on RNC and Node B. it is splitinto:

• RNC observation activation

• Node B and microNode B observation activation

• MSS observation activation



6.1.1 RNC observation activationThis section describes the counter observation activation mechanism in RNC.

The activation of an observation type in the RNC restarts the counting for the concerned set ofcounters.

At the RNC level the observation can be activated or deactivated from the OMC on operatorrequest.

The RNC observation activity is associated with an OAM object, the PerfScanner, to form theobservation session. This session is automatically created at the RNC creation time with a defaultgranularity period (GP) of 15 minutes. This applies to the entire RNC sub-network.

The associated attributes transmitted at the activation are:

• the granularity period (GP) which defines the periodicity of the generation of results.

• the reference of the observation: this attribute contains the identity of the observed entity,only useful for temporary observations

• the counter set list to be used

The granularity period (GP) is the time between two successive measurement resultsgatherings in the NE. The GP is synchronized on full hour or half/quarter hour or full fiveminutes. The GP value in RNC can be changed on operator request through WICL.

At the end of each GP, the RNC generates one observation file, compresses it and stores it onthe disk of the C-Node. Then an observationFileReady notification is sent to WMS to triggerfile retrieval.

At the NE level the observation files are generated in the XDR format and are compressed.

The first statistic record collected at the C-Node level after a PerfScanner creation (or unlockoperation) may have an effective measurement period less than the required granularity period.

For example, if the PerfScanner is created at 12:53 with a 15 minutes GP the next collection time atthe C-Node level will be 13:00, 13:15, 13:30.

The modification of the GP is immediately taken into account. For instance, if GP of the PerfScanneris modified from 15 minutes to 1 hour at 16:17, then the next collection times at the Control Nodelevel are17:00, 18:00, 19:00, and so on.

If the C-Node receives a PerfScanner deletion (or lock operation) request, the in-progress statisticsare collected and no observationFileReady event is sent to the main server for the current period.

For example, if the PerfScanner is deleted at 09:55, no observationFileReady event is sent at 10:00.

When the RNC (C-Node/I-Node/POC) receives an OAM request for a PerfScanner object, the



request is executed locally and an associated request is transmitted to the UMTS applications of theC-Node/I-Node/POC.

RNC counter list management

Due to the increase of the number of counters in the UA06 release, a new mechanism ensuresthat the volume of the configured counter records does not exceed the RNC capacity limit. It isapplicable only if GP is greater than 5 minutes.

This mechanism controls the activated RNC counter volume, and allows configuring andmanaging an activated counter list.

To prevent exceeding the counter volume limits, the RNC applies the following defensemechanism:

• When the configured counter volume exceeds 80% of the maximum supported volume, awarning alarm is raised. The user is notified to start managing the counter list.

• When the configured counter volume exceeds 100% of the maximum supported volume aminor alarm is raised. The RNC starts disabling counters according to a predefined (static)priority order until the configured counter volume complies with the defined limits.

• If all checks are passed, the WMS configures the list of counters in the RNC using WICLcommands. During this operation, if one or more counters families are configured, the WMSunconfigures them.

The reason is that, when familyIdList is set (i.e. not empty), all its counters are collected bythe RNC whatever the counterIdList setting.

The operator sets the list of counters to be activated in the RNC through a counter descriptorfile (text-based file). For this purpose, a reference counter descriptor file is exported from theWMS using PM ExportCounterList WICL command. The file is modified to activate/deactivatecounters. Checking is also performed via a PM CheckCounterList WICL command.

The new counter list file can eventually be propagated to a specific set of RNCs through a PMImportCounterList WICL command.

Note that these WICL commands must not be used for activation of UA06.0 NEs. The counterlist management feature must be used, instead.

Activated RNC counter descriptor file

The counter list format is a csv type, to be used by common applications. It must be semicolondelimited.

The Header section of the file is informative. When the file is generated from an exportcommand, this header provides details on the RNC from which the list is exported, on theUTRAN release on which the RNC is aligned, and on the OAM release of the WMS server.

Example:



RNC-105;06_00_00;OAM6.0;;;

• RNC-105 is the RNCUserlabel

• 06_00_00 is the utranRelease.

This field value corresponds to the UTRAN release of the RNC from which the counter listfile was originated, or to which the counter list file is to be applied. From OAM6.0 andonward, the UTRAN release format will be xx_yy_zz, where xx is the major UTRAN release,yy the minor UTRAN release, and zz a supplementary release identifier. The only supportedutranRelease field value is 06_00_00 in OAM6.0.

• OAM6.0 is the oamRelease

In the Counter List section of the file, the first line defines the field names:"isActivated;group;name;measuredObjectClass;weight;priority".

Then each line corresponds to a single root CNode counter.

• isActivated

A Y value in this field indicates:

— for the counter list import operation, the counter is to be collected

— for the counter list export operation, the counter is currently collected.

Setting a isActivated field value to Y will activate all the counters of the same group,whatever the isActivated value of the other counters within the group.

• group

This field indicates the group of all the counters sharing the same internal CNode id.

• name

This field indicates the counter full 3GPP name.

• measuredObjectClass

This field indicates the CNode objet class on which the counter is published in the 3GPPobservation files.

• weight

This field indicates the weight associated with the counter (1 In OAM6.0).

• priority

This field indicates the priority associated to the counter. The higher the priority value is, theless important the counter is considered. This value is used in case of resource shortage tostop counter collection .

When a counter is configured, all its screenings are pegged; in the same way, when a family isconfigured, all its counters are collected whatever the setting of the counters of this family.

The RNC updates the counter lists even if the counter observation is deactivated when



receiving the new configuration. This new configuration applies when the counter observation isre-activated

The CSV counter list files are stored on the Primary Main Server in the following directories:

• opt/nortel/data/counterlists/import/

• opt/nortel/data/counterlists/export/

The exported counter list files are automatically purged by the WMS after 30 days. If storagespace is required on the server, the files are recursively purged by the WMS, the oldest filesfirst, by 1 day steps.

The filenaming scheme for a counter list file exported from a managed RNC is:export_<id>_<date>_<timestamp>_<NE type>-<RNC userlabel>_<utranRelease>.csv

The file naming scheme for a default counter list file exported from a given UA release is:export_<id>_<date>_<timestamp>_<NE type>_<utranRelease>.csv

No specific file naming is required for the counter list files customized by the user.

Counter lists for upgraded or newly installed RNCs

In the OAM6.0 release, no upgrade is performed for the counterIdList/familyIdList of themanaged UA5.X RNCs. If a customization was performed for those attributes prior to OAM6.0, itwill be preserved. The counter list management WICL commands don#t apply to UA5.X RNCs.

In the OAM6.0 release, no upgrade is performed for the counterIdList/familyIdList whenupgrading a UA5.x RNC to UA6.0. If a customization was performed for those attributes prior toOAM6.0, it will be replaced by the default values for those attributes in UA6.0/OAM6.0. After theupgrade to UA6.0, the user will be able to manage the counter list of the RNC by using thededicated WICL counter list management commands.

When a new UA6.0 RNC is deployed, its counter list is set to a default value. Its counter list canbe customized by the user using the dedicated WICL counter list management commands.



6.1.2 Node B and microNode B observation activationThis section describes the counter observation activation mechanism in Node B and microNodeB.

The Node B and microNode B observation session is automatically created after building theNode B or microNode B and opening the OAM-BTS link with a fixed granularityPeriod of 1 hour.

At the Node B level the counter collection cannot be deactivated.

The GP can be modified through WICL. The available values are 15 min and 60 min. When theGP modification request is received, the Node B continues applying the old GP value until (andincluding) the end of the next top of the hour, and then apply the new GP value for the nextcollection periods.

The Node B generates and stores one observation file per GP with a maximum latency of 1minute after the end of this GP. The guaranteed storage duration is one day for 60 min GP filesand six hours for 15 min GP files.

The observation files are generated in XDR format.

No event is sent to the Main Server.



6.1.3 MSS observation activationThis section describes the counter observation activation mechanism in MSS paltform.

I-Node and POC counter activation and collection depends on the provisioning of the MSSPlatform and there is no correlation between the RNC (C-Node) observation and the MSSPlatform counter collection.

There are two kinds of counters available in MSS Platform: statistic counters and accountingcounters.

• Statistic counters

GP is fixed to 15 min and cannot be modified.

• Accounting counters

The default GP is 60 minutes. This corresponds to 24 timestamps at which MSS Platformcollects accounting data. Actually, up to 24 scheduled collection times can be set and thetime difference between two consecutive collection times must be greater than 1 hour andlower than 12 hours.

Statistic and accounting counters activation can be deactivated.

The generated files are closed either:

• on WMS demand, or

• automatically when the file size reaches 500 KBytes, or

• automatically at midnight.



6.2 Trace activationThis section describes the trace activation mechanism, the trace sessions and the XDR trace datafiles generated at the NE level.

It is split into:

• Trace session activity

• XDR trace data files



6.2.1 Trace session activity

The trace activity in the UTRAN can exist only during and within the frame of Trace sessions. Atrace session is managed within the OMC and the RNC through different managed objectclasses.

There is one object class dedicated for each different type of trace.

A CallTrace or ObjectTrace session is created or deleted through the OMC GUI and mapped ontoone or more CallTrace or ObjectTrace creation or deletion commands.

An active trace session corresponds to the activity of trace processes both in the OMC and in theinvolved NEs:

• Trace records are generated in the Network Elements on occurrence of call processing relatedevents and according to the criteria specified during the trace session creation.

• Trace records are logged in trace files stored in the NEs.

• Trace files are closed and made available for upload to the OMC, according to criteria specifiedat the trace session creation.

Note: Currently, Call Trace is only supported by the RNC.

When the C-Node receives an OAM request applying to the CallTrace or the ObjectTraceobjects, the request is executed locally and an equivalent request is transmitted to theapplications of the I-Node. The CallTrace/ObjectTrace files available on the disks of the C-Nodeand the I-Node are automatically uploaded to the main server.

The trace session activity is stopped definitively on a time condition specified at trace sessioncreation or at trace session deletion. The type of trace, the nature of data traced and the involvedNEs are specified in the trace session creation command.



6.2.2 Call trace and Object trace sessionsThis section describes the different trace session types. it is split into:

• Call trace session description

• Object trace session description

Call trace session description

The call trace session types are:

• Access Session (CTb)

• Geographical Session (CTg)

• Neighboring Session (CTn)

Access Session (CTb)

An Access Session (CTb) provides data related to all the calls initiated by a specified UE during thesession activation.

There is one and only one UE traced in an Access session. Therefore if n mobiles are to be tracedsimultaneously, then n sessions have to be created.

20 simultaneous Access sessions can be created per RNC.

The UE identity specified at the OMC when creating an Access session, may be one of thefollowing Initial UE identity IEs:

• an IMSI

• a TMSI

• an IMEI

• a P-TMSI

A call is traced by an Access session as soon as the required UE identity is checked during a callestablishment.

The traced UE in an Access session has its calls traced by an RNC as long as:

• the considered RNC is the SRNS of the UE

• the session is activated and exists.

To record all call messages or events, a mechanism called Call Trace initial UE identity learninghas been implemented which works as follows:

• UE Identity Learning

For every traced call, both the temporary UE identity (TMSI or PTMSI) and the permanent NASUE Id (IMSI) are recorded.



• Tracing

When a second traced call is made on a mobile, the call is traced if its initial UE identity matchesthe IMSI that has been recorded.

• Relearning

Whenever the initial UE identity (TMSI / PTMSI) of a mobile is changed, the new temporaryidentity is re-learned during the next call made by the UE.

When creating an access call trace session, use the NBAP dedicated Measurement parameters tooptimize the periodicity of measurement reports. You can configure the periodicity of threemeasurement types:

• Signal Interference Ratio (SIR),

• Round Trip Time (RTT),

• Transmitted Code Power (TCP).

The NBAP Dedicated Measurement parameters is also available in the Geographical Sessioncreation.

For more information about the NBAP Dedicated Measurements, see the 3GPP specification UTRANIub Interface NBAP signalling (TS 25.433).

To create an access session you can use WICL or the Call Trace Wizard application. See theCreating one or more Access sessions on one RNC and Creating an Access session on multipleRNCs procedures.

The XML CallTrace AccessSession files are generated on the main server in the followingdirectory:/opt/nortel/data/utran/callTrace/onOAMdemand/<sessionId>/<YYYYMMDD>/<UEid>/<callid>/*

These Access session trace files will be sent to the main server as soon as the traced call isterminated.

Geographical Session (CTg)

Use a Geographical call trace (CTg) session to trace calls established within a geographical area inthe UTRAN specified in the trace session creation command, during the session activation.

The geographical area in the UTRAN is a list of geographical areas in specified RNSs. RNSs aredefined by their RNC ID.

The geographic area in an RNS may be a cell, a set of cells from the RNS or all the cells in the RNS.

Therefore no UEs are identified in a Geographical session creation. Calls can be traced within aGeographical session as soon as the trace session is activated and exists.

The ratio of the established calls to trace is set by static configuration in each RNC. It is, therefore,taken into account on a per RNC basis.



http://www.3gpp.org/ftp/Specs/html-info/25433.htm


Calls may be traced even during peak hours, but the provided ratio can be lower than the committedratio (some calls may not be traced).

As soon as the call is established within a cell belonging to a geographical area specified in an activeGeographical session, it is traced all the time the session is active and the RNC remains as theSRNC of the related UE.

As a consequence, the call, once established, can be traced even if the related UE moves into areasthat do not belong to the geographical area.

The trace files are transferred to the server at intervals that are determined by theFileUploadSize - FileUploadPeriod parameters and/or when the Geographical session isdeleted.

Two Geographical sessions are supported per OAM simultaneously. Only one Geographical sessionis supported per RAN.

It is possible to select the types of call that will be traced within the CTg session. The selection isdone through the callTypeList attribute on the CTg object class.

When creating a Geographical Session, you can set NBAP Dedicated parameters. See AccessSession.

Call failure trace in CTg

In order to provide an efficient means for call drop troubleshooting, the CTg record can beenriched with call drop snapshots. These snapshots contain a set of information designed tohelp in understanding the drop context. Detailed failure cause values are provided, along withdata extracted from the RNC call context (radio measurements, radio links configuration, HOstates…).

Call failure snapshots are produced, if requested, in two different cases:

• When a call traced in a CTg session drops.

In this case, the snapshot is provided in addition to existing CTg data blocks. This will makeit possible to have in a synchronized way both traced messages allowing to build call DFDalong with detailed information related to the drop context,

• When a call drop occurs in a cell which is in the scope of the CTg session, but the call is nottraced by CTg. This provides a complete data set regarding all the call drops happening inthe scope of the session.

The snapshots is contained in a new data block. This data block is required through an existing"UE Call Failure Trace" function. This function is then available only in CTg session. Associatedsubfunctions are not considered, meaning that if at least one of them is set, the overall snapshotcontent is provided.

At the OMC level, all the snapshots recorded during a CTg session are gathered in a single file,



stored in the session sub-tree. WQA offers post-processing facilities to help investigatingdropped call issues.

Neighboring Session (CTn)

Use a Neighboring Call Trace (CTn) session to trace data that may be useful for cell neighboringanalysis and optimization.

The CTn session collects the data and provides the traces necessary to produce handover matrices.This is accomplished by the WQA (Wireless Quality Analyzis) product.

Just like for CTg, it is possible to define, when creating the session:

• the list of cells in which traces are recorded

• the list of call types to be traced (the possible call types are the same as the CTg ones)

The list of cells can contain even cells that do not belong to an RNC managed by the WMSserver. This allows the user to get measurements that are related to neighbor relationshipsestablished with these "external" cells.

Object trace session description

The object trace session types are:

• Cell session

• IuCs, IuPs, Iur and IuBC sessions.

Cell Session

An object trace cell session provides trace data related to the management of one cell orseveral cells.

The objects are traced within a given cell. A cell session traces common messages on a cell or set ofcells (for example NBAP Common Measurements).

Depending on its configuration, a Cell session can trace a single cell, a group of cells in an RNS, orall cells in an RNS.

Only one Cell session is supported at any time on each RNC. Two Cell sessions are supported perOAM simultaneously.

During the Cell session management, the NBAP Common measurement feature enables the tracingof NBAP Received Signal Strengh Indication (RSSI) and TCP measurements. Note that RSSI is alsoreferred to as Received Total Wideband Power (RTWP).

For more information about the Configuration Management trace parameters, see Alcatel-Lucent9300 W-CDMA Product Family - Parameters Reference Guide (NN-20500-027).



IuCS, IuPS, IuR, IuBC sessions

Use the IuCs Object Trace (OTIuCs) session and the Object Trace IuPs (OTIuPs) session to tracerecords related to common RANAP messages on IuCs or IuPS interface. The list of scoped IuCs orIuPS interfaces is configured at the OAM level.

Use the Object Trace Iur (OTIuR) session to trace records related to common (i.e. not linked to agiven call) RNSAP messages on an IuR interface. The list of concerned Iur interfaces is configured atthe OAM level through a list of Neighboring RNCs.

The Object Trace IuBc (OTIuBc) session provides records related to common SABP messages onan IuBc interface.

An RNC supports only one IuCS / IuPS / Iur / IuBC session at a time.

Create call trace and object trace sessions

To create call traces and object trace sessions you can use WICL or the Call Trace Wizardapplication.

To create an Access session see the Creating one or more Access sessions on one RNC andCreating an Access session on multiple RNCs procedures.

To create a Geographical Session see the Creating a geographical session procedure.

To create a Neighbouring Session see the Creating a Neighbouring session procedure.

To create a cell session see the Creating a cell session procedure.

To create an IuCs, IuPS, IuR or IuBC Object Trace sessions see the Creating an IuCS, an IuPS, anIuR or an IuBC sessionprocedure.

Session templates

Use the Session template facility to define typical sessions to be used frequently. It allows the user tospecify the record types to be traced and their associated modes, any time you create a session. Thesession templates are managed at the OAM level only; this can be done through the Wizardinterface.

A given number of pre-defined templates are delivered with the Call Trace Configuration Wizard.When creating a session template, you must select at least one predefined trace record.



6.2.3 XDR trace data filesThe file format of the trace files output by the RNC is XDR The XDR formatted call trace files arethen XML formatted by WMS.

This section describes the XDR trace files.

All the traced records related to a session are collected in a trace file, at a given time, in a NetworkElement. For the particular case on the RNC, two files related to a session may be opened at a giventime, one in the C-Node and one in the I-Node, if the session manages trace records from both theC-Node and the I-Node. If a trace record verifies recording criteria defined in different active tracesessions, then it is recorded into an only trace file. Priority criteria are specified for identifying the filein which the record is performed.

XDR Trace data files

Trace functions / subfunctions

Call Trace data provided by the RNC is organized into different traced functions / subfunctions.

Each traced function / sub-function provides information on a particular aspect of the Call processing.

A function has one or several subfunctions, and a subfunction provides one or several collectionpoints. Each collection point has an event name associated with it and provides trace data withASN.1 message, or context full data (i.e. decoded message), or both.

Each traced function / sub-function can be presented according to one or more modes.

Trace modes

The trace mode indicates the level of detail or format of data to provide.

The differences between the various trace modes are related to:

• The exhaustiveness of the provided information (either a part or the whole of the IEs in a tracedrecord provided by a traced sub-function),

• The coding of some provided IEs (encoded in ASN.1 or in ASCII).

The following trace modes are available:

• Mode 1 or Event only:

This mode provides the header including in particular: the traced function and sub-function,the event name, a time-stamp, the related cell Id (if relevant), the related RNC Id.

• Mode 2, or ASN.1:

This mode provides the header and the full record information, coded in ASN.1; this modeapplies only to UTRAN protocols PDUs (available for rrc, Iu, Iub, Iur 3GPP messages) and does



not apply to the I-node.

• Mode 3, or ctx_full:

This mode provides a specific set of data in XDR format associated with the event (not availablefor event linked to Iu/Iur/iub/rrc ASN.1 messages, except for RRC Dedicated Traffic).

RNC Trace file structure

A trace file includes:

• a trace file header

• management records providing information on the recording environment.

• trace data records.

The data record contents are particular to each traced function / subfunction, that is to say theinformation provided by a trace data record depends on the collecting point in a dedicatedsoftware module from which they are issued. The data records belong to the different types oftraced functions:

— UeMgt (starttime, endtime)

— Rrc (RRC events and RRC measurements)

— Iu (RANAP events)

— Iub (NBAP events)

— Iur (RNSAP events)

— IuBC (SABP events)

— Iupc (PCAP events)

— ALCAP

— Dtap (transparent data events on Rrc and Iu interfaces)

— Snapshot C-Node (important call processing events)

— Error plane (erroneous or out-of-sequence messages on all interfaces)

— QoS (Quality of Service events)

— I-Node power control (DHO events)

— I-Node RLC traffic (RLC events)

RNC file header structure

The file header structure is as follows:

• Node type (in OAM06.0 only RNC supports Call Trace)

• The version # of the Call Trace header file

• The session Id configured by the OMC



• The trace session type ( CTb, CTg, OTCell, OTIuCs, OTIuPs, OTIur, OTIuBc)

• A tracekey (present only for CTb trace)

• The identity of the traced UE (present only for CTb trace)

Record headers

The record header contains the record type (management record or data record).

Each entry for a particular traced sub-function contains the following common header information. Allitems are included regardless of whether the type of call trace is used:

• Traced sub-function identifier or name,

• Timestamp to 20 ms resolution and accuracy,

• UE identity may not be in every header (especially early in the call) but is included as soon as it isknown,

• Mobile type identifier, if it cannot be deduced from the UE identity -

• Tracekey,

• Last known reference cell for this call (allows the post-processing tools to associate otherinformation such as FER with a particular cell).

• Addresses/identifiers for the network elements being used for this call e.g. channel elements,RNC cards.

Note: The trace files from CTn sessions have a record header different from the ones from theother sessions.

Management records

The different management records of the trace file are:

• First or last file record for a traced call

• CN INVOKE TRACE message received

• CN DEACTIVATE TRACE message received

• SWACT (SWitch of ACTivity) on a collecting processor

• SWACT (SWitch of ACTivity) on a management processor

• SWACT (SWitch of ACTivity) on a disk processor

• Anomaly in tracekey management

• First or last file record for a traced emergency call

• Stop or restart file record for overload



7 Counter and Trace collection and mediationThe purpose of this section is to describe the mechanisms used to upload the performance datafrom the Access network elements to the Main Server.

This section is split as follows:

• Counter collection and mediation

• Trace data collection and mediation



7.1 Counter collection and mediationThis section describes how the counter observation data is collected and mediated from the NEs tobecome available for post-processing. It is split into:

• Counter collection

• Counter mediation

• XML observation file compression

• Counter data

• Manual collection and mediation of counter files



7.1.1 Counter collectionFrom the OAM point of view, the observation counters are managed by the ADI (Access DataInterface) application before being loadable into post-processing application.

RNC counter collection

As soon as the "observationFileReady" notification is received from the RNC, WMS starts thecollection of the observation files of a given GP using FTP (File Transfer Protocol). The filename is carried within the notification.

Once a counter observation file is retrieved, it is deleted from the RNC hard disk by WMS.

MSS counter collection

The I-Node and POC counter collection depends on the provisioning of the MSS Platform andthere is no correlation between the RNC (C-Node) observation and the MSS Platform countercollection.

The MSS Platform observation files are collected by WMS at suitable interval by forcing the fileclosure. The data are formatted in BDF representation.

Once the MSS Platform counter observation files are retrieved, WMS deletes them. MSSPlatform can autonomously delete the files when the maximum number of stored files isreached.

Node B counter collection

WMS autonomously starts the collection of the observation files from all supervised Node Bsusing FTP at least 1 minute after the end of the considered GP.

In case of file retrieval failure during the nominal collection process, WMS retries duringsubsequent time period between the end of this collection process and the beginning of the nextcollection process. The targeted observation files must not be older than 24 hours for the 60 minGP files and 6 hours for the 15 min GP files.



7.1.2 Counter mediationWhen collected from the NEs, the Access Network observation counter files are handled by the ADIapplication and stored in XML record files.

The role of mediation is to translate the raw data into a common format and to bind the observationmeasurement to their associated objects in the logical model of the performance managementapplication. Then, the processed data is made available to the upper layer applications.

This section describes how the XML access network observation files at the ADI application outputare organized, how to identify the counter information they contain, how they can be compressed. Italso describes how to generate observation reports.

Figure 3 Counter collection and mediation



The XML observation files comply with the 3GPP 32.401.02 DTD. For more details about this DTD,see DTD 32.401.02.

Some processing is done on the observation counters in order to provide temporal (different periodsof observation) and spatial aggregations. The observation counter records are then available as:

• single period records

• hourly aggregated records

• daily aggregated records

All the counters are produced in each observation file (single, hourly and daily), and a predeterminedsubset of these are aggregated at the RNC level.

To optimize the server storage capacity, the purge of the observation files is triggeredautomatically. The guaranteed storage duration on the server is three days.

File name convention for observations

The file name convention for the observations is as follows:

<type><startdate>.<starttime>-<endtime>_<NE>[_-_RC].xml

Where:

• type is set to A to indicates that the observation file contains observation data of a singleNE and for a single GP. This also applies to the hourly aggregated PM files.

• startdate is the beginning date of the granularity period; its format must be <YYYYMMDD>.

• starttime is the beginning time of the granularity period; its format must be <hhmm+#GMT>.

• endtime is the end time of the granularity period; its format must be <hhmm+#GMT>.

• NE is the Network Element ID, that means a unique numerical identifier as defined in 3GPP using<Node Type>-<NE userlabel> pattern, or the Node B name using the NE userlabel as an NE ID.

The list of possible value for Node Type is:

— RNCCN (for RNC C-Node)

— INode (for RNC I-Node)

— POC

— NodeB (for standard NodeB)

NE userlabel is the Userlabel of the NE (blanks replaced by underscores, for exampleRegion_Centre).

Example:

A20051103.1815+0200-1830+0200_RNCCN-RNC14A

When the starttime and the endtime are equal, the period corresponds to 24 hours.

See the following table for an interpretation of the codes.



Code Description

YYYY The 4-digit year

MM The month of the year (01, 02,..., 12) for file creation time at RNC level

DD The day of the month (01, 02,..., 31) for file creation time at RNC level

hh The 2-digit hour (00, 01,..., 23). In the case of daily aggregation files, hh is al-ways 00.

mm The 2-digit minute of the hour. Possible values are five minute steps: 00, 05,10, 15, 20, 25, 30, 35, 40, 45, 50, and 55.

#GMT Difference between local time and Greenwich Meridian Time (+/-hhmm). At10:15:02 in Paris, the April 22, 2004 in Paris, the #GMT is +0100 => the<hhmm><#GMT> is 1015+0100.At 18:12:11 in New York, the April 22, 2004,the #GMT is -0500 => the <hhmm><#GMT>is 1812-0500.



7.1.3 RNC observation XML filesThis section describes the file tree structure, the data formats and the file naming conventions usedby the ADI application to store the RNC observation data.

RNC C-Node XML observation files

The C-Node XML observation files are generated on the server in the following directory:opt/nortel/data/utran/observation/stats/<YYYYMMDD>/RNCCN-<NE userlabel>.

The XML format is compliant with the 3GPP dtd file: 32.401-02.dtd. The granularity perioddefines, in minutes, the periodicity of the generation of the counters; the supported values are 5,15, 30 and 60.

The C-Node XML generated file has the following format:

<type><startdate>.<starttime>-<endtime>_RNCCN-<NE userlabel>.xml

Where:

• type is set to A which indicates that the observation file contains data of a single NE and fora single GP.This also applies to hourly aggregated files.




Example:

A20051103.1815+0200-1830+0200_RNCCN-RNC14A

To generate UTRAN Access observation reports from NPO, see NPO User Guide (3BK 21376AAAA PCZZA). For other NPO manuals, see NPO (Network Performance Optimizer).

RNC C-Node observation during OMU SWACT

The OMU SWACT (SWitch of ACTivity) is a mechanism used to switch over the active OMU. Thismechanism is specific to the RNC C-Node.

When an OMU SWACT occurs, the counters do not appear in the NIMS-PrOptima application for the15-minute window, and the file transmitted from the new active OMU to the PerfServer contains onlya portion of the data.

The following example is based on a 15-minute collect time, the last collect launched by OMU at 2:15p.m., and notification sent and received at 2:20 p.m. (this means the previous collect is finished andcorrectly handled).

The impacts of the OMU SWACT are given in the following cases:

• Case 1. If SWACT occurs at 2:21 p.m., thus after the last collect or notification, and the restart



takes one minute, the TMUs continue running and computing statistics; at 2:30 p.m., the OMUwill send a collect request to all entities. Therefore there is no impact from OAM.

• Case 2. If SWACT occurs at 2:29 p.m., and when the OMU becomes active again, for example at2:32 p.m., it will be too late to send a collect request. Therefore the next collect time will be at2.45 pm and will last 30 minutes. This is a restriction.

• Case 3. If the collect request is sent at 2:30 p.m. but OMU SWACT occurs at 2:31 p.m. beforeany end of computing or before all the TMUs have time to send to the OMU their collect, the filewill be closed, and remain on disk with only the header, or part of the information or all of theinformation if writing has already started. The next period of collect will be aligned on the correct15-minute period. Therefore there is no notification sent to the OAM, and the period of collectfrom 2:25 to 2:30 p.m. is lost. The next collect will be on a valid period. This is a restriction.

• Case 4. If the collect request is sent at 2:30 p.m. but not all the LAs have received the collectrequest before SWACT occurs; this is quite rare, but can happen. Therefore there is no collect forthe 2:15 p.m. to 2:30 p.m. period, and a bad period of collect from 2:30 p.m. to 2:45 p.m. isrecorded. This is a restriction.

RNC I-Node and MSS POC XML observation files

The directory of the RNC statistical I-Node observation XML files is as follows:

opt/nortel/data/utran/observation/stats/<YYYYMMDD>/INode-<NE userlabel>

The directory of the RNCaccounting I-Node observation XML files is as follows:

opt/nortel/data/utran/observation/account/<YYYYMMDD>/INode-<NE userlabel>

The I-Node XML generated file has the following format:

<type><startdate>.<starttime>-<endtime>_INode-<NE userlabel>.xml

Example:

A20051103.1815+0200-1830+0200_INode-RNC14A

The directory of the RNC statistical POC observation XML file is as follows:

opt/nortel/data/utran/observation/stats/<YYYYMMDD>/POC-<NE userlabel>

The directory of the RNC accounting POC observation XML file is as follows:

opt/nortel/data/utran/observation/account/<YYYYMMDD>/POC-<NE userlabel>

The POC XML generated file has the following format:

<type><startdate>.<starttime>-<endtime>_POC-<NE userlabel>.xml

To generate UTRAN Access observation reports from NPO, see NPO User Guide (3BK 21376 AAAAPCZZA).



7.1.4 Node B observation XML filesThis section describes the file tree structure, the data formats and the file naming conventions usedby the ADI application to store the Node B observation data.

The observation files stored on the Node B disk are periodically uploaded by WMS.

The Node B XML observation files are generated on the main server in the following directory:

/opt/nortel/data/utran/observation/stats/<YYYYMMDD>/<BTSEquipment-BTSUserLabel>

The XML format is compliant with the 3GPP dtd file: 32.401-02.dtd.

The generated Node B XML file has the following format:

<type><startdate>.<starttime>-<endtime>_<BTSEquipment-BTSUserLabel>

Where:

• type is set to A which indicates one of the following aggregated observations:

— the observation file contains data originated from a single Node B for an hourly aggregation.

— the observation file contains data originated from a single Node B for a daily aggregation.




To generate UTRAN Access observation reports from NPO, see NPO User Guide (3BK 21376 AAAAPCZZA).



7.1.5 XML observation file compression

At the installation time, you can enable or disable the compression file feature. When this feature isdisabled, the XML observation files consume more hard disk space. It is recommended not tochange the compression file setting before processing counter observation. If you want to modify thecompression setting, contact the system administrator.

The compression feature enables the compression of the observation XML files before they aresaved in the hard disk, using the "gzip" algorithm. Compressed file names follow the patterndescribed in the section above, except they have the ".gz" suffix.

This feature applies to all the observation files produced after the option is activated.

The following example shows the compressed XML file for RNC C-Node observations.

Example:

A20010513.1730+0100-1800+0100_RNCCN-rncSud.gz

Use the following command to change the compression status in a Unix shell logged on to the ROC:

fmkpm_adm.sh -online <server> [disable|enable] compress

Where:

Where <server> determines to which server this script will apply: the list of servers is obtained via thefmkpm_adm.sh -listserver command. There is one server dedicated to all the observations.

The compression status behaves according to the following rules:

• It is preserved across system restart.

• It is backed up, and restored, when performing a customer data backup.

• The default option status after a new system installation or a system upgrade is activated.

• The default option status after a system upgrade is deactivated.



7.1.6 Counter data

Observation counter identification

There are three types of observation counters available on the OAM GUI:

• CUMULATIVE (or TOTAL) to count the events. It is incremented by 1 each time the countedevent occurs, and it provides the cumulated value for the observation period.

• VALUE to record value accumulation. It offers the means of measuring minimum, maximum, andthe average values. The average value is an event weighted average.

• LOAD offers the means of sampling rapidly changing data, and obtaining an average, aminimum, or maximum value of the sampled data. The average value is a time weighted average

To each counter, zero, one or more screenings may be associated. Screening mechanismprovides a further "specialization" of the counters. For example, the screening TimeOut of theRNC counter RadioLinkSetupUnsucess counts the number of unsuccessful radio link setupbecause of time out.

A counter record can be understood as a counter screening value for a given measured objectinstance. More precisely, when a CUM counter screening is measured on an object instance theresult is one counter record; and when a LOD/VAL counter screening is measured on an objectinstance, the result is four counters records.

Observation counter name

Counters are identified by name (for example: TheCounter). For some measurements, it is possibleto add several screening names, and/or the following five fields:

• cumulated value

• maximum value

• minimum value

• number of events

• average value.

the CUMULATIVE counter has one value, while VALUE and LOAD counters have five values.

The associated counters are identified using a dotted notation:

• VS.<CounterName>.Cum

Example:

VS.AveragePowerUsedForSpeech.Cum

• VS.<CounterName>.Min

Example:

VS.AveragePowerUsedForSpeech.Min



• VS.<CounterName>.Max

Example:

VS.AveragePowerUsedForSpeech.Max

• VS.<CounterName>.NbEvt

Example:

VS.AveragePowerUsedForSpeech.NbEvt

• VS.<CounterName>.Avg

Example:

VS.AveragePowerUsedForSpeech.Avg

• VS.<CounterName>.<Screening>

Example:

VS.IuRelocationRequestFailuresCs.2Gto3GRejectionDueToTimeOut

For more information about the screening meanings and observation measurements, seeAlcatel-Lucent 9300 W-CDMA Product Family - Counters Reference Guide (NN-20500-028).

Managed object format

The Managed Objects contained in the observation record files are identified according to the 3GPPTS 32.300.

The following conventions are only used in the XML record file. For the NE identifiers used in filenaming conventions refer to the File name convention for observations section.

A Distinguished Name (DN) is built as a series of comma-separated name components referred to asRelative Distinguished Names (RDN).

DN ::= RDN [',' RDN]*

The syntax of these name components is the following:

RDN ::= className '=' identifierValue

There is no space character between RDNs; the only possible separator is "," (comma).

The className element is not the name of the naming attribute (for example rncId) but the name ofthe class (for example RNC).

The <identifierValue> must be processed as a string.

For example, the ROC "ROC2" RNC "RNC-A" Cell "C123" is identified by the following DN:

SubNetwork=ROC2, SubNetwork=UTRAN, ManagedElement=RNC-RNC-A, RncFunction=0,UtranCell=C123

Its MOid would be RncFunction=0, UtranCell=C123



Observation file DTD versioning

The issue is to unambiguously identify the release of DTD used for the XML output.

The name of the DTD referred to in the XML document header includes the protocol name and therelease of this DTD, as in the following example:

Figure 4 DTD versioning



7.1.7 Manual collection and mediation of counter files

Manual collection and mediation mechanism description

Generally, the files are uploaded with no problem by WMS from the NEs, however some errorscan occur during this process.

A catch up mechanism automatically tries to get counters files when the regular collection failed.

In some cases, the catch up mechanism is not triggered. The Performance Managementoperator has the possibility to use a manual command that fetches all the files still present onthe NE, including whatever files not mediated that were not purged yet. The end result is XMLobservation files saved in a specific directory but using the same directory structure as regularobservations.

The WICL command is called RecoverObs. It triggers the recovery process and returns with alist of files to be recovered. The recovered files are stored in theopt/nortel/data/utran/manual_obs directory, in a specific NE subdirectory.

The RecoverObscommand performs the following operations in sequence:

• recover the FTP login information from the database, MDM or default values

• log in FTP and list the directory expected to contain observation files

• for each file found in the observation directory, generate one CORBA message to the serverto start the recovery and processing process.

• the WICL command returns

• the server transfers the files one by one, and processes them in sequence. The processingis restricted to decoding, mediation, synthetic counter calculations and XML generation. Notemporal aggregation is made, and threshold for alarms are not evaluated.



7.2 Trace data collection and mediationThe treatments performed on the trace data at the main server level are sequenced as follows:

Figure 5 Call trace data mediation

This section describes the following topics:

• Call Trace data collection

• Call Trace data mediation



7.2.1 Call Trace data collectionThis section explains how the NE data are transmitted to the OMC.

Call Trace data collection

The Trace data originated from the UMTS Radio network and available at the ADI level is aimed totrace the events and measurements occurring during mobile communications.

When it closes a trace data file, the RNC (namely C-Node) sends an event report to the OMC.The XDR trace files generated by the RNC are retrieved by ADI. They are then pre-processedto XML files in order to ease the RFO or WQA post-processing.



7.2.2 Call trace data mediation

The collected trace files are made available to RFO in directories dedicated to each tracesession: CTb, CTg, OTCell, OTIuCs, OTIuPs, OTIuR, OTIuBc. The CTn files are madeavailable for WQA in a dedicated directory.

The trace data is stored in a directory hierarchy according to the day associated with the start time ofthe communication and to the associated UE identification (for example, IMSI).

This data is stored in one or more files according to call Id or object Id. The records pertaining to asame call are gathered in a given set of files. These files contain records of different types as follows:

• UeMgt (starttime, endtime)

• Rrc (RRC events and RRC measurements)

• Iu (RANAP events)

• Iub (NBAP events)

• Iur (RNSAP events)

• Iubc (SABP events)

• Iupc (PCAP events)

• ALCAP

• Dtap (transparent data events on Rrc and Iu interfaces)

• Snapshot C-node (important call processing events)

• Error plane (erroneous or out-of-sequence messages on all interfaces)

• QoS (Quality of Service events)

• I-Node power control (DHO events)

• I-Node RLC traffic (RLC events)

• Neighbouring call trace in CTn session.

This data is stored in dedicated files using XML formats. The formats of the produced XML filesare described further below.

The protocol events (i.e. SABP, PCAP, RRC, RANAP, NBAP and RNSAP events) are storedaccording to the concerned interface: RRC, Iu, Iub, Iur as values of XML elements in anhexadecimal format (they are ASN1 encoded). They can be decoded to XML on demand.

Parts of some protocol events are systematically decoded by the NE in order to provideessential information in a convenient format. RRC measurements (intraFrequency andtrafficVolume), which are sent already decoded from the RRC messages, are displayed as XMLtags.

Inode measurements are stored in separate files under the same directories. Error traces



contain undecoded ASN.1 messages. Decoding them using the on-demand service may lead toimprevisible results.

One file uploaded by a CTg session may mediate into several files, one session file plus one fileper traced call.

One file uploaded by a CTb session always mediates in two files, one session file plus one tracefile, because the CTb sessions produce files for one call only.

One trace file uploaded by an object trace session always mediate into one file, each recordidentifies the object(s) that produced it.

Each Trace session is associated with a CT_<sessionId>.xml log file located at the root of the dailyhierarchy. A log file stores the list of traced communications for the associated session. These logsmay be used to retrieve trace data associated to a particular session. This file has its own DTDdescription, which is stored in the mgtData.02.dtd file..

XML Trace data file contents• CTb mediated files

Each CTb mediated trace file contains all recorded information related to a given call. Sucha file is identified by:

— the session Id of the session during which the call was traced

— a time-stamp

— the related UE Id

— a call number

• CTg mediated files

Each CTg mediated trace file is identified by:

— the session Id

— a time-stamp

— callEstabCause value

• CTn mediated files

Each CTn mediated trace file is identified by:

— the session Id

— a time-stamp

— tracekey

— callEstabCause value

• OTIuCs, OTIuPs and OTIur mediated files

Each OTIuCs, OTIuPs and OTIur mediated file is identified by:



— the session Id

— a time-stamp

— IuInterfaceID value

• OTIuBc mediated files

Each OTIuBc mediated file is identified by:

— the session Id

— a time-stamp

— IuInterfaceID value

XML Trace data files directories

The XML CallTrace AccessSession files are generated on the main server in the followingdirectory:

/opt/nortel/data/utran/callTrace/onOAMdemand/<sessionId>/<YYYYMMDD>/<UEid>/<callid>/*

The XML geographical trace files are generated on the main server in the followingdirectory:/opt/nortel/data/utran/callTrace/originatedFromGeographicalArea/<sessionId>/<YYYYMMDD>/-<rc>/calls/<callid>/*

The rc field in the hierarchy is added when the number of calls in one day is over the maximumnumber of directory entries supported by the OS. So when the YYYMMDD directory is up to themaximum capacity, a YYYMMDD-2 directory is added, then a YYYMMDD-3. There never is aYYYMMDD-1 directory.

The XML Neighboring Session files are generated in the followingdirectory:/opt/nortel/data/utran/calltrace/NeighboringTrace/RNC-userlabel/<YYYYMMDD>/*

The XML ObjectTrace CellSession files are generated in the following directory:/opt/nortel/data/utran/objectTrace/cell/<sessionId>/<YYYYMMDD>/*

The XML Object Trace IuCs, IuPS, IuR, IuBC session files are respectively generated in thefollowing directories:

• /opt/nortel/data/utran/objectTrace/Iu-Cs/<sessionId>/<YYYYMMDD>/*

• /opt/nortel/data/utran/objectTrace/Iu-Ps/<sessionId>/<YYYYMMDD>/*

• /opt/nortel/data/utran/objectTrace/Iu-R/<sessionId>/<YYYYMMDD>/*

• /opt/nortel/data/utran/objectTrace/Iu-Bc/<sessionId>/<YYYYMMDD>/*

The protocol events are stored according to the concerned interface in an ASN.1 encodedhexadecimal format.

Each trace session is associated with a log file located at the root of the daily directory hierarchy. Thelog file stores the list of traced communications for the associated session. Use these logs to retrievetrace data associated with a particular session.



The log data is stored in a CT_<sessionId>.xml file for each session , published at the end of theday. This file has its own DTD description, which is stored in the mgtData.02.dtd file .

Call dedicated traces

The traces of a call simultaneously traced by more than one RNC and belonging to the sametrace session are located in the same directory. The OAM replaces the RNC traceKey by itsown string tracekey which is unique for the whole server. The ADI groups all the data related toa single UE call into a unique directory.

The trace data is stored according to the date and time of the beginning of the call even if the call hasstarted the day before. If the purge has been triggered and has removed directories the day before,the directory structure is re-created if possible (that means if startTime is known). Otherwise, data isstored in the current day.

XML file compression for traces

At the installation time, you can enable or disable the compression file feature. When this feature isdisabled, the XML observation files consume more hard disk space. It is recommended not tochange the compression file setting before processing traces. If you want to modify the compressionsetting, contact the system administrator.

The compression feature enables the compression of the xml files before they are saved on the harddisk, using the "gzip" algorithm. Compressed file names follow the pattern in the section above,except they have the '.gz' suffix.

This feature applies to all observation files produced after the option is activated.

The following example shows the compressed XML file for RNC C-Node observations.

Example:

A20010513.1730+0100-1800+0100_RNCCN-rncSud.gz

Use the following command to change the compression status in a Unix shell logged on to the ROC:

fmkpm_adm.sh -online <server> [disable|enable] compress

Where:

Where <server> determines to which server this script will apply: the list of servers is obtained via thefmkpm_adm.sh -listserver command. There is one server dedicated to all the observations.

The compression status behaves according to the following rules:

• It is preserved across system restart.

• It is backed up, and restored, when performing a customer data backup.

• The default option status after a new system installation or a system upgrade is activated.

• The default option status after a system upgrade is deactivated.



Trace file DTDs

This section presents the following trace DTDs:

• 3GPP call trace DTD

• 3GPP object trace DTD

• Log file DTD

3GPP call trace DTD

All the ADI XML data for call traces share the same DTD.

Whenever possible, the set of XML elements is defined by the 3GPP 32.108 contribution. Parts ofthe older DTD file are kept in a separate DTD file to describe the management record files. The mainDTD file is called 32.108-contrib02.dtd.



Figure 6 Call trace DTD-first part



Figure 7 Call trace DTD-second part



Figure 8 Call trace DTD-third part

3GPP object trace DTD

The object trace feature is vendor-specific. Whenever possible, the set of XML elements is definedby the 3GPP 32.108 contribution. The main difference is in the replacement of the<traceRecSession> element with the <TracedObject> element and the introduction of a<traceRecSessionRef>.

This description is filed under objectTrace.04.dtd. The tags added or modified from the standardare represented in italics.

Figure 9 Object trace DTD-part 1/4





Log file DTD



The CT_<sessionId>.xml log file located at the root of the daily hierarchy has its own DTD. Thecorresponding description is found in the following mgtData.02.dtd figures:

Figure 13 Management data DTD (Part 1/3)



XML file trace data format


• Element definitions

• DTD versioning

• Valid character set

• Basic types

• UE identifiers

• Timestamps

• Traced object format

Element definitions

This section describes the 3GPP 32.108 contribution tags and the generic tags in the contribution, forthe specific needs of tracing application. It is split into the following parts:

• 33GPP 32.108 contribution tags

• Tags specific to object traces

••Table 1 3GPP 32.108 contribution tags

XML element Description Contents

traceCollection This is the top-level element. Itidentifies the file as a collec-tion of trace data. It has 2 at-tributes:

• version: file format versionapplied by the sender. Thedefault format version is01.

• collectionBeginTime:timestamp that refers tothe start of the first tracedata that is stored in thisfile. It is a completetimestamp including day,time and delta UTC (checkif it is UTC) hour.

vendor (optional), sender,traceRecSession

vendor Optional element that identi-fies the vendor of the equip-ment that provided the tracefile. Set to Alcatel-Lucent

string

sender The sender uniquely identifiesthe NE or EM that assembledthis trace file, according to thedefinitions in 3GPP TS 32.106.

string



It is identical to the sender#snEDistinguishedName. Thiselement has one optional at-tribute:

• type : type of the networknode that generated thefile.

Example:

RNC, SGSN

traceRecSession This element contains thetraced data associated to acall of a traced mobile. It has 3attributes :

• traceSessionRef : uniquetrace identifier provided atthe trace activation by theOperator or allocated bythe management system.

• traceRecSessionRef : Re-quired attribute thatprovides a unique identifierof a traced call. This identi-fier is attributed to all tracerecords associated to acall. It is unique for a peri-od of time sufficient toavoid any collision.

• stime : optional attributethat provides the start timeof the call.

ue UE identifier provided in traceactivation messages. It can beIMSI or IMEI. It has 2 requiredattributes:

• uetype : user equipmentidentifier type (IMSI,IMEIor Public User Id)

• ueid : the ue identifiervalue

string

evt The evt element contains theinformation associated with atraced message. It has the fol-lowing required attributes:

• function : function nameassociated with the tracedmessage.

initiator (opt) target (opt) mes-sage (opt) cause (opt) IE (0..)IEGroup (0..) object (0..)



Example:

RRC, Iu CS, Iub, Intrafrequency measure-ment, Gb

• name : protocol messagename

• changeTime : time differ-ence with the beginCollec-tionTime. It is expressed innumber of seconds andmilliseconds (nbsec.ms)

• vendorSpecific : booleanvalue that indicates if themessage is vendor specif-ic (true) or not (false).

initiator nEDistinguishedName of NEinitiator of the protocol mes-sage. The string may beempty (i.e. string size =0) incase the initiator is the senderor the mobile. This elementhas one optional attribute:

• type: type of the networknode that initiate the mes-sage.

Example:

RNC, SGSN

string

target nEDistinguishedName of NEtarget of the protocol mes-sage. The string may beempty (i.e. string size =0) incase the target is the senderor the mobile. This elementhas one optional attribute:

• type : type of the networknode that receives themessage.

Example:

RNC, SGSN

string

message The element value is the hexa-decimal, ASN.1- encoded formof the message. This XML ele-ment has two required attrib-utes:

string



• protocol : protocol nameassociated with the event.

Example:

RanapSee supported protocolsbelow.

• version : protocol version

cause (global) The element value is the eventcause value The value is theENUMERATED value carriedby the message as defined in3GPP TS. Unknown or unex-pected cause values are writ-ten in numerals. This XML ele-ment has one required attrib-ute:

• type : cause type.

Example:

failure cause may beunknown

string

IEgroup (global) This element contains one ormore IE. This XML elementhas one optional attribute:

• name : IE group name

Example:

RAB parameters

IE (1..) IEGroup (1..) object(1..)

IE (global) This element contains thevalue of an IE decoded from atraced message. This XMLelement has one required at-tribute:

• name : IE name

Example:

Minimum DL Power

string

object This element contains IE asso-ciated with a specific object.(e.g. radio link, RAB). It has 2required attributes :

• type : object type

Example:

Radio link, RAB

• id : object identity

cause (opt) IE (0..) IEGroup(0..)



Example:

RABid

Among those tags, some are considered as specific, which means that the information they containis defined by the tag itself. The table above fully defines these tags and the meaning of theircontents.

On the contrary, the <evt>, <IE>, <IEGroup>, and <object> tags are generic, which means that theircontents cannot be analyzed without using the discriminating information contained in their attributes,and in the tags above them. For <evt> the discriminating attributes are function and name. For <IE>and <IEGroup> the name attribute is the discriminating one, and for <object>, the discriminatingattribute is type. The contents of the generic tags depend on the value of their discriminating tags,and the <evt> tag where they appear.

Table 2 Tags specific to object traces

XML element Description Contents

traceCollection This is the top-level element. Itidentifies the file as a collec-tion of trace data. It has 2 at-tributes:

• version : file format versionapplied by the sender. Thedefault format version shallbe 01.

• collectionBeginTime :timestamp that refers tothe start of the first tracedata that is stored in thisfile. It is a completetimestamp including day,time and delta UTC (checkif it is UTC) hour.

vendor (optional), sender,tracedObject

tracedObject This element contains thetraced data associated to acall of a traced mobile. It has 3attributes :

• traceSessionRef: uniquetrace identifier provided atthe trace activation by theOperator or allocated bythe management system

• type: Required attributethat provides the tyupe ofthe traced object : may beCell or NeighbouringRNC.

ue evt (0..)



evt The evt element contains theinformation associated to atraced message. It has the fol-lowing required attributes:

• function : function nameassociated to the tracedmessage.

Example:

RRC, Iu CS, Iub, Intrafrequency measure-ment, Gb

• name : protocol messagename

• changeTime : time differ-ence with the beginCollec-tionTime. It is expressed innumber of seconds andmilliseconds (nbsec.ms)

• vendorSpecific : booleanvalue that indicates if themessage is vendor specif-ic (true) or not (false).

initiator (opt), target (opt), tra-cedIds (opt), message (opt),cause (opt), ue (opt),traceRecSessionRef, IE (0..),IEGroup (0..), object (0..)

traceRecSessionRef A system-generated string thatuniquely identifies the call thatgenerated the present event.

String

tracedIds The empty element lists thecell ids that are associatedwith the particular trace, ifavailable. The element ismissing if there is no cell IDavailable.

• idList : Comma-separatedlist of object ids as con-tains no blanks.

— OT-cell : list of fddCellcellId

— OT-Iur : neighbouringRNC rncId

— OT-IuCS : CS-<#>(with the network ID )

— OT-IuPS : PS-<#>(with the network ID )

— OT-Iubc : interface isunique, element is ab-sent

empty



protocol attribute : In the <message> tag, the protocol attribute takes the name of the protocol,which may be 3gppNbap, Nbap, Ranap, Rnsap, Pcap or Rrc. In order to allow on-demanddecoding in the case of Rrc, the channel name is concatenated with the Rrc string. Possiblechannels are DL-DCCH, UL-DCCH, DL-CCCH, UL-CCCH, PCCH, DL-SHCCH, UL-SHCCH,BCCH-FACH, BCCH-BCH, MCCH. If an unknown or missing value is sent, the channel will beNO_CHPDU_ID.

version attribute: In the <message> tag, the version attribute indicates which version of a givenASN.1 description was used to encode the data block. It is used by the on-demand decoders todecode the blocks. The version number is an Alcatel-Lucent internal flag, the supportednumbers vary according to the UA version.

Protocol 3GPP standard ref UA06.0

3gppNbap TS 25.433 0005 v6c0, dec 2006

Ranap TS 25.413 0009 v6c0, dec 2006

Rnsap TS 25.423 0006 v6c0, dec 2006

Pcap TS 25.453 0003 v6a0, dec 2005

Rrc TS 25.331 0009 v6c0, dec 2006

Sabp TS 25.429 0001 v6.20, dec 2004

causes attribute: In the <cause> tag, the attribute type indicates which of the following tablesshould be consulted. The strings in the following tables are the ones presented in the XML files.

Table 3 List of Cause values for the <cause type = estabcause> (vendor specific)

Cause value Cause text

0 Originating Conversational Call

1 Originating Streaming Call

2 Originating Interactive Call

3 Originating Background Call

4 Originating Subscribed traffic Call

5 Terminating Conversational Call

6 Terminating Streaming Call 7

7 Terminating Interactive Call 8

8 Terminating Background Call 9

9 Emergency Call 10

10 Inter-RAT cell re-selection 11

11 Inter-RAT cell change order 12

12 Registration 13

13 Detach 14

14 Originating High Priority Signalling 15



15 Originating Low Priority Signalling 16

16 Call re-establishment 17

17 Terminating High Priority Signalling 18

18 Terminating Low Priority Signalling 19

19 Terminating - cause unknown 20

20 MBMS Reception

21 MBMS PTP RB Request

default unknown cause = <cause#>

Table 4 List of Cause values for the <cause type = RRCRelCause> (3GPP)


0 normal event

1 unspecified

2 pre-emptive release

3 congestion

4 re-establishment reject

5 user inactivity

6 directed signalling conn

default unknown cause = <cause#>

Table 5 List of Cause values for the <cause type = IuRelCause> (3GPP)


1 RAB pre-empted

2 Trelocoverall Expiry

3 Trelocprep Expiry

4 Treloccomplete Expiry

5 Tqueing Expiry

6 Relocation Triggered

7 TRELOCalloc Expiry

8 Unable to Establish During Relocation

9 Unknown Target RNC

10 Relocation Cancelled

11 Successful Relocation

12 Requested Ciphering and/or Integrity Protec-tion Algorithms not Supported

13 Conflict with already existing Integrity protec-tion and/or Ciphering information

14 Failure in the Radio Interface Procedure



15 Release due to UTRAN Generated Reason

16 User Inactivity

17 Time Critical Relocation

18 Requested Traffic Class not Available

19 Invalid RAB Parameters Value

20 Requested Maximum Bit Rate not Available

21 Requested Guaranteed Bit Rate not Available

22 Requested Transfer Delay not Achievable

23 Invalid RAB Parameters Combination

24 Condition Violation for SDU Parameters

25 Condition Violation for Traffic Handling Priori-tyRelocation TRelocationriggered

26 Condition Violation for Guaranteed Bit Rate

27 User Plane Versions not Supported

28 Iu UP Failure

29 Relocation Failure in Target CN/RNC or TargetSystemRelocation

30 Invalid RAB ID

31 No remaining RAB

32 Interaction with other procedure

33 Requested Maximum Bit Rate for DL not Avail-able

34 Requested Maximum Bit Rate for UL not Avail-able

35 Requested Guaranteed Bit Rate for DL notAvailable

36 Requested Guaranteed Bit Rate for UL notAvailable

37 Repeated Integrity Checking Failure

38 Requested Request Type not supported

39 Request superseded

40 Release due to UE generated signalling con-nection release ported

41 Resource Optimisation Relocation

42 Requested Information Not Available

43 Relocation desirable for radio reasons

44 Relocation not supported in Target RNC orTarget system

45 Directed Retry



46 Radio Connection With UE Lost

47 RNC unable to establish all RFCs

48 Deciphering Keys Not Available

49 Dedicated Assistance data Not Available

50 Relocation Target not allowed

51 Location Reporting Congestion

52 Reduce Load in Serving Cell

53 No Radio Resources Available in Target cell

54 GERAN Iu-mode failure

55 Access Restricted Due to Shared Networks

56 Incoming Relocation Not Supported Due ToPUESBINE Feature

57-64 Unknown Radio Network Layer Cause. value =<cause#>

65 Signalling Transport Resource Failure

66 Iu Transport Connection Failed to Establish

67-80 Unknown Transport Layer Cause. value =<cause#>

81 User Restriction Start Indication

82 User Restriction End

83 Normal Release

84-96 Unknown NAS Cause. value = <cause#>

97 Transfer Syntax Error

98 Semantic Error

99 Message not compatible with receiver state

100 Abstract Syntax Error (Reject)

101 Abstract Syntax Error (Ignore and Notify)

102 Abstract Syntax Error (Falsely ConstructedMessage)

103-112 Unknown Protocol Cause. value = <cause#>

113 Operation and Maintenance Intervention

114 No Resource Available

115 Unspecified Failure

116 Network Optimisation

117-128 Unknown Miscellaneous Cause

default non-standard cause

256 Invalid Cause Value



IE rncExceptionInd: This IE may appear in any <evt> tag, that can hold a <message> tag. Itmeans some sort of error appeared on the RNC when creating a record containing an ASN.1protocol message. The possible values of the IE are summarized in the table below :

Table 6 List of values for the <IE> attibute

<IEname = rncExceptionInd> string value Meaning

NOT_SPECIFIED Internal RNC error when reporting the ASN.1message, if it exists, the contents of the<message> tag are unreliable, if decoding ofthe ASN.1 bytes is attempted, the resultsshould be discarded.

OVERSIZED_ASN1_MSG_IS_TRUNCATED Too many ASN.1 bytes to report, the<message> tag holds the first bytes of themessage. Partial decoding of the ASN.1 maybe possible, decoding result is partial, but reli-able.

OVERSIZED_ASN1_MSG_IS_DISCARDED Too many ASN.1 message bytes to report, the<message> tag is missing. No decoding ispossible.

OVER-SIZED_CONTEXT_FULL_DATA_IS_DISCARDED

Too many XDR bytes to report in a data block.Contex-full data block is missing.

DTD versioning

The release of the DTD referred to in the XML document header is included in:

• the DTD file name (for example, ".../32.108-contrib01.dtd ", ".../objectTrace.02.dtd " or"?/mgtData.01.dtd ")

• the body of the XML document: value of the attribute version in the traceCollection element (forexample, traceCollectionf version="01" ....)

The following figure is an example of the trace DTD versioning.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<!DOCTYPE mdc SYSTEM "/opt/nortel/data/utran/callTrace/32.108-contrib01.dtd">

or


<!DOCTYPE mdc SYSTEM "/opt/nortel/data/utran/callTrace/objectTrace.02.dtd">

or


<!DOCTYPE mdc SYSTEM "/opt/nortel/data/utran/objectTrace/mgtData.01.dtd">



Valid character set

The XML documents produced by ADI only use UTF-8 characters (ISO 10654-1): the binary valuesare stored as hexadecimal strings.

Basic types

The XML element values are always strings. Depending on the 3GPP Recs, these strings can beinterpreted as:

• a signed or unsigned integer (for example, 12, -6).

• floating point values signed or not, and can have an optional exponent part (for example, -3.5,1.0567e+03). The separator between the fractional part and integer part is the dot character ('.').

• boolean True or False.

• enumerated as literal strings (for example, speechData). The possible values are defined by theASN.1 syntax of the related protocol.

• binary rendered as hexadecimal strings using the following characters: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9,A, B, C, D, E, F.

• bit string rendered as a sequence of 0 and 1 (for example, 01001101).

UE identifiers

A mobile can have the following identifiers:

• IMSI (6 to 15 decimal digit sequence)

• IMEI (15 hexadecimal digit sequence)

• TMSI (4 hexadecimal digit sequence)

• PTMSI (4 hexadecimal digit sequence)

Trace rec session identifier

use the trace rec session identifier to identify a call. This identifier is given in the traceRecSessionRefattribute of the traceRecSession element.

Timestamps

Each trace records is likely to have one timestamp given by the original application running on anRNC TMU (proc timestamp). Each produced XML file uses the cbt or cet element to encode a fulltimestamp ( day+local time+#GMT).

This timestamp is produced at the RNC OMU level for the first trace record of the file. The cbtelement has the following syntax:

<YYYYMMDD>.<hhhhmmss><#GMT >

See the following table for an interpretation of the codes:



Code Description

YYYY The 4-digit year

MM The month of the year (01,02,...,12)

DD The day of the month (01,02,...,31)

hh The 2-digit hour (00,01,...,23) (local time)

mm The 2-digit minute of the hour (00,01,...,59) (local time)

ss The 2-digit second of the minute (00,01,...,59) (local time)

#GMT Difference between local time and Greenwich Meridian Time (+/-hhmm). Itchanges according to location and time of year (daylight saving time).

For example, on April 22, 2004 at 10:15:13 in Paris, the #GMT would be +0100thus the cbt value is <cbt>20040422101513+0100</cbt> whereas on April 22,2004 at 18:12:23 in New York, the #GMT would be -0500, and thus the cbtvalue is <cbt>20040422181223-0500</cbt>.

Each traced information has its own changeTime (c attribute) value expressed in seconds andmilliseconds since the collectionBeginTime (cbt). Milliseconds are always expressed as zeroed-threedigit values (%03 d); for example, 13.045.

Traced object format

The Managed Objects contained in the trace record files are identified according to the Rec 32.106-8

A Distinguished Name (DN) is built as a series of comma-separated name components referred to asRelative Distinguished Names (RDN).

DN ::= RDN [',' RDN]*

The syntax of these name components is the following:

RDN ::= className '=' identifierValue

There is no space character between RDNs; the only possible separator is "," (comma).

The className element is not the name of the naming attribute (for example rncId) but the name ofthe class (for example RNC).

No assumption can be made on the character case used by className: rnc. RNC and RNC identifythe same class.

The identifierValue can be an integer or a string value.

The character cases used by identifierValue must be distinguished: abcd is not equivalent to AbcD.

The identifierValue strings accept any character except special, where special can be one of thefollowing characters:

• ,



• =

• CR

• LF

• +

• <

• >

• #

• ;

• \

• *

For example, the RNC 1 NodeB abcd is identified by the following DN: RNC=1,NodeB=abcd.

This object format only applies to the sn tag.

Trace events

The trace events supported are the following:

• UeMgt (starttime, stop time, extracted from some specific RRC events)

• Rrc (RRC events and RRC measurements)

• Iu (RANAP events)

• Iub (NBAP events)

• Iur (RNSAP events)

• IuBC (SABP events)

• Iupc (PCAP events)

• ALCAP

• Dtap (transparent data events on Rrc and Iu interfaces)

• Error signaling plane (erroneous or out-of-sequence messages on all interfaces)

• Snapshot C-node (important call processing events)

• Quality of Service events (QoS)

• I-Node power control (DHO events)

• I-Node RLC traffic (RLC events)

• DHO Power control

• CTn

For further information about these events, see UTRAN Call Trace Events Dictionary(UMT/SYS/DD/009157).



8 Operational Alarm on thresholds for access observationsThis chapter describes the Alarms on thresholds function for the Access Network.

This part is split into the following topics:

• Overview of Alarm on thresholds

• Architecture of Alarm on thresholds

• Syntax of Alarm on thresholds

• Tools of Alarm on thresholds

• Hysteresis

• Alarm management



8.1 Overview of Alarm on thresholdsThe Alarm on threshold function allows the operator to be quickly informed of significant counterobservation related events. The authorized users can set the threshold (minor, major and critical) forperformance event, and define rule sets for violation event.

The alarm on thresholds feature consists of three functions: counter collection, threshold detectionand alarm injection.Counter collection enables the data collection from the counters the thresholds of which are set.Threshold detection involves the comparison of observed measurement values against the valuespecified in a threshold.Alarm injection involves the creation of an alarm when a threshold is crossed.

ADI detects the threshold trespassing at the server level. In the event of state change (forexample, when a threshold exceeds or returns to a normal value), an alarm start or an alarmend is notified to the access EMS software. The alarm is pushed to the upper layer applicationsAccess-DA, FMBB, Alarm window, HFB, and 3GPP Alarm IRP.

APM performs MOD to RAN Model mediations. This feature allows APM to push alarms to the mainserver in a correct format. ADI is responsible for:

• the RAN Model to 3GPP containment mediation

• the XML file production.



8.2 Architecture of Alarm on thresholdsThis section describes the alarm thresholds architecture for access observations.

The alarm thresholds are defined in a static configuration file.

The threshold conditions are checked when the observation records are received from the RNC orthe NodeB. These conditions are the following:

• a start alarm is set if the threshold is crossed over,

• an end alarm is set if the threshold is crossed down.

It is possible to manage hysteresis to avoid sending multiple alarm start/end when the successivecounter values are close to the threshold value.

A threshold is identified by the combination of the two following criteria:

• the counter name which it is associated with.

It means that there is only one threshold defined for a given counter.

• the threshold scope, which can be an observed class or a specific observed object.

If a counter threshold is defined both at the class level and at the object instance level, the objectinstance definition supersedes the class definition for threshold detection.

To associate the threshold set rules and conditions with the counters you can perform the followingactions :

• Configuring the alarm thresholds for a counter.

This can be performed via a dedicated XML definition file located in the directory/opt/nortel/data/utran/custom. There is one dedicated configuration file by NE type: one forthe Node B counters, one for the C-Node counters.

The threshold configuration files are not overwritten by the OAM upgrades or OAM patches.

To learn how to configure alarm thresholds, see the Configuration of alarm thresholds for accessobservations procedure.

• Hysteresis management.

This function avoids the emission of multiple start and end alarms when the successive countervalues are close to the threshold value.

• Alarm browsing.

The alarms can be viewed either in the Alarm window or through the Historical Fault Browser.The alarms are also sent through the 3GPP Interface-N.

Before removing an alarm on thresholds definition file, you must manually clear the alarms that arebeing raised.



8.3 Syntax of alarm on thresholdsThe observation thresholds can be defined thanks to a dedicated configuration file.

Use the threshold syntax to define:

• Threshold scope:

this can be an observed class or an observed object.

• Threshold type:

this can be standardized or not.

• Threshold comparison operators:

> (up) or < (down).

• Optional reference periods (in minutes):

0, 15, 30, 60. If provided, the normalization is applied to the counter value before comparison(which means that the counter value is converted to an equivalent refPeriod value. A refPeriodof 0 (default value) means that normalization is not needed.

Example:

Let the refPeriod be set to 60 minutes:

— if the counter value n has been measured for a 12-minute observation duration, itshour-equivalent value is 5 x n.

— if the counter value a has been measured for a 15-minute observation duration, itshour-equivalent value is 4 x n.

— if the counter value a has been measured for a 30-minute observation duration, itshour-equivalent value is 2 x n.

— if the counter value a has been measured for a 60-minute observation duration, itshour-equivalent value is n.

The observation duration is not the granularityPeriod: it is the real measurement period at NElevel.

• Threshold values startValue and endValue:

these are expressed as integers or floating values.

• Alarm severity.

Its status can be one of the following:

— warning

— minor

— major

— critical



The threshold syntax is based on XML with the following DTD:

Figure 16 Threshold syntax DTD

The threshold syntax DTD is case-sentitive.

It contains the following attributes for the "THD" element:

• class

The class name is defined as follows: <class name> := "<class relative identifier>".

Example:

class = "FDDCell"

• objects



The syntax of the objects is defined as follows:

— <object> := <object relative distinguished name>

— <object relative distinguished name> := <object type name> = "<object relativeidentifier>".

Example:

object = "RNC=rncid,NodeB=5,FDDCell= cell user label 1"

• counter

The counter name is defined as follows: <counter name> := "[A-Za-z][._0-9A-Za-z/]".

Example:

counter="hoFailures"

• endValue

This parameter is optional. It is used only for hysteresis. See the Hysteresis section for moreinformation.

• refPeriod

This parameter is optional. If the refPeriod is not provided, it is not taken into account.

The possible values (in minutes) are 0, 15, 30 and 60. By default, the refPeriod is 0, whichmeans that no normalization is applied.

The following table gives the mapping of the object type names on the class names:

Table 7 Mapping of object type names on object class names

Object type name Class name

RNC R or RNC

NodeB R/Nodeb or NodeB

FDDCell R/Nodeb/FddCell or FDDCell

DlAsConfId Depending on the container object, the class name can be one of thefollowing classes:

• R/DlAsConfId

• R/Nodeb/FddCell/DlAsConfId

• R/NeighbouringRnc/DlAsConfId.

UlAsConfId R/UlAsConfId

DlRbSetId R/DlRbSetId

NeighbouringRNC R/NeighbouringRnc or NeighbouringRNC

RNCEquipment R/RncEqp or RNCEqp

CNode R/RncEqp/CN or CNode

OMU R/RncEqp/CN/OMU or OMU



Object type name Class name

TMU R/RncEqp/CN/TMU or TMU

CC1 R/RncEqp/CN/CC or CC

BTSEquipment B

BTSCell B/BTSCell

VCC B/ATMVCC

PCM B/PCMLink

PassiveComponent B/PassiveComponent

PA B/PassiveComponent/PA

ImaGroup B/IMAgroup

IpInterface B/IPinterface

Board B/Board

TRM B/Board/TRM

CCM B/Board/CCM

CEM B/Board/CEM

HSSPC B/Board/HSSPC

INode P

ANode P

Lp P/Lp

AtmPort P/AtmPort

The following table gives the mapping of the object type names on the object relative identifiers:

Table 8 Mapping of object type names on object relative identifiers

Object type name Object Relative Identifier

RNC R or RAN RNC Id

NodeB RAN RDN Id

FDDCell FDDCell user label

DlAsConfId RAN DLAccessStratumConf Id

UlAsConfId RAN ULAccessStratumConf Id

DlRbSetId RAN DLRadioBearerSet Id

NeighbouringRNC RAN NeighbouringRNC Id

RNCEquipment RAN RNCEquipment Id

CNode RAN CNode.RDN Id

OMU RAN OMU Id

TMU RAN TMU Id

CC1 RAN CC1 Id

BTSEquipment RAN BTSEquipment user label



Object type name Object Relative Identifier

BTSCell RAN BTSCell RDN Id

VCC RAN VCC RDN Id

PCM RAN PCM RDN Id

PassiveComponent RAN PassiveComponent Id

PA RAN PA Id

ImaGroup RAN ImaGroup RDN Id

IpInterface RAN IpInterface RDN Id

Board RAN Board Id

TRM RAN TRM Id

CCM RAN CCM Id

CEM RAN CEM Id

HSSPC RAN HSSPC Id

INode RAN INode NE Id (Nortel Multiservice Switch Id/Name)

ANode RAN ANode NE Id (Nortel Multiservice Switch Id/Name)

Lp BDF Lp Id

AtmPort BDF AtmPort Id

The following figure shows an example of alarm threshold syntax.



Figure 17 Example of alarm threshold syntax

The list of counters is provided in the/opt/nortel/config/utran/gpo/CP_APM_UTRAN_xdrCounterTable.cfg file.

Their associated class is provided inthe/opt/nortel/config/utran/gpo/CP_APM_UTRAN_xdrClassTable.cfg file.



8.4 Tools of alarm on thresholdUse the fmkpm_thdsyncheck.sh and fmkpm_thdreload.sh tools to define the counter thresholds.These tools are used to check and load counter thresholds files defined by the operator.

These tools are executed from the Unix command line as user oamops.

Check of the threshold definition file syntax

The fmkpm_thdsyncheck.sh tool allows you to check the XML configuration file syntax.

This tool is located in the /opt/nortel/shell/utran directory.

The syntax is the following:

fmkpm_thdsyncheck.sh <action>

where <action> specifies the action the PM server is required to take; in this case, it is <filetype><filename>;

• <filetype> is the XML counters file. It can be OBS_NODE_B or OBS_C_NODE,

• <filename> is the counter thresholds file with the full path.

Example:

The following command checks the syntax of the Node B threshold definition fileCP_APM_UTRAN_NodeBThresholdDef.xml:

/opt/nortel/shell/utran/fmkpm_thdsyncheck.sh OBS_NODE_B/opt/nortel/data/custom/utran/CP_APM_UTRAN_NodeBThresholdDef.xml

You can find in the log file /opt/nortel/logs/pmf/fmkpm_thdsyncheck.log:

[3916:New IIOP Connection (desirade:15001)][3916:New Connection (dominique,IT_deamon,*,root,pid=8853,optimised)][3916:New IIOP Connection (dominique:1612)][3916:New IIOP Connection (dominique:1611)]The threshold definition file is valid.

Loading of the threshold definition file

Use the fmkpm_thdreload.sh tool to force the reloading of an updated threshold definition file and tomodify the threshold value during the OAM execution.

This tool is located in the /opt/nortel/shell/utran directory.

The syntax is the following:

fmkpm_thdreload.sh <filetype>

where <filetype> is the XML counters file. It can be OBS_NODE_B or OBS_C_NODE.

Example:



For example, the following command loads the Node B threshold definition fileCP_APM_UTRAN_NodeBThresholdDef.xml:

/opt/nortel/shell/utran/fmkpm_thdreload.sh OBS_NODE_B

You can find the following in the log file /opt/nortel/logs/pmf/fmkpm_thdreload.log:

[4179:New IIOP Connection (desirade:15001)][4179:New Connection (dominique,IT_deamon,*,root,pid=8853,optimised)][4179:New IIOP Connection (dominique:1611)][4179:New IIOP Connection (dominique:1612)]Load threshold definition file successfully.



8.5 HysteresisThis section describes how to avoid sending multiple start/end alarms when the successive countervalues are close to the threshold value.

To manage the hysteresis, use the optional endValue as shown below:

• For the up thresholds, the endValue must be less than or equal to the startValue (this meansthe alarm will be cleared only if the counter value reaches a lower value).

• For down thresholds, the endValuemust greater than or equal to the startValue (this means thealarm will be cleared only if the counter value reaches a higher value).

If no endValue is provided, it is by default equal to the startValue.



8.6 Alarm managementThis section introduces the following topics:

• Alarm definition

• Protection against flooding

Alarm definition

The probableCause associated with threshold crossings is {5676, "thresholdCrossed"} as shown inthe following table:

Attributes Value

Time Obs record collectionTime (=scanInitTime + obsDuration)

NotificationID

SpecificProblem Threshold trespassing on counter<counterName>

Alarm Type QoS

Probable Cause thresholdCrossed

NE user label

subComponentID follow RAN containment

AdditionalText AdditionalText information sent by ADI as follows:

• Flooded alarm: yes | no

• Counter name: %s

• Comparison operator: GREATER | LOWER

• Threshold value: %f

• Counter value: %f

• Threshold Reference Period (min): %d

• obsDuration (min): %d

Alarm Severity Depends on threshold definition

Alarm on threshold flooding

This section introduces the following topics:

• Alarm flooding mechanism

• Protection against flooding

Alarm flooding mechanism

The alarm flooding mechanism has the following characteristics:

• When the flooding occurs, no new single alarms are raised on the same counter in the next



observation periods, until the flooded alarm is cleared, and this even if the threshold iscontinuously being over-crossed.

• The alarm flooding condition is always examined against the total number of threshold-crossedobject instances in the CURRENT observation period.

• The individual start alarms raised on the same counter before the flooding observation periodmust be cleared separately and independently by the corresponding end alarms. They cannot becleared by the start or end flooded alarms.

The following examples show how the alarms are cleared in case of flooding.

Examples:

1 • Granularity Period 1:

The counter <counter_a> of the object <object_a> goes beyond the threshold. Anew alarm <new_alarm_a> is raised on the object <object_a>.

• Granularity Period 2:

The alarm flooding occurs on the counter <counter_a>. A new flooded alarm<new_flooded_alarm_b> is raised on the root object <root_object_a>.

The counter <counter_a> of the object <object_a> still crosses the threshold. Nonew alarm is raised on the object.


The counter <counter_a> meets the clearing condition of the flooded alarm. A clearalarm <clear_flooded_alarm_b> is raised on the root object <root_object_a> toclear the associated flooded alarm <new_flooded_alarm_b>.

The counter <counter_a> of the object <object_a> still crosses the threshold. Noclear alarm is raised on the object.


The counter <counter_a> goes within the threshold. A clear alarm <clear_alarm_a>is raised on the object <object_a> to clear the associated single alarm<new_alarm_a>.

2 • Granularity Period 1:

The counter <counter_a> of the object <object_a> goes beyond the threshold. Anew alarm <new_alarm_a> is raised on the object <object_a>.


The alarm flooding occurs on the counter <counter_a>. A new flooded alarm<new_flooded_alarm_b> is raised on the root object <root_object_a>.

The counter <counter_a> of <object_a> goes within the threshold. A clear alarm<clear_alarm_b> is raised on the object <object_a> to clear the associated single



alarm <new_alarm_a>.


The counter <counter_a> meets the clearing condition of the flooded alarm. A clearalarm <clear_flooded_alarm_b> is raised on the root object <root_object_a> toclear the associated flooded alarm <new_flooded_alarm_b>.

The counter <counter_a> of the object <object_a> is still within the threshold. Noclear alarm is raised on the object.

Protection against flooding

Whenever numerous alarms are generated for a given threshold, these alarms are replaced bya single alarm, held by the container object which is always the root object of the alarming NE inthe RAN model. That means RNC for RNC CNode, RNC/RNCEquipment/INode for INode, andBTSEquipment for BTS.

When an alarm flooding condition is detected, the single start alarm raised for the flooding conditionalways has a critical severity to emphasize the importance of the flooding problem.

As for flooded alarms, the <classId>, counter value and threshold value in the AdditionalText fieldare left empty, because the flooded alarm is used to suppress numerous individual alarms withdifferent target class IDs, counter values and threshold values.



9 Access Data Interface (ADI) and Management Data Provider (MDP)applications

This section is an overview of ADI and MDP, applications involved in the performancemanagement process.

Access Data Interface (ADI)

The ADI application provides the interfaces for Access Performance and Configuration databetween the Access Performance Management (APM) and NPO or external applications. TheAPM uploads the following counters:

• counters from Node B

• wireless counters from RNC I-Node and C-Node

• non-wireless (Nortel Multiservice Switch platform) counters from the RNC I-Node and POC

• trace data from the RNC C-Node and I-Node

The APM additionally carries out decoding and mediation to provide the ADI with trace files based onconsistent formats and object identifications. For example the UTRAN messages traced by the RNCand not coded in ASN.1 yet are decoded in ASCII by the APM.

The ADI mediates counters and trace data from the native format into XML files. These files areexported to NPO, WQA or RFO applications.

The counter XML files at the ADI output are 3GPP-compliant but the trace data files are not.

Management Data Provider (MDP)

The MDP application is used internally to convert the MSS (Nortel Multiservice Switch) observationrecords into an ADI-processable format

For the Nortel Multiservice Switch-based devices, the MDP collects raw data. In the Access domain,MDP primarily converts Nortel Multiservice Switch statistics collected by the APM into Bulk DataFormat (BDF) file format.



10 Wireless Quality Analyzer (WQA)WQA is an optional application designed to provide ability to reflect graphically Call Trace informationissued from Utran networks.

It is deployed in a ROC configuration but it is not hosted by the WMS servers and it requires adedicated hardware.

Introduction

WQA is designed to provide ability to reflect graphically the following Traces information issuedfrom the UTRAN networks:

• CTn

The Utran Neighboring Tuning feature allows to build proposal to optimize the neighboringdeclaration based on a dedicated UTRAN information flow.

• CTx

CTx is the whole of several types of Call Trace. This feature allows customers to optimizethe UTRAN sub system, mainly the radio aspects, without requirement of drive tests. TheUTRAN traces bring very detailed information on UTRAN behavior. This information canhelp on engineering analysis of the network performances. In OAM6.0, two KeyPerformance Indicators (KPI) are available and these KPI are computable throughinformation available in CTb and CTg trace sessions.

• The Call Failure Traces (CFt) data are also collected to allow the customers to optimize theUTRAN through the analysis of call failures.

Functional architecture

WQA offers a web-based interface, with a server running on PC hardware.

WQA is connected to the WMS through a LAN.

Two different steps are part of the WQA post-processing activity: data collection and parsing datareporting

The CTn and CTx data is collected from the UTRAN and mediated to an XML file in WMS (see Tracedata collection and mediation. The data is not displayed at the WMS level but in WQA.

The downloaded data is forwarded to the WQA core where processing occurs. The processed data isstored in the WQA data storage. Data Analyzer is used to retrieve processed data and organize itinto logical reports that are accessible via http to the WQA users.

Neighbouring Call Trace processing



WQA processes the Neighboring Call trace information to provide the users with proposal foradding or removing neighboring declaration.Work orders can then be generated to apply the changes into WMS.

The CTn measurements are provided on an XML external interface by the WMS. Theneighboring tuning module of WQA then uploads the data on this external interface andprovides the users with recommendations for all selected cells on:

• Cells that should be added to the neighboring list

• Cells that should be removed from the neighboring list

The users then select a sub set of the proposed modifications and loop information back to WPS.

Reporting can be done on data organized in the database. Predefined reports defined byAlcatel-Lucent are also available in WQA.

CTx analyzis

The post processing of the CTb and CTg traces data by WQA allows computing KeyPerformance Indicators not accessible through the counters (composite formulas of counters),but computable through information available in Call traces messages.

Fine tuning is not covered by this feature and is still the responsability of RFO.

A lot of files are produced by the CTb and CTG sessions, so the file size might be big. The filesize will be reduced by keeping the useful functions only (RRC, UEMgt).

CFt analysis

WQA DocumentationTable 9 WQA for WNMS documentation

Title Description

Alcatel-Lucent 9351 Quality Analyzer - Installation Guide (CTn part) NN-20500-126The WQA Administration Guide provides the software en-gineer with the steps to install the WQA product.

Alcatel-Lucent 9351 Quality Analyzer - Administration Guide (CTn part) NN-20500-127The WQA Administrator Guide provides information on ad-ministration of the WQA product, including user accessmanaging and report schedules, and objects exporting andimporting within the WQA repository.

Alcatel-Lucent 9351 Quality Analyzer - User Guide for CTN module NN-20500-128This guide covers the following features and functions ofWQA:

• WQA access:login/logout, managing account, changinggeneral options of the WQA interface, changing reportediting preferences

• Call trace neighboring analysis reports:user interface



Title Description

overview, access and description of the sets of stand-ard and predefined reports.

• User functions:functions that allows to design, and de-ploy enterprise analytic reports with the web browser in-terface.

Alcatel-Lucent 9351 Quality Analyzer - Troubleshooting Guide (CTn part) NN-20500-129This document provides additional information about pos-sible issues during installation of the WQA product and theappropriate solutions.

Alcatel-Lucent 9351 Quality Analyzer - User Guide for CTX module NN-20500-165This document describes the basic features of the user in-terface and how to perform the access to the standard re-ports.

It also describes the set of on-demand and cached CTx re-ports. Each report is described in a separate section.

Alcatel-Lucent 9351 Quality Analyzer - User Guide for CFT module NN-20500-164This document describes the basic features of the user in-terface and how to perform the access to the standard re-ports.

It also describes the set of predefined CFt reports. Each re-port is described in a separate section.



11 Network Performance Optimizer (NPO)This section is an overview of Network Performance Optimizer (NPO), the performance reportingsolution based on the internal platform.

NPO Overview

NPO is a GUI driven application with full flexibility for reporting (drag and drop, markers etc) andcreation of indicators. It offers a full range of multi-standard QoS monitoring and radio networkoptimization facilities:

• Powerful Graphical User Interface supporting all efficient use of the MS-NPO functions

• QoS analysis

• QoS decrease cause diagnosis

• Radio resource configuration tuning

• Cartographic telecom management

• Customizing

This product includes a powerful Oracle™ database containing performance measurements andcalculated indicators. Based on them, the detection of QoS degradation is done much faster.

NPO Documentation

For detailed information about NPO, see the following documents:

• NPO User Guide (3BK 21376 AAAA PCZZA)

This document is an introductory information about the NPO application. It describes:

— NPO overview, architecture and functions

— NPO main features

— how to run NPO applications from the NPO Client iconbox

• NPO Administration Guide (3BK 21386 AAAA PCZZA)

This guide describes how to perform administrative tasks for the Network PerformanceOptimizer (NPO), the basic principles of NPO administration, how to open administrationpages, how to start Data Management and NPO Import /Export Management, the NPOconfiguration tasks.

• NPO / 9953 MP Introduction (3BK 21370 AAAA PCZZA)

This guide describes how to use the Network Performance Optimizer (NPO) in order to viewand manage counter and indicator values for various network objects, and to know how tomonitor and optimize the radio network.



— current terminology introduction

— initialization and performing of simple tasks using the Analysis Desktop main window

— common tasks in the functional windows

— common tasks when dealing with topology objects

— how to manipulate objects as a group with objects zones

— how to manipulate Network Objects within Topology Classifications

— how to manipulate functions within the Function Classifications

— how to manage the Working Zone editor

— how to manage counters and indicators

— how to manage radio parameters

— use of reference values

— overview of free fields

— management of view templates

— how to manage reports

— how to perform diagnosis of QoS problems

— how to use Post-Its (user defined comments associated with topology objects)

— favorites (user preferred functions for a friendlier and quicker navigation)

— setting the QoS requirement levels

• NPO Diagnosis Development Guide (3BK 21379 AAAA PCZZA)

• Alcatel-Lucent 9359 Network Performance Optimizer - Indicators Reference Guide (3BK21172 AAAA TQZZA)

This documentation is composed of 5 volumes:

— Base Line Indicators

— Basic Indicators 1/3



— Extended Indicators



12 Radio Frequency Optimizer (RFO)This section is an overview of Radio Frequency Optimizer (RFO), the post-processing tool of theXML call trace files generated by CTb, CTg and OTCell session.

RFO Overview

RFO is introduced in the OAM06.0 release, as replacement of the PrOptima Call Trace module.It is an offline tool used for analysis and optimization of the Alcatel-Lucent UTRAN Network.

RFO has a function of Per Call Trace analysis.

The inputs are the Call Trace data from RNC collected in CTb, CTg and OTCell sessions.

Once a set of files are selected to be inserted in a database, a parsing of each file issystematically performed.

All the supported messages are decoded and the information is stored in the database. Afterthis step, this file is no longer used, RFO only uses the information in the database. That meansthat the original input file, on the WMS Server, may be moved or suppressed withoutconsequences on the database.

Then:

• if one input file contains call traces for several mobiles, this file is seen as several files inRFO,

• if several Call Trace files are related to the same session for the same UE, they arecombined to be seen as one file.

RFO Documentation

Alcatel-Lucent Radio 9358 Frequency Optimizer - User Guide (NN-20500-181)

Alcatel-Lucent Radio 9358 Frequency Optimizer - Installation Guide (NN-20500-182)



13 Call Trace Configuration Wizard applicationUse the Call Trace Configuration Wizard application from the NSP GUI to manage Call Trace andObject Trace sessions of all different types as well as trace session templates.

Using the Wizard, you can create, delete and/or print records of trace sessions and trace sessiontemplates. You can also create custom templates, based on predefined trace records.


• The Call Trace configuration Wizard interface

• Using the Call Trace configuration Wizard



13.1 The Call Trace configuration Wizard interfaceThis section introduces the main window and the buttons of the Call Trace Configuration Wizardinterface.

Wizard windows

The following figure is an example of the Wizard window of an access session creation.

Figure 18 Example of a Call Trace Wizard window

This wizard window is composed of the following parts, whatever the trace session type.

• Explanation part:

the upper part of the window explains the operation to perform, except in the case of someparticular windows (for example, the Welcome and End Wizard windows).

• Operational part

the central part of the window is dedicated to the operations.

• Command part:

the lower part of the window, which contains:

— a progress bar indicating when an operation is performing. The label of the progress bardetails the state of the operation;



— wizard buttons, which can vary, according to the state of the wizard and the option selected.

Wizard buttons

Click Next to display the next window. It becomes available once the required fields are filled in orselected in the window part, which is dedicated to the operation. It is not available on the last wizardwindow.

Click Back to display the previous window. It is not available on the first wizard window.

Click Create, Delete or Print to apply the required action.

Click Cancel to cancel the current operation and quit the wizard; a confirmation window appears.



13.2 Using the Call Trace configuration WizardThis section describes the Call trace configuration wizard uses.

With the Wizard you can manage trace sessions and session templates.

You also can create, delete, list and print reports of trace sessions or session templates.:

Management of trace sessions

You can create the following types of trace sessions.

• More than one Access Sessions on a single RNC.

See Creating one or more Access sessions on one RNC.

• An Access Session on more than one RNCs.

See Creating an Access session on multiple RNCs.

• A Geographical Session.

See Creating a geographical session.

• A Neighbouring Session.

See Creating a Neighbouring session.

• A Cell Session.

See Creating a cell session.

• IuCS, IuPS, IuR and IuBC sessions.

See Creating an IuCS, an IuPS, an IuR or an IuBC session.

After the trace session creation, the associated sessions are automatically activated by asynchronization operation.

You can delete the call trace session. See Deleting trace sessions.

You can print a report of the call trace sessions. See Listing and printing a call trace session report.

Management of trace session templates

To create a trace session template, you must select one or more predefined trace records.

See Creating a trace session template.

You can delete a trace session template. See Deleting a trace session template.

For more information on the trace records, see Session templates.

You can print a report of the trace session templates. See Listing and printing a trace sessiontemplate report.



14 Performance Management proceduresThis section presents the performance management procedures represented by tasks organized inthe following order:

• Retrieving counter files further to a Node B IP address change

• Configuration of alarm thresholds for access observations

• Configuration of Call Trace sessions



14.1 Retrieving counter files further to a Node B IP address changeUse this procedure to allow the OAM to retrieve the Node B observation files after an IP addresschange, without waiting for a 24-hour delay.

Procedure

Step Action

1. Lock the Node B 10 minutes before the set hour; for example at 01:50.

2. Change the IP address of the Node B 10 minutes following the set hour; for example at 02:10.

3. Reset the Node B 20 minutes following the set hour; for example at 02:20.

4. Unlock the Node B.On the next set hour (for example, at 03:00), the OAM retrieves the counter files from theNode B with the new IP address.

--End--



14.2 Configuration of alarm thresholds for access observationsThis section explains how to configure the alarm thresholds for the counter observations.

Use the Alarm on thresholds configuration to configure alarms on specific QoS thresholds forwhatever number of raw counters in each report.

Thresholds can be simple settings as well as complex formula mathematical operator based settings.

Alarms can be configured and sent in the following formats:

• ASCII, XML, HTML

• E-mail, SMS, WAP

Alarms include at last the following information:

• Network element type

Example:

3G_SGSN

• Network element ID

Example:

AlcatelLucent-3G_SGSN3

• Calculation

Example:

msInitFailAtSgsn

• Granularity

Example:

15 minutes

• Date and time

Example:

December 20 2002 09:49:57

The following procedures are documented:

• Configuring a threshold definition file

• Checking the syntax of the threshold definition file

• Loading the threshold definition file

• Determining the identifier of a RNC

• Determining the identifier of a Node B



14.2.1 Configuring a threshold definition fileThe following procedure explains how to configure alarm thresholds for a given counter in a thresholddefinition file.

Procedure

Step Action

1. Open one of the template threshold definition files (according to the NE type) located under the/opt/nortel/data/custom/utrandirectory:

• CP_APM_UTRAN_CNodeThresholdDef.xml for CNode counters,

• CP_APM_UTRAN_NodeBThresholdDef.xml for Node B counters.

2. Edit the file. You must set the following parameters:

• class: enter the class name of the object(s) on which you want the threshold to be defined. Ifyou do not know the class name of the object(s) on which you want to define a threshold, seethe table Mapping of object type names on object class names.

• objects: enter the name(s) of the selected object(s).

See the table Mapping of object type names on object relative identifiers to know whichidentifier must be used in the definition file for a given object type.

This parameter is optional: if no object is specified, the threshold applies to all the objects ofthe selected class.

If you do not know the identifier of the object for which you want to configure alarmthresholds, see the following procedures:

— Determining the identifier of a RNC: for a RNC equipment.

— Determining the identifier of a Node B: for a Node B equipment.

• counter: enter the name of the counter.

• severity: select the alarm severity.

• compOp: select the comparison operator.

• startValue: enter a starting value.

• endValue: enter an endValue (optional).

• refPeriod: enter a refPeriod (optional).

For more information on parameter configuration in the threshold definition file, see Syntax ofalarm on threshold.



3. When you have made the required modifications, rename the file and save it under the/opt/nortel/data/custom/utrandirectory..

Example:

Below is an example of the CP_APM_UTRAN_CNodeThresholdDef.xml threshold definition foran instance of a class without hysteresis (no endvalue parameter) and without normalization (norefperiod parameter):

<?xml SYSTEM "thresholds-1.0.dtd">

<THRESHOLDS domain="UTRAN">

<THD class="R/Nodeb/FddCell" objects="RNC=9,NodeB=0,FDDCell=BTS_277090_0"counter="VS.NumberUeWithNRadioLinks.2RadioLinks.Avg" severity="CRITICAL"compOp="LOWER" startValue="8000"/>

< /THRESHOLDS>

4. Ensure that the syntax of your threshold definition file is correct, using the dedicated tool:fmkpm_thdsyncheck.sh. For more information, see Checking the syntax of the thresholddefinition file.

The threshold definition file must comply with the threshold syntax DTD. For more information,see Syntax of alarm on threshold.

5. Reload the file for the new threshold parameters to be taken into account. To do this, use thededicated tool: fmkpm_thdreload.sh. For more information, see Loading the threshold definitionfile.

--End--



14.2.2 Checking the syntax of the threshold definition fileThe following procedure explains how to check the syntax of the threshold definition file.

Procedure

Step Action

1. To check the syntax of the threshold definition file, go to the /opt/nortel/shell/utran directory andenter the following command:fmkpm_thdsyncheck.sh <filetype> <filename>where:

• <filetype> can be OBS_NODE_B or OBS_C_NODE,

• <filename> is the threshold definition file with full path.

For more details on the use of the fmkpm_thdsyncheck.sh tool to check threshold definition files,see Check of the threshold definition file syntax.

--End--



14.2.3 Loading the threshold definition fileThe following procedure describes how to load the threshold definition file, for the new parametersdefined to be taken into account in the alarms display.

Procedure

Step Action

1. To load the threshold definition file, execute the shell:fmkpm_thdreload.sh <filetype>where:

• <filetype> can be OBS_NODE_B or OBS_C_NODE.

For more details on the use of the fmkpm_thdreload.sh tool to load threshold definition files, seeLoading of the threshold definition file.

--End--



14.2.4 Determining the identifier of a RNCThe following procedure describes how to determine the identifier of a given RNC.

Procedure

Step Action

1. Open the WICL command line shell.

2. In the WICL command line, use the display command with the following syntax to display theparameters of the selected Node B:>: RNC <RNC User Label> NodeB <NodeB User Label> dis

Example:

The following command displays the parameters of the Node B BTS_277090:

>: RNC RNC_1209 NodeB BTS_277090 dis

It returns the following result:

...

administrativeState unlocked

class NodeB

connectionMode passive

dn (RNC,259)(NodeB,0)

endPoint 20

isSilentModeAllowed true

...

You must use the relative distinguished name of the Node B (nodeB,0), as defined in theMapping of object type names on object relative identifiers table. In this example, thedistinguished name to be used in the threshold definition file is 0.

--End--



14.2.5 Determining the identifier of a Node BThe following procedure describes how to determine the identifier of a given Node B.

Procedure

Step Action

1. Open the WICL command line shell.

2. In the WICL command line, use the display command with the following syntax to display theparameters of the selected Node B:>: RNC <RNC User Label> NodeB <NodeB User Label> dis

Example:

The following command displays the parameters of the Node B BTS_277090:

>: RNC RNC_1209 NodeB BTS_277090 dis

It returns the following result:

...

administrativeState unlocked

class NodeB

connectionMode passive

dn (RNC,259)(NodeB,0)

endPoint 20

isSilentModeAllowed true

...

You must use the relative distinguished name of the Node B (nodeB,0), as defined in theMapping of object type names on object relative identifiers table. In this example, thedistinguished name to be used in the threshold definition file is 0.

--End--



14.3 Configuration of Call Trace sessionsThis section describes the following procedures:

• Launching the Call Trace Configuration Wizard

• Creating one or more Access sessions on one RNC

• Creating an Access session on multiple RNCs

• Creating a geographical session

• Creating a Neighbouring session

• Creating a cell session

• Creating an IuCS, an IuPS, an IuR or an IuBC session

• Creating a trace session template

• Deleting trace sessions

• Deleting a trace session template

• Listing and printing a call trace session report

• Listing and printing a trace session template report

Prerequisites

The NSP platform must be started. Instructions on how to access this platform are provided inAlcatel-Lucent 9353 Management System - User Guide (NN-20500-032).

Preliminary requirements

Before running the following procedure, ensure that the following requirements are met:

• OAM main server is operational.

• RNC is operational.

• Node B is operational.

• UE mobile call is operational.



14.3.1 Launching the Call Trace Configuration WizardThe following procedure describes how to launch the Call Trace Configuration Wizard option.

Procedure

Step Action

1. From the Network Services Platform window, select the File>Select Network Layout menu .The Layout Selector window appears.

2. From the Available Network Layouts list in the Layout Selector, select the layout you want tocreate the Call Trace session for , then click View or Edit.

3. From the Performance menu, select Radio Access>Call Trace Wizard for UMTS.The Call Trace Configuration Wizard window appears.

Figure 19 Call Trace Wizard for UMTS command

4. Click Next.The second Call Trace Configuration Wizard window appears and displays the main menuof the wizard.



Figure 20 Call Trace Configuration Wizard main window

--End--



14.3.2 Creating one or more Access sessions on one RNCThe following procedure describes how to create multiple access sessions on one RNC.

Use this mode allows to trace calls made by several UEs on a given RNC. When creating multipleAccess sessions, it is possible to set the NBAP Dedicated Measurement parameters for the selectedRNC.

Procedure

Step Action

1. Perform the Launching the Call Trace Configuration Wizard procedure.

2. Enable the Manage the Call Trace Session option and click Next.

3. Enable the Create Call Trace Sessions option and click Next.

4. Enable the Access session option and click Next.

5. Enable the Create one or more Access sessions on a single RNC option and click Next.A window appears with the RNC and NBAP parameters fields. The following figure is anexample of equipment and NBAP parameter selection:



Figure 21 Example of window of multiple access session on a single RNC

6. If you want to consider specific NBAP Dedicated Measurements, modify the RNC and NBAPparameters fields. Note that in this case, you must select one of the following templates in theSession Template list (next window):

• a custom template,

• the RemoteOptimization template,

• the RFOptimization template.

The values of SIR, TCP and RTT periods (ms) must be:

• between 500 and 10000,

• multipliers of 500.

For the NBAP Dedicated Measurements feature description, see Access Session.

If you do not need to configure NBAP Dedicated Measurements, go to Step 7..

7. Click Next .A window appears with the Mobile identification and session parameters fields. Thefollowing figure is an example of Mobile identification and session parameters selection:



Figure 22 Parameter window of access session creation on a single RNC

8. In the Mobile Identification field, select one of the following traceUeidType identities:

• IMSI (6 to 15 decimal digits)

• TMSI (4 hexadecimal digits)

• IMEI (15 hexadecimal digits)

• P-TMSI (4 hexadecimal digits)

9. Enter the identifier, according to the selected type.

10. Enter the following information in the Session parameters fields:

• Session Template: select a session template. By default, the template called"TroubleShooting" is selected.

• User Label: enter a unique label.

• Duration (mn): enter the session duration. The maximum duration is 65535.

The default value 0 corresponds to an infinite session duration.

• Session Note: enter additional information about the session. The maximum number ofcharacters is 32.

• Start Time: enter the lapse of time (in minutes) between the creation of the session and its



first activation.

The default value 0 means that the session will start immediately.

• File Upload Size: enter the maximum size (in kb) of the trace file.

The default value is 512 kb, the maximum value is 1024.

• File Upload Period: enter the lapse of time (in minutes) before the trace file is closed andmade available.

The default value is 15 min.

11. Click Add.

The selected parameters are verified. An error message is returned if:

• The user label entered is already used.

• No template has been selected.

• The UE identifier is not typed correctly.

• The UE equipment is already used in another trace session.

• The session note exceeds the maximal number of characters.

• The duration exceeds the maximum authorized value.

• The file upload size value exceeds the maximum authorized value.If the parameters are correct, the selected equipment appears in the list with thecorresponding session parameters.

12. Repeat steps 9. to 11. to add equipment to the trace session.

You can create up to 20 simultaneous sessions on the selected RNC.

13. When you have finished selecting, click Next.A window appears with a summary of the session parameters selected.



Figure 23 Summary window of an access session creation on a single RNC

The externalSessionId is computed automatically during creation. It is unique for eachcreated TraceSession and different than 0. The username and the dateCreation arecomputed by the server during creation.

14. Click Create to confirm the access session creation.A window appears with a summary result in the Wizard status field.

15. Click Finish.

If the operation failed and the Launch report window on close option is enabled, a windowdescribing the detail of the failure appears. The failure message indicates:

• if the error occured either during the creation or during the activation of the sessions,

• the probable failure causes,

• the attribute table of the created sessions, in case of partial failure.

If the operation is successful and the Launch report window on close option is enabled, thefollowing window appears with the results:



Figure 24 Result window of access session creation on a single RNC

16. Click Close to close the window.

--End--



14.3.3 Creating an Access session on multiple RNCsThe following procedure describes how to create an access session on multiple RNCs.

Use this mode to trace calls made by one UE on a number of RNCs. When creating a single Accesssession on one or more RNCs, it is possible to set the NBAP Dedicated Measurement parameters foreach RNC to be added.

Procedure

Step Action

1. Perform Launching the Call Trace Configuration Wizard.


3. Enable the Create Call Trace Sessions option and click Next.

4. Enable the Access session option and click Next .

5. Enable the Create single Access session on one or more RNCs option and click Next.A window appears with the RNCs and NBAP parameters fields. The following figure is anexample of equipment and NBAP parameters selection:



Figure 25 Create single Access Session window

6. If you want to consider specific NBAP Dedicated Measurements, modify the RNC and NBAPparameters fields. Note that in this case, you must select one of the following templates in the"Session Template" list (next window):


• the RemoteOptimization template,

• the RFOptimization template.



• a multiple of 500.

For the NBAP Dedicated Measurements feature description, see Access Session.

If you do not need to configure NBAP Dedicated Measurements, go to Step 7.

7. Click Add.The selected RNC appears in the list with the associated NBAP parameters.

8. Repeat steps 6. and 7. to add more equipment to the trace session.



9. If you want to remove an equipment, select it in the list and click Remove.

10. When you have finished your selection, click Next.A window appears with the Mobile identification and session parameters fields.

Figure 26 Parameter window of single access session creation on multipleRNCs

11. Select one of the following traceUeidType identities in the Mobile Identification field:

• IMSI (6 to 15 decimal digits)

• IMEI (15 hexadecimal digits)

• TMSI (4 hexadecimal digits)

• P-TMSI (4 hexadecimal digits)

12. Enter the identifier, according to the selected type.

13. Enter the following information in the Session Parameters fields:

• Session Template: select a session template. By default, the template named"TroubleShooting" is selected.


• Duration (min): enter the session duration. The maximum duration is 65535.



The default value 0 corresponds to an infinite session duration


• Start Time: enter the time lapse (in minutes) between the creation of the session and its firstactivation.






14. Click Next.

The parameters selected are verified. An error message is returned if:



• The UE identifier is not typed correctly.


• The duration exceeds the maximum authorized value.

• The file upload size value exceeds the maximum authorized value.A window appears with a summary of the session parameters selected.



Figure 27 Summary window of access session creation on multiple RNCs

The externalSessionId is computed automatically during creation. It is unique for eachcreated trace session and different from 0. The userName and the date are computed by theserver during creation.

15. Click Create to confirm the access session creation.A window appears with a summary result in the Wizard status field.

16. Click Finish.

If the operation fails and the Launch report window on close option is enabled, a windowdescribing the detail of the failure appears. The failure message indicates:

• if the error occured either during the creation or during the activation of the session,

• the probable failure causes,

• the attributes table of the created session, in case of partial failure.



If an error occurs during the creation, a window describing the details of the failure appears.When you click Close, all the objects already created are deleted.

If the operation is successful and the Launch report window on close option is enabled, a newwindow appears with the results.

The following figure shows an example of successful trace session creation:

Figure 28 Result window of access session creation on multiple RNCs




--End--



14.3.4 Creating a geographical sessionThe following procedure describes how to create a geographical session.

Procedure

Step Action


2. Enable the Manage the Call Trace Session option and click Next .

3. Enable the Create Call Trace Sessions option and click Next .

4. Enable the Geographical session option and click Next.A window appears with an "Equipment Selection" area:

Figure 29 Geographical session creation vindow

The Available Equipments field displays the list of available targets in a Tree View or in aFlat View. The view type can be selected from the combo box on the top of the list. TheSelected Equipments field displays the selected FDDCells or RNCs.

5. Use the command buttons in the middle of the window:



• Select ->: to add the selected equipment to the Selected equipment list.

If you select a non terminal object (RNC or Node B) in the Tree View, all FDDCells attachedto this object are also added.

• Select All ->: to add all FDDCells to the "Selected equipment" list

• <- Remove: to remove the selected equipment from the "Selected equipment" list

• <- Remove All: to remove all FDDCells from the "Selected equipment" list

An element cannot be added twice.

6. After you have selected the required equipment, click Next.A window appears with the RNC and NBAP parameters fields. The following figure showsan example of equipment and parameter selection:

Figure 30 RNC an NBAP parameter window of geographical session creation

The RNC and NBAP parameters section lists the selected RNCs and RNCs containingselected objects (CNodes or FDDCells).

7. If you want to update the RNCs and NBAP parameters, select the RNC you want to updatebefore accessing the RNCs and NBAP parameters fields. Note that in this case, you must selectone of the following templates in the Session Template list (next window):


• the Optimization template.





• a multiple of 500.

You cannot modify the NBAP parameters of a RNC if you have not selected all the objectscontained in this RNC for the trace session.

For the NBAP Dedicated Measurements feature description, see theGeographical Sessionsection.

8. Click Update.

9. Repeat steps 7. and 8. to update other RNCs.

10. After you have made the modifications, click Next.A window appears with the Session parameters fields. For example:

Figure 31 Parameter window of geographical session creation

11. Enter the required information in the Session parameters fields.

• Call Type List: select a call type from the drop list.




• Session Template: select a session template. By default, the template named"StandardTroubleShooting" is selected.




• Start Time: enter the lapse of time (in minutes) between the creation of the session and itsfirst activation.






12. Click Next.





• The duration exceeds the maximum authorized value.A window appears with a summary of the session parameters selected:



Figure 32 Summary window of geographical session creation

The externalSessionId is computed automatically during creation. It is unique for eachcreated trace session and different than 0. The userName and the date are computed by theserver during creation.

13. Click Create to confirm the cell session creation.A window appears with a summary result in the Wizard status field.

14. Click Finish.

If the Launch report window on close option is enabled, a new window appears with theresults.

The following figure is an example of successful trace session creation:



Figure 33 Result window of geographical session creation

This windows displays the details of all attributes of the created trace session and the detailsof the failure if a failure occurs.


--End--



14.3.5 Creating a Neighbouring sessionThe following procedure describes how to create a Neighbouring session.

Procedure

Step Action




4. Enable the Neighbouring session option and click Next.A window appears with an Equipment Selection area. For example:

Figure 34 Neighbouring creation session window





• Select ->: to add the selected equipment to the Selected Equipments list.

If you select a non-terminal object (RNC or Node B) in the Tree View, all FDDCells attachedto this object are also added.

• Select All ->: to add all FDDCells to the Selected Equipments list

• <- Remove: to remove the selected equipment from the Selected Equipments list

• <- Remove All: to remove all FDDCells from the Selected Equipments list

An element cannot be added twice.

6. When you have selected the required equipment, click Next.A window appears with the Input targets area. Use this window to enter the RNC id and theCell id for the neighbouring session you want to create. For example:

Figure 35

7. Select an RNC from the Equipment Identification drop list.

8. If necessary, enter numeric values in the Rnc Id and Cell Id fields.

If you do not need to define RNC and Cell ids, go to step 12..



9. Click Add.The values appear in the Equipment Input table.

10. Repeat steps 8. and 9. to enter other RNC and Cell ids.

11. If you want to remove one RNC Id - Cell Id set or more, select it in the Equipment Input tableand click Remove.

12. Click Next.A window appears with the Session parameters fields. For example:

Figure 36 Parameter window of neighbouring session creation


• Call Type List: select a call type from the drop list.



Note that the "NeighbouringOptimization" template is configured for the Neighbouring sessionuse only.












14. Click Next.








Figure 37 Summary window of neighbouring session creation

The externalSessionId is computed automatically during creation. It is unique for eachcreated trace session and different from 0. The userName and the date are computed by theserver during creation.


16. Click Finish.





Figure 38 Result window of neighbouring session creation

A window displays the details of all attributes of the created trace session and the details ofthe failure if a failure occurs.




--End--



14.3.6 Creating a cell sessionThe following procedure describes how to create a cell session.

Procedure

Step Action


2. Enable the Manage Call Trace Session option and click Next .


4. Enable the Cell session option and click Next.A window appears with an Equipment Selection field:

Figure 39 Cell session creation window





• Select ->: to add the selected equipment to the "Selected equipment" list.

If you select a non-terminal object (RNC or Node B) in the Tree View, all FDDCells attachedto this object are also added.

• Select All ->: to add all FDDCells to the "Selected equipment" list

• <- Remove: to remove the selected equipment from the "Selected equipment" list

• <- Remove All: to remove all FDDCells from the "Selected equipment" list

You cannot add the same element twice. It is not possible to select more than 250 cells either.

6. Click Next.A window appears with the Mobile identification and session parameters fields.

Figure 40 Parametr wondow of cell session creation

7. Enter the following information in the Session parameters fields:






The default value 0 corresponds to an infinite session duration








8. Click Next.








Figure 41 Summary window of cell session creation

The externalSessionId is computed automatically during creation. It is unique for eachcreated TraceSession and different from 0. The username and the dateCreation arecomputed by the server during creation.




10. Click Finish.If the Launch report window on close option is enabled, a new window appears with theresults. The following figure is an example of successful trace session creation:

Figure 42 Result window of cell session creation



This window displays the details of all attributes of the created trace session and the detailsof the failure if a failure occurs.


--End--



14.3.7 Creating an IuCS, an IuPS, an IuR or an IuBC sessionThe following procedure describes how to create an IuCS, IuPS, IuR or IuBC session.

Procedure

Step Action




4. Enable one of the following options:

• IuCS session

• IuPS session

• IuR session

• IuBC session

5. Click Next.A window appears with the "Equipment identification and session parameters" area. Forexample, for an IuCS session creation:



Figure 43 IuCS session creation window


• Equipment Identification:

select one or more IuCS(s) for an IuCS session,

select one or more IuPS(s) for an IuPS session,

select one or more Neighboring RNC(s) for an IuR session,

select one or more RNC(s) for an IuBC session.














7. Click Next.





• The duration exceeds the maximum authorized value.A window appears with a summary of the session parameters selected. For example, for anIuCS session creation:



Figure 44 Summary window of IuCS session creation

The externalSessionId is computed automatically during creation. It is unique for eachcreated trace session and different than 0. The userName and the date are computed by theserver during creation.

8. Click Create to confirm the cell session creation.



A window appears with a summary result in the Wizard status field.

9. Click Finish.





Figure 45 Result window of IuCS session creation

A window displays the details of all the created trace session attributes and the details of thefailure if a failure occurs.




--End--



14.3.8 Deleting trace sessionsThe following procedure describes how to delete one or more trace sessions.

Procedure

Step Action



3. Enable the Delete Call Trace Sessions option and click Next.

A window appears with the Trace Sessions and Note fields. This window displays all theexisting Call Traces with the following information:

• External Session Id

• User Label

• Type

• Date

• RNC list

• Duration (mn)The following figure is an example of selection of a trace session to delete:



Figure 46 Trace session deletion window

4. Select the trace session(s) to delete.

To delete more than one trace session at the same time, press the Ctrl tab while selecting thetrace sessions to be deleted.

5. Click Next.A window appears with information on the traces to be deleted in the Trace Sessions field.The following figure is an example of confirmation of the trace session to be deleted:



Figure 47 Example of window of deletion confirmation

6. Click Delete to confirm the access session(s) deletion.A window appears with a summary result in the Wizard status field. The message window issame as the following:

Figure 48 Example of wizard status window



7. Click Finish.If the Launch report window on close option is enabled, a new window appears with theresults. The following figure is an example of successful trace session deletion:

Figure 49 Result window of session deletion

This windows displays the results of deletion for each trace and the details of the failure if afailure occurs.


--End--



14.3.9 Creating a trace session templateThe following procedure describes how to create a trace session template.

Procedure

Step Action


2. Enable the Manage the Trace Session Template option and click Next .

3. Enable the Create a Trace Session Template option and click Next .

4. Click Next.A window appears with the Trace Template Parameters fields.

Figure 50 Template session creation window



5. Select one of the following filter modes in the Mode field:

• eventOnly

• ASN.1

• ctxfull

For the trace mode descriptions, see Trace modes.

6. Enter a unique name in the Template name field.

7. Select one or more records in the Trace Record list.

8. Click Next.

The list of trace records is verified. An error message is returned if:

• The filter name entered is already used or no name has been entered.

• The filter name exceeds the maximal number of characters or it contains the character ",".

• No trace record has been retrieved by the system.A window appears with a summary of the trace session template parameters selected:



Figure 51 Summary of trace template creation

9. Click Create to confirm the trace session template creation.A window appears with a summary result in the Wizard status field.



Figure 52 Example of wizard status for template session creation

10. Click Finish.If the Launch report window on close option is enabled, a new window appears with theresults. The following figure is an example of successful trace session template creation:



Figure 53 Result window of session template creation

This windows displays the results of the call trace template creation and the details of thefailure if a failure occurs.


--End--



14.3.10 Deleting a trace session templateThe following procedure describes how to delete a trace session template.

Procedure

Step Action



3. Enable the Delete a Trace Session Template option and click Next.

A window appears with the Trace Sessions and Note fields. This window displays all theexisting call trace templates with the following information:

• Template name

• Filter list

• Duration (mn)The following figure is an example of selection of a call trace template to delete:

Figure 54 Deletion trace template window



4. Select the trace template(s) to delete.

To delete more than one templates at the same time, press the "Ctrl" tab while selecting thetemplates to be deleted.

Before selecting a template to delete, check that it is not currently used by a trace session;otherwise, an error message appears and the template will not be deleted.

5. Click Next.A window appears with information on the templates to be deleted in the "Trace SessionTemplates" field. The following figure is an example of confirmation of the template to bedeleted:

Figure 55 Window of template deletion confirmation

6. Click Delete to confirm the template(s) deletion.A window appears with a summary result in the Wizard status field. The message window issame as the following:



Figure 56 Wizard status window in template deletion

7. Click Finish.


The following figure is an example of successful call trace template deletion:



Figure 57 Result window of session template deletion

This window displays the results of deletion for each template and the details of the failure ifa failure occurs.


--End--



14.3.11 Listing and printing a call trace session reportThe following procedure describes how to print a call trace session report.

Procedure

Step Action



3. Enable the List Call Trace Sessions option and click Next.

A window appears with the Trace Sessions and Notes fields. This window displays all theexisting call trace sessions with the following information:

• External Session Id

• User Label

• Type

• Date

• RNC list

• Duration (mn)The following figure is an example of session selection to be printed:



Figure 58 Window of session selection for printing

4. Select the trace session(s) that you want to print.

To print more than one session at the same time, press the "Ctrl" tab while selecting the sessionsto be printed.

Select the Print with detail information option, if you want to print a detailed report.

5. Click Next.A window appears, displaying the trace session with the following information:

• Trace session name

• Date of creation of the trace session report

• Trace session parametersThe following figure is an example of a trace session report to be printed:



Figure 59 Example of trace session report

6. Click Print.The Setup window of your printer appears.

7. Select the desired parameters and validate your selection to print the report.

--End--



14.3.12 Listing and printing a trace session template reportThe following procedure describes how to print a trace session template report.

Procedure

Step Action



3. Enable the List Trace Session Templates option and click Next.

A window appears with the Trace Session Templates and Summary fields. This windowdisplays all the existing call trace templates with the following information:

• Template name

• Filter list

• Duration (mn)The following figure is an example of selection of a template to be printed:



Figure 60 Window of template selection for printing

4. Select the trace template(s) that you want to print.

To print more than one template at the same time, press the Ctrl tab while selecting thetemplates to be printed.

Select the Print with detail information option, if you want to print a detailed report.

5. Click Next.

A window appears, displaying the trace session template with the following information:

• Trace session template name

• Date of creation of the trace session template report



• Trace session template parametersThe following figure is an example of a trace session template report to be printed:

Figure 61 Example of template report

6. Click Print.The Setup window of your printer appears.

7. Select the desired parameters and validate your selection to print the report.

--End--



15 Appendix: DTD 32.401.02This part presents complementary information about the DTD 32.401.02.

A DTD gives the rules to organize and name XML elements (tags) in a document. It defines the datastructure for an XML file.

For performance management, the counter observation files use the convention defined with the3GPP DTD 32.401.02. For more details about the DTD 32.401.02, see the 3GPP specificationTelecommunication management; Performance Management (PM); Concept and requirements (TS32.401).

DTD 32.401.02 description

The following XML DTD describes the observation files format.





Figure 62 DTD 32.401.02 for observations

The following table summarizes the XML tags and their associated full names and descriptions.



XMLtag

Full name Description

mdc measDataCollection This top-level tag identifies the file as a collection ofmeasurement data.

The file content includes a header (measFileHeader), acollection of measurement result items (measData) anda measurement file footer (measFileFooter)

mfh measFileHeader This parameter is the measurement result file header tobe inserted in each file. It includes the version indicator,name, type and vendor name of the sending networknode, and the timestamp collectionBeginTime.

md measData This construct represents the sequence of zero or moremeasurement result items contained in the file. It can beempty when no measurement data is provided. Individu-al measData elements can be displayed in any order.

Each measData element contains the name of the NEnEId and the list of measurement results pertaining tothat NE measInfo.

mft measFileFooter This parameter is to be inserted in each file. It includesthe timestamp, which refers to the end of the overallmeasurement collection interval that is covered by thecollected measurement results being stored in this file.

ffv fileFormatVersion This parameter identifies the file format version appliedby the sender.

The format version defined in this publication is 1.

sn senderName This parameter uniquely identifies the NE or EM that as-sembled this measurement file, according to the defini-tions in 3GPP TS 32.106. It is identical to the

nEDistinguishedNameof the sender. This DN uses the (userLabel) value toidentify an NE.

st senderType This is a user-configurable identifier of the type of net-work node that generated the file, for example, RNC,Node B.

vn vendorName This parameter identifies the vendor of the equipmentthat provided the measurement file. Always set to Alca-tel-Lucent.

cbt collectionBeginTime This timestamp refers to the start of the first measure-ment collection interval (granularity period) which iscovered by the collected measurement results that arestored in this file.



XMLtag


neid nEId This unique identification of the NE in the system

includes the user name (nEUserName) and the distin-guished name (nEDistinguishedName) of the NE.

neun nEUserName This parameter is the user-definable NE name.

NE user name is set to the userLabel value of the RNC.

nedn nEDistinguishedName This parameter is the distinguished name defined for theNE. It is unique across a 3G network operator. NE dis-tinguished name is built using the network ID and RNCID values.

mi measInfo The sequence of measurements, values and related in-formation.

It includes the list of measurement types (measTypes)and the corresponding results (measValues), togetherwith the timestamp (measTimeStamp) and granularityperiod.

(granularityPeriod) pertaining to these measurements.

All object instances found in a mi tag please refer to thesame object class.

nesw nESoftwareVersion This parameter is optional and defines the software ver-sion for NE in 3GPP TS 32.632. This parameter allowspost-processing systems to take care of vendor-specificmeasurements modified between versions. For the RNCmeasurements (including IN and AN files), this is theRNC system release. For the Node-B measurements, itis the system release. This tag is optional and is notpresented when the information is not known.

mts measTimeStamp Timestamp refers to the end of the granularity period.

gp granularityPeriod Granularity period of the measurement(s) is expressedin

(measValues)seconds.

mt measTypes This parameter is the list of measurement types to whichthe following similar list of measurement values) per-tains.

mv measValues This parameter contains the list of measurement resultsfor the resource being measured (trunk, cell).

It includes the identifier of the resource(measObjInstId), the list of measurement result values(measResults) and a flag that indicates if the data is re-liable (suspectFlag).



XMLtag


moid measObjInstId This parameter field identifies the measured object classand its instance, for example trunk1 means that objectclass is trunk and instance #1 is being measured.

mr measResults This parameter contains the sequence of result valuesfor the observed measurement types. The measResultssequence will have the same number of elements,which follow the same order as the measTypes se-quence.

Normal values are INTEGERs and REALs. The NULLvalue is reserved to indicate that the measurement itemis not applicable or can not be retrieved for the object in-stance.

sf suspectFlag This flag indicates the quality of the scanned data(FALSE in the case of reliable data, TRUE if not reli-able). The default value is FALSE. If the suspect flaghas a default value it can be omitted.

ts timeStamp This parameter is a GeneralizedTime format. The min-imum required information within the timestamp is year,month, day, hour, minute, and second.

DTD versioning

The name of the DTD referred to in the XML document header includes the protocol name and therelease of the XML DTD. The following lines display the DTD versioning:

Figure 63 DTD versioning



Wireless Service Provider SolutionsW-CDMAAlcatel-Lucent 9300 W-CDMA Product FamilyPerformance Management

Copyright © 2002-2008 Alcatel-Lucent, All Rights Reserved

ALCATEL-LUCENT CONFIDENTIAL

UNCONTROLLED COPY: The master of this document is stored on an electronic database and is "write protected"; it may be alteredonly by authorized persons. While copies may be printed, it is not recommended. Viewing of the master electronically ensures accessto the current issue. Any hardcopies taken must be regarded as uncontrolled copies.

ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of Alcatel-Lucent. Except asexpressly authorized in writing by Alcatel-Lucent, the holder shall keep all information contained herein confidential, shall disclose theinformation only to its employees with a need to know, and shall protect the information from disclosure and dissemination to thirdparties. Except as expressly authorized in writing by Alcatel-Lucent, the holder is granted no rights to use the information containedherein. If you have received this document in error, please notify the sender and destroy it immediately.

Alcatel-Lucent, Alcatel, Lucent Technologies and their respective logos are trademarks and service marks of Alcatel-Lucent, Alcateland Lucent Technologies.

The Alcatel-Lucent 9370 Radio Network Controller and the Alcatel-Lucent Point Of Concentration are based on Nortel MultiserviceSwitch products.

All other trademarks are the property of their owners.

Document number: NN-20500-033Document issue: 09.06/ENDocument status: PreliminaryProduct Release: OAM06.0Date: September 2008

nn-20500-033 (9300 product family - performance management) 09.06 preliminary september2008

Documents

en draftupissue

document issue

en draftupdate

en preliminaryupdate

lucent technologies

en standardupdate

current issue

service marksof alcatellucent