RPMO Introduction

Slide 1Slide title In CAPITALS 50 pt Slide subtitle 32 pt
RPMO introduction
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
*
an OSS feature
Fetch the data, process and export real-time information about the network or cell behaviour.
Advantage
The R-PMO collects all the cell related measurements data at regular intervals for defined duration and pass this information to OSS for presentation.
The R-PMO provides the radio network optimizer with presentation of quality and traffic related monitors in real time.
The R-PMO can be used for fast reaction to suspected problems and thus help in troubleshooting.
The R-PMO offered several types of reports.
*
OSS
R-PMO
TCP/IP
X.25
BSC
*
R-PMO Feature installed in OSS.
Activation of RTED (Real Time Event Data) Feature in BSC to enable recordings.
BSC with STOC (Signaling Terminal for Open Communication) Feature. This functionality enable communication from BSC to RPMO. This would additionally required a physical cable from BSC to OSS.
An IP address to communicate OSS and BSC.
To Support RTED, One Dedicated RPG3 (AXE 810) or RPG2E (BYB501) is required
RTED in not supported in Mixed (BYB202-BYB501) combination
*
Step 1
Go to OSS Network Explorer on Common Desk Environment of OSS
Step 2
Step 4
Select R-PMO
This window will appear
*
Circuit Switched Reports
TCH Traffic Report
GPRS/EGPRS TBF Release Report
GPRS/EGPRS Multislot Utilization Report
*
---TCH drops Report
*
---Main window
The Main window in R-PMO shows the activated system defined Report
*
N/A means data “Not Available”
The user can select between 1 minute up to 60 minutes(1,15,30 or 60Minutes
Data is only shown for one hour and only saved for one hour
*
The user sees an overview of the cells or cell sets included in a table report, and for each cell the current values of the monitors are visible. Each monitor can also be displayed in a graph, showing how the values have changed during the last 60 minutes.
Note: It is possible to pause the update in the GUI. The collection in the BSC is still ongoing but update of the GUI is stopped as long as the user wants.
It is also possible to close the table window but the collection in the BSC will be ongoing as long as the report is active.
*
---Graph window
The graph window views one graph for each monitor (window) and the selected cells appears in every graph with the same color.
The graph can be paused.
The user can Drag and Drop cells and monitors into the graph.
The graph has the same resolution as the table window had when the graph was opened.
*
Set handler in R-PMO
Cell sets are created using the Set Handler available from the R-PMO main window.
Cells can then be added to and removed from cell sets by using the Set Handler.
*
A cell set contains a number of selected cells that can belong either to the same BSC or to different BSCs.
Cell sets are created using the Set Handler available from the R-PMO main window. The cell set and the R-PMO reports that are connected to the set will then be visible in the main window.
Cells can then be added to and removed from cell sets by using the Set Handler. When the cell set is modified, any active R-PMO reports on that set is also updated to reflect the new content of the set. RNO is using the same cell sets. This means that cell sets created in R-PMO can be used in RNO and vice versa.
When a cell set is deleted all reports that belong to the set will automatically be deactivated
*
Report Customization in R-PMO
Create User Defined Report
click on “Report” icon from the menu bar and select subtitle “New user report definition”.
Combining the Reports in One Report
*
To analyze the KPI of cell, user can select any parameter from the existing report and can create own or customized report for better understanding.
The way, to create user-defined report is to click on “Report” icon from the menu bar and select subtitle “New user report definition”. After selecting this give a name to that report as any name and select the parameter on which analysis needs to be done.
*
---REDE (Raw Event Data Export)
This function is used for storing any events and measurements that are provided by the R-PMO , in a file. The format of the file can be tab separated or XML
The format of the file can be tab separated or XML
*
This function is used for storing any events and measurements that are provided by the R-PMO , in a file. The format of the file can be tab separated or XML. The function can be used to collect both raw events from the network as well as KPI values.
The Raw Event Data Export is initiated from a GUI started from the R-PMO main window. The collection of data starts when the user initiates the collection from the GUI and stops when the user stops the collection or at a user-specified point of time. The result can then be post processed by the user outside the R-PMO application.
Post processing tool for R-PMO out put is ”Tems Visualization”(PC-based software product)
Note: In addition to this the out put of R-PMO, which is now the input for Tems Visualization stores, the data in .mdb format (MS-Access Data base) as well.
Once the data gets stored in access database, user can create his own query by using SQL/PL-SQL for his own analysis
*
---R-PMO Event Log
This is simple XML file, generated by R-PMO after collecting the events and measurements for the a particular cell set for analysis very similar to Layer-3 Message analysis
*
Improved event monitoring capacity
Dual Transfer Mode
Extended Dynamic Allocation
*
Below are some dimensioning or application issues related to R-PMO.
There is no provision of scheduling of reports for user-defined time; it gives the results only as and when R-PMO starts.
The R-PMO Configured, BSC processor load, on an average can be increased by 5-7%.
The load on the OSS server is going to be higher side.
The number of users on the application server in the OSS should be restricted, as the application server loading will increase by apprx.10%.
*
Conclusion and reference
R-PMO is very useful tool to analyze nearly online performance of the network. This is also very useful to see affects of any changes made in the network in very short time.
The following document for your reference and help you analyze the network performance.
3.pdf
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
Approved Checked Date Rev Reference
E
Disclaimer
No part of this document may be reproduced in any form without the written permission of the copyright owner.
The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.
Trademarks
Ericsson is a trademark owned by Telefonaktiebolaget LM Ericsson. All other product or service names mentioned in this Function Specification are trademarks of their respective companies.
Contents Page
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Revision Information .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Technical Description .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Radio Network Performance Analysis, Circuit Switched Traffic . . . . . . . . . . . . . . 8 3.3 Radio Network Performance Analysis, Packet Switched Traffic . . . . . . . . . . . . . . 16 3.4 Inter System Handover .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5 TRX ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.6 New filters in R12 .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.7 Operator and User-defined Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.8 Raw Event Data Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.9 R-PMO Database Export Interface .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.10 Event Based Statistics Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.11 Improved monitor presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.12 Related Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Engineering Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.1 Application Guidelines .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A4 XSEIF R3
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
4.2 Prerequisites and System Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.3 System Administration Information .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.4 Load and Limitation Issues .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 Parameters .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.1 Main Controlling Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.2 Parameters for Special Adjustments .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.3 Value Ranges and Defaults Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6 <Appendix> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8 Glossary .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
9 References .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
1 Introduction
1.1 General
R-PMO (Real-time Performance Monitoring) provides detailed, flexible data in real-time. This data can be presented and exported in several different ways, allowing the user to use R-PMO for different purposes such as
• real-time monitoring
• detailed troubleshooting
• storing of event based statistics
OSS receives certain BSC event notifications, as they occur, via a TCP/IP connection, and handles and presents the information. OSS subscribes to the specific BSC event notifications that are required for the user selected reports, monitors, and event exports.
Three types of reports are offered: Ericsson Standard Reports, Operator-defined Reports, and User-defined Reports. The data in these reports can be viewed in real-time and/or stored in a relational database.
REDE (Raw Event Data Export) allows short-term logging of event notifications or monitor data in a file for the purpose of detailed troubleshooting. Thanks to the very detailed data, advanced correlations (that otherwise cannot be done) are possible.
RPDBI (R-PMO Database Export Interface) enables short term storing and handling of monitors as counters based on cell sets. With this feature, it is possible for the user to create customized counters and store them in a relational database. They can then be combined with STS counters in Business Objects reports.
EBS (Event Based Statistic Database) enables long term storing of large amounts of event data based on one, several or all BSCs in the network. The user can define the number of monitors that are included as event statistics. An authorized user can activate and de-activate storage of event statistics. The user can select how data shall be aggregated when it comes to time period. The event statistics can be combined with STS counters in Business Objects reports.
A more detailed description of R-PMO can be found in R-PMO Monitor Description,Reference [7]
1.2 Revision Information
This UD is based on the R11 document 225/1553-HSC 103 12 Uen Rev A3. The changes between the above document and this document are as follows:
Ericssonwide Internal USER GUIDE 4 ( 51 )
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
• TRX data in monitors
• Multi select of filters when more than two filters are available
• More cause values for dropped calls
• A number of new reports:
− EIT Report
− TBF Release, cause (#)
− Times Admission control denied an EIT user access (#)
− Requested Transfer Delay (ms)
− Achieved Transfer Delay (ms)
− Inter System Successful Resource Allocation Outgoing HO (%)
− Inter System Outgoing HO Attempts (#)
− Inter System Successful Resource Allocation Incoming HO (%)
− Inter System Incoming HO Attempts (#)
− Inter System Multi RAT MS (#)
− Inter System HO Attempts (#)
− Inter System HO Success (%)
− Inter System HO Reversion (%)
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
− Max number of ISHO Triggered (#)
− Inter System HO Lost (%)
− IP Buffer Discards, PFC (#)
− IP Buffer Discards, TBF (#)
− TRX Handover Attempts (#)
− TRX Handover Success (#)
− TRX TCH Drops (#)
− Low priority mode
− MS MSlot Class
− MS 3GPP Capability
− IMEISV, Traffic case
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
− DTM
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
2 Capabilities
R-PMO (Real-time Performance Monitoring) is a BSS feature used to collect, process, present, and export real-time information about the BSS performance. The BSC feature RTED (Real Time Event Data) is needed for the BSC part of the functionality. The OSS application has the same name as the BSS feature; R-PMO.
R-PMO is dimensioned to be run for all events (CS and PS) derived from traffic of up to 100 000 Erlang per OSS (generated by up to 150 BSCs). The OSS is dimensioned in different ways depending on how much event load that is expected. Each BSC can be dimensioned to support all event types from all cells (see chapter 4.2), and load regulation secures that pay-load traffic always has higher priority than events.
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
3.1 General
The feature RTED in the BSC is used for reporting of event notifications to the OSS application R-PMO in real-time. The event data is sent from the BSC to OSS using TCP/IP via an RPP device. The communication between BSC and OSS uses the infrastructure provided by the BSC feature ’IP Connectivity’ described in Reference [1].
The data is presented in several ways in the R-PMO application.
• Real time presentation of statistics by retrieving measurements from tables that are updated and calculated once a minute.
• The REDE function can store event- and monitor data in a file. The file can be analyzed by means of post processing tools.
• The RPDBI function can store R-PMO monitors, and create reports at the user’s request. The monitors are stored in a database in a format similar to the existing statistical counters.
• The EBS function can store statistics from one, several or all BSCs, and create statistical reports at the users request. Only authorized users can initiate storage of data to the event based statistics database.
The performance data that can be evaluated in real-time includes traffic load, service quality, hand over statistics, GPRS/EGPRS cell reselection performance, GPRS/EGPRS data throughput and more. The statistical measures are called Monitors. The displayed values are based on measurements made during a specified time period; the Mean Time Value Resolution period. It is possible to select 1, 5, 15, 30 or 60 minutes.
The monitors are combined into reports. Several pre-defined Ericsson Standard Reports for both circuit switched and packet switched traffic performance monitoring are available. The user can also assemble monitors into own reports. Those reports have characteristics and functionality corresponding to the Ericsson Standard Reports.
A wide range of filters can be used on monitors, depending on the nature of the monitor. As an example the performance information for circuit switched traffic can be filtered per MS manufacturer and type.
3.2 Radio Network Performance Analysis, Circuit Switched Traffic
3.2.1 General
This chapter deals with monitors available for monitoring of circuit switched traffic in R-PMO. A number of predefined reports - Ericsson Standard Reports - are supplied for Circuit Switched traffic. These are:
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
• SDCCH Handover report
• Multi Band Cell report
Monitors are generally available for the user to be included in user-defined reports, but they are also, generally, part of an Ericsson Standard report. The following sections describe the monitors and indicate in which Ericsson Standard report they are included.
Monitoring the circuit switched radio network performance with R-PMO is described in the areas of: General traffic information; Accessibility; Retainability; and Service integrity.
3.2.2 General Circuit Switched Traffic Information
The main purpose with this area is to check the traffic on cell level, or average for a group of cells in a cell set. By monitoring the TCH and SDCCH traffic level, decisions can be taken regarding capacity increase such as installation of more TRUs or the need for more SDCCHs. The TCH or SDCCH traffic level can also, at extremely low values, indicate a problem.
The monitor for traffic level is called:
TCH Traffic (Erlang)
Shows the TCH traffic level.
(Included in TCH Traffic report, Quality report, Multi Band Cell report and Inter System Resource Allocation report)
Further guidance on where more TRUs are needed can be fetched from the TCH Utilization monitor in chapter 3.2.3.
By comparing the installed channel resources with the actually used, (using the TCH Utilization monitor), the efficiency of the resource planning can be checked. Early indications are given regarding where more TRUes are needed due to for instance short-term traffic volume peaks.
An early indication of future or existing congestion problems can be monitored with:
Busy TCHs Peak (#)
Shows the highest number of simultaneously used TCHs during the resolution time period.
(Included in TCH Traffic report)
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
SDCCH Traffic (Erlang)
Shows the SDCCH traffic level
(Included in SDCCH Traffic report)
Further guidance on where more SDCCHs are needed can be fetched from the SDCCH Utilization monitor in chapter 3.2.3
3.2.3 Accessibility, Circuit Switched Traffic
The accessibility is defined as the ability to set up a call. The monitors are defined per cell. The availability can be studied by looking at the monitor for total number of TCHs together with the monitor for TCH utilization:
Attempted Calls (#)
Number of attempted calls filtered on a specific TRX
TCHs (#) The average number of time slots that have been available for TCH connections.
This value is typically rather stable since it shows the current circuit switched capacity of the cell. It will vary if time slots are blocked for various reasons, or if time slots are used as dedicated PDCHs.
TCH Utilization (%)
Shows the percentage of busy TCH channels out of total number of available TCH channels.
If the utilization for a cell is low the accessibility for that cell has a good chance to be high. The number of available TCHs together with TCH utilization will show if the cell is dimensioned correctly.
Subscriber perceived congestion is also a good indicator of the accessibility of the network:
TCH Congestion (%)
Shows the percentage of subscriber perceived congestion. This is the fraction of call setup attempts that fails due to lack of resources (for instance TCHs and Transcoders) out of the overall amount of call setup attempts.
TCH time Congestion (%)
Shows the percentage of time during which no TCHs were available but requested.
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
SDCCH Utilization (%)
Shows the percentage of busy SDCCHs out of the total number of available SDCCHs.
3.2.4 Retainability, Circuit Switched Traffic
The retainability area within the radio network covers the ability to keep a call. The monitors are defined per cell.
3.2.4.1 Dropped call monitors
Dropped calls are monitored with the following Monitors:
Bad Q (%) Shows the percentage of drops due to bad quality.
(Included in TCH Drop report)
Excessive TA (%)
FER (%) Shows the percentage of drops due to FER.
Low SS (%) Shows the percentage of drops due to Low SS.
Other, BSC Initiated (%)
Shows the percentage of drops due to other BSC initiated cause.
MSC Initiated (%)
Shows the percentage of drops due to MSC initiated cause.
SDCCH drop (%)
Shows the percentage of dropped SDCCH connections out of total number of released SDCCH connections (handovers not included).
(Included in Quality report)
TCH Drops (#)
Shows the total number of dropped TCH connections (’dropped calls’). A dropped connection is a connection (occupying one or more TCHs) which is released for other reasons than successful handover or normal call release.
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
(Included in TCH Drop report, Quality report, and Multi Band Cell report)
TCH Drop (%)
Shows the percentage of dropped TCH connections (see monitor TCH Drop (#)) out of the total number of released TCH connections.
(Included in TCH Drop report and Multi Band Cell report)
Note For other MSCs than Ericsson’s, the Clear Command causes may differ and these monitors may show strange values.
Note To get the correct drop reason, the exchange parameter CALLDROPMSC must be set. See chapter 5.2.1.
3.2.4.2 Handover performance monitors
These monitors are only valid for GSM since Inter System Hanover is calculated and presented separately, see chapter 3.4.
Handover attempts (#)
Handover success (%)
Shows the percentage of successful outgoing handover attempts out of total number of handover attempts. Both intra and inter BSC handovers are counted, but not intra cell.
(Included in TCH/SDCCH Handover report and Quality report)
Handover reversions (%)
Shows the percentage of outgoing handovers that failed, but the calls were not lost. Both intra and inter BSC handovers are counted, but not intra cell.
(Included in TCH/SDCCH Handover report)
Handover lost (%)
Shows the percentage of lost outgoing handover attempts out of total number of handover attempts. Both intra and inter BSC handovers are counted, but not intra cell.
Incoming Handover attempts (intra-BSC) (#)
Shows the total number of incoming handover attempts. Intra BSC handovers are counted, but neither Inter BSC nor intra cell.
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
Intra- and subcell Handover attempts (#)
Shows the total number of intra cell and subcell handover attempts.
(Included in TCH/SDCCH Handover report and Multi Band Cell report)
Intra- and subcell Handover success (%)
Shows the percentage of successful intra cell handover attempts out of total number of intra cell handover attempts.
(Included in TCH/SDCCH Handover report and Multi Band Cell report)
On cell relation level (Cell A - Cell B) the following handover monitors are available (Inter BSC neighbor relations are grouped together in the presentation):
Note intra cell handover does not contribute to calculations in the following four monitors.
Handover attempts (#)
Shows the total number of handover attempts for that specific neighbor relation.
Handover success (%)
Shows the percentage of successful outgoing handover attempts, for a specific neighbor relation, out of total number of handover attempts. Both intra and inter BSC handovers are counted.
Handover reversion (%)
Shows the percentage of outgoing handovers, for a specific neighbor relation, that failed, but were not lost. Both intra and inter BSC handovers are counted.
Handover lost (%)
Shows the percentage of lost outgoing handover attempts, for a specific neighbor relation, out of total number of handover attempts. Both intra and inter BSC handovers are counted.
SDCCH Handover performance is monitored with the following monitors (intra cell handover does not contribute to calculations):
SDCCH handover attempts (#)
Shows the total number of SDCCH handover attempts. Both intra and inter BSC handovers are counted.
(Included in SDCCH Handover report)
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
SDCCH Handover success (%)
Shows the percentage of successful outgoing SDCCH handover attempts out of total number of SDCCH handover attempts. Both intra and inter BSC handovers are counted.
SDCCH Handover reversion (%)
Shows the percentage of outgoing SDCCH handovers that failed, but were not lost. Both intra and inter BSC SDCCH handovers are counted.
SDCCH Handover lost (%)
Shows the percentage of lost outgoing SDCCH handover attempts out of total number of SDCCH handover attempts. Both intra and inter BSC handovers are counted.
3.2.4.3 Multi Band Cell monitors
A number of monitors are supplied to supervise the enhanced traffic distribution among the frequency bands in a Multi Band Cell:
Ping-pong Frequency Band Group Changes (#)
Number of Frequency band group changes within a cell that returns to the originating Frequency Band Group within a specified time period. The return to the originating Frequency Band Group must be done within the specified time period.
(Included in Multi Band Cell report)
Ping-pong Handovers (#)
Number of intra BSC handovers from the non-BCCH frequency band in cell A to any frequency band in cell B and back to cell A (any frequency band), within a time period. The return to the originating cell must be done within the specified time period.
Distribution of RXLEV difference DL (#)
The distribution of the difference between simultaneously reported RxLev on the active channel, DL (compensated for BTS output power, BTS power control, etc.) and the RxLev on the BCCH of the serving cell. The samples are collected only when the active channel is belonging to the non-BCCH frequency band group.
Frequency Band Offset Delta (dB)
The delta of the Frequency band offset filter. The frequency band offset controls when an intra cell Handover shall be performed between the frequency bands.
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
3.2.5 Service Integrity, Circuit Switched Traffic
The degree to which a service is provided without excessive impairments. The monitors are defined per cell.
The quality within the area can be evaluated with:
RXLEV To filter on RxQual upper and lower limit and/or TA upper and lower limit.
TA To filter on RxLev upper and lower limit and/or RxQual upper and lower limit.
RXQUAL over given threshold (%)
The monitor allows the user to supervise speech traffic performance per codec type and per direction (UL/DL). It can also be filtered on channel group granularity, TA upper and lower limit, and RxLev upper and lower limit. Shows the percentage of RxQual measurements with a value greater than given threshold in GSM.
The monitor is also available in the following instances:
• RXQUAL UL over 5 GSM (%), included in the Quality Report.
• RXQUAL DL over 5 GSM (%), included in the Quality Report.
RXQUAL (GSM)
Shows the average of RxQual in measurement results within the measurement period. Different aspects of monitoring can be set by filters Direction, Codec type and Channel group.
RXQUAL DL after SCC (GSM)
When a subcell change from the underlaid to the overlaid subcell is made, the RxQual values in the measurement result (MR) events that occur within a specific time period for that specific mobile are saved.
(Included in the Multi Band Cell report)
RXQUAL DL after Handover (GSM)
When a handover is made from cell A to cell B with the overlaid subcell as serving in cell B, the RxQual values in the MR events that occur within a specific time period for that specific mobile are saved.
(Included in the Multi Band Cell report)
Speech Quality under given threshold UL (%)
Shows the percentage of SQI (Speech Quality Index) measurements with a value below given threshold in dBQ.
(included in the Quality Report)
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
Speech Quality under given threshold DL (%)
Shows the percentage of SQI DL values under a given threshold.
(included in the Quality report)
Number of SQI (#)
Average FER (GSM)
Distribution FER (%)
3.3.1 General
This chapter contains the GPRS/EGPRS related monitors available in R-PMO. The monitors are described in the chapters below. A number of predefined reports - Ericsson Standard Reports - are supplied for Packet Switched traffic. These are:
• GPRS overview report
• GPRS Multislot utilization report
• Dual Transfer Mode report
• Ericsson Instant Talk
GPRS/EGPRS Monitors are generally available for the user to be included in user-defined reports, but they are also, in many cases, part of an Ericsson Standard report. The following sections describe the monitors and indicate if they are included in one of these Ericsson Standard reports. There are also a number of monitors that are not part of any Ericsson Standard report, these are named Stand-alone, and can be found in the following categories:
• (E)GPRS TBF Characteristics Monitors
• (E)GPRS PDCH Characteristics Monitors
• (E)GPRS Data Throughput Monitors
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
• IP Latency Distribution Monitors
The monitors are defined per cell, unless else is stated.
3.3.2 Ericsson Instant Talk (EIT) Monitors
Note It is possible to de-activate the EIT-flag for all monitors below.
Request made to Admission Control (#)
Number of request made to admission control
(Included in Ericsson Instant Talk report)
Times Admission Control denied an EIT user access (#)
Number of denied requests made to admission control
Requested Transfer Delay (ms)
Average requested transfer delay for EIT connections during PFCA lifetime
Achieved Transfer Delay (ms)
Average achieved transfer delay for EIT connections during PFCA lifetime
BLER DL for GPRS EIT TBFs (%)
Average Block Error Rate (BLER) DL during TBF lifetime for the TBF that was in EIT mode sometime during the TBF
BLER DL for EGPRS EIT TBFs (%)
Average Block Error Rate (BLER) DL during TBF lifetime for the TBF that was in EIT mode sometime during the TBF
BLER UL for EGPRS EIT TBFs (%)
Average Block Error Rate (BLER) UL during TBF lifetime for the TBF that was in EIT mode sometime during the TBF
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
Total IP Data received by AQM (Kbyte)
Total IP data received by Active Queue Management in the GPRS/EGPRS network.
Total IP Data delivered by AQM (Kbyte)
Total IP data delivered by Active Queue Management to the MS.
Total IP Data, TBF (Kbyte)
Total LCC data transferred in the cell on TBF level. To be used as a validity monitor together with the TBF distribution monitors.
Total IP Data (PFC) (Kbyte)
Total LLC data transferred in the cell on PFC activity level, to be used as a validity monitor to check the significance of the LLC and radio link bit rate distribution monitors.
(Included in GPRS overview report)
3.3.4 IP Throughput monitors
Monitoring of GPRS/EGPRS data throughput, and the factors that affect it, will directly indicate the network performance as perceived by the users.
IP Throughput DL (PFC) (Kbps)
Weighted average downlink throughput for the LLC data per PFC Activity transferred in BSS.
(Included in GPRS overview report)
IP Throughput (DL, PFC, DTM connections) (Kbps)
As “IP Throughput DL” but measures only DTM connections.
(Included in Dual Transfer Mode report)
IP Throughput Distribution (TBF) (%)
Distribution of TBF throughput based on TBF data volume. Indicator for user perceived performance.
IP Throughput Distribution (PFC) (%)
Distribution of LLC throughput based on LLC data volume. Indicator for BSS performance.
3.3.5 IP Latency monitors
Note At normal traffic load there is no data in these monitors
The filter MS 3GPP Capability R97/R99 or R4 can be set .
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
IP Latency Samples (TBF) (#)
Number of IP Latency samples during the specified time interval. Different aspects of monitoring can be set by filters.
The IP Latency is the round trip time PCU - MS - PCU per TBF measured by the PCU. Note that MS processing time is included.
IP latency Distribution (TBF) (%)
Part of IP Latency samples during the specified time interval with an IP latency within the given IP latency interval compared to the total number of IP Latency samples. Different aspects of monitoring can be set by filters.
3.3.6 IP Transfer Interrupts monitors
TBF Releases, cause (#)
The number of normal TBF releases. The release cause due to TBF mode change.
Abnormal DL TBF releases per TBF minute (#)
The number of abnormally (due to radio reasons) released DL TBFs, per TBF minute, divided by the total duration for all DL TBFs in a cell.
(Included in GPRS Overview report)
Abnormal TBF Releases (#)
The number of abnormal TBF releases. The release cause due to Normal release, Flush and Suspend are not included. Direction (UL/DL) and MS EGPRS Capability can be set by filters.
(Included in GPRS TBF release report)
Abnormal TBF Releases, cause (#)
As the ‘Number of Abnormal TBF Releases’ monitor, but filterable also with cause value.
Abnormal TBF Releases, cause (%)
The number of abnormally released TBFs in relation to the total number of released TBFs. Filters same as Abnormal TBF Releases, cause (#)
The monitor is available in the following instances all included in the GPRS TBF release report:
• TBF release due to missing radio contact (%) with filter: No response from BTS after Immediate Assignment has been sent, timing advance channel faulty, no answer from the MS.
• TBF release due to lost radio contact (%) with filter: Too many consecutive unanswered polling requests.
• TBF release due to MS Fault (%) with filter: Releases due to MS fault.
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
3.3.7 IP Buffer Discards
IP Buffer Discards, PFC (#)
The forced IP delays for the user as the PCU IP buffers are discarded.
IP Buffer Discards, TBF (#)
The numbers of TBFs affected by discarded buffers (disturbance in the radio environment).
3.3.8 Radio Link Quality monitors
BLER (%) Block Error Rate during TBF lifetime
Radio Link Bit Rate (kbps)
Average bit rate on the radio link. Filtering on direction (UL/DL) and TBF mode can be made.
This monitor is also available in the following three instances; all included in the GPRS overview report:
• Radio Link bit rate DL Basic (kbps) for TBF mode BASIC.
• Radio Link bit rate DL GPRS (kbps) for TBF mode GPRS.
• Radio Link bit rate DL EGPRS (kbps) for TBF mode EGPRS.
IP Distribution Radio Link Bit Rate (%)
Distribution of radio link bit rate based on LLC data volume. Different aspects of monitoring can be set by filters.
RXQUAL DL (CS1–4) (% over threshold)
Shows the percentage of downlink TBFs in TBF mode GPRS that at the end of the TBF have exceeded a specified RxQual value.
RXQUAL DL at Cell Reselection ( CS1–4) (% over threshold)
Shows the percentage of downlink TBFs in TBF mode GPRS at cell reselection that have exceeded a specified RxQual value (measured in the source cell).
RXQUAL DL at Cell Reselection (CS1–4) (GSM)
Average value of Rxqual for TBFs in TBF mode GPRS at cell reselection (measured in the source cell).
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
BEP DL (MCS1–9) (% over threshold)
Shows the percentage of downlink TBFs in TBF mode EGPRS that have exceeded a specified Bit Error Probability value.
BEP DL at Cell Reselection ( MCS1–9) (% over threshold)
Shows the percentage of downlink TBFs in TBF mode EGPRS at cell reselection that have exceeded a specified Bit Error Probability value (measured in the source cell).
BEP at Cell Reselection (MCS1–9) (BEP)
Average value of Bit Error Probability for TBFs in TBF mode EGPRS at cell reselection (measured in the source cell).
3.3.9 Mobility monitors
The mobility- and IP transfer interrupt performance information will assist the operator in the work for optimizing and tuning the radio network (for instance cell planning). By having information about the cell reselection frequency, the outage time and between which cells the mobiles are moving, it is possible to identify the affected geographical areas (cell relations) and estimate the degree of service impact for the users.
By optimizing the cell plan in respect to cell reselection, the user service as well as efficient utilization of the radio network resources can be improved.
Outgoing Flush Messages (#)
Number of mobiles in SGSN ready state leaving the cell.
Incoming internal Flush Messages (#)
Number of mobiles in SGSN ready state incoming to the cell, coming from cells within the same RA with no change of serving PCU. This means that mobiles coming from cells outside the RA, or mobiles for which the serving PCU is changed, will not be counted.
(Included in GPRS Cell reselection performance report)
Incoming internal Cell Reselection (#)
The number of mobiles that during DL data transfer enter the cell from cells within the same RA and the same PCU. This means that mobiles coming from cells outside the RA or outside the PCU will not be counted.
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
Incoming internal CRS outage time (s)
The average outage time for the mobiles that during DL data transfer enter the cell from cells within the same RA with no change of serving PCU. The outage time is measured from the last packet DL ACK/NACK message until the Flush Message is received.
Outgoing Internal Flush Messages (#)
Number of mobiles in SGSN ready state leaving the cell, to cells within the same RA and the same PCU.
Outgoing internal CRS outage time (s)
The average outage time for the mobiles during DL data transfer leaving the cell, to cells within the same RA and the same PCU. The outage time is measured from the last packet DL ACK/NACK message until the Flush Message is received.
Outgoing internal Cell Reselection (#)
The number of mobiles that during DL data transfer leave the cell to cells within the same RA and the same PCU.
Outgoing External Flush Messages (#)
The number of Cell Reselections performed by mobiles leaving the cell to cells outside the RA or outside the PCU.
Outgoing External CRS (#)
The number of Cell Reselections performed by mobiles that during DL data transfer leave the cell to cells belonging to other RA or other PCU.
Flush Messages (#)
Number of flush messages from mobiles in SGSN ready state moving from the source cell to the target cell.
(This monitor is on cell relation level and is included in GPRS Cell reselection performance report)
Cell reselections no NACC (#)
The number of mobiles that during DL data transfer move from the source cell to the target cell without support from NACC.
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
CRS outage time no NACC (s)
The average outage time for the mobiles that during DL data transfer move from the source cell to the target cell without support from NACC. The outage time is measured from the last acknowledged poll request message to the Flush Message is received.
Cell reselections NACC (#)
The number of mobiles that during DL data transfer move from the source cell to the target cell with support from NACC.
CRS outage time NACC (s)
The average outage time for the mobiles that during DL data transfer move from the source cell to the target cell with support from NACC. The outage time is measured from the last acknowledged poll request message to the Flush Message is received.
3.3.10 GPRS Traffic Load monitors
Low Priority Time, TBF (s)
To show how much time TBFs are in a low scheduling mode due to low priority
TBFs (#) Number of TBFs per direction and per TBF mode. Different aspects of monitoring can be set by filters.
Average TBF time (s)
Average duration time in seconds for TBFs per direction and per TBF mode. Different aspects of monitoring can be set by filters.
DTM Connections (#)
Non CS used TS (#)
The number of channels available for packet traffic. This is calculated as the number of deblocked channels minus the number of busy TCH in average during the selected integration period. Different aspects of monitoring can be set by filters.
On-demand PDCHs (#)
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
On-demand PDCH allocations (#)
3.3.11 Multi-slot Utilization monitors
TS for MultiSlot capable MS (%)
MultiSlot utilization for MultiSlot capable mobiles. This means the average number of allocated timeslots in % of the number of timeslots asked for. The monitors can be filtered with respect to DTM connection: All, no DTM, DTM only
This monitor is available in seven instances; for 4 slot-, 3 slot- and 2 slot MSs and for UL and DL respectively, and for DL 5-slot MS in the GPRS Multislot Utilization report.
3.3.12 Average Number of Timeslots
To see if the number of given channels are in proportion to the number of possible channels in the MS.
Reserved Timeslots (#)
Reserved Timeslots (%)
The percentage of reserved timeslots out of the number of reservable timeslots.
Reservable Timeslots (#)
3.4 Inter System Handover
3.4.1 General
This chapter deals with monitors available for monitoring of inter system handover in R-PMO. A number of predefined reports - Ericsson Standard Reports - are supplied for Inter System Handover. These are:
• Inter System Resource Allocation
These monitors will give information about resource allocation result during Inter System Handover and Inter System Handover performance
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
Inter System Successful Resource Allocation Outgoing HO (%)
Successful resource allocation for outgoing handover attempts from GSM to UTRAN due to load.
(Included in Inter System Resource Allocation report)
Inter System Outgoing HO Attempts (#)
Number of resource allocation for outgoing handover attempts in UTRAN from GSM to UTRAN due to load.
Inter System Successful Resource Allocation Incoming HO (%)
Successful resource allocation for incoming handover attempts from UTRAN to GSM due to load.
Inter System Incoming HO Attempts (#)
Number of resource allocation for incoming handover attempts from UTRAN to GSM due to load.
Inter System Multi RAT MS (#)
Number of Multi RAT mobiles that can do handover to UTRAN
Inter System Handover attempts
(Included in Inter System Handover report)
Inter System Handover success (%)
Successful handover in percentage.
Average value of UMTS cell quality for successful handovers.
Inter System Handover reversion (%)
Handover reversions are handover attempts that were failed but not lost.
Inter System Quality at HO reversion
Average value of UMTS cell quality for successful handovers.
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
Average value of UMTS cell quality for Handover lost
Max number of ISHO triggered (#)
Shows the number of times when the maximum number of Inter System Handovers have been triggered (MAXISHO has been reached).
3.5 TRX
3.5.1 General
This chapter deals with monitors available for monitoring of the TRXs. The monitors can be used for statistical purposes (i.e. stored in EBS) and not in real-time. The monitors are defined per cell but the information received is per TRX.
3.5.2 TRX Monitors
These monitors will provide information about the activity on the TRXs.
TRX Handover Attempts (#)
TRX Handover Success (#)
TRX Num of Attempted Calls (#)
The total number of attempted calls on TRX level
TRX TCH Drops (#)
The number of dropped calls on TRX level. A dropped call is a TCH connection that is released for other reasons than handover or normal call release.
TRX TCH Traffic (Erlang)
The average traffic level on TRX level, calculated from the number of busy channels.
3.6 New filters in R12
For the complete picture of all filters in R-PMO see R-PMO Monitor Description, Reference [7]
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
Low Priority Mode
For Throughput monitors and monitors showing Radio Link Bitrate and IP Latency it shall be possible to filter on “low scheduling mode”. The new filter is added to following monitors:
• Total IP Data, TBF (kbyte)
• IP Distribution, Radio Link Bitrate (%)
• IP Throughput Distribution, TBF (%)
• Radio Link Bitrate (kbps)
Compensate for parallel PFCs Yes/No, default value is Yes
If there are two parallel active PFCs it is possible to include the PFC with the highest priority in the monitors, and if the PFCs have the same priority none of them are counted. Affected monitors are:
• IP Throughput DL, PFC (kbyte/s)
• IP Throughput, DTM Connections (kbyte/s)
• IP Throughput Distribution, PFC (%)
MS MSlot Class (1–45, All), default value is All
To enable the operator to determine the IP throughput impact from multi slot usage. One or more ms multi slot classes can be selected at the time (multi select). Affected monitors are:
• IP Throughput DL, PFC (kbyte/s)
• IP Throughput, DTM Connections (kbyte/s)
• IP Distribution, Radio Link Bitrate (%)
• IP Throughput Distribution, PFC (%)
• IP Throughput Distribution, TBF (%)
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
MS 3GPP Capability (R97/R99, R4, No filter) default value is No filter
The filter MS 3GPP R97/R99 or R4 should be possible to set on the IP Latency monitor. Affected monitors are:
• IP Latency Distribution, TBF (%)
Extended cause codes for dropped calls
New causes will replace the old cause list from R10 and R11. These causes are possible to multi select as user defined filters in applicable monitors. The filters are:
• Channel group
• Codec type
• Sub cell
• Urgency condition
IMEISV, Traffic case
A possibility to set a filter for Traffic Case in following monitors:
• Intra- and subcell handover attempts (#)
• Intra- and subcell handover success (%)
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
• TCH drops (#)
• Unsatisfactory SQ (%)
• Handover success (%)
• Handover attempts (#)
• Intra- and subcell handover attempts (#)
• Intra- and subcell handover success (%)
3.7 Operator and User-defined Reports
The operator can define reports including the monitors that are the most interesting for his specific needs. Two types of customized reports exists:
- The Operator-defined Report can only be created and edited by a person with the system administrator authority. The reports can be used throughout an Operators network to enable comparisons of different parts of the network using identical reports. The reports are available for all users and for all cell sets.
- The User-defined Report. This type of report can be created by the end users working with R-PMO. The User-defined Report can be customized for certain local monitoring needs. The report is only available for the creator of the report.
Both Operator and User-defined Reports are assembled from the monitors available in R-PMO.
3.8 Raw Event Data Export
The Raw Event Data Export, REDE, lets the user store event notifications from BSC and monitors defined in R-PMO in an OSS file. All event- and monitor data is stored. The format of the file can be tab separated or XML.
The Raw Event Data Export is initiated from a GUI started from the R-PMO main window. The collection of data starts when the user initiates the collection from the GUI and stops when the user stops the collection or at a user specified time. The result can then be post processed by the user.
For more detailed information about the functions in REDE please see the OSS User Guide Reference [9], for more information about the REDE interface see RPMO Raw Event Data Export File Interface Description Reference [4].
3.8.1 IMEI Trace
The monitors included in the Operator-defined and User-defined Reports can be set up to present the measured value for a specific Mobile Station HW. The Mobile Station HW is defined by the manufacturer and type. This information
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
is also available as a file at the Raw Event Data Export interface. It is also possible to set up a filter on Mobile Station HW in the file to Raw Event Data Export interface.
3.9 R-PMO Database Export Interface
The R-PMO Database Export Interface (RPDBI) admits the storing of user-selected monitors in a database. The user can select, per cell set, which monitors to be stored as counters. The data can later be post-processed and reports can be created from monitors stored as counters by using the Business Objects tool. If the data is stored with the same periodicity in RPDBI and STS it is possible, in post processing, to combine R-PMO data with STS data in the same Business Objects report.
For more detailed information about RPDBI, please see the R-PMO, RPDBI, EBS User Guide Reference [9].
3.10 Event Based Statistics Database
The data in this database will act as a complement to the STS database but it is of more detailed character than the STS statistics. The data can either be stored in the database or in a Bulk Copy format file that can be distributed to other post-processing tools. The monitors (counters) that can be stored must be activated in the GUI by the user, the user must have the correct authority to perform this action. The user must also select if the counters are to be collected for a specific BSC or several/all BSCs. The user can schedule the start and stop of data storage. The aggregation time, i.e. how often data is accumulated, can be decided by the user.
The data can later be post-processed and reports can be created from monitors stored as counters by using the Business Objects tool. If the data is stored with the same periodicity as in STS it is possible, in post processing, to combine R-PMO data with STS data in the same Business Objects report.
For more information regarding EBS, please see the R-PMO, RPDBI, EBS User Guide Reference [9] .
3.11 Improved monitor presentation
There are a lot of data presented in the monitors and it is sometimes difficult to navigate and to find what is really important. To handle this a filtering possibility using thresholds are added to the R-PMO application, by using this it is possible to limit the amount of data shown in the user interface.
It is possible to save the following settings; user organized columns in a report, the way a report is sorted, and threshold settings.
It is possible to display the Average Row in the graph.
It is possible to perform multi-select for filters.
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
It is possible to perform a delayed start of REDE.
When a received Measurement Result data is below a given confidence level the values are suspect marked and the reason for the suspect mark is shown.
3.12 Related Statistics
N.A.
N.A.
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
4 Engineering Guidelines
4.1 Application Guidelines
4.1.1 User-defined Reports
A central mechanism in R-PMO is the ability to create personal reports. User-defined reports are created by dragging and dropping monitors into a report template and defining a number of filters to filter out the preferred data. For the owner, the reports will then appear amongst the other reports, for others it is not visible.
The user can select any name on the report as well as on the included monitors.
The following sections are examples on User-defined Reports.
4.1.2 Create a report for the Distribution of Difference of RxLev DL (only used for Multi Band Cells)
The purpose of the report is to present a distribution of the difference between simultaneously reported RxLev on the active channel, DL (compensated for BTS output power, BTS power control, etc.) and the RxLev on the BCCH of the serving cell.
This report is useful when tuning Multi Band Cells and will give guidance on what values to set for the Multi Band Cell parameter FBOFFS (defines the frequency band group offset that is added to the reported RxLev when the active channel resides in the non-BCCH frequency band). The suggested intervals below have been chosen so that the granularity is higher around the expected median of the distribution and lower for the tails. This will keep down the number of instances needed for the monitor.
Note that it is recommended to carefully read the User Description, Multi Band Cell, before FBOFFS is changed since other factors may influence the choice, see Reference [11].
Here are the examples:
1. BCCH frequency in weaker band (GSM 1800 or 1900). Difference of RxLev DL to Active channel in stronger band
Include (drag and drop) seven monitors of “Distribution of difference, RxLev DL (#)” with the following thresholds into a User Defined report:
Distribution of difference, RXLev DL (#), RXLEV Min=-8, RXLEV Max=0 (counts # of -1, -2, -3, -4, -5, -6, -7, -8)
Distribution of difference, RXLev DL (#), RXLEV Min=0, RXLEV Max=4 (counts # of 0, 1, 2, 3)
Distribution of difference, RXLev DL (#), RXLEV Min=4, RXLEV Max=6 (counts # of 4, 5)
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
Distribution of difference, RXLev DL (#), RXLEV Min=10, RXLEV Max=14 (counts # of 10, 11, 12, 13)
Distribution of difference, RXLev DL (#), RXLEV Min=14, RXLEV Max=22 (counts # of 14, 15, 16, 17, 18, 19, 20, 21)
Comment to the first example; The general interpretation of the result from this report is that if the median difference in the cell is found to be in the interval containing 6 and 7, then FBOFFS could be set to -7 to give a suitable compensation for most of the cell.
2. BCCH frequency in stronger band (GSM 800 or 900). Difference of RxLev DL to Active channel in weaker band
Include (drag and drop) seven monitors of “Distribution of difference, RxLev DL (#)” with the following thresholds into a User Defined report:
Distribution of difference, RXLev DL (#), RXLEV Min=-21, RXLEV Max=-13 (counts # of -14, -15, -16, -17, -18, -19, -20, -21)
Distribution of difference, RXLev DL (#), RXLEV Min=-13, RXLEV Max=-9 (counts # of -10, -11, -12, -13)
Distribution of difference, RXLev DL (#), RXLEV Min=-9, RXLEV Max=-7 (counts # of -8, -9)
Distribution of difference, RXLev DL (#), RXLEV Min=-3, RXLEV Max=1 (counts # of 0, -1, -2, -3)
Distribution of difference, RXLev DL (#), RXLEV Min=1, RXLEV Max=9 (counts # of 1, 2, 3, 4, 5, 6, 7, 8)
Comment to the second example; The general interpretation of the result from this report is that if the median difference in the cell is found to be in the interval containing -6 and -7, then FBOFFS could be set to 7 to give a suitable compensation for most of the cell.
4.1.3 Create an RxQual Report
The purpose of the report is to present the percentage of connections with "bad RxQual", that can be used when comparing the performance between
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
cells or the performance in the same cell before and after changes have been implemented in the network.
Note that an RxQual based report can never give a totally accurate representation of the user perceived speech quality because the quality is also dependent on the used speech codec and the Frame Erasure Rate (FER). The FER values are not measured here and in order to manage this limitation different thresholds for what should be considered "bad RxQual" should be used. The different thresholds can then be applied based on the supplementary information about the used speech codec and whether a connection is on a hopping channel or a non-hopping channel.
Here are suggestions for thresholds that could be used:
Non-hopping CHGR
Use RxQual threshold 3 for HR, FR and AMR HR.
Use RxQual threshold 4 for EFR.
Use RxQual threshold 5 for AMR FR.
Hopping CHGR
Use RxQual threshold 5 for HR, FR, EFR and AMR HR.
Use RxQual threshold 6 for AMR FR.
(Note that AMR FR performance on a hopping channel is actually too good to be represented by this simple formula, so the percentage of RxQual 7 alone will substantially exaggerate the fraction with bad speech quality.)
In the example below the CHGR0 (with the BCCH frequency) is non-hopping and CHGR1 is hopping over 6 frequencies. Create a user-defined report based on different filter settings, e.g. filter on direction (UL or DL), codec type and channel group level. Name the report for instance “AMR RxQual”. The following instances of the monitor “RxQual, %>threshold” are defined in the report:
AMR RxQual Report contents:
RXQUAL over given threshold (%) filtered on UL, AMR HR, CHGR0, Threshold=3
RXQUAL over given threshold (%) filtered on DL, AMR HR, CHGR0, Threshold=3
RXQUAL over given threshold (%) filtered on UL, AMR FR, CHGR0, Threshold=5
RXQUAL over given threshold (%) filtered on DL, AMR FR, CHGR0, Threshold=5
RXQUAL over given threshold (%) filtered on UL, AMR HR, CHGR1, Threshold=5
RXQUAL over given threshold (%) filtered on DL, AMR HR, CHGR1, Threshold=5
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
RXQUAL over given threshold (%) filtered on UL, AMR FR, CHGR1, Threshold=6
RXQUAL over given threshold (%) filtered on DL, AMR FR, CHGR1, Threshold=6
4.1.4 Create a Speech Quality Supervision Report
This report is only possible to create if the features SQS and EMR are activated.
The purpose of the report is the same as with the RxQual Report, but the SQI and FER measures give possibilities to look at different codecs with the same threshold. In the example below, there are FER monitors for AMR FR, EFR, and the rest as AMR FR and EFR are expected to have noticeable better result.
The SQI thresholds have been chosen to reflect "perfect" (>27), "good" (>22), and "acceptable" (>13) speech quality.
Here are suggestions for monitors and thresholds to use:
SQI %>27, all codecs
FER (#)
4.1.5 Create an IP Throughput Distribution Report
Assume the throughput of EGPRS DL data is in focus. The monitor to show how big part of the IP data that is sent with a IP Throughput between 50-100 kbps, for example, should be defined in the following fashion:
Monitor IP Throughput Distribution, PFC (%)
Filter Direction: DL
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
Traffic Class: No filter
Thpt (Throughput) Min: Individual per monitor instance
Thpt (Throughput) Max: Individual per monitor instance
MBR/GBR Min: 0 kpbs
MBR/GBR Max: 8460 kbps
Cell name
IP Throughput Distribution - PFC (%) with above defined filter + Thpt Min/Max 0-50 (kbps)
ditto + Thpt Min/Max 50-100 (kbps)
ditto + Thpt Min/Max 100-150 (kbps)
ditto + Thpt Min 150 (kbps)
Total IP data - PFC (kbyte)
Using the above concept, reports with optional granularity can be created.
4.1.6 Create an IP Latency report
From the average IP latency (as provided by STS counter) it is possible to calculate the average total impact on a users data session from the round-trip times within the BSS and MS.
For example say the download of a certain web page needs a total of 20 requests/responses from the server to enable the transfer of all data objects and the measured average IP latency is 330 ms. Then on average the IP latency within the BSS and MS contributes 6.6 seconds to the total transfer time.
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
However by creating a distribution of the IP latency in R-PMO it is possible to see if the average IP latency comes from a very narrow or large range of values (a variation in delay is often referred to as "jitter" in the internet world). Using R-PMO it can be investigated if the IP latency varies between different types of services (for example EIT, normal streaming or interactive & background) or between different MS types (GPRS capable only or GPRS/EGPRS capable).
The IP latency may also vary between different mobile manufactures and different types of user configuration (for example an application built into the mobile or an application on a PC connected to the mobile via IR).
This example report presents the percentage of IP latency samples that fall within different time intervals. Only EGPRS capable terminals are studied.
Use the Stand-alone monitor IP latency Distribution - TBF(%)
Filter TBF mode: All (default)
RLC mode: Both (default)
IP Latency Min: Individual per monitor instance
IP Latency max: Individual per monitor instance
Repeat the process for the other IP Latency time intervals and add a monitor for the total number of samples:
IP Latency Distribution Report Contents
Cell name
IP latency Distribution - TBF (%) with above defined filter + IP Latency Min/Max 200-250 ms (%)
ditto + IP Latency Min/Max 250-300 ms (%)
IP Latency Samples - TBF (#)
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
Filter Direction: DL
TBF mode: EGPRS
Cell name
Abnormal TBF releases (%) with above defined filter.
TBFs (#) with above defined filter.
Average TBF time (s) with above defined filter.
Total IP data - TBF (kbyte) with above defined filter.
Total IP data - PFC (kbyte) with above defined filter.
4.1.8 Operator-defined Reports
This is a function that is closely related to User-defined Reports. The only difference is that only the System Administrator can create, modify, and delete these reports. For other users, there is no difference between Operator-defined reports and the Ericsson Standard Reports.
The following section is an example of an Operator-defined Report.
4.1.9 Create a KPI report
The idea is to give the operators a chance to put together a network wide report with specific Key Performance Indicators. This example shows a mix between circuit switched monitors and GPRS monitors:
KPI Report Contents
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
4.1.10 Raw Event Data Export
With Raw Event Data Export (REDE), the user can select any raw event notifications and monitors available, and collect them during a selected time (up to 60 minutes). They are then saved in a file (tab limited or XML), for external post-processing in for example Excel.
The idea is either to select all the event notifications and monitors for one or a few cells for general troubleshooting, or to select events and monitors pinpointed to a specific problem.
Assume the TCH drop situation should be studied. First select the cell in focus, then specify the following events in REDE:
TCH drop troubleshooting event notifications
Measurement Result Event
Clear Request Event
Clear Command Event
The result is a file with all events of the specified types - event per event. The user can look at the causes for each Clear Request and Clear Command, see which reasons there were for releasing calls, see what RxQual and RxLev values were logged just before for a specific connection, and draw conclusions.
Due to memory consumption in the OSS, the recommended maximum number of cells to log with all events subscribed is estimated to 100. For more detailed
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
information about REDE please see the OSS User Guide RPMO Raw Event Data Export File Interface Description, Reference [4].
4.1.11 R-PMO Database Export Interface
The procedure to create reports is identical to the real time presentation case. After creation, the report can be made active in two ways: “Activate” (which means active as a real time report) or “Store in database”. Instances of the same report may be active both as ‘real time’ and ‘store in database’ at the same time. This database is meant to be a tool for the single user to store his/hers individually created reports. For more information regarding RPDBI see the R-PMO, RPDBI, EBS User Guide Reference [9] .
If the data is stored with the same periodicity in RPDBI and STS it is possible to combine R-PMO data with STS data in for instance the same Business Objects report.
4.1.12 Event Based Statistics Database
The data can either be stored in the database or in a file with Bulk Copy file format. The user selects which BSC(s) and monitor(s) that shall be stored and selects “Activate”. When the statistics collection shall stop the user selects “Deactivate” and no new statistics is then stored for the selected monitors. The data is stored in the database every 15 minutes. This database is meant to be used as a complement to the STS since it is possible to continuously store data from the entire network (i.e. max 15.000 cells). For more information regarding EBS see the R-PMO, RPDBI, EBS User Guide Reference [9] .
If the data is stored with the same periodicity in EBS and STS it is possible to combine R-PMO data with STS data in for instance the same Business Objects report.
4.2 Prerequisites and System Setup
The event notifications are transferred from an RPP device in the BSC, via the BSC LAN switch to the OSS on a TCP/IP connection.
The optional feature IP Connectivity described in Reference [1] is needed for the feature. In addition the optional BSC feature ‘Real Time Event Data’ (RTED) is needed. The cabling architecture for RTED is described in Reference [1].
The RTED and IP Connectivity features are supported in BSCs of type BYB 501 or AXE 810.
Guidelines for calculating the required bandwidth for the TCP/IP links between OSS and BSC are found in chapter 4.4.2.
Setting up the BSC for RTED is described in the User Guide Reference [10]. In addition the following recommendations should be considered:
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
• If a BSC controls more than 3000 Erlang of traffic, it is a recommendation to configure the MES functionality to run on the RPP located to a 100 Mbps slot in the RP magazine.
Furthermore the number of GSL traffic channels handled by this ’MES RPP’ should be reduced to half.
• In addition, if a BSC supervises more than 6000 Erlang of traffic, the ’MES RPP’ should not have to handle any GSL traffic channels at all.
Note Locating the MES function to a specific RPP means that no automatic relocation of the MES function to another RPP is performed at an RPP fault. The recommendation is to appoint two RPPs to event handling by blocking all devices and only use one RPP as master and the other as hot stand-by, the fail over are between these two dedicated RPPs (the RPPs shall be placed on the 100 Mbps position but in two different racks).
Note Usage of the feature GPRS/EGPRS Mobile Logging requires additional consideration. See Reference [6].
Note This information might be updated.
The procedures of dedicating a the MES to a specific RPP and removing traffic from the RPP is described in the Operator Instruction Reference [2].
4.3 System Administration Information
4.3.1 The BSC Configuration
Configuring the BSC for R-PMO is described in Reference [10].
To check if the optional feature RTED in the BSC is enabled, the current status of parameter RPMO can be printed with the following printout command:
DBTSP:TAB=AXEPARS,SETNAME=CME20BSCF,NAME=RPMO;
The feature is enabled if the value of parameter RPMO=1.
4.3.2 The Event Notification Transfer between BSC and OSS
The OSS client connects to the BSC Master Event Server using a TCP/IP network. The setting up of the network is described in Reference [1].
4.3.3 The OSS Configuration
In the OSS the port for the R-PMO agent to communicate with the server handling the BSC needs to be setup. The procedure for that is described in the OSS document R-PMO, Real Time Performance Monitoring, System Administrator Guide Reference [3]. The document also describes the following maintenance procedures:
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
• Commissioning
• Configuring BSCs for R-PMO
• Connecting R-PMO to a BSC
• Disconnecting R-PMO from a BSC
The OSS can be configured in different ways depending on how much data that is sent from the BSC to the OSS.
For a user that will store data in EBS for the entire network (i.e. max 15.000 cells) it requires storage facilities of approximately 100 Mbytes of storage per recording period.
4.4 Load and Limitation Issues
Load regulations prevents the R-PMO application from disturbing pay load traffic performance in the system.
• BSC slows down the event rate (discards events) in situations where traffic performance could be affected; event notifications that are results of measurement reports have least priority and are discarded first. The reporting rate of Measurement Result event is based on a statistical calculated system where more MR events are received during low traffic and fewer MR events are received during busy traffic or at overload situations. The calculation of reporting rate is based on the traffic in the cell. At overload in BSC both CP and RP events can be discarded according to priority on the events. System events are never discarded. A cause value is included in the event “Event Lost” to describe why the event notification was discarded. If there are too few events coming through from the BSC to the OSS the cause for this will be indicated in the information field in the R-PMO monitors.
• In OSS the R-PMO application can increase or decrease the event notification rate from the BSCs to keep it on a level where overload is stopped. When an increase is decided, the BSC(s) with no event based statistics turned on will be down regulated first. And when the event notification rate is decreased again the BSC with event based statistics are turned on first. The BSC with REDE turned on is never down regulated. Many BSCs will have the same level of suitability for down regulation but the BSCs will be picked randomly to avoid that the same BSC always is picked first. BSCs of version BSS R11 or earlier cannot be load regulated. The regulation intervals are kept short and will not be activated for temporarily congestions.
According to dimensioning rules, the Event Based Statistics application in OSS should be able to process event notifications from 100% of the total network supervised by OSS. For large R-PMO systems these 100% are estimated to correspond to a traffic load of maximum 100 000 Erlang (15.000 cells). The
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
dimensioning rule for the real time monitoring applications is 10.000 Erlang (3000 cells).
Certain measures are recommended for setting up BSCs for which a high amount of event traffic is expected; see chapter 4.2.
If the load is at all an issue of concern it is likewise recommended for a user to select the monitors that are really of interest, rather than subscribe to all available events. Note that the RxQual (UL and DL) and the Unsatisfactory Speech Quality monitors that are using the Medium Measurement Result event are causing up to over 80% of the total event handling load due to the high frequency of measurement results. The Large Measurement Result event is always sent for every received Measurement Result.
For more detailed information of the BSC load see Reference [5].
4.4.1 OSS CPU Load, and Memory Requirements
In a theoretical model the OSS CPU load, due to R-PMO, is estimated to a maximum of 100% when all available CS+PS events are active in all cells. The total traffic volume generated in the theoretical model is 100.000 Erlang (traffic generated in maximum 15.000 cells connected to several BSCs). The required memory space is estimated to 20 GB.
4.4.2 TCP/IP Load
If all available CS and PS events for supervising 10.000 Erlang of traffic (total traffic from all BSCs), a load on the OSS link of up to 4 Mbps could be expected. If the case of 100.000 Erlang of traffic (total traffic from all BSCs) is activated, a load on the OSS link of up to 34 Mbps could be expected. For further information see BSC/TSC HW Dimensioning Handbook Reference [8]
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
5.2 Parameters for Special Adjustments
5.2.1 Set the CALLDROPMSC Parameter
The CALLDROPMSC parameter in the BSC has to be set, to be able to receive the full set of Drop Calls cause values in R-PMO.
This parameter indicates if the reason for dropped call is to be reported to the MSC or not. If CALLDROPMSC is ON, the reason is sent to the MSC in message CLEAR REQUEST.
0 = OFF, the reason for dropped call is not reported to MSC.
1 = ON, the reason for dropped call is reported to MSC.
Default value: 0
Note To get the correct drop reason, the exchange parameter CALLDROPMSC must be set.
5.2.2 Enable Ciphering
Ciphering needs to be enabled in the network (MSC and BSC) for monitoring of IMEI information (mobile HW information).
5.3 Value Ranges and Defaults Values
N.A.
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
7 Concepts
Accessibility The accessibility performance is the system’s ability to handle subscribers’ requests for service.
Cell set A number of cells, grouped together.
Event Notification
An Event Notification refers to a message transfer from the BSC to the OSS. It reflects an occurred event registered by the BSC.
GUI Update Period
Mean Value Resolution
See Resolution
Monitor A Monitor refers to statistical measures displayed in R-PMO in real-time. Event notifications are the base for the monitors. In the Graphical User Interface the name of the monitor is often stated in a shorter form than in this document.
This document specifies in which Ericsson Standard Report a monitor is included. All monitors (exception see below) are also, by default, possible to select as stand-alone monitors (to be used in user or operator-defined reports). Exception: Monitors defined on neighbor cell level are not available to the user to be included in user-defined reports.
Raw Event Data Export
A function that provides access to event notification - and monitor data at an export interface in OSS. The data can then be post processed at the operators own wish. The function is part of R-PMO.
Real-time In this document it means that the information will arrive for display as soon as the BSC has processed the data. Tests have shown a delay of approximately 2 seconds.
Report R-PMO mentions three types of reports:
• Ericsson Standard Report which is built in and which is directly possible to select by any user. The standard report cannot be modified by the user.
• Operator-defined Report which is defined by the system- or application administrator, and which is available for all users and for all cell sets. The report contains a number of monitors that can not be changed or removed by any user other than the system administrator.
• User-defined Report which is defined by the end user and available for all cell sets. The report contains a number
/ EPKAJAC 225/1553-HSC 103 12 Uen
/ 2005-06-17 PB7
E
of monitors that can be changed or removed only by the creator of the report.
Resolution Mean Value Resolution period is the time duration for monitor value calculations. It is possible to set in the table report GUI and can be set to 1, 5, 15, 30, or 60 minutes. Regardless of Mean Value Resolution, each monitor value in the GUI is updated every minute.
Retainability Retainability covers the ability to keep established connections until normal termination.
Ser

RPMO Introduction

Documents