BSS R8 GPRS Counter Descriptions: Prepared (Also Subject Responsible If Other) No

Commercial In Confidence
1 (14)
Prepared (also subject responsible if other)
No.
SV/NKM Neil Stobie SV/N Erik Westerberg

Approved
Checked
ERA/RN/NKM [Joakim Westerberg]
ERA/SV-01:1680 Uen
Date
Rev
2002-02-07
Reference
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.
2 (14)
No.

Approved
Checked
ERA/SV-01:1680 Uen
Date
Rev
2002-02-07
Reference
Table of Contents
1
2
3
4
4.1
4.2
4.3
4.4
4.5
5
5.1
5.2
5.3
5.4
5.5
Revision History
Introduction
References
Counter overview
PDCH allocation and pre-emption
PDCH Usage
Random Accesses
Traffic Volume and Retransmission Rates
Transmission between the PCU and the CCU
Detailed Counter Descriptions
5.1.1
The PDCH allocation process
5.1.2
PDCH allocation and pre-emption counters
PDCH Usage
Random Accesses
5.4.1
Counter Descriptions
5.4.2
User Formulae
3
3
3
4
4
4
4
4
4
5
5
5
8
9
10
12
12
13
14
3 (14)
No.

Approved
ERA/SV-01:1680 Uen
Checked
Date
Rev
2002-02-07
Reference
Revision History
Rev
Date
Description
2001-07-26
Created
2001-08-01
Small comment added to section on RETRANSDL regarding

retransmissions in new TBFs.
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.
2002-02-07
Internal references taken away. Classification changed to

Commercial in Confidence
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.
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 (14)
No.

Approved
Checked
ERA/SV-01:1680 Uen
Date
Rev
2002-02-07
Reference
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
4.2
4.3
4.4
4.5

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
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
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

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

DISCUL
Number of discarded PCU frames downlink
DISCDL
Number of discarded PCU frames downlink
5 (14)
No.

Approved
Checked
ERA/SV-01:1680 Uen
Date
Rev
2002-02-07
Detailed Counter Descriptions
5.1
Reference
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 ondemand 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.
6 (14)
No.

Approved
ERA/SV-01:1680 Uen
Checked
Date
Rev
2002-02-07
Reference
Figure 1a: Signal diagram for allocation of on-demand PDCHs
RCS
RTS
S7
RNLCT
S5
S6
S4
S3
RTGPHDEV
S2
LOAS
RGRLC
S0
Central Processor (CP)
S8
RCS
Regional PCU
Processor (RPP)
S1
RGRLCR
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).
S5
S7
S4
S6
C
S3
B
A
RGRLC
S2
S0
S8
S1
7 (14)
No.

Approved
ERA/SV-01:1680 Uen
Checked
Date
Rev
2002-02-07
Reference
Figure 2: Flow graph for PDCH allocation, including relevant PDCH allocation counters. The
signalling S1, S2, refers to figure 1.
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.
S1: RGRLC receives a request for

allocating one or more dedicated PDCHs
Yes
Is the CP
load too high to service the PDCH
allocation request?
No
S2: How many GSL devices are
presently free in the RPP presently
serving cell A? The inquiry is sent from
RGRLC to RTGPHDEV.
S3: RTGPHDEV responds to RGRLC with the

number of free GSL devices in the RPP serving
cell A.
Yes
S4: The request in S1 is forwarded from

RGRLC to RNLCT.
No
PCHALLATT += 1
RNLCT allocates zero or more PDCHs
according to the request in S4. The
result is sent to RGRLC in S5.
Is the number of GSL

devices sufficient to serve the PDCH
allocation request?
No
Is the
allocation
attempt for a
dedicated
PDCH?
ALLPDCHPCUFAIL += 1
Initiate the process
Move Cell To
Other RPP in
RTGPHDEV.
Yes
No
PDCHALLFAIL += 1
Is at least
one PDCH allocated by
RNLCT?
Yes
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.
Yes
No
Is at least one of
the PDCHs reported allocated in S5 still
allocated as PDCH?
No
Yes
RGRLC requests RNLCT to

de-allocate the PDCHs that
did not get a GSL device.
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.
S8: A response message

containing information about the
allocated PDCHs is sent from
RGRLC to RGRLCR in the RPP.
RGRLC marks the allocated PDCHs as PDCH.

Send message No PDCH allocated
from RGRLC to RGRLCR.
Did every
PDCH reported
allocated in S5 get one
GSL device?
Stop
The activated PDCHs

are now ready to use.
8 (14)
No.

Approved
Checked
ERA/SV-01:1680 Uen
Date
Rev
2002-02-07
Reference
Comments to the flow graph, figure 2.
5.1.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.
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
9 (14)
No.

Approved
Checked
ERA/SV-01:1680 Uen
Date
Rev
2002-02-07
Reference
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
10 (14)
No.

Approved
Checked
ERA/SV-01:1680 Uen
Date
Rev
2002-02-07
Reference
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.
11 (14)
No.

Approved
ERA/SV-01:1680 Uen
Checked
Date
Rev
2002-02-07
Reference
Figure 3: Overview of the sampling of the PDCH usage counters
1 minute
Scan
15
Scan
8
+
7
+
23
7
+
31
38
RPP takes value

of Active PDCH
accumulator
Active PDCH
Accumulator
cleared
Divides by # of
RPP scans during
last minute
Active PDCH
Accumulator
cleared
Divides by # of
RPP scans during
last minute
Multiplies by # of CP
scans since previous
value reported
Scan
Scan
404
Scan
Scan
Scan
Scan
+
PDCH
Accumulator = 400
ALLPDCHACTACC=
Accumulation of
these results during
measurement period
Multiplies by # of CP
scans since previous
value reported
Scan
Scan
Number
of PDCHs =
Scan
8
+
10
RPP takes value

of Active PDCH
accumulator
5
+
30
Scan
+
Active PDCH
Accumulator =
Scan
Scan
Scan
Scan
Number of
Active PDCHs =
ALLPDCHSCAN=
Number of CP scans
during measurement
period
408
412
420
428
435
+
442
ALLPDCHACC=
Increase in PDCH
accumulator during
measurement
period
12 (14)
No.

Approved
Checked
ERA/SV-01:1680 Uen
Date
Rev
2002-02-07
5.4
5.4.1
Counter Descriptions
Counter:
RBCDL
Reference
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).
13 (14)
No.

Approved
ERA/SV-01:1680 Uen
Checked

Counter:
RETRANSUL
Date
Rev
2002-02-07
Reference
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.
BLER _ DL =
RETRANSDL
* 100[%]
RBCDL
BLER _ UL =
RETRANSUL
* 100[%]
RBCUL + RETRANSUL
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.
PDCH _ BITRATE _ DL = CODING _ BITRATE [1 BLER _ DL]

PDCH _ BITRATE _ UL = CODING _ BITRATE [1 BLER _ UL]
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.
14 (14)
No.

Approved
Checked
ERA/SV-01:1680 Uen
Date
Rev
2002-02-07
Reference
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).
RLC _ PAYLOAD _ DL = [RBCDL RETRANSDL]

RLC _ PAYLOAD _ UL = [RBCUL]
5.5
CODING _ BITRATE 20ms

8
CODING _ BITRATE 20ms

8

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.

BSS R8 GPRS Counter Descriptions: Prepared (Also Subject Responsible If Other) No

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

BSS R8 GPRS Counter Descriptions: Prepared (Also Subject Responsible If Other) No

Încărcat de

Drepturi de autor:

Formate disponibile

Commercial In Confidence

SV/NKM Neil Stobie SV/N Erik Westerberg

ERA/RN/NKM [Joakim Westerberg]