Date post: | 02-Jun-2018 |
Category: |
Documents |
Upload: | mohamedsalah |
View: | 222 times |
Download: | 0 times |
of 28
8/10/2019 GPRS End-To-End Performance Paper
1/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 1 of 28
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
AbstractThis 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 ofMotorola. Reverse engineering of any or all of the information in this documentis prohibited. The copyright notice does not imply publication of this document.
Copyright Motorola, Inc. 2000 All Rights
8/10/2019 GPRS End-To-End Performance Paper
2/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 2 of 28
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.................................................... ........................................................... .. 161.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. MAXIMUM TRANSFER UNIT (MTU)........................................................... ............................. 18
2.2. TCP PARAMETERS ....................................................... ........................................................... 19
2.3. COMMITTED INFORMATION RATE (CIR)..................................................... ............................ 19
2.4. RADIO PARAMETERS .................................................... ........................................................... 20
2.5. BLOCK ERROR RATE IN THE RADIO INTERFACE (BLER): PERFORMANCE OF GPRS IN THE FIELD
....................................................... ............................................................ ............................. 20
3. TCP PERFORMANCE OVER GPRS .......................................................................................23
3.1. EFFECT OF HIGH LATENCY LINKS ON TCP THROUGHPUT ........................................................ 23
3.2. EFFECT OF PACKET LOSS ON TCP THROUGHPUT ............................................................ ......... 24
4. EXAMPLE OF TROUBLESHOOTING A GPRS PERFORMANCE ISSUE.......................26
5. REFERENCES............................................................................................................................. 28
8/10/2019 GPRS End-To-End Performance Paper
3/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 3 of 28
1. IntroductionThe 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 metricsThere 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:
8/10/2019 GPRS End-To-End Performance Paper
4/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 4 of 28
Bandwidth
Latency
Jitter
Throughput
Throughput variability
End-to-end
performance metric
Definition
Bandwidth Number of bytes or bits transmitted across a reference point.
Latency Time it takes for a data bit to travel from one end to another of a system.
Jitter Variation of the time it takes for a data bit to travel from one end to
another of a system.
Throughput Ratio of the amount of time it takes to complete a full data transaction
Throughput variability The difference between the maximum and the minimum throughput
Errors Corruption, lost or duplication of a data packet
The performance of a GPRS -GENERALpacket 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 systemThe bandwidth of a system is dictated by the slowest link. In a GPRS system the
slowest link is the radio interface.Bandwidthis 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
8/10/2019 GPRS End-To-End Performance Paper
5/28
8/10/2019 GPRS End-To-End Performance Paper
6/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 6 of 28
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 whichBW is calculated: application, UDP, IP, RLC, etc. Specific formula used if any
As another example if it is necessary to measure theBW at the radio interface (PCU or
mobile) the following formula is recommended:
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 theBWMS IP layerspecified 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.
1TS 2TSUDP throughput
(kbps) CS-1 CS-2 CS-1 CS-2
DLBWPCU LLC layer 7.33 11.00 14.66 22.00
ULBWPCU LLC layer 6.67 10.00 13.34 20.00Table 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 termpacket is used instead of bit.
( )
( )
( )
( ) )(20
828)(
)(20
828)(
kbpsmsblockdataRLCfirsttimestampblockdataRLClasttimestamp
bytessizepacketpacketsofnumber
BW
kbpsmsABNstartingABNending
bytessizepacketpacketsofnumberBW
layerIPMS
layerIPPCU
+
=
+=
8/10/2019 GPRS End-To-End Performance Paper
7/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 7 of 28
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 latencyand
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 latencywill 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 clientconnected 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 serverconnected 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 clientconnected 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.
Figure 1. Illustration of the four types of latency that need to be distinguished in a GPRS system.
GPRS
networkPDN
uplink latency
downlink latency
uplink round trip latency
downlink round trip latency
8/10/2019 GPRS End-To-End Performance Paper
8/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 8 of 28
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 documentwith updates for smg31.
1.2.1. Theoretical uplink latencyThe uplink latency is defined by:
Equation 3. Elements involved in the uplink latency.
Where:Px=packet processing time for node X
Ty=packet transmission time across interface Y
Equation 3contains 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.
If we consider negligible the processing times of the PC, mobile, PCU and GSN
complex Equation 3can be reduced to:
Equation 4. Simplified formula to calculate the uplink latency.
Where:
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 4for smg31are shown in Figure 2. The calculations assume
N201=1520.
21
21
2 PCCHCHCHGGSNGGSNGGSNCHCHSGSNSGSNSGSNPCUPCUPCUMSMSMSPC
PCCHCHCHGGSNGGSNGGSNCHCHCHSGSNSGSNSGSNPCUPCUPCUMSMSMSPClatency
TPTPTTPTPTPT
TPTPTPTPTPTPTUL
+++++++++++=
=++++++++++++=
21 PCSGSNSGSNPCUPCUMSMSPClatency TTTTUL +++=
DATATBFSETUPTBFPCUMS
PCIrDAMSPC
TTT
TTT
+=
+=
11
8/10/2019 GPRS End-To-End Performance Paper
9/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 9 of 28
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 latencyThe downlink latency is defined by:
Equation 6. Elements involved in the downlink latency
Where:
Px=packet processing time for node X
Ty=packet transmission time across interface Y
Equation 6contains 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.
If we consider negligible the processing times of the PC, mobile, PCU and GSN
complex Equation 6can be reduced to:
Equation 7. Simplified formula to calculate the downlink latency.
Where:
12
12
2 PCMSMSMSPCUPCUSGSNPCUSGSNSGSNCHCHGGSNGGSNGGSNCHCHCHPC
PCMSMSMSPCUPCUSGSNPCUSGSNSGSNCHCHCHGGSNGGSNGGSNCHCHCHPClatency
TPTPTPTTPTPT
TPTPTPTPTPTPTDL
+++++++++++=
=++++++++++++=
12 PCMSMSPCUPCUSGSNSGSNPClatency TTTTDL +++=
DATATBFSETUPTBFMSPCU
PCIrDAPCMS
TTTTTT
+=
+=
11
Minimum theoretical latency (UDP packet)
0
200
400
600
800
1000
1200
14001600
1800
2000
0 100 200 300 400 500 600 700 800 900 1000
UDP packet payload (bytes)
Time(ms)
UL latency 1TS CS-1
UL latency 1TS CS-2
8/10/2019 GPRS End-To-End Performance Paper
10/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 10 of 28
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 7for smg31 are shown in Figure 3.
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 latencyThe 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:
Equation 9. Elements involved in the uplink round trip latency.
The results of Equation 9 for smg31 are shown in Figure 4.
Minimum theoretical latency (UDP packet)
0
20 0
40 0
60 0
80 0
1000
1200
1400
1600
1800
0 100 200 300 400 500 600 700 800 900 1000
UDP packet payload (bytes )
Time
(ms
)DL latency 1TS CS-1
DL latency 1TS CS-2
latencydownlinkreleaseTBFuplinklatencyuplinkRTTuplink ++=
8/10/2019 GPRS End-To-End Performance Paper
11/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 11 of 28
Figure 4. Minimum theoretical uplink RTT (PING). The graph is valid for N201=1520.
1.2.4. Using PING to measure the round trip latencyThe 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.
Minimum theoretical latency (UDP packet)
0
500
1000
1500
2000
2500
3000
3500
0 100 200 300 400 500 600 700 800 900 1000
UDP packet payload (bytes)
Time(ms)
UL RTT 1TS CS-1
UL RTT 1TS CS-2
2 seconds
PING REQUEST
PING REQUEST
PING REPLY
PING REPLY
PING #1
PING #2
8/10/2019 GPRS End-To-End Performance Paper
12/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 12 of 28
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 interfacethrough 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 ofsegments before them in the network node buffers.
1.2.5. How many PINGs should be sent to have a reliable average time of the RTTOne 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 certaindegree of confidence?
Based on a mathematical analysis of the Motorola GPRS system (see reference [1])
Table 3was 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 3only
applies if the standard deviation of the PING times is around 170ms.
How should Table 3be 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%.
1TS UL, 2TS DL
Confidence (ms)No. Samples
95% 98%
4 482.585 572.796
10 305.214 362.26850 136.496 162.011
8/10/2019 GPRS End-To-End Performance Paper
13/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 13 of 28
100 96.517 114.559
300 55.724 66.141
500 43.164 51.232
1000 30.521 36.227
2000 21.582 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 GPRSFigure 6shows 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.
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 currentMotorola GPRS systemsThe 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.
Round trip time dur ing a TCP data connection and its dow nlink and uplink
components
01
2
3456
TCP segment sequence
Seconds
uplink latency
dow nlink latency
8/10/2019 GPRS End-To-End Performance Paper
14/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 14 of 28
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):
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 anda 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 termpacket is used instead ofbit.
Percentage of RTT (resolution 500ms)
0.0010.0020.0030.0040.0050.0060.0070.0080.0090.00
1900
2400
2900
3400
3900
4400
4900
5400
5900
6400
6900
7400
7900
8400
8900
9400
Interval of 500 ms
Perce
ntage(%)
PING time results:
average: 2898 msstandard deviation: 456.8 msminimum: 1956 ms
maximum: 8947 ms
8/10/2019 GPRS End-To-End Performance Paper
15/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 15 of 28
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 andthe 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). Thismeasured 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 web-
browsing.
1.4.1. Using FTP to measure GPRS throughputFTP (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-and-
wait 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.
8/10/2019 GPRS End-To-End Performance Paper
16/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 16 of 28
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 forcurrent 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 variabilityThe 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 TBFconcurrent 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-endthroughput can be expected.
Network jitter Mobile jitter: the Motorola GPRS mobile (smg29) introduces a large jitter when
processing a packet. The Figure 10shows the measured round trip time jitter (MS-
>PC->MS) for a 40 bytes packet (time-stamped at the LLC layer).
server client
BLOCK n
ACK block n
BLOCK n+1
8/10/2019 GPRS End-To-End Performance Paper
17/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 17 of 28
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 checksumprocedure. 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 ofnode congestion, buffer overflow or packet damage that makes it unrecognisable
by the hardware.
Extra packets: duplicates of previously delivered packets. The causes of this canbe 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 theapplication.
Motorola GPRS mobile (smg29) variability
0
100
200
300
400
500
600
700
0 3 6 912 15 18 21 24 27 30 33 36 39 42 45 48
No. PING (10 bytes payload)
roundtriptimeMS->PC->MS(ms)
8/10/2019 GPRS End-To-End Performance Paper
18/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 18 of 28
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 GPRSperformance
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 followingbenefits:
The IP packets are not fragmented in the SGSN in several LLC frames. Thereforelosing 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.
Figure 11shows that, on average, a small MTU value provides an end-to-end
throughput comparable to a large MTU value.
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.
8/10/2019 GPRS End-To-End Performance Paper
19/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 19 of 28
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 productBW x delay
Initial retransmission timeout:it is recommended to set the value of thisparameter 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.
FTP DL Performance V MTU
0.00
0.50
1.00
1.50
2.00
2.50
400 500 600 700 800 900 1000 1100 1200 1300 1400 1500
MTU
KBytes/sec
0.00
2.00
4.00
6.00
8.00
10.00
12.00
14.00
16.00
18.00
20.00
Kbits/s Max
Min
Avg
8/10/2019 GPRS End-To-End Performance Paper
20/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 20 of 28
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 amobile 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_mfrmshas 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 ofGPRS 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. Thefield 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 12and 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 goodcandidate.
8/10/2019 GPRS End-To-End Performance Paper
21/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 21 of 28
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.
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.
TU3
No Hopping
0.01
0.1
1
10
100
0 2 4 6 8 10 12 14 16 18 20 22 24
CI (dB)
BLER
CS1
CS2
CS3
CS4
TU50
No Hopping
0.01
0.1
1
10
100
0 4 8 12 16 20 24
CI (dB)
BLER
CS1
CS2
CS3
CS4
8/10/2019 GPRS End-To-End Performance Paper
22/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 22 of 28
Throughputs - TU3
No Hopping
0
5
10
15
20
25
0 4 8 12 16 20 24
CI (dB)
Throughput(kbit/s)
CS1
CS2
CS3
CS4
Throughputs - TU50
No Hopping
0
10
20
30
0 4 8 12 16 20 24
CI (dB)
Through
pu
t
(kbit/s
)CS1CS2
CS3
CS4
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.
8/10/2019 GPRS End-To-End Performance Paper
23/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 23 of 28
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.
Figure 16shows 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.
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 10Mbpsbandwidth). 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.
Uplink BLER for M-Cell Arena 900
0
5
10
15
20
25
30
35
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)
BLER(%) CS-1 TU 3
CS-2 TU 3
CS-1 TU 50
CS-2 TU 50
8/10/2019 GPRS End-To-End Performance Paper
24/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 24 of 28
Server NT4/SP5 Client NT4/SP5
0
0.5
1
1.5
2
2.5
3
0 1000 2000 3000 4000 5000 6000 7000 8000
RTT (ms)
Throughput(KBytes/sec)
DL 55D1 UL 55D1
Server:NT4 / SP5
MSS/MTU 1460/1500
Win 65535
Client
NT4 / SP5
MSS/MTU 1460/576
Win 65535
General:
DL bit rate: 21500 bps
UL bit rate: 9500 bps
UL/DL Latency Symmetric
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 forthe 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.
8/10/2019 GPRS End-To-End Performance Paper
25/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 25 of 28
Figure 17. Full TCP data transaction of adownlink FTP with six TCP segments lost (1kbps).
Figure 18. FullTCP data transaction of a downlink FTP over GPRS (16.8kbps).
Server and client chronological activity
1601241719
1601246719
1601251719
1601256719
1601261719
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)
TCPsequence
Tx TCP seg (server)
Rx TCP ack (server)
Rx TCP seg (client)
Tx TCP ack (client)
S erver and client chrono logical activity
2499714042
2499716042
2499718042
2499720042
2499722042
2499724042
2499726042
2499728042
T ime (s)
Tx T CP seq (server)
Rx TCP ACK (server)
Tx T CP ACK
Rx TCP seq
b
8/10/2019 GPRS End-To-End Performance Paper
26/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 26 of 28
4. Example of troubleshooting a GPRS performance issueIt is out of the scope of this document to define procedures to troubleshoot an end-to-
end 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 19shows all the loggingpoints 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 themeasuredBW 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 bepossible to measure aBWof 6kbps in the uplink and 21kbps in the downlink.
PCUBTS BSC
SGSN
GGSNCH
filters
MS-DecoderEtherpeek
Etherpeek
RADCOMfilters
8/10/2019 GPRS End-To-End Performance Paper
27/28
GPRS end-to-end performance 5thOctober 00
Jos L.Gil Motorola Confidential Proprietary Page 27 of 28
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 allthe 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.
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.
Server and client chronological activity
2499714042
2499716042
2499718042
2499720042
2499722042
2499724042
2499726042
2499728042
020
40
60
80
100
120
Time (s )
segm
entsequence
Tx TCP seq (server)
Rx TCP ACK (server)
Tx TCP ACK
Rx TCP seq
b
8/10/2019 GPRS End-To-End Performance Paper
28/28
GPRS end-to-end performance 5thOctober 00
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 filtersreveal 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