Upload
dgmateos
View
205
Download
21
Embed Size (px)
DESCRIPTION
BSS KPI and Counters
Citation preview
Proposal for BSS Radio Network KPIs
DOCPROPERTY "AdmInfo" \* MERGEFORMAT
Ericssonwide InternalTECHNICAL REPORT39 (41)
Prepared (also subject responsible if other)No.
EAB/RJT/F Robert GavelEAB/RJT-04:0048 Uen
ApprovedCheckedDateRevReference
EAB/RJT/F [Robert Gavel] DOCPROPERTY "Checked" \* MERGEFORMAT 2004-06-07A DOCPROPERTY "Reference" \* MERGEFORMAT
Propsal for BSS Radio Network KPIsAbstract
This report has been written based on an assignment from PC BSS and contains a proposal of a standard set of BSS Radio Network Key Performance Indicators. The purpose is to align the usage of KPIs within PDU GRAN and also within Ericsson.
Contents
41Introduction
41.1Background
41.2Purpose
51.3Scope of this report
51.4Scope of the Radio Network KPIs
61.5Structure of this document
61.6Comments on the formulas
92Circuit Switched KPIs
92.1Introduction
92.2Overview of the Circuit Switched KPIs
102.3Accessibility
102.3.1General
102.3.2Random Access Success rate
102.3.3SDCCH time congestion
112.3.4SDCCH drop rate
122.3.5TCH Assignment Success rate
132.4Retainability
132.4.1TCH drop rate
152.4.2Call minutes between drops
152.4.3Handover Success Rate
152.4.4Handover Lost Rate
162.5Integrity
162.5.1General
162.5.2Speech Quality on uplink
182.6Inter system operability
182.6.1GSM to UTRAN Handover Success Rate
182.6.2GSM to UTRAN Handover Lost Rate
192.7Traffic level
192.7.1General
192.7.2TCH traffic
192.7.3SDCCH Traffic
203GPRS KPIs in BSS
203.1Introduction
213.2Overview of GPRS KPIs
233.3General GPRS KPIs
233.3.1IP transfer interrupt downlink
253.3.2IP transfer interrupt uplink
263.3.3GPRS Availibility
273.4Best effort service KPIs (traffic class background and interactive)
273.4.1IP latency BSS-MS-BSS (R11)
283.4.2IP Throughput
303.5Streaming KPI
303.5.1QoS Negotiation success rate
313.6Ericsson Instant Talk (EIT) KPIs (R11)
323.7Dual Transfer Mode KPIs (R11)
333.8IP User Data Volume
344Next Step
355Potential counter and formula updates
376Abbreviations
387References
Appendix A Object Types per KPI35
1 Introduction
1.1 Background
Within the PDU GRAN an initiative has been taken to identify standard KPIs in different areas. The KPIs should be used internally and towards the customer to measure our products, organisation and processes. This report focuses on the radio network KPIs.
Different formulas and Radio Network KPIs are today described and used in different parts of Ericsson, e.g.:
The User Description Radio Networks Statistics is the official set of formulas supplied in the product documentation, see reference 1. Even if this document points out key areas in performance management is does not promote a limited set of specific formulas as KPIs.
NetQB, a benchmarking service supplied by BUGS based on a number of predefined KPIs (see reference 2).
BUGS have their own documents describing formulas they use when performing network optimisation services, see reference 3
During LiTe tests a number of Radio Network Performance KPIs are measured and documented in LiTe reports, see reference 4.
Miscellaneous presentation that have been used to present KPIs to the customers
Customers also define their own KPIs, often based on definitions from other vendors that are mapped on to the Ericsson counters
The divergence when it comes to KPI definitions leads to some confusion and makes it difficult to compare and relate measurements done at different locations and activities.
1.2 Purpose
This Technical Report has been written in response to the Assignment Specification found in reference 5.
The purpose of the report is to propose a standard set of BSS radio network KPIs in order to align the metrics used within primarily PDU GRAN, but also within Ericsson. The proposed KPIs should also be used as a support to KAM organisations when discussing KPI definitions used by the customers.
By aligning the KPIs within Ericsson it will be possible to give a more uniform message to the customer and to compare results from KPI measurements from different activities and customers. By aligning the KPIs also to the NetQB benchmarking service it will be possible to compare KPI measurements with actual figures collected from a large number of operators.
The basis for the proposal has been what is recommended today in the RNS UD (reference 1) and what BUGS and NetQB use.
1.3 Scope of this report
The primary scope of the report is to propose BSS radio network KPIs, the scope of the KPIs is described in chapter 1.4.
The following parts are not within the primary scope, even though they may be covered to a certain extent:
Propose how the KPIs should be communicated (covered to a certain extent in chapter 4)
How the KPIs should be included in the product (covered to a certain extent in chapter 4)
More elaborate description of suitable second level performance indicators to use if a KPI indicates poor performance. The RNS UD should be used for this purpose, see reference 1.
Propose how the KPIs should be used and applied in different activities within PDU GRAN.
1.4 Scope of the Radio Network KPIs
The following apply to the scope of the proposed radio network KPIs:
The KPIs are aimed at fulfilling the needs of the operator to monitor the performance of their BSS radio network. The KPIs might not be ideal for other purposes, like rating the performance or capacity of the BSC.
The KPIs reflect the end-user perception of the performance of BSS as far as possible rather than the system view. The KPIs are though only based on what can be measured in BSS, for GPRS end-to-end KPIs on service level need other types of measurements and are described e.g. by GETEP see reference 7.
The KPIs are possible to collect from STS statistics and are formulated on counter level.
The KPI definitions are proposed for the R10 and R11 releases.
The KPIs are formulated on cell level; they can though of course be aggregated on BSC or system level. It has been commented per KPI if a simpler version of the formula can be used if applied on BSC or system level.
1.5 Structure of this document
The KPI definitions are described in two separate chapters, one for circuit switched (CS) and one for packet switched (PS) KPIs.
Chapter 4 contains some ideas on how the work with the KPIs should proceed.
Chapter 5 contains proposals for changes in counter and existing formulas that have been identified during the work with the KPIs.
Appendix A lists the object types that must be collected to create the KPIs.
1.6 Comments on the formulas
Formulas have been written for both R10 and R11 if they differ.
PERLEN stands for measurement period length in STS (minutes), and is available as a parameter in STS.
Formulas that include handovers have considered handovers both to BSC internal and external neighbours. If data is only collected from one BSC it is not possible to obtain the incoming handovers from external cells, so then all handovers for external cells could be omitted.
For formulas handling handovers user defined summation counter have been used. The summation counters are not part of the BSC STS counters, but should created on cell level in a post processing tool, The summation counters are available in the NWS database and report generator in OSS, see reference 9. The counters are also described in reference 3.
Note: The names used in NWS for the summation counters have been used in this document, the tools SPOS/TURTLE in some cases use shorter versions of the names as there is a limitation to the number of characters that can be used, e.g SPOS/TURTLE use SUMEOHATT and NWS SUMEOHOATT.The STS object types that contain counters for BSC internal cell relations are NCELLREL and NICELASS, and for BSC external cell relations NECELLREL and NECELASS. The following formulas show how the summation counters are calculated as a sum over all internal and external cell relations:
ATT= HOVERCNT
SUCC=HOVERSUC
REV=HORTTOCHLOST=HOVERCNT-HOVERSUC-HORTTOCH
ABSUCC=HOSUCBCL
AWSUCC=HOSUCWCL
The following summation counters are used for every cell in the BSC as the sum over all internal or external cell relations:
SUMIAWSUCC Sum of Successful Internal Assignment Handovers to Worse Cell (Incoming Handover)
SUMOHOSUCC Sum of Successful Internal Handovers (Outgoing Handover)
SUMOABSUCC Sum of Successful Internal Assignment Handovers to Better Cell (Outgoing Handover)
SUMOAWSUCC Sum of Successful Internal Assignment Handovers to Worse Cell (Outgoing Handover)
SUMIHOSUCC Sum of Successful Internal Handovers (Incoming Handover)
SUMIABSUCC Sum of Successful Internal Assignment Handovers to Better Cell (Incoming Handover)
SUMIAWSUCC Sum of Successful Internal Assignment Handovers to Worse Cell (Incoming Handover)SUMEIHOSUCC Sum of Successful External Handovers (Incoming Handover)
SUMEIABSUCC Sum of Successful External Assignment Handovers to Better Cell (Incoming Handover)
SUMEIAWSUCC Sum of Successful External Assignment Handovers to Worse Cell (Incoming Handover)
SUMEOHOSUCC Sum of Successful External Handovers (Outgoing Handover)
SUMEOABSUCC Sum of Successful External Assignment Handovers to Better Cell (Outgoing Handover)
SUMEOAWSUCC Sum of Successful External Assignment Handovers to Worse Cell (Outgoing Handover)
SUMOHOATT Sum of Internal Handover Attempts (Outgoing Handover)SUMEOHOATT Sum of External handover Attempts (Outgoing Handover)SUMOHOLOST Sum of MS Lost Internal Handovers (Outgoing Handover)SUMEOHOLOST Sum of MS Lost External Handovers (Outgoing Handover)
For GSM to UTRAN handovers similar summation counters are created on cell level, all counters are located in the object type NUCELLRELCNT:
SUMHOVERCNTUTRAN Sum of the counter HOVERCNTUTRAN over all GSM to UTRAN cell relations (outgoing handover)
SUMHOVERSUCUTRAN Sum of the counter HOVERSUCUTRAN over all GSM to UTRAN cell relations (outgoing handover)
SUMHOLOSTUTRAN Sum of HOVERCNTUTRAN-HOVERSUCUTRAN-HORTTOCHUTRAN over all GSM to UTRAN cell relations (outgoing handover)
2 Circuit Switched KPIs
2.1 Introduction
The proposal for CS radio network KPIs is based on the KPIs defined by NetQB, as they are widely spread and already used to collect data from a large number of operators. More information about NetQB can be found in reference 2. The KPIs described in this chapter are in line with the NetQB definitions and the changes that are proposed for R10.
The KPIs are grouped in the areas accessibility, retainability and integrity as defined by ITU, see reference 6.
Paging performance has not been included as it primarily should be monitored with MSC counters as one location area might span more than one BSC.
Traffic level has also been added even if it strictly speaking is not a KPI of its own.
2.2 Overview of the Circuit Switched KPIs
Table 1 below gives an overview of the proposed circuit switched KPIs.
Accessibility
Random access success rateSDCCH time congestion
SDCCH Drop rateTCH Assignment success rate
Retainability
TCH Drop rateCall minutes per drop
Handover success rateHandover lost rate
Integrity
Speech quality goodSpeech quality acceptableSpeech quality bad
Inter system operability
GSM to UTRAN Handover success rateGSM to UTRAN Handover lost rate
Traffic level
TCH Traffic SDCCH Traffic
Table 1 Overview of CS KPIs
2.3 Accessibility
2.3.1 General
For setting up a signalling connection the mobile might try several times for each call setup. Thereby building up a combined total metric for accessibility is not recommended, as one access failure seen from the subscribers will be seen as several access failures in the system. Each step in the call set-up process should thus be accounted for separately and for SDCCH availibility time congestion is a better measure than success rate.
TCH time congestion was previously part of NetQB but is proposed to be removed. How the counters for TCH time congestion shall be interpreted with a subcell structure depends on the channel allocation profile of the customer and if assignment to other cell is allowed it does not give a good measure of the subscriber perceived congestion. The subscriber perceived TCH congestion is visible in the KPI TCH Assignment success rate.
2.3.2 Random Access Success rate
Formula
Random access success rate
Percentage successful random accesses.
[%]
Description
A failed random access burst does not mean a failure to access the system, as the mobile may send many random access bursts each time it tries to access the network. E.g. bad BSIC planning, too high TA, parameter settings (e.g. MAXRET) or interference might cause a high number of random access failures.
The KPI covers random accesses over RACH both for CS and PS connections, but not over PRACH (when using a MPDCH). Only failures related to the random access as such are considered, rejects due to load regulation are not included and can be monitored by separate counters.2.3.3 SDCCH time congestion
Formula
SDCCH Time congestion
SDCCH time congestion, percentage of the time.
[%]
DescriptionCongestion on SDCCH might not lead to a call set-up failure as the mobile may retry several times to set-up an SDCCH in case of congestion (controlled by the MAXRET parameter). Also if immediate assignment on TCH is allowed the call set-up may proceed on a TCH even if there is SDCCH congestion. SDCCH time congestion starts incrementing when all channels are occupied, even if there are no rejected accesses.
If there is an SDCCH in both the OL and the UL subcell the KPI will over estimate the congestion as there will only be subscriber perceived SDCCH congestion the SDCCHs in both subcells are congested. Note though that in a multi band cell some mobiles may not be capable to access both subcells.
The systems are normally dimensioned to have a certain SDCCH GoS, so the KPI should be compared to the GoS that the system was planned for. The system should normally be dimensioned with low SDCCH congestion, as a rule of thumb the SDCCH Grade of Service (GOS) should be dimensioned for no more than of the TCH GOS. Even if the SDCCH congestion is normally very low it is important to monitor it as it can rise sharply due to subscriber behaviour, e.g. through heavy usage of SMS or positioning using AGPS.
If the feature Adaptive configuration of logical channels is used SDCCH congestion is prevented by allowing on-demand SDCCHs to be allocated in case of congestion, and monitoring the SDCCH congestion is less critical.
2.3.4 SDCCH drop rate
Formula
SDCCH Drop rate
Percentage drops on SDCCH channels.
[%]
DescriptionA drop on SDCCH does not mean a failed call set-up since it can be used for procedures that only requires an SDCCH like a location update or SMS. In fact as the SDCCH holding time for call set-up is just under 3 seconds and about twice as long for SMS, drops for SMS should be over represented.
The KPI does not include released SDCCH connection due to TCH or transcoder congestion (i.e. the CNRELCONG counter), as it is seen in the TCH assignment success rate KPI. The drop rate is related to all SDCCH establishments in the cell; no compensation has been done for SDCCH handovers, as the mobiles normally camp on the SDCCH a short time SDCCH handover occur seldom.
A high SDCCH drop rate may be due to:
Poor coverage
Interference
Equipment faults (e.g. BTS or mobile related)
Subscriber behaviour (sending frequent large SMS, using AGPS positioning or causing sudden loss e.g. entering an elevator)2.3.5 TCH Assignment Success rate
Formula
TCH Assignment success rate
Percentage successful first TCH assignments for the mobiles that tuned in to signalling in the cell.
[%]
Note: If the formula is used on BSC or system level handovers do not need to be considered. The summation counters used for the handovers are described in chapter 1.6.
DescriptionThe assignment success rate covers both change from SDCCH to TCH or changed channel mode on TCH from signalling to speech.
It should be noted that during the assignment procedure there may be several attempts to allocate a channel in several cells, but the attempts counter in this formula (TASSALL) will only be incremented once, if an attempt succeeds or if all attempts have failed.
The counters in the formula are only stepped for the for the first assignment attempts on a TCH, changing from SDCCH to TCH or changed channel mode on TCH from signalling to speech or circuit switched data.
The KPI covers the TCH grade of service in the cell, but also includes other reasons for failures to establish a TCH like transcoder congestion, CLEAR COMMAND, RESET or RESET CURCUIT received from the MSC, Ater RESET or Ater RESET CURCUIT received from the TRC, MS lost, link connection or HW failure during the assignment process. The system are dimensioned to have a certain TCH GoS, so the KPI must be compared to the TCH GoS the system was planned for.
The counters in the formula are for successful assignments are stepped in the target cell; if the assignment fails the TASSALL counter is stepped in the serving cell (the cell where the MS was tuned in for signalling). To show how many mobiles that tuned in for signalling in the cell that managed to establish a TCH outgoing assignment handovers are added (they managed to get a TCH in an other cell) and incoming assignment handovers are subtracted (they tuned in to signalling in an other cell) from both the numerator and the denominator.
The TCH assignment success rate is impacted by parameter settings e.g. for the assignment timeout (TASSREQ) and assignment to worse or better cell (e.g. AWOFFSET).
.2.4 Retainability
2.4.1 TCH drop rate
Formula
TCH Drop rate
Percentage dropped TCH connections of the total number of TCH connections terminated in the cell.
[%]
Note: If the formula is used on BSC or system level handovers do not need to be considered. The summation counters used for the handovers are described in chapter 1.6.
Description
To capture the subscriber perceived drops in a cell the number of calls terminated in the cell are considered, i.e. a compensation is done for incoming and outgoing hand-overs for all internal and external cell relations.
It is important to note that the TCH drop counters are stepped as soon as a TCH is established even if there has yet not been any B-answer, this is also applies when TCH is used for signalling. If the TCH is dropped before the B-answer the subscriber will experience it as a failed call set-up rather than a dropped call. If TCHs are used extensively for signalling one reason for increased TCH drops could be transcoder congestion, it can be seen in the counters THNRELCONG, THNRELCONGSUB, TFNRELCONG and TFNRELCONGSUB. TCH connections that are lost are during handovers are also seen as TCH drops in the counters.
If Adaptive Multi Rate (AMR) is used the subscriber will experience better speech quality and is more likely to hold on to the call until it drops rather than disconnecting the call due to poor speech quality, thus the drop rate might increase slightly when AMR is introduced. There are separate dropped call counters for AMR, which allows drops for AMR connections to be monitored separately.
As HOVERSUC includes successful SDCCH hand-overs, the drop rate on cell level can be skewed if there are a large number of SDCCH hand-overs. The mobile though camps on the on the SDCCH only a short period of time and number of SDCCH hand overs is normally small compared to the total number of TCH assignment, typically less than one percent.
A high TCH drop rate may be due to:
Poor coverage
Interference
Hardware faults (e.g. transcoder, BTS or mobile related)
Subscriber behaviour (e.g. causing sudden loss by entering an elevator or pulling out the battery)
Handover failure
Too high timing advance (TA)2.4.2 Call minutes between drops
Formula
Call minutes between drops
Average time period between TCH drops in minutes.
[min]
DescriptionThis KPI complements the TCH drop rate KPI as the call holding time may be differ in different networks or in different parts of one network, which may impact the TCH drop rate.
2.4.3 Handover Success Rate
Formula
Handover success rate
Percentage successful handovers. Summed up for all external and internal cell relations.
[%]
Note: The summation counters used for the handovers are described in chapter 1.6.
Description
The KPI does not only cover TCH handover but also handovers during assignment and SDCCH handovers.
A low handover success rate may be due to not optimised cell plan, parameters or neighbour relations.
.
2.4.4 Handover Lost Rate
Formula
Handover lost rate
Percentage MS lost at handovers. Summed up for all external and internal cell relations.
[%]
Note: The summation counters used for the handovers are described in chapter 1.6.
Description
The KPI does not only cover TCH handover but also handovers during assignment and SDCCH handovers.
The KPI shows the subscriber perceived impact due to failed handovers, as it shows the percentage of handover that resulted in a lost call. This KPI is important to correlate to the TCH drop rate since a lost handover for a TCH will also bee seen in the TCH drop KPI.
The handovers that are not successful or not lost revert to the old cell.
2.5 Integrity
2.5.1 General
The Integrity KPIs are based on the Speech Quality Supervision function, which is a method to measure and monitor the speech quality in the network based on radio quality information. The speech quality is determined by monitoring the radio conditions for each ongoing call in the network. The radio conditions are converted to a Speech Quality Index (SQI) which corresponds to a subjective speech quality, for more details see reference 11.
SQI is in R10 and R11 is available on the uplink, in R12 with the features EMR and SQS enhancements SQI on the downlink will be available for EMR capable mobiles. In R11 STS counters for RXQUAL uplink and downlink are introduced. The RXQUAL distribution for different hopping networks (or different network configurations) will not truly reflect the difference in subjective speech quality of the networks. The RXQUAL measure can thus not be used for benchmarking, and should therefore not be used as a KPI. However, RXQUAL is still interesting when comparing between cells within one network. 2.5.2 Speech Quality on uplink
Formulae
SQI UL Good
Percentage SQI samples with good quality of total number of SQI samples in both OL and UL subcells.
[%]
SQI UL Acceptable
Percentage SQI samples with acceptable quality of total number of SQI samples in both OL and UL subcells..
[%]
SQI UL Bad
Percentage SQI samples with unsatisfactory quality of total number of SQI samples in both OL and UL subcells..
[%]
2.6 Inter system operability
A UTRAN cell is considered as a candidate for handover if the signal quality in the target cell is good enough. When prioritizing between UTRAN or GSM the traffic load of the GSM cell is also used as a criterion for handover towards UTRAN. The handover between GSM to UTRAN can be controlled by a several parameters, more details can be found in reference 10.
Only outgoing handovers from GSM cells to UTRAN cells are counted in BSS. Similar counter exist in the UTRAN system that cover handovers from UMTS to GSM.
GPRS Cell Reselections to UMTS are not counted in BSS since the BSC is not aware if a mobile moves to another GSM BSC or to the UTRAN network.
2.6.1 GSM to UTRAN Handover Success Rate
Formula
GSM to UTRAN Handover success rate
Percentage successful GSM to UTRAN handovers.
[%]
Note: The summation counters used for the handovers are described in chapter 1.6.
Description
The KPI covers SDCCH and TCH handovers to UTRAN, no handovers during assignment are done to UTRAN.
The handovers to UTRAN are not seen in the general retainability KPIs for handover success rate and handover lost rate, see chapter 2.4.3 and 2.4.4. Generally the handovers to UTRAN are only seen in the UTRAN specific handover counter in BSS, except for the SDCCH hand over counters on cell level where they are included.
2.6.2 GSM to UTRAN Handover Lost Rate
Formula
GSM to UTRAN Handover lost rate
Percentage MS lost at GSM to UTRAN handovers.
[%]
Note: The summation counters used for the handovers are described in chapter 1.6.
DescriptionThe KPI shows the subscriber perceived impact due to failed GSM to UTRAN handovers, as it shows the percentage of handover that resulted in a lost call. This KPI is important to correlate to the TCH drop rate since a lost handover for a TCH will also bee seen in the TCH drop KPI.
The handovers that are not successful or not lost revert to the old cell.
2.7 Traffic level
2.7.1 General
Traffic level is not a KPIs in its own right but can be used to relate to changes in other KPIs, e.g. a sharp increase of traffic might explain an increased congestion or degraded speech quality (many half rate connections).
2.7.2 TCH traffic
Formula
TCH Traffic
Average TCH traffic in Erlang.
[Erlang]
2.7.3 SDCCH Traffic
Formula
SDCCH Traffic
Average SDCCH traffic in Erlang.
[Erlang]
3 GPRS KPIs in BSS
3.1 Introduction
In the telecom world network performance is often defined in the ITU terms accessibility, retainability and integrity. These terms work well in a circuit switched network; accessibility relates to blocked calls, retainability to dropped calls and integrity to speech quality. For the end user in a packet switched system it is though difficult to define measures in the BSS, that relate these terms to the end user perception of service quality. There are two main reasons for this:
The GPRS/EGPRS system has many layers of protocols. A user session where a TBF lost, which would be a retainability problem in BSS, will normally be kept alive by higher protocol layers (e.g. TCP) until a new TBF is established. To the user this seems like an integrity problem, a session that included a short delay. The higher layer protocols are transparent to BSS.
The GPRS/EGPRS network is a bearer for a number of different services. These are affected by events in the network in different ways. For example if BSS failed to transfer any data for 5 seconds it would be a serious problem for a WAP user, but hardly be noticed by a user down loading emails in the background. The end-user services are also normally not visible to BSS.
The terms accessibility, retainability and integrity can be applied to the EGPRS/GPRS system, but only on higher layers and by considering events that are invisible to the BSS. A full set of end-to-end KPIs have been defined and is available from Ericsson, see reference 7. The BSS GPRS KPIs in sections 3.2- 3.8 are all integrity KPIs on end-user level (with exception of GPRS availability in chapter 3.3.3). Accessibility and Retainability on GPRS Attach and PDP context level should be measured in the GPRS nodes (SGSN & GGSN).
As different characteristics are important depending on what type of application that the end-user is running the BSS IP service KPIs have been put in the following categories or application types:
General GPRS KPIs that are relevant for all types of transfers.
Best effort services (traffic class interactive and background). This could typically be email downloads, WAP session and ftp.
Streaming (traffic class streaming). This could typically be real time viewing of film clips.
Ericsson Instant Talk (also called Push to talk Over Cellular). A walkie-talkie like service that is identified in BSS to cater for its specific characteristics; high demand on transfer delay but moderate demands on bandwidth. In BSS R11 support for EIT is implemented over a streaming bearer using the quality of service feature.
Dual Transfer Mode, a simultaneous CS call and PS data transfer. DTM is not an application as such, but needs to be monitored separately since fewer timeslots can be used for the PS connection and as the mobility pattern will differ compared to pure PS connections..
The KPIs in this document are directly related to the BSS ability to transfer IP packets, which impact the user perception of the service. Each KPI is normally affected by a number of different factors. To trouble shoot deviations found in the KPIs lower level performance indicators must be used; these second level performance indicators are not within the scope of this document and are described in reference 1. Apart from using STS counter further detailed troubleshooting can be done with other applications like R-PMO and GMLOG.
3.2 Overview of GPRS KPIs
Table 2 below gives an overview of the BSS GPRS KPIs.
General GPRS KPIs
IP Transfer interrupts uplinkIP Transfer interrupts downlink
GPRS Availability
Best effort service KPIs (traffic class background and interactive)
IP Latency GPRSIP Latency EGPRS
IP Throughput uplink GPRSIP Throughput uplink EGPRS
IP Throughput downlink GPRSIP Throughput downlink EGPRS
Streaming KPI
QoS Negotiations success rate
Ericsson Instant Talk, EIT (R11) KPIs
Transfer delay success uplinkTransfer delay success downlink
Dual Transfer Mode, DTM (R11) KPIs
DTM IP Transfer interrupts uplinkDTM IP Transfer interrupts downlink
DTM IP Throughput uplinkDTM IP Throughput downlink
IP User data volume
IP User data volume uplinkIP User data volume downlink
Table 2 Overview of BSS GPRS KPIsThe KPIs are described in the subsequent chapters. Table 2 below give an overview how the KPIs as they are defined and the different application types relate to each other. The impact on DTM transfers depends on what application is running in the PS session of the DTM transfer, it is assumed that it will normally be a best effort application.
Application type
KPIBest EffortStreamingEITDTM
IP transfer interrupts (Ch. 3.3.1 and 3.3.2)+++++0
GPRS Availability (Ch 3.3.3)++++++++
IP latency (Ch 3.4.1)++0+++
IP throughput (Ch 3.4.2)++0+0
QoS negotiations (Ch 3.5)0++0+
EIT transfer delay (Ch 3.6)00++0
DTM IP transfer interrupts (Ch 3.7)000+
DTM IP Throughput (Ch 3.7)000++
IP User data volume (Ch 3.8)IIII
Table 3 Relation KPI and application type. Legend:++ : Significant impact on end-user performance+ : Impact on end-user performanceI : Included in KPI, no direct impact on end-user performance0 : Not included in KPI or not applicable
EIT transfers are built on a streaming bearer for the voice and an interactive bearer for the signalling, so also the KPIs for best effort services have impact on EIT.
Its important to focus the optimization efforts where they will give the biggest performance improvements for the users.
For interactive and background transfers this means minimizing the total transfer time (i.e. for each WAP page, web page, email transfer, MMS transfer etc). The best way to do this is to calculate the total transfer time as a function of the IP throughput, IP latency and IP transfer interrupts.
Example:
An operator wishes to optimize the GPRS network for the download of an average web page. This consists of 5 objects of size 9kbyte (giving a total of 45 Kbytes of data). To transfer these 5 TCP objects 20 Round Trip Times are needed (for TCP handshake messages and TCP slow starts).
A bit simplified the transfer can be modeled as:
The measured average IP throughput is 30 kbit/s. Transfer time = (45*8)/30 = 12 seconds.
The measured average IP latency is 300ms. Total latency time = 20 * 300 ms = 6 seconds.
The measured average TBF time per IP transfer interrupt = 20 minutes or 1200 seconds. Assume each interruption lasts for 5 seconds. If one web page takes a total of 18 seconds to download then a user should, on average, be able to download a total of 66 web pages without any problems. An interruption of 5 seconds will be experienced in the next download.
Another way to look at this is to say that for every 1 second of TBF time there is, on average, an added 0.0042 seconds of interrupt time. So added interrupt time = 18 * 0.0042 = 0.076 seconds.
So for this application, the optimization effort should be first directed towards improving the IP throughput, then the IP latency. The impact of the IP transfer interrupts is more subjective - is one interrupt in every 67th web page too much?
Different operators will have different focus on different applications. For example for WAP the IP latency will be a much larger part of the total transfer time.
Its important to note though that improving the IP throughput or IP latency will improve the performance for all applications (just to different degrees depending on whether the application is throughput or latency sensitive).
3.3 General GPRS KPIs3.3.1 IP transfer interrupt downlink
Formula
IP transfer interrupts downlink
Average downlink data session transfer in minutes per downlink IP buffer discard. DTM transfers not included.
R10:
[min]
R11:
[min]
Description
The KPI IP transfer interrupts downlink is a combined user integrity measure for mobility, TBF retainability and TBF accessibility assuming the delay or interruption to the user transfer is similar in all cases, typically in the order of 3-7 seconds.
The IP throughput counters measure the speed with which the BSS ships IP packets to and from the users. But what happens when the BSS has received IP packets from the SGSN but cannot transfer these to the MS for some reason (perhaps the BSS could not set-up a connection to the MS or the connection was broken mid-transfer)? Then the entire contents of the buffer in the PCU and SGSN will be discarded. Even if, as is likely in most cases, the data transfer is automatically re-established fairly quickly by the higher layer protocols (TCP or UDP), there will still be some impact on the transfer of IP packets from the discard. The transfer interrupts downlink KPI is measured as the number of complete downlink buffer discards per downlink TBF minute.
For TCP transfers this will usually result in a temporary reduction in the send rate of the TCP connection (TCP congestion avoidance and/or slow start).
For UDP transfers the application may request re-sending of the discarded data.
The user experience of an IP buffer discard is heavily dependent on the application he/she is running. But there will be some interruption in the transfer since the buffer is empty after the discard. It is the number of these interruptions in service that are important to measure rather than the amount data discarded.
. Shorter delays induced by an inter Routing Area or inter PCU cell reselection do not cause any PCU buffer discard are not considered in the KPI, these interrupts are normally in the range of 2-3 seconds and can be monitored by the FLUMOVE counter. With the feature network assisted cell change this time will be reduced even further down to one second.
In R11 with the feature loss less pre-emption the downlink IP buffer is kept during 5 seconds after a TBF is lost, the interrupt that will occur if a new TBF is established during this time is not visible in this KPI, but will be seen as a reduced throughput for the transfer.3.3.2 IP transfer interrupt uplink
Formula
IP transfer interrupts uplink
Average uplink data session transfer in minutes per abnormally released TBF Uplink and access reject. DTM transfers not included.
R10:
[min]
R11:
[min]
Description
The KPI IP transfer interrupts uplink is a combined user integrity measure for mobility, TBF retainability and TBF accessibility assuming the delay or interruption to the user transfer is similar in all cases, typically in the order of 3-7 seconds.
Ideally there should be a mirror image of the IP buffer discard counters for the uplink. However it is impossible for the PCU to know when the MS has decided to discard the contents of its IP buffer.Instead we measure the number of times the PCU knew the MS had data to send but was unable to for some reason. These can be split into two areas:
MS Access Rejects (MS request to set-up an uplink TBF must be repeated)
MS to BSS connection loss (Ongoing uplink TBF released with countdown value not 0)
A rejected packet access means that the MS has to retry its attempt to access the system. Normally the MS is prevented from attempting packet accesses in the same cell until the Wait Indication has expired (T3412 specified in the Immediate Assignment Reject message or T3172 (optional) specified in the Packet Access Reject message). This value always 5 seconds in the Ericsson BSS.A rejected packet access does not directly relate to a failure to transfer IP packets on the uplink since a packet access procedure is still required for other purposes (for example for the transfer of GMM/SM signalling). However the ratio of rejected packet access will give a good indication if there are problems in the cell.
When the MS to BSS connection is lost due to radio reasons, again, this does not indicate a direct impact on the users in terms of a failure to transfer IP packets on the uplink, but does gives an indication that there may be coverage and/or interference problems in the cell. It should be noted that it is impossible for the BSS to distinguish between radio contact lost due to cell reselection (non-NACC) and other radio reasons on the uplink. It is the MS that makes the decision to leave the old cell without the involvement of the BSS.
3.3.3 GPRS Availibility
Formulae
GPRS availability Cell level
Measure of GPRS availability per Cell. If the result is 0 the cell is likely not available for GPRS if 1 it is considered available. R11 only.
Note: GPRS_AVA_C should be calculated per cell and measurement period and be aggregated as a status counter i.e. be averaged over time.
GPRS availability BSC level
Measure of GPRS availability per BSC, the average percentage of cells considered as not being available for GPRS.
Description
The GPRS Availability KPI is based on measurements showing cells that are suspected to be unavailable for GPRS.
In the cells with no GPRS traffic during the last 5 minutes attempts are made to inject Packet Switched traffic by forcing a limited number of suspended GPRS attached MSs present in the cell to perform a Routing Area Update. The GPRSAVA counter counts each injection. If the number of traffic injection attempts over the chosen measurement period is five or more, but the data transferred is still zero the cell is suspected to be unavailable for GPRS.
If GPRS is unavailable in a cell may normally not be due to problems in BSS, but in other parts of the GPRS network.
It should be noted that the formula on cell level only works on data that has not been aggregated over time. The result of the formula should be aggregated as a status counter, i.e. by averaging over time.
3.4 Best effort service KPIs (traffic class background and interactive)
3.4.1 IP latency BSS-MS-BSS (R11)
Formulae
IP Latency BSS-MS-BSS GPRS
Average IP latency BSS-MS-BSS for GPRS capable mobiles, regardless of extended UL capability. R11 only.
[ms]IP Latency BSS-MS-BSS EGPRS
Average IP latency BSS-MS-BSS for EGPRS capable mobiles - regardless of extended UL capability. R11 only.
[ms]
Description
The IP latency BSS-MS-BSS is measured on small IP packets (or rather small isolated LLC PDUs) received on the Gb interface to an empty downlink buffer where a small IP packet is received on the uplink in response. The time is measured from the downlink packet is received on the GB interface until the uplink packet is sent onto the GB interface, i.e. it measures the delay Gb-BSS-MS-BSS-Gb, which in the majority of the GPRS networks contributes to more than 90% of the total client-server round-trip time. Note that also delays induced by the mobiles are included in the KPI. The picture below shows the time that will be measured as the BSS-MS-BSS IP latency.
All applications transfer sessions can be modelled as a period of round-trip-times (typically hand-shake procedures) and a period of data transfer. For the round-trip-time period the IP latency determines the performance and for the data transfer it is the IP throughput. For applications like WAP where only short bursts for data is transferred the IP latency is the major factor for the total transfer time, while for an ftp download of a large single file it would be the IP throughput.
The IP latency is affected by parameter settings for PULS (Persistent Uplink Scheduling), penetration of 3GPP R4 capable mobiles that are capable of Extended UL TBF, the traffic load, radio link quality and the coding schemes used.The formulas have been separated for EGPRS and GPRS as the higher throughput for EGPRS transfers will give better latency and to enable better correlation with the IP throughput KPIs that are separated for GPRS and EGPRS transfers. Note though that for the throughput KPIs the combination EGPRS/GPRS relates to the TBF mode while for latency it relates to the MS capability.3.4.2 IP Throughput
Formulae
IP Throughput UL GPRS
Weighted throughput, interactive and background transfers, GPRS transfers uplink.
[kbit/s]
IP Throughput DL GPRS
Weighted throughput, interactive and background transfers, GPRS transfers downlink.
[kbit/s]
IP Throughput UL EGPRS
Weighted throughput, interactive and background transfers, EGPRS transfers uplink.
[kbit/s]
IP Throughput DL EGPRS
Weighted throughput, interactive and background transfers, EGPRS transfers downlink.
[kbit/s]
Description The IP throughput is measured per PFC for the active PFC lifetime i.e. when there is data to send in the downlink buffers or when data is being sent uplink. Note that the active PFC lifetime timer is stopped a soon as there is no user data in the PCU buffer and the measured throughput is thus not impacted if the TBF is kept alive artificially by the system, for example by the feature Delayed release of DL TBF.
The IP throughput is weighted by data volume, i.e. a transfer of 100 KB will contribute 10 times more to the weighted IP throughput than a transfer of 10 KB.
Technically speaking the counters show throughput on the LLC layer rather than the IP layer, but the LLC overhead is very small. E.g. a 500 byte LLC PDU only contain 11 byte, or 2.2%, of header data.
In the throughput measurements the term GPRS and EGPRS relates to the TBF mode. In R12 new counters are introduced where it relates to the capability of the mobile, which will be a better KPI from the end-user perspective.
The IP throughput is impacted by e.g. the radio link quality, the number of PDCHs reserved per transfer, the capabilities of the mobiles and the traffic load in the system.3.5 Streaming KPI
3.5.1 QoS Negotiation success rateFormula
QoS Negotiation success rate
Percentage of QoS negotiations resulting in the requested GBR, XX relates to the GBR intervals the counters are divided in.
[%]
Description
This KPI relates to the quality of service class streaming, for more information on the quality of service feature see reference 8.
The characteristics of streaming transfers differ in many important aspects from the best effort services. Streaming transfers require a fixed throughput that is held consistent throughout the whole session; throughput for streaming transfers is thus not good measure of BSS performance. The reservations for streaming transfers therefore differs compared to other traffic classes and at high traffic load new streaming sessions will not be admitted or not get the requested Guaranteed Bit rate (GBR).
The parameters BPDCHBR, GPDCHBR and EPDCHBR are used to reserve a number of effective streaming PDCHs that are required to meet the requested GBR that is stored in the ABQP. The streaming transfer will have absolute priority on the effective streaming PDCHs and they are normally not allowed to be pre-empted. If the parameter settings are well tuned the normal problem for streaming sessions at resource shortage will be getting the requested GBR for a transfer. For details regarding the quality of service feature see reference 8.
The GBR is negotiated with the SGSN and by monitoring the outcome of these attempts to reserve resources it can be seen if the users get the GBR, and hence the quality of service, they requested. The success rate will vary with the type of streaming traffic in the cell (higher requested GBRs are more difficult to serve). As a second level measurement it should be verified that the parameters are set so that the reservation really meets the granted GBR.
IP transfer interrupts are important for streaming transfers as it will be experienced by the end-user as a bigger disturbance for streaming than for best effort services.3.6 Ericsson Instant Talk (EIT) KPIs (R11)
Formulae
Transfer delay success, Uplink
The percentage of EIT TBFs where more than 96% percent of the LLC-PDUs achieved the QOS attribute transfer delay. Only for R11.
[%]Transfer delay success, downlink
The percentage EIT TBFs where more than 96% percent of the LLC-PDUs achieved the QoS attribute transfer delay. Only for R11.
[%]
Description
EIT is a walkie-talkie like service that provides speech over a streaming bearer. The transfer delay is therefore more important than for other packet switched services, while the requirements on bandwidth are moderate. A too long transfer delay would lead to annoying silent periods during the conversation.
In BSS R11 support for EIT is introduced by identifying EIT users by the received ABQP and modifying the channel reservation and LQC to reduce delay and allow multiplexing of several EIT users on the same PDCH to increase capacity.
The primary KPI for EIT users is the transfer delay. In BSS it is influenced by both the IP latency in BSS and the throughput for the EIT users. If the EIT users do not get a high enough throughput the PDUs will be scheduled too late and the transfer delay will not met.
The KPI does not cover the whole subscriber perceived transfer delay, only the transfer induced by BSS can be measured. On the downlink it is measured from the time PDU arrives in the PCU buffer until it has successfully been sent over the air interface, on the uplink it is measured from the time the first radio block is received over the air interface until the PDU has been reassembled. The requested transfer delay from the SGSN is only this BSS portion of the total transfer delay.
EIT transfers are built on a streaming bearer for the voice and an interactive bearer for the signalling, so also the KPIs for best effort services have impact on EIT.
3.7 Dual Transfer Mode KPIs (R11)
Formulae
DTM IP transfer interrupts downlink
Average downlink data session transfer in minutes per downlink IP buffer discard, R11 only.
[min]
DTM IP transfer interrupts uplink
Average uplink data session transfer in minutes per abnormally released TBF Uplink and access rejects, R11only.
[min]
DTM IP Throughput UL
Weighted throughput, interactive and background traffic classes, EGPRS and GPRS uplink, R11 only.
[kbit/s]DTM IP Throughput DL
Weighted throughput, interactive and background traffic classes, EGPRS and GPRS downlink, R11 only.
[kbit/s]
Description
Dual Transfer Mode (DTM) enables a user to run a CS call and PS data transfer simultaneously.
The throughput and IP transfer interrupts needs to be monitored separately for DTM connections.
For DTM the mobility pattern will be different compared to other packet data sessions as the CS locating algorithm is used. Therefore the rate of IP transfer interrupts is likely to differ.
The throughput for DTM connections will be consistently lower than for other transfers as fewer timeslots can be used for the PS connection.
The formulas for DTM are constructed the same way and have the same interpretation as the corresponding general KPIs with the exception that the throughput KPI covers both GPRS and EPGRS.
3.8 IP User Data Volume
Formulae
IP User data volume downlink
LLC data volume for the whole cell including all traffic classes except GMM/SM signalling.
R10:
[MB/h]
R11:
[MB/h]
IP User data volume uplink
LLC data volume for the whole cell including all traffic classes except GMM/SM signalling.
R10:
[MB/h]
R11:
[MB/h]
Description
Strictly speaking IP user data volume is not an end-user KPI, however in general if the performance of the network improves then the users will be able to transfer a greater volume of data within the same time. Also if performance problems are identified using other KPIs then the IP user data volume can be used to evaluate if these are worth fixing. In system with low traffic levels it can also be used to as a rough indication of the statistical significance of deviations found in other KPIs.
The counters are technically measuring the LLC data volume rather than the IP data volume, but the LLC overhead is small. 4 Next Step
When the KPIs proposed in this report have been approved by PC-BSS the next step will be to document, communicate and align other relevant documents to the KPIs.
Documentation and updates of the KPIs
The KPIs should be documented in customer friendly format (basically an adaptation of this report) and be complemented by power point presentations. The KPIs should be revised twice a year based on input from the development projects and measurements on the installed based. To ensure that updates to the KPIs are spread each revision of the KPI definitions should be marked with an expiry date and a location where the new KPI definitions can be found.
A KPI reference group should be formed that is responsible for the KPI definitions and review and agree on the updates, the reference group should consist of representatives from BSS system, BUGS, BUSY and possibly from major KAM organizations.
Impact on the product and product documentation
There is an inherit problem to include the KPIs in the product documentation as the KPI definitions should be kept updated based on feedback from the live networks, but the product documentation is frozen on an early stage in the project and should not undergo major changes after the release. A reasonable ambition level is to update the RNS UD, see reference 1, to be aligned to the structure of the KPIs and contain the formulas, but not explicitly point them out as KPIs. As the structure of the KPIs basically follows the structure in the RNS UD this is minor effort that basically being done for R11.
The NWSA reports in OSS do not follow the structure of the KPIs today. To introduce a report in NWSA that match the KPIs proposed in this document would be difficult to get into the current projects and create some overlaps as the same topics are covered by other reports. To promote the KPIs and usage of NWSA the proposal is to add a new report with the KPIs in the NWSA product, but not to change existing reports.
Impact on BUGS
The documents from BUGS and the KPIs used in NetQB should also be aligned with the proposed KPIs. This alignment has already started as BUGS have been involved discussing this proposal. KPIs will though not be included in NetQB until a certain feature (like streaming) has a reasonable penetration in the installed base. The KPI reference group meetings will be a way to keep the definitions used by BUGS and PDU GRAN aligned.
Communication of the KPIs
KPIs in other areas, like support and supply, are also being defined. The proposed radio network KPIs should be communicated to the local companies and KAM organization jointly with these as the KPIs promoted by PDU GRAN.
Additionally presentations should be held when required to promote and present the KPIs.
Need for new counters
The requirements for new counter that have been identified during the work should be discussed with SPM do decide if there should be any new requirements.
5 Potential counter and formula updates
This chapter contains a number of proposals for updates to currently used formulas in the RNS UD and new counter that have been identified during the work with the KPIs.
Difficult to see subscriber perceived SDCCH (or rather signalling connection) time congestion
There are today SDCCH time congestion counters for OL and UL subcell, but as there might be SDCCHs in both UL and OL subcell and there is really not congestion subscriber perceived congestion until both are congested. Additionally even if there is SDCCH congestion the call set-up up might still proceed by signalling on a TCH (if immediate assignment on TCH is allowed).
To catch the subscriber perceived congestion there should be a time congestion counter on cell level that are incremented only when signalling connection attempts are rejected due to that no SDCCH or TCH is available for signalling both in the OL and UL subcell.
As call set-ups have higher priority than procedures that only require an SDCCH (SMS and LA update) there should perhaps be two separate counters.
The draw back with the counter is that is might depend on the MS capability, in a multi band cell a non multi band capable mobile might suffer congestion while other that is multi band capable do not.
There are new SDCCH time congestion counters for UL and OL subcell in the scope for R12 that increment only when there are rejected accesses (the current counter start incrementing when all channels are busy). Possible this requirement could be change to what is stated above to give a better picture of the subscriber perceived congestion.
Difficult to see subscriber perceived TCH time congestionThe same problem with the OL/UL cell structure applies to the TCH time congestion counters. Additionally there are also separate time congestion counter for half rate and full rate. There is also a set of hard time congestion counters (when a TCH could not be allocated after any type of pre-emption) for full rate OL/UL and half rate UL (OL in the scope of R12).
How to find out the subscriber perceived congestion depends on if a sub cell structure is used, the channel allocation profile and if cell load sharing is active.
Also for TCH time congestion there might be a new counter showing when access attempts are being rejected due on cell level.
New counter for TCH time congestion this is not as critical as for SDCCH time congestion since we have formulas for number of call-set-up attempts that failed due to TCH congestion; for SDCCH we do not have any similar measure as the mobile may retry several times during one call set-up attempt if there is SDCCH congestion.
SDCCH hand overs not on cell relation
The SDCCH handovers are included in the general cell relation counters for handovers but the SDCCH handover counters are on cell level. This makes it impossible to compensate for SDCCH handovers in the SDCCH and TCH drop formulas or to see exactly how many lost handovers that caused a TCH drop.
The solution could be either to have the SDCCH handovers on cell relation level or to exclude them from the general handover counter. On the other hand we do not recommend SDCCH handovers and the rate of SDCCH handovers is normally low.
Old TCH assignment success rate formula gives values over 100%
The formula currently used in the RNS UD and by NetQB sometimes gives values over 100% as the counter in denominator and numerator are from different object types. Using the counter TCASSAL in the numerator solves this problem. Actually the counter was introduced to solve the problem, but the formulas have not been updated.
Formula used to show subscriber perceived TCH congestion difficult to interpret on cell level
The current formula used to show TCH assignment success rate and subscriber perceived TCH congestion ((CNRELCONG+TxNRELCONG+TxNRELCONGSUB)/TASSALL) is difficult to interpret on cell level as TASSALL is incremented in the target cell for successful establishments but in the serving cell is it fails.
To give a better view of the grade of service in the area covered by the cell outgoing handovers during assignment should be added and incoming handovers during assignment should be subtracted.
Difficult to measure integrity for streaming users
With the counters at hand today it is difficult to see the number of streaming session that suffer from bad quality due to low throughput.
The throughput measurements for streaming that related to the GBR are an average over the whole cell and as connections that have good radio conditions will have a throughput is significantly higher than the GBR, the average throughput does not show how many connection that did not meet the GBR.
This could be solved by introducing new counters that indicate a degraded service for the streaming users, e.g. by measuring the number of user that did not meet the GBR or where a transfer delay was induce by BSS as the data could not be scheduled fast enough due to low throughput.
6 Abbreviations
ABQPAggregate BSS QoS Profile
AGCHAccess Grant Channel
AMRAdaptive Multi Rate
BUGSBusiness Unit Global Services
CSCircuit Switched
DTMDual Transfer Mode
GBRGuaranteed Bit rate
GETEPGPRS End-to-End Performance
EIT Ericsson Instant Talk
KPIKey Performance Indicator
LQCLink Quality Control
LLCLogical Link Control
MSMobile Station
MPDCHMaster Packet Data Channel
PDUPacket Data Unit
PRACHPacket Random Access Channel
PSPacket Switched
QoS Quality of Service
RACHRandom Access Channel
SQISpeech Quality Index
TBFTemporary Block Flow
7 References
1. Radio Network StatisticsUser Description62/1555-HSC 103 12/4 Uen
2. NetQB and quality benchmarking web sitehttp://netqb.lmc.ericsson.se/netqb/3. BSC STS User-formulas, Ericsson GSM system R9.1EAB/GRE/SNI-03:0724. BSS R9.1/R10 NAED Performance evaluation6/152 83-100/FCP 103 3486/35. Assignment Specification, Definition of BSS Radio Network KPI9/12261-100/FCP1034511 Uen6. ITU-T Recommendation E.8007. GPRS End-to-End Performance (GETEP) web site http://eed.ericsson.se/CNIV/s-g/organisation/groups/gx/GETEP/8. User Description, GPRS/EGPRS Quality of Service94/1553-HSC 103 12/4 Uen9. SDM, BSD DB DescriptionDatabase Description2/198 18-APR 901 011 Uen
10. User Description, GSM-UMTS Cell Reselection and Handover93/1553-HSC 103 12/4
11. User Description, Speech Quality Supervision53/1553-HSC 103 12/4
Appendix A Object Types per KPI
The table below shows which object types that need to be collected to create the KPIs in this document. If not otherwise explicitly stated they are valid for both R10 and R11.
KPIObject Types
Random access success rateRANDOMACC, CELLGPRS
SDCCH time congestionCLSDCCH, CLSDCCHO
SDCCH drop rateCLSDCCH, CLSDCCHO
TCH assignment success rateCLTCH
TCH drop rateCELTCHF, CELTCHH, NCELLREL, NECELLREL, NICELASS, NECELASS
Call minutes per dropCELTCHF, CELTCHH
Handover success rateNCELLREL, NECELLREL,
Handover lost rateNCELLREL, NECELLREL,
Speech qualityCELLSQI
GSM to UTRAN Handover success rateNUCELLRELCNT
GSM to UTRAN Handover lost rateNUCELLRELCNT
TCH traffic CELTCHF, CELTCHH
SDCCH Traffic CLSDCCH
IP Transfer interrupts uplinkR10: CELLGPRS2, TRAFULGPRSR11: CELLGPRS2, CLDTMPER, TRAFULGPRS
IP Transfer interrupts downlinkR10: CELLGPRS2,TRAFDLGPRSR11: CELLGPRS2, CLDTMPER, TRAFDLGPRS
GPRS AvailibilityR11: CELLGPRS3
IP LatencyR11: CELLGPRS3
IP Throughput GPRSCELLQOSG
IP Throughput EGPRSCELLQOSEG
QoS NegotiationsCLQOSCON, CLQOSCON2
EIT Transfer delay uplinkCELLEIT
EIT Transfer delay downlinkCELLEIT
DTM IP Transfer interrupts uplinkCLDTMPER
DTM IP Transfer interrupts downlinkCLDTMPER
DTM IP Throughput uplinkCLDTMQOS
DTM IP Throughput downlinkCLDTMQOS
IP User data volume uplinkR10: CELLQOSG, CELLQOSEG, CELLQOSSR11: CELLGPRS3, CLDTMQOS, CELLQOSS, CELLEIT2
IP User data volume downlinkR10: CELLQOSG, CELLQOSEG, CELLQOSSR11: CELLGPRS3
Response IP packet
Request IP packet
BSS IP Latency
MS
SGSN
PCU
_1144062468.unknown
_1144655788.unknown
_1146991990.unknown
_1147844494.unknown
_1246979451.unknown
_1146992286.unknown
_1147843387.unknown
_1146992102.unknown
_1146991121.unknown
_1146991136.unknown
_1144670217.unknown
_1144670238.unknown
_1144671717.unknown
_1144669101.unknown
_1144062802.unknown
_1144062979.unknown
_1144063257.unknown
_1144063299.unknown
_1144063413.unknown
_1144583670.unknown
_1144063412.unknown
_1144063280.unknown
_1144063204.unknown
_1144063255.unknown
_1144062838.unknown
_1144062967.unknown
_1144062966.unknown
_1144062810.unknown
_1144062607.unknown
_1144062743.unknown
_1144062606.unknown
_1144062272.unknown
_1144062337.unknown
_1144062415.unknown
_1144062299.unknown
_1144061988.unknown
_1144062032.unknown
_1144061963.unknown