Professional Documents
Culture Documents
RNC/BSC Performance Report: Ro - Qos South Optimisation
RNC/BSC Performance Report: Ro - Qos South Optimisation
Version 1.1
Version V1.1
Page 1 of 14
RO - QoS South Optimisation RNC/BSC Performance report
Document History
Version Reason Date
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
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).
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 an ACCESS query and is linked to a live database. It’s used to acquire 2G data.
2.2
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.
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.
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
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.
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.
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.
Page 7 of 14
RO - QoS South Optimisation RNC/BSC Performance report
Did the degradation happen at the same time on all of the RNC?
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.
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.
If not:
Page 8 of 14
RO - QoS South Optimisation RNC/BSC Performance report
Did the degradation happen at the same time on all of the cells?
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.
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.
Did the degradation happen at the same time on all of the BSC’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.
If not:
Did the degradation happen at the same time on all of the cells?
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
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.
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
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
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.
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
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
Unsuccessful planned work that impacts cell performance usually at BSC or RNC level.
E.g. a software upgrade or RNC cutover
Software upgrades impacting performance. Will mainly be seen in the early hours of the
morning.
Cutover
RBS power
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
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.
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