06 mn1783eu11mn 0001 performance

Performance measurements management Siemens

MN1783EU11MN_0001 © 2003 Siemens AG

1

Contents 1 Background 3 1.1 Introduction 4 1.2 Performance Measurement Categories and Parameters 5 1.3 Common Parameters for Scanner Objects 6 2 Performance Measurement Management 9 2.1 Creation of PLMN Scanners 10 2.2 Setting, Locking/Unlocking, and Deleting Scanners 12 2.3 Automatic Adaptation of PLMN Scanners 16 2.4 Retrieving Scanner Results 18 2.5 Current Performance Measurement Data 22 2.6 Handling of Measurement Groups 24 2.7 Symbolic Names for Scanners 28 2.8 File Conversion to ASCII & XML Format 31 3 SCA Handling 35 3.1 Creation of an SCA Object 36 3.2 Uploading the SCA Results 38 3.3 Elaboration of SCA Data 40 4 RFLOOP Handling 43 4.1 Creation of an RFLOOP Object 46 4.2 Uploading the RFLOOP Results 48 4.3 Conversion of the RFLOOP Data 50 5 History on Dropped Calls 53 5.1 Basics 54 5.2 Implementation 54 5.3 Handling on Radio Commander 57 6 Exercise 65 7 Solution 69

Performance measurements management

Siemens Performance measurements management

MN1783EU11MN_0001© 2003 Siemens AG

2



3

1 Background

Fig. 1



4

1.1 Introduction Performance measurements or scanners are an essential tool to survey a PLMN and gather information about its quality. The performance measurement results enable the operator to identify failures and problem zones within the network, which are not detected by the fault management. Information is collected about many aspects of the network, so that after a detailed analysis of the measurement results an optimization and fine-tuning of the network parameters is possible. For example performance measurements give hints about the load in radio cells, about bottlenecks in the system, about handover performance etc.



5

1.2 Performance Measurement Categories and Parameters

The performance measurements can be grouped into the categories shown below. For each of these categories, one ore more measurements exist.

GERAN Network measurement category

Meaning

SCANBSC Measurements related to the BSC

SCANSS7L Measurements related to CCSS7 signaling

SCANBTSM Measurements related to a BTS Site Manager

SCANBTSE Measurements related to a BTSE

SCANBTS Measurements related to a cell

SCANTRX Measurements related to transceivers

SCANCTRX Correlated TRX measurements

SCANCHAN Measurements related to the air interface

SCANBTSIHO Measurements related to incoming handovers

SCANBTSOHOI Measurements related to outgoing handovers intra-BSC

SCANBTSOHON Measurements related to outgoing handovers inter-BSC

SCANBTSOHOS Measurements related to outgoing handovers inter-system, e.g. to UMTS (FDD) or TD-SCDMA (TDD)

SCANFBTSM Measurements related to flexible Abis interface

SCANGPRS Measurements related to GPRS service

RFLOOP Measurements for supervision of RF link

SCA Measurements related to Smart Carrier Allocation

TIP The scanner objects with the ending TD refer to TD-SCDMA network element, which are not described in this document!



6

1.3 Common Parameters for Scanner Objects Performance measurements of one category are defined with a set of parameters. The parameters from one category may differ to the one from another category. The most important common parameters are shown below.

Attribute Meaning Granularity The granularity defines the duration of a measurement

and the time interval between subsequent measurement reports. Possible values are 5, 15, 30 and 60 minutes.

Measurement list In a measurement category several separate measurements are contained, which can be chosen here.

Object list A measurement works on an object, e.g. cells. The object(s) can be defined here.

Recording interval With this attribute the measurement can be scheduled to run daily, weekly or all the time. If it is scheduled, up to 7 measurement periods can be entered.

Start and stop date Dates for begin and end of a measurement campaign can be defined.



7

Fig. 2



8



9

2 Performance Measurement Management



10

2.1 Creation of PLMN Scanners Performance measurements are created from the BSS Summary panel with the command create <SCAN_OBJ>. Upon entering this command, the parameters required have to be filled. When a scanner is created, the RC performs scanner checks on the specified attribute values. If the user has entered an inadmissible value, he is informed immediately. Some examples of the implemented checks are:

• value range checks

• consistency checks (e.g. correct combination of measurement types and observed objects)

• restriction checks (e.g. specification of measurement types which are not allowed to report by event).

Fig. 3



11

Fig. 4



12

2.2 Setting, Locking/Unlocking, and Deleting Scanners

Scanner objects can be set, locked or unlocked as well as deleted. Therefore the scanner summary has to be opened, the scanner objects have to be selected and the corresponding action must be chosen:

Fig. 5



13

Fig. 6

Fig. 7



14

If objects have to be added to the objects list, or if measurements should be added to the measurement list, this can be performed by the add command:

Fig. 8



15

Fig. 9

Fig. 10



16

2.3 Automatic Adaptation of PLMN Scanners As networks continuously change (addition and reconfiguration of sites, addition of TRX, etc.), the scanners that are observing the performance of these PLMN objects must be adapted too. Otherwise, if the manual procedure is not executed, the following situations happens:

• in case of object creation, the new object is not included in the measurements;

• in case of object deletion, the counters related to the deleted object (even if equal to 0) are always reported with “suspect flag” set to TRUE.

To set the properties of a scanner, e.g. the objects, that are observed, the scanner has to be locked before the set command, and unlocked after the command. This will lead to a short outage time of the scanner and unreliable measurement results in that time interval. Therefore another possibility is offered by the system: In case that all existing objects of one category are objects of a scanner, the setting self adapting in the objects list will enable the scanner to react to configuration changes in order to always include all existing objects without any further user intervention.



17

Fig. 11



18

2.4 Retrieving Scanner Results Performance measurement data in binary format (as they are gathered by file on the BSC) are uploaded and parked by RC on OMP disk. The raw measurement data are kept, under an appropriate directory, for a specific time period. The binary file is transferred from the BSC to the RC through a compressed format (it is however possible also that the binary file is in uncompressed format). To make the identification of the cells easier, during the data post-processing phase (e.g., by METRICA, SPOTS), a section, containing the current BSC, BTS, BTSM and TGTBTS Symbolic Names, is inserted by the RC in each raw measurement file. The measurement data binary format is a BSC-RC internal format and it can be modified in each BSS release, depending on the number and type of the measurements, the buffer size, the number and length of the measurement counters and so on. The trigger to upload a measurement data file from the BSC can be:

• Manual upload,

• Periodic upload,

• Automatic upload. Just before its uploading, the SCAN.TMP file (i.e. the file used for temporary storage), that is in a BSC directory named MEASURE_DIR, is renamed and saved as SCAN_xx.LOG in the BSC READY_MEAS directory, where xx is the progressive creation number of the .LOG file. Then data storing continues in a new SCAN.TMP file. To save upload time, the file SCAN_xx.LOG ready to be transferred from BSC to OMP is compressed to a file SCAN_xx.ZIP in the BSC DBFH_ZIP directory (the LOG file is deleted after successful compression). The presence of files in the directory DBFH_ZIP is notified to the RC.every 15 minutes until the deletion of the files. The compressed file can now be uploaded from BSC to OMP. When the compressed file is successfully uploaded, the compressed file is deleted from the BSC hard disk. The PM-data files are uploaded and the temporary files reside in the directory $DATADIR_ON_OMP/ OMP/PMG/binaryPmg/ and are named as <SwVersion>_<BssId>.<StartingDateTime>. <EndingDateTime>. LOG. A header containing a list of the symbolic names of the BSC, BTS and TGTBTS is added to the file. Its structure remains unchanged. The PM data are no longer inserted in the Radio Commander’s relational database as in previous releases, relieving its CPU to a large extent without reducing the operator’s comfort. The interface to the O&M Toolset has changed due to this redesign.



19

2.4.1 Manual uploading of performance measurement results The manual upload is triggered with the command UploadMeasFile, which is found at the measurements summary icon in the BSS summary panel.

Fig. 12



20

2.4.2 Periodic uploading of performance measurement results The periodic upload can be performed by setting the values MeasurementDataFileUploadStart and MeasurementDataFileUploadPeriod in the BSC basic settings

2.4.3 Automatic uploading of performance measurement results

An upload can also be triggered if the file size reaches a predefined threshold (value maxScannerLogFileSize) which can be set in the BSC basic settings.



21

Fig. 13

Fig. 14



22

2.5 Current Performance Measurement Data To get current performance measurement data for scanners belonging to BSC use one of the following commands:

• getCurrentMeasValues for SCANBSC

• getMonObjCurrentMeasValues for SCANBTS - SCANBTSOHOI - SCANBTSOHON - SCANBTSOHOS - SCANFBTSM - SCANGPRS - SCANSS7L - SCANTRX

• getIHOCurrentMeasurementValues for SCANBTSIHO

Behavior of these commands

• Only one command can be started on one monitored object at a time with a delay defined by the BSC.

• The reported scan report buffer is the same as used for the performance measurement binary files.

• The measurement information is reported in one or more events. Each of these will contain an identifier that refers to the command that triggered the event reporting.

• The RC translates the scanner information into a plain text format. The parsing algorithm is the same as used for performance measurement binary files.

• BSC can reply, if needed, to avoid performance degradation on both sides as well as RC-BSC channel overloading.



23

Fig. 15

Fig. 16



24

2.6 Handling of Measurement Groups The RC allows the user to create self-defined measurement groups containing one or more measurement types of the same Scanner Object. For the following twelve Scanner Objects it is possible to create measurement groups:

• SCANBSC

• SCANBTS

• SCANBTSE

• SCANBTSIHO

• SCANBTSM

• SCANBTSOHOI

• SCANBTSOHON

• SCANBTSOHOS

• SCANFBTSM

• SCANSS7L

• SCANGPRS

• SCANTRX. Creation of a Measurement Group: 1. Open the RC Sum panel. 2. Right-click the RC icon and select Configuration Management > create > Create

MEAS_GRP_<OBJ>. The Create MEAS_GRP_<OBJ> dialog opens. 3. Enter the values for the following parameters.

• Naming Attribute: Specifies the instance number that identifies the measurement group (0..9 for every scanner object).

• <OBJ>Measures: Specifies a set of measurements of the same scanner object. At least one measurement must be selected.

• measGroupName: Specifies the name of the group (from 1 to a maximum of 25 characters). Do not use the following characters: blanks (' '), slashes ('/'), asterisks ('*') and question marks ('?').

4. Click OK to save your settings.



25

Fig. 17

Fig. 18



26

After a measurement group creation, when the user creates a new scanner related to this type of measurement, it is possible to specify the group name instead of selecting each measurement one by one. This possibility is given selecting the measList parameter in the measureListattribute from the Create ScannerObject window. The measurement group defined is then saved on the OMP. The groups are available on a per OMP basis, i.e. another user on another OMT may use this group independently of the BSS in which the measurement job runs. Furthermore, a delete, set and get command are provided for measurement groups.



27

Fig. 19

Fig. 20



28

2.7 Symbolic Names for Scanners To increase the comfort of the RC user interface, scanners can be addressed by symbolic names instead of using their fully distinguished name (FDN). This requires that the usage of symbolic names is enabled generally for the BSS. The symbolic names will be used instead of the complete path information in commands, logs and exported data. In the scanner summary, after selecting a scanner, a command is available to set the symbolic name of this scanner.



29

Fig. 21

Fig. 22



30



31

2.8 File Conversion to ASCII & XML Format While the translation of the binary files into the ASCII format is still supported for BR 8.0, it is strongly recommended that operators migrate their PM-data handling to the XML-files as supported interface to PM-tools. The standard compliant XML-format (in contrast to the ASN.1 format) has been chosen due to the following reasons:

• XML is better readable than ASN.1.

• Using an XSL (extensible stylesheet language)- or CSS (cascading style sheet)-stylesheet the XML-format can be displayed very convenient in an operator definable way using a standard Internet browser.

• XML data can be transformed to other data-formats using XSL-stylesheets. An exemplary file size comparison is given below:

Filesizes in kByte

BSC RC XML Schema ASN.1

original (uncompressed)

799 820 103% 2907 364% 3134 393%

original (compressed)

48 48 100% 75 156% 77 160%

Note: The “schema based XML format” has been preferred to the “DTD based XML format” in close harmony with other Siemens O&M systems.



32

The configuration of the conversion of binary PM-data files to files in XML-format is done in a panel that can be opened from the icon “Meas File Admin”. Operators can choose the following options:

• For which BSC shall the file conversion be done?

• Which identifiers for the managed objects are used in the xml-files: symbolic names, CGID or distinguished names?

• Shall a reference to a stylesheet (CSS or XSL) be added to all XML-Files, defining an XML-processing statement that is added into the header of the XML-file (<?xml-stylesheet type="text/xsl" href="./MeasDataCollection.xsl" ?>).

Which filename shall be used for the exported file (using relative or absolute filenames)? Each binary file stored in directory “$DATADIR_ON_OMP/OMP/PMG/binaryPmg/“ is translated into one file in XML-format. The XML-Files are stored in the directory “$DATADIR_ON_OMP/OMP/PMG/xmlPmg/“ using the 3GPP standard compliant filename “<Type><Startdate>.<Starttime>-<Enddate>.<Endtime>_<BSSId>”. The XML measurement files are kept for a user definable time (default 10 days, 1-15 days configurable during SW installation, specified by the environment variable MEAS_PERM_TIME_XML). After this time the files are automatically deleted from the disk without giving any additional information to the user. An analogous solution is already implemented for binary files.



33

Fig. 23 Set Meas XML Conv mode command

Fig. 24 Set Meas Conv Mode parameters



34



35

3 SCA Handling



36

The SCA feature consists of providing histograms of measurements on frequency basis and elaborating them to determine in a ranked list of frequencies the best one to substitute an under-test frequency for a microcell, or to change an existing frequency much disturbed by surrounding frequencies, or to put in service a carrier that has been foreseen as hardware but it has not had frequency planning done. The Smart Carrier Allocation feature comprises three different kinds of measurements, that allow the user to really know the interference situation of the network:

• Normal Measurements, which are split in two different kinds of measurements: by default: Normal Measurements; on demand: Busy Cumulative Measurements;

• Extended Idle Channels Measurements (only on uplink). Each type of measurement must be treated separately from the others. Moreover, they can be elaborated by the RC after their upload from BSC.

3.1 Creation of an SCA Object When creating a SCA object a window is displayed to the user in which there are three subwindows: the Basics subwindow contains general information about the SCA object, the Extended Idle Channel Measurements subwindow contains the information about SCA Extended Measurements, and the Normal Measurements subwindow contains information about both the SCA Normal Measurement kinds. In each of these sub windows the user must specify some parameters. Configuration is done at the RC by appropriate set-up of SCA parameters. The following parameters have to be defined:

• Selection of cells under observation.

• Definition of the list of frequencies to put under observation.

• Definition of accumulation times up to four in a day between 6 o’clock a.m. up to 12 o’clock p.m.

• Selection of type of measurements Normal measurements on downlink data (NM_DL), Busy Cumulative Measurement data (BCM) Extended Idle Channel measurements data (E-ICM)

• Eventually change the ”adjacent relationships”



37

SCA is set on a per cell basis and can be disabled by default after a system startup. SCA can be activated for up to 2000 cells per Radio Commander. It is possible to put up to 250 cells per BSC under observation. For an already created SCA object the commands get, set, lock, unlock and delete are available.

Fig. 25



38

3.2 Uploading the SCA Results When the feature is activated the measurements begin to be stored. Three different places are used to store data:

• into the BTSs: rough data

• into BSC: rough data, frequencies lists (and BSICs only for Normal Measurement)

• into the RC: rough data, outputs of elaborations, i.e. statistics, the best frequency or the best ones, the interference matrix .

SCA binary files are automatically uploaded between 3:00 a.m. - 6:00 a.m. from the BSC to the RC. They can also be uploaded on user request. The uploaded file is saved in the directory $DATADIR_ON_OMP/SBS_i/PMG, where the $DATADIR_ON_OMP is an environmental variable set on OMP. The Radio Commander then decompresses the file. Once the SCA file is completely decompressed, the compressed file is deleted. Simultaneously, under the directory $DATADIR_ON_OMP/OMP/SCA, a directory for each day is created and named with the date it refers to. In this directory many directories naming with the BSS identifier number are created. The path is then the following: $DATADIR_ON_OMP/OMP/SCA/date/xx where:

date: directory named with the upload date xx (hex): BSS identifier number

The decompressed uploaded file is transferred in the right directory of the OMP disk in its original binary format and named as SCAyyzz_CGI.LOG, where:

yy (hex): BTSM identifier number zz (hex): BTS identifier number CGI: Cell Global Identifier

The retention period of the SCA binary files is 30 days. After this time, the directories and all the included files are automatically removed from the OMP disk without giving any additional information to the user.



39

Fig. 26

Fig. 27



40

3.3 Elaboration of SCA Data The elaboration activity consists in the generation of:

• statistics,

• ranked frequencies lists,

• interference matrixes. The user can indicate which data have to be used in the procedures giving input type, time range of data collection and thresholds used to filter input data. The first step of the elaboration is to create cumulative histograms, starting from histograms collected from more than a day of observation for each cell. For each type of input a cumulative histogram is created. In case of monthly observation, rough data are kept for at least 1 week. Before erasing them, partial cumulative data is created. At the end of the whole observation period, the final cumulative data are available. If the list of frequencies inside a cell has been changed, the cumulative histogram is the enlarged one with all the frequencies. If the observation period is limited at just one day, no cumulative histograms are required and the original data are elaborated. The allowed elaborations on SCA measurements are the following:

• average

• bad adjacent cells

• best frequency

• coverage probability

• interference matrix

• Nth percentile

• outage rate

• quality link



41

Fig. 28

Fig. 29



42



43

4 RFLOOP Handling



44

The RF Loopback feature provides a complete test and diagnosis at TRX/carrier level in order to detect both not working TRX and minor service degradations (e.g. reduced RF power). This is achieved by utilizing standard measurements: Whilst a call is in progress the BTSE gathers a series of call related standard measurements that are used for handover decisions and power control. For the RFLOOP measurements four of these measurements are of interest:

• power generated by the BTS transmitter on the channel’s downlink.

• power generated by the MS transmitter on the channel’s uplink

• received signal strength detected by the BTS receiver on the channel’s uplink

• signal strength detected by the MS receiver on the channel’s downlink, which is documented in a periodically sent measurement report

Using these measurements the path loss on the downlink as well as the path loss on the uplink can be calculated. A difference between the two indicates a problem. A first evaluation of the measurement results is performed in the BTSE. They are then sent from the BTSE to the RC through BSC. If the average difference exceeds an operator defined threshold, an alarm is sent for the carrier concerned. The alarm message indicates that the RF-TX/RX signal path of the concerned carrier shows a service degradation. The alarm message contains the TRX, the related combiner equipment and the averaged path loss difference. This information allows a further fault localization



45

BTSE

TxPwr (BTS)

TxPwr (MS)

RxLev (BTS)

RxLev (MS)

Fig. 30



46

4.1 Creation of an RFLOOP Object When creating the RF Loop object, a window is displayed in which the user must specify the following parameters:

Parameter Meaning alarmThreshold This attribute specifies the alarm threshold expressed in db

unit.

autoReport This flag enables/disables the automatic file upload.

bandWidthOfHysteresis This attribute specifies the bandwidth of hysteresis expressed in db unit.

measCount This attribute specifies the minimum required measurement samples count.

minCallCount This attribute specifies the minimum number of calls.

rxLevel This attribute specifies the minimum RXLEV value to take a connection into account.



47

Fig. 31



48

4.2 Uploading the RFLOOP Results In the current implementation of the Online RF Loopback feature, both the automatic upload and the manual upload are supported. The command for the manual upload is uploadRFLFile. One file for every cell put under observation by the user is automatically uploaded every 24 hours or manually uploaded on user command at any moment. As happens for scanners and SCA files, the uploaded compressed files are saved in an RC directory named: $DATADIR_ON_OMP/SBS_i/PMG where the SBS_i is the subdirectory for the i-th SBS and $DATADIR_ON_OMP is an environment variable set on OMP. The Radio Commander then activates the task that provides file decompression. Once the RFLOOP file is completely decompressed, the compressed file is deleted from the $DATADIR_ON_OMP/SBS_i/PMG directory. Simultaneously, the decompressed uploaded file is transferred under the directory $DATADIR_ON_OMP/OMP/PMG/binaryRfl in its original binary format and named as BSS<nn>-Rel-<RFxxyy>.LOG, where:

nn: BSS identifier number Rel: BR release xx: BTSM identifier (0..199) yy: BTS identifier (0..23)

Only the last uploaded file for every cell is maintained. The retention period of an RF Loopback .LOG file is chosen during the installation phase and its value has the range 1-15 days (default value: 10 days). After this time the file is automatically deleted from the disk without giving any additional information to the user. To manually upload RFL measurement data files stored in the BSC: 1. Open the BTS Sum panel. 2. Right-click the RF Loop icon and select Performance Management >

uploadRFLFile . If the file is successfully uploaded from the BSC to the RC it is stored in the default path:

$DATADIR ON OMP/OMP/RFL/binaryRFL/SBS/<data> 3. Open a text editor to browse the file.



49

Fig. 32



50

4.3 Conversion of the RFLOOP Data The parsing and conversion of the binary RF Loopback files into ASCII format must be initiated manually via the user convertRFLFile command. After this command has been launched a window is displayed in which the user must specify the name of the .LOG file to be converted in ASCII format. If the user then clicks the OK button, the file is saved under the directory $DATADIR_ON_OMP/OMP/PMG/asciiRfl and named as BSS<nn>-Rel-<RFxxyy>.ASCII, where:

nn: BSS number Rel: BR release xx: BTSM identifier (0..199) yy: BTS identifier (0..23)

RC generates one RF Loopback ASCII file, which is the total conversion of related binary file uploaded from BSC on RC. The retention period of an RF Loopback .ASCII file is chosen during the installation phase and its value has the range 1-15 days (default value: 10 days). After this time the file is automatically deleted from the disk without giving any additional information to the user. To convert and save an RFL measurement data file: 1. Open the RC Sum panel. 2. Right-click the Meas File Admin icon and select Performance Management >

convertRFL. The convertRFL MEASFILE_ADMIN dialog opens. 3. Enter the value for the following parameter:

fileName: Name of the binary file to convert. Enter the name directly or open the File Browser dialog and select the file from the Files field. save: Specifies whether the file is automatically saved (True) or not (False).

4. Click OK. The Text Editor opens displaying the ASCII file. 5. You may browse the file and search for keywords.

TIP By default, save is set to False (step 3). This means that the converted ASCII file will be deleted when closing the Text Editor window. However, if you want to save the data, select save as from the File menu.



51

Fig. 33

Fig. 34



52



53

5 History on Dropped Calls



54

5.1 Basics A main aspect of network optimization is to reduce the number of call drops in the network. In order to do this, it is very important and necessary to provide the system operator more detailed data for each dropped call. This feature is required for the operator to do operator specific dropped call statistics, for example the number of dropped calls per timing advance, the number of dropped calls per TRX, the number of dropped calls per channel type and so on. This makes it possible to easily find out the reasons and locations of the dropped calls. It is very important for Radio Network Optimisation and Self-Optimizing Network SON.

5.2 Implementation The drops are observed for TCH and SDCCH channels, so the term “call” is used here for calls on TCH channels as well as for SMS, Location update procedures on SDCCH. The history data on a dropped call means the following data are recorded and stored by the BTSE:

• the receive levels in the uplink and downlink,

• the receive quality in the uplink and downlink,

• the timing advance,

• the power values of uplink and downlink power control (of MS and BTS),

• the receive level of neighboring cells before the call drop.

• flags indicating the occurrence of HO-COMMAND, ASSIGNMENT COMMAND, HO-failure, ASSIGNMENT failure

• the last monitored HO CONDITION INDICATION cause

• the last monitored HO- or ASSIGNMENT COMMAND message Note: For neighboring cells the six strongest BCCH frequencies of the BA/3G BA list (BCCH Allocation) are reported (only if enhanced MEASUREMENT REPORT is used more than six neighbors are possible). In order to do this, the following functionality is supported:

• The operator at the RC activates/stops/modifies the measurement ‘history data on the dropped calls’.

• The BTS collects and records the history data for all calls, but only the data for dropped calls are sent to BSC.



55

• After having received a history data message related to a dropped call, the BSC generates a history data record and stores it in the History Data logfile, which can be uploaded to the RC.

• The OMC tool set (OTS) provides the evaluation and statistic functionality related to the history data on the dropped call.

Time

470 or480 ms units

Call dropValid Measurement Reports

Skipped event data records: 3

Up to 16 valid event data records

Fig. 35 Principle of event data record collection in the BSS



56

Data collected by this feature

• The BSC stores the history data uploaded from the BTSE in a so-called HDCTR logfile. One BSC HDCTR logfile contains all trace data recorded per BSC.

• Each dropped call contained in this file is characterized by

• Cell ID

• TRX ID

• BSIC

• Neighbor cell IDs

• Cause of the call drop: Error indication: T200 expired N200+1 times Error indication: sequence error Connection failure: Distance Limit Exceeded Connection failure: Handover access failure Connection failure: Radio link failure Connection failure: Remote transcoder failure Expiry of T10 for intracell handover failures Expiry of T8 for internal intercell handover failures etc.

• History Information: Timeslot number Channel mode (speech or data) Channel type (SDCCH, TCH/F, TCH/H) Mobile ID (e.g.IMEISV) Event records (RXLEV, RXQUAL, MS and BS power, TA, DTX flag, etc.) Number of skipped event data records

• Commands and signaling: Assignment commands Handover commands (with preceding HO CONDITION INDICATION) Power control commands

• etc.



57

5.3 Handling on Radio Commander

5.3.1 Activation of the History Data of Dropped Calls Feature

HDCTR object The HDCTR object can be created from the BSS icon in the BSS Summary panel:

Fig. 36 Create HDCTR command



58

The parameters have the following meaning:

Parameter Meaning Measurement Sets the number of valid event data records (measurements,

etc.) stored before a call dropped

Periodicity list of trace periods, one for every day of the week with start and end time (analogous to CTRSCHED)

Start and Stop date the dates when the collection of history data starts and stops

BTS object In the BTS object only one parameter is important:

Parameter Meaning Enable HDCTR (range: false, true) This attribute is used to enable

HDCTR data provisioning for a BTS. If this flag is set (true), the BSC will ask the BTS for history data in case of a call drop event within this BTS.



59

Fig. 37 Creation of the History of dropped calls object

Fig. 38 Enabling History on Dropped Call Trace



60

5.3.2 Transfer of BSS Logfiles to the RC The transferring of the BSS History Data logfiles to the RC is the same as for other CTR logfiles. An upload of the History Data logfile is initiated by a BSC Trace logfile upload notification. The upload takes place in one of the following cases:

• After a configurable period (0 = not automatically, 1 hour, 2 hours,…, 24 hours) the BSC sends an HDCTR upload request notification to the RC with the list of HDCTR trace logfile ready to be uploaded. As no starting time parameter for the automatic upload is foreseen, the upload will be performed every X (configured) hours at the full minute.

• If the maximum logfile size at BSC is reached.

• At any time when the operator issues a corresponding upload command (all files). For the LMT only the manual upload is available and in this case the logfiles on the BSC are not deleted.

BSC object Also in the BSC object some parameters are of relevance for the handling of the history data files:

Parameter Meaning File size (range: 1 to 12 MByte) history on dropped calls file size

Upload Period (0, 1, 2, 3, 4, 6, 8, 12, 24 hours) The attribute defines the period between two automatic uploads of HDCTR logfiles, where ‘0’ means ‘no automatic (periodic) upload’.



61

Fig. 39 Parameters to configure the upload of History data file for dropped calls



62

5.3.3 History data administration and conversion at the RC The History Data logfile uploaded from BSC are handled in the same way as other CTR logfiles. At the RC, the uploaded files are moved to a predefined directory. During this phase a header file containing the symbolic names of the objects of the BSS (BSC, BTSM, BTS, TGTBTS), and the Cell Global Identifiers of the BTSs and TGTBTSs, are attached to the uploaded file, and then stored in the binaryHistory directory. A History Data file conversion can be performed on operator request and the operator can ask for the conversion to ASCII format or to XML format. In that conversion process there is an automatic replacement of the Network Element Id of the objects (BTS, TGTBTS) with the related symbolic names, if available.

5.3.4 Export of history data The history data logfiles in binary or converted (ASCII/XML) file format can be exported to a post-processing tool (third party tool, O&M toolset). Therefore, a post-processing tool can load the history data logfiles from RC via FTP.



63

Fig. 40 Export options for history data files



64



65

6 Exercise



66



67

Exercise Title: Handling of scanners

Objectives: Handling of scanners

Task

Create a scanner that reports the processor load of the BSC with the minimum reporting interval.

Create another scanner that reports the processor load of a single BTSE periodically every 30 minutes.

Change the scanner to include a second BTSE.

Change it to always include all existing BTSE.

Manually upload the results and convert them to xml-format.

Trigger an automatic upload every day at a predefined time.



68



69

7 Solution



70



71

Solution Title: Handling of scanners

Objectives: Handling of scanners

Task

Create a scanner that reports the processor load of the BSC with the minimum reporting interval.

Fig. 41



72

Create another scanner that reports the processor load of a single BTSE periodically every 30 minutes.

Fig. 42



73

Change the scanner to include a second BTSE.

Fig. 43



74

Change it to always include all existing BTSE.

Fig. 44



75

Manually upload the results and convert them to xml-format.

Fig. 45



76

Fig. 46



77

Trigger an automatic upload every day at a predefined time.

Fig. 47



78

06 mn1783eu11mn 0001 performance

Documents

scanbsc measurements

scanbtsm measurements

bsc scanss7l measurements

cell scantrx measurements

btse scanbts measurements

handover performance

siemens ag

sca results