gprs

Published on June 2016 | Categories: Documents | Downloads: 42 | Comments: 0 | Views: 434
of 26
Download PDF   Embed   Report

Comments

Content

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 required 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 IPpacket 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.
70 60 Number of radio blocks 50 40 30 20 10 CS-2 Minimal number of radio blocks

CS-1

28

576 1024 IP-packet size (B)

1500

Figure 1: Minimal number of radio blocks for each IP-packet size with channel 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 theoretical maximum rates. Since a typical user application is likely to send and receive IPpackets 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 acknowledgements. 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 following 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 8.30 16.59 24.89 12.28 24.57 36.85

CS-1 CS-2

4 33.18 49.13

2.3 Minimal necessary delays
Here it is assumed that the number of time slots that the user is allocated and the channel 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.
1 12 PDTCH blocks per multiframe 1 11 PDTCH blocks per multiframe 1 TS 0.8 1 TS 0.8

Delay (s)

Delay (s)

0.6 2 TS 3 TS 0.2 4 TS

0.6 2 TS 0.4 3 TS 0.2 4 TS

0.4

28

576 1024 IP-packet size (B)

1500

28

576 1024 IP-packet size (B)

1500

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 account 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 essentially 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.
1.6 1.4 1.2 1 Delay (s) 0.8 0.6 0.4 0.2 28 576 1024 IP packet size (B) 1500 1+3 TS 2+2 TS Delay (s) From TE to network and back 1.6 1.4 1.2 1 0.8 0.6 0.4 0.2 28 576 1024 IP packet size (B) 1500 1+3 TS 2+2 TS From TE to network and back

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 receiving 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 connection 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 distance. These factors should of course be somehow eliminated when planning a measurement 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 connections 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 protocols, 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 abbreviations used in the pictures. ME ME1 ME1 ME2 Serial cable (SC) or Infrared (IR) SC IR IR Request period (RP) 1s, 2s 1s, 2s 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 ME1, SC, RP = 1s RTT (s) 1.5 RTT (s) ME2, IR, RP = 1s 0.5 36 292 548 804 1060 IP-packet size (B) 1316 0.5 36 292 548 804 1060 IP-packet size (B) 1316 Microscopic view of the minimum RTT 1.5 2

1

1

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.
2.5 2.5 Microscopic view of the minimum RTT

2

2

RTT (s)

1.5

RTT (s) 40 50 60 70 IP-packet size (B) 80

1.5

1

1

0.5

0.5 1390 1400 1410 1420 1430 1440 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 contain delay due to radio resource reservation but the first packet always contains it due to 60 seconds sleep period between each ping command. Let Ü denote the IP-packet size. The second hypothesis is that the value of the difference

ÖÜ

seq.no

ÑÒ

¼

ÊÌ Ì Ü

  seq.no ÑÒ

¼

ÊÌ Ì Ü

is independent of packet size Ü. The minimal TBF establishment delay.
2.5 Minimum RTT, ME2, IR, RP = 1s

Ö can be considered as an estimator of the
ME2, IR, RP = 1s 1.4

2

Host 2 1.2

RTT (s)

1.5

Host 1

dr [x] (s)

1 Host 1

1

0.8

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

Figure 6: The left-hand picture shows the result of two minimum RTT measurements for ME2. The right-hand picture shows the value of Ö in these measurements. In these pictures the pinged host was different but the position of MS was the same, Otaniemi. The left-hand picture of figure 7 shows examples of the measured values of Ö with both ME1 and ME2. They are clearly of different scale. The right-hand picture of figure 6 show that the value of Ö 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 Ö 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 Ö between 412 and 548 bytes probably refers to the change of multislot property from ½ · ¿ to ¾ · ¾, i.e. when there are enough packets or the single packet size exceeds a threshold, ME2 always tries to 9

ILIAS-2001
Examples of dr [x] 1.4 0.35 1.2 1 dr [x] (s) 0.8 0.6 0.4 0.2 ME1, SC, RP = 2s 36 292 548 804 1060 IP-packet size (B) 1316 36 292 ME1, SC, RP = 1s dr [x] (s) ME2, IR, RP = 1s 0.3 0.25 0.2 0.15 0.1 0.05

25th February 2002
ME1, SC, RP = 2s

0.4

Kapyla Kapyla Otaniemi

548 804 1060 IP-packet size (B)

1316

Figure 7: The measured value of Ö Ü 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 independent of packet size has to be reformulated.

Ö is

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 12 10 8 6 4 2 RP = 2s 36 292 548 804 1060 IP-packet size (B) 1316 36 292 548 804 1060 IP-packet size (B) 1316 RP = 2s 4 3.5 Percentage of lost packets Percentage of lost packets 3 2.5 Host 1 2 1.5 1 0.5 Host 2 ME2, IR, RP = 1s

RP = 1s

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 smaller 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 Cumulative percentage of lost packets Cumulative percentage of lost packets 4 ME1, SC, RP = 2s 4 Packet loss in time ME1, SC, RP = 2s

3

3

2

2

1

1

ME2, IR, RP = 1s

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

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 ME1 ME2 Total packet loss percentages upstream downstream 3.43% 0.88% 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
Upstream 4 4

25th February 2002
Downstream

Percentage of lost packets

Percentage of lost packets

3

ME1, SC, RP = 2s

3

2

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

1 ME2, IR, RP = 1s

36

292

548 804 1060 IP-packet size (B)

1316

36

292

548 804 1060 IP-packet size (B)

1316

Figure 10: Packet loss per packet size percentages for upstream and downstream 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 Ø is plotted against the time Ø. 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 1.0 3 x 13.4kbps Volume (MB) 0.8 0.6 13.4kbps 0.4 0.2 2 x 13.4kbps

0

100

200

300 400 Time (s)

500

600

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 inter12

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 providing 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+); “Multiplexing 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 understand 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 ½ ¾ ¼ 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 multiplexed 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 Basic unit ¢ TS ¾ ¢ TDMA frame ¢ Multiframe Duration (ms) 15/26 0.577... 60/13 4.615... 240 1920

Time slot (TS) TDMA frame Multiframe Superframe

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. Multislot class 1 2 3 4 5 6 7 8 Maximum number of time slots Rx Tx Sum 1 1 2 2 1 3 2 2 3 3 1 4 2 2 4 3 2 4 3 3 4 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. According 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. IPpackets 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 consecutive 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 Ò½ blocks from the list (1), the second uses next Ò¾ blocks and the third logical channel uses last 12-´Ò½ · Ò¾ µ 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 ´½¾ ¢ CS ¢ TSµ ´¾ ¼ 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 9.05 18.10 27.15 13.40 26.80 40.20

CS-1 CS-2

4 36.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 functionality 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 Ericsson T39m 4 IrDa and IrDa-Ultra V.24 Yes ME2 Nokia 8310 4 and 5 Yes No No

Vendor Model Multislot class Infrared Serial cable Bluetooth

Table 9: Terminal equipments. TE1 Dell Latitude CPi Linux Pentium II Yes Yes No TE2 Dell Latitude C600/C500 Windows 2000 Pentium III Yes Yes No TE3 Dell OptiPlex Windows 95 Pentium II No Yes No

Vendor Model Operating system Processor Infrared (IR) Serial cable (SC) Bluetooth

B.4

The inteface between TE and MT

The connection from the computer to the phone was handled via Point-to-Point Protocol (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 Windows. 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 algorithm described in figure 13: The algorithm described in figure 13 generates ½¾ ¢ ½¾ ½ ping commands, each sending ½¼¼ echo request packets making a total of ½ ¼¼ request packets. For each packet size, ½¾ ¢ ½¼¼ ½¾¼¼ request packets is sent. There was a ¼ 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 receive-all defaultroute noipdefault lcp-echo-interval 0 novj novjcomp noproxyarp nocrtscts noauth local Comment Accept all control characters from the peer. Add a default route to the system routing tables. Not to determine the local IP-address from the hostname. Disable LCP echo-request frame. Disable TCP/IP header compression. Disable connection-ID compression. Disable proxy ARP. Disable hardware control on the serial port. Do not require the peer to authenticate itself. 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 algorithm 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 successive 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 14 12 10 RTT (s) 8 6 4 2 RTT (s) 14 12 10 8 6 4 2 ME1, SC, RP = 2s

1 i:th measurement

13875

1 i:th measurement

13794

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 allocation 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 14 12 10 RTT (s) 8 6 4 2 RTT (s) 14 12 10 8 6 4 2

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

0

50 ICMP seq.no

99

0

50 ICMP seq.no

99

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 14 12 10 RTT (s) 8 6 4 2 RTT (s) 14 12 10 8 6 4 2

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

0

50 ICMP seq.no

99

0

50 ICMP seq.no

99

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

23

ILIAS-2001

25th February 2002

ME1, SC, RP = 2s 14 12 10 RTT (s) 8 6 4 2 RTT (s) 14 12 10 8 6 4 2

ME2, IR, RP = 1s, Host 1

36

292

548 804 1060 IP-packet size (B)

1316

36

292

548 804 1060 IP-packet size (B)

1316

Figure 17: Examples of the results of systematic ping.

ME2, IR, RP = 1s, Host 2 14 12 10 RTT (s) 8 6 4 2 RTT (s) 14 12 10 8 6 4 2

ME1, SC, RP = 1s

36

292

548 804 1060 IP-packet size (B)

1316

36

292

548 804 1060 IP-packet size (B)

1316

Figure 18: Examples of the results of systematic ping.

24

ILIAS-2001

25th February 2002

25

ME2, IR, RP = 1s

25

ME1, SC, RP = 2s

Percentage of lost packets

15

Percentage of lost packets 1 25 49 73 97 i:th ping command 121 144

20

20

15

10

10

5

5

1

25

49 73 97 i:th ping command

121

144

Figure 19: Two examples of packet loss percentages per each ping command.

12 10 Percentage of lost packets 8 6 4 2

ME2, IR, RP = 1s

12 10 Percentage of lost packets 8 6 4 2

ME1, SC, RP = 2

0

50 ICMP seq.no

99

0

50 ICMP seq.no

99

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

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close