Gprs

Traffic Engineering Concepts
for Cellular Packet Radio Networks

with Quality of Service Support
Presented by Yujing Wu
Based on Peter Stuckmann‘s Public PhD defense on

20/06/2003
Outline
• Motivation and objectives

• Traffic models for existing and future applications
• Simulation environment GPRSIM
• Analytical Traffic Engineering Approaches
• GPRS/EDGE performance analysis
• Performance of different applications
• Traffic engineering
• QoS support
• Mutual dependency of traffic engineering and traffic
management
Peter Stuckmann‘s thesis work

2
20/06/2003
Motivation: Cost-effective Network Evolution
• Traffic Engineering and Traffic Management
Design and upgrade the network in a cost-effective way

 Based on traffic-performance relation
 Service differentiation ensured by admission control and scheduling
->Influence on traffic-performance relation
term circuit-sw itched packet-switched

traffic offered traffic in amount of data per
Erlang time in kbit/s
QoS parameter blocking probability throughput, delay,...
resources traffic channels packet data channels
tool simple formula or dimensioning graphs
table or tables
methodology Erlang-B formula simulation results,
analytical/algorithmic
techniques

3
20/06/2003
Evolution from 2G to 3G
Requirements for 3G systems:
high data rate (144kbit/s outdoor and 2Mbit/s indoor) ;
asymmetric traffic; packet switched; high spectrum efficiency.

4
20/06/2003
Assignment of GSM Channels for GPRS
GPRS packet
pool of GSM physical channels
data channels
x fixed PDCHs
y on-demand PDCHs
• Packet Data Channels (PDCHs) assigned out of pool of GSM

physical channels
• Fixed PDCHs are permanently available
• On-demand PDCHs only available if not used for GSM
circuit-switched traffic

5
20/06/2003
Dimensioning Approach
• Dimensioning graphs for application-specific performance measures
• Valid for the cell and load scenarios of interest
• Applicability: only based on user number/ traffic volume in the busy hour
• Accuracy: derived from realistic models for the protocol stacks, traffic patterns and radio channel
QoS QoS
resource configuration 3
QoS limit QoS limit
acceptable traffic offered traffic predicted traffic offered traffic

6
20/06/2003
TE Methodology and Evaluation Scenarios
1. Analytical and algorithmic models:
 Lack of details of protocol stacks and realistic traffic model
(close-loop control of TCP and heavy tailed traffic)
1. Measurement:
 Lack of tunable traffic load and different protocol options
1. Simulation:
 Detailed implementations of GPRS and Internet protocols
 Traffic generator for common applications
 Models of the radio channel
Simulation Scenarios:
• Per cell: max PDCH no 8; max IP throughput 80kbits; 1-40
active stations;
• Traffic: Web browsing and email with small obj size; not
much WAP traffic; no mobility model.

7
20/06/2003
Traffic Management
• Increase performance for best-effort services
 Coupled RLC/MAC implementation considering urgency of RLC blocks for MAC
scheduling
 MAC scheduler considering link quality
• Support application-specific QoS (class differentiation on MAC level)
 Priority queuing
 Fairer scheduling algorithms introducing weights for traffic classes
QoS QoS
application 2
application 2
QoS limit 2 QoS limit 2

application 1
QoS limit 1 QoS limit 1
application 1
capacity gain
acceptable traffic offered traffic (aggregate) acceptable traffic offered traffic

(aggregate)
8
20/06/2003
Outline
• QoS support
management

9
20/06/2003
Multimedia Traffic Modelling
• Aim
 definition of user profiles
 characterization of sessions
• Predicted applications for mobile users
 Internet (WWW, e-mail, FTP)
 Wireless Application Protocol (WAP)
 Streaming (Video & Audio)
 Video-Conferencing, VoIP
• Methodology
 Use measurement results for fixed Internet from literature
 Perform own measurements
 Use standardized models (e.g. UMTS 30.03)
 Use market prediction studies

10
20/06/2003
WWW Session / Structure of Web Page
Sdfsadfsda Sdfsadfsda
safsdfsafd safsdfsafd
sadfasfdsaf sadfasfdsaf
sdfasfdsaf sdfasfdsaf
Sdfsadfsda Sdfsadfsda
safsdfsafdSdfsadfsdasaf safsdfsafdSdfsadfsdasaf
sdfsafd Sdfsad sdfsafd Sdfsad
fsdasafsdfsafdSdfs adfs fsdasafsdfsafdSdfs adfs
a safs dfsafd Sdfsadfsda a safs dfsafd Sdfsadfsda
tread
safsdfsafd Sdfsadfs da safsdfsafd Sdfsadfs da
fgdfg dfg afsdfs afd fgdfg dfg afsdfs afd
gfdgs fgsdf sdfg sdg gfdgs fgsdf sdfg sdg
sdfg sdfg
page 1 page n
picture
links
text
object 1 object 2 object m

tobject
page 2 size m

11
20/06/2003
Mosaic Traffic Model [Arlitt and Williamson 1995]
Parameter Distribution Mean Variance
Pages per session Geometric 5 20.0

Reading time between pages [s] Exponential 12 s 144.0
Objects per page [byte] Geometric 2.5 3.75
Object size [byte] Log2-Erlang-k (k=17) 3700 1.36 x 10e6
Transformed Erlang 9.4 5.2

12
20/06/2003
Choi’s Behavioral Model of Web Traffic
• Larger WWW pages with higher object sizes

• Not yet suitable for GPRS traffic engineering
• Important when performance of wireless Internet access will
be comparable to today‘s fixed networks, e.g. with EGPRS or
UMTS

13
20/06/2003
E-mail Traffic Model
• Parameters derived by measurements made at the Lawrence
Berkeley Laboratory (California, USA) by Paxson in 1994
• Fixed overhead of 300 byte
• Bimodal distribution of e-mail sizes
 Lower 80% can be interpreted as text-based mails
 Upper 20% represents mails with attached files
• Maximum size 100 kbyte

E-mail size (lower 80%) [byte] Log2-Normal 1700 5.2 x 10e6
Transformed Normal 10.0 2.13
E-mail size (upper 20%) [byte] Log2-Normal 15700 115 x 10e9
Base quota [byte] C onstant 300 ---

14
20/06/2003
WAP Traffic Model
• Parameters are depending on the content
• Values derived by measurements performed at a WAP gateway
in test operation
 Suitable for introduction scenarios
 Will change over the next years
(today: 1 kbyte for monochrome decks, 3 kbyte for colored decks)
Decks per session Geometric 20.0 3800

Reading time between decks [s] Exponential 14.1 198.8
Packet size 'Get Request' [byte] Log2-Normal 96.1 3.75 x 10e3
Packet size 'C ontent' [byte] Log2-Normal 562.6 3.5 x 10e5

15
20/06/2003
Video Streaming Traffic Model
• Traffic model based on three real video sequences
coded with the H.263 codec specified by the ITU-T
(similar to MPEG)
• Sequences proposed by the Video Quality Expert Group
each one representing a particular group of motion
intensity
• Sequences are randomly concatenated producing a
continuous video stream
Sequences Offered IP traffic

Q20 80-10-10 Mix
C laire 10.9 kbit/s

C arphone
Foreman
26.7 kbit/s
31.7 kbit/s
}
14.39 kbit/s

16
20/06/2003
Outline
• QoS support
management

17
20/06/2003
GPRS Architecture

18
20/06/2003
GPRSIM
GPRSim Load Generator
Manager
• Event-driven Simulator
Session
Session
Arrival
Arrival
based on C++ and SDL
HTTP SMTP FTP Video WAP
•
Process
Process
Circuit
Switched WTP
Prototype
Generator implementations of
TCP UDP
CAC protocol stacks at
IP session
mgmt.  Mobile Station (MS)
 Base Station (BS)
 SGSN
SNDCP SNDCP
• Stochastic traffic
Channel
Mgmt. LLC
LLC
(SDL)
Relay LLC models to generate
(SDL)
well-defined traffic load
•
RLC/
RLC/
MAC MAC
BSSGP GbUplink BSSGP Channel and mobility
(SDL) (SDL) Frame
Relay
Frame
Relay
models
Channel
Transc.
Error
Model Transc.
Gb Downl.
SGSN • Evaluation and
MS
BS graphical
Um Gb representation
GIST Web Interface Statistical Evaluation • Validation by
measurement
Throughput (S)
0.9 0.9
Blocking Rate
24 RA Slots
0.8 0.8 56
0.7 Funet 88 RA
RA Slots
Slots
0.7
0.6 0.6
0.5 0.5
0.4 0.4
0.3 Railway 0.3
0.2 0.2
Mobitex
0.1 0.1
0.20.40.60.81 1.21.41.61.82 1000
2000
3000
4000
50007000
60008000
9000
10000
Offered Load (G) Offered Load [byte/s]

19
20/06/2003
Simulation Results
IP user/cell throughput
IP datagram delay
application response time
session blocking rate,
circuit switch call blocking
rate
PDCH utilization
assigned PDCHs

20
20/06/2003
Validation I (Analytical TCP Model, Meyer2001])
TCP Client TCP Server Transmission time t for a file of size F:
( F − BSS )
t ( F ) =N SS ( RTT + TBFsetup ) + + DLCH
}
PSH + Data RTCP
SLOW START
1st RTT
ACK Transition to steady state with the number of Round-trip
periods Nssss :   R ( RTT + TBF )  
}
TCP setup
 log  
W MSS NSS Winit MSS
2nd RTT RTT ≤ init k SS ⇔ N SS =  
RTCP  log(k ss ) 
 
 
}
Amount of data Bssss transmitted in slow start:
STEADY STATE
3rd RTT
 1 − k SS N SS 
BSS =Winit MSS  
 1 − k SS 
M ode l W W W ( 3 70 0 b ytee)- m a il ( 1 kb yte )

A n a lyt ica l 1 4 .9 kb it /s 2 2 .7 kb it /s
Sim u la t io n 1 7 .2 kb it /s 2 2 .9 kb it /s

21
20/06/2003
Validation II (Measurement)
Downlink IP throughput (FTP)
Vodafone NL GPRS measurement settings 30
GPRSim
Measured
• CS-2 25
Downlink IP throughput [kbit/s]

• 4 fixed PDCHs
• Multislot (dl/ul) 3/1 20
BTS 15
Notebook &
10
GPRS mobile
Um
BSC
5
PPP
infrared G
b SGSN
(WinDump) 0
1 1.5 2 2.5 3 3.5 4 4.5 5
Number of mobile stations
IPBackbone GGSN
External
Measurement Point Network
Gi IPNetwork
Internet
Web
Server
22
20/06/2003
Outline
• QoS support
management

23
20/06/2003
Fluid-flow Model Approach
• Basic concept:
 Traffic sources are water taps, being randomly turned on and off
 Regarded network element is a water reservoir with constant depletion rate C
• Source model: Markov-modulated Rate Process (MMRP)
 Single source: behavior controlled by two-state Markov Chain
 Multiple sources: Superimposing N equal MMRP‘s again leads to an MMRP
• MMRP parameters: alpha = 0.187, h = 3272 byte/s , EN_B = 9150 byte

100000
GPRSim with ON/OFF sources
 ON state probability  (activity factor) GPRSim with WWW sources
Mean IP Datagram Delay [ms]

 Mean burst length ENB Fluid-flow Analysis
10000
 Transmission rate during ON state h
h
 µ= 1000
EN B
OFF ON
α
 λ =µ⋅ 100
1−α
10
0 1 2 3 4 5 6 7 8 9 10
Peter Stuckmann‘s thesis work Number of MS 24
20/06/2003
MMAP/G/1 Queue [Vornefeld 2002]
• Arrival Process: analytically tractable representation of Choi‘s
WWW model using Marked Markovian Arrival Process:
 Sojourn times in on and off phase approximated with PH-type
distributions (EM algorithm)
 Poisson arrivals of single IP datagrams during on phase
• Accounts for complicated stochastic nature of arrival process
• Traffic sources can have individual service time distributions
• No batch arrivals of IP datagrams
• Service Process: n-point distribution describing the number of
time slots required for transmission of an IP datagram
 Link-level simulations, models of channel coding and radio channel
 Each IP packet (576 byte) leads to batch arrival of RLC blocks
 Size of batch determined by applied Coding Scheme (CS)
• Approximation of n-point distribution by cont. PH-dist. (EM alg.)

25
20/06/2003
Result Comparison: System Capacity and CIR
Scenario parameters: 1e+06
Simulation 2 PDCHs
• 1 MS Analysis 2 PDCHs
Simulation 4 PDCHs
• CS-2 Analysis 4 PDCHs
• MSC = #PDCHs 1e+05
Mean IP packet delay [ms]

1e+04
Deviations caused
by TCP protocol
behavior: 1e+03
❍ Batch arrivals on
IP level
❍ Slow start and 1e+02
congestion
avoidance
(elastic traffic) 1e+01
5 10 15 20 25 30
Mean C/I [dB]

26
20/06/2003
Outline
• QoS support
management

27
20/06/2003
Performance and system measures
• Application response time
 for each received file (WAP deck, e-mail or WWW page) the difference
between the date of request from the client (GET request) and the date of
reception at the client is calculated
• Downlink IP throughput per user
 during an ongoing transmission the downlink IP throughput for each user
is calculated for each TDMA frame
• Downlink IP datagram delay
 for each received IP packet the difference between the date of
transmission (IP data request) and the date of reception (IP data
indication) is calculated
• Downlink IP system throughput per radio cell
 the quotient of the total amount of received IP bytes in one radio cell
divided by the regarded time period
 equals the offered IP traffic (loss-free system)
• Downlink PDCH utilization
 the quotient of the number of transmitted radio blocks containing data or
control information divided by the total number of transmitted radio blocks

28
20/06/2003
General Simulation Parameter Settings
multislot cap. (DL/UL) 4/1
coding scheme CS-2
PDCHs fixed 8
PDCHs on-demand 0, 8
C/I [dB] 12 (BLER = 13.5 %)
cluster size 3, 7
cell radius [m] 300, 3000
MS velocity [km/h] 7, 100
TCP version Reno
TCP MSS [byte] 512
TCP maximum window size [kbyte] 8
HTTP version 1.1
Traffic mix WWW / email 30% / 70%
Traffic mix WAP / WWW / email 60% / 12% / 28%
Traffic mix Streaming / WWW / email 10% / 27% / 63%

29
20/06/2003
GPRS with Fixed PDCHs
• Maximum user throughput of 22 kbit/s

• Maximum system throughput of 56 kbit/s for 8 fixed PDCHs

30
20/06/2003
Effect of Multislot Capability and C/I
• Effect of multislot capability only visible in situations with low

traffic load
• Low sensitivity of performance to mean C/I

31
20/06/2003
GPRS with on-demand PDCHs
• Performance degradation only occurring with high coexisting

speech traffic
• Effect of lower speech traffic visible in situations with medium
GPRS traffic
32
20/06/2003
Outline
• QoS support
management

33
20/06/2003
WAP vs. Conventional Internet Applications (I)
• WAP and e-mail response times remain below 5 s for the whole
load range for pure traffic scenarios, while WWW exceeds 30 s
• In the traffic mix scenario (60% WAP, 28% email and 12%
WWW), WWW performance increases, while e-mail and WAP
performance decreases slightly
34
20/06/2003
WAP vs. Conventional Internet Applications (II)
• Low throughput performance for WAP because of small deck size

• E-mail performance remains stable in pure traffic scenario
because of low offered traffic per session
• Similar behavior of WWW and e-mail in traffic mix scenario
because of equal load conditions
35
20/06/2003
Streaming vs. Background Applications (I)
• Streaming performance in traffic mix scenario stable over the

whole load range for EGPRS, up to 20 MSs for pure Streaming
• For GPRS only 5 MSs (pure) and 15 MSs (mix) acceptable for
Streaming applications
• WWW performance only affected in GPRS scenario
36
20/06/2003
Outline
• QoS support
management

37
20/06/2003
Dimensioning for Fixed and On-demand PDCHs
• Dimensioning graph for fixed PDCHs based on the performance

for different resource configurations over the offered IP traffic
• Dimensioning graph for on-demand PDCHs based on the
performance for different coexisting speech loads over the offered
IP traffic
38
20/06/2003
Traffic Engineering Rules
1)Define the QoS target

2)Estimate the number of users per cell
3)Define the offered IP traffic per user
4)Calculate the offered IP traffic per cell
5)Regard the operating point p defined by the QoS
target on the y-axis and the offered traffic per cell
on the x-axis and choose the next curve that lies
above p
6)Result: Number of fixed PDCHs to be allocated or
the acceptable coexisting speech traffic

39
20/06/2003
Outline
• QoS support
• Mutual dependency of traffic engineering and
traffic management

40
20/06/2003
Dimensioning Graphs without QoS support
• Streaming performance starts to decrease with an offered traffic

of 20 kbit/s and 4 fixed PDCHs
• Streaming application can be seen as the critical application

41
20/06/2003
Dimensioning Graphs with QoS support
• In using DWRR the performance of Streaming applications can be

increased
• Depending on the QoS target for lower prioritized applications a
resource configuration with 4 fixed PDCHs might be sufficient
42
20/06/2003
Conclusions
• Traffic engineering rules for the cost-effective evolution of cellular
packet radio networks
 Requirements: applicability and accuracy
 Approach: traffic models and prototype implementation (GPRSIM)
 Result: Dimensioning graphs for fixed and on-demand configurations
• Advanced traffic management techniques
 Proposed scheduling algorithms for best-effort services
• DPARR very effective and easy to implement
 Proposed scheduling algorithms for traffic class support
• Solution should be based on the operator´s strategy
 Connection admission control parameterization
• Mutual dependency of traffic engineering and traffic management
 Estimate the effects of QoS support and best-effort scheduling on
traffic engineering rules
 Stay inline with network evolution

43
20/06/2003
Research Contributions
• Development of a comprehensive GPRS/EDGE emulation tool for
radio interface performance analysis and capacity planning
• Identification and development of traffic models for existing and
future mobile applications
• Comprehensive performance analysis for GPRS and EDGE networks
considering a wide range of applications and system parameters
• Derivation of radio resources traffic engineering rules for the cost-
effective evolution of cellular packet radio networks
• Development and performance evaluation of advanced QoS
management algorithms for cellular packet radio networks
• Book publication “The GSM Evolution” (Wiley 2002)
• 2 journal publications
• More than 20 conference papers
• 1 patent

44
20/06/2003
What can we learn from this work?
Thoughts on TE of CDMA Cellular Networks
• Can we borrow the TE methodology in this work?
• Survey of simulators of CDMA networks (not complete yet):
•NS2, Glomosim, SSF, Telesim: not provide.
any other free network simulator?
•Several commercial products: e.g. Opnet wireless module,
MACdma, Netplan (Motorola), CELLsim (Nomad Access) etc.
• At the initial stage, can we build a simple simulator (without
implementation of full protocol stack) for a good enough evaluation?
Must consider the key features of CDMA systems: interferencelimited
capacity.
• Theoretic analysis is always a good starting point.

45
20/06/2003

Gprs

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gprs

Uploaded by

Copyright:

Available Formats

Traffic Engineering Concepts

for Cellular Packet Radio Networks

Based on Peter Stuckmann‘s Public PhD defense on

• Motivation and objectives

Peter Stuckmann‘s thesis work

term circuit-sw itched packet-switched

Peter Stuckmann‘s thesis work

Peter Stuckmann‘s thesis work

• Packet Data Channels (PDCHs) assigned out of pool of GSM

Peter Stuckmann‘s thesis work

acceptable traffic offered traffic predicted traffic offered traffic

Peter Stuckmann‘s thesis work

Peter Stuckmann‘s thesis work

QoS limit 2 QoS limit 2

acceptable traffic offered traffic (aggregate) acceptable traffic offered traffic

Peter Stuckmann‘s thesis work

Peter Stuckmann‘s thesis work

object 1 object 2 object m

Peter Stuckmann‘s thesis work

Parameter Distribution Mean Variance

Pages per session Geometric 5 20.0

Peter Stuckmann‘s thesis work

• Larger WWW pages with higher object sizes

Peter Stuckmann‘s thesis work

Parameter Distribution Mean Variance

Peter Stuckmann‘s thesis work

Decks per session Geometric 20.0 3800

Peter Stuckmann‘s thesis work

Sequences Offered IP traffic

C laire 10.9 kbit/s

Peter Stuckmann‘s thesis work

Peter Stuckmann‘s thesis work

Peter Stuckmann‘s thesis work

Peter Stuckmann‘s thesis work

Peter Stuckmann‘s thesis work

M ode l W W W ( 3 70 0 b ytee)- m a il ( 1 kb yte )

Peter Stuckmann‘s thesis work

Downlink IP throughput [kbit/s]

Peter Stuckmann‘s thesis work

• MMRP parameters: alpha = 0.187, h = 3272 byte/s , EN_B = 9150 byte

Mean IP Datagram Delay [ms]

Peter Stuckmann‘s thesis work

• MSC = #PDCHs 1e+05

Mean IP packet delay [ms]

Peter Stuckmann‘s thesis work

Peter Stuckmann‘s thesis work

Peter Stuckmann‘s thesis work

Peter Stuckmann‘s thesis work

• Maximum user throughput of 22 kbit/s

Peter Stuckmann‘s thesis work

• Effect of multislot capability only visible in situations with low

Peter Stuckmann‘s thesis work

• Performance degradation only occurring with high coexisting

Peter Stuckmann‘s thesis work

• Low throughput performance for WAP because of small deck size

• Streaming performance in traffic mix scenario stable over the

Peter Stuckmann‘s thesis work

• Dimensioning graph for fixed PDCHs based on the performance

1)Define the QoS target

Peter Stuckmann‘s thesis work

Peter Stuckmann‘s thesis work

• Streaming performance starts to decrease with an offered traffic

Peter Stuckmann‘s thesis work