Author
Date
Version
V1.1
Filename
Page 1 of 15
Responsibility
South Optimisation
Specialist
South Optimisation
Engineer
Jose Crespo
Hugo Araujo
Level
Signature
Approver
Reviser
Document History
Version
Reason
Date
0.1
Initial Version
15.12.2006
Draft approved
20.12.2006
1.1
22.01.2007
Page 2 of 15
Table of Contents
1
Background.................................................................................................................................
1.1
Requirements.............................................................................................................................
2.1
2.2
Update Procedure.......................................................................................................................
3.1
Using the Access query.......................................................................................................
3.2
General Guidance................................................................................................................
3.2.1 Using the Business Objects query..................................................................................
Page 3 of 15
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
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. Its 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. Its linked to the VPW database so its used to acquire 3G data.
Page 4 of 15
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
Double click the Macro: Daily_2G_KPI_Macro. This will open a new sheet which will have
the new data.
3.2
Copy that data, and then paste it in the appropriate columns in the daily BSC report.
General Guidance
The Case or sub case should be dispatched to the relevant incoming queue
Page 5 of 15
3.2.1
Enter the desired date, remember that the daily aggregates are usually available on the
following day.
Page 6 of 15
Once refreshed, save as a TXT file, open the file in Excel and copy all rows, pasting them
into the Daily performance report.
4.1
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.
Page 7 of 15
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 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.
4.2.1
Did the degradation happen at the same time on all of the RNC?
4.2.2
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.
Page 8 of 15
If not:
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:
It is only expected that BSC will be commented against when degradation is seen.
Page 9 of 15
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
Did the degradation happen at the same time on all of the BSCs?
4.3.2
The Access query GSM_KPI.mdb stored in the directory below provides the cell-level KPIs 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.
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.
Page 10 of 15
If not:
Did the degradation happen at the same time on all of the cells?
4.4
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 well give a summarise description of each of the accepted reason categories
4.4.1
The following are the accepted reasons for RNC failing to meet the KPI thresholds as defined in
subchapters 4.2
Event
Whenever the major contributor for the KPI degradation is associated with a foreseen or
unforeseen public event.
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.
Page 11 of 15
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
Trial
When a parameter trial being run by RO or TS impacts performance. Generally, these trials
should be reversed.
4.4.2
Event
Whenever the major contributor for the KPI degradation is associated with a foreseen or
unforeseen public event.
RBS Fault
Page 12 of 15
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
Unknown
Cannot determine cause or cause unclear. E.g. un explained spikes in traffic or short dips in
performance/availability
Cutover
RBS, BSC re-parenting, causing temporary dip in performance
RBS power
Page 13 of 15
Page 14 of 15
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 15 of 15