You are on page 1of 26

Performance analysis of GPRS/GSM from the single

user point of view


Jorma Kilpi, Petteri Mannersalo
VTT Information Technology
P.O.Box 1202, 02044 VTT, FINLAND
Email: {Jorma.Kilpi, Petteri.Mannersalo}@vtt.fi

Abstract
We have made simple tests and measurements of throughput, round-trip time
and packet loss over a GPRS access network. Measured values are compared to
estimated theoretical values that could be calculated beforehand.

1 Introduction
This paper reports some background work made for understanding how a GPRS access
network might affect the behavior of a typical IP-user. More precisely, some sort of
limits of this new mobile data service have been examined. The aim of the study is
twofold: First, how will the users find themselves using the new dimensions offered
by GPRS, wireless Internet connections with partial freedom from electrical networks.
Second, how will the technical limits of GPRS and the randomness of capacity show
up in the behavior of data traffic. Hence the attempt is to combine both the user point
of view and a traffic theory point of view.
Also, the emphasis is on the situation, where a GSM mobile phone equipped with
GPRS functionality acts as a modem connecting the terminal equipment (TE), i.e. the
computer of a user, to the Internet via a GSM operator’s GPRS access network. Recall
that the mobile station (MS) refers to the mobile equipment (ME) equipped with the
subscriber identity module (SIM) card. The MS may also be logically split to TE and
mobile termination (MT).
Note that GPRS is also specified to be part of UMTS, but we restrict our interest to
the existing GPRS network which is implemented as a part of a normal GSM network.
This is sometimes emphasized by writing GPRS/GSM instead of plain GPRS.
We consider only user initiated sessions where the other endpoint is some host in
the Internet. Another restriction is to consider only channel coding classes CS-1 and
CS-2 as the other classes, CS-3 and CS-4, are not implemented.
Appendix A contains explanations of the basic concepts and terminology used
throughout this paper.

1
ILIAS-2001 25th February 2002

2 Performance aspects of GPRS/GSM access network


In this section the focus is on the technical limits of the existing GPRS access networks.
More precisely, we discuss briefly the maximal possible throughput and the minimal
unavoidable delays that any user meets. It is assumed that the MS of a user is attached
to the GPRS network and a PDP context activation is made. It means that the user is
logically, but not necessarily physically, connected to the GPRS gateway support node
(GGSN). A logical connection means, amongst other things, that the user is given an
IP-address. It is also assumed that the radio interface works optimally as any sort of
retransmissions clearly decrease throughput and increase delays.

2.1 Minimal number of radio blocks generated by an IP-packet


The first thing to ask or to calculate is the minimal number of RLC radio blocks re-
quired to send a single IP-packet of a given size. We consider sizes to smaller than
1500 bytes. Figure 1 below shows the minimal number of radio blocks for each IP-
packet size with both channel codings CS-1 and CS-2. See appendix A.1.4 for details
of the calculation and assumptions that were made. Small changes in the assumptions
do not affect dramatically the slopes of the curves.
Minimal number of radio blocks
70

60 CS-1
Number of radio blocks

50

40

30 CS-2

20

10

28 576 1024 1500


IP-packet size (B)

Figure 1: Minimal number of radio blocks for each IP-packet size with chan-
nel codings CS-1 and CS-2.

2.2 Maximal possible throughput


See appendix A.1.5 and A.1.6 for the definitions of the multiframe structure and theor-
etical maximum rates. Since a typical user application is likely to send and receive IP-
packets simultaneously, blocks used for acknowledgements of RLC blocks and LLC
frames over the radio interface will be needed in both directions and some blocks from
the multiframe structure are hence used on signalling channels carrying acknowledge-
ments. For example, if we assume that on average 1 block per multiframe of each
PDCH is used on transferring other than blocks that carry user data, we get the follow-
ing table 1 instead of table 7 of appendix A.1.6.

2
ILIAS-2001 25th February 2002

Table 1: Transfer rates (kbps) when on average 11 blocks per multiframe of


each physical channel carry user data.

Number of time slots


1 2 3 4
CS-1 8.30 16.59 24.89 33.18
CS-2 12.28 24.57 36.85 49.13

2.3 Minimal necessary delays


Here it is assumed that the number of time slots that the user is allocated and the chan-
nel coding scheme do not change during these considerations. Uplink and downlink
PDCHs are independent of each other, hence we handle them separately.

2.3.1 Uplink delays


Starting from terminal equipment, there is some transfer delay between TE and MS.
This delay is not a bottleneck but the delay per packet depends on the packet size.
Then there is possible buffering in SNDCP layer and building of LLC frame(s) in
MS. These delays are essentially independent of the packet size.
Temporary Block Flow (TBF) establishment, i.e. reservation of radio resources, is
performed only in the beginning of the first radio block. There is a random backoff
time if resources are not available.
In the radio interface the delay is directly related to the size of the IP-packet being
sent and proportional to the number of time slots being used. Figure 2 below shows the
minimal unidirectional delay of the radio interface for different time slot allocations.
12 PDTCH blocks per multiframe 11 PDTCH blocks per multiframe
1 1

1 TS
1 TS
0.8 0.8

0.6 0.6
Delay (s)

Delay (s)

2 TS 2 TS
0.4 0.4
3 TS 3 TS

0.2 0.2
4 TS 4 TS

28 576 1024 1500 28 576 1024 1500


IP-packet size (B) IP-packet size (B)

Figure 2: Minimal unidirectional delays over the radio interface for each
IP-packet size with channel coding CS-2 and different numbers of time slots
allocated.

3
ILIAS-2001 25th February 2002

The calculation made for the left-hand picture of figure 2 does not take into ac-
count signalling. In the right-hand picture we assumed that on average 1 block per
multiframe of each PDCH is used on signalling, i.e. 11 blocks can be used with those
PDTCH blocks that carry user data.
Reassembly of blocks to frames and frames to IP-packets again should not essen-
tially depend on the packet size.
Delays after the radio interface inside the operator’s GSM-network and in the
GPRS backbone network are small relative to the delay of the radio interface.

2.3.2 Downlink delays


In the downlink direction the delay of radio interface is basically the same, altough
reservation and releasing of radio resources differ a little. The base station needs to
manage the resource allocation and signalling communication with several MSs, but
properly dimensioned it should be able to do that during rather heavy busy hours still
with small delays. General system level signalling from network to MS requires one
block per multiframe of one of the allocated downlink PDCHs, but if there are 2 or
more downlink PDCHs available, the effect of this is reasonably small.

2.3.3 Up- and downlink delay


Figure 3 shows the minimal delay for each packet size when the radio interface and the
interface between TE and MS is crossed twice, i.e. when a packet of the same size is
sent uplink and received downlink. In the left-hand picture we assumed 12 blocks per
multiframe of one PDCH, in the right-hand picture we assumed 11 blocks on average.
The curve with higher slope assumed 1 time slot in the uplink and 3 time slots in the
downlink direction, whereas the curve with lower slope assumed the symmetric 2+2
situation. The data transfer rate between TE and MS was assumed to be 115.2 kbps in
one direction.
From TE to network and back From TE to network and back
1.6 1.6

1.4 1.4

1.2 1.2

1 1
Delay (s)

Delay (s)

0.8 0.8

0.6 1+3 TS 0.6 1+3 TS

0.4 2+2 TS 0.4 2+2 TS

0.2 0.2

28 576 1024 1500 28 576 1024 1500


IP packet size (B) IP packet size (B)

Figure 3: Minimal delays when a packet of same size is transmitted from TE,
echoed back right after the radio interface and received at TE.

4
ILIAS-2001 25th February 2002

The right-hand picture of figure 3 shows that increasing the IP-packet size by one
byte might increase the delay by 100 ms in the worst case.

2.4 Delays due to mobility management


GPRS introduces some new aspects that are added to GSM mobility management.
Here the interest is on the case when the MS is in move while transmitting and receiv-
ing IP-packets. Change of a base station may cause small or large delays.
Radio Resource (RR) management operates in idle or transfer modes. In idle mode
no TBF exists, TBF establishment automatically moves RR management to transfer
mode. When the MS selects a new cell while it is transmitting or receiving, it first
leaves the transfer mode and enters the idle mode. In idle mode the MS switches to
the new cell, reads the system information and then returns to the transfer mode in the
new cell [2]. This delay need not be very large, since cell re-selection in GSM is quite
fast.
The LLC connection between MS and Serving GPRS Support Node (SGSN) is
maintained as the MS moves between such cells, that are served by the same SGSN.
But when the MS moves to a cell being served by another SGSN, the existing connec-
tion is released and a new logical connection is established with the new SGSN [1]. It
is quite clear that this delay must be about several seconds, since the signalling delays
for LLC frames between LLC layers in the MS and in the old and new SGSN takes
about a second.

3 Performance aspects from the user point of view


The IP-user sees the effects of the structural delays presented in the previous section,
but not directly. When thinking from the user point of view, the performance aspects
can be listed as user data throughput, round-trip or response time, packet loss and the
effects of mobility.

3.1 User data throughput


There is essentially no limit on how bad throughput the user might get and even a
simple question like how long a single down- or uploading will last on average is very
hard.

3.2 Round-trip time (RTT)


The round-trip time that the user finds has some technical or even physical limitations
and some more or less random effects.
The quality of radio environment and distance from the source MS to the closest or
optimal Base Transceiver Station (BTS) can be considered as a random effects since
the user hardly knows the closest BTS. This affects on the channel coding scheme. The
channel coding scheme can be assumed to be typically the fastest possible in urban and
suburban areas.

5
ILIAS-2001 25th February 2002

The destination is typically some server in the Internet, and thus one should also
take into account the number of hops, server delay, bottleneck links and physical dis-
tance. These factors should of course be somehow eliminated when planning a meas-
urement or a test for the performance of GPRS, but an ordinary user does not want to
consider these factors.
Considering the number of available TDMA time slots that the MS of a user can
be allocated during active sending and receiving, the technical limitations are what the
ME supports, i.e. its multislot class, and what the operator supports or allows. Random
effects are the intensity of ordinary GSM calls and data traffic from other GPRS users.
These random effects bring also the time into considerations as the number of available
time slots vary in time.
When no QoS is supported, the transfer protocol, like TCP or UDP, should not have
any effect on the GPRS part of round-trip time as GPRS should see only IP-packets.
The behavior of the host may of course differ according to the protocol and this may
affect on the round-trip time.
The effect of packet size was alredy described.

3.3 Packet loss


User applications cannot distinguish between a virtually lost packet, i.e. when a packet
appears lost due to large delays, and a truely lost packet. The essential question is, of
course, how long it is worth to wait for one packet.

3.4 The effects of mobility


Mobility allows to have Internet connections from varying positions other than home
or office. By stable positions we mean connections from for example cafeterias, hotel
rooms, airports, train stations, bus stations, etc.
In principle, mobility offers also an opportunity to have Internet or WAP connec-
tions from moving positions like for example taxi, bus, train or ship. Also, use of WAP
is possible while cycling or walking, although these could be considered as practically
stable positions.
One of the possible near future applications, an MS equipped with a digital camera,
clearly benefits from mobility.
The above listed items are the main advantages of GPRS.

4 The measurement scenarios and results


First we discuss some problems found by other people, see e.g. [9], when measuring
the performance of other GPRS access networks from the user point of view: GPRS
coverage is uneven, PDP context activation requires many attempts, unexpected loss of
PDP context and long delays occur due to crossing of routing area boundaries. In our
experience of Radiolinja’s network the PDP context activation was typically successful
in the first attempt, and unexpected loss of PDP context was also rare although it did
happen a few times. It is very hard to know whether the failure of activation or the loss
of context has been due to the network. In a very simple car test we found long delays
which most probably were due to crossing of location or routing area boundaries.

6
ILIAS-2001 25th February 2002

Other problems, round-trip time delays, delay variations and packet losses are
easier to measure. Also, throughput in various situations, like with different proto-
cols, different positions or even moving positions can easily be tested.

4.1 Measurement framework


Appendix B contains more details and figures of the tests and measurements that were
done. The two mobile equipments, ME1 and ME2, that were used are described in B.2.
The mean difference for these MEs is that the multislot class of ME1 was 4 whereas
ME2 was able to change its multislot class from 4 to 5 if there were enough data in the
uplink direction. Table 2 shows all measurement combinations that were used and also
the abbreviations that are used in labels of pictures. The request period (RP) refers to
the time gap between two echo request packets in a single ping command. The
reason for introducing RP was that ME1, with only 1 time slot in the uplink direction,
introduced systematic delays with 1 second RP for large packets. This is explained in
appendix B.5 in more detail.

Table 2: Combinations used in the measurements and the corresponding ab-


breviations used in the pictures.

ME Serial cable (SC) Request


or Infrared (IR) period (RP)
ME1 SC 1s, 2s
ME1 IR 1s, 2s
ME2 IR 1s

However, the infrared between TE1 and ME1 did not work optimally so that we
have left this combination out of pictures. See figure 16 of appendix B.5.1.
One of the pinged host, denoted by Host 1, was a router of Radiolinja which is
just behind the GPRS backbone network, another host, denoted by Host 2, was further
behind a 11 hops long Internet path.
TE1 with Linux was used in the measurements. In addition to that, TE2 with
Windows 2000 and TE3 with Windows 95 were used in different types of tests. The
properties of TEs are described in B.3.

4.2 The minimum round-trip time


The key idea is simply that a observed minimum round-trip time over a very large
number of RTT measurements, 1200 per each IP-packet size, should happen only when
the following conditions hold both in up- and downlink direction: radio resources
have been practically immediately available, the radio environment has been close to
optimal and the throughput during the transfer of packet has been close to maximum
possible in both up- and downlink direction. Hence we can assume that observed
minimal delays have necessarily been close to minimum possible.
The first hypothesis is thus that the minimum round-trip time depends on the packet
size approximately as was calculated in figure 3. Indeed, the left-hand picture of figure

7
ILIAS-2001 25th February 2002

4 shows the anticipated shape. The purpose of the right-hand picture of figure 4 and
the left-hand picture of figure 6 that the minimum RTT is really a quite stable property.

Minimum RTT Minimum RTT, ME1, SC, RP = 2s


2.5 2.5

ME1, SC, RP = 2s
2 2
ME1, SC, RP = 1s
RTT (s)

RTT (s)
1.5 1.5

1 1

ME2, IR, RP = 1s
0.5 0.5
36 292 548 804 1060 1316 36 292 548 804 1060 1316
IP-packet size (B) IP-packet size (B)

Figure 4: The left-hand picture shows the minimum RTT for both MEs. The
right-hand picture shows the result of three measurements of minimum RTT,
one made in Otaniemi, Espoo and two made in Käpylä, Helsinki.

Figure 5 below shows microscopic view of the minimum RTT. In this case there
were only 100 RTT-measurements for each possible IP-packet size between a short
packet size interval, which is not enough to get the minimal possible RTT in all of
the sizes. However, the microscopic views show that the linearly looking shape of the
pictures of figure 4 is a global property. The local view brings visible the structural
shape caused by the radio interface.
Microscopic view of the minimum RTT Microscopic view of the minimum RTT
2.5 2.5

2 2
RTT (s)

RTT (s)

1.5 1.5

1 1

0.5 0.5
40 50 60 70 80 1390 1400 1410 1420 1430 1440
IP-packet size (B) IP-packet size (B)

Figure 5: Microscopic view of minimum RTT. The measurement combination


in these pictures was ME1, SC and RP = 2s. Each IP-packet size was an
argument in one ping command with 100 RTT-measurements.

8
ILIAS-2001 25th February 2002

Let seq.no denote the ICMP sequence number of a ping packet in a single
ping command which sends 100 echo request packets. The value of seq.no
runs from 0 to 99. The first ping packet contains a systematic delay due to reservation
of radio resources and also due to other factors that depend on the computer hardware
and on the operating system [10]. We cannot know whether other ping packets con-
tain delay due to radio resource reservation but the first packet always contains it due
to 60 seconds sleep period between each ping command.
Let x denote the IP-packet size. The second hypothesis is that the value of the
difference

r [x] = seq.no
d min RT T [x]
=0
min
seq.no>0
RT T [x]

is independent of packet size x. The r can be considered as an estimator of the


d

minimal TBF establishment delay.


Minimum RTT, ME2, IR, RP = 1s ME2, IR, RP = 1s
2.5
1.4

2 Host 2
1.2
RTT (s)

dr [x] (s)

1.5 Host 1 1 Host 1

1 0.8

0.6
0.5 Host 2
36 292 548 804 1060 1316 36 292 548 804 1060 1316
IP-packet size (B) IP-packet size (B)

Figure 6: The left-hand picture shows the result of two minimum RTT meas-
urements for ME2. The right-hand picture shows the value of dr in these
measurements. In these pictures the pinged host was different but the posi-
tion of MS was the same, Otaniemi.

The left-hand picture of figure 7 shows examples of the measured values of dr


with both ME1 and ME2. They are clearly of different scale. The right-hand picture
of figure 6 show that the value of dr is quite stable for ME2, the right-hand picture of
figure 7 shows the same for ME1.
It seems that ME1 and ME2 use different methods to allocate and transmit, see
appendix A.1.7 and A.1.8. For example, an explanation to the difference of the value of
dr for the two MEs could be that ME1 uses one phase access in resource allocation and

fixed allocation whereas ME2 uses two phase access and dynamic or even extended
dynamic allocation. In this way ME2 loses some time before the data transfer begins,
but wins that time back when the time for continuous data transfer gets longer.
The jump that occurs for ME2 in the value of dr between 412 and 548 bytes prob-
ably refers to the change of multislot property from 1 + 3 to 2 + 2, i.e. when there
are enough packets or the single packet size exceeds a threshold, ME2 always tries to

9
ILIAS-2001 25th February 2002

Examples of dr [x] ME1, SC, RP = 2s


0.4
1.4
0.35
1.2
ME2, IR, RP = 1s 0.3 Kapyla
1 Kapyla
dr [x] (s) 0.25 Otaniemi

dr [x] (s)
0.8
0.2
0.6 0.15

0.4 0.1
ME1, SC, RP = 1s

0.2 0.05
ME1, SC, RP = 2s
36 292 548 804 1060 1316 36 292 548 804 1060 1316
IP-packet size (B) IP-packet size (B)

Figure 7: The measured value of dr [x] for different IP-packet sizes. The
left-hand picture shows the difference between the two MEs, the right-hand
picture shows the result of three different measurements for ME1.

allocate two time slots in the uplink direction. The hypothesis that the value of dr is
independent of packet size has to be reformulated.

4.3 Lost packets


Figure 8 shows examples of packet loss per each packet size that occured in the RTT
measurements. These losses are total losses, containing both up- and downlink losses.
A natural question to ask is whether packet loss probabilty in the uplink differs from
that of downlink.
ME1, SC ME2, IR, RP = 1s
4
12
3.5
10
Percentage of lost packets

Percentage of lost packets

8 2.5
RP = 1s Host 1
6 2

1.5
4
Host 2
1
2 RP = 2s
0.5
RP = 2s

36 292 548 804 1060 1316 36 292 548 804 1060 1316
IP-packet size (B) IP-packet size (B)

Figure 8: Total packet loss percentages per IP-packet size. Note that the
scale of y-axes differ, the observed packet loss for ME2 was essentially smal-
ler than for ME1.

10
ILIAS-2001 25th February 2002

Here the idea was to run the systematic ping procedure while the tcpdump
program in the pinged host recorded the request and reply packets. This allows to
figure out whether packets were lost in the up- or downstream direction. Unfortunately,
for practical reasons, the pinged host had to be host 2. Hence we must talk of usptream
and downstream directions, instead of plain uplink and downlink of the radio interface
of GPRS.
In figure 9 we probably see the effect of blocking as two ping commands lost all
their packets. Since the following commands were again successful, the most probable
explanation is that no radio resources were available for that time.
Packet loss per current number Packet loss in time

Cumulative percentage of lost packets


Cumulative percentage of lost packets

4 ME1, SC, RP = 2s 4 ME1, SC, RP = 2s

3 3

2 2

1 1 ME2, IR, RP = 1s

ME2, IR, RP = 1s
1 7200 14400 1 2 3 4 5 6 7 8 9 10
i:th packet Time (h)

Figure 9: Cumulative total packet loss per order of packet on the left, and per
time from beginning on the right. For ME2 with RP = 1s the measurement
lasted almost 7 hours, for ME1 with RP = 2s the duration was almost 11
hours.

Table 3 below shows the total packet loss percentages in both directions. The
percentages are scaled according to those packets that really has been sent, i.e. those
packets which actually have not been sent at all are removed when scaling.

Table 3: Total packet loss percentages in up- and downstream direction.

ME Total packet loss percentages


upstream downstream
ME1 3.43% 0.88%
ME2 1.23% 0.15%

Figure 10 shows how the packet loss depends on packet size. In the specification
[2] it is already noted that the one phase resource allocation is somewhat insecure.
This could also well explain the difference between the two MSs.

11
ILIAS-2001 25th February 2002

Upstream Downstream
4 4

Percentage of lost packets


Percentage of lost packets
3 ME1, SC, RP = 2s 3

2 2

ME1, SC, RP = 2s

1 1
ME2, IR, RP = 1s ME2, IR, RP = 1s

36 292 548 804 1060 1316 36 292 548 804 1060 1316
IP-packet size (B) IP-packet size (B)

Figure 10: Packet loss per packet size percentages for upstream and down-
stream directions.

4.4 Testing the throughput


Some up- and downloading were made with File Transfer Protocol (FTP). These were
typically slow but successful in the stable position and hopeless in the moving position,
car or train. The simple measurement framework, running tcpdump program in TE, is
too coarse for to measure the throughput very accurately. Figure 11 shows an example
of six downloadings in a picture, where a cumulative volume that is already received
by time t is plotted against the time t. The solid lines represent the instantaneous bit
rates with CS-2 and 1, 2 or 3 time slots.
6 TCP downloadings with ME1

1.2 2 x 13.4kbps

1.0 3 x 13.4kbps
Volume (MB)

0.8

0.6
13.4kbps
0.4

0.2

0 100 200 300 400 500 600


Time (s)

Figure 11: Cumulative volume against time for six downloadings of the same
file of fixed size 1.2MB.

Radiolinja offers a data compression service that can be used for web browsers in
Windows. It consists of a proxy server in the TE which connects to a compression
server in Radiolinja’s network. Data packets, that are transmitted over the radio inter-

12
ILIAS-2001 25th February 2002

face, are UDP datagrams. In addition to data compression, some data is also filtered
out and a user can select the quality levels of e.g. graphics that he/she wants to get.
This was tested with TE2 by surfing through the same web pages with and without
data compression. The effect was sometimes clearly visible, sometimes less. The
main problem was the connection establishment to compression server, which took
quite often several seconds.

5 Conclusions and further work


Two phase access and dynamic resource allocation are better than one phase access
and fixed resource allocation.
The ability of ME to change between multislot classes according to the traffic load
is better than fixed multislot class for ME.
Uplink properties of a ME, resource allocation method and time slot limit, are not
the bottleneck features for ordinary web surfing. But with only one time slot any kind
of uploading is a rather painful task for a busy user.
Minimum RTT, estimator of minimum TBF establishment delay and packet loss
probability per packet size seem to be suprisingly stable properties for these two MEs.
The effect of other GSM users has been seen in that the time slot allocation in some
ping commands has not been the best possible or the allocation is blocked totally.
The load of other GPRS users during the end of year 2001 when first measurements
were performed has been rather small. Those measurements that might have showed
signs of other users were performed in January and February 2002.
Acknowledgements. We are grateful for Mika Sarén from Radiolinja for provid-
ing us the SIM card used and for Yrjö Raivio from Nokia Networks for lending us the
Nokia 8310 phone.

References
[1] 3GPP TS 03.60:“Digital cellular telecommunications system (Phase 2+); General
Packet Radio Service (GPRS); Service description; Stage 2”.

[2] 3GPP TS 03.64:“Digital cellular telecommunications system (Phase 2+); General


Packet Radio Service (GPRS); Overall description of the GPRS radio interface;
Stage 2”.

[3] 3GPP TS 04.60:“Digital cellular telecommunications system (Phase 2+); General


Packet Radio Service (GPRS); Mobile Station (MS) - Base Station System (BSS)
interface; Radio Link Control/Medium Access Control (RLC/MAC) protocol”.

[4] 3GPP TS 04.64:“Digital cellular telecommunications system (Phase 2+); General


Packet Radio Service (GPRS); Mobile Station - Serving GPRS Support Node
(MS-SGSN) Logical Link Control (LLC) layer specification”.

[5] 3GPP TS 04.65:“Digital cellular telecommunications system (Phase 2+); General


Packet Radio Service (GPRS); Mobile Station - Serving GPRS Support Node
(SGSN); Subnetwork Dependent Convergence Protocol (SNDCP)”.

13
ILIAS-2001 25th February 2002

[6] GSM 05.01:“Digital cellular telecommunications system (Phase 2+); Physical


layer on the radio path; General description”.

[7] GSM 05.01:“Digital cellular telecommunications system (Phase 2+); “Multiplex-


ing and multiple access on the radio path”.

[8] 3GPP TS 07.60:“Digital cellular telecommunications system (Phase 2+); General


Packet Radio Service (GPRS); Mobile Station (MS) supporting GPRS”.

[9] Korhonen, J., Aalto, O., Gurtov, A., Laamanen, H., “Measured Performance of
GSM HSCSD and GPRS”, IEEE International Conference on Communications
2001.

[10] Stevens, W. R., “TCP/IP Illustrated, Volume 1”, Addison-Wesley Publishing


Company, 1994

A Some properties of GPRS/GSM in a nutshell


This appendix summarizes very briefly the basic concepts that are needed to under-
stand about GPRS/GSM for reading this paper. The reader is assumed to know only
some general properties of GSM. The material is collected from specifications [1, 2, 3,
4, 5, 6, 7, 8] and hence contains no originality from the authors side, except possible
(but hopefully not serious) errors.

A.1 Radio interface between MS and GPRS network


A.1.1 Protocol layers
Table 4 below shows the protocol layers of GPRS and some of their functionalities
relevant for the purposes of this paper. These layers appear both in the MS and in the
network side. In the network side the LLC is split between Base Station Subsystem
(BSS) and Serving GPRS Support Node (SGSN).

A.1.2 Time slots and physical channels


The basic radio resource, which can be allocated to a user is a time slot (TS), which
has a duration of 15=26  0:577 milliseconds. Eight successive time slots form a
TDMA frame. In the context of packet data traffic, successive TDMA frames form
multiframes and superframes as explained in table 5. These differ from GSM.
Every 13th TDMA frame is either a timing advance (TA) frame or an idle (I) frame,
they do not carry any data. The MS uses TA frames to synchronize itself with the base
station and, since uplink and downlink directions are independent of each others, TA
frames are required for the synchronzation of both directions independently. During
the I frames MS monitors the neighboring GSM-cells for to choose an optimal cell.
Time slots inside a TDMA frame are numbered from 0 to 7. In this way 8 physical
channels characterized by frequency parameters and time slot number (TN) are multi-
plexed into one basic physical channel which is characterized by frequency parameters
only. In the following the term physical channel refers to physical channel determined
by frequency parameters and TN. A fixed physical channel uses always the same TN

14
ILIAS-2001 25th February 2002

Table 4: Protocol layers of GPRS

IP
Subnetwork Dependent Convergence Protocol (SNDCP)
-possible segmentation of IP-packets
-buffering of IP-packets
Logical Link Control (LLC)
-framing of data segments coming from SNDCP
-flow control of LLC frames
-detection and recovery from lost or corrupted LLC frames
and retransmissions of LLC frames in acknowledged mode
Radio Link Control/Media Access Control (RLC/MAC)
-reservation and release of radio resources
-segmentation of LLC frames to RLC radio blocks
-selective retransmissions of erroneous RLC data blocks
in acknowledged mode
-re-assembly of RLC radio blocks to LLC frames
GSM RF

Table 5: The TDMA frame structure of GPRS/GSM.

Definition Duration (ms)


Time slot (TS) Basic unit 15/260.577...
TDMA frame 8  TS 60/134.615...
Multiframe 52  TDMA frame 240
Superframe 8  Multiframe 1920

15
ILIAS-2001 25th February 2002

in every TDMA frame. Allocation of radio resources means that the MS is given the
frequency parameters and the TN that it can use. In a multislot operation more than
one time slot may be used by one MS. According to specifications, even all 8 time
slots of a TDMA frame may be allocated to one MS.
The maximum number of time slots that a MS can be allocated depends on the
multislot class to which it belongs. Table 6 below describes only first 8 classes out of
29 classes defined [7]. The columns Rx and Tx in table 6 refer to maximum number

Table 6: First 8 MS classes for multislot capability.

Multi- Maximum number


slot of time slots
class Rx Tx Sum
1 1 1 2
2 2 1 3
3 2 2 3
4 3 1 4
5 2 2 4
6 3 2 4
7 3 3 4
8 4 1 5

of receive and transmit time slots per TDMA frame that the MS can use, and column
Sum refers to the total number of uplink and downlink time slots that can be used by
the MS per one TDMA frame.

A.1.3 Logical channels


The physical channel which is reserved for packet data traffic is called a Packet Data
Channel (PDCH). Logical channels used for signalling and data transfer are mapped
onto physical channels, i.e. onto one or more PDCH’s. Different logical channels can
occur on the same PDCH, the section A.1.5 below describes the sharing of PDCH
more closely.
The logical channel that is allocated to data transfer is called Packet Data Traffic
Channel (PDTCH). One PDTCH is mapped onto one physical channel whereas logical
channels used for signalling may usually be mapped onto several physical channels.
One PDTCH is temporarily dedicated to one MS in either uplink or downlink direction,
and in the multislot operation one MS may use multiple PDTCHs in parallel and in the
opposite directions for individual packet data transfer.

A.1.4 LLC frames and RLC radio blocks


In convergence layer (SNCDP) an IP-packet coming from network layer is first split
into segments of size not exceeding the value of a parameter named N201-I. Accord-
ing to [4] this parameter has default value 1503, and the value is allowed to range

16
ILIAS-2001 25th February 2002

from 140 to 1520 octets. In the calculations we have assumed this default value. IP-
packets of size smaller than 1500 bytes are hence not segmented in this case. Anyhow,
a smaller segment size in this layer increases the overhead induced by lower layers.
In logical link layer (LLC) a LLC frame header and a Frame Check Sequence field
tailer are added to a segment coming from the above convergence layer. This unit is
then called a LLC frame. The header consists of Address field and Control field. The
Address Field consists of one octet, the Control Field is of variable length but when
carrying user data in acknowledged mode it should be of length 3 octets [4]. The
Frame Check Sequence field is of length 3 octets.
In radio link layer (RLC) the LLC frame is split into segments of size either 181
bits or 268 bits according to channel coding scheme, CS-1 or CS-2 respectively, used.
Some bits are then added to these segments to form a header and a tailer and, with
these additional bits the segments are called RLC radio blocks.
In channel coding these blocks go through a convolutional coding and, in the case
of CS-2, some of the coded bits are removed so that the resulting block size is 456
bits in both channel codings. These 456 bits are transmitted in four normal bursts, one
burst carrying 114 bits of the block. One burst is transmitted in one time slot, this burst
being the physical content of the corresponding time slot.

A.1.5 Multiframe structure for PDCH


The sharing of the physical channel to logical channels is based on blocks of 4 con-
secutive bursts, exception being only the logical channels dedicated to the estimation
of the timing advance. In a multiframe these blocks are numbered from B0 to B11, as
shown in figure 12. The actual usage of the blocks is indicated in the block header.

 52 TDMA frames -
B0 B1 B2 T B3 B4 B5 I B6 B7 B8 T B9 B10 B11 I

Figure 12: Multiframe structure for PDCH.

The mapping of logical channels onto the blocks is defined by means of ordered
list

( B0, B6, B3, B9, B1, B7, B4, B10, B2, B8, B5, B11 ): (1)

For example, if there three logical channels are to be mapped, the first logical channel
uses first n1 blocks from the list (1), the second uses next n2 blocks and the third
logical channel uses last 12-(n1 + n2 ) blocks. In the one downlink PDCH, at least
block B0 is reserved for general signalling purposes, [2]. All other blocks in this and
other possible down- and uplink PDCHs can in principle be used for blocks carrying
user data and associated signalling blocks that carry acknowledgements.

A.1.6 Maximum transfer rates


A simple calculation of (12  CS  TS)=(240 ms ), where CS is either 181 or 268 bits
according to channel coding used, and TS is either 1,2,3 or 4 according to the time

17
ILIAS-2001 25th February 2002

Table 7: Theoretical maximal transfer rates (kbps).

Number of time slots


1 2 3 4
CS-1 9.05 18.10 27.15 36.20
CS-2 13.40 26.80 40.20 53.60

slots allocated to a user, leads to the transfer rates of table 7 below. More realistic
calculation is performed in the main text.

A.1.7 Reservation and release of radio resources


A Temporary Block Flow (TBF) is a physical connection between two Radio Resource
(RR) entities to support the unidirectional transfer of LLC frames on PDCHs. The
TBF is an allocated radio resource on one or more PDCHs and contains a number
of RLC/MAC blocks carrying one or more LLC frames. A TBF is temporary and is
maintained only for the duration of the data transfer which means until there are no
more blocks to be transmitted and all the transmitted blocks have been acknowledged
by the receiving RR entity. Concurrent TBFs may be established in opposite directions.
In a resource assignment message, which comes from network to MS, each TBF is
assigned a unique Temporary Flow Identity (TFI) by the network. TFI is used instead
of the MS identity in the RLC/MAC layer and it is included in every RLC header
which belongs to the corresponding TBF.
Allocation of radio resources can happen in one or two phases. In one phase access
the network may not know exactly which MS owns the allocation until first block from
the MS is received by the network. In two phase access, the MS which requested for
resource allocation is automatically uniquely defined. Both the network and the MS
can require the two phase access.
In principle, three different medium access modes are supported. They are called
fixed allocation, dynamic allocation and extended dynamic allocation. According to
[2] Release 1997, the support for extended dynamic allocation is optional.

A.1.8 Transmitting and receiving


In dynamic allocation the network gives to the MS a list of physical channels and the
corresponding Uplink State Flag (USF) value per each PDCH. The MS monitors the
USFs on the allocated PDCHs and transmits blocks on those which currently bear the
USF value reserved for the MS. The MS may be allowed to use the uplink resources
as long as there is queued data on the RLC/MAC layer to be sent from MS which can
include a number of LLC frames.
The fixed allocation consists of a start time, slot assignment and block assignment
bitmap which represents the assigned blocks per time slot. The MS waits until the
start frame indicated and then transmits radio blocks on those blocks indicated in the
bitmap. No USF is used, the network uses the unused USF value to prevent other MSs
to transmit. In fixed allocation the number of blocks an MS requests to send account

18
ILIAS-2001 25th February 2002

for the number of data blocks it intends to send, i.e. the MS does not request additional
blocks beforehand for the retransmission of erroneous blocks.
The PDCH where the MS may expect occurence of its downlink PDTCH blocks
are indicated in resource allocation messages. The mobile owner of the downlink
PDTCH blocks is indicated by TFI value in the block header.
Successive transfer of more than one LLC frame is possible, and if the contents
of a LLC frame do not fill an integer number of radio blocks, the beginning of the
next LLC frame is placed within the last radio block of the previous LLC frame, with
no padding or spacing in between. If the final LLC frame in the TBF does not fill an
integer number of radio blocks, filler octets shall be used to fill the remainder of the
last block.

A.2 The interface between TE and MT


The MS may be logically split to terminal equipment (TE) and mobile termination. If
the TE is not ISDN compatible, the interface between TE and MT contains a reference
point called R. In this case the main functions of the MT to support data services are
the physical connection at the reference point R and flow control between TE and
MT. According to [8] the physical interface may conform to CCITT/ITU-T V.24/V.28,
or to IrDA IrPHY physical standard specification, or to PCMCIA PC-Card electrical
specification.

B Some more details of measurements


B.1 The operator
The operator Radiolinja launched its commercial GPRS service in October 2001. As
related to standards, the implementation satisfies Release 1997 3GPP specifications.
The very first tests were made already in september 2001, when the GPRS functional-
ity was only open for test users, and the last measurements were performed in February
2002.

B.2 Mobile equipments


Table 8 shows the basic properties of MEs that were used in the measurements. In
the main text and figures they are referred as ME1 and ME2 only since the aim of
this paper has not been to compare the two MEs. Such a comparison would anyhow
be very unfair since the MEs have different multislot capabilities and ME1 is at least
half a year older model. On the other hand, having the possibility for three different
physical connection between TE and ME1 is clearly superior when compared to a
single possibility of only infrared that ME2 offers.

B.3 Terminal equipments


Table 9 shows the basic properties of computers that were used as TEs. In the text and
figures they are referred as TE1, TE2 and TE3. TE1 and TE2 are laptop computers.
TE1 with Linux was used in the measurements, TE2 and TE3 were mainly used
for different types of tests.

19
ILIAS-2001 25th February 2002

Table 8: Mobile equipments.

ME1 ME2
Vendor Ericsson Nokia
Model T39m 8310
Multislot class 4 4 and 5
Infrared IrDa and IrDa-Ultra Yes
Serial cable V.24 No
Bluetooth Yes No

Table 9: Terminal equipments.

TE1 TE2 TE3


Vendor Dell Dell Dell
Model Latitude CPi Latitude C600/C500 OptiPlex
Operating system Linux Windows 2000 Windows 95
Processor Pentium II Pentium III Pentium II
Infrared (IR) Yes Yes No
Serial cable (SC) Yes Yes Yes
Bluetooth No No No

B.4 The inteface between TE and MT


The connection from the computer to the phone was handled via Point-to-Point Pro-
tocol (PPP). Table 10 shows some of the options of PPP that were used with Linux.
The point of these options is typically to disable some ordinary modem options as the
MS, when acting as a modem, does not support these.
It required some work to get the TE1 with Linux to work properly with both MEs
over infrared and ME1 over serial cable. The transfer rate between TE1 and MEs could
in all cases be specified to be the same, 115.2 kbps.
The vendors’ supplement modem drivers were used in TE2 and TE3 with Win-
dows. These drivers were downloaded from the vendors’ web pages. The ’plug and
play’ principle almost works with Windows 2000, although some problems did occur.
For example, after the infrared driver for ME2 was istalled in TE2, the infrared driver
for ME1 did not work any more and had to be reinstalled.

B.5 Systematic ping procedure


The systematic ping procedure was typically performed according to the type of al-
gorithm described in figure 13:
The algorithm described in figure 13 generates 12  12 = 144 ping commands,
each sending 100 echo request packets making a total of 14400 request packets.
For each packet size, 12  100 = 1200 request packets is sent. There was a 60 seconds
idle time after each ping command to make sure that the reserved radio resources

20
ILIAS-2001 25th February 2002

Table 10: Some options of Point-to-Point Protocol

Option Comment
receive-all Accept all control characters from
the peer.
defaultroute Add a default route to the system
routing tables.
noipdefault Not to determine the local
IP-address from the hostname.
lcp-echo-interval 0 Disable LCP echo-request frame.
novj Disable TCP/IP header compression.
novjcomp Disable connection-ID compression.
noproxyarp Disable proxy ARP.
nocrtscts Disable hardware control on the
serial port.
noauth Do not require the peer to
authenticate itself.
local Do not use the modem control lines.

sl="8 136 264 392 520 648 776 904 1032 1160 1288
1416";
for ((k = 1; k < 13; k++))
do
for size in $sl
do
ping -c 100 -i 1 -s $size host » logfile;
sleep 60;
done;
done;
Figure 13: An algorithm used in systematic ping.

21
ILIAS-2001 25th February 2002

were released.
The run of algorithm typically lasted many hours and both the phone and the laptop
had to be connected to the electrical network. The phones were able to run the al-
gorithm only about 2-3 hours with fully loaded batteries and without being connected
to the electrical network.
The largest IP-packet size that the algorithm 13 sends is of size 1444 bytes. The
largest IP-packet that we were able send and receive was 1460 bytes although GPRS
should be able to send and receive IP-packets of size 1500 bytes.

B.5.1 The request period (RP)


The option -i 1 in the algorithm of figure 13 defines the time interval between suc-
cessive echo request packets to be 1 second. This time gap is referred in some
figures as the request period (RP). With ME2 the RP was always 1 second but with
ME1 the value of RP had to be 2 seconds for large packets. The reason for this can be
seen from figures 14 and 15.
ME1, SC, RP = 1s ME1, SC, RP = 2s

14 14

12 12

10 10
RTT (s)

RTT (s)

8 8

6 6

4 4

2 2

1 13875 1 13794
i:th measurement i:th measurement

Figure 14: The output of the systematic ping algorithm with different values
for the RP.

As the ME1 has only 1 time slot available in the uplink direction and the delay of
the radio interface alone for large packets is almost one second at its best, the ME1
introduced a systematic delay with 1 second RP. Since the packets were not lost they
must have been waiting in buffers. This seems to indicate that ME1 uses fixed alloc-
ation and could not send or receive packets when one allocation was used and a new
allocation was not immediately available. Figure 15 shows this even more clearly.
Figure 16 shows the problems that we had with infrared between TE1 and ME1.

B.5.2 More round-trip time pictures


Figures 17 and 18 shows plots of points (IP-packet size, RTT).

22
ILIAS-2001 25th February 2002

ME1, SC, RP = 1s, IP-packet size =1444 ME1, SC, RP = 2s, IP-packet size =1444

14 14

12 12

10 10
RTT (s)

RTT (s)
8 8

6 6

4 4

2 2

0 50 99 0 50 99
ICMP seq.no ICMP seq.no

Figure 15: On the left: For large packets the ME1 with RP = 1s did not have
enough time for to make new radio resource allocations. On the right: with
RP = 2s no problems occur.

ME1, IR, RP = 1s, IP-packet size =164 ME1, SC, RP = 1s, IP-packet size =164

14 14

12 12

10 10
RTT (s)

RTT (s)

8 8

6 6

4 4

2 2

0 50 99 0 50 99
ICMP seq.no ICMP seq.no

Figure 16: The infrared did not work well between TE1 and ME1.

23
ILIAS-2001 25th February 2002

ME1, SC, RP = 2s ME2, IR, RP = 1s, Host 1

14 14

12 12

10 10
RTT (s)

RTT (s)
8 8

6 6

4 4

2 2

36 292 548 804 1060 1316 36 292 548 804 1060 1316
IP-packet size (B) IP-packet size (B)

Figure 17: Examples of the results of systematic ping.

ME2, IR, RP = 1s, Host 2 ME1, SC, RP = 1s

14 14

12 12

10 10
RTT (s)

RTT (s)

8 8

6 6

4 4

2 2

36 292 548 804 1060 1316 36 292 548 804 1060 1316
IP-packet size (B) IP-packet size (B)

Figure 18: Examples of the results of systematic ping.

24
ILIAS-2001 25th February 2002

ME2, IR, RP = 1s ME1, SC, RP = 2s


25 25

20 20
Percentage of lost packets

Percentage of lost packets


15 15

10 10

5 5

1 25 49 73 97 121 144 1 25 49 73 97 121 144


i:th ping command i:th ping command

Figure 19: Two examples of packet loss percentages per each ping com-
mand.

ME2, IR, RP = 1s ME1, SC, RP = 2


12 12

10 10
Percentage of lost packets

Percentage of lost packets

8 8

6 6

4 4

2 2

0 50 99 0 50 99
ICMP seq.no ICMP seq.no

Figure 20: Packet loss percentage per ICMP sequence number.

25
ILIAS-2001 25th February 2002

B.5.3 More about packet loss


Figures 19 and 20 show that there were no particular moment of time when packets
were lost except that for some ping commands all packets might have been lost. But
such a loss must be considered systematic and probably due to temporary lack of radio
resources.

26