Table of Contents

Ultima Mentor
Required Data Inputs for ALU
Infrastructure

i
Confidentiality, Copyright Notice & Disclaimer
Due to a policy of continuous product development and refinement, TEOCO Ltd. (and its affiliates,
together “TEOCO”) reserves the right to alter the specifications, representation, descriptions and all
other matters outlined in this publication without prior notice. No part of this document, taken as a whole
or separately, shall be deemed to be part of any contract for a product or commitment of any kind.
Furthermore, this document is provided “As Is” and without any warranty.
This document is the property of TEOCO, which owns the sole and full rights including copyright.
TEOCO retains the sole property rights to all information contained in this document, and without the
written consent of TEOCO given by contract or otherwise in writing, the document must not be copied,
reprinted or reproduced in any manner or form, nor transmitted in any form or by any means: electronic,
mechanical, magnetic or otherwise, either wholly or in part.
The information herein is designated highly confidential and is subject to all restrictions in any law
regarding such matters and the relevant confidentiality and non-disclosure clauses or agreements
issued with TEOCO prior to or after the disclosure. All the information in this document is to be
safeguarded and all steps must be taken to prevent it from being disclosed to any person or entity other
than the direct entity that received it directly from TEOCO.
®
TEOCO and Netrac are trademarks of TEOCO.
All other company, brand or product names are trademarks or service marks of their respective holders.
This is a legal notice and may not be removed or altered in any way.
COPYRIGHT © 2015 TEOCO LTD.
ALL RIGHTS RESERVED.

Your feedback is important to us: The TEOCO Documentation team takes many measures in order
to ensure that our work is of the highest quality.
If you found errors or feel that information is missing, please send your Documentation-related
feedback to Documentation@teoco.com
Thank you,
The TEOCO Documentation team
 Table of Contents

Table of Contents
1 Introduction ................................................................................................. 4
2 Required Information and Data ......................................................................... 5
2.1 Network configuration Data ................................................................................... 5
2.1.1 ALU UMTS Network topology (XML format) ...................................................... 5
2.1.2 Antenna and sectors physical location, profiles and parameters in Delimited Format ..... 5
2.2 Performance Counter collection .............................................................................. 7
2.2.1 Counter activation..................................................................................... 7
2.2.2 Counter collection ..................................................................................... 9
2.2.3 Counter Mediation .................................................................................... 9
2.2.4 Performance counter XML file collection ........................................................ 10
2.2.5 Performance counter XML file compression .................................................... 10
2.3 Trace collection ............................................................................................... 11
2.3.1 Trace activation ..................................................................................... 11
2.3.2 Trace data collection ............................................................................... 18
Appendix A: TBD ........................................................................................... 21

iii
1 Introduction
This document contains a list of the information and data to be collected for ALU UMTS infrastructures in
order to perform an optimization cycle using Ultima Mentor.

The following information and data are required:

 Network configuration
 UMTS Logs and counter data

When preparing to set up Mentor in a network, we usually recommend starting by creating the
network configuration, followed by a sample data collection.

The following sections of this document provide a more in-depth description of the required
data sources, and the manner in which they can be obtained.
 Required Information and Data

2 Required Information and Data

2.1 Network configuration Data

The sources for network configuration data are:
o A predefined set of Network Topology files exported from the ALU OSS in XML
format.

o Textual files, including complete information required for physical sites and soft
parameter configuration, depending on availability (“Schema Format”).

IMPORTANT – Mentor includes an automatic wizard that generates most of the textual files
required for its operation, based on the data commonly available in the service provider
environment.

2.1.1 ALU UMTS Network topology (XML format)

There are several options to generate the ALU XML configuration files. Many variants exist,
which will generate different content within the XML files.

The Mentor product makes use of an elaborated configuration file, which contains all of the RNC
and NodeB parameters. Using this type of file enables Mentor to identify and warn about
configuration problems.

The network topology dump could be generated by the TML tool by a full configuration export or it
might already be activated and generated daily basic on the OSS that could be retrieved by ftp
download.

2.1.2 Antenna and sectors physical location, profile s and

parameters in Delimited Format

The physical parameters of the network, such as the sector and antenna location, and the antenna
profiles, might not be available through the OSS configuration dump.

Most of the required physical configuration of the network can be derived from network planning

tools or from customer-self-maintained databases with the most updated network configuration.

Mentor defines a set of textual files that should be available. These files are:

• Antenna file - includes the physical configuration of each sector. See section for the file format.

v
• Antenna profiles – antenna-pattern data files

In contrast to planning tools or other configuration sources, Mentor requires only active
sectorcarriers.

Sectors that are inactive during an analyzed period should be marked as “inactive” in the antenna
files.

All soft parameters may be defined in this file, but will be overridden by the Network Topology files.
We recommend that the latest Network Topology files be used to update the Schema format file
and to identify any inconsistencies, such as missing or unnecessary sectors.

2.1.2.1 Antenna file

The antenna file (in tab-delimited text format) includes the physical configuration of each sector,
including:
o Location data (i.e., coordinates, height, and so forth)
o Antenna characteristics (i.e., height, azimuth, and so forth)
o Physical constraints
o Network topology
The antenna file must include all sectors selected for optimization and all sectors in the
guard-zone area – where optimization is not performed. We recommend that all sectors
within two tiers of the selected sectors be included.

The Antenna file fields are described in table below

 Required Information and Data

Note: If UTM coordinates are used, the relevant column headers should be different:

NodeB X, NodeB Y, Antenna X, and Antenna Y.

2.1.2.2 Antenna profiles

Antenna-pattern data files are in Planet/XML format.

2.2 Performance Counter collection

2.2.1 Counter activation

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.

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

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

vii
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

• 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
 Required Information and Data

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

• opt/nortel/data/counterlists/import/
• opt/nortel/data/counterlists/export/
The exported counter list files are automatically purged by the WMS after 30 days. If 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.

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

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.

2.2.3 Counter Mediation

Mentor processes the ALU counter files in standard XML format which contain both objects and
performance counters. The following diagram shows the performance counter generated by ALU
UMTS system.

ix
File name convention for performance counter files is at below:

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

2.2.4 Performance counter XML file collection

The XML files are generated and stored at below directory for:

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 RNC statistical POC observation XML file is as follows:
opt/nortel/data/utran/observation/stats/<YYYYMMDD>/POC-<NE userlabel>

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>

2.2.5 Performance counter XML file compression

ALU UMTS system allows operator to activate the compression mode for the XML files to save the hard disk.
In this case it will use gzip for the compression method.
 Required Information and Data

2.3 Trace collection

2.3.1 Trace activation

2.3.1.1 Trace types

Mentor uses ALU UMTS trace for CTg, CTg and CTn for analysis and optimization. The traces files
output by the RNC is XDR. The XDR formatted call trace files are then XML formatted by WMS.

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.

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.

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

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.

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.

2.3.1.2 Launching calltrace wizard

You can reach the Call Trace Wizard application from the Performance menu of the NSP main
window (Performance/Radio Access/ Call Trace Configuration Wizard)
 Required Information and Data

The following figure shows how to access the Call Trace Configuration Wizard command.

The Call Trace Configuration Wizard option of the Radio Access command allows you to:

• Create, delete and print reports of trace sessions

• Create, delete and print reports of trace session templates

The following figures show the Call Trace Configuration Wizard window when the Call Trace Wizard

Next button

xiii
Next button

Enable the Geographical session option and click the Next button
 Required Information and Data

The "Call Trace Configuration Wizard" window appears with the following parts in the "Equipment
Selection" field:
• "Available Equipments" displays the list of available targets in a Tree View or in a Flat View. The view type is
selected by the combo box at the top.
• "Selected Equipments" displays the selected FDDCells.
• Command buttons are located in the middle:
- Select ->: used to add the target(s) in the selected target list. If you select a non terminal object (RNC or
NodeB) in the Tree View, all FDDCells attached to this object are also added.

- Select All ->: used to add all FDDCells

- Remove: used to remove the target(s) from the Equipment List

- Remove All: used to remove all FDDCells from the Equipment List

When you have selected the required equipment, click the Next button.

A window appears with the "RNC and NBAP parameters" fields. The following figure is an example of

equipment and parameters selection:

xv
The "RNC and NBAP parameters" list displays the list of selected RNCs and RNCs containing selected
objects (CNodes or FDDCells).You can update the NBAP parameters of the RNCs displayed in the list:

a. Select in the list the RNC that you want to update.

b. Modify the value of the "SIR Period", "TCP Period" and "RTT Period" fields. The value must meet the
following requirements:

• it must be between 500 and 10000,

• it must be a multiplier of 500 (or "modulo" 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.

c. Click the Update button.

d. Repeat steps a to c to update other RNCs.

 Required Information and Data

When you have done the required modifications, click the Next button.

A window appears with the "Mobile identification and session parameters" fields.

Enter the following information in the "Session Parameters" fields:

• Call Type List: Types of call that will be traced within the session. Any combination of call types
above can be chosen, without any restrictions

• Session Template: select a session template. By default, the template named

"StandardTroubleShooting" 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 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 first
activation.

• File Upload Size: enter the maximum size of the trace file. The maximum value is 1024.

• File Upload Period: enter the lapse of time before the trace file is closed and made available.

xvii
Click the Next button. The parameters selected are verified. An error message is returned if:

• The user label entered is already used.

• No template has been selected.

• The session note exceeds the maximal number of characters.

• The duration exceeds the maximum authorized value.

A window appears with a summary of the session parameters selected

 In OAM 5.1: Click the Create button to confirm the access session creation.

 From OAM 5.2: Click the Create button and Activate the session from the session
manager

Click the Finish button. If the Launch report window on close option is enabled, a new window
appears with the results.

Click the Close button to close the window.

2.3.2 Trace data collection

Trace data flows in ALU UMTS system is at below diagram

 Required Information and Data

The XML geographical trace files are generated on the main server in the following

directory:/opt/nortel/data/utran/callTrace/originatedFromGeographicalArea/<sessionId>/<YYYYMM
DD>/- rc>/calls/<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>/*

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.

xix
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

 Required Information and Data

Appendix A: TBD

xxi