gprs end-to-end performance paper

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


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


3/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:


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


5/28


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

+

=

+=


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


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


10/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.


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


11/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.


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


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


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


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


15/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.


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


17/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)


18/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.


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


20/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.


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


22/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.


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


24/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.


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


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


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


28/28


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

gprs end-to-end performance paper

Documents