ALU CTN CTG Recording

NN-20500-033
Wireless Service Provider Solutions
W-CDMA
Alcatel-Lucent 9300 W-CDMA Product Family
Performance Management
NN-20500-033 09.11/EN Standard June 2009
W-CDMA
Document number:
Document issue:
Document status:
Product release:
Date:
NN-20500-033
09.11/EN
Standard
OAM06.0
June 2009
Alcatel-Lucent - Internal - Proprietary - Use pursuant to Company instruction
Copyright 2002-2009 Alcatel-Lucent, All Rights Reserved

UNCONTROLLED COPY: The master of this document is stored on an electronic database and is "write
protected"; it may be altered only by authorized persons. While copies may be printed, it is not
recommended. Viewing of the master electronically ensures access to 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 as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all
information contained herein confidential, shall disclose the information only to its employees with a need
to know, and shall protect the information from disclosure and dissemination to third parties. Except as
expressly authorized in writing by Alcatel-Lucent, the holder is granted no rights to use the information
contained herein. 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, Alcatel and Lucent Technologies.
The Alcatel-Lucent 9370 Radio Network Controller and the Alcatel-Lucent Point Of Concentration are
based on Nortel Multiservice Switch products.
All other trademarks are the property of their owners.
Publication history
PUBLICATION HISTORY
SYSTEM RELEASE: OAM06.0
June 2009
Issue 09.11/EN Standard
Update after internal remarks for DR5
April 2009
Update for DR5
January 2009
Issue 09.09/EN Preliminary
Update after internal review
December 2008
October 2008
Update for MNCL1
September 2008
August 2008
Issue 09.05/EN Draft
Up-issue for DR4
July 2008
May 2008
Copyright 2002-2009 Alcatel-Lucent
Publication history

Update for Pre-DR4
April 2008
January 2008
Update for OAM06.0
SYSTEM RELEASE: OAM05.2

January 2008
Update after documentation reorganization
November 2007
September 2007
August 2007
Update for OAM05.2
SYSTEM RELEASE: UMTS 5.1

July 2007
Update for OAM 5.1 / UA 5.0 Channel Readiness
March 2007
Editorial update
Publication history
January 2007
December 2006
Update for OAM 5.1 / UA 5.0
The Publication History information for the outdated releases

has been deleted.
Document creation date: December 2002
Table of contents
1 About this publication................................................................................................................................................. 12

2 UMTS Access Network Collection Roadmap.............................................................................................................16
3 New in this release....................................................................................................................................................... 17
4 Performance management introduction.................................................................................................................... 18
4.1 Performance management purpose......................................................................................................................... 19
4.2 Performance management applications................................................................................................................... 21
4.3 Counter observation benefits....................................................................................................................................22
4.4 Call Trace benefits....................................................................................................................................................23
5 Counter and Trace overview....................................................................................................................................... 24
5.1 UTRAN counter overview......................................................................................................................................... 25
5.1.1 Counter system architecture.............................................................................................................................. 26
5.1.2 RNC counter observation data........................................................................................................................... 28
5.1.3 MSS counter observation data........................................................................................................................... 30
5.1.4 Node B counter observation data.......................................................................................................................31
5.2 Call Trace overview.................................................................................................................................................. 32
5.2.1 Call Trace system architecture........................................................................................................................... 33
5.2.2 Call Trace data flows..........................................................................................................................................34
6 Counter and Trace activation......................................................................................................................................36
6.1 Counter observation activation................................................................................................................................. 37
6.1.1 RNC observation activation................................................................................................................................38
6.1.2 Node B and microNode B observation activation............................................................................................... 42
6.1.3 MSS observation activation................................................................................................................................43
6.2 Trace activation........................................................................................................................................................ 44
6.2.1 Trace session activity......................................................................................................................................... 45
6.2.2 Call trace and Object trace sessions.................................................................................................................. 46
6.2.3 XDR trace data files........................................................................................................................................... 51
7 Counter and Trace collection and mediation............................................................................................................ 54
7.1 Counter collection and mediation............................................................................................................................. 55
7.1.1 Counter collection...............................................................................................................................................56
7.1.2 Counter mediation.............................................................................................................................................. 57
7.1.3 RNC observation XML files................................................................................................................................ 60
7.1.4 Node B observation XML files............................................................................................................................ 62
7.1.5 XML observation file compression..................................................................................................................... 63
7.1.6 Counter data.......................................................................................................................................................64
7.1.7 Manual collection and mediation of counter files................................................................................................67
Table of contents
7.2 Trace data collection and mediation......................................................................................................................... 68

7.2.1 Call Trace data collection................................................................................................................................... 69
7.2.2 Call trace data mediation....................................................................................................................................70
8 Operational Alarm on thresholds for access observations..................................................................................... 96
8.1 Overview of Alarm on thresholds ............................................................................................................................97
8.2 Architecture of Alarm on thresholds.........................................................................................................................98
8.3 Syntax of alarm on thresholds............................................................................................................................... 100
8.4 Tools of alarm on threshold................................................................................................................................... 106
8.5 Hysteresis.............................................................................................................................................................. 108
8.6 Alarm management............................................................................................................................................... 109
9 Access Data Interface (ADI) and Management Data Provider (MDP) applications.............................................. 112
10 Wireless Quality Analyzer (WQA)........................................................................................................................... 113
11 Network Performance Optimizer (NPO)................................................................................................................. 116
12 Radio Frequency Optimizer (RFO)..........................................................................................................................118
13 Call Trace Configuration Wizard application.........................................................................................................119
13.1 The Call Trace configuration Wizard interface.....................................................................................................120
13.2 Using the Call Trace configuration Wizard ......................................................................................................... 122
14 Performance Management procedures..................................................................................................................124
14.1 Retrieving counter files further to a Node B IP address change........................................................................... 125
14.2 Configuration of alarm thresholds for access observations.................................................................................. 126
14.2.1 Configuring a threshold definition file............................................................................................................. 127
14.2.2 Checking the syntax of the threshold definition file........................................................................................ 129
14.2.3 Loading the threshold definition file................................................................................................................130
14.2.4 Determining the identifier of an RNC..............................................................................................................131
14.2.5 Determining the identifier of a Node B........................................................................................................... 133
14.3 Configuration of Call Trace sessions.................................................................................................................... 135
14.3.1 Launching the Call Trace Configuration Wizard............................................................................................. 136
14.3.2 Creating one or more Access sessions on one RNC..................................................................................... 138
14.3.3 Creating an Access session on multiple RNCs.............................................................................................. 144
14.3.4 Creating a geographical session.................................................................................................................... 151
14.3.5 Creating a Neighbouring session................................................................................................................... 157
14.3.6 Creating a cell session................................................................................................................................... 164
14.3.7 Creating an IuCS, an IuPS, an IuR or an IuBC session................................................................................. 170
14.3.8 Deleting trace sessions.................................................................................................................................. 176
14.3.9 Creating a trace session template..................................................................................................................180
Table of contents
14.3.10 Deleting a trace session template................................................................................................................ 185

14.3.11 Listing and printing a call trace session report............................................................................................. 189
14.3.12 Listing and printing a trace session template report..................................................................................... 192
15 Appendix: DTD 32.401.02........................................................................................................................................ 195
List of figures
Figure 1 - Functional view of the counter observation domain........................................................................... ......... 26

Figure 2 - Architecture of the trace application................................................................................................... ......... 34
Figure 3 - Counter collection and mediation ...................................................................................................... ......... 57
Figure 4 - DTD versioning..................................................................................................................... ............. ......... 66
Figure 5 - Call trace data mediation...................................................................................................... ............. ......... 68
Figure 6 - Call trace DTD-first part........................................................................................................ ............. ......... 75
Figure 7 - Call trace DTD-second part.................................................................................................. ............. ......... 76
Figure 8 - Call trace DTD-third part....................................................................................................... ............. ......... 77
Figure 9 - Object trace DTD-part 1/4.................................................................................................................. ......... 77
Figure 10 - Object trace DTD-part 2/4................................................................................................................ ......... 78
Figure 13 - Management data DTD (Part 1/3).................................................................................................... ......... 80
Figure 16 - Threshold syntax DTD........................................................................................................ ............. ....... 101
Figure 17 - Example of alarm threshold syntax.................................................................................................. ....... 105
Figure 18 - Example of a Call Trace Wizard window ........................................................................... ............. ....... 120
Figure 19 - Call Trace Wizard for UMTS command.............................................................................. ............. ....... 136
Figure 20 - Call Trace Configuration Wizard main window................................................................... ............. ....... 137
Figure 21 - Example of window of multiple access session on a single RNC....................................... ............. ....... 139
Figure 22 - Parameter window of access session creation on a single RNC..................................................... ....... 140
Figure 23 - Summary window of an access session creation on a single RNC.................................... ............. ....... 142
Figure 24 - Result window of access session creation on a single RNC.............................................. ............. ....... 143
Figure 25 - Create single Access Session window .............................................................................. ............. ....... 145
Figure 26 - Parameter window of single access session creation on multiple RNCs ........................................ ....... 146
Figure 27 - Summary window of access session creation on multiple RNCs....................................... ............. ....... 148
Figure 28 - Result window of access session creation on multiple RNCs.......................................................... ....... 149
Figure 29 - Geographical session creation vindow............................................................................... ............. ....... 151
Figure 30 - RNC an NBAP parameter window of geographical session creation................................. ............. ....... 152
Figure 31 - Parameter window of geographical session creation....................................................................... ....... 153
Figure 32 - Summary window of geographical session creation........................................................... ............. ....... 155
Figure 33 - Result window of geographical session creation................................................................ ............. ....... 156
Figure 34 - Neighbouring creation session window............................................................................................ ....... 157
Figure 35 - ............................................................................................................................................ ............. ....... 158
Figure 36 - Parameter window of neighbouring session creation......................................................... ............. ....... 159
Figure 37 - Summary window of neighbouring session creation........................................................................ ....... 161
Figure 38 - Result window of neighbouring session creation................................................................ ............. ....... 162
Figure 39 - Cell session creation window........................................................................................................... ....... 164
Figure 40 - Parametr wondow of cell session creation ...................................................................................... ....... 165
Figure 41 - Summary window of cell session creation.......................................................................... ............. ....... 167
List of figures
10
Figure 42 - Result window of cell session creation............................................................................... ............. ....... 168

Figure 43 - IuCS session creation window............................................................................................ ............. ....... 171
Figure 44 - Summary window of IuCS session creation..................................................................................... ....... 173
Figure 45 - Result window of IuCS session creation.......................................................................................... ....... 174
Figure 46 - Trace session deletion window........................................................................................... ............. ....... 177
Figure 47 - Example of window of deletion confirmation.................................................................................... ....... 178
Figure 48 - Example of wizard status window....................................................................................... ............. ....... 178
Figure 49 - Result window of session deletion...................................................................................... ............. ....... 179
Figure 50 - Template session creation window..................................................................................... ............. ....... 180
Figure 51 - Summary of trace template creation................................................................................... ............. ....... 182
Figure 52 - Example of wizard status for template session creation..................................................... ............. ....... 183
Figure 53 - Result window of session template creation....................................................................... ............. ....... 184
Figure 54 - Deletion trace template window.......................................................................................... ............. ....... 185
Figure 55 - Window of template deletion confirmation.......................................................................... ............. ....... 186
Figure 56 - Wizard status window in template deletion......................................................................... ............. ....... 187
Figure 57 - Result window of session template deletion....................................................................... ............. ....... 188
Figure 58 - Window of session selection for printing.......................................................................................... ....... 190
Figure 59 - Example of trace session report......................................................................................... ............. ....... 191
Figure 60 - Window of template selection for printing........................................................................... ............. ....... 193
Figure 61 - Example of template report.............................................................................................................. ....... 194
Figure 62 - DTD 32.401.02 for observations......................................................................................... ............. ....... 196
Figure 63 - DTD versioning................................................................................................................... ............. ....... 199
List of tables
11
Table 1 - 3GPP 32.108 contribution tags.............................................................................................. ............. ......... 82

Table 2 - Tags specific to object traces.............................................................................................................. ......... 86
Table 3 - List of Cause values for the <cause type = estabcause> (vendor specific)........................... ............. ......... 88
Table 4 - List of Cause values for the <cause type = RRCRelCause> (3GPP).................................... ............. ......... 89
Table 5 - List of Cause values for the <cause type = IuRelCause> (3GPP)......................................... ............. ......... 89
Table 6 - List of values for the <IE> attibute....................................................................................................... ......... 92
Table 7 - Mapping of object type names on object class names........................................................................ ....... 102
Table 8 - Mapping of object type names on object relative identifiers................................................................ ....... 103
Table 9 - WQA for WMS documentation............................................................................................... ............. ....... 114
12
About this publication

The purpose of this publication is to provide information about the performance management of the
UMTS Access Network, to describe the aim of this function, the involved applications and the
associated data collected.
It also describes how to launch the applications.
The Performance Management function in the OAM06.0 release is described in this document.
However, complementary information about detailed description (for example counters, 3GPP
interfaces) 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 the
referred 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 UMTS Access Network Performance
Management.
Prerequisites
Readers must be familiar with the following publications:
UMTS W-NMS for Access Network - Overview (NN-20500-031)
UMTS Access Network Performance Reference Observation Counters (NN-20500-028)
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
13
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
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:
14
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-CDMA
Product 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:

Granularity
Period (GP)
The time between two successive measurement results gatherings in the NE.
Managed Ob- Component.

ject (MO)
Central
timestamp
Timestamp provided by the OMU card of the RNC
Proc
timestamp
Timestamp provided by the TMU cards of the RNC
Session
The session can be Observation or Trace. It identifies a data collection requested 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 Cplane part
(also named C-Node) and the term MSS Platform refers both to RNC Uplane part (also named
I-Node) and POC.
15
16
UMTS Access Network Collection Roadmap

For a collection roadmap, see Alcatel-Lucent 9300 W-CDMA Product Family - Document Collection
Overview and Update Summary (NN-20500-050).
17
New in this release

This section details what is new in Alcatel-Lucent 9300 W-CDMA Product Family - Performance
Management (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 OAM
upgrade processes
Other changes
New NPO document references.
18
Performance management introduction

The purpose of this chapter is to introduce the Performance Management concepts for the UMTS
Access Network.
It is split into:
Performance management purpose
Performance management applications
Counter observation benefits
Call Trace benefits
19
4.1
Performance management purpose

This 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 the
physical and logical configuration of the network and to locate potential problems as early as
possible. This leads to call drops reduction, better quality of service (QoS) and traffic increase.
The Performance Management portfolio focuses on the following features:
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 the following two types:
Counter observation data
Call trace data
Counter observation data

The observation counters, collected from different NEs, are used to calculate the number of
occurrences of an event.
The access network observation counters handled by the ADI application for the OAM06.0 release
are:
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 the
same telecom function or service.
The access network counters are divided into the three following families:
RNC counter families, see RNC counter observation data
MSS counter families, see MSS counter observation data
NodeB counter families, see Node B counter observation data
For further definitions of observation counters, refer to the 3GPP TS 32.104 specifications.
Counters are defined in the following dedicated counter dictionaries: Alcatel-Lucent 9300 W-CDMA
Product Family - Counters Reference Guide (NN-20500-028).
20
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 or
more mobiles, one or more cells. It can assist with the optimization of the radio engineering and the
network engineering of the UTRAN. This feature provides improved capacity, dimensioning and
traffic management of the networks.
Call Trace is a very powerful feature that allows the collection of very detailed information on one or
more mobiles, one or more cells. It can assist with the optimization of the radio engineering and the
network engineering of the UTRAN. This feature provides improved capacity, dimensioning and
traffic management of the networks.
21
4.2
Performance management applications

This 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, Geographical
Information System views and call trace analysis.
Data collection and mediation are performed by ADI (Access Data Interface) and MDP (Management
Data Provider).
The counter observation data post-processing is performed by NPO (Network Performance
Optimizer), 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 traces
information 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 is Access
Invoked Call Trace (CTb) and Geographic Call Trace (CTg).
RFO (Radio Frequency Optimizer), optional stand alone application for a "per call" trace analysis.
Note: Day-to-day monitoring of Access networks is available through real-time views displayed
from the main bar menu of NSP. These views allow a close observation of the NE behavior and
health. The physical & logical resources are displayed by selecting the Configuration/Radio
Access/physical & logical resources sub menu. For more information about this function see
Alcatel-Lucent 9353 Management System - User Guide (NN-20500-032).
22
4.3
Counter observation benefits

This section describes the benefit of the counter observation in the access network Performance
Management.
The performance measurement data is produced by NEs and made available to the operator for the
network performance monitoring and evaluation. The counters and metrics (indicators) combined
with the network configuration data represent a valuable source of information for 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 overall
health of the network in almost Near Time. Upon violation of these conditions the authorized users
will 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 the
OAM06 release.
23
4.4
Call Trace benefits

This section describes the benefit of the call trace data collection in the access network Performance
Management.
Call Trace is a very powerful feature that allows the collection of very detailed information about the
UTRAN resources and call management. The collection of detailed information can be tailored to the
specific 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 analysis
are 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
24
Counter and Trace overview

This section provides an overview of the principle and the architecture of the counter observation and
call trace data collecting.
It is split into:
UTRAN counter overview
Call Trace overview
25
5.1
UTRAN counter overview

This section describes the following topics:
Counter system architecture
RNC counter observation data
Node B counter observation data
26
5.1.1
Counter system architecture
This 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 management
parameter 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 a
counter list. One XDR file is generated at the end of every GP.
27
WMS is in charge of collecting data files from the NEs and exporting them in XML format (the
files from microNode B are already XML formatted). The WMS is also responsible for network
configuration export (CM.xml).
NPO is responsible of XML files and CM.xml file import and post-processing. It is also
responsible for QoS data computation and storage for network performance monitoring.
The results of the counter observations are XML record files, which store the Access Network
Observation data (counters). The DTD of this XML format is 3GPP-compliant. Each record file
contains the counters produced by a single collecting element (e.g. the C-node on RNC "N3" or the
Node B equipment "NB502").
You can use Network Performance Optimizer (NPO) to perform reporting of observations. NPO is the
performance reporting tool based on the internal platform and introduced in the OAM05.2 release.
NPO polls regularly the counter observation directory, uploads the XML counter observation files 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 Performance
Optimizer).
28
5.1.2
RNC counter observation data
This 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 function
or 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-BEARER
establishments (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 the
UE and cell levels.
QoS performance
These observation counters report the number of events attached to the downsizing/upsizing
service (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
29
(successful/failed), additions (successful/failed), deletions (successful/failed), and

reconfigurations (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 the highest
priority and 8 is the lowest one; 0 and 9 are unused in this version. Counter priorities are used 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 Product Family Counters Reference Guide for RNC (NN-20500-028).
30
5.1.3
MSS counter observation data
This section lists the MSS (I-Node and POC) observation counter families handled by the ADI
application.
Each Nortel Multiservice Switch (RNC I-Node and POC) observation family is attached to Managed
Object instances.
The RNC I-Node and POC observation counter families available for this release are classified as
follows:
ATM port
Logical Processor Use
Adjunct Processor Stats
GigabitEthernet
ACCOUNT ATM Vcc
ACCOUNT ATM Vpc
For the Nortel Multiservice Switch platform observations, see Alcatel-Lucent 9300 W-CDMA Product
Family - Counters Reference Guide for MSS (NN-20500-028).
31
5.1.4
Node B counter observation data
This 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 Power
Amplifier.
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 ATM
protocol.
Each Node B observation counter is attached to Managed Object instances.

About the Node B observations, see Alcatel-Lucent 9300 W-CDMA Product Family - Counters
Reference 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 and
9314 Pico Node B - Performance Measurement Manual (NN-20500-123).
32
5.2
Call Trace overview

Call Trace system architecture
Call Trace data flows
33
5.2.1
Call Trace system architecture
This section describes the components of the Call Trace feature.

A Call Trace application is considered to be distributed between the RNC and the OMC acting as
element manager. When a specification applies to the RNC alone, this is normally clearly mentioned.
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 various Call
Processing applications to provide Call Processing events as Call Trace data according to
configurable filters.
The Call Processing events may be RNC external or internal messages, snapshot of software
contexts 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 of
collecting this data and providing XML files. ADI also performs the necessary decoding and
mediation to generate Trace files based on consistent formats and object identifications. For
instance, some UTRAN messages traced by the RNC and coded in ASN.1 yet are decoded in ASCII
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 added value
information covering the different Call Trace needs: RF optimization, Network optimization,
troubleshooting.
WQA
processes the CTn traces and provides hand over matrixes used for neighboring optimization
(CTn module of WQA).
It also offers post-processing facilities to help investigating dropped call issues (CFt module of
WQA).
It also uses the CTx data, which are, in the OAM06 release, the data collected from CTg and
CTb, to optimize the UTRAN sub system, mainly the radio aspects, without requirement of drive
tests (CTx module of WQA).
34
5.2.2
Call Trace data flows
This section describes the call trace data flows.

The following figure provides described data flows, which are shown as arrows and referred to by 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. A
dedicated Call Trace Configuration Wizard is offered by WMS.
2. The Call Trace configuration data is sent on the configuration management data flow from the
OMC towards the RNC. This activates the Call Trace session on the RNC.2' The C-Node
transmits to the I-Node the configuration management data received from the WMS Server and
concerning the I-Node.
3. The call processing events are collected as Call Trace data, according to configurable filters,
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 or file
size conditions. If the trace has to be continued, then another file is opened.When a file becomes
available for upload from the RNC to the OMC, a dedicated event is sent on the Event data flow
by the RNC to the OMC. 4' . Conversely the Control Node may receive some events from the
35
Interface Node as "Trace File ready" events and forward them on the Fault Management data
flow.
5. ADI downloads the call trace files from RNC using ftp session and purges the call trace data files
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 converts them
to XML format. Then RFO or WQA, depending on the session files, get those files.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 Call Trace usage.
7. The RFO or WQA post-processing tasks can be performed on demand.
36
Counter and Trace activation

This section describes the mechanism of:
Counter observation activation
Trace activation
37
6.1
Counter observation activation

This section explains how to activate the observation data collection on RNC and Node B.
This section explains how to activate the observation data collection on RNC and Node B. it is split
into:
RNC observation activation
Node B and microNode B observation activation
MSS observation activation
38
6.1.1
RNC observation activation
This 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 of
counters.
At the RNC level the observation can be activated or deactivated from the OMC on operator request.
The RNC observation activity is associated with an OAM object, the PerfScanner, to form the
observation session. This session is automatically created at the RNC creation time with a default
granularity 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 results gatherings in
the NE. The GP is synchronized on full hour or half/quarter hour or full five minutes. 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 on the
disk of the C-Node. Then an observationFileReady notification is sent to WMS to trigger file
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 unlock
operation) 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 at
the 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 PerfScanner
is modified from 15 minutes to 1 hour at 16:17, then the next collection times at the Control Node
level are17:00, 18:00, 19:00, and so on.
If the C-Node receives a PerfScanner deletion (or lock operation) request, the in-progress statistics
are 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 the
39
C-Node/I-Node/POC.
RNC counter list management

Due to the increase of the number of counters in the UA06 release, a new mechanism ensures that
the volume of the configured counter records does not exceed the RNC capacity limit. It is applicable
only if GP is greater than 5 minutes.
This mechanism controls the activated RNC counter volume, and allows configuring and managing
an activated counter list.
To prevent exceeding the counter volume limits, the RNC applies the following defense mechanism:
When the configured counter volume exceeds 80% of the maximum supported volume, a
warning 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 a minor
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 WICL
commands. During this operation, if one or more counters families are configured, the WMS
unconfigures them.
The reason is that, when familyIdList is set (i.e. not empty), all its counters are collected by the
RNC whatever the counterIdList setting.
The operator sets the list of counters to be activated in the RNC through a counter descriptor file
(text-based file). For this purpose, a reference counter descriptor file is exported from the WMS using
PM ExportCounterList WICL command. The file is modified to activate/deactivate counters.
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 PM
ImportCounterList WICL command.
Note that these WICL commands must not be used for activation of UA06.0 NEs. The counter list
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 semicolon
delimited.
The Header section of the file is informative. When the file is generated from an export command,
this header provides details on the RNC from which the list is exported, on the UTRAN 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
40
06_00_00 is the utranRelease.

This field value corresponds to the UTRAN release of the RNC from which the counter list file
was originated, or to which the counter list file is to be applied. From OAM6.0 and onward, 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 supported utranRelease
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 3GPP
observation 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, the less
important the counter is considered. This value is used in case of resource shortage to stop
counter collection .
When a counter is configured, all its screenings are pegged; in the same way, when a family is
configured, 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 is re-activated
The CSV counter list files are stored on the Primary Main Server in the following directories:
41
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 storage space is
required on the server, the files are recursively purged by the WMS, the oldest files first, 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 the managed
UA5.X RNCs. If a customization was performed for those attributes prior to OAM6.0, it will be
preserved. The counter list management WICL commands do not apply to UA5.X RNCs.
In the OAM6.0 release, no upgrade is performed for the counterIdList/familyIdList when upgrading a
UA5.x RNC to UA6.0. If a customization was performed for those attributes prior to OAM6.0, it will be
replaced by the default values for those attributes in UA6.0/OAM6.0. After the upgrade to UA6.0, the
user will be able to manage the counter list of the RNC by using the dedicated 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 can be
customized by the user using the dedicated WICL counter list management commands.
42
6.1.2
Node B and microNode B observation activation
This section describes the counter observation activation mechanism in Node B and microNode B.
The Node B and microNode B observation session is automatically created after building the Node 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 the GP
modification request is received, the Node B continues applying the old GP value until (and including)
the end of the next top of the hour, and then apply the new GP value for the next collection periods.
The Node B generates and stores one observation file per GP with a maximum latency of 1 minute
after the end of this GP. The guaranteed storage duration is one day for 60 min GP files and six
hours for 15 min GP files.
The observation files are generated in XDR format.
No event is sent to the Main Server.
43
6.1.3
MSS observation activation
This section describes the counter observation activation mechanism in MSS paltform.
I-Node and POC counter activation and collection depends on the provisioning of the MSS Platform
and there is no correlation between the RNC (C-Node) observation and the MSS Platform counter
collection.
There are two kinds of counters available in MSS Platform: statistic counters and accounting
counters.
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 Platform collects
accounting data. Actually, up to 24 scheduled collection times can be set and the time difference
between two consecutive collection times must be greater than 1 hour and lower 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.
About INode counters

The INode generates one PM file every 15 min, for example:
file01 is genereated for the interval 10:00 to 10:15,
file02 is generated for 10:15 to 10:30, and so on.
The WMS should collect F1 no later than 10:20, F2 at 10:35,. This is the requirement implemented
for CNode or NodeB.
The INode requires additional time to complete the PM file, so an additional 28 minutes is taken into
account before collection. For example, this allows the WMS to collect the data as follows:
file01 for 10:15 is collected at 10:43 (plus 28 min)
file02 for 10:30 is collected at 10:58, and so on

Note: In Passive mode, INode counters are available with a 28 min delay
44
6.2
Trace activation
This section describes the trace activation mechanism, the trace sessions and the XDR trace data
files generated at the NE level.
It is split into:
Trace session activity
XDR trace data files
45
6.2.1
Trace session activity
The trace activity in the UTRAN can exist only during and within the frame of Trace sessions. A trace
session is managed within the OMC and the RNC through different managed object classes.
Currently, Call Trace is only supported by the RNC.
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 onto
one 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 the
involved NEs:
Trace records are generated in the Network Elements on occurrence of call processing related
events 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 specified
at the trace session creation.
When the C-Node receives an OAM request applying to the CallTrace or the ObjectTrace objects,
the request is executed locally and an equivalent request is transmitted to the applications of the
I-Node. The CallTrace/ObjectTrace files available on the disks of the C-Node and the I-Node are
automatically uploaded to the main server.
The trace session activity is stopped definitively on a time condition specified at trace session
creation or at trace session deletion. The type of trace, the nature of data traced and the involved
NEs are specified in the trace session creation command.
46
6.2.2
Call trace and Object trace sessions
This 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 the
session activation.
There is one and only one UE traced in an Access session. Therefore if n mobiles are to be traced
simultaneously, 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 the following
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 call
establishment.
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 learning
has been implemented which works as follows:
UE Identity Learning
For every traced call, both the temporary UE identity (TMSI or PTMSI) and the permanent NAS
UE Id (IMSI) are recorded.
47
Tracing
When a second traced call is made on a mobile, the call is traced if its initial UE identity matches
the IMSI that has been recorded.
Relearning
Whenever the initial UE identity (TMSI / PTMSI) of a mobile is changed, the new temporary
identity is re-learned during the next call made by the UE.
When creating an access call trace session, use the NBAP dedicated Measurement parameters to
optimize the periodicity of measurement reports. You can configure the periodicity of three
measurement types:
Signal Interference Ratio (SIR),
Round Trip Time (RTT),
Transmitted Code Power (TCP).
The NBAP Dedicated Measurement parameters is also available in the Geographical Session
creation.
For more information about the NBAP Dedicated Measurements, see the 3GPP specification UTRAN
Iub Interface NBAP signalling (TS 25.433).
To create an access session you can use WICL or the Call Trace Wizard application. See the
Creating one or more Access sessions on one RNC and Creating an Access session on multiple
RNCs procedures.
The XML CallTrace AccessSession files are generated on the main server in the following directory:
/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 is
terminated.
Geographical Session (CTg)

Use a Geographical call trace (CTg) session to trace calls established within a geographical area in
the 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 are
defined 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 a
Geographical 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.
48
Calls may be traced even during peak hours, but the provided ratio can be lower than the committed
ratio (some calls may not be traced).
As soon as the call is established within a cell belonging to a geographical area specified in an active
Geographical session, it is traced all the time the session is active and the RNC remains as the
SRNC of the related UE.
As a consequence, the call, once established, can be traced even if the related UE moves into areas
that do not belong to the geographical area.
The trace files are transferred to the server at intervals that are determined by the FileUploadSize FileUploadPeriod parameters and/or when the Geographical session is deleted.
Two Geographical sessions are supported per OAM simultaneously. Only one Geographical session
is supported per RAN.
It is possible to select the types of call that will be traced within the CTg session. The selection is
done through the callTypeList attribute on the CTg object class.
When creating a Geographical Session, you can set NBAP Dedicated parameters. See Access
Session.
Call failure trace in CTg

In order to provide an efficient means for call drop troubleshooting, the CTg record can be enriched
with call drop snapshots. These snapshots contain a set of information designed to help in
understanding the drop context. Detailed failure cause values are provided, along with data extracted
from the RNC call context (radio measurements, radio links configuration, HO states).
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 make it
possible to have in a synchronized way both traced messages allowing to build call DFD along
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 not
traced by CTg. This provides a complete data set regarding all the call drops happening in the
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. Associated
subfunctions are not considered, meaning that if at least one of them is set, the overall snapshot
content 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 investigating dropped
call issues.
49
Neighboring Session (CTn)

Use a Neighboring Call Trace (CTn) session to trace data that may be useful for cell neighboring
analysis 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 WMS server.
This allows the user to get measurements that are related to neighbor relationships established 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 or several
cells.
The objects are traced within a given cell. A cell session traces common messages on a cell or set of
cells (for example NBAP Common Measurements).
Depending on its configuration, a Cell session can trace a single cell, a group of cells in an RNS, or
all cells in an RNS.
Only one Cell session is supported at any time on each RNC. Two Cell sessions are supported per
OAM simultaneously.
During the Cell session management, the NBAP Common measurement feature enables the tracing
of NBAP Received Signal Strengh Indication (RSSI) and TCP measurements. Note that RSSI is also
referred to as Received Total Wideband Power (RTWP).
For more information about the Configuration Management trace parameters, see Alcatel-Lucent
9300 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 trace
50
records related to common RANAP messages on IuCs or IuPS interface. The list of scoped IuCs or
IuPS 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 a
given call) RNSAP messages on an IuR interface. The list of concerned Iur interfaces is configured at
the OAM level through a list of Neighboring RNCs.
The Object Trace IuBc (OTIuBc) session provides records related to common SABP messages on
an 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 Wizard
application.
To create an Access session see the Creating one or more Access sessions on one RNC and
Creating 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, an
IuR or an IuBC sessionprocedure.
Session templates
Use the Session template facility to define typical sessions to be used frequently. It allows the user to
specify the record types to be traced and their associated modes, any time you create a session. The
session templates are managed at the OAM level only; this can be done through the Wizard
interface.
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.
51
6.2.3
XDR trace data files
The file format of the trace files output by the RNC is XDR The XDR formatted call trace files are
then 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 Network
Element. For the particular case on the RNC, two files related to a session may be opened at a given
time, one in the C-Node and one in the I-Node, if the session manages trace records from both the
C-Node and the I-Node. If a trace record verifies recording criteria defined in different active trace
sessions, then it is recorded into an only trace file. Priority criteria are specified for identifying the file
in 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 collection
points. Each collection point has an event name associated with it and provides trace data with
ASN.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 traced
record 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 mode
applies only to UTRAN protocols PDUs (available for rrc, Iu, Iub, Iur 3GPP messages) and does
52
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 available
for 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 the
information provided by a trace data record depends on the collecting point in a dedicated
software module from which they are issued. The data records belong to the different types of
traced 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
53
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. All
items 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 is
known,
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 other
information 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 the
other 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
54
Counter and Trace collection and mediation

The purpose of this section is to describe the mechanisms used to upload the performance data from
the NEs to the MainServer.
This section is divided in two subsections:
Counter collection and mediation
Call trace collection and mediation
55
7.1
Counter collection and mediation

This section describes how the counter observation data is collected and mediated from the NEs to
become 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
56
7.1.1
Counter collection
From the OAM point of view, the observation counters are managed by the ADI (Access Data
Interface) application before being loadable into post-processing application.
RNC counter collection

As soon as the "observationFileReady" notification is received from the RNC, WMS starts the
collection of the observation files of a given GP using FTP (File Transfer Protocol). The file name 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 and there
is no correlation between the RNC (C-Node) observation and the MSS Platform counter collection.
The MSS Platform observation files are collected by WMS at suitable interval by forcing the file
closure. The data are formatted in BDF representation.
Once the MSS Platform counter observation files are retrieved, WMS deletes them. MSS Platform
can autonomously delete the files when the maximum number of stored files is reached.
Node B counter collection

WMS autonomously starts the collection of the observation files from all supervised Node Bs using
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 during subsequent
time period between the end of this collection process and the beginning of the next collection
process. The targeted observation files must not be older than 24 hours for the 60 min GP files and 6
hours for the 15 min GP files.
57
7.1.2
Counter mediation
When collected from the NEs, the Access Network observation counter files are handled by the ADI
application and stored in XML record files.
The role of mediation is to translate the raw data into a common format and to bind the observation
measurement to their associated objects in the logical model of the performance management
application. 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 output
are organized, how to identify the counter information they contain, how they can be compressed. It
also 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,
58
see DTD 32.401.02.

Some processing is done on the observation counters in order to provide temporal (different periods
of observation) and spatial aggregations. The observation counter records are then available as:
single period records
hourly aggregated records
All the counters are produced in each observation file (single, and hourly), and a predetermined
subset of these are aggregated at the RNC level.
To optimize the server storage capacity, the purge of the observation files is triggered automatically.
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 which indicates that the observation file contains observation data of a single NE
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 example
Region_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
YYYY
Description
The 4-digit year
59
Code
Description
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).
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). At

10: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.
60
7.1.3
RNC observation XML files
This section describes the file tree structure, the data formats and the file naming conventions used
by 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 period defines, 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 for a
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 21376 AAAA
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. This
mechanism is specific to the RNC C-Node.
When an OMU SWACT occurs, the counters do not appear in the Network Performance Optimizer
(NPO) application for the 15-minute window, and the file transmitted from the new active OMU to the
PerfServer contains only a portion of the data.
The following example is based on a 15-minute collect time, the last collect launched by OMU at 2:15
p.m., and notification sent and received at 2:20 p.m. (this means the previous collect is finished and
correctly 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 OMU
61
will 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 at
2:32 p.m., it will be too late to send a collect request. Therefore the next collect time will be at
2.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. before
any end of computing or before all the TMUs have time to send to the OMU their collect, the file
will be closed, and remain on disk with only the header, or part of the information or all of the
information if writing has already started. The next period of collect will be aligned on the correct
15-minute period. Therefore there is no notification sent to the OAM, and the period of collect
from 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 collect
request before SWACT occurs; this is quite rare, but can happen. Therefore there is no collect for
the 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. is
recorded. 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
PCZZA).
62
7.1.4
Node B observation XML files
This section describes the file tree structure, the data formats and the file naming conventions used
by 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 that the observation file contains data originated from a single
Node B for an hourly aggregation.
PCZZA).
63
7.1.5
XML observation file compression
At the installation time, you can enable or disable the compression file feature. When this feature is
disabled, the XML observation files consume more hard disk space. It is recommended not to
change the compression file setting before processing counter observation. If you want to modify the
compression setting, contact the system administrator.
The compression feature enables the compression of the observation XML files before they are
saved in the hard disk, using the "gzip" algorithm. Compressed file names follow the pattern
described 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 the
fmkpm_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.
64
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 counted
event occurs, and it provides the cumulated value for the observation period.
VALUE to record value accumulation. It offers the means of measuring minimum, maximum, and
the average values. The average value is an event weighted average.
LOAD offers the means of sampling rapidly changing data, and obtaining an average, a
minimum, 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 mechanism provides a
further "specialization" of the counters. For example, the screening TimeOut of the RNC counter
RadioLinkSetupUnsucess counts the number of unsuccessful radio link setup because of time out.
A counter record can be understood as a counter screening value for a given measured object
instance. More precisely, when a CUM counter screening is measured on an object instance the
result is one counter record; and when a LOD/VAL counter screening is measured on an object
instance, the result is four counters records.
Observation counter name

Counters are identified by name (for example: TheCounter). For some measurements, it is possible
to 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
65
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, see
Alcatel-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 3GPP
TS 32.300.
The following conventions are only used in the XML record file. For the NE identifiers used in file
naming 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 as
Relative 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 of
the 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
66
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 the
release of this DTD, as in the following example:
Figure 4 DTD versioning
67
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 errors can
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 Management operator
has the possibility to use a manual command that fetches all the files still present on the NE,
including whatever files not mediated that were not purged yet. The end result is XML observation
files saved in a specific directory but using the same directory structure as regular observations.
The WICL command is called RecoverObs. It triggers the recovery process and returns with a list of
files to be recovered. The recovered files are stored in the opt/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 server to
start the recovery and processing process.
the WICL command returns
the server transfers the files one by one, and processes them in sequence. The processing is
restricted to decoding, mediation, synthetic counter calculations and XML generation. No
temporal aggregation is made, and threshold for alarms are not evaluated.
68
7.2
Trace data collection and mediation

The treatments performed on the trace data at the main server level are sequenced as follows:
Figure 5 Call trace data mediation
Call Trace data collection
Call Trace data mediation
69
7.2.1
This section explains how the NE data are transmitted to the OMC.

The Trace data originated from the UMTS Radio network and available at the ADI level is aimed to
trace 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-processed to XML
files in order to ease the RFO or WQA post-processing.
70
7.2.2
Call trace data mediation
The collected trace files are made available to RFO in directories dedicated to each trace session:
CTb, CTg, OTCell, OTIuCs, OTIuPs, OTIuR, OTIuBc. The CTn files are made available for WQA in a
dedicated directory.
The trace data is stored in a directory hierarchy according to the day associated with the start time of
the 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 a
same call are gathered in a given set of files. These files contain records of different types as follows:
UeMgt (starttime, endtime)
Iu (RANAP events)
Iub (NBAP events)
Iur (RNSAP events)
Iubc (SABP events)
Iupc (PCAP events)
ALCAP
Snapshot C-node (important call processing events)
Error plane (erroneous or out-of-sequence messages on all interfaces)
QoS (Quality of Service events)
Neighbouring call trace in CTn session.
This data is stored in dedicated files using XML formats. The formats of the produced XML files are
described further below.
The protocol events (i.e. SABP, PCAP, RRC, RANAP, NBAP and RNSAP events) are stored
according to the concerned interface: RRC, Iu, Iub, Iur as values of XML elements in an hexadecimal
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 provide essential
information in a convenient format. RRC measurements (intraFrequency and trafficVolume), which
are sent already decoded from the RRC messages, are displayed as XML tags.
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 to imprevisible
71
results.
One file uploaded by a CTg session may mediate into several files, one session file plus one file per
traced call.
One file uploaded by a CTb session always mediates in two files, one session file plus one trace file,
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 record
identifies the object(s) that produced it.
Each Trace session is associated with a CT_<sessionId>.xml log file located at the root of the daily
hierarchy. A log file stores the list of traced communications for the associated session. These logs
may be used to retrieve trace data associated to a particular session. This file has its own DTD
description, 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. Such a 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
72
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 following directory:
/opt/nortel/data/utran/callTrace/onOAMdemand/<sessionId>/<YYYYMMDD>/<UEid>/<callid>/*
The XML geographical trace files are generated on the main server in the following
directory:/opt/nortel/data/utran/callTrace/originatedFromGeographicalArea/<sessionId>/<YYYYMMDD>/-<rc>/ca
The rc field in the hierarchy is added when the number of calls in one day is over the maximum
number of directory entries supported by the OS. So when the YYYMMDD directory is up to the
maximum capacity, a YYYMMDD-2 directory is added, then a YYYMMDD-3. There never is a
YYYMMDD-1 directory.
The XML Neighboring Session files are generated in the following
directory:/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 the following
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 encoded
hexadecimal format.
Each trace session is associated with a log file located at the root of the daily directory hierarchy. The
log file stores the list of traced communications for the associated session. Use these logs to retrieve
trace 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 the
73
day. 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 same trace
session are located in the same directory. The OAM replaces the RNC traceKey by its own string
tracekey which is unique for the whole server. The ADI groups all the data related to a 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 has
started 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 is
stored 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 is
disabled, the XML observation files consume more hard disk space. It is recommended not to
change the compression file setting before processing traces. If you want to modify the compression
setting, contact the system administrator.
The compression feature enables the compression of the xml files before they are saved on the hard
disk, 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 the
fmkpm_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.
74
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 of
the older DTD file are kept in a separate DTD file to describe the management record files. The main
DTD file is called 32.108-contrib02.dtd.
75
Figure 6 Call trace DTD-first part
76
Figure 7 Call trace DTD-second part
77
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 defined
by 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 standard are
represented in italics.
Figure 9 Object trace DTD-part 1/4
78
79
Log file DTD
80
The CT_<sessionId>.xml log file located at the root of the daily hierarchy has its own DTD. The
corresponding description is found in the following mgtData.02.dtd figures:
Figure 13 Management data DTD (Part 1/3)
81
82
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, for
the 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
traceCollection
This is the top-level element. It vendor (optional), sender,

identifies the file as a collectraceRecSession
tion of trace data. It has 2 attributes:
version: file format version

applied by the sender. The
default format version is
01.
collectionBeginTime:
timestamp that refers to
the start of the first trace
data that is stored in this
file. It is a complete
timestamp including day,
time and delta UTC (check
if it is UTC) hour.
Contents
vendor
Optional element that identifies the vendor of the equipment that provided the trace
file. Set to Alcatel-Lucent
sender
The sender uniquely identifies string

the NE or EM that assembled
this trace file, according to the
definitions in 3GPP TS 32.106.
string
83
It is identical to the sender#s

nEDistinguishedName. This
element has one optional attribute:
type : type of the network

node that generated the
file.
Example:
RNC, SGSN
traceRecSession
ue
evt
This element contains the

traced data associated to a
call of a traced mobile. It has 3
attributes :
traceSessionRef : unique
trace identifier provided at
the trace activation by the
Operator or allocated by
the management system.
traceRecSessionRef : Required attribute that

provides a unique identifier
of a traced call. This identifier is attributed to all trace
records associated to a
call. It is unique for a period of time sufficient to
avoid any collision.
stime : optional attribute

that provides the start time
of the call.
UE identifier provided in trace string

activation messages. It can be
IMSI or IMEI. It has 2 required
attributes:
uetype : user equipment

identifier type (IMSI,IMEI
or Public User Id)
ueid : the ue identifier

value
The evt element contains the initiator (opt) target (opt) mesinformation associated with a sage (opt) cause (opt) IE (0..)
traced message. It has the fol- IEGroup (0..) object (0..)
lowing required attributes:
function : function name

associated with the traced
message.
84
Example:
RRC, Iu CS, Iub, Intra
frequency measurement, Gb
initiator
name : protocol message

name
changeTime : time difference with the beginCollectionTime. It is expressed in

number of seconds and
milliseconds (nbsec.ms)
vendorSpecific : boolean
value that indicates if the
message is vendor specific (true) or not (false).
nEDistinguishedName of NE
string
initiator of the protocol message. The string may be
empty (i.e. string size =0) in
case the initiator is the sender
or the mobile. This element
has one optional attribute:
type: type of the network

node that initiate the message.
Example:
RNC, SGSN
target
nEDistinguishedName of NE
target of the protocol message. The string may be
empty (i.e. string size =0) in
case the target is the sender
or the mobile. This element
string
type : type of the network

node that receives the
message.
Example:
RNC, SGSN
message
The element value is the hexa- string

decimal, ASN.1- encoded form
of the message. This XML element has two required attributes:
85
protocol : protocol name

associated with the event.
Example:
Ranap
See supported protocols
below.
cause (global)
version : protocol version
The element value is the event string

cause value The value is the
ENUMERATED value carried
by the message as defined in
3GPP TS. Unknown or unexpected cause values are written in numerals. This XML element has one required attribute:
type : cause type.

Example:
failure cause may be
unknown
IEgroup (global)
This element contains one or

more IE. This XML element
IE (1..) IEGroup (1..) object

(1..)
name : IE group name

Example:
RAB parameters
IE (global)

string
value of an IE decoded from a
traced message. This XML
element has one required attribute:
name : IE name
Example:
Minimum DL Power
object
This element contains IE asso- cause (opt) IE (0..) IEGroup

ciated with a specific object.
(0..)
(e.g. radio link, RAB). It has 2
required attributes :
type : object type

Example:
Radio link, RAB
id : object identity
86
Example:
RABid
Among those tags, some are considered as specific, which means that the information they contain
is defined by the tag itself. The table above fully defines these tags and the meaning of their
contents.
On the contrary, the <evt>, <IE>, <IEGroup>, and <object> tags are generic, which means that their
contents 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 discriminating
attribute 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
traceCollection
This is the top-level element. It vendor (optional), sender,

identifies the file as a collectracedObject
tion of trace data. It has 2 attributes:
tracedObject
version : file format version

applied by the sender. The
default format version shall
be 01.
collectionBeginTime :
timestamp that refers to
the start of the first trace
data that is stored in this
file. It is a complete
timestamp including day,
time and delta UTC (check
if it is UTC) hour.
Contents

ue evt (0..)
traced data associated to a
call of a traced mobile. It has 3
attributes :
traceSessionRef: unique
trace identifier provided at
the trace activation by the
Operator or allocated by
the management system
type: Required attribute

that provides the tyupe of
the traced object : may be
Cell or NeighbouringRNC.
87
evt
The evt element contains the

information associated to a
traced message. It has the following required attributes:
function : function name

associated to the traced
message.
initiator (opt), target (opt), tracedIds (opt), message (opt),

cause (opt), ue (opt),
traceRecSessionRef, IE (0..),
IEGroup (0..), object (0..)
Example:
RRC, Iu CS, Iub, Intra
frequency measurement, Gb
name : protocol message

name
changeTime : time difference with the beginCollectionTime. It is expressed in

number of seconds and
milliseconds (nbsec.ms)
vendorSpecific : boolean
value that indicates if the
message is vendor specific (true) or not (false).
traceRecSessionRef
A system-generated string that String

uniquely identifies the call that
generated the present event.
tracedIds
The empty element lists the

cell ids that are associated
with the particular trace, if
available. The element is
missing if there is no cell ID
available.
empty
idList : Comma-separated
list of object ids as contains no blanks.
OT-cell : list of fddCell
cellId
OT-Iur : neighbouring
RNC rncId
OT-IuCS : CS-<#>
(with the network ID )
OT-IuPS : PS-<#>
(with the network ID )
OT-Iubc : interface is
unique, element is absent
88
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-demand decoding
in the case of Rrc, the channel name is concatenated with the Rrc string. Possible channels 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 be NO_CHPDU_ID.
version attribute: In the <message> tag, the version attribute indicates which version of a given
ASN.1 description was used to encode the data block. It is used by the on-demand decoders to
decode the blocks. The version number is an Alcatel-Lucent internal flag, the supported numbers
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 tables should
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
Originating Conversational Call
Originating Streaming Call
Originating Interactive Call
Originating Background Call
Originating Subscribed traffic Call
Terminating Conversational Call
Terminating Streaming Call 7
Terminating Interactive Call 8
Terminating Background Call 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
89
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)
Cause value
Cause text
normal event
unspecified
pre-emptive release
congestion
re-establishment reject
user inactivity
directed signalling conn
default
unknown cause = <cause#>
Table 5 List of Cause values for the <cause type = IuRelCause> (3GPP)
Cause value
Cause text
RAB pre-empted
Trelocoverall Expiry
Trelocprep Expiry
Treloccomplete Expiry
Tqueing Expiry
Relocation Triggered
TRELOCalloc Expiry
Unable to Establish During Relocation
Unknown Target RNC
10
Relocation Cancelled
11
Successful Relocation
12
Requested Ciphering and/or Integrity Protection Algorithms not Supported
13
Conflict with already existing Integrity protection and/or Ciphering information
14
Failure in the Radio Interface Procedure
15
Release due to UTRAN Generated Reason
90
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 PriorityRelocation 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 Target

SystemRelocation
30
Invalid RAB ID
31
No remaining RAB
32
Interaction with other procedure
33
Requested Maximum Bit Rate for DL not Available
34
Requested Maximum Bit Rate for UL not Available
35
Requested Guaranteed Bit Rate for DL not

Available
36
Requested Guaranteed Bit Rate for UL not

Available
37
Repeated Integrity Checking Failure
38
Requested Request Type not supported
39
Request superseded
40
Release due to UE generated signalling connection release ported
41
Resource Optimisation Relocation
42
Requested Information Not Available
43
Relocation desirable for radio reasons
44
Relocation not supported in Target RNC or

Target system
45
Directed Retry
46
Radio Connection With UE Lost
91
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 To

PUESBINE 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 Constructed

Message)
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. It means
92
some sort of error appeared on the RNC when creating a record containing an ASN.1 protocol
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.1

message, if it exists, the contents of the
<message> tag are unreliable, if decoding of
the ASN.1 bytes is attempted, the results
should be discarded.
OVERSIZED_ASN1_MSG_IS_TRUNCATED
Too many ASN.1 bytes to report, the

<message> tag holds the first bytes of the
message. Partial decoding of the ASN.1 may
be possible, decoding result is partial, but reliable.
OVERSIZED_ASN1_MSG_IS_DISCARDED
Too many ASN.1 message bytes to report, the

<message> tag is missing. No decoding is
possible.
OVERToo many XDR bytes to report in a data block.

SIZED_CONTEXT_FULL_DATA_IS_DISCAR Contex-full data block is missing.
DED
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 (for
example, 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
93
The XML documents produced by ADI only use UTF-8 characters (ISO 10654-1): the binary values
are stored as hexadecimal strings.
Basic types
The XML element values are always strings. Depending on the 3GPP Recs, these strings can be
interpreted 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 the
ASN.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 traceRecSessionRef
attribute of the traceRecSession element.
Timestamps
Each trace records is likely to have one timestamp given by the original application running on an
RNC TMU (proc timestamp). Each produced XML file uses the cbt or cet element to encode a full
timestamp ( day+local time+#GMT).
This timestamp is produced at the RNC OMU level for the first trace record of the file. The cbt
element has the following syntax:
<YYYYMMDD>.<hhhhmmss><#GMT >
See the following table for an interpretation of the codes:
Code
Description
94
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). It

changes 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 +0100
thus 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 cbt
value is <cbt>20040422181223-0500</cbt>.
Each traced information has its own changeTime (c attribute) value expressed in seconds and
milliseconds since the collectionBeginTime (cbt). Milliseconds are always expressed as zeroed-three
digit 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 as
Relative 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 of
the class (for example RNC).
No assumption can be made on the character case used by className: rnc. RNC and RNC identify
the 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 the
following characters:
95
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)
Iu (RANAP events)
Iub (NBAP events)
Iur (RNSAP events)
IuBC (SABP events)
Iupc (PCAP events)
ALCAP
Error signaling plane (erroneous or out-of-sequence messages on all interfaces)
Snapshot C-node (important call processing events)
Quality of Service events (QoS)
DHO Power control
CTn
For further information about these events, see UTRAN Call Trace Events Dictionary
(UMT/SYS/DD/009157).
96
Operational Alarm on thresholds for access observations

This 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
97
8.1
Overview of Alarm on thresholds

The Alarm on threshold function allows the operator to be quickly informed of significant counter
observation related events. The authorized users can set the threshold (minor, major and critical) for
performance event, and define rule sets for violation event.
The alarm on thresholds feature consists of three functions: counter collection, threshold detection
and 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 value
specified 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 (for example,
when a threshold exceeds or returns to a normal value), an alarm start or an alarm end is notified to
the access EMS software. The alarm is pushed to the upper layer applications Access-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 main
server in a correct format. ADI is responsible for:
the RAN Model to 3GPP containment mediation
the XML file production.
98
8.2
Architecture of Alarm on thresholds

This 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 or
the 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 successive
counter 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 object
instance definition supersedes the class definition for threshold detection.
To associate the threshold set rules and conditions with the counters you can perform the following
actions :
Configuring the alarm thresholds for a counter.

This can be performed via a dedicated XML definition file located in the directory
/opt/nortel/data/custom/utran. There is one dedicated configuration file by NE type: one for the
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 access
observations procedure.
Hysteresis management.
This function avoids the emission of multiple start and end alarms when the successive counter
values 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 are
being raised.
99
100
8.3
Syntax of alarm on thresholds

The 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 refPeriod
of 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, its
hour-equivalent value is 5 x n.
if the counter value a has been measured for a 15-minute observation duration, its
hour-equivalent value is n.
The observation duration is not the granularityPeriod: it is the real measurement period at NE
level.
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
101
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
102
The syntax of the objects is defined as follows:

<object> := <object relative distinguished name>
<object relative distinguished name> := <object type name> = "<object relative
identifier>".
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 more
information.
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, which
means 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 the
following 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
103
Object type name
Class name
TMU
R/RncEqp/CN/TMU or TMU
CC1
R/RncEqp/CN/CC or CC
BTSEquipment
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
ANode
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
104
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.
105
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 in
the/opt/nortel/config/utran/gpo/CP_APM_UTRAN_xdrClassTable.cfg file.
106
8.4
Tools of alarm on threshold

Use the fmkpm_thdsynchck.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 file
CP_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)]
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 to
modify 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:
107
For example, the following command loads the Node B threshold definition file
CP_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)]
Load threshold definition file successfully.
108
8.5
Hysteresis
This section describes how to avoid sending multiple start/end alarms when the successive counter
values 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 means
the 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 the
alarm 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.
109
8.6
Alarm management
This section introduces the following topics:
Alarm definition
Protection against flooding
Alarm definition
The probableCause associated with threshold crossings is {5676, "thresholdCrossed"} as shown in
the following table:
Attributes
Time
Value
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:
Alarm Severity
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
Depends on threshold definition
Alarm on threshold flooding

This section introduces the following topics:
Alarm flooding mechanism
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
110
observation periods, until the flooded alarm is cleared, and this even if the threshold is
continuously being over-crossed.
The alarm flooding condition is always examined against the total number of threshold-crossed
object instances in the CURRENT observation period.
The individual start alarms raised on the same counter before the flooding observation period
must be cleared separately and independently by the corresponding end alarms. They cannot be
cleared 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. A
new 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 the object <object_a> still crosses the threshold. No
new alarm is raised on the object.
The counter <counter_a> meets the clearing condition of the flooded alarm. A clear
alarm <clear_flooded_alarm_b> is raised on the root object <root_object_a> to
clear the associated flooded alarm <new_flooded_alarm_b>.
The counter <counter_a> of the object <object_a> still crosses the threshold. No
clear 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>.
The counter <counter_a> of the object <object_a> goes beyond the threshold. A
new 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
111
alarm <new_alarm_a>.
The counter <counter_a> meets the clearing condition of the flooded alarm. A clear
alarm <clear_flooded_alarm_b> is raised on the root object <root_object_a> to
clear the associated flooded alarm <new_flooded_alarm_b>.
The counter <counter_a> of the object <object_a> is still within the threshold. No
clear alarm is raised on the object.

Whenever numerous alarms are generated for a given threshold, these alarms are replaced by a
single alarm, held by the container object which is always the root object of the alarming NE in the
RAN model. That means RNC for RNC CNode, RNC/RNCEquipment/INode for INode, and
BTSEquipment for BTS.
When an alarm flooding condition is detected, the single start alarm raised for the flooding condition
always 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 field
are left empty, because the flooded alarm is used to suppress numerous individual alarms with
different target class IDs, counter values and threshold values.
112
9 Access Data Interface (ADI) and Management Data Provider (MDP)

applications
This section is an overview of ADI and MDP, applications involved in the performance management
process.
Access Data Interface (ADI)

The ADI application provides the interfaces for Access Performance and Configuration data between
the Access Performance Management (APM) and NPO or external applications. The APM 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 on
consistent formats and object identifications. For example the UTRAN messages traced by the RNC
and 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 are
exported 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) observation
records 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 Data
Format (BDF) file format.
113
10
Wireless Quality Analyzer (WQA)

WQA is an optional application designed to provide ability to reflect graphically Call Trace information
issued from Utran networks.
It is deployed in a ROC configuration but it is not hosted by the WMS servers and it requires a
dedicated hardware.
Introduction
WQA is designed to provide ability to reflect graphically the following Traces information issued from
the UTRAN networks:
CTn
The Utran Neighboring Tuning feature allows to build proposal to optimize the neighboring
declaration based on a dedicated UTRAN information flow.
CTx
CTx is the whole of several types of Call Trace. This feature allows customers to optimize the
UTRAN sub system, mainly the radio aspects, without requirement of drive tests. The UTRAN
traces bring very detailed information on UTRAN behavior. This information can help on
engineering analysis of the network performances. In OAM6.0, two Key Performance Indicators
(KPI) are available and these KPI are computable through information available in CTb and CTg
trace sessions.
The Call Failure Traces (CFt) data are also collected to allow the customers to optimize the UTRAN
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 data
reporting
The CTn and CTx data is collected from the UTRAN and mediated to an XML file in WMS (see Trace
data 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 is
stored in the WQA data storage. Data Analyzer is used to retrieve processed data and organize it
into logical reports that are accessible via http to the WQA users.
Neighbouring Call Trace processing
114
WQA processes the Neighboring Call trace information to provide the users with proposal for adding
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. The neighboring
tuning module of WQA then uploads the data on this external interface and provides 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 by
Alcatel-Lucent are also available in WQA.
CTx analyzis
The post processing of the CTb and CTg traces data by WQA allows computing Key Performance
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 file size
will be reduced by keeping the useful functions only (RRC, UEMgt).
CFt analysis
WQA Documentation
Table 9 WQA for WMS documentation
Title
Description
Alcatel-Lucent 9351 Quality Ana- The WQA Administration Guide provides the software engineer with the steps to install the WQA product.
lyzer - Installation Guide (CTn
part) NN-20500-126
Alcatel-Lucent 9351 Quality Analyzer - Administration Guide (CTn
part) NN-20500-127
The WQA Administrator Guide provides information on administration of the WQA product, including user access
managing and report schedules, and objects exporting and
importing within the WQA repository.
Alcatel-Lucent 9351 Quality Ana- This guide covers the following features and functions of
lyzer - User Guide for CTN mod- WQA:
ule NN-20500-128
WQA access:login/logout, managing account, changing
general options of the WQA interface, changing report
editing preferences
115
Title
Description
Call trace neighboring analysis reports:user interface

overview, access and description of the sets of standard and predefined reports.
User functions:functions that allows to design, and deploy enterprise analytic reports with the web browser interface.
Alcatel-Lucent 9351 Quality Ana- This document provides additional information about possible issues during installation of the WQA product and the
lyzer - Troubleshooting Guide
appropriate solutions.
(CTn part) NN-20500-129
Alcatel-Lucent 9351 Quality Ana- This document describes the basic features of the user inlyzer - User Guide for CTX mod- terface and how to perform the access to the standard reule NN-20500-165
ports.
It also describes the set of on-demand and cached CTx reports. Each report is described in a separate section.
Alcatel-Lucent 9351 Quality Ana- This document describes the basic features of the user inlyzer - User Guide for CFT mod- terface and how to perform the access to the standard reule NN-20500-164
ports.
It also describes the set of predefined CFt reports. Each report is described in a separate section.
116
11
Network Performance Optimizer (NPO)

This section is an overview of Network Performance Optimizer (NPO), the performance reporting
solution based on the internal platform.
NPO Overview
NPO is a GUI driven application with full flexibility for reporting (drag and drop, markers etc) and
creation of indicators. It offers a full range of multi-standard QoS monitoring and radio network
optimization 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 and
calculated 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 Performance Optimizer
(NPO), the basic principles of NPO administration, how to open administration pages, how to
start Data Management and NPO Import /Export Management, the NPO configuration tasks.
NPO / 9953 MP Introduction (3BK 21370 AAAA PCZZA)

This guide describes how to use the Network Performance Optimizer (NPO) in order to view and
manage counter and indicator values for various network objects, and to know how to monitor
and optimize the radio network.
current terminology introduction
117
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 (3BK 21172
AAAA TQZZA)
This documentation is composed of 5 volumes:
Base Line Indicators
Basic Indicators 1/3
Extended Indicators
118
12
Radio Frequency Optimizer (RFO)

This section is an overview of Radio Frequency Optimizer (RFO), the post-processing tool of the
XML 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 is systematically
performed.
All the supported messages are decoded and the information is stored in the database. After this
step, this file is no longer used, RFO only uses the information in the database. That means that the
original input file, on the WMS Server, may be moved or suppressed without consequences on the
database.
Then:
if one input file contains call traces for several mobiles, this file is seen as several files in RFO,
if several Call Trace files are related to the same session for the same UE, they are combined 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)
119
13
Call Trace Configuration Wizard application

Use the Call Trace Configuration Wizard application from the NSP GUI to manage Call Trace and
Object 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 session
templates. You can also create custom templates, based on predefined trace records.
The Call Trace configuration Wizard interface
Using the Call Trace configuration Wizard
120
13.1
The Call Trace configuration Wizard interface

This section introduces the main window and the buttons of the Call Trace Configuration Wizard
interface.
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 some
particular 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 bar
details the state of the operation;
121
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 or
selected in the window part, which is dedicated to the operation. It is not available on the last wizard
window.
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.
122
13.2
Using the Call Trace configuration Wizard

This 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 a
synchronization 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 session
template report.
123
124
14
Performance Management procedures

This section presents the performance management procedures represented by tasks organized in
the following order:
125
14.1

Use this procedure to allow the OAM to retrieve the Node B observation files after an IP address
change, 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 the
Node B with the new IP address.
--End--
126
14.2

This 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 for
whatever 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
127
14.2.1
Configuring a threshold definition file
The following procedure explains how to configure alarm thresholds for a given counter in a threshold
definition 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. If
you do not know the class name of the object(s) on which you want to define a threshold, see
the 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 which
identifier 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 of
the selected class.
If you do not know the identifier of the object for which you want to configure alarm
thresholds, 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 of
alarm on threshold.
128
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 for
an instance of a class without hysteresis (no endvalue parameter) and without normalization (no
refperiod 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 threshold
definition 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 the
dedicated tool: fmkpm_thdreload.sh. For more information, see Loading the threshold definition
file.
--End--
129
14.2.2
Checking the syntax of the threshold definition file
The 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 and
enter 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--
130
14.2.3
Loading the threshold definition file
The following procedure describes how to load the threshold definition file, for the new parameters
defined 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, see
Loading of the threshold definition file.
--End--
131
14.2.4
Determining the identifier of an RNC
The 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 the
parameters of the specific RNC:
>: RNC <RNC User Label> dis
Example:
The following command displays the parameters of the RNC_03:
>: RNC RNC_03 dis
It returns the following result:
...
aliasName
clusterId Cluster/UMAINSERV1
frequencyBandList umtsBand
inAccessOperationalState enabled
isNmoClass3Allowed false
isSysInfoChangeNotifMobilesFach true
isSysInfoChangeNotifMobilesIdle true
iubHeartbeatNumAttempts 2
iubHeartbeatPingTimeInterval 1000
iubHeartbeatUdpPortNumber 65535
modelName 0
numberOfServiceGroups 3
operationalState enabled
outageGranularity 30
132
passiveSystemRelease UNSET
perfServerId UPERFSERV1
pmClusterId PMCluster/UPERFSERV1
provisionedSystemRelease 06_00_00
rdnId 0
rncArchitecture rnc1500
rncFamily rnc1500
rncId 20
rncNSAPAddress 4711111111222222222233333333334444444200
runningSoftwareVersion RNC-6.0.0-RI60425091701s (Secure)
stateChangeNotificationDelay 15
systemRelease 06_00_00
unknownStatus unknownstatusfalse
upgradeStatus IDLE
userSpecificInfo ...
...
In this example the rncId is20.
--End--
133
14.2.5
Determining the identifier of a Node B
The 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 the
parameters 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 2UV2_P2:
>: RNC RNC_03 NodeB 2UV2_P2 dis
It returns the following result:
...
administrativeState unlocked
alcapCellValidityTimer UNSET
associatedBTSEquipment UNSET
connectionMode passive
endPoint 20
ibSgDataEncodingVariant variant2
isCellReconfSupported true
isManualOVControlAllowed false
isNbapCommonMeasRsepsAllowed false
isSilentModeAllowed true
iubIfId 1
manualOverloadThresholdEventA 65535
manualOverloadThresholdEventB 65535
nodebCapability 0
134
nodeBConfClassId RadioAccessService/0 DedicatedConf/0 NodeBConfClass/0

nodeBId 257
nodebType iBTS
note UNSET
rdnId 0
rnarProfileRefForManualActivation UNSET
serviceGroupId 0
softShutdownAllowed true
startPoint 50
sttdIndicator false
userSpecificInfo UNSET
...
You must use the relative distinguished name of the Node B (nodeB,0), as defined in the
Mapping of object type names on object relative identifiers table. In this example, the
distinguished name to be used in the threshold definition file is 0.
--End--
135
14.3

This 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 in
Alcatel-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.
136
14.3.1
Launching the Call Trace Configuration Wizard
The 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 to
create 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 menu
of the wizard.
137
Figure 20 Call Trace Configuration Wizard main window
--End--
138
14.3.2
Creating one or more Access sessions on one RNC
The 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 multiple
Access sessions, it is possible to set the NBAP Dedicated Measurement parameters for the selected
RNC.
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 an
example of equipment and NBAP parameter selection:
139
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 NBAP
parameters fields. Note that in this case, you must select one of the following templates in the
Session 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. The
following figure is an example of Mobile identification and session parameters selection:
140
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 of
characters is 32.
Start Time: enter the lapse of time (in minutes) between the creation of the session and its
141
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 and
made 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 the
corresponding 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.
142
Figure 23 Summary window of an access session creation on a single RNC
The externalSessionId is computed automatically during creation. It is unique for each

created TraceSession and different than 0. The username and the dateCreation are
computed 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 window
describing 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, the
following window appears with the results:
143
Figure 24 Result window of access session creation on a single RNC
16. Click Close to close the window.

--End--
144
14.3.3
Creating an Access session on multiple RNCs
The 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 Access
session on one or more RNCs, it is possible to set the NBAP Dedicated Measurement parameters for
each 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 an
example of equipment and NBAP parameters selection:
145
Figure 25 Create single Access Session window
6. If you want to consider specific NBAP Dedicated Measurements, modify the RNC and NBAP
parameters fields. Note that in this case, you must select one of the following templates in the
"Session Template" list (next window):
a custom template,
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.
146
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 multiple RNCs
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
147
characters is 32.
Start Time: enter the time lapse (in minutes) between the creation of the session and its first
activation.
made available.
14. Click Next.

The parameters selected are verified. An error message is returned if:
The UE identifier is not typed correctly.
The file upload size value exceeds the maximum authorized value.
A window appears with a summary of the session parameters selected.
148
Figure 27 Summary window of access session creation on multiple RNCs

created trace session and different from 0. The userName and the date are computed by the
server during creation.
15. Click Create to confirm the access session creation.
16. Click Finish.
If the operation fails and the Launch report window on close option is enabled, a window
describing 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.
149
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 new
window 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
150
--End--
151
14.3.4
Creating a geographical session
The 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 a
Flat View. The view type can be selected from the combo box on the top of the list. The
Selected Equipments field displays the selected FDDCells or RNCs.
5. Use the command buttons in the middle of the window:
152
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 attached
to 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 shows
an 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 containing
selected objects (CNodes or FDDCells).
7. If you want to update the RNCs and NBAP parameters, select the RNC you want to update
before accessing the RNCs and NBAP parameters fields. Note that in this case, you must select
one of the following templates in the Session Template list (next window):
a custom template,
the Optimization template.
153
a multiple of 500.
You cannot modify the NBAP parameters of a RNC if you have not selected all the objects
contained in this RNC for the trace session.
For the NBAP Dedicated Measurements feature description, see theGeographical Session
section.
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.
154

"StandardTroubleShooting" is selected.
characters is 32.
first activation.
made available.
12. Click Next.


A window appears with a summary of the session parameters selected:
155
Figure 32 Summary window of geographical session creation

created trace session and different than 0. The userName and the date are computed by the
13. Click Create to confirm the cell session creation.
14. Click Finish.
If the Launch report window on close option is enabled, a new window appears with the
results.
The following figure is an example of successful trace session creation:
156
Figure 33 Result window of geographical session creation
This windows displays the details of all attributes of the created trace session and the details
of the failure if a failure occurs.
--End--
157
14.3.5
Creating a Neighbouring session
The 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
158
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 attached
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 the
Cell 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..
159
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 table
and 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 session
use only.
160
characters is 32.
first activation.
made available.
14. Click Next.


161
Figure 37 Summary window of neighbouring session creation

created trace session and different from 0. The userName and the date are computed by the
16. Click Finish.
results.
162
Figure 38 Result window of neighbouring session creation
A window displays the details of all attributes of the created trace session and the details of
the failure if a failure occurs.
163
--End--
164
14.3.6
Creating a cell session
The 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
165
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 attached
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:

166
The default value 0 corresponds to an infinite session duration
characters is 32.
first activation.
made available.
8. Click Next.

167
Figure 41 Summary window of cell session creation

created TraceSession and different from 0. The username and the dateCreation are
computed by the server during creation.
168
10. Click Finish.

results. The following figure is an example of successful trace session creation:
Figure 42 Result window of cell session creation
169
This window displays the details of all attributes of the created trace session and the details
of the failure if a failure occurs.
--End--
170
14.3.7
Creating an IuCS, an IuPS, an IuR or an IuBC session
The 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. For
example, for an IuCS session creation:
171
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.

characters is 32.
first activation.
172
made available.
7. Click Next.

A window appears with a summary of the session parameters selected. For example, for an
IuCS session creation:
173
Figure 44 Summary window of IuCS session creation

created trace session and different than 0. The userName and the date are computed by the
174
9. Click Finish.
results.
Figure 45 Result window of IuCS session creation
175
A window displays the details of all the created trace session attributes and the details of the
failure if a failure occurs.
--End--
176
14.3.8
Deleting trace sessions
The 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 the
existing 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:
177
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 the
trace 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:
178
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 is
same as the following:
Figure 48 Example of wizard status window
179
7. Click Finish.
results. 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 a
failure occurs.
--End--
180
14.3.9
Creating a trace session template
The 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
181
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:
182
Figure 51 Summary of trace template creation
9. Click Create to confirm the trace session template creation.

183
Figure 52 Example of wizard status for template session creation
10. Click Finish.

results. The following figure is an example of successful trace session template creation:
184
Figure 53 Result window of session template creation
This windows displays the results of the call trace template creation and the details of the
failure if a failure occurs.
--End--
185
14.3.10
Deleting a trace session template
The 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 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 call trace template to delete:
Figure 54 Deletion trace template window
186
4. Select the trace template(s) to delete.

To delete more than one templates at the same time, press the "Ctrl" tab while selecting the
templates 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 Session
Templates" field. The following figure is an example of confirmation of the template to be
deleted:
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 is
same as the following:
187
Figure 56 Wizard status window in template deletion
7. Click Finish.
results.
The following figure is an example of successful call trace template deletion:
188
Figure 57 Result window of session template deletion
This window displays the results of deletion for each template and the details of the failure if
a failure occurs.
--End--
189
14.3.11
Listing and printing a call trace session report
The 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 the
existing 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:
190
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 sessions
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 with the following information:
Trace session name
Date of creation of the trace session report
Trace session parameters

The following figure is an example of a trace session report to be printed:
191
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--
192
14.3.12
Listing and printing a trace session template report
The 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 window
displays 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:
193
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 the
templates 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
194
Trace session template parameters

The 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--
195
15
Appendix: DTD 32.401.02

This 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 data
structure for an XML file.
For performance management, the counter observation files use the convention defined with the
3GPP DTD 32.401.02. For more details about the DTD 32.401.02, see the 3GPP specification
Telecommunication management; Performance Management (PM); Concept and requirements (TS
32.401).
DTD 32.401.02 description

The following XML DTD describes the observation files format.
196
Figure 62 DTD 32.401.02 for observations
The following table summarizes the XML tags and their associated full names and descriptions.
197
XML
tag
mdc
Full name
measDataCollection
Description
This top-level tag identifies the file as a collection of
measurement data.
The file content includes a header (measFileHeader), a
collection of measurement result items (measData) and
a measurement file footer (measFileFooter)
mfh
measFileHeader
This parameter is the measurement result file header to

be inserted in each file. It includes the version indicator,
name, type and vendor name of the sending network
node, and the timestamp collectionBeginTime.
md
measData
This construct represents the sequence of zero or more

measurement result items contained in the file. It can be
empty when no measurement data is provided. Individual measData elements can be displayed in any order.
Each measData element contains the name of the NE
nEId and the list of measurement results pertaining to
that NE measInfo.
mft
measFileFooter
This parameter is to be inserted in each file. It includes

the timestamp, which refers to the end of the overall
measurement collection interval that is covered by the
collected measurement results being stored in this file.
ffv
fileFormatVersion
This parameter identifies the file format version applied

by the sender.
The format version defined in this publication is 1.
sn
senderName
This parameter uniquely identifies the NE or EM that assembled this measurement file, according to the definitions in 3GPP TS 32.106. It is identical to the
nEDistinguishedName
of the sender. This DN uses the (userLabel) value to
identify an NE.
st
senderType
This is a user-configurable identifier of the type of network node that generated the file, for example, RNC,
Node B.
vn
vendorName
This parameter identifies the vendor of the equipment

that provided the measurement file. Always set to Alcatel-Lucent.
cbt
collectionBeginTime
This timestamp refers to the start of the first measurement collection interval (granularity period) which is
covered by the collected measurement results that are
stored in this file.
198
XML
tag
neid
Full name
nEId
Description
This unique identification of the NE in the system
includes the user name (nEUserName) and the distinguished 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 the

NE. It is unique across a 3G network operator. NE distinguished name is built using the network ID and RNC
ID values.
mi
measInfo
The sequence of measurements, values and related information.

It includes the list of measurement types (measTypes)
and the corresponding results (measValues), together
with the timestamp (measTimeStamp) and granularity
period.
(granularityPeriod) pertaining to these measurements.
All object instances found in a mi tag please refer to the
same object class.
nesw
nESoftwareVersion
This parameter is optional and defines the software version for NE in 3GPP TS 32.632. This parameter allows
post-processing systems to take care of vendor-specific
measurements modified between versions. For the RNC
measurements (including IN and AN files), this is the
RNC system release. For the Node-B measurements, it
is the system release. This tag is optional and is not
presented 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 expressed

in
(measValues)
seconds.
mt
measTypes
This parameter is the list of measurement types to which

the following similar list of measurement values) pertains.
mv
measValues
This parameter contains the list of measurement results

for 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 reliable (suspectFlag).
199
XML
tag
Full name
Description
moid
measObjInstId
This parameter field identifies the measured object class

and its instance, for example trunk1 means that object
class is trunk and instance #1 is being measured.
mr
measResults
This parameter contains the sequence of result values

for the observed measurement types. The measResults
sequence will have the same number of elements,
which follow the same order as the measTypes sequence.
Normal values are INTEGERs and REALs. The NULL
value is reserved to indicate that the measurement item
is not applicable or can not be retrieved for the object instance.
sf
suspectFlag
This flag indicates the quality of the scanned data

(FALSE in the case of reliable data, TRUE if not reliable). The default value is FALSE. If the suspect flag
has a default value it can be omitted.
ts
timeStamp
This parameter is a GeneralizedTime format. The minimum 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 the
release of the XML DTD. The following lines display the DTD versioning:
Figure 63 DTD versioning
200

W-CDMA
Alcatel-Lucent - Internal - Proprietary - Use pursuant to Company instruction
Copyright 2002-2009 Alcatel-Lucent, All Rights Reserved

UNCONTROLLED COPY: The master of this document is stored on an electronic database and is "write protected"; it may be altered
only by authorized persons. While copies may be printed, it is not recommended. Viewing of the master electronically ensures access
to 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 as
expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information contained herein confidential, shall disclose the
information only to its employees with a need to know, and shall protect the information from disclosure and dissemination to third
parties. Except as expressly authorized in writing by Alcatel-Lucent, the holder is granted no rights to use the information contained
herein. 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, Alcatel
and Lucent Technologies.
The Alcatel-Lucent 9370 Radio Network Controller and the Alcatel-Lucent Point Of Concentration are based on Nortel Multiservice
Switch products.
All other trademarks are the property of their owners.
Document number:
Document issue:
Document status:
Product Release:
Date:
NN-20500-033
09.11/EN
Standard
OAM06.0
June 2009

ALU CTN CTG Recording

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ALU CTN CTG Recording

Uploaded by

Copyright:

Available Formats

NN-20500-033

Wireless Service Provider Solutions

Wireless Service Provider Solutions

Alcatel-Lucent - Internal - Proprietary - Use pursuant to Company instruction

Copyright 2002-2009 Alcatel-Lucent, All Rights Reserved

Copyright 2002-2009 Alcatel-Lucent

Issue 09.03/EN Draft

SYSTEM RELEASE: OAM05.2

SYSTEM RELEASE: UMTS 5.1

NN-20500-033 09.11/EN Standard June 2009

Copyright 2002-2009 Alcatel-Lucent

The Publication History information for the outdated releases

Copyright 2002-2009 Alcatel-Lucent

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

NN-20500-033 09.11/EN Standard June 2009

Copyright 2002-2009 Alcatel-Lucent

7.2 Trace data collection and mediation......................................................................................................................... 68

Copyright 2002-2009 Alcatel-Lucent

14.3.10 Deleting a trace session template................................................................................................................ 185

NN-20500-033 09.11/EN Standard June 2009

Copyright 2002-2009 Alcatel-Lucent

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

Copyright 2002-2009 Alcatel-Lucent

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

NN-20500-033 09.11/EN Standard June 2009

Copyright 2002-2009 Alcatel-Lucent

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

Copyright 2002-2009 Alcatel-Lucent

About this publication

UMTS W-NMS for Access Network - Overview (NN-20500-031)

UMTS Access Network Performance Reference Observation Counters (NN-20500-028)

Alcatel-Lucent 9353 Management System documentation

Alcatel-Lucent 9300 W-CDMA Product Family documentation

NN-20500-033 09.11/EN Standard June 2009

Copyright 2002-2009 Alcatel-Lucent

Counters Reference Guide for Node B

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

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

Alcatel-Lucent 9353 Management System documentation

How this publication is organized

Performance Management fundamentals:

Performance Management procedures:

Copyright 2002-2009 Alcatel-Lucent

Retrieving counter files further to a Node B IP address change

Appendix: DTD 32.401.02

Bulk Data Format

Document Type Definition

eXternal Data Representation standard

eXtensible Markup Language

Network Performance Optimizer

Wireless Quality Analyzer

Radio Frequency Analyzer

The specific terms used in this publication include the following:

Managed Ob- Component.

Timestamp provided by the OMU card of the RNC

Timestamp provided by the TMU cards of the RNC

The unique identifier of a mobile call

NN-20500-033 09.11/EN Standard June 2009

Copyright 2002-2009 Alcatel-Lucent

Copyright 2002-2009 Alcatel-Lucent

UMTS Access Network Collection Roadmap

NN-20500-033 09.11/EN Standard June 2009

Copyright 2002-2009 Alcatel-Lucent