Dimension Ing Guide for GPRS CS1-CS4 Trafic Chanles

Rev C 2002-06-07 Ericsson Wide Internal 1(29)

DIMENSIONING GUIDELINE FOR GPRS CS1 – CS4TRAFFIC CHANNELS

ERICSSON WIDE INTERNAL

1 Revision History

Rev Date Description

A 2002-02-26 Created

B 2002-06-07 Minor updates

C 2002-06-07 Minor updates

2 Purpose

The purpose of this guideline is to present a dimensioning method thatcan be used for the implementing of GPRS CS1 to CS4 in an existingEricsson GSM network. The guideline focuses on the dimensioning oftraffic channels and the number of TRXs.

GUIDELINE

2(29) Ericsson Wide Internal 2002-06-07

3 Glossary

3.1 Abbreviations

BCCH Broadcast Control Channel

CGI Cell Global Identity

CS Coding Scheme

GoS rade of Service

GPRS General Packet Radio Service

PDCH Packet Data Channel

QoS Quality of Service

RLC Radio Link Control

SNDCP Subnetwork Dependent Convergence Protocol

TBF Temporary Block Flow

TCH Traffic Channel

TCP Transmission Control Protocol

TRU Transceiver Unit

TS Timeslot

UDP User Datagram Protocol

WAP Wireless Application Protocol

WWW World Wide Web

GUIDELINE


3.2 Concepts

Link Adaptation This is an approach to select the most optimumcoding scheme based on the radio link quality.

MS Multislot Class The MS capability to handle multiple TS inpacket data channels.

PDCHCS2_conf A PDCH configured for CS1 to CS2

PDCHCS4_conf A PDCH configured for CS1 to CS4

PSET A set of PDCHs allocated for GPRS

Poll Interval How often the PCU (Packet Control Unit)requests an acknowledgement report from themobile.

QoS Profile A subscription connected priority class forpacket data.

Round trip delay The delay for the route PCU =>mobilestation=> PCU.

4 How to read this document

The Introduction (chapter 5) gives a brief background to the method andthe different aspects that affects the dimensioning.

The General Procedure (chapter 6) gives the non-technical reader anunderstanding of the purpose of the proposed method as well as itexplains the general steps required for the dimensioning. The ExecutiveSummary quantifies the errors and risks associated with the method.

The Dimensioning Method (chapter 7) presents step by step how todimension a GPRS network. This section includes both necessarysimulation results and dimensioning examples.

Appendix B and C include forms to fill in preconditions, results etc.

GUIDELINE


5 Introduction

5.1 General

The purpose of this report is to present a dimensioning method for theimplementation of GPRS CS1 to CS4 in an existing Ericsson R9.1 BSS.The method is based on drive tests using the TEMS investigation andsystem simulation results for CS2. By mapping TEMS GPRS predictionson to simulation results it is possible to predict the application throughputfor CS4 capable networks with respect to different load conditions andconfigurations. Furthermore, the method also considers the channelallocation when calculating the amount of traffic that can be supportedby the network. E.g. how many PDCHs are available and how many ofthese are CS3 and CS4 capable. According to the standard all GPRSMSs will support CS1 to CS4.

In brief the method is based on the following components:

• TEMS Investigation

• GPRS Traffic Simulations

• Channel Allocation

For more information about how to configure the network see ref. [4].

5.2 TEMS Investigation

The TEMS investigation R3.1 enables predictions of the GPRSthroughput in an existing network. The predicted throughput is the RLCthroughput with no sharing of resources, i.e. the bandwith on the airinterface for one timeslot under the measured radio conditions. For moreinformation see [3].

GUIDELINE


5.3 GPRS Traffic Simulator

The system simulation results used in this report are from the GPRSRadio Network Dimensioning Guideline, ref [1].

Simulations are used to derive insight into GPRS performance. Thesimulator focuses on the investigation of the end-to-end communicationfrom an application perspective. Thus, the simulator models the wholeGPRS node chain including the Internet. That means all the protocoloverheads and interactions of the underlying stack below http areinvolved. No compression is assumed. The radio environment wasmodeled as a typical urban environment using a normally distributed C/Iwith a mean of 12 dB and a 5 dB variance. This setting corresponds to aC/I distribution with 90% of the “samples” having a C/I > 9 dB. Thesimulation scenario corresponds to multiple users running WWWapplications with their GPRS terminals within the same cell. The users allbehave according to a traffic model described in ref [1]. The modelimplies that each user has an average bitrate of 2.5 kbps. Note that thisaverage bitrate also includes the idle time in between downloading ofobjects.

Only downlink performance is simulated. Each requested WWW-pageconsists of one or several WWW objects with different sizes. Thepresented throughput results represent the packet size of these objectsdivided by the delay from the server to the client.

The simulation results are only valid if the average number of PDCHs isat least the same as the MS multislot class. Since the PDCHs to bedimensioned either can be CS4 capable or only CS2 capable it isrequired to have this amount of PDCHs for CS4 as well as for CS2.

GUIDELINE


5.4 Channel Allocation

When a packet data channel is required, the system first looks for adedicated PDCH. If no channel is found (either there is no dedicatedPDCH allocated in the cell or all PDCHs are busy), the system checks foravailable timeslots. The system will then open a PSET on which thePDCHs can be allocated. In R9.1 the maximum size of a PSET is 8 TS.

For an incoming MS accessing a cell the channel allocation algorithm willinvestigate on which PDCHs it will get the best throughput and place itthere. E.g. if the load on the CS2 capable PDCHs is as high as the loadon the CS4 capable PDCHs, the MS will be placed on the CS4 capablePDCHs. On the other hand if the load on the CS4 capable PDCHs ismuch larger than on the only CS2 capable PDCHs, the MS will beassigned to the CS2 only PDCHs.

This document assumes no QoS profiles and Round Robin scheduling isused to empty the queues. This means that users who are assignedresources on the same timeslot take turns sending one RLC block each.A mobile station assigned more than one timeslot (multislot mobiles)participates in the Round Robin scheduling on each of the assignedtimeslots. As soon as a new user enters the queue, it starts to transmit atthe same speed as the other MSs of the same multislot class.

GUIDELINE


6 General Procedure

6.1 Purpose and Procedure

This Guideline presents a method for dimensioning of GPRS networks,i.e. to investigate how much hardware is required to fulfil the voice andGPRS requirements. The method is suitable for the introduction ofGPRS in existing network or for the introduction of the higher codingschemes, such as CS3 and CS4 in an already existing CS2 only GPRSnetworks. The work procedure for the dimensioning involves thefollowing steps:

1. Gathering of Dimensioning Input

For the dimensioning it is necessary to know the requirements on GPRSsuch as the median throughput and the expected data load. Thesevalues are usually achieved from the operator requirements for GPRS.Furthermore it is required to gather information about the current networksituation, such as the number of TRXs and the current load situation.The dimensioning can either be based on predictions or the currentstatus. In either case it is necessary to collect information about theactual network. This procedure also includes decisions on where toperform the drive tests.

2. Drive Test

The drive test requires two persons: one that drives a vehicle throughthe areas of interest and one that handles the measurement equipment(TEMS MS and PC).

3. Post Processing and Analysis

The data analysis includes post processing of measured data. In thisstep the engineer can evaluate different configurations and hence find aconfiguration that fulfills the requirements.

GUIDELINE


6.2 Executive Summary

This report is intended for dimensioning of GPRS networks andestimating the anticipated application throughput a user will experience.The results are partly based on simulation results and mightconsequently deviate from actual network performance.

When dimensioning a GPRS network for a certain average throughputthe actual average will in most cases not deviate more than +/- 20 %.

The variation of the total load will in most cases not deviate more than+/- 20 %.

A basic requirement for the method is that the assumptions presented insection 7.1 are valid.

GUIDELINE


7 Dimensioning Method

7.1 General

For the dimensioning it is required to know the data and voice load thatis to be supported. By assuming an initial configuration it is then possibleto find a configuration that satisfies the throughput and loadrequirements through an iterative process.

As an input to the evaluation of the configuration it is required to haveTEMS measurements of the predicted RLC throughput. Thesemeasurements should be performed during busy hour in the actualnetwork. The method for predicting the CS4 and CS2 end-to-endthroughput is based on mapping GPRS RLC prediction results on tosystem simulation results for CS2. This enables an adaptation of themeasured characteristics of the specific network to simulated systemend-to-end behaviour.

The following bullets summarizes the most important assumptions for thedimensioning method:

• The additional data traffic is small compared to the total (CS+PS)traffic. I.e. the GPRS traffic will not increase the interference to alarge extent.

• The number of average available PDCHs for CS2 as well as CS4 isat least the same as the MS multislot class to dimension.

• The MSs always get the number of timeslots corresponding to theMS multislot class.

• The WAP traffic load is small compared to the total load (<10%), i.e.the traffic behavior should not differ too much from the traffic modelused in the simulations.

GUIDELINE


7.2 Dimensioning Flow chart

Figure 1. Flow chart of the dimensioning process

Start

2. Make assumptions:• Voice volume• Data volume including required average throughput• MS multislot class

DesiredThroughputand Load?

Stop

No

Yes

3. Drive test - Estimate the RLC bitrate per PDCH for:• PDCHCS2_conf

• PDCHCS4_conf

4. Derive the “GPRS dimensioning characteristics”diagram for the cell

5. Make a new assumption about total # of TRXs and# of PDCHCS4_conf

6. From the voice traffic volume, estimate average #of PDCHs in the cell and calculate average number ofPDCHCS2_conf.

7. Using the graph in step 4 to evaluate theconfiguration

1. Gather cell data

GUIDELINE


7.3 Description of the dimensioning steps

Step 1: Gather cell data

Gather the cell data for all cells that are to be included in thedimensioning. Associate cells to clusters belonging to the same TEMStest route.

Step 1 and 2 are used to complete form in Appendix B, with theexception of the last column (no. 7, Extra TRXs). This is completed instep 7.

Example:

Table A4. Cell Data Form

DriveTestArea

Cell id # of TRX CS_Served_

Traffic

CS_Offered_

Traffic

BTS type Extra TRXs

Area 1 100 3 10 Erlang 2202

101 3 12 Erlang 2202

Area 2 102 2 11 Erlang 2202

103 2 10 Erlang 2202

Step 2: Make assumptions

Define the Voice and Data Requirements. Choose multislot class todimension.

Voice:

• CS_Served_Traffic is the served traffic (usually collected fromstatistics)

or

• CS_Offered_Traffic is the offered traffic (usually from forecasteddata)

• GoS is the required Grade of Service

The CS served traffic should be estimated using the following STScounters:

GUIDELINE


Average traffic in Erlang / Cell

Data:

• tpreq is the required average throughput for a GPRS user, regardlessof coding scheme.

• LWAP is the total WAP load per cell [kbps]

• LWWW is the total WWW load per cell [kbps] (include also FTP etc.)

• LTot = LWAP * 1.1 + LWWW [kbps]

where LTot is total load (kbps) per cell.

The WAP load is multiplied with a factor 1.1 due to ∼ 10% higheroverhead loss as compared to the WWW traffic, see Appendix A.

To convert from numbers of packet data users to packet data load (LWWW

or LWAP) the number of users should be multiplied with the averagebitrate. For this any traffic model can be used.

Example:

Assume that 20k GPRS users are distributed over 500 cells.

In average each WWW user downloads 5400 kb (6 times 900kb) duringbusy hour, which corresponds to an application bitrate of ∼ 1.5 kbps(5400/3600).

In average each WAP user downloads 28 kb (7 times 4kb) during busyhour, which corresponds to an application bitrate of ∼ 0.008 kbps(28/3600).

With 20k users and 500 cells, there are ∼ 40 users per cell in average.This gives the following load situation:

LWAP = 40 * 0.008 = 0.32 kbps per cell

LWWW = 40 * 1.5= 60 kbps per cell

Multislot class:

Select a multislot class to dimension (1,2 or 4). This is the multislot classthat the throughput requirement should be valid for. The system may ofcourse include more than one multislot class, but the dimensioning isonly done for one at the time. When looking at the simulation results theload can be viewed as background traffic.

[ ]ETxNSCAN

TxTRALACCTRAFT =_

GUIDELINE


GUIDELINE


Step 3: Drive Test - Estimate the RLC bitrate per PDCH

Perform Drive Test

Drive tests are preferable performed using the TEMS investigation 3.1(ornewer). The test should be performed so that it gives a good statisticalrepresentation of the area that is to be dimensioned. It is important thatthe drive test is performed during busy hour for the specific area.

Step 3 and 4 are used to complete the form in Appendix C.

Example:

Table A5. Drive Test Form

Drive TestArea

Cell id Average CS2throughput

Average CS4throughput

aCS2 aCS4

Area 1 100 12 18 1 1.5

101

Area 2 102 11 15.4 0.92 1.28

103

Parameters to measure are:

• CS4 predicted throughput, tpCS4




TEMS Settings:

Round trip delay = 80ms (80-240)

Poll interval = 20 radio blocks (20-60)

Number of slots = 1 (1-8)

Note: If the BCCH frequencies are not to be used for GPRS theseshould be blocked in TEMS during the measurements.

GUIDELINE


Analyze Data

The data can be extracted by exporting the logfile using the text fileformat. Remove the Export Message Information under the TextProperties tab.

Choose the information elements in set up:

• Pred. GPRS CS4 throughput




Open the text file in Excel or any other data processing tool to analyzedata.

Estimate the average RLC bitrate for a CS4 PDCH

By assuming ideal link adaptation the CS4 radio link the Averagethroughput can be estimated as:

N

MaxN

∑= 0

CS1CS2CS3CS4

CS4_av

)tp;tp;tp;tp(tp

where N is the number of measurement points and Max(tpCS4; tpCS3;tpCS2; tpCS1) returns the largest throughput value for a specificmeasurement.

Estimate the average RLC bitrate for a CS2 PDCH

By assuming ideal link adaptation the CS2 radio link the Averagethroughput can be estimated as:

N

MaxN

∑= 0

CS1CS2

CS2_av

)tp;tp(tp

where N is the number of measurement points and Max(tpCS2; tpCS1)returns the largest throughput value for a specific measurement.

GUIDELINE


Post processing in Excel

Note: Excel can not handle logfiles that are longer than 100 min (10measurements/second and max no. of rows in Excel ≈ 65000).

1. Open the logfile

Initial structure:

Column 1: Time

Column 2: All-Pred. GPRS CS-1 Throughput (kb/(s*timeslots))




2. Set Column 6 to max(C2;C3)

Evaluate Average of Column 6, i.e. average CS2 throughput,tpCS2_av

3. Set Column 7 to max(C2;C3;C4;C5)

Evaluate Average of Column 7, i.e. average CS4 throughput,tpCS4_av

Table 1. Example of Excel table and calculation formulas.

GUIDELINE


Step 4: Derive the “GPRS dimensioning characteristics” diagram forthe cell

Calculate the scaling factors “aCS4” and “aCS2”:

aCS4 = tpCS4_av / 12

aCS2 = tpCS2_av / 12

where 12 kbps is the maximum bitrate for CS2 on the radio path in thesystem simulation.

Use the simulation results (table 2) to derive the “GPRS dimensioningcharacteristics” diagram for the test route area/cell (a graph). Both theMedian throughput (y-axis) and the offered load (x-axis) must be scaledwith the “aCS4” or the “aCS2” parameter. I.e. the values in the table shouldbe multiplied with the scaling factors. Plot both the CS2 and the CS4results in the same graph.

Table 2. Median throughput vs. offered load based on system simulationresults for CS2, ref [1].

Offered load[kbps/pdch]

Median tp for 1timeslot MSs[kbps/pdch]



0 9.2 17.2 330.5 9.2 17.1 32.91 9.2 16.8 32.5

1.5 9.1 16.3 322 9 15.8 31.2

2.5 8.9 15.2 303 8.7 14.5 27.8

3.5 8.6 13.8 25.64 8.4 13 23

4.5 8.2 12.2 20.25 8 11.5 18

5.5 7.8 10.5 -6 7.4 9.8 -

6.6 7.1 9 -7 6.8 8.1 -

7.6 6.4 7.2 -8 6.1 6.5 -

8.5 5.7 - -9 5.3 - -

9.5 4.9 - -10 4.4 - -

GUIDELINE


0 5 10 154

5

6

7

8

9

10

11

12

13

14

Offered WWW load [kbps/pdch]

Medianthroughput[kbps]

Scaling

Scaling

Figure 1. Example of scaling where the 1-timeslot CS2 simulation result(blue solid line) have been scaled with a scaling parameter of 1.5 (reddashed line).

Step 5: Make an assumption about the total number of TRXs and thenumber of PDCHCS4_conf

From the assumed number of TRXs calculate the number of trafficchannels per cell:

TCH = 8 * # of TRXs – # of control channels

Define the number of CS4 capable timeslot (pdch CS4).

This assumption might be altered if later proven to be insufficient.

Note that the number of pdch CS4 must be at least the same as themultislot class.

GUIDELINE


Step 6: From voice traffic volume, estimate average number ofPDCHs in the cell and calculate average number of PDCHCS2_conf

Determine the average number of available PDCHs per cell (pdch)

For on-demand channels, the average available PDCHs during theGPRS busy hour can be expressed as

pdch = TCH - CS_Served_Traffic

or

pdch = TCH - CS_Offered_Traffic (1 – GoS)

Calculate the average number of CS2 capable PDCHs per cell (pdch CS2)

pdch CS2 = pdch - pdch CS4

Note that the number of pdch CS2 must be at least the same as themultislot class.

Step 7: Use graph from step 4 to evaluate configuration

Plot the requested throughput tpreq in the “GPRS dimensioningcharacteristics” diagram for the cell.

Estimate the load per PDCH:

• Find the corresponding CS4 load per PDCH (Lpdch_CS4 )

• Find the corresponding CS2 load per PDCH (Lpdch_CS2 )

GUIDELINE


Figure 2. Example of “GPRS dimensioning characteristics” and procedure forinvestigating the configuration.

Evaluation of configuration

If tpreq < max average PDCHCS2_conf throughput:

LTot < ( Lpdch_CS4 * pdch CS4) + (Lpdch_CS2 * pdch CS2)

If tpreq > max average PDCHCS2_conf throughput:

LTot < ( Lpdch_CS4 * pdch CS4), i.e. use only pdch CS4

If the configuration is confirmed it can be used. If not, repeat step 5 to 7after increasing the resources. The resources can either be increasedthrough increasing the number of PDCHCS4_conf or by increasing thenumber of TRXs.

Offered WWWload [kbps/pdch]


CS4 capable Link Adaptation

CS2 capable Link Adaptation

Lpdch_CS2 Lpdch_CS4

tpreq

GUIDELINE


7.4 Example

An operator plans to set up a packet data network where the GPRSusers is estimated to 25k with 4-slot mobiles and the radio networkcomprises 750 cells. It is expected that each user in average will accessWWW applications through GPRS 4 times during busy hour anddownload 1100 kb per session. It is further expected that each user willaccess WAP applications through GPRS 5 times during busy hour anddownload 3.6 kb per session. GPRS busy hour is assumed to coincidewith the speech busy hour. On-demand PDCHs are desired. Whatconfiguration should the operator use if the required median throughputis 27 kbps?

Step 1: Gather cell data

• 750 cells

• 3 TRXs/cell

• Only 2202 BTSs using synthesizer hopping.

Step 2: Make assumptions

Expected Voice traffic:

CS_Offered_Traffic = 11.9 Erlang (from forecasted data)

GoS = 2 % (desired grade of service)

Expected Data traffic:

In average each WWW user downloads 4400 kb (4*1100) during busyhour which corresponds to an application bitrate of ∼ 1.23 kbps(4400/3600).

In average each WAP user downloads 18 kb (5 * 3.6) during busy hourwhich corresponds to an application bitrate of ∼ 0.005 kbps (18/3600).

With 25k users and 750 cells, there are ∼ 33 users per cell in average.This gives the following load situation:

LWAP = 33 * 0.005 = 0.17 kbps per cell

LWWW = 33 * 1.23= 40.6 kbps per cell

LTot = LWAP * 1.1 + LWWW = 0.17 * 1.1 + 40.6 = 40,8 kbps per cell

tp req = 27 kbps

Multislot class:

The dimensioning is performed for 4-slot mobiles.

GUIDELINE


Step3: Drive Test - Estimate the RLC bitrate per PDCH

TEMS measurements resulted in the following average RLCthroughputs:

tpCS2_av = 11 kbps

tpCS2_av = 17.4 kbps

Step 4: Derive the “GPRS dimensioning characteristics” diagram for thecell

Calculation of the scaling parameters:

aCS4 = tpCS4_av / 12 = 17.4 / 12 = 1.45

aCS2 = tpCS2_av / 12 = 11.0 / 12 = 0.92

Scale the GPRS dimensioning characteristics (table 2) according to thescaling factors, table 3.

Table 3. Scaled GPRS dimensioning characteristics, i.e. the “GPRSdimensioning characteristics”

Offered load[kbps/pdch] *a CS2

Median tp for 4timeslot MSs *a CS2 [kbps/pdch]

Offered load[kbps/pdch] *a CS4

Median tp for 4timeslot MSs * a CS4

[kbps/pdch]

0 30.4 0 47.90.46 30.3 0.73 47.70.92 29.9 1.45 47.11.38 29.4 2.18 46.41.84 28.7 2.90 45.22.30 27.6 3.63 43.52.76 25.6 4.35 40.33.22 23.6 5.08 37.13.68 21.2 5.80 33.44.14 18.6 6.53 29.34.60 16.6 7.25 26.1

GUIDELINE


0 1 2 3 4 5 6 7 815

20

25

30

35

40

45

50

Offered WWW load [kbps/pdch]


CS4, 4TSCS2, 4TS

Figure 3. The “GPRS dimensioning characteristics” diagram forPDCHCS4_conf (blue line) and PDCHCS2_conf (red line) using 4-slot mobiles.

Step 5: Make an assumption about the number of TRXs and the numberof CS4 capable timeslots

Assume that there are 3 TRX per cell with 22 TCH (excluding 2 timeslotsfor control and signaling channels).

Assume further that 4 PDCHs will be configured for CS4 per cell, i.e.

pdch CS4 = 4.

This assumption might be altered if later proven to be insufficient.

GUIDELINE


Step 6: From voice traffic volume, estimate average number of PDCHs inthe cell and calculate average number of CS2 PDCHs

The average available PDCHs during the GPRS busy hour can becalculated as:

pdch = TCH - CS_Offered_Traffic (1 – GoS) = 22 – 11.9 ⋅⋅⋅⋅ (1 – 0.02) =10.4

The average available CS2 capable PDCHs becomes:

pdch CS2 = pdch – pdch CS4 = 10.4 – 4 = 6.4

Step 7: Use graph from step 4 to evaluate configuration

The requested throughput tpreq = 27 kbps gives the corresponding loadper PDCH:

• Lpdch_CS4 = 7.0 kbps/pdch

• Lpdch_CS2 = 2.4 kbps/pdch

Since tpreq is lower than the maximum average CS2 throughput thefollowing evaluation is used:

LTot < ( Lpdch_CS4 * pdch CS4) + (Lpdch_CS2 * pdch CS2)

Where

LTot = 40.8 kbps

( Lpdch_CS4 * pdch CS4) + (Lpdch_CS2 * pdch CS2) = (7,0 * 4)+(2,4 * 6,4) = 43,3kbps

Evaluation

Since the load that can be supported (43,3 kbps) is more than LTot (40.8kbps) the configuration is ok.

GUIDELINE


8 References

[1] GPRS Radio Network Dimensioning Guideline for Ericsson GSMSystem BSS R8, LVR/D-99:0178 Rev C

[2] P. Stuckmann, H. Finck, T. Bahls, “A WAP Traffic Model and itsAppliance for the Performance Analysis of WAP over GPRS”, InProc. of the IEEE International Conference on Third GenerationWireless and Beyond (3Gwireless '01), San Francisco, USA, June2001, can be found at: http://www.comnets.rwth-aachen.de/publications/P_Stuckmann.html

[3] TEMS Investigation GSM at:http://www.ericsson.com/tems/gsm/investigation-gsm.shtml

[4] Radio Network Configuration Guideline for EDGE and GPRSCS3/CS4 in Ericsson's BSS, ERA/SV-01:0976 Rev A

GUIDELINE


Appendix A Theoretical Overhead Loss Comparison

The purpose of this calculation is to compare the overhead loss of aWAP object as compared to WWW object. The result from thisinvestigation can be used to estimate the effective load of mixed WAPand WWW traffic when using the WWW simulation result.

Table A.1 Overhead and padding loss for each IP datagram

Protocol Overhead/Paddingloss size (octet)

UDP 8

TCP 20

IP 20

SNDCP 4

LLC 7

Referring to Table A.1, the average overhead loss per IP packet forUDP:

OverheadlossUDP = UDP + IP + SNDCP + LLC = 39 octet

The average overhead loss per IP packet for TCP:

OverheadlossTCP = TCP + IP + SNDCP + LLC = 51 octet

An additional RLC padding loss can be seen as the non-filled part of thelast RLC packet. For CS2 the RLC size is 30 bytes resulting in anaverage loss of 15 bytes. For CS4 the RLC size is 50 bytes resulting inan average loss of 25 bytes. In this example a value of 20 is chosen as ageneral estimation.

Furthermore, there is an extra overhead loss due to TBF downlink setupfor both protocols. As for TCP, connection setup with 3 ways handshakewill also increase the overhead loss.

Table A.2 Connection establishment overhead loss

Overhead loss (octet)

TBF downlink establishment 30 per application object30 per application object

TCP 3-way handshakes setup 50 per HTTP applicationobject (downlink only)

GUIDELINE


Table A.3 Overhead loss calculation for WAP and HTTP

WAP HTTP

Application objectsize (byte)

450 600 12800

MTU Size (byte) 576 576 576

Payload size perMTU (byte)

536 536 536

Required number ofIP packet

1 2 24

Total Overhead loss(byte)

39+20+30 =89

2*39+20+30=128

24*51+20+30+50 =1324

Percentageoverhead loss

19.8% 21.3% 10.3%

Table A.3 describes the total overhead loss for WAP and HTTPaccording to the WAP and HTTP object size distribution given in ref. [2].The average packet size for WAP is 450 bytes and the average packetsize for HTTP is 12800 bytes. The percentage of WAP objects havingsizes above 1 IP payload (536 bytes) is around 40%.

The total average overhead loss for WAP is hence 0.6*89 + 0.4*128 =92.6 byte. The percentage overhead loss for WAP object would be92.6/450 = 20,6%, which is 10% (20.6-10.3) higher than WWW object.

GUIDELINE


Appendix B Cell data form

Definitions:

Drive Test Area An area covered by one drive test route.The area contains one or more cells.

Cell Id Cell identity (or CGI)

# of TRXs The total number of TRXs per cell

CS_Served_Traffic See ch. 6.3

CS_Offered_Traffic See ch. 6.3

Use CS_Served_Traffic or CS_Offered_Traffic for dimensioning.

Table A4. Cell Data Form

Drive Test Area Cell Id # of TRX CS_Served_Traffic

CS_Offered_Traffic

BTS type Extra TRXs

GUIDELINE


Appendix C Drive Test Form

Definitions:

Drive Test Area An area covered by one drive test route.The area contains one or more cells.

Cell Id Cell identity (or CGI)

Average CS2 throughput The average predicted CS2 throughput inthe drive test area.

Average CS4 throughput The average predicted CS4 throughput inthe drive test area.

aCS2 Average CS2 throughput / 12, see ch. 6.3.

aCS4 Average C4 throughput / 12, see ch. 6.3.

Table A5. Drive Test Form

Drive Test Area Cell Id Average CS2throughput

Average CS4throughput

aCS2 aCS4

Dimension Ing Guide for GPRS CS1-CS4 Trafic Chanles

Documents