Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Radio Network Dimensioning For GSM/GPRS Supporting Circuit-And Packet-Switched Services

Download as pdf or txt
Download as pdf or txt
You are on page 1of 18

Radio Network Dimensioning for GSM/GPRS Supporting Circuit- and Packet-Switched Services

Peter Stuckmann www.comnets.rwth-aachen.de/~pst

Peter Stuckmann

Structure

the problem coexisting circuit-switched traffic dimensioning rules for fixed PDCH configurations dimensioning rules for on-demand PDCH configurations configurations with fixed and on-demand PDCHs

Peter Stuckmann

2nd Wrzburg-Workshop on IP

Motivation
radio network dimensioning demands the relationship between
? ? ? offered traffic predicted by operator QoS desired by operator for his clients radio resources needed (number of PDCHs and TRX)

analytical complexity caused by


? ? radio channel attributes bursty traffic (no Erlang-B-formula like in CS)

system complexity no test bench or field trials with complete protocol software and hardware components available solution: computer simulation of the system that models
? ? ? system components and their protocols traffic sources radio channel
Peter Stuckmann

2nd Wrzburg-Workshop on IP

Capacity planning and radio network dimensioning


relationship between
? ? ? offered traffic QoS desired radio resources needed

Traffic Simulation model Analytical model

QoS

Capacity model

Erlang table

Erlang Formula

Radio network dimensioning


Peter Stuckmann

2nd Wrzburg-Workshop on IP

Measures and methodology


term traffic QoS parameter resources tool methodology circuit-switched offered traffic in Erlang packet-switched offered amount of data per time in kbit/s

blocking probability (GoS) throughput, delay,... traffic channels simple formula or table Erlang-B formula packet data channels dimensioning graphs or tables simulation results, analytical / algorithmic techniques

Peter Stuckmann

2nd Wrzburg-Workshop on IP

Simulation Environment (E)GPRSim


Circuit Switched Generator Packet Generator
Funet Mobitex Railway

Internet Load Generator (SDL)


TeleHTTP FTP SMTP WAP RT matic

Session Arrival Process

TCP/UDP IP

Generator
Channel Management

CAC (session management)

SNDCP LLC Relay LLC (SDL)

SNDCP

LLC (SDL)

RLC/MAC (SDL) Channel/Error Model

RLC/MAC (SDL)

BSSGP Frame Relay

G b Uplink

BSSGP Frame Relay

G b Downlink Transceiver

Transceiver

SGSN

MS
Um

BS
Gb

GIST

Web Interface
Throughput (S)

Statistical Evaluation
1 0.9 0.8 Funet 0.7 0.6 0.5 0.4 0.3 Railway 0.2 Mobitex 0.1 00 0.20.4 0.6 0.8 1 1.2 1.4 1.61.8 2 Offered Load (G) 1 0.9 24 RA Slots 0.8 56 RA RA Slots Slots 88 0.7 0.6 0.5 0.4 0.3 0.2 0.1 00 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 Offered Load [byte/s] Blocking Rate

Peter Stuckmann

2nd Wrzburg-Workshop on IP

Dimensioning rules for fixed-PDCH scenarios (I)


downlink IP throughput over offered traffic
25 3 fixed PDCH 4 fixed PDCH 5 fixed PDCH 6 fixed PDCH 25 4 fixed PDCH 5 fixed PDCH 6 fixed PDCH

Dimensioning Graph

Downlink IP throughput [kbit/s]

20

Downlink IP throughput [kbit/s]

20

15

15

10

10

0 5 10 15 20 25 30

0 0 1 2 3 4 5 6 7

Offered IP traffic [kbit/s]

Offered IP traffic / PDCH [kbit/s]

Peter Stuckmann

2nd Wrzburg-Workshop on IP

Dimensioning rules for fixed-PDCH scenarios (II)


define the desired QoS estimate the number of users per cell estimate the offered traffic per user calculate the total offered traffic per cell determine the acceptable traffic per PDCH with the desired QoS from the dimensioning graph calculate the needed number of PDCHs PDCH = estimated offered traffic / acceptable traffic per PDCH

Peter Stuckmann

2nd Wrzburg-Workshop on IP

Example
define the desired QoS
? example value: 12.5 kbit/s is desired

estimate the number of users per cell


? example value: 10 users with 540 kbyte/h per user

calculate the offered traffic per user and the offered traffic per cell
? ? offered traffic per user = 540 kbyte/h = 1.2 kbit/s total offered traffic per cell = 12 kbit/s

take the acceptable traffic per PDCH from the reference graph
? ? ? acceptable traffic per PDCH = 3.5 kbit/s/PDCH PDCH = 3.4 4 PDCHs have to be allocated for GPRS

Peter Stuckmann

2nd Wrzburg-Workshop on IP

Radio resource management


on-demand assignment of PDCHs for GPRS voice connections are prioritized
TCH release TCH shift X X X X X X X X

maximum number of on-demand PDCHs TCHs allocated for CS

maximum number of fixed PDCHs Transition

TCHs allocated for GPRS

X
2nd Wrzburg-Workshop on IP 10

Peter Stuckmann

Circuit switched traffic


radio network dimensioned for voice services with blocking probability of e.g. 1 % (blocking probability = Grade of Service (GoS)) unutilized resources can be used for GPRS
State probability vs no. of TCHs for 1TRX 0.3 0.25
Probability Probability

State probability vs no. of PDCHs 0.8 0.7 0.6

0.2 0.15 0.1 0.05 0

0.5 0.4 0.3 0.2 0.1

Number of channels Peter Stuckmann

Number of channels

2nd Wrzburg-Workshop on IP

11

GPRS performance with coexisting CS traffic (I)


downlink IP throughput per user
30 2 0 fixed PDCH 1 fixed PDCH 2 fixed PDCH

downlink IP packet delay


0 fixed PDCH 1 fixed PDCH 2 fixed PDCH

25

Downlink IP throughput [kbit/s]

1.5 20

Downlink IP delay [s]

15

10

0.5 5

0 0 2 4 6 8 10 12

10

12

Offered IP traffic [kbit/s]

Offered IP traffic [kbit/s]

Peter Stuckmann

2nd Wrzburg-Workshop on IP

12

GPRS performance with coexisting CS traffic (II)


downlink PDCHs assigned (average)
8 0 fixed PDCH 1 fixed PDCH 2 fixed PDCH 100

downlink PDCH utilization


0 fixed PDCH 1 fixed PDCH 2 fixed PDCH

Downlink PDCHs assigned (average)

Downlink PDCH utilization [percent]


0 2 4 6 8 10 12

7 6 5 4

80

60

3 2 1 0

40

20

10

12

Offered IP traffic [kbit/s]

Offered IP traffic offer [kbit/s]

Peter Stuckmann

2nd Wrzburg-Workshop on IP

13

Dimensioning rules for on-demand-PDCH scenarios


simulation results show that the shared use of GSM physical channels both for CS and GPRS makes sense dimensioning rules for on-demand-PDCH scenarios are needed the aim is to take an existing TRX scenario as the basis and find the acceptable CS traffic so that the desired GPRS performance can be achieved if the predicted offered traffic is exceeded a new TRX module should be added to the base station in the following an example is given for a 3 TRX scenario

Peter Stuckmann

2nd Wrzburg-Workshop on IP

14

Example: 3 TRX scenario (I)


downlink IP throughput per user
25 0.5% GoS 2% GoS 10% GoS

Example values
? ? ? ? offered CS traffic with 1.5 % GoS 10 GPRS users per cell 540 kbyte/h offered per user desired QoS of 12.5 kbit/s

Downlink IP throughput [kbit/s]

20

15

10

0 5 10 15 20 25 30

Offered IP traffic [kbit/s]

Peter Stuckmann

2nd Wrzburg-Workshop on IP

15

Example: 3 TRX scenario (II)


calculate the offered traffic per cell
? total offered traffic per cell = 10 * 540 byte/h = 12 kbit/s

regard the operating point p defined by the desired user performance on the y-axis and the offered traffic per cell on the x-axis and choose the adequate GoS curve as the next that lies above the operating point
? p = (x = 12 kbit/s, y = 12.5 kbit/s)

if the offered CS traffic corresponding to the GoS is predicted to be exceeded, a new TRX should be added
? ? ? the operating point p lies just below the 2 % GoS curve coexisting CS traffic up to 2 % GoS is acceptable since 1.5 % GoS was assumed an additional TRX is not necessary in this cell

Peter Stuckmann

2nd Wrzburg-Workshop on IP

16

Mixed configurations
to be able to guarantee the availability of GPRS, operators might provide fixed PDCHs and the rest as on-demand PDCHs in this case simple estimations can be done:
? ? scenarios with 1,2 or 3 fixed PDCHs: take pure on-demand configurations for dimensioning (probability that the first PDCHs are used by CS is low) scenarios with more than 3 fixed PDCHs: take a pure fixed PDCH configuration for dimensioning (probability that the on-demand PDCHs are used by CS is high)

Peter Stuckmann

2nd Wrzburg-Workshop on IP

17

Conclusions
fixed PDCH configurations can be dimensioned with one simple dimensioning graph on-demand PDCH configurations are recommended, since not all physical channels are highly utilized by CS dimensioning of on-demand PDCHs can be done by taking dimensioning graphs for the regarded TRX scenario as the basis for mixed scenarios with both fixed and on-demand PDCHs simple estimations can be done and pure fixed or pure on-demand dimensioning rules can be applied

Peter Stuckmann

2nd Wrzburg-Workshop on IP

18

You might also like