Sei sulla pagina 1di 5

MULTI-SERVICE RADIO DIMENSIONING FOR UMTS PACKET-SWITCHED SERVICES

Dina Adiego and Christophe Cordier


Orange Support & Consulting, Innovation & Training Departement
10-12 rue Massue, 94306 Vincennes Cedex, France
Email: dina.adiego-navarro@orange-sc.com, christophe.cordier@orange-sc.com
Abstract: In this paper, we address the issue of multi-
service packet demand modeling in the radio
dimensioning process for 3G/IMT-2000 systems. For
packet services, Quality of Service (QoS) is measured as
a time delay over the radio interface. New tables
stemming from simulations are proposed to convert the
volume of packet data expressed in Mbits into a required
pipe respecting the QoS. The mix of packet services with
different QoS requirements and the mix of circuit and
packet services are also addressed. This new demand
modeling scheme has been implemented in Orange
Support & Consultings dimensioning tool, ndt and
compared to the results of Orange Support &
Consultings UTRA simulation tool.
I. INTRODUCTION
IMT2000-compliant Third Generation systems like UMTS
will offer a wide range of services, with different data rates
and various QoS requirements. The introduction of the
packet services in mobile networks demands radical
modifications in the engineering process, and specific tables
for packet services are required to convert traffic demand
into needed resources.
UTRA-FDD radio interface, such as specified by 3GPP,
supports multiple bearer services. The segmentation of
packet services for UMTS considers UDD (Unconstrained
Delay Data) services, with rates ranging between 64 and
2048 Kbps. The traffic demand is expressed in Mbits per
peak hour and the QoS is measured as a time delay over the
radio interface. Each type of service may have its own QoS
requirement. As packet data transmission represents a new
feature in mobile networks, for packet traffic there is no
equivalent of the Erlang laws for circuit traffic, to convert
the volume of packet data into a required pipe respecting the
QoS requirements. Consequently, new tables adapted to
packet services specificity are needed to accomplish that
conversion. The challenge of packet demand modeling is
tackled in this paper.
II. PACKET TRAFFIC MODEL
In addition to speech, packet data traffic will be the major
component of the multiple services offer expected from
third generation systems. Packet data traffic is much more
bursty than voice traffic, and besides, data traffic has
different quality of service (QoS) requirements: on the one
hand data traffic is much more tolerant to delay than voice
traffic, but on the other hand data is much more sensitive to
bit errors.
The traffic model used in this study is the Web model
defined by ETSI [1]. That is the model recommended for
Internet traffic and it has adaptable parameters in order to
represent a variety of services and traffic behaviors. The
parameters of this model have been chosen to represent only
downlink web traffic.
This model suggests a three-layered structure. The highest
entity is a packet session arriving with a Poisson
distribution. The session consists of a sequence of packet
calls. The user initiates a packet call when requesting an
information entity. During a packet call several packets are
generated, representing the collection of IP packets coming
from a WWW page.
III. PIPE SIMULATION APPROACH
Simulations of packet traffic have been performed in order
to analyze the behavior of packet services and to build a
dimensioning method for this type of services. Two
complementary blocks constitute the developed simulation
tool: Generation and Processing.
The Generation block generates the traffic for a peak hour
following the steps set by the model: firstly, sessions are
created with a rate depending on the total amount of data to
be exchanged; secondly, packet calls are generated inside
these sessions; thirdly, each packet call is composed by a
certain number of packets that must also be generated.
For bandwidth calculation purposes, the resulting signal
from the Generation block corresponds to the data stream
arriving to the base station at the peak hour. To have more
accurate statistics, the signal has been simulated during
several peak hours.
The Processing block has to determine the necessary
bandwidth in kbps to support the traffic volume respecting
the different QoS. Delay in the buffer of the base station is
the only parameter that affects the QoS in this study. Figure
1 presents the developed approach:
The buffer and the pipe, the latter representing the radio
resources bandwidth, constitute the queuing system. Its
input signal is the volume per second that arrives to the
buffer.
For a given pipe size we can picture the state of the buffer
at each second: processed data volume (the maximum
0-7803-7589-0/02/$17.00 2002 IEEE PIMRC 2002
allowable is the pipe value); stored data volume and delay
due to this storage. With this information we create the
cumulated density function of the buffer delay for a given
input and a given pipe size.
Figure 2 shows an example of this type of representation.
The situation of a service at 64 kbps and 100 Mbits of traffic
is analyzed. Let us consider a pipe of 50 kbps: for 95% of
the cases the delay is lower than 2 s. Hence, in this case, a
pipe of 50 kbps assures a QoS of 2s.
The way to compute the required bandwidth consists in an
iterative process. Different pipe size values are considered
and the guaranteed QoS for each one is calculated. The
resulting pipe size is the lower one that assures the QoS.
IV. DIMENSIONING TABLES
The iterative process described above has been performed
for all standardized data rates and for a set of possible delays
(QoS). For a given data rate-delay pair we obtain a curve to
get the required bandwidth for a given volume of data. The
input volume ranges from 4 to 130000 Mbits per peak hour.
The next two figures present these curves for a service at 64
kbps with seven target QoS values.
The next curves illustrate the margin needed in the
bandwidth evaluation in order to account for packet arrival
burstiness. The higher the tolerated delay and the lower is
the required margin.
The black thick line represents the average bandwidth
without taking into account QoS constraints. We note that
this average pipe is not sufficient and one must necessarily
consider the QoS in packet traffic dimensioning.
We can observe in these curves a similar behavior to that of
the Erlang curves used to estimate the resources for circuit
switched services: the low data volumes are associated with
curves that are tending to saturation, but for higher data
volume the curve is near to a straight line (i.e. linear
asymptotic behavior).
We can also point out a relevant effect: when the data
volume is high enough, the straight lines for the different
QoS for a given data rate have a tendency to converge to the
same straight line (service dependent). This fact is much
more relevant for the higher delays, but this behavior
suggests that for a very high data volume, the required pipe
is fixed, independent from the chosen QoS and does not
coincide with the average bandwidth.
In the sequel we will call these curves Pipe
ji
and they will be
used as follows to calculate the required pipe
(PipePacket
ji
(kbps)):
( ) ( ) ( ) Mbits Vol Pipe kbps PipePacket ji ji ji = (1)
with
( ) Mbits Volji : volume of traffic for data rate j and QoS i.
V.PACKET MULTI SERVICE CASE
Once the processing of a single packet service class is
settled, one must consider the required bandwidth for a mix
of packet traffic demands. All the packet services must be
separated according to their QoS requirement. First one
must deal with the services with different data rates but the
Fig. 3: Dimensioning curves for 64 kbps

0 5 10 15 20 25 30 35
0.84
0.86
0.88
0.9
0.92
0.94
0.96
0.98
1
1.02
CdF of buffer-delay test64k-100
Time(s)
P
r
o
b
a
b
i
l
i
t
y


Pipe=50Kbps
Fig.2 : Cdf curve example
Pipe
Buffer
Data arrival
Fig. 1: Approach developed in simulations
same QoS requirement. In a second step the multi-service
case involving different QoS constraints is handled.
To compute the required bandwidth for several packet
services with the same QoS requirement (QoS
i
), multi-
service simulations have been performed (straightforward
extension of simulation model described in section III).
However, exploitation of multiservice simulation results
within a dimensioning tool is rendered difficult by the
variety of possible profiles: it is impractical to store all
curves corresponding to all possible service combinations.
In this context, a single-service based solution has been
sought to treat multi-service situations. The following model
has been successfully introduced, namely a weighed sum of
individual service pipes applied to the total volume
including all services. The next formula summarizes this
methodology (j is the data rate index and i is the QoS
index):
Vol
ji
: traffic volume (Mbits) for data rate j and QoS i.
Pipe
ji
(Vol): curve stemming from simulations to compute
the required bandwidth for a given volume Vol
ji
for data rate
j with QoS i.
( )

=
=
j
ji i
i ji
j i
ji
QoSi
Vol Vol
Vol Pipe
Vol
Vol
PipePacket
with
(2)
Simulations of various packet services with the same QoS
have been performed to validate this formula. Different data
rate combinations, with a high spectrum of traffic volume
have been considered for all QoS values. Then, the
simulated pipe is compared to the proposed multi-service
model.
Figure 4 depicts an instance of this comparison. Different
combinations of UDD 64, UDD 144 and UDD 384 services,
with traffic values of 24, 48, 72 and 96 Mbits are analyzed.
0
50
100
150
200
1 2 3 4 5 6 7 8 9 10
P
i
p
e

(
k
b
p
s
)
Theoritical
Simulated
We observe in this graph that the bandwidth values obtained
with the last formula are very close to the simulated ones.
The found error for all the tests does not exceed 3%.
Therefore, the weighed sum theoretical model explained
above for the multi-service mono-QoS bandwidth
calculation gives results close enough to the simulated ones
to validate this formula.
With the unchanged concern of minimizing the storage of
results for dimensioning, a similar model has been
established to address the multi-QoS case. A possible option
could be the simple addition of pipes for the different QoS
to compute the global pipe for the multi-QoS case. This
approach leads to an over dimensioning because the margin
originally applied to guarantee a given QoS is rarely used.
The basic idea is that this margin can be reused to absorb
part of lower priority traffic (with higher tolerated delay).
The treatment of packet services with different QoS
requirements then lies in the reuse of the spare capacity of a
more restrictive QoS by the next less demanding one.
We introduce the concept of Pipe Occupancy to calculate
the Spare Capacity for a given QoS value. The Pipe
Occupancy per service and per QoS is defined as the
average percentage of the Pipe used each time and it is
calculated as the ratio between the average data rate and the
Pipe size.
3600 * ) (
) (
kbps PipePacket
kbits Vol
ncy PipeOccupa
ji
ji
ji
=
(3)
To calculate the Pipe Occupancy per QoS a weighed sum is
applied as described next.
( ) i ji
j
i
ji
QoSi Vol ncy PipeOccupa
Vol
Vol
ncy PipeOccupa =

(4)
Then the spare capacity is computed as follows
( ) QoSi QoSi QoSi ncy PipeOccupa PipePacket ity SpareCapac = 1 * (5)
Supposing the mix of two QoS values , where QoS
1
is more
restrictive than QoS
2
, the next figure displays the principle
of the spare capacity reuse:
Resorting to simulations modified to process several
services and several QoS, we have observed that reusing the
total spare capacity implies under-dimensioning. Then, a
correction factor indicating the fraction of the spare capacity
to be reused is introduced. This factor is calculated for a
given pair of QoS values: it depends on both QoS involved
and ranges from 60% to 90%.
VI. COMPREHENSIVE SIMULATION TOOL
The simulation approach described in section III does not
take into account specific packet transmission mechanisms
Fig. 4: Validation of the theoretical method for the
computation of the multi-service mono-QoS
Pipe QoS
1
x
Pipe Occupancy QoS
2
Fig. 5 : Spare Capacity reuse concept
Packet Pipe
Packet Pipe QoS
1
Packet Pipe QoS
2
Spare Capacity
QoS
1
like segmentation and scheduling, such as specified in RLC
and MAC layers of UTRA-FDD radio interface protocol.
Orange Support & Consultings simulation tool follows the
approach described earlier but including packet
segmentation and scheduling and allowing the coexistence
of circuit and packet-switched services. The next figure
presents the segmentation and scheduling mechanisms
applied:
This tool allows to perform an accurate dimensioning of
radio and transport (ATM) resources, because it models
each layer of the network from the application layer to the
physical layer: traffic demand and modeling application
layer;transport block scheduling and QoS management
MAC layer with physical layer; ATM shaping ATM
layer. Scheduling can be done either according to the
bandwidth or to the BTS power. In addition, the tool
presents advanced features, such as Channel Element
number calculation.
Figure 7 presents the packet services processing: traffic flow
is generated following the ETSI model, it is segmented into
payloads and queued in the RLC buffer, next the transport
blocks are built and the packet scheduling is performed;
finally the occupied radio bandwidth is shown.
In the case of our study, the described simulation tool has
been used to validate results of the pipe model. Figure 8
shows the comparison between curves presented in section
IV and detailed simulation results for a packet service at 64
kbps and 0.5s of QoS.
0
50
100
150
200
250
300
10 25 50 100 150 200 250
Volume (Mbits)
P
i
p
e

(
k
b
p
s
)
Pipe model 0,5s
Simulation tool 0,5s
As revealed in the previous graph a good agreement has
been found between detailed simulation tool bandwidth
results and those previously obtained with the simplified
pipe model.
This tool is also useful to calibrate some key parameters, as
described in the next section.
VII. MIX OF CIRCUIT AND PACKET SERVICES
We have presented a method to compute the needed
bandwidth for packet services alone with different data rates
and QoS requirements. The required bandwidth for circuit
services can be calculated using the Erlang laws [2]. Now,
we can envisage the calculation of the total bandwidth
required to handle both circuit and packet services.
As considered for packet services, we can contemplate the
reuse of the spare capacity from the circuit services to carry
packet services traffic. However, as this spare capacity is
needed to guarantee the blocking rate for circuit services,
and in order to avoid under-dimensioning, we must set an
appropriate correction factor. This correction factor (CctF)
imposes the allocation of only a fraction of the spare
capacity to packet services and takes into account the
fluctuations of circuit traffic.
ircuit SpareCapaC CctF PipePacket t PipeCircui Pipe * + = (6)
To calibrate this factor, the simulation tool described in
section VI has been used and we have obtained that the
recommended value is to reuse 80% of the circuit spare
capacity.
For example, let us consider a mix of two services: 3
Erlangs of speech and 200 Mbits of packet service at 64
kbps. Tolerated QoS is 2% of blocking for speech and 0.5 s
of delay for packet service. Table 1 summarizes pipes
results using the methodology proposed in this article. Table
2 recapitulates results from the simulation tool.
We can see that the single service results obtained by
simulation are very close to the theoretical ones (Erlang B
Fig. 7 : Packet services processing in the simulation tool

Application
RLC
MAC
Traffic flow generation
(traffic modeling)
Scheduling of transport blocks
(with radio QoS management
and bandwidth use policy)
Traffic data segmentation into
Payload Units (associated to the
radio bearers) and queuing
Fig. 6: Segmentation and scheduling mechanisms
Fig. 8: Pipe model and simulation results comparison
law for speech and Pipe tables stemming from simulation
for packet service). Same conclusions can be drawn for the
multi-service case: the value of 80% of reuse of the circuit
services spare capacity by packet traffic is also validated
thanks to the simulation tool.
Table 1: Bandwidth calculation example
Circuit Packet Circuit+Pack
et
Pipe (kbps) 97.6 212.85 261.65
Calculation means Erlang B Eq. (1) Eq. (6)
Spare Capacity(kbps) 61 28.08 Not required
Table 2: Bandwidth simulation results
Only Circuit Only Packet Circuit+Packet
Pipe(kbps) 98.2 216.125 252.65
QoS 1.89% 0.341 s 0%; 0.451 s
VII. IMPACT OF PACKET DEMAND MODELING ON
DIMENSIONING RESULTS
The previous dimensioning rules for packet services,
specifically the pipe model, have been implemented in
Orange Support & Consultings dimensioning tool, ndt.
For circuit services, multi-service Erlang laws are used as
described in [2].
UMTS radio dimensioning is performed in 2 steps in ndt
(see Fig. 9):
1
st
Dimensioning by coverage, to evaluate the minimum
number of sites required providing coverage over the
considered area.
2
nd
Carrier upgrade and traffic dimensioning which aims
at adjusting network resources to absorb traffic demand.
Let us consider the subscriber profiles (downlink traffic) in
Table 3.
Profile 1 represents subscribers with high circuit switched
traffic and low packet switched traffic. Profile 2 is related
with high traffic subscribers for all services. Considering
1000 subscribers, the resulting bandwidths for both profiles
are presented in next Table 4.
As the circuit traffic is similar for both profiles, the required
circuit pipe remains invariable. On the other hand, as the
packet traffic is much higher in profile 2, the required packet
pipe is considerably more elevated than in profile 1.
Table 3: Subscriber profiles
Profile 1 Profile 2
Speech (mErlang) 8.33 8.33
LCD 64 (Mbits) 0.03 0.03
LCD 144 (Mbits) 0.062 0.062
UDD 64 (Mbits) 0.00124 0.0624
UDD 144 (Mbits) 0.00305 0.0905
UDD 384 (Mbits) 0.011 0.91
Table 4: Bandwidth results example
Required Pipe (kbps) Profile 1 Profile 2
Circuit Pipe 378.2 378.2
Packet Pipe 47.49 669.23
Total Pipe 378.2 806.002
Regarding the total pipe, we observe that in profile 1 the
reuse of the circuit spare capacity is enough to carry packet
traffic. That is why the total pipe equals the circuit pipe. In
this configuration, no additional bandwidth is required to
support packet data traffic.
But for profile 2, circuit spare capacity is not large enough
to contain the packet pipe and additional pipe with respect to
circuit bandwidth is required to carry packet traffic.
However, a portion of the circuit spare capacity is reused
the total pipe is lower than the sum of circuit and packet
pipes.
VIII. CONCLUSIONS
A novel method has been presented to evaluate the
bandwidth needed to handle the packet traffic respecting the
different QoS constraints. Dimensioning tables, equivalent
to Erlang laws for circuit services, have been built as a result
of traffic generation and processing simulations for each
data rate-QoS pair.
A method to derive the needed bandwidth for different
services with the same QoS is proposed, and the way to mix
the required bandwidth for different QoS is also presented.
To finalise the dimensioning process, the mix of circuit and
packet services is addressed. The obtained results have been
validated using a sophisticated simulation tool, employing
UTRAN scheduling and segmentation mechanisms.
This simple and efficient dimensioning model has been
implemented in Orange Support & Consultings
dimensioning tool ndt
TM
, and it offers an essential
instrument to predict the impact of packet data traffic onto
the roll-out of 2.5G and 3G networks.
VIII. REFERENCES
[1] "UMTS 30.03 version 3.2.0", ETSI
[2] D. Adiego, C. Cordier "Multi-service Radio
Dimensioning for UMTS Circuit-Switched Services",
IEEE VTC Fall 2001.

Traffic vo l ume
Surface (km)
QoS Yes
Number of
carriers
Coverage
dimensio n ing
Cell
size
Traffic
vo l ume
per cell
Figure 9 : Dime n sioning flow chart
No
END
B
N
needed BW
Bo>B
N
B
O
offered BW
M ulti-service
Traffic demand
modeling

Potrebbero piacerti anche