5th October 00

GPRS end-to-end performance

Analysis and optimization of GPRS end-to-end system performance

Jos L. Gil

Motorola
GSM Network Operations
GSM Systems Division
15, Euroway, Blagrove, Swindon SN5 8YQ UK

Abstract
This document defines, analyses, and optimizes the end-to-end performance of a GPRS system. It
defines the key GPRS performance metrics: bandwidth, throughput, throughput variability, latency,
jitter and errors. And it presents tools and techniques that measure and evaluate these key performance
metrics. Practical results on the impacts of GPRS on TCP are also presented. An example on how to
troubleshoot a GPRS performance issue is presented.

MOTOROLA CONFIDENTIAL PROPRIETARY

This document and the information contained in it is CONFIDENTIAL INFORMATION of Motorola,
and shall not be used, or published, or disclosed, or disseminated outside of Motorola
in whole or in part without Motorolas consent. This document contains trade secrets of
Motorola. Reverse engineering of any or all of the information in this document
is prohibited. The copyright notice does not imply publication of this document.

Copyright Motorola, Inc.

Jos L.Gil

2000 All Rights

Motorola Confidential Proprietary

Page 1 of 28

5th October 00

GPRS end-to-end performance

Table of contents

TABLE OF CONTENTS....................................................................................................................... 2
1.

INTRODUCTION.......................................................................................................................... 3

2.

END-TO-END PERFORMANCE METRICS............................................................................. 3

1.1. BANDWIDTH ......................................................................................................................... 4
1.1.1.
What determines the bandwidth in an end-to-end GPRS system...................................... 4
1.1.2.
Using UDP to measure the end-to-end bandwidth........................................................... 5
1.2. LATENCY ............................................................................................................................... 6
1.2.1.
Theoretical uplink latency ................................................................................................ 8
1.2.2.
Theoretical downlink latency ........................................................................................... 9
1.2.3.
Theoretical round trip latency........................................................................................ 10
1.2.4.
Using PING to measure the round trip latency.............................................................. 11
1.2.5.
How many PINGs should be sent to have a reliable average time of the RTT............... 12
1.2.6.
Round Trip Time (RTT) seen by TCP over GPRS .......................................................... 13
1.2.7.
A recommendation on how latency results should be presented for current Motorola
GPRS systems ................................................................................................................. 13
1.3. JITTER................................................................................................................................... 14
1.3.1.
Jitter seen by TCP over GPRS........................................................................................ 15
1.4. THROUGHPUT..................................................................................................................... 15
1.4.1.
Using FTP to measure GPRS throughput ...................................................................... 15
1.4.2.
Is TFTP appropriate to measure GPRS throughput?..................................................... 15
1.4.3.
A recommendation on how throughput results should be presented for current Motorola
GPRS systems. ................................................................................................................ 16
1.5. THROUGHPUT VARIABILITY .......................................................................................... 16
1.5.1.
Causes of the throughput variability .............................................................................. 16
1.6. ERRORS ................................................................................................................................ 17

2.

MAIN FACTORS THAT INFLUENCE THE END-TO-END GPRS PERFORMANCE..... 18

2.1.
2.2.
2.3.
2.4.
2.5.

3.

MAXIMUM TRANSFER UNIT (MTU)........................................................................................ 18

TCP PARAMETERS .................................................................................................................. 19
COMMITTED INFORMATION RATE (CIR) ................................................................................. 19
RADIO PARAMETERS ............................................................................................................... 20
BLOCK ERROR RATE IN THE RADIO INTERFACE (BLER): PERFORMANCE OF GPRS IN THE FIELD
................................................................................................................................................ 20

TCP PERFORMANCE OVER GPRS ....................................................................................... 23

3.1.
3.2.

EFFECT OF HIGH LATENCY LINKS ON TCP THROUGHPUT ........................................................ 23

EFFECT OF PACKET LOSS ON TCP THROUGHPUT ..................................................................... 24

4.

EXAMPLE OF TROUBLESHOOTING A GPRS PERFORMANCE ISSUE ....................... 26

5.

REFERENCES ............................................................................................................................. 28

Jos L.Gil

Motorola Confidential Proprietary

Page 2 of 28

5th October 00

GPRS end-to-end performance

1. Introduction
The performance analysis of an end-to-end GPRS system and its troubleshooting
requires a wide set of skills and knowledge. A systems engineer working on GPRS
performance issues will be required to:
understand how different data applications behave,
how TCP (Transport Control Protocol) works,
how IP connectivity is achieved, how the GPRS radio interface is designed,
what parameters can be tuned in the system databases and protocols (GSN, BSS,
TCP/IP),
etc.
All these different protocols and system features make possible the transaction of data
from one end to another but not always necessarily in the best form. In these
occasions it is necessary to investigate and understand the nature of the problem. The
problem could be a system fault or it could be just an optimisation issue of system
databases or protocol timers and counters.
Having the skills mentioned above is not enough. It is indispensable to know what
performance means, what are its metrics, how they can be measured and how they
should be understood. For example, you could have good network FTP throughput but
dreadful PING times. Is this a good or a bad network performance? The answer will
depend on what the end user application is looking for. For a telnet application a good
FTP throughput is irrelevant while for a downloading application FTP performance is
what matters. Different users, different applications, different systems, will have
different performance requirements.
This paper defines performance through its metrics. It introduces concepts,
procedures, techniques, tools and examples to analyse and troubleshoot end-to-end
performance. Most of the contents of this paper can be applied to performance
engineering of data networks in general.
A Motorola GPRS system will be performing well when the measured values of the
metrics defined in this paper are close to the expected values defined in this paper.
The contents of this paper apply to a single mobile user unless otherwise specified.

2. End-to-end performance metrics

There are two fundamental questions when assessing the end-to-end performance of a
GPRS system and in general of any data network:
1. What is the latency or delay for a packet to travel from one end to the other?
2. What is the expected end-to-end throughput for a large file transfer?
It is important to translate these two questions into unambiguous, accurate and
measurable technical parameters or metrics. The following metrics meet these
requirements and should be used to assess the end-to-end performance of a GPRS
system:

Jos L.Gil

Motorola Confidential Proprietary

Page 3 of 28

5th October 00

GPRS end-to-end performance

Bandwidth
Latency
Jitter
Throughput
Throughput variability

End-to-end
performance metric
Bandwidth
Latency
Jitter
Throughput
Throughput variability
Errors

Definition
Number of bytes or bits transmitted across a reference point.
Time it takes for a data bit to travel from one end to another of a system.
Variation of the time it takes for a data bit to travel from one end to
another of a system.
Ratio of the amount of time it takes to complete a full data transaction
The difference between the maximum and the minimum throughput
Corruption, lost or duplication of a data packet

The performance of a GPRS -GENERAL packet radio system- system can be defined
by its bandwidth, latency, jitter, throughput, throughput variability and error
characteristics.
A GPRS system will be performing well when the measured values of these six
metrics are close to the expected values.

1.1. BANDWIDTH
Bandwidth is the number of bytes or bits per second observed across a reference
point.
1.1.1. What determines the bandwidth in an end-to-end GPRS system
The bandwidth of a system is dictated by the slowest link. In a GPRS system the
slowest link is the radio interface. Bandwidth is also named raw user data rate. Table
1 shows the bandwidth of the GPRS air interface for the four different channel coding
schemes and for a different number of timeslots.
CS-1

CS-2

CS-3

CS-4

1 Timeslot

9.05

13.4

15.6

21.4

2 Timeslots

18.1

26.8

31.2

42.8

3 Timeslots

27.15

40.2

46.8

64.2

4 Timeslots

36.2

53.6

62.4

85.6

5 Timeslots

45.25

67

78

107

6 Timeslots

54.3

80.4

93.6

128.4

7 Timeslots

63.35

93.8

109.2

149.8

8 Timeslots

72.4

107.2

124.8

171.2

Jos L.Gil

Motorola Confidential Proprietary

Page 4 of 28

5th October 00

GPRS end-to-end performance

Table 1. GPRS air interface bandwidth.

Each application has its bandwidth needs. Knowing the bandwidth of the interfaces
that integrate the end-to-end GPRS system will allow us to predict probable locations
of bottlenecks within the network.
It is important to introduce here the concept of aggregated bandwidth. The
aggregated bandwidth demand is the sum of the bandwidth requirements of all the
users trying to access the system or a particular node in the system. This aggregated
bandwidth concept must be used mainly in the bottlenecks of a system, such as the
radio interface in the GPRS system, and also in servers and congestion points such as
routers (including GGSN).
1.1.2. Using UDP to measure the end-to-end bandwidth
UDP stands for User Datagram Protocol and is a transport layer protocol part of the
TCP/IP protocol suite. Each output (data bytes) from an application process produces
one UDP datagram. UDP does not provide reliability: it does not guarantee that the
datagram will reach its destination. UDP does not have any of the flow control and
congestion algorithms that TCP does. UDP is a simple transport protocol suitable for
our purpose of measuring the bandwidth of the GPRS system.
There are several tools that can be used to send UDP datagrams from one end to
another. The most used are UDP scripts developed in BSS development and a tool
called Iperf.
The most common UDP test consists in sending 50 UDP datagrams of 400 bytes each
one with an inter-datagram gap of 10 miliseconds.
Once the UDP test is finished the bandwidth of the system can be measured at any
point of it although this will depend on the availability of packet time-stamps at that
specific point. The easiest measurement point and the only one that matters to the end
user is at the PC client.
The bandwidth at the PC client can then be measured at the IP, UDP or application
layer using the time-stamps of the first and last packet and applying the following
formulas:

packets 1) ( packet size(bytes) + 28) 8

1

(kbps)
timestamp last packet ( s) timestamp first packet ( s ) 1000
(number of packets 1) ( packet size(bytes) + 8) 8 1 (kbps)
BWUDP layer =
timestamp last packet ( s ) timestamp first packet ( s ) 1000
(number of packets 1) packet size(bytes) 8 1 (kbps)
BWapp. layer =
timestamp last packet ( s ) timestamp first packet ( s ) 1000
BWIP layer =

(number of

Equation 1. Bandwidth calculation at the PC client using a UDP test.

It is recommended to use the formula BWapp.layer (bandwidth at the application layer)

because this is the one that the user is going to perceive.
Jos L.Gil

Motorola Confidential Proprietary

Page 5 of 28

5th October 00

GPRS end-to-end performance

Whatever formula is used to calculate the bandwidth careful attention must be paid
when communicating to others UDP results. At least three information elements
should be provided:
Location of the BW measurement: PC client, mobile, PCU, SGSN, etc.
Layer at which BW is calculated: application, UDP, IP, RLC, etc.
Specific formula used if any
As another example if it is necessary to measure the BW at the radio interface (PCU or
mobile) the following formula is recommended:

BWPCU IP layer =
BWMS IP layer =

number of packets ( packet size(bytes) + 28) 8

(ending ABN starting ABN ) 20ms

(kbps)

number of packets ( packet size(bytes) + 28) 8

(timestamp last RLC data block timestamp first RLC data block ) 20ms

Equation 2. Bandwidth calculation at the PCU and/or mobile (IP layer) using UDP testing.

Accessing the PCU might be difficult sometimes. However accessing the mobile
might be easier. The MS-Decoder, tool developed in the GSM Network Operations
department and available to Motorola, has been designed to decode the air interface
messages received and sent by the mobile at different layers: RLC, LLC, L3, IP. The
MS-Decoder tool is the ideal tool to measure the BWMS IP layer specified in Equation 2.
The maximum bandwidth provided by the Motorola GPRS radio interface is shown in
Table 2. This bandwidth is what an LLC frame will see when no TBF needs to be
setup. These figures do not take into account the overhead due to signalling.

UDP throughput
(kbps)
DL BWPCU LLC layer
UL BWPCU LLC layer

1TS
CS-1 CS-2
7.33
11.00
6.67
10.00

2TS
CS-1 CS-2
14.66 22.00
13.34 20.00

Table 2. Maximum theoretical UDP throughput (smg31)

1.2. LATENCY
Latency is the time it takes for a data bit to travel from one end to another.
The definition uses the term bit for strictness purposes. In practice it is not always
possible to transmit just one bit and measure the time it takes to arrive to the other
end. Therefore when performing latency measurements the size of the packet needs to
be determined. In this section the term packet is used instead of bit.

Jos L.Gil

Motorola Confidential Proprietary

Page 6 of 28

(kbps)

5th October 00

GPRS end-to-end performance

Many applications are not sensitive to latency such as FTP data. But many others are
such as telnet, rlogin, FTP control (not FTP data), TFTP, DNS UDP query, interactive
voice and video. A packet video application has already being used by Motorola for
GPRS demonstrations. Latency-sensitive applications usually have a point beyond
which late packets are discarded.
It is important to note that the technical literature distinguishes between latency and
delay. Those delay contributors that are relatively fixed and beyond the control of the
network engineer are attributed to latency. Whilst all other delay contributors which
the network engineer has some amount of control are attributed to delay. This
distinction is conceptually important when providing reference latency figures for
GPRS systems around the world. This is because there are certain GPRS database
parameters settings, traffic conditions and system configurations that can affect the
time it takes for a packet to cross the network. And therefore different GPRS
systems will have different latency figures and will not be possible to compare them.
In this paper the term latency will be used with no distinction with delay.
Four types of latency need to be distinguish in a GPRS system:
Uplink latency: the time it takes for a packet to travel from the PC client
connected to the mobile to the server connected to a PDN (Packet Data Network).
Downlink latency: the time it takes for a packet to travel from the server
connected to a PDN to the PC client connected to the mobile.
Uplink round trip time: the time it takes for a packet to travel from the PC client
connected to the mobile to the server and back again.
Downlink round trip time: the time it takes for a packet to travel from the server
to the PC client connected to the mobile and back again.
The Figure 1 illustrates these four types of latency.
The downlink and uplink latency are not the same in a GPRS system because both
paths are not symmetrical.

GPRS
network

PDN

uplink latency
downlink latency
uplink round trip latency
downlink round trip latency

Figure 1. Illustration of the four types of latency that need to be distinguished in a GPRS system.

Jos L.Gil

Motorola Confidential Proprietary

Page 7 of 28

5th October 00

GPRS end-to-end performance

The following sections provide theoretical and empirical results for the latency. It is
possible to calculate an approximate number for the minimum latency, but it is not for
the maximum latency since the number of variables involved for this case is very big
and some of them not possible to predict, such as RLC retransmissions. Reference [1]
contains detailed information on latency. The next sections refer to that document
with updates for smg31.
1.2.1. Theoretical uplink latency
The uplink latency is defined by:
ULlatency = TPC1MS + PMS + TMSPCU + PPCU + TPCUSGSN + PSGSN + TSGSNCH + PCH + TCHGGSN + PGGSN + TGGSNCH + PCH + TCHPC2 =
= TPC1MS + PMS + TMSPCU + PPCU + TPCUSGSN + PSGSN + TSGSNCH + TCHGGSN + PGGSN + TGGSNCH + 2 PCH + TCH PC2
Equation 3. Elements involved in the uplink latency.

Where:
Px=packet processing time for node X
Ty=packet transmission time across interface Y
contains a few variables that are not possible to quantify analytically, such
as the transit times through the network elements (MS, PCU, GSN complex). For this
reason it is extremely difficult to provide exact theoretical numbers for the minimum,
maximum and average latency.
Equation 3

If we consider negligible the processing times of the PC, mobile, PCU and GSN
complex Equation 3 can be reduced to:

ULlatency = TPC1 MS + TMS PCU + TPCU SGSN + TSGSN PC 2

Equation 4. Simplified formula to calculate the uplink latency.

Where:

TPC1 MS = TIrDA + TPC1

TMS PCU = TTBF SETUP + TTBF DATA

Equation 5. Components of the transmission time between PC and mobile and between mobile and
PCU.

Due to the limited extension of this paper is not possible to provide full details
although this can be found in reference [1].
The results for Equation 4 for smg31 are shown in Figure 2. The calculations assume
N201=1520.

Jos L.Gil

Motorola Confidential Proprietary

Page 8 of 28

5th October 00

GPRS end-to-end performance

Minimum theoretical latency (UDP packet)

2000
1800
1600
Time (ms)

1400
1200

UL latency 1TS CS-1

1000

UL latency 1TS CS-2

800
600
400
200
0
0

100

200

300

400

500

600

700

800

900

1000

UDP packet payload (bytes)

Figure 2. Minimum theoretical uplink latency against the payload of a UDP packet. This graph is valid
for N201=1520.

1.2.2. Theoretical downlink latency

The downlink latency is defined by:
DLlatency = TPC2CH + PCH + TCHGGSN + PGGSN + TGGSNCH + PCH + TCHSGSN + PSGSN + TPCUSGSN + PPCU + TPCUMS + PMS + TMS PC1 =
= TPC2CH + 2 PCH + TCHGGSN + PGGSN + TGGSNCH + TCHSGSN + PSGSN + TPCUSGSN + PPCU + TPCUMS + PMS + TMS PC1
Equation 6. Elements involved in the downlink latency

Where:
Px=packet processing time for node X
Ty=packet transmission time across interface Y
contains a few variables that are not possible to quantify analytically, such
as the transit times through the network elements (MS, PCU, GSN complex). For this
reason it is extremely difficult to provide exact theoretical numbers for the minimum,
maximum and average latency.
Equation 6

If we consider negligible the processing times of the PC, mobile, PCU and GSN
complex Equation 6 can be reduced to:
DLlatency = TPC 2 SGSN + TSGSN PCU + TPCU MS + TMS PC1
Equation 7. Simplified formula to calculate the downlink latency.

Where:

TMS PC1 = TIrDA + TPC1

TPCU MS = TTBF SETUP + TTBF DATA

Jos L.Gil

Motorola Confidential Proprietary

Page 9 of 28

5th October 00

GPRS end-to-end performance

Equation 8. Components of the transmission time between mobile and PC and between PCU and
mobile.

Due to the limited extension of this paper is not possible to provide full details
although this can be found in reference [1].
The results for Equation 7 for smg31 are shown in Figure 3.

Minim um theoretical latency (UDP packet)

1800
1600

Time (ms)

1400
1200
1000

DL latency 1TS CS-1

800

DL latency 1TS CS-2

600
400
200
0
0

100

200

300

400

500

600

700

800

900

1000

UDP packet payload (bytes)

Figure 3. Minimum theoretical downlink latency against the payload of a UDP packet. This graph is
valid for N201=1520.

1.2.3. Theoretical round trip latency

The round trip latency can be uplink initiated from the mobile- or downlink initiated
from the server in the PDN-. Against what intuition might say these two round trip
latencies are not symmetrical in a GPRS system. Nevertheless the uplink round trip
latency is the most common and easy to measure since it is initiated at the mobile.
This section presents the uplink round trip latency. For the downlink round trip time
please refer to reference [1].
The uplink round trip latency is defined by:
RTTuplink = uplink latency + uplink TBF release + downlink latency
Equation 9. Elements involved in the uplink round trip latency.

The results of Equation 9 for smg31 are shown in Figure 4.

Jos L.Gil

Motorola Confidential Proprietary

Page 10 of 28

5th October 00

GPRS end-to-end performance

Minimum theoretical latency (UDP packet)

3500
3000

Time (ms)

2500
2000

UL RTT 1TS CS-1

UL RTT 1TS CS-2

1500
1000
500
0
0

100

200

300

400

500

600

700

800

900

1000

UDP packet payload (bytes)

Figure 4. Minimum theoretical uplink RTT (PING). The graph is valid for N201=1520.

1.2.4. Using PING to measure the round trip latency

The PING command is an easy and ideal tool to measure the round trip time in the
GPRS system. The PING command is composed of an ICMP echo request and ICMP
echo reply.
The PING testing provides information that UDP testing cannot provide: TBF setup
times (both directions). This is because UDP throughput is measured at the receiver
side based on the time-stamps of the UDP packets as they reach the UDP application.
Therefore the first UDP packet does not contain the time it took to setup the radio
TBF (Temporary Block Flow).
When using the PING command it is recommended to set an interval between PINGs
of 2 seconds (AGNettools provides this option). Figure 5 illustrates this concept. The
reason for this is to guarantee that every single PING has experienced the same
conditions. The interval of 2 seconds allows the radio interface timers to expire and
the mobile contexts to be deleted properly. If certain PINGs re-use resources or
conditions of the previous PINGs it will create a variability in the PING results
difficult to undertand.

PING REQUEST
PING #1
PING REPLY
2 seconds
PING REQUEST
PING #2
PING REPLY

Jos L.Gil

Motorola Confidential Proprietary

Page 11 of 28

5th October 00

GPRS end-to-end performance

Figure 5. It is recommended to set an interval of 2 seconds between PING commands to guarantee that
every single PING happens under the same conditions with regard to timers, counters and contexts.

Secondly, it is recommended to use PING sizes of 0 bytes to eliminate the variable of

the channel coding scheme selection algorithm. PINGs of 0 bytes occupy only 1 RLC
block regardless of the channel coding scheme. It is also recommended PING sizes of
10 bytes (some PING programs do not accept 0 bytes payload) since the PING will
require only 3 CS-1 RLC blocks or 2 CS-2 RLC blocks. In this case there is only one
RLC block difference between using CS-1 and CS-2 and will still eliminate the
variable of the channel coding scheme selection algorithm.
The PING times are not always the times that TCP is going to measure as round trip
time because the scenarios have certain differences:
Concurrent TBFs are frequent during a TCP data transaction, which reduces the
measured round trip times.
Other TCP segments will not be so lucky to be transmitted over the radio interface
through a concurrent TBF and instead a TBF will be required to be setup for its
transmission.
TCP segments might experience different delays depending on the number of
segments before them in the network node buffers.
1.2.5. How many PINGs should be sent to have a reliable average time of the RTT
One question arises when measuring the average round trip time in a GPRS system:
how many PING do I need to run in order to have an average result within a certain
degree of confidence?
Based on a mathematical analysis of the Motorola GPRS system (see reference [1])
Table 3 was produced to provide an indication of the number of PINGs needed to be
run to have an specific interval of confidence for the obtained average. Table 3 only
applies if the standard deviation of the PING times is around 170ms.
How should Table 3 be read? Lets say that it is wished to know how many times the
PING command needs to be run to obtain an average value for the round trip time
within a range of 20 ms and a confidence of 95%. Looking at we see that for the 1TS
UL-2TS DL category, in the column labelled 95%, there is a number of 96.517ms
(row 4). The number of samples needed to run to obtain this resolution (96.517ms) is
300 (left column same row as the number 96.517ms). Therefore if we run 100 times
the PING command (with a payload of 10 bytes) the average we will obtain will be
average96.517ms with a confidence of a 95%.

No. Samples
4
10
50

Jos L.Gil

1TS UL, 2TS DL

Confidence (ms)
95%
98%
482.585
572.796
305.214
362.268
136.496
162.011

Motorola Confidential Proprietary

Page 12 of 28

5th October 00

GPRS end-to-end performance

100
300
500
1000
2000

96.517
55.724
43.164
30.521
21.582

114.559
66.141
51.232
36.227
25.616

Table 3. Relation

between the number of PINGs and the interval of confidence of the

obtained average. This table applies only for a standard deviation around 170ms.
1.2.6. Round Trip Time (RTT) seen by TCP over GPRS
Figure 6 shows a real example of the round trip time seen by TCP during an FTP
transaction in the downlink. The blue bar is the downlink component (TCP data
segments of 960 bytes payload) while the red bar is the uplink component (TCP
ACKs). What samples of the round trip time are actually measured and used by TCP
for the calculation of the estimated RTT and the RTO depends on the TCP
implementation.

Seconds

Round trip tim e during a TCP data connection and its dow nlink and uplink
com ponents

6
5
4
3
2
1
0

uplink latency
dow nlink latency

TCP segm ent sequence

Figure 6. Round trip time and its downlink and uplink components during a TCP data connection. This
graph corresponds to a downlink FTP data transaction. The data TCP segments had a payload of 960
bytes (blue bars).

1.2.7. A recommendation on how latency results should be presented for current

Motorola GPRS systems
The experience gathered with the Motorola GPRS system during the last two years
suggests to use the following four indicators when presenting latency measurements:
Average
Minimum
Maximum
Standard deviation
The current Motorola GPRS system is experiencing a certain degree of variability that
needs to be expressed in meaningful terms. It is for this reason that the standard
deviation, maximum and minimum metrics must be presented.

Jos L.Gil

Motorola Confidential Proprietary

Page 13 of 28

5th October 00

GPRS end-to-end performance

It is suggested to add to the previous four indicators a bar graph that shows the
distribution of latency samples against time intervals of 500ms.
Figure 8 shows

an example of a distribution graph of PING times. A tool called

AGNettools was used. To have meaningful statistical data a large number of PINGs
was generated (10 bytes payload). The results for Figure 7 are (BSS load 1613.85 MS
load AF.27):
PING time results:

average:
standard deviation:
minimum:
maximum:

2898

ms

456.8 ms
1956

ms

8947

ms

00

00

94

00

89

00

84

00

79

00

74

00

69

00

64

00

59

00

54

00

49

00

44

00

39

00

34

29

24

19

00

90.00
80.00
70.00
60.00
50.00
40.00
30.00
20.00
10.00
0.00

00

Percentage (%)

Percentage of RTT (resolution 500ms)

Interval of 500 ms
Figure 8. Round trip time expressed as distribution of PING samples within time intervals. The results
shown in this graph were obtained with BSS release 1613.85 and mobile release AF.27. The
AGNettools was used to generate a sample of 10000 PINGs with inter-PING interval of 2 seconds and
a payload of 10 bytes.

1.3. JITTER
Variation of the time it takes for a data bit to travel from one end to another of a
system
The definition uses the term bit for strictness purposes as in the latency definition. In
practice it is not always possible to transmit just one bit and measure the time it takes
to arrive to the other end. Therefore when performing jitter measurements the size of
the packet needs to be determined. In this section the term packet is used instead of
bit.

Jos L.Gil

Motorola Confidential Proprietary

Page 14 of 28

5th October 00

GPRS end-to-end performance

The jitter in a packet-switched network can be very large. In a GPRS network it is

caused by the internal operation of:
routers (internal GGSN- and external),
switches (CommHub),
half duplex ethernet configuration (CommHub),
processing (CPUs),
buffers and queues in the GGSN, SGSN, PCU, mobile and PC serial port, and
the architecture of the GPRS/GSM radio interface (due to the ETSI standards and
the Motorola design).
Of the above elements the major cause of the jitter in GPRS is the architecture of the
GSM/GPRS radio interface.
1.3.1. Jitter seen by TCP over GPRS
One of the key inputs of TCP is the measured Round Trip Time (RTT). This
measured RTT is used to calculate the Retransmission Timeout (RTO) value. The
RTO will determine when TCP segments need to be retransmitted. If the jitter at the
TCP layer is large this might cause unnecessary TCP segment retransmissions that
reduce the end-to-end throughput.
Typical jitter in a TCP data connection over GPRS can be observed in Figure 6. The
jitter seen in this figure is of 3.1 seconds.

1.4. THROUGHPUT
The ratio of the amount of time it takes to complete a full data transaction.
Many applications are not sensitive to latency but are to throughput such as webbrowsing.
1.4.1. Using FTP to measure GPRS throughput
FTP (File Transfer Protocol) is the Internet standard for file transfer. FTP was
designed for general purpose and to provide high-performance in terms of throughput.
FTP is recommended as the tool to measure the throughput of a GPRS system. It is
recommended not to use files smaller than 10KBytes
1.4.2. Is TFTP appropriate to measure GPRS throughput?
TFTP stands for Trivial File Transfer Protocol. It is commonly used for bootstrapping
devices with no disk. TFTP uses UDP as transport protocol. However its stop-andwait transmission strategy is not suitable at all to measure the throughput of the GPRS
system. TFTP is not designed for high-throughput. The Figure 9 illustrates the
concept of the stop-and-wait protocol.

Jos L.Gil

Motorola Confidential Proprietary

Page 15 of 28

5th October 00

GPRS end-to-end performance

server

client
BLOCK n
ACK block n

BLOCK n+1

Figure 9. Illustration of the stop-and-wait protocol strategy used in TFTP.

1.4.3. A recommendation on how throughput results should be presented for

current Motorola GPRS systems.
Same recommendation as for latency results in section 1.2.7.

1.5. THROUGHPUT VARIABILITY

The difference between the maximum and the minimum throughput.
1.5.1. Causes of the throughput variability
The causes of the throughput variability can be multiple and will vary between
different scenarios. Some of the most frequent are:
Channel coding scheme selection algorithm: the change of channel coding
scheme can cause up to a 34 % variation in the end-to-end throughput. The main
reasons for the change of the channel coding scheme during a TBF will be radio
interference and strong fading.
Non-concurrent TBFs: every time a LLC frame cannot be transmitted in a TBF
concurrent with another TBF in the opposite direction means to setup a TBF,
which takes more than 300ms. TCP is a full duplex protocol therefore during a
TCP transaction there should be mostly concurrent TBFs in the radio interface.
Packet loss: every time a TCP segment is lost a 15% reduction in the end-to-end
throughput can be expected.
Network jitter
Mobile jitter: the Motorola GPRS mobile (smg29) introduces a large jitter when
processing a packet. The Figure 10 shows the measured round trip time jitter (MS>PC->MS) for a 40 bytes packet (time-stamped at the LLC layer).

Jos L.Gil

Motorola Confidential Proprietary

Page 16 of 28

5th October 00

GPRS end-to-end performance

700
600
500
400
300
200
100

48

45

42

39

36

33

30

27

24

21

18

15

12

0
0

round trip time MS->PC->MS (ms)

Motorola GPRS mobile (smg29) variability

No. PING (10 bytes payload)

Figure 10. Round trip time for a 40 bytes packet departing from the LLC layer at the mobile to the PC
across the IrDA interface and back again to the LLC layer. Observe the jitter of 500ms.

1.6. ERRORS
Corruption, lost or duplication of a data packet
Errors occur in many different forms and have different impacts in different
applications. Reliable transport protocols such as TCP will make sure that all the data
packets will arrive to their destination error-free. Every retransmitted data packet will
mean a reduction in throughput and an expensive occupancy of the scarce GPRS radio
bandwidth. For these reason the error factor needs to be taken into consideration when
analysing the performance of a GPRS network.
In a GPRS system we can classify errors in four categories:
Checksum errors: packets discarded due errors detected by the checksum
procedure. There are at least four layers in the end-to-end GPRS system were
checksum errors can occur: frame relay, LLC, IP and TCP.
Lost packets: packets that are discarded at some GPRS network node because of
node congestion, buffer overflow or packet damage that makes it unrecognisable
by the hardware.
Extra packets: duplicates of previously delivered packets. The causes of this can
be a corrupted IP address or a recovery attempt after a network failure.
Late packets: error-free packets that are delivered too late to be useful to the
application.

Jos L.Gil

Motorola Confidential Proprietary

Page 17 of 28

5th October 00

GPRS end-to-end performance

The most important and common kind of error in a GPRS network is the lost packets.
The consequences of losing packets are usually dramatic in the end-to-end
throughput. Section 3.2 illustrates this problem.

2. Main factors that influence the end-to-end GPRS

performance
2.1. Maximum Transfer Unit (MTU)
The MTU is the Maximum Transfer Unit. The MTU is a characteristic of the link
layer that determines the maximum length of the packet from the network layer that
will be accepted. When IP has a packet to send, if the packet is larger than the MTU,
IP will have to fragment the IP packet. This involves extra processing and additional
overhead for every transmitted IP packet.
There is a trade off between the jitter and the overhead. The smaller the IP packet is
the smaller will be the network jitter (specially the one introduced by the GGSN and
SGSN). But the smaller is the IP packet the more overhead is transmitted and
therefore the use of the bandwidth is less efficient.
Another consideration to take into account is the LLC frame size (N201). The SNDCP
layer in the SGSN and in the mobile will have to break the IP packets in smaller
pieces if the IP packet is larger than the LLC frame size. This means additional
processing and an increase in the jitter. From this perspective it is recommended to
define an MTU 10 bytes smaller than the LLC frame size. This has the following
benefits:
The IP packets are not fragmented in the SGSN in several LLC frames. Therefore
losing an LLC frame means losing an IP packet which will have to be
retransmitted by TCP. However if the IP packet is fragmented into several LLC
frames and one of them is lost in its way to the mobile then the full IP packet will
have to be retransmitted by TCP.
Less processing time by the SGSN (important for heavy load scenarios).
The jitter introduced by the SGSN will be reduced.
shows that, on average, a small MTU value provides an end-to-end
throughput comparable to a large MTU value.
Figure 11

If the MTU is set to 10 bytes smaller than the LLC frame size this will only need to be
done in the PC client. No modification is needed in the routers or the host server. This
is because the client advertises its MTU to the server (using the MSS maximum
segment size- in the beginning of the TCP connection and the sever has to use the
smaller value between the MSS (Maximum Segment Size) and the local server MTU.

Jos L.Gil

Motorola Confidential Proprietary

Page 18 of 28

5th October 00

GPRS end-to-end performance

FTP DL Performance V MTU

2.50

20.00
18.00

2.00

16.00
14.00

1.50

10.00
1.00

Kbits/s

KBytes/sec

12.00
Max
Min
Avg

8.00
6.00

0.50

4.00

2.00
0.00
400

500

600

700

800

900

1000

1100

1200

1300

1400

0.00
1500

MTU

Figure 11. FTP throughput against MTU. On average it is recommended to use small MTU values.

2.2. TCP parameters

There are several TCP parameters that can be optimised. The most significant are:
Receiver window: it should be set at least equal to the product BW x delay
Initial retransmission timeout: it is recommended to set the value of this
parameter at least to 5 seconds.
Different operating systems allow different TCP parameters to be modified. Unix
offers more flexibility than Microsoft to modify the values of TCP parameters. In any
case, for a GPRS operator it might be relatively easy to modify the TCP parameters at
the PC client but it will be much more difficult, if not impossible, to modify the server
TCP parameters since the server might be used by not only GPRS (wireless) users.
Proxy servers are being developed to optimise the performance of TCP over wireless
links.

2.3. Committed Information Rate (CIR)

It is recommended to set the Committed Information Rate (CIR) at the frame relay to
the maximum bandwidth offered by the link. Although for low traffic scenarios the
CIR value might not be a crucial parameter for the end-to-end performance, it will be
for high traffic scenarios. In these situations the signalling over the frame relay links
might mean more than the 10% of the total traffic carried by the Gb links.

Jos L.Gil

Motorola Confidential Proprietary

Page 19 of 28

5th October 00

GPRS end-to-end performance

2.4. Radio parameters

Some radio parameters play an important role in the end-to-end latency and
throughput. A full description of the Motorola PCU database parameters and
guidelines on how to optimise them can be found on reference [4].
Some of the parameters that have a bigger impact on the latency and throughput are:
bs_pa_mfrms: defines the sub-channels in the downlink CCCH channel where a
mobile can receive a paging or immediate assignment message (DRX mode).
Although the optimum value for end-to-end performance is 2 multi-frames
(bs_pa_mfrms=0 in the database) it will be very unusual if an operator will accept
this value. This is because bs_pa_mfrms has an impact on the paging load
dimensioning.
gprs_t3192
gprs_t3168
gprs_bs_cv_max
2.5.

Block Error Rate in the radio interface (BLER): performance of

GPRS in the field
Sections 1.1 and 1.2 provide theoretical performance values for the bandwidth and the
round trip time of Motorola GPRS system. These values are calculated for optimum
conditions: no link interference, best transmission times and minimum node
processing times. Obviously these values will not be frequently seen in the field. The
field will be hostile due to interference, fading and traffic load.
What GPRS performance can we expect in the field? This section presents simulation
and lab results on the performance of the channel coding schemes under different
interference and mobility scenarios.
Simulation results (reference [2]) of the performance of the channel coding schemes
against C/I and different fading profiles are shown in Figure 12 and Figure 13 . It is
observed from these two figures that CS-3 performs just slightly worse than CS-2 in
terms of BLER. However, since CS-3 provides higher throughput than CS-2 it is
desirable to work with CS-3 instead than CS-2. CS-4 seems to be very expensive in
terms of C/I (a high C/I is needed to benefit from the highest throughput).
The BLER results can be converted to throughput results as experienced by an RLC
user (=LLC frame). Figure 12 shows the throughput results for a downlink LLC frame
against different C/I and different fading profiles. Again CS-3 seems a good
candidate.

Jos L.Gil

Motorola Confidential Proprietary

Page 20 of 28

GPRS end-to-end performance

TU3
No Hopping

5th October 00

100
CS1
CS2
CS3
CS4

BLER

10
1
0.1
0.01
0 2 4 6 8 10 12 14 16 18 20 22 24
CI (dB)

Figure 12. Performance of the four GPRS channel coding schemes for a mobile moving at 3kmph and
for different C/I values. No frequency hopping has been assumed.

TU50
No Hopping
100
CS1
CS2
CS3
CS4

BLER

10
1
0.1
0.01
0

12

16

20

24

CI (dB)

Figure 13. Performance of the four GPRS channel coding schemes for a mobile moving at 50kmph and
for different C/I values. No frequency hopping has been assumed.

Jos L.Gil

Motorola Confidential Proprietary

Page 21 of 28

5th October 00

GPRS end-to-end performance

Throughput (kbit/s)

Throughputs - TU3
No Hopping
25
20
15
10
5
0

CS1
CS2
CS3
CS4
0

12

16

20

24

CI (dB)

Throughput
(kbit/s)

Throughputs - TU50
No Hopping
30
20
10
0
0

12

16

20

24

CS1
CS2
CS3
CS4

CI (dB)
Figure 14. Downlink throughput seen by a LLC frame (no TBF setup time) for different C/I and for
3kmph and 50kmph.

The author has performed some lab measurements of the BLER against C/I. These are
presented in Figure 15.

Jos L.Gil

Motorola Confidential Proprietary

Page 22 of 28

5th October 00

GPRS end-to-end performance

Uplink BLER for M-Cell Arena 900

35

30

BLER (%)

25

CS-1 TU 3
20

CS-2 TU 3
CS-1 TU 50

15

CS-2 TU 50
10

0
5.35

6.35

7.35

8.35

9.35

10.35

11.35

12.35

13.35

14.35

15.35

16.35

C/I (dB)

Figure 15. Lab measurements of uplink BLER for M-Cell Arena 900.

3. TCP performance over GPRS

3.1. Effect of high latency links on TCP throughput
It has been observed (see reference [3]) that FTP throughput decreases with an
increase of the latency. The decrease rate varies among different operating systems.
shows the FTP throughput against the round trip latency for Windows NT4
Service Pack 5. The FTP throughput decreases very abruptly when the RTT is
between 2 and 3 seconds.
Figure 16

One of the reasons for the reduction of the TCP throughput against high RTT values
is that TCP was designed for low latencies (Ethernet networks with 10Mbps
bandwidth). The slow start and congestion avoidance algorithms are not optimum for
high latency links. In addition packet loss is one of the most damaging elements for
TCP. See section 3.2.

Jos L.Gil

Motorola Confidential Proprietary

Page 23 of 28

5th October 00

GPRS end-to-end performance

Server NT4/SP5 Client NT4/SP5

3

DL 55D1

UL 55D1

2.5

Throughput (KBytes/sec)

Server:
NT4 / SP5
MSS/MTU 1460/1500
Win 65535

2
Client
NT4 / SP5
MSS/MTU 1460/576
Win 65535

1.5

General:
DL bit rate: 21500 bps
UL bit rate: 9500 bps
UL/DL Latency Symmetric

0.5

0
0

1000

2000

3000

4000

5000

6000

7000

8000

RTT (ms)

Figure 16. FTP throughput against round trip time. The round trip used in this simulation was set to be
symmetrical in the downlink and uplink (RTT= downlink latency + uplink latency =2 x downlink
latency). The FTP throughput is severely affected when the RTT is between 2 and 3 seconds.

3.2. Effect of packet loss on TCP throughput

Packet loss in high latency networks such as GPRS is the most damaging element for
the TCP throughput. This is due mainly to:
the RTO calculated by TCP
the execution of the congestion avoidance and slow start algorithms.
For the current Motorola GPRS system on average a lost TCP segment will reduce the
end-to-end throughput by a 15%. Actually the first lost TCP segment in a TCP data
transaction has a smaller impact in the end-to-end throughput reduction than the
following lost segments.
Figure 17 shows the TCP segments of a downlink FTP over GPRS that achieved
1kbps. Six TCP segments were lost and had to be retransmitted by TCP. The impact
of this six lost segments on the end-to-end throughput is dramatic.
Figure 18 shows the TCP data transaction of downlink FTP over GPRS that did not
experience any packet loss. The achieved throughput was 16.8 kbps.
The difference in throughput between Figure 17 and Figure 18 is of a 94%. This is a
clear evidence of the devastating effects that packet loss in a GPRS network can
produce on TCP and therefore end-to-end performance.

Jos L.Gil

Motorola Confidential Proprietary

Page 24 of 28

5th October 00

GPRS end-to-end performance

S er v er and client chr o no lo gical act iv it y

2499728042

2499726042

2499724042

T x T CP seq (ser ver )

Rx T CP ACK (ser ver )

2499722042

T x T CP ACK
2499720042

Rx T CP seq
2499718042

2499716042

2499714042

T i me ( s )

Figure 17. Full TCP data transaction of a downlink FTP with six TCP segments lost (1kbps).

Server and client chronological activity

1601261719

TCP sequence

1601256719

Tx TCP seg (server)

Rx TCP ack (server)
1601251719

Rx TCP seg (client)

Tx TCP ack (client)
1601246719

1601241719

0.000

5.000 10.000 15.000 20.000 25.000 30.000 35.000 40.000 45.000 50.000 55.000

time (s)

Figure 18. Full TCP data transaction of a downlink FTP over GPRS (16.8kbps).

Jos L.Gil

Motorola Confidential Proprietary

Page 25 of 28

5th October 00

GPRS end-to-end performance

4. Example of troubleshooting a GPRS performance issue

It is out of the scope of this document to define procedures to troubleshoot an end-toend GPRS system. It is also difficult, for not to say impossible, to collect all the
possible cases that can be given in a GPRS system and how they are analysed.
Nevertheless this section provides one real performance analysis example that
illustrates some of the core concepts of this document: bandwidth, throughput, latency
and errors (packet loss) the key GPRS end-to-end performance metrics-.
Customer ABC complains that the downlink FTP throughput is below 4kbps. No
more information is provided.
Where should we start investigating this problem?
The first step is to gather logs at many points as possible. The problem could be
anywhere so the more information obtained the better. Figure 19 shows all the logging
points and tools available to analyse an end-to-end GPRS system.
Once the log files have been obtained one recommendation is to follow a top-down
system analysis: from TCP and UDP down to the GSM physical layer.
We start by measuring the bandwidth (BW) and the packet loss of the system. For
such purpose we use UDP testing (see 1.1.2). The UDP testing reveals a bandwidth of
6kbps in the uplink and 21kbps in the downlink. It also reveals occasional packet loss
between an 8% and a 25%. From these results we can conclude that:
The end-to-end system is providing the expected bandwidth.
The radio interface is not experiencing interference and is healthy otherwise the
measured BW would not be 6kbps (CS-1) in the uplink and 21kbps (CS-2) in the
downlink.
The packet loss is not produced in the radio interface, otherwise it would not be
possible to measure a BW of 6kbps in the uplink and 21kbps in the downlink.
filters

BTS

BSC

PCU

filters
RADCOM

SGSN

CH
Etherpeek

GGSN

MS-Decoder
Etherpeek

Jos L.Gil

Motorola Confidential Proprietary

Page 26 of 28

5th October 00

GPRS end-to-end performance

Figure 19. Logging points in the GPRS system for its analysis and troubleshooting.

The analysis at the RLC layer (with the MS-Decoder and PCU filters) shows that all
the TBFs are normally released, which reinforces the fact that the there is not
significant radio interference.
An analysis of the round trip latency (see 1.2) shows that the average RTT is 4.072
seconds for a 500 bytes PING. This is an indication that TCP is going to measure an
RTT of around 4 seconds for an MTU of 1000 bytes.
The TCP analysis reveals a very first significant fact: TCP segments are being lost.
These segments lost are causing TCP retransmissions (see figure. The TCP
retransmissions are very slow (above 20 seconds) due to the fact that the RTT has an
average of 4 seconds, which will set the RTO approximately above 10 seconds.
However this is only an approximation since TCP might have measured the worst
round trip cases.
The next step is to identify the lost IP packets and trace them in the system. The IP
packet ID is in the header of the IP packets and will be searched in those packets that
left the server but never reached the client.
Once we have the IP packet ID the next step is to verify if these packets actually
reached the Gb interface. For this purpose we look at the RADCOM log file.
Server and client chronological activity

2499728042

segment sequence

2499726042
2499724042
Tx TCP seq (server)
Rx TCP ACK (server)

2499722042

Tx TCP ACK
b

2499720042

Rx TCP seq

2499718042
2499716042

120

100

80

60

40

20

2499714042

Time (s)

Figure 20. TCP analysis. The graph shows lost TCP segments and the long time it takes to TCP to
retransmit them which is causing the end-to-end throughput to be below 2kbps.

Jos L.Gil

Motorola Confidential Proprietary

Page 27 of 28

5th October 00

GPRS end-to-end performance

The IP packets appear in the Gb interface fragmented into 3 LLC frames. This is
because the MTU of the system is 1000 bytes but the LLC frame size negotiated
between the mobile and the SGSN is 500 bytes. Some of these LLC frames are
corrupted due to CRC errors at the frame relay layer.
The next step is then to look for these LLC frames into the PCU. The PCU filters
reveal that some of these LLC frames are dropped (this is the packet loss metric
within the error key performance metric defined in section 1.6).
We say that the LLC frames were dropped by the PCU not only because the PCU
filters demonstrate it but also because the MS-Decoder (LLC window) does not show
those LLC frames. These LLC frames were never transmitted over the radio interface
which did not reduce the bandwidth of the of the radio interface. However because
these LLC frames did not reach the mobile the SNDCP layer within the mobile could
not re-build the full IP packet and therefore dropped the full IP packet. This problem
could have been solved if the operation at the LLC layer would have been set to
acknowledge mode. This would have avoided TCP to retransmit the packets.
Unfortunately the negotiation between Motorola GPRS mobile and Motorola SGSN
sets the LLC mode of operation to unacknowledge mode. This is an optimum LLC
mode when there are not errors in the network but in some occasions the acknowledge
mode could help (specially when mobility is involved).
Then the cause of the lost TCP segments was a noisy GB link that produced random
CRC errors in LLC frames that were part of an IP packet.

5. References
[1]

GPRS latency: theory and practice.

Version 0.1
19th May 2000
Jose L. Gil

[2]

Impact of the radio interface on GPRS system dimensioning a simulation

study-.
2nd June 1999
Phil Jones

[3]

TCP performance over high latency links

Version 0.1
22nd July 2000
Adam Mann, Sergio Domingo

[4]

BSS and SGSN database optimisation

Version 0.1
13th March 2000
Jose L.Gil

Jos L.Gil

Motorola Confidential Proprietary

Page 28 of 28