Abstract GPRS/EDGE networks provide an opportunity for

operators to offer new services to their potential and existing

subscribers. Unlike circuit switched services, EGPRS services are
dependent on a multitude of factors to guarantee a timely content
delivery. To ensure that the contracted QoS is sustained, it is not
sufficient to overprovision resources. In addition, operators need
to have tools for monitoring the QoS experienced by diverse
packet flows in different network segments. This paper presents
theoretically, and confirms experimentally, a simple mechanism
to monitor throughput of distinct services across EGPRS
networks, which enables a proactive and timely supervision of
service level agreements and quality. The approach is based on
the treatment class concept, which maps services with different
performance requirements onto distinct QoS profiles. By means
of treatment classes, defined by a subset of the bearer attributes,
i.e. bit rates, priorities and traffic classes, it is possible to
formulate metrics to measure the performance of distinct services
within the network domains, without any visibility of the content
carried by upper layer protocols. Experimental results show good
agreement between throughput measurements in the network and
the corresponding measured values at the application layer in the
mobile terminals.
Index Terms Quality of Service, QoS monitoring, GPRS,
EDGE, service differentiation, performance management.
I. INTRODUCTION
eneral Packet Radio Service (GPRS) and Enhanced Data
Rates for Global Evolution (EDGE) networks support
service applications with diverse performance requirements.
Packet switched person-to-person services, content to person
and business services are becoming common public utilities,
and as such, must be monitored and provisioned separately to
provide quality of service (QoS) guarantees and ensure that the
agreed QoS is sustained. It is not sufficient to reserve network
resources, since QoS degradation is often unavoidable. Any
fault, change in traffic mix or volume, or incorrect parameter
setting of a network element, may result in the deterioration of
a contracted QoS in a so-called service level agreement (SLA)
or expected performance from a user perspective. A SLA is a
formal negotiated contract between two parties that establishes

D. Soldani is with Nokia Networks, System Technologies, P.O. Box 301,
FIN-00045 Nokia Group, FINLAND (phone: +358-50-3633527; fax: +358-
7180-30204; e-mail: david.soldani@ nokia.com).
N. Lokuge is with Nokia Networks, OS/Performance, P.O. Box 301, FIN-
00045 Nokia Group, FINLAND (e-mail: nilmini.lokuge@nokia.com).
A. Kuurne is with Nokia Networks, System Technologies, P.O. Box 301,
FIN-00045 Nokia Group, FINLAND (e-mail: antti.kuurne@ nokia.com).
committed levels of network and service performance and
responsiveness [1]. The two parties may be a consumer and an
operator, or two operators where one takes the customer-role
buying services from another service provider. Thus, QoS
monitoring is required to track the ongoing QoS, detect
possible quality deterioration, compare the monitored metrics
against the contacted performance and, accordingly, enable
operators to fine tune network resources to sustain the
delivered QoS.
Although delivered service performance is becoming a
major aspect of differentiation of service providers, little
material is available, either theoretical or experimental, to
describe how essential performance metrics can be measured
for a proactive management of an end-to-end GPRS service
performance. In [2], only the challenges involved in providing
QoS distribution monitoring were discussed, and the proposed
approaches to meet these challenges were far from any
practical cost-effective service assurance solution. A realistic
approach to end-to-end service assurance on the mobile
Internet was presented in [3]. Yet, only a management model
and architecture of the service performance management
system and related capabilities were introduced. In [4], Sonera
presented an interesting performance evaluation of their GPRS
network accomplished by a combination of measurements at
the end hosts and tracing user and control plane data at U
m

(radio interface), A
bis
(interface between the Base Station, BS,
and its Controller, BSC) and G
b
(interface between BSC and
Serving GPRS Support Node, SGSN). For throughput
measurements, they used tools generating bulk transfers over
TCP and dumped data at the end hosts. Ultimately,
standardization forums define QoS attributes and specify what
to measure, but not how to monitor the actual QoS
management functions in the user and control plane: This is
left to the vendor and operator's choice.
In this paper, we introduce the EGPRS packet data transfer
across the service access points (SAPs) of protocol entities
deployed into different network domains. The paper describes
how throughput can be measured by the base station
subsystem (BSS) and the classification of counters to assess
performance of protocols carrying application services through
the radio interface. As a part of this framework, we explain
theoretically, and validate in the laboratory, how performance
of EGPRS services can be assessed based on the treatment
class (TREC) concept. Our target is to provide means and
methods to monitor separately and in a cost-effective way
Service Performance Monitoring for EGPRS
Networks Based on Treatment Classes
David Soldani, Nilmini Lokuge and Antti Kuurne
G

higher layer application services, without tracing or explicitly
disclosing the characteristics of upper layer protocols by
means of any tool or protocol entity. The throughput collected
by the base station subsystem (BSS) provides an essential
input to ensure quality compliance to service layer
management commitments.
Section II describes the packet data transfer across EGPRS
networks. Section III and IV define the TREC concept, and
how throughput of distinct services can be monitored by
means of TRECs. Section V presents our test network and
discusses measurement results to validate the accuracy of the
proposed performance indicators. Conclusions are drawn in
Section VI.
II. PACKET DATA TRANSFER IN EGPRS NETWORKS
The section introduces the end-to-end EGPRS packet data
transmission and protocols used to carry user plane application
data. Our target is to explain the mapping between SAPs of
protocols and the information available in the network
elements to classify performance counters and indicators
during the measurements. Such identifiers will allow the
network management system (NMS) to monitor services based
on treatment classes. Besides this, we describe the deployed
QoS management functions in the BSS for QoS differentiation.
This is needed to understand the added values provided by the
proposed monitoring solution to assess performance of distinct
services offered with different priorities, as well as to analyze
the measurement results discussed in Section V. More
information on the topics covered in this section can be found
in [5]-[14].
A. EGPRS Packet Data Transmission
The user plane protocol stack is depicted in Fig. 1. The
numbers in the figure define the SAPs between protocol layers
where the corresponding performance can be assessed. In the
BSS, we have broken the protocol stack to show how the
different entities may be deployed in the radio access network.
The channel codec unit (CCU), i.e. the layer 1 functions, is in
the base transceiver station (BTS) and the GSM packet control
unit (PCU), i.e. medium access control (MAC) and radio link
control (RLC) functions, is deployed in the base station
controller (BSC) [8].
The sub network dependent convergence protocol (SNDCP)
minimizes the transfer of redundant control information (e.g.
TCP/IP header) and user data between the SGSN and MS
through compression techniques. SNDCP multiplexes N-PDUs
(protocol data units) from one or several NSAPIs (network
service access point identifiers) onto one LLC (logical link
control protocol) SAPI. NSAPIs multiplexed onto the same
SAPI must use the same radio priority level, QoS traffic
handling priority, and traffic class. The output of the
compression sub-functions are segmented (reassembled) to
LLC frames of maximum length (to SNDCP packets) [8].

Relay
Network
Service
GTP-U
Application
IP
SNDCP
LLC
RLC
MAC
GSM RF
SNDCP
LLC
BSSGP
L1bis
RLC
MAC
GSM RF
BSSGP
L1bis
Relay
L2
L1
IP
L2
L1
IP
GTP-U
IP
Um Gb Gn Gi
MS BSS SGSN GGSN
Network
Service
UDP UDP
BSC
BTS
10 11
12 13
0 1
2 3
6
4 5
7 8 9

Fig. 1. User plane protocol stack.
LLC permits the information transfer between the SGSN
and one or more MSs using the same physical radio resources
with different service criteria. An LLC connection is identified
by a Data Link Connection Identifier (DLCI), which consists
of a SAP Identifier (SAPI), to identify the service access point
on the SGSN side and the MS side of the LLC interface, and
the MS's Temporary Logical Link Identifier (TLLI), to identify
a specific MS. The LLC protocol supports acknowledged,
unacknowledged and ciphering type of operations. The LLC
frames are multiplexed onto BSS Virtual Connections [9].
RLC functions are: Segmentation of LLC PDUs into RLC
data blocks and reassembly of RLC data blocks into LLC
PDU; segmentation of RLC/MAC control messages into
RLC/MAC control blocks and reassembly of RLC/MAC
control messages from RLC/MAC control blocks; backward
error correction (BEC) enabling the selective retransmission of
RLC data blocks. An RLC data block transfer has a unique
Temporary Flow Identity (TFI), a set of physical data channels
(PDCHs) to be used for the downlink transfer; and optionally,
a TBF (Temporary Block Flow) starting time indication. A
TBF is comprised of two peer entities, which are the RLC
endpoints [10].
MAC enables multiple mobile stations to share a common
transmission medium, which may consist of several physical
channels. MAC may allow a mobile station to use several
physical channels in parallel, i.e. use several timeslots within
the TDMA frame [10].
The interface between the SGSN and BSS (denoted by Gb
in Fig. 1) allows many users to be multiplexed over a common
physical resource. The communication between BSS GPRS
protocol (BSSGP) entities is based on BSSGP Virtual
Connections (BVCs). Each BVC is used in the transport of
BSSGP PDUs between: Peer point-to-point (PTP) functional
entities; peer point-to-multipoint (PTM) functional entities,
and peer signaling functional entities. There is a one PTP
functional entity per cell, which is identified by a BSSGP
Virtual Connection Identifier (BVCI). Each BVC is identified
by means of a BVCI, which has end-to-end significance across
the Gb interface. Each BVCI is unique between two peer
network service entities (NSEs). The identifier of the network
service entity (NSEI), together with the BVCI, uniquely
identifies a BSGP Virtual Connection (e.g. a PTP functional
entity) within an SGSN. The NSEI is used by the BSS and the
SGSN to determine the NS-VCs that provides service to a
BVCI. In the downlink, the SGSN includes the IMSI (or TLLI)

in the PDU and makes available to BSS: MS Radio Access
Capability; QoS Profile (peak bit rate, type of BSSGP SDU
(signaling or data), type of LLC frame (ACK, NACK, or not),
Precedence Class (1,2,3), and transmission mode to be used
when transmitting the LLC-PDU across the radio interface, i.e.
acknowledged (using RLC/MAC ARQ functionality) or
unacknowledged (using RLC/MAC unit data functionality). In
the uplink the BSS provides the TLLI, received from the MS,
negotiated QoS Profile (peak bit rate, the precedence used at
radio access and the Tx mode used across the radio path) to the
SGSN, which obtains the BVCI and NSEI from underlying
network service [11], [12].
In packet idle mode, no TBFs exist; the upper layers can
require the transfer of a LLC PDU that, implicitly, may trigger
the establishment of TBF and transition to packet transfer
mode. MS listens to the broadcast channel and to the paging
sub-channel for the paging group the MS belongs to in idle
mode. In packet transfer mode, the MS is allocated radio
resources providing a TBF on one or more physical channels.
Concurrent TBFs may be established in opposite directions so
that the transfer of LLC PDUs in RLC acknowledged or RLC
unacknowledged mode is provided. When selecting a new cell,
mobile station leaves the packet transfer mode, reads the
system information and enters the packet idle mode where it
switches to the new cell [6].
One Radio Block is by definition carried by four normal
bursts (20 ms). The MAC header is constant length, 8 bits,
whereas the RLC header is variable length. RLC data field
contains octets from one or more LLC PDUs. The Block
Check Sequence (BCS) is used for error detection [6].
In R98, four different coding schemes, i.e. CS-1, CS-2, CS-
3 and CS-4, are defined for the radio blocks carrying RLC data
blocks. CS-1 is as for SACCH, i.e. 1/2 convolutional code for
FEC and a 40 bit FIRE code for BCS; CS-2 and CS-3 are
punctured versions of CS-1 for FEC. CS-4 has no FEC. CS-2
to CS-4 use the same 16 bit CRC for BCS over the whole
uncoded RLC Data Block. Table I summarizes the channel
coding for PDTCH [6].
In R99, the radio block structure for user data transfer is
different for GPRS and EGPRS. For EGPRS, a Radio Block
(four normal bursts, 20ms) for data transfer consists of one
RLC/MAC header and one or two RLC Data Blocks. The
interleaving depends on the Modulation and Coding Scheme
(MCS) used. Nine different modulation and coding schemes,
MCS-1 to MCS-9, are defined for the EGPRS Radio Blocks
carrying RLC data blocks. For all EGPRS packet control
channels the corresponding GPRS control channel coding is
used. The details of the EGPRS coding schemes are shown in
Table II. Transmission and reception data flows are the same
for GPRS and EGPRS, except for EGPRS MCS-9, 8 and 7,
where four normal bursts are used to carry two RLC blocks
(one RLC block within two bursts for MCS-9 and 8) [13].



TABLE I
CHANNEL CODING FOR PDTCH
Scheme Code rate Radio block size
(Bytes)
Data rate
(kb/s)
Data rate excluding
RLC/MAC headers (kb/s)
CS-1 23 9.05 8
CS-2 2/3 34 13.4 12
CS-3 3/4 39 15.6 14.4
CS-4 1 54 21.4 20
TABLE II
CHANNEL CODING FOR PDTCH
Scheme Code
rate
Header
Code rate
Modulation RLC blocks
per Radio
Block
(20ms)
Raw Data
within one
Radio
Block
Data
rate
kb/s
MCS-9 1.0 0.36 2 2x592 59.2
MCS-8 0.92 0.36 2 2x544 54.4
MCS-7 0.76 0.36 2 2x448 44.8
MCS-6 0.49 1/3 1 592
48+544
29.6
27.2
MCS-5 0.37 1/3


8PSK
1 448 22.4
MCS-4 1.0 0.53 1 352 17.6
MCS-3 0.85 0.53 1 296
48+248
and 296
14.8
13.6
MCS-2 0.66 0.53 1 224 11.2
MCS-1 0.53 0.53


GMSK
1 176 8.8
NOTE: The italic captions indicate the 6 octets of padding when retransmitting
an MCS-8 block with MCS-3 or MCS-6. For MCS-3, the 6 octets of padding
are sent every second block (see [13]).
Ultimately, Fig. 2 summarizes the end-to-end packet data
transfer across the EGPRS network and the relevant
information stored and available in the MS, BBS, and packet
core network (CN). Besides this, Fig. 2 illustrates how the
network layer uniquely identifies the ongoing packets
belonging to distinct communications. As described in the
following sections, by means of such identifiers, it is possible
to classify measurements to assess the performance of the
carried applications based on the TREC concept.
B. QoS Differentiation in BSS
In the PCU, Packet Scheduler (PS) is an entity responsible
for deciding which TBF gets a transmission turn on each radio
block period. The implementation details of the PS algorithm
are not defined by the standardization bodies, but is left vendor
dependent. PS may or may not offer bit rate guarantees. If
some bit rate guarantees are given, there is usually an
admission control mechanism providing protection against
overload situations. In this work, we describe a simple PS
implementation solution that does not offer bit rate guarantees,
but is able to differentiate throughput (i.e. portion of received
transmission turns) according to the TBF priority.
The differentiation is based on the Allocation Retention
Priority (ARP) attribute, which has a value ranging from 1 to
3. (Note that there is a one to one mapping between ARP and
the R98 Precedence Class value, presented in the above
section, for network releases compatibility [7].) The value
ARP is listed in the QoS profile of the packet data protocol
(PDP) context.

Abis
BSC SGSN
BTS
CCU
CCU
Um
Gb
PCU
Packet-switching
Circuit-switching
Gn
GGSN
Packet-switching
MS
MS
One tunnel per PDP Context
(NSAPI, TLLI, TEID)
BSS Packet Flow Context (PFC)
( TLLI+SAPI(s)= DLCI(s) )
BSS Virtual Connections
(BVCI)
RR connection over one or
more PDCH(s)
( TS(s) )
Temporary Block Flow
(TBF)
( TFI)
PCU Frames
( 320b/20ms=16kb/s)
Radio Blocks on PDTCH
CS 1 CS 4 (GPRS)
MCS 1 MCS 9 (EGPRS)
(M-CS)
One BSS context per MS
BSS PFCs (PFIs)
Aggregate BSS QoS Profile(s)
One MM context per MS
PDP context(s)
QoS Profile(s)
Radio priority (UL)
PFI(s)
Aggregate BSS QoS Profile(s)
PDP context(s)
QoS Profile(s)
TFT(s)
One MM context
PDP context(s)
QoS Profile(s)
TFT(s)
Radio priority (UL)
PFI(s)

Fig. 2. EGPRS end-to-end data transmission.

A different instance of QoS profile exists for each IMSI
Access Point Name (APN) combination [8]. As QoS profile is
user specific, user differentiation in the radio interface is
possible based on groups of distinct PDP contexts. For
example, VIP subscriptions could be offered, where lower
ARP value is given to user and marked on the corresponding
QoS profile. But since APN can be chosen according to the
offered service, also service differentiation can be provided via
ARP values. Packet calls requesting for example a streaming
media content can be associated with an APN, within which all
users have high priority ARP value; correspondingly, with
other services the ARP value provides low priority. Since there
are three possible values for ARP, three distinct groups of
services can be formed between which differentiation in the air
interface is provided.
As described in the pervious section, BSC knows the ARP
value associated with each TBF. BSC also has an internal one-
to-one mapping from each of the three ARP values to a
parameter denoted by Scheduling Step Size (SSS). SSS value
of a TBF is used by PS to allocate the transmission turn of that
particular TBF in a weighted round-robin fashion among the
other TBFs. The inverse of the SSS value yields the scheduling
weight for each TBF. The lower the SSS value, the higher the
scheduling priority of the TBF in question. Hence, out of all
TBFs having data to transmit, the one with the lowest
scheduling priority value is allowed to transmit first. Each time
a TBF gets to transmit one radio block, its scheduling priority
is incremented by the SSS value corresponding to that TBF.
The following radio block will be then used by the TBF having
the smallest scheduling priority value. In our case, the SSS
ranges from 1 to 12. Thus, a TBF associated with a SSS value
of 3 would get to transmit four radio blocks during the period
that a TBF with SSS value of 12 transmitted only one radio
block. Hence, the throughput R
j
experienced by the TBF j in
one time slot (TSL) can be estimated by:
TSL
N
i i
j
j
R
SSS
SSS
R

=
=
1
1
1
,


(1)
where SSS
i
is the SSS value associated with the TBF i, N is the
total number of TBFs sharing the same TSL and RTSL is the
maximum bit rate the TSL in question can offer.
Equation (1) is only an approximation, since it ignores the
facts that due to different radio conditions some users need
more retransmissions than others, and that radio blocks may
contain different amount of user data depending on the used
modulation and coding scheme. In terms of scheduling, PS
considers each time slot independently. Thus, a TBF may get
to transmit more often on one slot than on the other due to
different number of users in both slots.
The spectral efficiency gains provided by the service
differentiation according to packet scheduling algorithm
described above were investigated in [14]. Three different
service types were offered in the network, i.e. video streaming,
Web browsing and MMS messaging. For each service, a user
satisfaction criterion based on throughput was defined.
Streaming, being a real time service, was deployed with the
highest possible priority, i.e. the SSS value for the bearer
carrying this service was set to 1. MMS traffic, being a typical
best-effort application without any particular QoS requirement,
was handled with lowest scheduling priority, i.e. MMS SSS
was set to 12. Conversely, the SSS value related to Web
browsing was varied from 4 to 9. Several combinations of
traffic mixes and number of dedicated GPRS time slots were
analyzed by means of dynamic simulations. It was found out
that the network with QoS differentiation activated, and the
SSS set to 1, 4, and 12, for video streaming, Web browsing
and MMS, respectively, at a given QoS (percentage of
satisfied users), could carry roughly the double load compared
to non-differentiated case, where all bearer services were

associated to the same SSS value.
Equation (1) is not sufficient for the network administrator
to assess the quality experienced by the users of the services
and to ensure that the contracted QoS is sustained. Hence, in
the following sections, we propose a more adequate tool for
monitoring throughout of the diverse packet flows in BSS.
III. DEFINITION OF TREATMENT CLASSES
In this section, we introduce the concept of performance
monitoring based on treatment classes (TRECs). The TREC of
a PDP context (bearer service) is defined based on a subset of
attributes of the subscribed QoS profile, i.e. Traffic Class
(TC), Traffic Handling Priority (THP) for Interactive class,
Allocation Retention Priority (ARP) and maximum bit rate [7].
On these grounds, differentiated treatment of bearer services
can be deployed in all network domains supporting PDP
contexts. In the BSS, the PCU may handle packet flows
differently by means of three priority queues (see Section II-
B). The packet flows are mapped onto the queues based on the
R97/R98 Precedence Class values, which correspond to the
R99 ARP attributes for GPRS-UMTS interworking [7]. In the
CN elements, the definition of TREC is based on the R97/98
Delay Class, which relate to the R99 TC and THP attributes
[7], [8]. Therefore, GGSN and SGSN may support 4 different
queues (Interactive THP1, THP2 and THP3, and background),
as illustrated in Fig. 3. (Note: Delay Class = 1 corresponds to
Interactive THP = 1, Delay Class = 2 corresponds to
Interactive THP = 2, Delay Class = 3 corresponds to
Interactive THP = 3 and Delay Class = 4 corresponds to TC =
Background. For consistent traffic treatment through the
mobile network, one needs to set ARP = THP = Precedence
Class = Delay Class. Background class (Delay Class = 4) is
mapped by the SGSN to ARP = Precedence Class = 3.).
Hence, without taking into account the bit rate attribute, 4
TRECs can be defined for legacy terminals. The practical
TREC definition and mapping of services onto TRECs is for
the operator to manage. In Fig. 4, we illustrate an example of 4
TRECs and a possible mapping of distinct services onto
different TRECs. Push to talk over Cellular (PoC) and See
What I See (SWIS) are novel real time services for cellular
networks [5]. They can be offered with the highest priority on
TREC 1 (Interactive class, THP=ARP=Precedence Class=1).
Audio and video streaming applications can be carried using
TREC 2 (Interactive class, THP=ARP=Precedence Class=2).
Corporate and Internet traffic can be offered with lower
priority on TREC 3 (Interactive class, THP=ARP=Precedence
Class=3) and TREC 4 (Background class, ARP=3),
respectively. In BSS, TREC 3 and 4 undergo the same
treatment (see Fig. 3).
To assess the carried applications, at the different network
elements, i.e. BSC, SGSN and GGSN, performance of bearer
services needs to be collected based on treatment classes. This
means that counters should be classified by the NEs with a
granularity that allows the NMS to make statistics based on
TRECs. This is possible, because the all attributes defining the
treatment classes of the bearer service in question are available
in the network elements, as described Section II. In Fig. 5, we
illustrate an example of how different counters collected by
SGSN and BSC can be classified to support the TREC based
monitoring of throughput by the management layer. The
classification of measurements by BSC and SGSN includes
attributes as Precedence Class and Delay Class that enable
NMS to filter out the indicators and compute throughput per
TREC as described in the following section, where the
differentiated throughput analysis is presented. From these
measured metrics, taking into account the one to one mapping
of applications onto distinct TRECs, it is possible for the
operator to draw conclusions upon the performance of each
provisioned service. However, if more applications (as for
example WAP and MMS in Fig. 4) are carried by the same
PDP context, or placed behind the same Access Point Name
(APN) for legacy terminal, i.e. mapped onto the same TREC,
the QoS monitoring of the services using this method it is not
possible, because only the overall performance of the bearer
service (traffic aggregate) would be assessed, and the integrity
of the different services can no longer be distinguished from
each other.
GGSN
BSC
BTS BTS
S
h
a
p
i
n
g

a
n
d

p
o
l
i
c
i
n
g
Background
Interacti ve 1
Interacti ve 2
Interacti ve 3
W
F
Q
S
c
h
e
d
u
l
e
r
S
h
a
p
i
n
g

a
n
d

p
o
l
i
c
i
n
g
Background
Interacti ve 1
Interacti ve 2
Interacti ve 3
W
F
Q
S
c
h
e
d
u
l
e
r
SGSN
ARP = 1
ARP = 2
ARP = 3
W
F
Q
TREC1
TREC2
TREC3
TREC4

Fig. 3. TRECs in BSS and Packet Core Network.




TREC1 Interactive TC, THP=ARP=1, Target bitrate EDGEUL8 kbit /s, DL30 kbit /s
Target bitrate GPRSUL8 kbit /s, DL20 kbit /s
TREC 2 Interactive TC, THP=ARP=2, Target bitrate EDGEUL20 kbit /s, DL30 kbit /s
Target bitrate GPRSUL10 kbit /s, DL20 kbit /s
TREC 3 Interactive TC, THP=ARP=3, Best effort (with some avg. bitrate targets)
TREC 4 Background TC, ARP=3, Best effort (with some avg. bitrate targets)
PoC
SWIS
Streaming
Corporates
Other operator services
Internet

Fig. 4. Example of TRECs definition and mapping of services onto TRECs.

BSC
Delivered RLC data blocks
-Classification (supporting TREC):
- Precedence class (1, 2, 3)
SGSN
Delivered BSSGP data blocks
-Classification (supporting TREC):
- Delay class (1, 2, 3, 4)
Collect classified counters
from NEs and compute
throughput per TREC for a
consistent performance
monitoring
TREC
- Definition
BSS throughput per TREC
SGSN throughput per TREC
Management layer
(Tools)
Network layer

Fig. 5. Example of how classified counters at the different NEs can be retrieved by the management layer to compute, consistently, throughput for a particular
treatment class (TREC).

IV. DIFFERENTIATED PERFORMANCE MONITORING
This section presents theoretically how throughput of
differentiated EGPRS services can be assessed through
counters collected and classified in BSS to support the TREC
concept.
A. Counters for QoS Monitoring
The essential counters to monitor throughput per cell and
treatment class in the BSS are: Correctly delivered RLC
blocks, duration of the corresponding TBFs, and measurement
period, denoted by S in the following. These indicators need to
be collected in uplink (UL) and downlink (DL) directions,
separately for GPRS and EDGE networks, and classified based
on (see Fig. 2):
RLC transmission mode (acknowledged,
unacknowledged);
EGDE modulation and coding schemes (MCS 1-9);
GPRS coding schemes (CS 1-4);
Precedence Class or Allocation Retention Priority (1-3);
Cell identifier (Cell ID) or BSS Virtual Connection
Identifier (BVCI).
From the above counters throughput per TREC can be
derived as described in the next section.
B. Differentiated Throughput Analysis
Let
k p
i
B
,
be the number of delivered RLC blocks (without
retransmissions) of the TBF i of duration
p
i
d , where p is the
treatment class, and k is the modulation and/or coding scheme
having thirteen possible values (CS-1, , CS-4, MCS-1, ,
MCS-9). The total correctly delivered bits
p
b and the related
duration
p
D for a particular treatment class p in a cell of the
EGPRS network (SAP 7 in Fig. 1), can be calculated as:

=

= =
= =
N
i
p
i
p
MCS
CS k
N
i
k p
i k
p
d D B r b
1
9
1 1
,
, ,

(2)
where the radio block size in bits without RLC header r
k

depends on the CS or MCS k of that particular TBF i, see
Table I and II, and N is the total number of TBFs collected by
the BSC in that particular cell during the measurement period
S. The average throughput per user in the cell in question
within the TREC p, from (2), is therefore:
p
p
p
D
b
t = ,

(3)
where p =1, 2 and 3, corresponds to the possible Precedence
Class values in the BSS.
Ultimately, for each TREC, the mean cell throughput
p
cell
t
can be derived from (2) by summing up all correctly delivered
GPRS and EGDE bits in the cell, over the monitored period S,
and dividing the attained value by S, i.e.
S
b
t
p
p
cell
= .
(4)

V. EXPERIMENTAL VALIDATION AND DISCUSSION
In this section, we compare the real end user throughput of
each treatment class to the corresponding values given by the
network using the performance indicators presented in Section
IV-B. For throughput testing, several FTP file transfers were
made between three mobile phones and a server connected
through a GPRS network. As a part of this framework, the
validity of (1) presented in Section II-B is also discussed.
A. Measurement Setup and Network Configuration
The laboratory setup is depicted in Fig. 6. As shown in the
figure, the measured network consisted of three mobile phones
(Nokia N8310, which supports 2+3 timeslots in UL and DL
respectively) and one base station connected to a FTP
application server through the GPRS packet core network, i.e.
SGSN and GGSN. For each FTP connection, the real end user
throughput was measured using a laptop computer (PC)
connected to the mobile station. In the PC, we used the
standard Windows Dos-prompt FTP application. In the BS,
only the 3 mobiles utilized the TRX with 3 TSLs available for
GPRS traffic. No other calls were allowed to the cell. Further,
only one FTP connection was established between each mobile
and the served placed behind the G
i
interface (see Fig. 1). The
counters, presented in Section IV-A, were collected in the
performance management (PM) database from the BSC over
one hour and the throughput derived by the NMS using (3).
Due to the good radio channel conditions in the laboratory,
only the coding scheme CS-2 for the radio blocks carrying
RLC data was used. The mobiles were mapped onto different
TRECs by setting R97/R98 distinct Precedence Class values in
the BSS and consistent Interactive THP and Background
traffic class setting in the core, as explained in Section III. The
validation was based on three different combinations of
mappings of TRECs onto SSS values. The lower the
Precedence Class value the higher the priority of the
corresponding TREC in the BSS queues.
B. Measurement Results and Discussion
For all connections, the FTP file size was held constant
(1048406 bytes) and only the downlink throughput was
collected. The bit rate estimates using (1), the indirect
measurement results by NMS using (3), and the corresponding
values dumped at the application layer by the FTP application
in the laptop connected to the terminals, as well as a
comparison of thereof, are reported in Table III. For the sake
of clarity, throughput results are also shown in Fig. 7-Fig. 9. In
Table III, we also calculated the ratio between the TREC i, i =
1, 2, and 3, throughput derived by NMS and the one attained
for TREC 3. This is needed to verify the influence of the SSS
value on the overall packet data transmission of each of the
monitored FTP connection. From the below values we can
conclude that the system worked as intended, i.e. as explained
in Section II-B.
By comparing the real throughput measured at the
application layer, denoted by nt (net throughput) in Table III,
with the data reported by NMS using (3), we can notice from
Table III and Fig. 7-Fig. 9 that there is a constant deviation
(error) between these values. This effect is due to upper layer
protocol headers, which is expected to be around the 10% of
the overall throughput [5]. Since such a bias can be removed
from the measured data, it does not compromise the accuracy
of the proposed method, which turns out to be sufficiently
accurate to ensure quality compliance to any service layer
management commitments.
As shown in Table III, and also visible in Fig. 7, Fig. 8 and
Fig. 9, (1) gives an estimate of the instantaneous throughput of
the FTP connection when all TBFs are simultaneously active.
Hence, it is not possible to derive from (1) the average
connection throughput over a longer period when the number
of users changes along with the corresponding TBF activities.
The usage of (1) to monitor the service performance in a live
network is therefore not feasible. However, (1) was correctly
applied in Case 3, where the number of TBFs was constant,
since each of the FTP connections lasted the same time.
BSC
GGSN
2G SGSN
BSC
GGSN
2G SGSN
Application
Servers
HLR HLR
PM Data Base
BSC
GGSN
2G SGSN
Application
Servers
Application
Servers
BTS
Phone 3
Phone 2
Phone 1
PM Data Base
Gi
NMS
FTP

Fig. 6. Measurement setup in the laboratory environment.



TABLE III
CHANNEL CODING FOR PDTCH

Case

TREC

SSS
NMS
(3)
(kb/s)
Laptop
(nt)
(kb/s)
Throughput
Ratio
(Ti/T3)
Error
(3) vs. (nt)
(%)
Theory
(1)
(kb/s)
Error
(1) vs. (3)
(%)
T1 3 19.33 17.62 1.6 10 19.64 2
T2 6 13.47 12.12 1.1 11 9.82 -27

1
T3 9 12.11 10.77 1.0 12 6.55 -46
T1 1 25.47 23.63 2.1 8 26 3
T2 4 14.34 12.94 1.2 11 6.55 -54

2
T3 8 12.18 10.78 1.0 13 3.27 -73
T1 1 12.02 10.77 1.0 12 12.00 0
T2 1 12 10.75 1.0 12 12.00 0

3
T3 1 12.06 10.75 1.0 12 12.00 0



0
5
10
15
20
25
30
T1 T2 T3
Treatment Class (TREC)
T
h
r
o
u
g
h
p
u
t

(
k
b
/
s
)
Case 1 - NMS
Case 1 - Laptop
Case 1 - Theory

Fig. 7. Case 1 Throughput results attained from NMS (blue diamond), laptop
(green circle) and using the formula presented in Section II-B (red triangle).


0
5
10
15
20
25
30
1 2 3
Treatment Class (TREC)
T
h
r
o
u
g
h
p
u
t

(
k
b
/
s
)
Case 2 - NMS
Case 2 - Laptop
Case 2 - Theory

Fig. 8. Case 2 Throughput results attained from NMS (blue diamond), laptop
(green circle) and using the formula presented in Section II-B (red triangle).
0
5
10
15
20
25
30
1 2 3
Treatment Class (TREC)
T
h
r
o
u
g
h
p
u
t

(
k
b
/
s
)
Case 3 - NMS
Case 3 - Laptop
Case 3 - Theory

Fig. 9. Case 3 Throughput results attained from NMS (blue diamond), laptop
(green circle) and using the formula presented in Section II-B (red triangle).
VI. CONCLUSION
Measuring throughput by means of treatment classes is a
promising technique for assessing performance of packet
switched services through GPRS/EDGE networks, without
tracing higher layer protocols at the different interfaces or
dumping data in the mobile terminals. The proposed solution,
in its simplicity, turns out to be sufficiently accurate for a
proactive and timely supervision of service level agreements
and quality in the bases station subsystem (BSS). Yet, its
application it is not limited to BSS, but it can be deployed in
any radio access and packet core networks supporting PDP
(packet data protocol) contexts.
ACKNOWLEDGMENT
We would like to acknowledge the valuable suggestions and
contributions of Erkka Ala-Tauriala, Outi Hiironniemi, and
Anneli Korteniemi working at Nokia Networks.
REFERENCES
[1] Tele Management Forum, SLA Management Handbook, v.1.5, June
2001.
[2] Y. Jiang, C. Tham and C. Ko, Providing quality of service monitoring:
Challenges and approaches, Network Operation and Management
Symposium, April 2000, IEEE/IFIP, pp. 115-128.
[3] R. Vukovic and J. Rdemar, Approach to E2E service assurance on the
mobile internet, Ericsson Review No. 3, 2001.
[4] A. Gurtov, M. Passoja, O. Aalto and M. Raitola, Multi-layer protocol
tracing in a GPRS network, IEEE VTC fall 2002, pp. 1612-1616, vol. 3.
[5] T. Halonen, J. Romero and J. Melero, (Editors), GSM, GPRS and EDGE
Performance, John Wiley & Sons, second edition, April 2003, 615 p.
[6] ETSI TS 101 350, Overall description of the GPRS radio interface;
Stage 2, GSM 03.64, v.7.1.0, R98.
[7] 3GPP TS 23.107, Quality of Service (QoS) concept and architecture,
v.3.9.0, R99.
[8] 3GPP TS 23.060, GPRS - Service description - Stage 2, v.3.15.0, R99.
[9] 3GPP TS 04.64, Logical Link Control (LLC) layer specification,
v.7.5.0, R98.
[10] 3GPP TS 04.60, Radio Link Control/Medium Access Control
(RLC/MAC), v.7.10.0, R98.
[11] 3GPP TS 08.18, BSS GPRS Protocol (BSSGP), v.7.4.0, R98.
[12] GSM 08.58, BSC-BTS, Layer 3 specification, v. 7.4.1, R98.
[13] 3GPP TS 03.64, Overall description of the GPRS radio interface; Stage
2, v. 8.11.0, R99.
[14] A. Kuurne, D. Fernndez and R. Snches, On the benefits of quality of
service differentiation based on service class in GPRS radio interface,
submitted at VTC fall 2004.