RO - QoS South Optimisation RNC/BSC Performance report

RO – QoS South Optimisation

RNC/BSC Performance report

Version 1.1

Author Moe Abbas & Janet Acheson

Date 22nd December 2006

Version V1.1

Filename BSC&RNC Performance Reporting V1.1.doc

Page 1 of 14
RO - QoS South Optimisation RNC/BSC Performance report

Review & Approval

Name Responsibility Level Signature

South Optimisation
Jose Crespo Approver
Specialist
South Optimisation
Hugo Araujo Reviser
Engineer

Document History
Version Reason Date

0.1 Initial Version 15.12.2006

1 Draft approved 20.12.2006

1.1 Chapter 4.4 : « KPI degradation cause categories » added 22.01.2007

All Rights Reserved

This is unpublished work. No part of this document may be copied, photocopied, reproduced, translated or
reduced to any electronic or machine readable form without the prior written consent of Vodafone Group
Plc.

Page 2 of 14
RO - QoS South Optimisation RNC/BSC Performance report

Table of Contents

1 Background................................................................................................................................. 4
1.1 Purpose and Scope............................................................................................................. 4
2 Requirements............................................................................................................................. 4
2.1 ..................................................................................................................... 4
2.2 ..................................................................................................................... 4
3 Update Procedure....................................................................................................................... 5
3.1 Using the Access query.......................................................................................................5
3.2 General Guidance................................................................................................................ 5
3.2.1 Using the Business Objects query..................................................................................6
4 Updating the Performance Report Information............................................................................7
4.1 Definition of incidents thresholds.........................................................................................7
4.2 Investigation of 3G issues....................................................................................................7
4.2.1 Several RNC fail same KPI(s).........................................................................................8
4.2.2 Single RNC failing KPI(s)................................................................................................8
4.3 Investigation of 2G issues....................................................................................................9
4.3.1 Several BSC’s fail same KPI(s)......................................................................................9
4.3.2 Single BSC failing KPI(s)................................................................................................9
4.4 KPI degradation cause categories.....................................................................................10
4.4.1 RNC failure categories..................................................................................................10
4.4.2 BSC failure categories..................................................................................................12
5 BSC/RNC performance Report publishing................................................................................13

6 Appendix A – Email distribution list for report commenting........................................................14

Page 3 of 14
RO - QoS South Optimisation RNC/BSC Performance report

1 Background
Associated to the daily network performance KPI reporting, RO QoS Optimisation was asked to
comment on performance impacting issues. A decision was taken to keep a record of these
comments including a record of any action taken. Since most of the issues are associated with
network nodes the tracking is done by RNC and BSC with drill downs as required. This reporting
was included as one of the required deliverables in the managed service agreement between
Vodafone and the Optimisation supplier (Ericsson).

1.1 Purpose and Scope

The purpose of this document is to illustrate the existing process for BSC and RNC Performance
monitoring of incidents, including the creation and maintenance of the daily and weekly reports
associated with this task. This document defines the procedure and it provides details of the
inputs, outputs and requirements needed to complete the report. This document also provides a
framework for the responsibilities of those involved in managing the network change
management process.

2 Requirements
Daily aggregates of the Performance Management (PM) counters are required for the completion
of this task, these are available in two NMS maintained data-warehouse tools: GPD and VPW.
Accounts and ODBC connections are required for both of these PM counter repositories.

Two queries are used to collect the relevant daily aggregate counters required for the update of
the reporting document.

2.1

This is located under:

\\Rpd2\main\QoS_Optimisation_South\09.Reports\19.BSC_RNC_performance

This is an ACCESS query and is linked to a live database. It’s used to acquire 2G data.

2.2

This is located under:

\\Rpd2\main\QoS_Optimisation_South\09.Reports\19.BSC_RNC_performance
This is a Business Objects query. It’s linked to the VPW database so it’s used to acquire 3G data.

Page 4 of 14
RO - QoS South Optimisation RNC/BSC Performance report

Both applications should be run locally rather than from the Network.

3 Update Procedure
In this chapter we describe how to update the BSC data using the repository and applications
mentioned in Chapter 2.

3.1 Using the Access query

 Open the query, and then go to Macros.

 Double click the Macro: Daily_2G_KPI_Macro. This will open a new sheet which will have
the new data.

 Copy that data, and then paste it in the appropriate columns in the daily BSC report.

3.2 General Guidance

 If using the query on Mondays, go to queries, click on BSC_daily_GSM_KPI, design and
then change the number from 2 to 4

 Follow the same procedure for the query BSC_daily_kpi_GPRS.

 The Case or sub case should be dispatched to the relevant incoming queue

Page 5 of 14
RO - QoS South Optimisation RNC/BSC Performance report

3.2.1 Using the Business Objects query

 Open the Business objects query.

 Click on the refresh tab.

 Enter the desired date, remember that the daily aggregates are usually available on the
following day.

Page 6 of 14
RO - QoS South Optimisation RNC/BSC Performance report

 Once refreshed, save as a TXT file, open the file in Excel and copy all rows, pasting them
into the Daily performance report.

4 Updating the Performance Report Information

In this chapter we describe how issues are identified and categorised in the daily performance
report document. This document is a live document update daily by engineer from both RO
Optimisation teams.

4.1 Definition of incidents thresholds

The objective of this activity is to identify the cause of any sudden performance degradation at
network level. In order to achieve this, a drill down to RNC and BSC level is done and thresholds
are define internally between the Optimisation experts and the Optimisation team leader.

The current thresholds in place within RO South Optimisation are defined in subchapters 4.2 and
4.3.

These thresholds try to minimise the work load of the engineers involved and filter any normal
KPI fluctuation of specific BSC or RNC.

4.2 Investigation of 3G issues

If an RNC performance fails any of the following then a comment must be added to the report to
explain the reason(s) for failure, and a drop down box selected to categorize the root cause:

 3G Voice CSSR < 98%

 3G PS CSSR < 98%

 3G Voice DCR >1%

 3G PS DCR >3%

In case where no cause is identified and degradation is ongoing the optimisation engineer
responsible for the area should be requested to follow up and raise the necessary support cases
via Clarify.

Page 7 of 14
RO - QoS South Optimisation RNC/BSC Performance report

4.2.1 Several RNC fail same KPI(s)

If several RNC fail the same KPI check the following:

 Was there a known incident which caused the degradation?

 Do the RNC have a common Core Network node?

 Did the degradation happen at the same time on all of the RNC?

4.2.2 Single RNC failing KPI(s)

The BO query ‘Cell_level_drill_down’ stored in the directory below provides the cell-level KPIs for
the RNC under investigation:

\\Rpd2\main\QoS_Optimisation_South\09.Reports\19.BSC_RNC_performance

The query sorts the cells in the RNC in terms of decreasing absolute failures for the KPI.

In the case of CSSR failure it is important to determine whether RRC or RAB establishment are
the main cause for failure.

4.2.2.1 Single cell/site responsible for degradation

If degradation is due to a single cell or the cells of a single site, then the Optimisation Engineer
responsible for the site should be alerted to the issue. If there has been a step change in
performance then the degradation is most likely to be due to a hardware fault, and a Clarify Case
should be raised for investigation by the Service Area Team.

4.2.2.2 Several cells/site responsible for degradation

If degradation is due to many cells check the following:

 Are all the cells on the RNC affected?

If not:

 Are the cells in the same vicinity within an RNC?

 Are the cells on the RNC border?

Page 8 of 14
RO - QoS South Optimisation RNC/BSC Performance report

 Are the cells on the same RNC module?

 Did the degradation happen at the same time on all of the cells?

4.3 Investigation of 2G issues

If a BSC performance fails any of the following then a comment should be added to the report to
explain the reason(s) for failure if the BSC would generally meet the threshold, and a drop down
box selected to categorize the root cause:

 2G Voice CSSR < 98%

 2G PS CSSR < 98%

 2G Voice DCR >1%

It is only expected that BSC will be commented against when degradation is seen.

In case where no cause is identified and degradation is ongoing the optimisation engineer
responsible for the area should be requested to follow up and raise the necessary support cases
via Clarify.

4.3.1 Several BSC’s fail same KPI(s)

If several BSC’s fail the same KPI check the following:

 Was there a known incident which caused the degradation?

 Do the BSC’s have a common Network node?

 Did the degradation happen at the same time on all of the BSC’s?

4.3.2 Single BSC failing KPI(s)

The Access query ‘GSM_KPI.mdb’ stored in the directory below provides the cell-level KPI’s for
the BSC under investigation:

\\Rpd2\main\QoS_Optimisation_South\09.Reports\19.BSC_RNC_performance

Once you have opened ‘GSM_KPI.mdb’ go to Queries select the ‘BSC_GSM_KPI_CELL’ query
then click on design. Enter the BSC name then run.

Page 9 of 14
RO - QoS South Optimisation RNC/BSC Performance report

The query will then produce a table and will sort the cells in the BSC in terms of highest sum of
congestion per cell for the KPI.

4.3.2.1 Single cell/site responsible for degradation

If degradation is due to a single cell or the cells of a single site, i.e. congestion is considerably
higher than the rest of the cells, the Optimisation Engineer responsible for the site should be
alerted to the issue. If the cell has been congested for a few hours only this may well be will be
due to either an event or planned software upgrade. If there has been a step change in
performance then the degradation is most likely to be due to a hardware fault, and a Clarify Case
should be raised for investigation by the Service Area Team.

4.3.2.2 Several cells/site responsible for degradation

If degradation is due to many cells check the following:

 Are all the cells on the BSC affected?

If not:

 Are the cells in the same vicinity within a BSC?

 Are the cells on the BSC border?

 Did the degradation happen at the same time on all of the cells?

4.4 KPI degradation cause categories

To enable the statistical analysis of the reasons behind each of the BSC or RNC failure to meet
the set threshold a drop down menu is in place with the most common causes. If possible a
objective assignment of a reason should be done for each of the failures, in subchapter 4.4.1and
4.4.2 we’ll give a summarise description of each of the accepted reason categories

4.4.1 RNC failure categories

The following are the accepted reasons for RNC failing to meet the KPI thresholds as defined in
subchapters 4.2

Page 10 of 14
RO - QoS South Optimisation RNC/BSC Performance report

 Event

Whenever the major contributor for the KPI degradation is associated with a foreseen or
unforeseen public event.

 Cell optimisation and dimensioning

Poor performance related to lack of capacity on a node that can be resolved by parameter
changes or capacity expansion. This is when carried traffic is higher than the capacity
deployed on the node.

 IUB Congestion

Lack of transmission capacity over the Iub interface.

 Planned Work

Schedule work that impacts cell performance usually at BSC or RNC level. E.g. a software
upgrade or RNC cutover.

 RBS fault

Performance degradation caused by a RBS fault, e.g. TRU fault or any other hardware on
the site.

 RNC fault

Fault which occurs on the RNC or that directly impact the RNC performance rather than
cells, e.g. SCCP congestion problem or module issues which would normally affect many
cells on that RNC

 Transmission

Faults which occur on the transmission network i.e. BT link faults or ATP link failures

 Unknown

Cannot determine cause or cause unclear. E.g. un explained spikes in traffic or short dips in
performance/availability

 Core Network fault

Failure in core network. E.g. MSC,SGSN, HLR

Page 11 of 14
RO - QoS South Optimisation RNC/BSC Performance report

 Trial

When a parameter trial being run by RO or TS impacts performance. Generally, these trials
should be reversed.

4.4.2 BSC failure categories

The following are the accepted reasons for BSC failing to meet the KPI thresholds as
defined in subchapters 4.3.

 Event

Whenever the major contributor for the KPI degradation is associated with a foreseen or
unforeseen public event.

 RBS Fault

Performance degradation caused by a RBS fault, e,g. TRU fault or any other hardware on
the site.

 BSC Fault

Fault which occurs or impacts directly the BSC performance. Usual affects many cells on
the BSC

 Transmission fault

Faults which occur on the transmission network i.e. BT link faults or ATP link failures

 Cell optimisation and dimensioning

Poor performance related to lack of capacity on a node that can be resolved by parameter
changes or capacity expansion. This is when normal traffic is higher than capacity on the
cell. For example, when cell is suffering from TCH congestion and an expansion has been
requested, or where expansion not possible due to cabin space limitations or SDCCH
congestion requiring additional SDCCH.

 Unknown

Cannot determine cause or cause unclear. E.g. un explained spikes in traffic or short dips in
performance/availability

Page 12 of 14
RO - QoS South Optimisation RNC/BSC Performance report

 Planned work failed

Unsuccessful planned work that impacts cell performance usually at BSC or RNC level.
E.g. a software upgrade or RNC cutover

 Planned software upgrade

Software upgrades impacting performance. Will mainly be seen in the early hours of the
morning.

 Cutover

RBS, BSC re-parenting, causing temporary dip in performance

 RBS power

Power failure on RBS

5 BSC/RNC performance Report publishing

As mentioned before the Report is based on a shared excel workbook, this workbook is updated
daily and therefore can be considered as a “live” available under:

\\Rpd2\main\QoS_Optimisation_South\09.Reports\19.BSC_RNC_performance

On new workbook sheet will be create each month allowing everyone to check the history of
previous months.

On a Monthly basis as well an update copy of that month’s sheet will be place in the RO-QoS
teamroom with all the comments updated.

Page 13 of 14
RO - QoS South Optimisation RNC/BSC Performance report

6 Appendix A – Email distribution list for report commenting.

On a daily basis after the report has been updated with the new daily PM information, an email
should be sent indicating the location of the save document, requesting comments on all
instances where the RNC or BSC performance failed to meet the desired thresholds defined in
this document.

The email distribution list should contain the following users:

To Field:

Feasby, Jonathan, VF UK; Araujo, Hugo, VF UK; Acheson, Janet, Tech Dev, VF UK; Levin, David,
VF UK; Samuels, Andre, VF-UK; Cole, Darren; Bains, Manjinder, Tech Dev, VF UK; Buchan,
Marcus, VF UK; Addison, Neil, VF UK, Partner; Parasuraman, Subhashini, VF UK; Mittal, Vinay,
SCP Tech Ops, VF UK; moorthy, murali, VF UK, Partner; McGaughey, David, SCP Tech Ops, VF
UK

CC Field:

Majumdar, Sibabrata, VF UK; Fahim, Sasan, Tech Ops, VF UK; Patel, Rajesh, VF UK -
Technology (RO); Bennegent, Pierre, VF UK - Technology (TS); Pipikakis, Michael, VF UK; Ali,
Muquid, VF UK; Ogunye, Wale, VF UK; Choudhury, Dipankar, Tech Ops, VF UK; Dutta, Amit, VF
UK; Oztezcan, Leyla, Tech Ops, VF UK; Sliva, Marek, VF UK; Moore, Gary, Tech Ops, VF UK;
Grey, Phil, Tech Ops, VF UK; Pattinson, Craig, VF UK; Young, Chris, Tech Dev, VF UK; Amin,
Ashker, VF UK; Neway, Mihretab, VF UK; Aziz, Khalid, VF UK Technology (TS)
rizwan.hassan@ericsson.com

Page 14 of 14