BSS+R8+GPRS+Counter+Descriptions+E

Commercial In Confidence

1 (14)Prepared (also subject responsible if other) No.

SV/NKM Neil Stobie SV/N Erik Westerberg ERA/SV-01:1680 Uen Approved Checked Date Rev Reference

ERA/RN/NKM [Joakim Westerberg] 2002-02-07 E

BSS R8 GPRS Counter Descriptions

Abstract

This document describes in detail how the GPRS STS counters in BSS are stepped in BSS R8. A detailed flow graph of the PDCH allocation process illustrates when the PDCH allocation related counters are stepped. The sampling of PDCH usage and the stepping of the corresponding counters are described in detail. The remaining GPRS BSS counters are listed and described in separate sections. In addition a set of user formulas is given to construct potential Key Performance Indicators from the basic STS counters.





Table of Contents

1 Revision History 3 2 Introduction 3 3 References 3 4 Counter overview 4

4.1 PDCH allocation and pre-emption 4 4.2 PDCH Usage 4 4.3 Random Accesses 4 4.4 Traffic Volume and Retransmission Rates 4 4.5 Transmission between the PCU and the CCU 4

5 Detailed Counter Descriptions 5 5.1 PDCH allocation and pre-emption 5

5.1.1 The PDCH allocation process 5 5.1.2 PDCH allocation and pre-emption counters 8

5.2 PDCH Usage 9 5.3 Random Accesses 10 5.4 Traffic Volume and Retransmission Rates 12

5.4.1 Counter Descriptions 12 5.4.2 User Formulae 13

5.5 Transmission between the PCU and the CCU 14





1 Revision History

Rev Date Description

A 2001-07-26 Created

B 2001-08-01 Small comment added to section on RETRANSDL regarding retransmissions in new TBFs.

C 2001-10-03 Some parts of the Rev B document were not up to date for the AC-A6 correction package. The descriptions of DISCUL,

and RETRANSDL have been updated.

Also in Rev B it was thought that the RBCUL counter had been corrected to work in the same way as RBCDL. This was not in fact the case (even after AC-A6). The counter

descriptions and associated formulae have been corrected.

D 2002-02-07 Internal references taken away. Classification changed to Commercial in Confidence

2 Introduction

This purpose of this document is to give an overview of how some of the GPRS counters, introduced in BSS R8, function.

Note that this document is not an exhaustive description of each and every GPRS counter, rather it concentrates on the counters where further documentation was felt to be necessary.

Also, the intention is that this document should only be used as a reference in the short term. The information contained here should go into an official customer document at some point in the near future. From that point on this document will not be updated.

The information is valid for BSS R8, including the Octoplus improvements and most recent CN-Is.

3 References

1. DocNo: 29/0360-46/FCP 103 1229/3, Title: Support for New GPRS Counters, Type: Report

2. DocNo: 4/155 17-CRT 240 06 Uen, Revision: B, Title: GPRS Channel Handling, Type: Function Specification

3. DocNo: 54/1553-HSC 103 12 Uen, Revision: E, Title: User Description, Channel Administration





4 Counter overview

The following counters are described in detail in the following section of this document. Again note that this is not a complete list of all the GPRS counters implemented in BSS R8.

4.1 PDCH allocation and pre-emption PCHALLATT Number of PDCH allocation attempts PCHALLFAIL Number of PDCH allocation attempt failures due

to no idle basic physical channels ALLPDCHPCUFAIL Number of PDCH allocation attempt failures due

to no GSL device in the PCU PREEMPTPDCH Number of pre-empted, active, PDCHs

4.2 PDCH Usage ALLPDCHACC Accumulated number of allocated PDCHs ALLPDCHACTACC Accumulated number of active PDCHs ALLPDCHSCAN Accumulated number of scans of ALLPDCHACC

and ALLPDCHACTACC ALLPDCHPEAK The largest number of simultaneously active

PDCHs during the last 15 minutes

4.3 Random Accesses PDRAC Number of Packet Random Access Messages

received in the PCU originating from access bursts on the CCCH

PDPRAC Number of Packet Random Access Messages received in the PCU originating from access bursts on the PCCCH

4.4 Traffic Volume and Retransmission Rates RBCDL Number of RLC PDUs sent downlink RBCUL Number of RLC PDUs sent uplink RETRANSDL Number of retransmission RLC PDUs sent

downlink RETRANSUL Number of retransmission RLC PDUs sent uplink

4.5 Transmission between the PCU and the CCU DISCUL Number of discarded PCU frames downlink DISCDL Number of discarded PCU frames downlink





5 Detailed Counter Descriptions

5.1 PDCH allocation and pre-emption

Before the detailed counter description an overview of the PDCH allocation and pre-emption process is given below as an aid to understanding.

5.1.1 The PDCH allocation process

PDCH allocation is handled by the software blocks RGRLC, RNLCT and RTGPHDEV residing in the CP, see figure 1. The blocks RGRLC and RTGPHDEV logically belong to the PCU. RNLCT is part of the BSC and controls how the basic physical channels are allocated for both circuit switched and packet switched traffic. While the execution of PDCH allocation is done in the CP, the initiation of PDCH allocation occurs outside the CP.

There are two basic reasons for a PDCH allocation attempt firstly when a dedicated PDCH is ordered and secondly when on-demand PDCHs are required. The allocation of one or more dedicated PDCHs is triggered by an operator-command that is forwarded to RGRLC. Allocation attempts for on-demand PDCHs are initiated by the block RGRLCR in the RPP. RGRLCR can request RGRLC for on-demand PDCHs for several reasons:

1. A PSET is required for the first TBF in the cell. The allocation attempt is made for this TBF.

2. The PDCH reservations for the GPRS MS do not match the multislot class. The allocation attempt is made for future TBFs.

3. The TBF limit is reached for all PDCHs in the PSET in the requested direction. The allocation attempt is made for future TBFs.

4. A PDCH reservation is performed above TBF limit. Note that BSS R8 has no access control so the TBF limits can be exceeded if no other resources are available. The allocation attempt is made for future TBFs.

In general the preference is to try to upgrade, i.e. add more PDCHs, to an existing PSET, before an attempting to allocate a new PSET. A more detailed description of why and when this occurs can be found in the Function Specification - GPRS Channel Handling, reference 2.

A request for allocation of one or more PDCHs triggers a set of signalling and processes in the PCU and the BSC. The result is either

- Allocation of one or more PDCHs (successful allocation PDCH attempt)

- No allocation of additional PDCHs (PDCH allocation failure)

The PDCH allocation procedure is depicted in the flow graph in figure 2. The signalling S1, S2, refers to figure 1.





S1

RTS

LOAS

RTGPHDEV

RCS

RGRLC

RNLCT

RCS

RGRLCR

Central Processor (CP)

Regional PCU Processor (RPP)

Figure 1a: Signal diagram for allocation of on-demand PDCHs

S2 S3

S4

S0

S5 S6

S7

S8

RGRLC

S1

A BC

S2

S0

S3

S4S5S6

S7

S8

Figure 1b: Signal diagram for allocation of on-demand PDCHs, focusing on the block RGRLC. The counters in RGRLC are ALLPDCHPCUFAIL (A), PCHALLATT (B), and PCHALLFAIL (C).





S1: A request for PDCHs is sent from RGRLCR to RGRLC. The request is either for upgrading a specified, existing, PSET in cell A or for an additional PSET in cell A.

S2: How many GSL devices are presently free in the RPP presently serving cell A? The inquiry is sent from RGRLC to RTGPHDEV.

S1: RGRLC receives a request for allocating one or more dedicated PDCHs

S3: RTGPHDEV responds to RGRLC with the number of free GSL devices in the RPP serving cell A.

RNLCT allocates zero or more PDCHs according to the request in S4. The result is sent to RGRLC in S5.

S6: RGRLC requests RTGPHDEV to set up through the group switch one GSL device for each PDCH reported allocated in S5.

In the RPP serving cell A RTGPHDEV sets up the requested number of GSL devices (or as many GSL devices the RPP has free if these are fewer than the requested number of GSL devices). The result is sent to RGRLC in S7.

RGRLC requests RNLCT to de-allocate the PDCHs that did not get a GSL device.

The activated PDCHs are now ready to use.

Send message No PDCH allocated from RGRLC to RGRLCR.

Is the number of GSL devices sufficient to serve the PDCH

allocation request?

Is at least one PDCH allocated by

RNLCT?

Is at least one of the PDCHs reported allocated in S5 still

allocated as PDCH?

Is the CP load too high to service the PDCH

allocation request?

Did every

PDCH reported allocated in S5 get one

GSL device?

Stop

Yes

No Yes

No

Yes

No

PCHALLATT += 1

PDCHALLFAIL += 1

ALLPDCHPCUFAIL += 1

RGRLC marks the allocated PDCHs as PDCH.

No

Yes

S8: A response message containing information about the allocated PDCHs is sent from RGRLC to RGRLCR in the RPP.

Via the sub-system RTS RGRLC sends a channel activation message to the BTS and also instructs the RPP to synchronize the allocated PDCHs to the CCU. After completion this is confirmed by the BTS and the PCU to RGRLC.

S4: The request in S1 is forwarded from RGRLC to RNLCT. No

No

Yes

Yes

Initiate the process Move Cell To Other RPP in RTGPHDEV.

Is the allocation

attempt for a dedicated PDCH?

Figure 2: Flow graph for PDCH allocation, including relevant PDCH allocation counters. Thesignalling S1, S2, refers to figure 1.





Comments to the flow graph, figure 2.

- The PDCH allocation attempt is continued with S4 regardless of the number of free GSL device reported in S3.

- The process Move cell to other RPP is not fast enough to free up GSL devices to benefit the on-going PDCH allocation attempt. Hence the number of GSL devices available at the request S6 equals the number of free GSL devices reported in S3. In particular, if there is a shortage of GSL devices reported in S3 (so that ALLPDCHPCUFAIL is stepped) the shortage persists to the actual allocation of GSL devices, S6/S7 unless by chance a GSL device has become available in the RPP thanks to expiration of the PILTIMER.

- The counter ALLPDCHPCUFAIL is stepped when there is a GSL-device shortage in the RPP rather than an overall shortage in the PCU. However, from the view of the ongoing PDCH allocation attempt the request cannot be fully served because of insufficient GSL device availability.

5.1.2 PDCH allocation and pre-emption counters

Counter: PCHALLATT Measured: Per Cell

Description: This counter is stepped each time the BSC attempts to allocate a set of one or more PDCHs from the circuit switched domain. The counter is stepped when signal S4 is forwarded to software block RNLCT as described above.

Counter: PCHALLFAIL Measured: Per Cell

Description: The counter is stepped when a PDCH allocation attempts fails due to no basic physical channel available in the cell. An attempt to allocate a set of PDCHs from the circuit switched domain is only deemed to be a failure when no (zero) PDCHs could be allocated.

Counter: ALLPDCHPCUFAIL Measured: Per PCU/BSC

Description: Before any PDCHs are added in a cell a check is made to see if it possible to add more PDCHs to the RPP. The counter is stepped if the RPP could not handle the request. For example 4 GSL devices were requested but only 3 GSL devices are available for use in the RPP.

Note: If in one PDCH allocation attempt there is both a shortage of GSL devices and no BPC available in the circuit switched domain, both PCHALLFAIL and ALLPDCHPCUFAIL are stepped.

Counter: PREEMPTPDCH Measured: Per Cell





Description: The total number of PDCHs pre-empted during the measurement period. Only incremented if the PDCH was active, meaning carrying one or more TBFs (UL or DL).

Pre-emption is affected by the GPRSPRIO setting. How this functions is described in the User Description Channel Administration, reference 3.

5.2 PDCH Usage

See figure 3 for an overview of the mechanism of the PDCH usage counters.

Counter: ALLPDCHACC Measured: Per Cell

Description: Accumulated number of allocated PDCHs. Divide by ALLPDCHSCAN to get the average number of allocated PDCHs during the measurement period.

Every 10 seconds the cell is scanned and the number of PDCHs recorded and added to an accumulator. This is done within the CP. The counter ALLPDCHACC reported by STS is the increase in this accumulator during the measurement period.

Counter: ALLPDCHACTACC Measured: Per Cell

Description: Accumulated number of active PDCHs. Divide by ALLPDCHSCAN to get the average number of active PDCHs during the measurement period.

Every 10 seconds the cell is scanned and the number of active PDCHs added to an accumulator. This is done in the RPP since only the RPP knows which PDCHs are active. Every 60 seconds the value in the accumulator is divided by the number of scans performed by the RPP, during those 60 seconds, and passed to the CP.

This average value is multiplied by the number of scans performed by the CP since the last average was received from the RPP. This is done in order to synchronise with ALLPDCHSCAN. The counter ALLPDCHACTACC reported by STS is the accumulation of these values during the measurement period. An active PDCH is defined as a PDCH carrying one or more TBFs (UL or DL)

Counter: ALLPDCHSCAN Measured: Per Cell

Description: Number of scans taken within the CP during the measurement period. A scan is taken once every 10 seconds.

Counter: ALLPDCHPEAK Measured: Per Cell





Description: The peak number of active PDCHs from the last 15 minutes. Every 60 seconds the highest value for the number of active PDCHs, from the 6 or so scans taken in the RPP, is written to one position in a circular store of 15 values. Also every 60 seconds, the highest value from this store of 15 values is sent to and stored in the CP. This value is ALLPDCHPEAK.

If the measurement period for STS is 1 hour then the value reported will be the peak from the latest 15 minutes. The 45 minutes prior to this are not considered.

5.3 Random Accesses

Counter: PDRAC Measured: Per Cell

Description: Incremented once for each Packet Channel Request Message, originating from a set of random access bursts on RACH, successfully received by the PCU from the BSC.

Counter: PDPRAC Measured: Per Cell

Description: Incremented once for each Packet Channel Request Message, originating from a set of random access bursts on PRACH, successfully received by the PCU from the BTS.

Note: Noise, interference and weak random access bursts from mobiles in distant cells can give rise to false Packet Channel Request Messages. E.g., a random access burst signaling the request to set up a CS call can, due to interference, be interpreted by the BTS as a Packet Channel Request Message. In this case the BTS forwards the Packet Channel Request Message to the PCU via the BSC. Though of no harm to the radio network performance, such false Packet Channel Requests Messages are still counted by PDRAC and PDPRAC. E.g., even cells with no registered GPRS traffic can measure a non-zero number of Packet Channel Request Messages.





Divides by # of RPP scans during last minute

Active PDCH Accumulator =

Multiplies by # of CP scans since previous value reported

1 minute

5

5

+5

10

+ 5

15

+8

23

+8

31

+7

38

+7

7

+

Scan

Scan

Scan

Scan

Scan

Scan

Scan

Number of Active PDCHs =

30

+

Scan

8

Active PDCH Accumulator cleared

4

404

+4

408

+4

412

+8

420

+8

428

+7

435

+7

442

+

Scan

Scan

Scan

Scan

Scan

Scan

Scan

400

+

Scan

6

ALLPDCHACTACC=Accumulation of these results during measurement period

ALLPDCHACC= Increase in PDCH accumulator duringmeasurement period

Number of PDCHs =

PDCH Accumulator =

ALLPDCHSCAN= Number of CP scans during measurement period

RPP takes value of Active PDCH accumulator

Divides by # of RPP scans during last minute

Multiplies by # of CP scans since previous value reported

Active PDCH Accumulator cleared

RPP takes value of Active PDCH accumulator

Figure 3: Overview of the sampling of the PDCH usage counters





5.4 Traffic Volume and Retransmission Rates

5.4.1 Counter Descriptions

Counter: RBCDL Measured: Per Cell

Description: The total number of RLC data blocks transmitted by the PCU during the measurement period. Retransmissions are included. MAC signalling blocks are not included.

The RLC data blocks contain either user data or signalling above RLC/MAC level (for example PDP Context Activation, Mobility Management signalling etc). This type of signalling requires a TBF.

MAC signalling blocks are used by BSS to establish, maintain and release TBFs and are not counted by RBCDL.

Counter: RETRANSDL Measured: Per Cell

Description: The total number of RLC data blocks retransmitted by the PCU during the measurement period. This is usually in response to a NACK in the acknowledgement bitmap.

In the latest versions of BSS R8 intentional retransmissions, up to 3 repeats of the last radio block in the TBF, are sent to allow an uplink TBF set-up while the downlink is closing. These intentional retransmissions are not counted by RETRANSDL (if correction package AC-A6 loaded).

Note that data retransmitted in a new TBF is not counted. For example, on cell reselection any unacknowledged LLC frames are transferred to the transmission buffer in the new cell.

Counter: RBCUL Measured: Per Cell

Description: The total number of first time transmitted RLC data blocks successfully received by the PCU during the measurement period plus the number of retransmitted blocks (calculated as described below).

The RLC data blocks contain either user data or signalling above RLC/MAC level (for example PDP Context Activation, Mobility Management signalling etc). This type of signalling requires a TBF.

MAC signalling blocks are used by BSS to establish, maintain and release TBFs and are not counted by RBCUL.

Note that RLC data blocks with stall indicator set are not counted (if correction package AC-A6 loaded).





Counter: RETRANSUL Measured: Per Cell

Description: The total number of RLC data blocks retransmitted by the GPRS MS during the measurement period.

Some estimation must be done in calculating this counter. This is because the PCU knows that a radio block has gone missing but not how many times the GPRS MS may have tried to re-send this block. The estimation is done at the end of each TBF and it is assumed that retransmitted blocks are lost in the same ratio as those transmitted for the first time.

For example say 100 blocks have been sent in a TBF. If 80 of those were successfully received on the first time transmission then the number of retransmitted blocks for the TBF is estimated to be 20+4+0.8+0.16 etc.

5.4.2 User Formulae

Block Error Rate (BLER)

The BLock Error Ratio (BLER) for DL and UL are calculated as below.

Average radio-link quality (kbps/PDCH)

The average radio-link quality tells what is the user-data rate (defined as RLC PDU payload data per second) one PDCH can carry.

The factor CODING_BITRATE is 8 kbps if CS-1 is used and 12 kbps if CS-2 is used for RLC PDUs in the BSC area.

Data volume

From the number of first-time transmissions and the coding scheme used the number of RLC PDU payload octets (Bytes) transferred UL and DL can be measured.

[ ]

[ ]%100*_

%100*_

RETRANSULRBCULRETRANSULULBLER

RBCDLRETRANSDLDLBLER

+=

=

[ ]

[ ]ULBLERBITRATECODINGULBITRATEPDCH

DLBLERBITRATECODINGDLBITRATEPDCH

_1___

_1___

=

=





As described previously the payload octets can be user data or higher-level signalling. However, there may also be spare octets in case where the last LLC PDU in a transfer does not completely fill the last RLC PDU. In most cells however the vast majority of the Payload Octets will be User Data. In such cells the user data transferred can for practical purposes be taken to be the number of LLC PDU octets (Bytes).

5.5 Transmission between the PCU and the CCU

Counter: DISCDL Measured: Per Cell

Description: Incremented each time an error is detected on a PCU frame on the downlink. An error can be DL block error.

Counter: DISCUL Measured: Per Cell

Description: Incremented each time an error is detected on a PCU frame on the uplink. An error can be lost UL message, CRC error on GSL interface, parity error in E bits or unexpected frame.

Note that prior to correction package AC-A6 the number of CRC errors on the air interface were also counted. However, CRC errors can occur normally when there is downlink traffic but no uplink traffic. These are not now counted as it resulted in unusally high values for the counter.

[ ]

[ ]8

20___

820___

msBITRATECODINGRBCULULPAYLOADRLC

msBITRATECODINGRETRANSDLRBCDLDLPAYLOADRLC

=

=

Documents

BSS+R8+GPRS+Counter+Descriptions+E