Professional Documents
Culture Documents
Copyright Notice
Due to a policy of continuous product development and refinement, Schema reserves the right to alter the
specifications and descriptions outlined in this publication without giving prior notice of any kind. In addition,
no part of this publication, taken as a whole or separately, shall be deemed to be part of any contract for
equipment or services.
Schema retains the sole proprietary rights to all information contained in this document. No part of this
publication may be reproduced, stored in a retrieval system, transmitted in any form or by any means,
including but not limited to: electronic, mechanical, magnetic, photocopy, recording, or otherwise, in use now
or in the future, without prior written consent from Schema.
Table of Contents
1
Introduction .............................................................................................. 3
May 2010
Page 2 of 35
Introduction
This document contains a list of the information and data to be collected for Ericsson GSM
infrastructures in order to perform an optimization cycle using Ultima Forte.
The following information is required:
Performance reports
This document not only identifies the required sources of data, but also explains how to obtain
the data.
May 2010
Page 3 of 35
2.1
Optimization Area
List of cells in the optimization and surrounding areas (optimization set and guard zone)
Current frequency planning strategy (BB,1:1, 1:2, , per site, per cell, ad-hoc, )
Desired optimization strategy (BB, 1:1, 1:2, , per site, per cell, ad-hoc, )
2.2
2.2.1
Network Data
Ericsson BSS Network Configuration
Retrieve the required BSS network configuration file from the Ericsson OSS, using the Cellular
Network Administrator (CNA), by running the following commands:
Overall Network configuration:
cna_export NW = all, MSC = all, MSC_REF = none, BSC = all, BSC_REF = all, SITE = all,
SITE_REF = none, CELL = all, CELL_REF = all, OUTPUT=AllParameters_YYYYMMDD.txt
Foreign cells:
cna_export NW = all, FCELL = all, FCELL_REF = all, OUTPUT=foreign_HO_YYYYMMDD.txt
(where: YYYY year, MM month, DD day)
Notes:
Foreign cell data must be exported only when the BSS network configuration data for the
surrounding networks (including other Ericsson OSS, the network configurations of other
vendors, or UMTS networks) has been provided. Ultima Forte will not create neighbor
relations with other networks if this file is not provided.
Daily CNA adjustment jobs should be scheduled for each BSC to ensure that the network
configuration is updated in the OSS.
May 2010
Page 4 of 35
It is recommended that the BSS network configuration file be retrieved for each day of mobile
measurement recordings. However, it is mandatory that this file be retrieved if any
BCCH/BSIC changes were made between two days of recordings.
The BSS network configuration file should be generated just before initiating the BAR and
MRR recording sessions.
The BSS network configuration should be retrieved for each OSS that is relevant to the
optimization and surrounding areas in the network.
In the beginning and end of the data collection process, the following optional data should be
retrieved for all BSCs, and included in the Ultima Forte network environment:
Data
Description
RLCRP:CELL=ALL,DETAIL;
Cell Resources
Details
RXMOP:MOTY=RXOTG;
Managed Object
Data
RAEPP:ID=ALL;
BSC Exchange
Properties
RXMOP:MOTY=RXOTX;
*See note
Data retrieval should be performed via the BSC command line interface.
The output of the command printout should be stored in text files. The command name (RLCRP,
RXMOP, RAEPP) of each output type should be at the beginning of the file name, e.g.,
RLCRP_BSC1.txt.
*Note: The files that are generated using this command should be used when the network
configuration contains multi-band sectors with 1 synthesized ch.gr in each band and the
parameter NUMREQBPC is not maintained.
May 2010
Page 5 of 35
2.2.2
The sector coordinates file should be in tab-delimited text file format, and should include
geographical information for all of the network sectors, including the following columns:
Sector
Latitude
Longitude
Azimuth
LAC (optional)
CI (optional)
Keywords (optional)
The latitude and longitude values should be expressed in decimal-degree format, with up to six
digits following the decimal point.
BSC split
The following changes should be performed only during maintenance (not during recording):
TRX additions
Site additions
The Mobile Measurements files can be extracted, as explained below, from the Ericsson OSS and
used by Ultima Forte either in binary format (Section 2.3.1) or in text format (Section 2.3.2).
May 2010
Page 6 of 35
2.3.1
May 2010
Page 7 of 35
Notes:
In a dual band network, recordings should be made separately, based on the cell band.
However, in order to provide full functionality of handover optimization, inter-band
recordings should be performed. Each band cell set should record a frequency set with the
BCCH frequencies for both bands. Multi Band Cells Reported (MBCR), is a cell parameter
that defines the number of neighbors from each frequency band are reported in the
measurement report. The recommended setting is either 2 or 3 in a multi-band network in
order for mobiles to report measurements from the opposite band.
While BAR files can also be generated with the Frequency Allocation Support (FAS), the
Neighboring Cell Support (NCS) should be used if possible.
The NCCPERM defines the allowed NCCs on the BCCH carriers for which the MSs are
permitted to send measurement reports. Hence if all NCCs are used NCCPERM should be
set accordingly (i.e., all NCCs included in the NCC parameter) so that all NCCs are
reported. NCCPERM has no impact on idle mode behavior, since Idle mode cell reselection
is based on CGI, and not ARFCN/BSIC).
The Active BA list Recording result may sometimes contain measurement results with
unexpected, disallowed BSICs, (e.g., 00 or 77). This occurs when some MSs report
irrelevant BSICs initially, before decoding actual BSIC information and is not related to a
fault in the BA List recordings feature.
If an operator has not purchased the RNO application to activate BAR recordings through NCS,
the BAR recordings can be activated by using the BSC command line interface, as follows:
May 2010
Page 8 of 35
R8:
o
/var/opt/ehpt/eac/data/fs/BSC_NAME/
/root/var/opt/ericsson/nms_eam_eac/data/fs/BSC_NAME/
/root/var/opt/ericsson/brf/data/db/tmpfileStore/BSC_NAME/
Note:
When BARFILs are transferred from UNIX to Windows via FTP, the binary transfer method should
be used. All BARFILs recorded on the same day should be stored in the same directory.
The Appendix contains instructions on troubleshooting situations in which BAR files are not
created.
May 2010
Page 9 of 35
Log in to OSS.
Start RNO.
Go to FileNew RecordingMRR.
Name the recording session.
Enter a Start date.
Enter a repeat value (set to daily) and a number of repetitions (set to 5).
Enter a date type, working days only (Monday to Friday five consecutive working days).
Enter hour range (Three hours should be defined to include the network busy hour).
Select the cell set or BSC (including every cell in the entire network).
Set Cell Filter to a desired (available) frequency band (The recorded cell set is limited to a
specified frequency band.)
Save and schedule the recording.
If an operator has not purchased the RNO application to activate MRR recordings, the MRR
recordings can be activated by using the BSC command line interface, as follows:
May 2010
Page 10 of 35
RAMRI: RID=MRRID00, DTIME=120; Recording period time; the recording starts as soon as this
command is entered!
RAMRP: RID=MRRID00; Print status (optional).
RAMTI: RID=MRRID00; After the recording is finished, this command should be run to create the
output file.
When the recording is finished, store the MRRFILs files for each BSC on an FTP. If this is not done
within 48 hours after the recording, it will be deleted from the system.
Binary MRRFILs files are located in the following OSS directories:
R8:
o
/var/opt/ehpt/eac/data/fs/BSC_NAME/
/root/var/opt/ericsson/nms_eam_eac/data/fs/BSC_NAME/
/root/var/opt/ericsson/brf/data/db/tmpfileStore/BSC_NAME/
Notes:
When MRRFILs are transferred from UNIX to Windows via FTP, the binary transfer method
should be used.
All MRRFILs recorded on the same day should be stored in the same directory.
The Appendix contains instructions on troubleshooting situations in which MRR files are not
created.
May 2010
Page 11 of 35
R8:
o
/var/opt/ehpt/eac/data/fs/BSC_NAME/
/root/var/opt/ericsson/nms_eam_eac/data/fs/BSC_NAME/
/root/var/opt/ericsson/brf/data/db/tmpfileStore/BSC_NAME/
Note:
When RIRFILs are transferred from UNIX to Windows via FTP, the binary transfer method should
be used. All RIRFILs recorded on the same day should be stored in the same directory.
FAS RIR recordings can only be activated for BSC software R9.1, and later versions, and RBS
software 8.4. RIR recordings should not be initiated for previous versions since they may take
timeslots out of service.
May 2010
Page 12 of 35
2.3.2
2.3.3
Handover Statistics
Handover statistics for each cell-to-cell relation should be collected for handover optimization.
This data should be aggregated over one week for each cell-to-cell relation, and provided in a
tab-delimited text file with the following fields:
Serving Sector
Target Sector
Handover Attempts
May 2010
Page 13 of 35
2.3.4
Traffic File
The traffic file should be in tab-delimited text file format with traffic information for all sectors in
the optimization and simulation areas (the guard-zone area), and should include the following
columns:
Sector
Since the Traffic file should comply with Schemas format, these columns can be in any order.
The Traffic file should contain information for five consecutive working days in a three to fourhour period that includes the network peak hour, and should be generated on the last recording
day.
2.3.5
The GPRS/EDGE traffic file should be in tab-delimited text file format with information for all
sectors in the optimization and simulation areas (the guard-zone area), and should include the
following columns:
Sector
The required traffic file can be prepared with raw counter data from the Performance
Management system. The counters should be taken from the object CELLGPRSO in an hourly
resolution, and should be average around network peak hour.
GPRS Traffic =
May 2010
Page 14 of 35
TCH Traffic (Traffic per Cell, Traffic per OL/UL, Traffic HR/EFR and per OL/UL, Traffic AMR
FR/AMR HR and per OL/UL). These statistics should include the following counters:
TFTRALACC, THTRALACC, TFTRALSUB, THTRALSUB, TSCAN, TFNSCAN, THNSCAN,
TFNSCANSUB, THNSCANSUB, TTCONGS, TFTCONGS, THTCONGS, TFTCONSUB, THTCONSUB
TCH Performance (Drops, Drops per OL/UL, Drops Reason, Drops Reason per OL/UL, Normal
Disconnection, Bad Quality). These statistics should include the following counters:
TFNDROP, THNDROP, TFNDROPSUB, THNDROPSUB, TFDISTA, THDISTA, TFDISTASUB,
THDISTASUB, TFDISSUL, TFDISSSDL, TFDISSSBL, TFDISSSULSUB, TFDISSSDLSUB,
TFDISSSBLSUB, THDISSSUL, THDISSSDL, THDISSSBL, THDISSSULSUB, THDISSSDLSUB,
THDISSSBLSUB, TFDISQAUL, TFDISQADL, TFDISQABL, TFDISQAULSUB, TFDISQADLSUB,
TFDISQABLSUB, THDISQAUL, THDISQADL, THDISQABL, THDISQAULSUB, THDISQADLSUB,
THDISQABLSUB, TFSUDLOS, THSUDLOS, TFSUDLOSSUB, THSUDLOSSUB
The following performance statistics should be collected and calculated daily for each cell relation,
for seven consecutive days:
May 2010
Page 15 of 35
2.4.1
100%
For the handover success rate the improvement will be calculated as:
100%
Each KPI improvement ratio can be calculated separately over a period of five working days
(during each days network busy hour) before and after the optimization cycle.
Any network performance KPIs that are not related to the BSS subsystem should be excluded
from the calculation.
2.4.2
(CNDROP)
(CMSESTAB + CMSESTABSUB)
+ TFNCASSALLSUB + THNCASSALLSUB
RxQual _ DL
RxQual _ DL
x =5
7
x =0
RxQual _ UL
RxQual _ UL
x =5
7
x =0
May 2010
Page 16 of 35
(HOVERSUC)
(HOVERCNT)
Note:
Bad_Quality statistics are retrieved directly from MRR data.
2.4.3
SDCCH _ Congestion =
(CCONGS)
(CCALLS)
TFCASSALL + THCASSALL +
TCH _ Congestion =
SDCCH _ Traffic =
TCH _ Traffic =
(CMSESTAB + CMSESTABSUB)
(CCALLS + CCALLSSUB)
(TASSALL)
TFNRELCONGSUB + THNRELCONGSUB
(TASSALL)
(CTRALACC + CTRALSUB)
3600
(TFTRALACC + THTRALACC)
360
(TFTRALACC)
TCH _ Traffic _ HR =
(THTRALACC )
HO _ BQ _ UL =
TCH _ Traffic _ FR =
HO _ BQ _ DL =
+ TFNCASSALLSUB + THNCASSALLSUB
360
360
(HODWNQA)
(HOVERCNT)
(HOUPLQA)
(HOVERCNT)
May 2010
Page 17 of 35
Comments
Check
Network Data
BSS Network
Configuration
Sector Coordinates File
Traffic File
Mobile Measurements Recordings
Day 1
Day 2
Day 3
Day 4
Day 5
BAR Files
MRR Files
RIR Files
BSS Network
Configuration
Network Performance Statistics
SDCCH Assignments
SDCCH Traffic
SDCCH Performance
SDCCH drop
SDCCH drop reason
TCH Assignments
TCH Traffic
TCH Performance
Drops
Drops per reason
Handover (HO)
Performance per Cell
Relation
HO
HO
HO
HO
Intra-Cell Handover
Performance
attempts
success
reversion
drop
HO reasons
HO attempts
HO success
May 2010
Page 18 of 35
When the import is executed, the planned area is ready to view in the CNA. The user can then
schedule an update, at a desired date and time, to implement the planned area into the real
network.
Note: When running a new Neighbor List import using CNAI in the Ericsson OSS, the option
-b is needed in order to allow deletion of neighbors. Without this option, the can_import
command will only add neighbors.
May 2010
Page 19 of 35
May 2010
Page 20 of 35
May 2010
Page 21 of 35
2. Transfer Fortes export file (by FTP) to the following OSS directory:
/var/opt/ericsson/cnai/data/import, and then verify that it exists.
May 2010
Page 22 of 35
4. Open the planned area. (File -> Open -> Planned Area ->All)
May 2010
Page 23 of 35
5. Run Udate Job. (File -> New Job -> Update Job)
May 2010
Page 24 of 35
May 2010
Page 25 of 35
May 2010
Page 26 of 35
May 2010
Page 27 of 35
A dialog box is displayed enabling you to select the update file to import.
May 2010
Page 28 of 35
May 2010
Page 29 of 35
May 2010
Page 30 of 35
May 2010
Page 31 of 35
May 2010
Page 32 of 35
ls
ls l
ll
cd directory_name
cd ..
cd $HOME
cd ~
pwd
To create a directory:
mkdir directory_name
To delete a directory:
rmdir director:y_name
To remove a file
rm filename
chmod +x filename
May 2010
Page 33 of 35
5 Appendix: Troubleshooting
BARFIL and MRRFIL files are transferred from the BSC to the OSS, once the recording has
finished.
5.1 The
Connect to the OSS via an external application, such as Citrix ICA Client.
Check the file removing option in OSS, which automatically deletes MS files (perhaps to avoid
hard disk space problems). The possible values for this parameter are:
removeFile Value
Result
MS files will be
removed
Parameters in OSS are stored in Parameter Database (PDB) maps. The removeFile parameter
belongs to the BRF map.
To determine the value of OSSs parameters, use the cap_pdb_get_para command:
cap_pdb_get_para n brf removeFile
The Ericsson Alex Library has additional details.
Change the value of the file removing option from 1 to 0, using the cap_pdb_mu command
(with the correct user privileges). (If the file removing option is set to 1, files will be
deleted.) If the BRF map is edited with an editor such as VI, it may lock the database, and
the cap_pdb_mu command may not work with BRF. A user with Super User access (and
perhaps additional knowledge) may be able to remedy this situation.
May 2010
Page 34 of 35
Description
<dbPath>
<bsc>
The BSC.
The removeFile parameter in the BRF map can be set up to delete files automatically, as
explained in the previous section.
Map Name
BRF
Brf
FAS
Fas
FOX
Fox
NCS
Ncs
NOX
Nox
TET
Tet
MRR
Mrr
May 2010
Page 35 of 35