bss kpi and counters

52
Ericssonwide Internal TECHNICAL REPORT 1 (52) Prepared (also subject responsible if other) No. EAB/RJT/F Robert Gavel EAB/RJT-04:0048 Uen Approved Checked Date Rev Reference EAB/RJT/F [Robert Gavel] 2004-06-07 A Propsal for BSS Radio Network KPIs Abstract 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.

Upload: dgmateos

Post on 16-Dec-2015

249 views

Category:

Documents


21 download

DESCRIPTION

BSS KPI and Counters

TRANSCRIPT

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