Traffic Calculation Guideline Hsdpa

ERICSSON WCDMA RADIO ACCESS NETWORK
TRAFFIC CALCULATION
GUIDELINE HSDPA
 Ericsson Radio Systems AB 2005

The contents of this product are subject to revision without notice due to continued progress in methodology,
design and manufacturing.
Note that this document contains information that should only be distributed within Ericsson organization and to
CONTRACTED WCDMA customers. The document has obtained the classification ERICSSON WIDE INTERNAL.
This also means that it should not be used directly for marketing, pre-sales or sales purposes.
137/100 56-HSD 10102/4 Rev A 2005-12-05 ERICSSON WIDE INTERNAL INFORMATION 1(47)
TRAFFIC CALCULATION GUIDELINE HSDPA
Revision history
Rev Date Description
A 2005-12-05 First release For P4
2(47) ERICSSON WIDE INTERNAL INFORMATION 137/100 56-HSD 10102/4 Rev A 2005-12-05
Contents
1 Introduction.........................................................................4
1.1 Background, purpose, overview...........................................................4
1.2 Concepts..............................................................................................4
1.3 Abbreviations.......................................................................................4
2 Assumptions and definitions............................................5
2.1 Introduction.......................................................................................... 5
2.2 Traffic model........................................................................................6
2.3 Transport bearers for HSDPA..............................................................7
2.4 Transport network topologies.............................................................10
2.5 Dimensioning criteria.........................................................................14
2.6 Elastic user model used in HSDPA user model.................................15
2.7 HS-DSCH transport efficiency...........................................................15
3 Dimensioning method......................................................17
3.1 The dimensioning steps.....................................................................17
3.2 Calculation Method for Step 2...........................................................20
3.3 Calculation Method for Step 4...........................................................25
3.4 Calculation Method Step 5.................................................................29
3.5 Calculation Method step 6.................................................................31
3.6 HUB Iub link dimensioning.................................................................32
4 Examples...........................................................................33
4.1 Separate resources - with IMA...........................................................33
4.2 Common resources - with IMA...........................................................36
4.3 Common resources - with IMA and UBR...........................................39
4.4 Separate resources - without IMA......................................................41
4.5 Final Considerations..........................................................................44
5 References........................................................................45
Appendix A: HSDPA overhead.............................................46
1 Introduction
1.1 Background, purpose, overview

The purpose of this collection of guideline documents is to describe how to
dimension the different UTRAN interfaces in an Ericsson WCDMA RAN for
release P4.
The first guideline contains the Release 99 Radio Bearers. See reference [1].
This is the second guideline, which contains the HSDPA Radio Bearers.
The purpose of this document is to present the dimensioning of transport network
resources for HSDPA related traffic at the Iub and Iur interfaces in WCDMA
RAN.
The dimensioning method is based on the HSDPA features that are supported by
WCDMA RAN P4.
New in P4 is the UBR on AAL2, which allows the user to configure the AAL2
class C for HSDPA on UBR and achieve up to three priorities levels within the
same Virtual Path (VP). The maximum bandwidth utilization for the combination
of Best effort and HSDPA requires three priority levels.
1.2 Concepts
Refer to reference [1].
1.3 Abbreviations
For a list of abbreviations used in WCDMA RAN system documents, see
Reference [2]. Some new abbreviations used within this document are:
A-DCH Associated Dedicated Channel
HSDPA High-Speed Downlink Packet Access
HS-DSCH High-Speed Downlink Shared Channel
QoS Quality of Service
Rel-99 3GPP Release 99
RAB Radio Access Bearer
RB Radio Bearer
Rel-99 RB Radio Bearers defined in Release 99 implemented in WRAN P3,
transported on AAL2 class A/B
SRB Signalling Radio Bearer or DCCH 3.4/3.4
2 Assumptions and definitions
2.1 Introduction
The traffic dimensioning for HSDPA described in this document is based on a
network scenario where the WCDMA RAN supports mixed circuit switched and
packet switched services and where a large part of the total traffic is carried on
dedicated channels, DCH. HSDPA is assumed to be used to provide
interactive/background packet switched services whenever possible, but the
proportion of PS traffic that is carried by HSDPA is restricted by the capabilities of
the user equipments.
The dimensioning of transport network resources in this network scenario is
structured into two parts:
 The need for transport network resources to carry Rel-99 and non-HSDPA
traffic are calculated according to the methods specified by Ref.[1].
 The additional transport network resources needed to carry HSDPA traffic

is calculated according to the guidelines described in this document.
The main impact from HSDPA on TN dimensioning is related to the Iub traffic.
The possible impact on dimensioning for HSDPA related traffic over Iur is
discussed separately in the document.
For the Iu dimensioning there is no need for any new method due to introduction of
HSDPA in the network. The Iu-PS user plane connections and protocols are the
same independent of the type of radio bearer and transport channel that is used at
the radio interface.
The dimensioning methods are based on the assumption that the user traffic load in
the downlink direction is so much larger than the traffic load in the uplink direction
that it is sufficient to dimension the Iub transport network resources for the
downlink traffic direction, provided that physical and ATM layer connections are
provisioned with the same capacity in both directions.
2.2 Traffic model

The user traffic model, describing average session intensities and transmitted data
volumes per user of packet switched services, represents the main input to the
traffic dimensioning process.
Examples in this document are derived from the Ericsson traffic model used as
reference for system design and verification.
The user traffic model may be specified with detailed characteristics for each of a
number of typical applications, like web browsing, long file transfers, WAP traffic,
E-mail and MMS. For the HSDPA-specific transport network dimensioning it is
assumed that the mixed characteristics for applications using
interactive/background RABs.
2.2.1 Mandatory HSDPA input data

Input data can be divided into two parts: the first one is mandatory to collect and
the second one can be treated as system constants.
Mandatory HSDPA input data to be collected and used in the dimensioning:
1. Number of users
2. Number of HSDPA capable cells
3. Average busy hour (HS) load [kbps/user]
4. Required average (HS) user bit rate [kbps]
5. Target peak bit rate for single (HS) user [kbps]
Constants describing system behavior (default values will be used in the
dimensioning):
1. Peak Air interface rate (default is 4320) [kbps/cell]
2. Average number of PDUs per HS-DSCH data frame (default is 8)
3. RLC payload length (default is 40) [octets]
4. HS-DSCH transport efficiency (default is 0.8)
5. HSDPA Inactivity timer (default is 10) [s]
6. Grade of Service for HSDPA CIDs
(default is 0.03%1 for SRB HSDPA user CID and 0.7% for HS CID)
7. Mean Holding Time for typical HSDPA session (default 19 s)
8. Soft Handover Factor for HSDPA connections (default 44%)
2.3 Transport bearers for HSDPA

1 1 order of magnitude less than the minimum R99 RABs GoS [1]: SRB CID availability should not be a blocking factor
2.3.1 Types of transport bearer connections
Iu
The Iu transport bearer for packet switched radio access bearers (using the GTP-U
protocol) is the same whether the corresponding radio links are set up to use
common channels (RACH/FACH), dedicated channels (DCH) or high-speed
downlink shared channels (HS-DSCH).
Iub
Three types of AAL2 transport bearer connections are used at Iub for HS-DSCH
connected UEs:
 Iub transport bearer for DCCH (signaling radio bearers) for uplink and
downlink on DCH
 Iub transport bearer for HSDPA associated uplink DTCH on DCH
 Iub transport bearer for downlink DTCH on HS-DSCH

For a UE in soft handover state, with radio links for dedicated transport channels
(DCH) towards two or more RBSes, a set of the two transport bearers for DCH is
needed to each RBS that the UE is connected to.
As a UE cannot be connected via HS-DSCH in more than one RBS (and one cell)
at a time, a transport bearer for HS-DSCH is needed to one RBS only.
Iur
The transport bearers for DCH can be established also over Iur in the case that the
UE is in soft handover with one or more radio links established to RBSes in
another RNS.
Use of HS-DSCH via Iur is not supported and there is thus no need to establish
transport bearers for HS-DSCH via Iur.
2.3.2 Parameters for AAL2 admission control

The AAL2 connection admission control function needs information about the
expected traffic characteristics and required quality of service for each transport
bearer that is requested by the radio network application.
Iub/Iur transport bearer for DCCH on DCH

The parameters for Iub/Iur transport bearer for the DCCH Signaling Radio Bearer
(3.4 kbps) are the same as for UE connections via DCH, see Ref. [1].
The requested AAL2 class of service is A.
Iub transport bearer for downlink “Interactive PS RB on HS-DSCH”

This transport bearer is characterized by a highly variable data flow rate with a
high peak rate. The data transfer is flow controlled by the RBS and will be adapted
to the available link capacity and the number of simultaneously active users. As
opposed to transport bearers for DCH, the Iub transport bearer for HS-DSCH does
not have any stringent timing requirements.
No AAL2 admission control will be performed for this type of transport bearer at
connection setup.
AAL2 QoS class C will be used for the HS-DSCH transport bearers: no specific
limits on delay or loss tolerance are specified. The AAL2 admission control will
then not evaluate any throughput or capacity limitations for the selected AAL2 path
but will only check that a CID value can be allocated to the connection.
The responsibility for allocation of the available link capacity among active HS-
DSCH transport bearer connections and prevention of excessive transport network
overload is instead placed on the HSDPA Iub flow control function.
The flow control algorithm has information about the maximum capacity for class
C traffic, and has continuously updated knowledge about the number of
connections that have data ready for transmission from RNC as well as the
predicted possible radio interface transfer rate for each connection. The appropriate
Iub transfer rate for each connection is dynamically evaluated and communicated
to the RNC in order to optimize user data transfer performance within the limits set
by the available AAL2 path capacity.
Iub transport bearer for HSDPA associated uplink “Interactive 64 kbps PS

RB” or Interactive 384 kbps PS RB”
In the uplink direction the traffic characteristics parameters for this transport
bearer are similar to the parameters for other interactive 64 and 384 kbps PS radio
bearers on DCH, see Ref. [1]. This transport bearer is however not used for any
downlink transmission and does thus not influence TN dimensioning for the
downlink direction other than that it requires a CID value.
The requested AAL2 class of service for this bearer is class C, that is, the same as
requested for the HS-DSCH transport bearer. The motivation for this is to allow
the uplink traffic for HS-DSCH connected users to use the capacity in the uplink
direction of the same set of AAL2 paths that are loaded by HS-DSCH traffic in the
downlink direction. This implies that there is no need to consider transport network
dimensioning in the uplink direction for those RBSes that support HS-DSCH as
long as the DL traffic is significantly higher than the UL traffic. This is assumed to
generally be the case.
Non-HSDPA capable RBSs that are neighbors to HSDPA capable nodes will be
affected, as soft handover radio links for uplink DCH may need to be supported.
The associated uplink DCH uses soft handover and may have one radio link
established in an RBS that is not otherwise supporting HSDPA but is a neighbor to
an HSDPA capable RBS. It is in this case necessary to configure the transport
network to the RBS to allow use of AAL2 class C.
If the expected traffic volume from the soft handover uplink DCH connections in
the non HSDPA capable RBS is low, it is possible to allow these class C
connections to use the same AAL2 paths as class A/B AAL2 connections without
use of QoS separation. The same (the most stringent) AAL2 admission control
criteria will then be applied to all connections. The traffic load from these soft
handover connections will in many cases not be large enough to motivate a re-
dimensioning of the transport network to non-HSDPA capable nodes.
Iur transport bearer for HSDPA associated uplink “Interactive 64 kbps PS

RB” or Interactive 384 kbps PS RB”
The transport bearer characteristics for the HSDPA associated uplink DCH are the
same at the Iub and Iur interfaces.
The HSDPA associated uplink DCH transport bearer will need to be carried over
the Iur interface whenever there is a soft handover connection with the associated
uplink DCH connected to an RBS that is controlled by another RNC.
When the proportion of HSDPA traffic is low it may be sufficient to reconfigure
existing AAL2 paths for Iur to also accept AAL2 class C connections without re-
dimensioning the Iur capacity. This AAL2 class C VCC should be configured on an
own VCC where UBR is the first/preferable choice or CBR when UBR cannot be
used.
2.4 Transport network topologies

A number of different access network transport topologies are supported in
WCDMA RAN. These are usually categorized as follows:
A: Connections over PDH/SDH networks
B: Connections over external ATM networks
C: Aggregated network structures
D: ATM ring configurations
For all topologies, the transport network dimensioning has to be performed on a
link-by-link basis with consideration of the possibilities and limitations of the
AAL2 and ATM multiplexing capabilities that are supported for different physical
interface and ET board types.
It is then observed that there is a limited number of generic link and AAL2 path
configuration cases for HSDPA (AAL2 QoS class C) that are applicable in the
above topologies, and for which dimensioning methods need to be defined.
These are:
 Single fixed capacity AAL2 path (on CBR) for class C traffic.
 Multiple fixed capacity AAL2 paths (on CBR) for class C traffic
 Single fixed capacity AAL2 path (on CBR) shared by all AAL2 QoS
classes, with class A/B traffic served with priority over class C traffic.
 One or more flexible capacity (UBR) AAL2 paths for class C traffic
combined with one or more fixed capacity (CBR) AAL2 paths for class A
and B within the same fixed capacity VPC. This configuration case will
give an optimal utilization of the total VPC capacity with three priority
levels:
- AAL2 class A will have highest or first priority,
- AAL2 class B will have medium priority and
- AAL2 class C will have low priority.
 One or more flexible capacity (UBR) AAL2 paths for class B and C traffic
combined with one or more fixed capacity (CBR) AAL2 paths for class A
within the same fixed capacity VPC. This configuration case can support
both best effort and HSDPA on the old ET boards (ET-M1 or ET-M4). The
drawback is that class B and C will be on the same priority level (more
about best effort dimensioning, see [4]). This will give us two priority
levels:
- AAL2 class A will have highest or first priority,
- AAL2 class B and class C will have same medium priority but
having separate queues served in round robin behavior.
Some other configuration cases are theoretically possible, but of marginal practical
value and thus not judged to motivate development of specific dimensioning
methods.
2.4.1 Advantages of resource sharing

The resource-sharing scenario has different possible implementations:
 Class A/B and class C traffic on the same CBR VC, class A/B with
priority over class C
o Resources not used by class A/B can be used by class C
 Class A and B traffic with AAL2 QoS separation on the same CBR VC
and class C traffic on a separate UBR VC but within the same VP: in this
case we have three priority levels where class A has priority over class B
and class C, class B has priority over class C
o Resources not used by class A can be used by class B or class C
o Resources not used by class A or class B can be used by class C
 Class A configured on a separate CBR VC, class B configured on a

separate UBR VC and class C configured on a separate UBR VC but all
VCs are within the same VP: in this case we have two priority levels where
class A has priority over class B and class C.
o Resources not used by class A can equally be used by class B or
class C
The dimensioning procedure takes into account the following aspects in order to
cope with the resource-sharing scenario:
A. Typically the class A/B traffic does not load to peak and the resources
allocated for class A/B vary in time. Class C can use the resources not
used by class A/B, but the speed of the adaptation of class C resource
allocation is limited by the dynamics of the protocols that control the
amount of HS-DSCH traffic (such as TCP and the flow control between
the RNC and the Node B). Figure 1 shows an example how Class C traffic
adapts to the varying available bandwidth. When the capacity available for
Class C traffic increases the adaptation slowly explores the additionally
available bandwidth. When the capacity available for Class C traffic
decreases then after detecting the congestion the adaptation cuts the rate of
the flows fast then slowly explores the available capacity. This adaptation
takes time in both cases, which results that not all the capacity remaining
from class A/B traffic can be used by low priority traffic.
HS-DSCH traffic (low priority)

adaptation
DCH connections (high priority)
Figure 1 Class C adaptation to the varying available bandwidth
B. The PS DCHs are usually not fully utilized (see Figure 2):
PS DCH
activity < 100%
Figure 2 The average utilization of PS DCHs is less than 100%
C. To fulfill the strict delay requirements of class A/B connections, the

resources reserved for a DCH by the CAC may well be above the DCH
rate (e.g., 64k or 384k).
For example, consider a system, where we have only two priority queues
on AAL2 level. In this case class A/B share the high priority AAL2 queue
in a FIFO manner, and thus the most stringent delay requirement have to
be fulfilled for all class A/B connections (i.e., the delay requirement of
voice). Assume that the VC capacity is so small that there can be at most
one 384k PS connection in the system. Figure 3 shows that since the delay
requirement, D ~ , is smaller than the TTI, the buffer server is busy only in
a fraction of the time. The AAL2 class C traffic can use remaining
capacity when the class A/B buffer is empty.
~
D
{
TTI
Buffer Buffer Buffer Buffer Buffer Buffer
server empty server empty server empty
busy busy busy
Figure 3 The buffer server is not busy all the time.
All the above effects are considered during dimensioning. The dimensioning is done
using the Kaufmann-Roberts dimensioning method. The low priority traffic demand
is included in the KR dimensioning as a new traffic class.
 Effect “A” is considered by using 10% GoS target value for the newly added
traffic class representing the low priority traffic demand. This means that the
capacity needed for low priority traffic will be available 90% of the time.
 Effects “B” and “C” are considered using the average load of a connection of
a traffic class as an input to KR dimensioning instead of the bandwidth
calculated by the CAC.
Figure 4 depicts the different dimensioned capacities. The green line represents
the bandwidth gain because of resource sharing.
Dimensioned capacity for common VC
O
Capacity need of low priority traffic (available for low
priority traffic at 90% of the time)
O Peak capacity avaiable for low priority traffic
Dimensionined capacity for high priority traffic only
Average capacity used by class A/B in busy hour
Figure 4 Dimensioning in a resource-sharing scenario
Guarantee some capacity for HSDPA

HSDPA traffic on AAL2 class C has lower priority than DCH traffic on class A
and in many cases also class B.
In the following condition in a resource sharing case is a risk that a high DCH
traffic load on AAL2 class A can overwhelm HSDPA traffic:
 CBR+CBR+UBR case i.e. AAL2 class A on CBR, AAL2 class B on CBR

and class C on UBR are configured on same VP. The sum of VCs CBR
capacity is equal to VP capacity
- In this case will the maximum amount of remaining AAL2
resources be available and shared in a priority order than the class
B has higher priority than class C.
 CBR+UBR+UBR case i.e. AAL2 class A on CBR, AAL2 class B on UBR

and class C on UBR are configured on same VP. The sum of VCs CBR
capacity is equal to VP capacity
- In this case will the maximum amount of remaining VP resources
be available and shared equally between class B and C.
This can be avoided by configure higher VP capacity than the sum of VCs CBR
capacity.
2.5 Dimensioning criteria

For transport network dimensioning, not only the traffic load, but also the required
quality of service and grade of service characteristics needs to be specified.
One parameter that is frequently used in marketing of HSDPA services is the
maximum throughput that can be offered to an HSDPA user.
As HSDPA applies dynamic resource sharing among active users, for both radio
and transport network resources, the throughput that can be offered to each user
depends on the total number of simultaneously active users. This property has to be
reflected in the way the QoS criteria for transport network dimensioning are
formulated.
The dimensioning method described in this document assumes that the required
QoS is expressed by the following two parameters:
 Peak user data throughput for single active HSDPA user

If there is only one active HSDPA user in the RBS, then the user should be
able to download long user data files at this rate, unless restricted by other
factors (for example poor radio conditions or low UE capability) than the
dimensioned TN capacity for Iub to the RBS.
 Session average user data throughput during busy hour

This is the average user data download rate within a session that in
average shall be experienced by an HSDPA user during busy hour traffic
load conditions. The experienced rate will vary statistically between
sessions with the variance decreasing for increasing session lengths.
The term Grade of Service (GoS) denotes the probability that a connection request
is rejected due to insufficient resources. The transport bearer admission for HS-
DSCH does not relay on any specific capacity reservation per connection but
capacity allocation is handled dynamically by the Iub flow control. An HS-DSCH
transport bearer connection request will thus not be rejected due to insufficient link
capacity, but it will be rejected if all 248 channel identifier (CID) values of the
selected AAL2 path are occupied. The transport network dimensioning for HSDPA
will thus need the following input parameter:
 Grade of Service for HSDPA transport bearers

This parameter denotes the acceptable probability of blocking of a
connection request due to insufficient transport network resources, for
example CID values.
2.6 Elastic user model used in HSDPA user model

The mathematical model used for HSDPA dimensioning is a special case of the
Elastic user model (see details in Reference [3]). This model is used for users
downloading files with given file size. These users download a given amount of
data per hour, and the length of their sessions depends on the transmission speed
they get.
Elastic users are characterized by their peak bandwidth requirement and average
system load. The applied resource sharing policy for Elastic users is the following:
 If the sum of the peak bandwidth requirements of all flows in the system does
not exceed the link capacity, each flow gets its required bandwidth.
 Otherwise, when the link is serving on its total capacity, the bandwidth is
shared between individual flows in proportion to their peak bandwidth
requirements, that is two flows from the same class always get the same
amount of bandwidth, and a flow with two times higher peak bandwidth
requirement gets two times higher bandwidth as well.
For HSDPA users a special case of the above model was used: all users are of the
same class, and their peak bandwidth requirement equals to the link capacity. This
results a system model where:
 If there is user in the system then the link is utilized to 100%.
 If there is more than one user in the system then the link capacity is shared
among them evenly.
When evaluating the above special case of the elastic user model the average
download rate experienced by a user can be calculated as the link capacity minus
the sum average load of all users.
Of course, HSDPA users cannot share resources ideally. The non-ideal behavior of
HSDPA users was taken to account using a factor called “HS-DSCH transport
efficiency”.
2.7 HS-DSCH transport efficiency

The HSDPA will use the transport network bandwidth/resources much more
efficiently than Rel-99 Packet Switched data RABs do. However the HSDPA users
cannot use the TN resources to 100% due to TCP slow start and Iub flow control
for HSDPA. The “HS-DSCH transport efficiency” is therefore introduced to
quantify how well can the HSDPA use the available bandwidth.
Default and recommended value for this “HS-DSCH transport efficiency” factor is
0.8 (80%) for normal traffic mix of PS traffic but canbe higher for users using ftp
for download of large files.
To achieve as high HS-DSCH transport efficiency as possible it is recommended to
use one AAL2 class C pipe for HSDPA. One pipe can be one CBR VCC or several
UBR VCCs in a CBR VPC. It can be done by using IMA when more than one
E1/T1 is needed or chose a higher capacity link e.g. E3/T3.
When several pipes must be used (e.g. when IMA cannot be used) the HS-DSCH
transport efficiency will be lower.
Having more than one pipe is disadvantageous because of the following reasons:
1. The HSDPA Iub flow control assumes one and only Iub transport network
bottleneck (pipe). If there is congestion on one of the bottlenecks it will
result in reduced throughput on all pipes. This degrades the overall Iub TN
utilization.
2. The achievable peak rate of a HSDPA connection is reduced.
3. The achievable multiplexing gain is reduced, because fewer connections

are multiplexed in one pipe.
3 Dimensioning method
3.1 The dimensioning steps
Step 1:
Collect input data
Step 2:
Determine capacity need for
AAL2 Class C
Step 3:
Determine if common or
separate resources are used
Step 4a : Step 4b:

Calculate capacity for Calculate capacity for
common resources separate resources
Step5:
Determine total link capacity
and conf iguration
Step 6:
HSDPA Flow Control
dimensioning
3.1.1 Step 1: Collect input data
Network specific traffic model:

Non-HSDPA traffic:
 See needed input data according to Ref. [1].

HSDPA traffic:
 Average downlink busy hour user data traffic per user, expressed in
bps/user, which is transferred by use of HSDPA.
 Mean Holding Time for typical HSDPA session
 Soft Handover Factor for HSDPA connections
Data per link to be dimensioned:
 Number of RBS sites, HSDPA capable cells and users that are to be served
by the link or set of links.
 For links serving multiple RBS sites, define whether AAL2 switching is
employed to combine the traffic on a single set of AAL2 paths or whether
the link carries individual sets of AAL2 paths for each RBS site.
 Determine the type of physical layer transmission interface to be used (for

example E1, T1, J1, E3, STM-1, …) and whether the configuration
options are restricted due to use of old ET-M1 boards.
Target values for performance measures:

The same user and system behavior (which is described by the above inputs) can
result different user performance depending on the dimensioned link capacity.
These below parameters describe what is the target performance of the system. By
fixing the value of these performance measures, it is possible to search for the link
capacity, which is enough to meet the below requirements.
 Peak user data throughput for single active HSDPA user
 Target average bit rate (i.e. session average user data throughput) during
busy hour
 Grade of Service for HSDPA transport bearers
3.1.2 Step 2: Determine capacity need for AAL2 class C

The output is the required AAL2 path capacity for class C traffic assuming that the
capacity is fixed and exclusively reserved for class C traffic.
The result also includes the busy hour average number of active HSDPA users.
Number of needed HSDPA VCs is also an output of this dimensioning step. This
value is applicable only if separate AAL2 VCs are used for HSDPA traffic.
See calculation method described in Section 3.2.
3.1.3 Step 3: Determine if common or separate resources are used

Decide if common or separate resources can be used.
1. Separate: separate CBR VCs for AAL2 class A/B and class C will be
dimensioned.
2. Common: three alternatives are possible
2.1. A common AAL2 path is used. Note that in this case all Release
99 RBs are on the same priority level as there are only two priority
queues per AAL2 multiplexer in case of P4 ET Bs.
2.2. Strict admission for a CBR VC containing AAL2 class A and

AAL2 class B and UBR VC for AAL2 class C within same VP.
2.3. Strict admission for a CBR VC class A, Best Effort admission for
CBR/UBR VC AAL2 class B, and UBR VC for AAL2 class C
within the same VP.
3.1.4 Step 4a: Calculate capacity for COMMON resources

The Iub AAL2 VCC capacity for RBS supporting RB for HSDPA and Rel-99
where common AAL2 paths is be used can be calculated using the method
described in Section 3.3.
Check that the Radio air peak capacity for an RBS is not less than the
corresponding HS peak capacity for a single user. This is to avoid unnecessary
over dimensioned transport network. Go to step 5.
3.1.5 Step 4b: Calculate capacity for SEPARATE resources

Calculate required capacity for class A/B traffic. See calculation method described
in section 3.3. Add capacity needed for class A/B to the capacity need of class C.
(Class C capacity was calculated in Step 2).
Check that the Radio air peak capacity for an RBS is not less than the
corresponding HS peak capacity for a single user. This is to avoid unnecessary
over dimensioned transport network.
3.1.6 Step 5: Determine total link capacity and configuration

Determine required number of AAL2 paths and their configuration parameters,
considering capacity and CID requirements for both HSDPA and non-HSDPA
traffic, possible link configuration alternatives and possibilities for flexible
capacity sharing between class A/B and class C connections.
Determine also the link capacity requirements and configuration parameters for
other ATM VCCs (signaling, O&M, and node synchronization).
The R99+HS dimensioning case we should add the O&M capacity demand to the
total needed link capacity for one RBS. Reason to this is to give a margin for
O&M and Iub signaling (NBAP Common, NBAP Dedicated and Q.2630) when
HS traffic is added.
See configuration selection recommendations in section 3.4.
3.1.7 Step 6: Determine the HSDPA Flow Control parameter

There is a parameter for flow control on each HSDPA RBS that has to be
configured. This parameter must be determined during dimensioning of HSDPA
link.
See HSDPA flow control dimensioning in section 3.5.
3.2 Calculation Method for Step 2
3.2.1 Input
The dimensioning of AAL2 resources for AAL2 class C starts with gathering input
data. See section 2.2.1.
3.2.2 Output
The dimensioning results of AAL2 resources for AAL2 class C are.
1. Required ATM/AAL2 VC capacity [kbps]
2. Average number of active HSDPA users [Erlang]
3. Number of HSDPA VCs needed
3.2.3 AAL2 path capacity (class C)

This section describes the method used for AAL2 path capacity dimensioning of
HSDPA traffic. For dimensioning we use a special case of “Elastic user model”. In
this special case knowing the “link capacity” and the “Average busy hour traffic”
the Session average user data throughput experienced by a user can be calculated
by subtracting the “Average busy hour traffic” from “link capacity”.
The equations in this chapter describe how to dimension the AAL2 path capacity
for class C.
First the “Average busy hour traffic [kbps] (AvgLoad)” of the path is calculated by
multiplying the number of users by the average load of a user:
AvgLoad  Nusers  BHperHSDPA user (1)
where
AvgLoad Average busy hour traffic [kbps]
Nuser Number of users
BHperHSDPAuser Busy Hour traffic per HSDPA user [kbps/user]
The dimensioning method based on the Elastic user model and consideration of
“Peak user data throughput for single active HSDPA user” will then result in the
following necessary link capacity as the required RLC SDU capacity.
The required capacity for user traffic can be calculated by applying the “HS-
DSCH transport efficiency”, which describes the efficiency of packet data
transmission on Iub interface.
ElasticDim  MAX ( AvgLoad  TargetAvg ; TargetPeak ) (2)
ElasticDim
CRLC _ SDU  (3)
HSDSCHefficency
where
MAX(a;b) Maximum of a or b
ElasticDim Elastic dimensioning result [kbps]
CRLC_SDU Required RLC SDU capacity [kbps], see 2.2.1.
HSDSCHefficency HS-DSCH transport efficiency, see 2.2.1 and 2.7.
AvgLoad Average busy hour traffic [kbps], see 2.2.1.
TargetAvg Target session average user data throughput during
busy hour [kbps], see 3.2.1
TargetPeak Target peak user data throughput for single active
HSDPA user [kbps], see 2.2.1.
Iub AAL2 class C capacity is finally calculated by multiplying with the
ATM/AAL2 overhead for HSDPA:
CIubHSDPAcl assC  OHHSDPA TN  CRLC _ SDU (4)
where
CIubHSDPAclassC Capacity required for HSDPA on AAL2 class C
[kbps]
OHHSDPATN Iub transport protocol overhead for HS-DSCH, see
Appendix A
CRLC_SDU Required RLC SDU capacity [kbps], see 2.2.1.
The average bit rate perceived by user is the difference between the result from
Elastic dimensioning and average load:
ExpAvg  ElasticDim  AvgLoad (5)
where
ExpAvg Expected average bit rate perceived by a user
AvgLoad Average busy hour traffic [kbps], see 2.2.1.
3.2.4 CID occupation

An HSDPA user will use high priority AAL2 class A CID for SRB and low priority
AAL2 class C CID for HS-DSCH and A-DCH.
High priority CID occupation

In this section the number of CIDs used for the following cases
1. Separate AAL2 VC on Class A/B AAL path (CBR)
2. Common class A/B&C path (CBR)
3. Common VP for Class A/B (CBR) and C (UBR)
is calculated.
Number of CIDs used by Rel-99 users:
1. These users use 2 CID (i.e. DCH/RAB + DCCH/SRB)
2. Soft handover for Rel-99 users is included in the offered load of these
users (see calculation method in Reference [1]).
Number of CIDs used by HSDPA user (depending on configuration):
1. Common AAL2 CBR VC for class A/B/C:
The number of CIDs used by HSDPA user is 3+2* f_SHO (i.e. HSDPA
SRB + HS-DSCH + A-DCH)
2. Separate AAL2 CBR VCs for class A/B:
The number of CIDs used by HSDPA user is 1+ f_SHO (i.e. HSDPA SRB)
3. Common VP with separate AAL2 CBR VCs for Class A/B and AAL2
UBR for class C
The number of CIDs used by HSDPA user is 1+ f_SHO (i.e. HSDPA SRB)
The soft handover calculation used for Rel-99 users is not applicable for HSDPA
users, because soft handover is not allowed for HS-DSCH. Soft handover for
HSDPA users is instead modeled by including the soft handover factor in the
channel need of HSDPA users. Soft handover factor affects only A-DCH and
HSDPA SRB in case of HSDPA transmission.
Table 1 Input for K-R dimensioning to calculate number of needed CIDs
DCH HSDPA
CID usage per user 2 +2* f_SHO (1+f_SHO) or
(3+2*f_SHO)1
Offered load [Erlang] Sum of offered load for Average number of active
all DCH traffic classes HSDPA users
GoS Target Minimum of GoS for all GoS target for HSDPA
DCH traffic classes/10 user blocking (because of
CID limitation)
Constant f_SHO is the fraction of users in soft handover (estimated to 44%). The
number of CIDs needed if HSDPA traffic is present can be calculated as:
NclassA/BCID = K-R dimensioning (Table 1) + NCCHCID (6)
Where
NCCHCID number of CIDs used by common channels
The number of necessary class A/B VCs can be calculated as
 NclassA / BCID 
nVCclassA / B  Ceil  (7)
 248 
where
NclassA/BCID Number of class A/B CIDs needed
nVCclassA/B Number of class A/B VCs needed.
248 Number of AAL2 CIDs available for user
connections per AAL2 VC.
Ceil(x) is a function where the result of this function is the
smallest integer which is larger than or equal to x
(e.g. it is a similar to a roundup function).
1 Depending whether common or separate AAL2 VCs are used for class A/B and C. Or common VP with separate AAL2 VCs for
class A/B (CBR) and class C (UBR)
Low priority CIDs on AAL2 class C path

The “Average number of active HSDPA users [Erlang]” can be calculated by
dividing the link capacity by the ExpAvg value. The “MHT/(MHT -
tHSDPA_inactive time)” factor represents the effect of inactivity timer on the
length of class C AAL2 connections.
ElasticDim MHT
AvgN HSDPA Users   (8)
ExpAvg ( MHT  tHSDPA _ inactive)
where
AvgNHSDPAUsers Average number of active HSDPA users [Erlang]
ExpAvg Expected average bit rate perceived by a user
MHT Mean Holding Time [s]
tHSDPA_inactive HSDPA inactivity time [s]
An HSDPA user uses 2 class C AAL2 connections: one for HSDPA and one for A-
DCH. As A-DCH can be in soft handover the soft handover factor (f_SHO) must
be also included in the calculations. The number of class C CIDs needed can be
calculated as follows. Note that if an AAL2 path is shared between Class A/B and
C connections then the calculation method is different and described in section
High priority CID occupation.
The required number of low priority CIDs (i.e. HS-DSCH and A-DCH) on AAL2
class C needed for HSDPA is calculated as
NHSDPA CID  erlangB( AvgNHSDPA Users; GoS )  (2  f _ SHO) (9)
where
NHSDPACID Number of low priority (AAL2 class C) CIDs
needed for HSDPA
ErlangB(traffic; GoS) Calculates the number of devices needed in a loss
system offered Poisson traffic. Traffic is the offered
traffic in Erlang ( > 0). Blocking probability is the
desired probability of blocking. (0 < GoS < 1)
GoS Grade of Service (or blocking probability)
f_SHO Soft handover factor
2 HS-DSCH and A-DCH CIDs on AAL2 class C
The number of necessary class C VCs can be calculated as:
 NHSDPA CID 
nVC HSDPA  Ceil  (10)
 248 
where
NHSDPACID Number of low priority (AAL2 class C) CIDs

needed for HSDPA
nVCHSDPA Number of HSDPA VCs needed.
248 Number of AAL2 CIDs available for user
connections per AAL2 VC.
3.3 Calculation Method for Step 4
3.3.1 General
A dimensioning method for non-HSDPA traffic is described in Ref. [1]. It is
applicable with minor extensions for dimensioning of the transport network
resources for AAL2 connections of QoS classes A and B.
3.3.2 Signaling radio bearers capacity for HSDPA users

The signaling radio bearers for a HS-DSCH user is transported on an AAL2 class
A connection.
The required or approximate required capacity for AAL2 class A/B is calculated
according to Ref. [1]. The required AAL2 class A/B capacity has to be increased
with the capacity for the HSDPA (HS-DSCH) signaling radio bearers. This is
calculated by using equivalent bandwidth for DCCH:
CSRB  AvgNHSDPA Users  (1  f _ SHO)  eqBWSRBUsers (11)
where
CSRB Capacity for Signaling Radio Bearers in down link
eqBWSRB Equivalent bandwidth for DCCH [kbps]; ref [1]
3.3.3 Step 4a: Calculating capacity for COMMON resources

A capacity gain can be achieved because of the effects described in Section 2.4.1
for following cases:
 If QoS separation is used for common CBR AAL2 path for class A and
class B and UBR AAL2 path for class C within the same VP.
a. Then should the priority (PRIO) queuing method be used for
class A and B (class A will have a higher priority than class
B).
b. Otherwise first in first out (FIFO) queuing method be used for
class A and B (both will have same priority and with class A’s
traffic descriptors).
 If common AAL2 path for class A/B and C (CBR) is used. Then should
first out (FIFO) queuing method be used for AAL2 class A and B.
The method for dimensioning this common path is described below.
The average bandwidth used by each class A/B AAL2 connection type is shown in
the following table:
Table 2 Average bandwidth of each AAL2 connection type (excluding AAL2

ATM OH, i.e. 12.8%)
RAB BWave [kbps]

DCCH 1.08
AMR 12.2 8.8
CS64/64 71.6
CS57.6 62.8
PS16/64 71.4
PS16/128 144
PS64/64 75.6
PS64/128 111.9
PS64/384 334.2
PCH 24,8
FACH1 22,4
FACH2 23,6
Knowing BWuse,avg for each class A/B RB type and the CIubHSDPAclassC the necessary
AAL2 path capacity for common AAL2 class A/B and C path can be calculated
using a modified Kaufmann-Roberts Dimensioning formula.
In the modified K-R dimensioning method there will be n+1 traffic classes, where n
is the number of class A/B RB types with offered load defined. The capacity need
of each RB type will be the BWuse,avg, while the load is derived form traffic profile
and GoS of these RB remain as the same as for Rel-99 dimensioning. The extra
class will represent the class C capacity need. Its capacity need will be
CIubHSDPAclassC, its load is 0 and its GoS requirement will be equal to “PS bandwidth
availability”. The modification to the KR dimensioning algorithm is that it
considers GoS of the last (class C) traffic class, in spite of that its load is zero.
This can be formalized as follows:
non  perm
C Iub , common  KR _ DIM ( BW , load , GoSTarget ) (12)
47
BW  ( BWuse, avgRB1; BWuse , avgRB 2;...; BWuse , avgRBn; CIubHSDPAcl assC  )
53
(13)
load  (loadRB1; loadRB 2;...; loadRBn;0)
(14)
GoSTarget  (GoSTargetRB 1; GoSTargetRB 2;.....; GoSTargetRBn ;1  PSBW , ave)
(15)
where
non  perm
C Iub , common
the necessary AAL2 path capacity for non-
permanent flows on common AAL2 class A/B and C
path
BWuse,avg,RBi average bandwidth used by the RB type in [kbps]
(ATM overhead not included)
loadRB1 Offered load of RB type in [Erlang]
GoStarget,RB1 GoS target of RB type I
CIubHSDPAclassC*47/53 the capacity needed for class C traffic [kbps] (ATM
overhead not included)
PSBW,ave this value is the probability that more than
CIubHSDPAclassC*47/53 is available for class C users.
The bandwidth need of the permanent flows must be added to the value of the
above calculation. The permanent sources are the common channels. The capacity
needed for the DCCH/SRB of the HSDPA users is also calculated here.
Nperm
CIubperm,common  AvgNHSDPAUsers  (1 fSHO )  BWuseSRB,avg   Ni BWusei ,avg (16)
i1
where
perm
C Iub ,common The necessary AAL2 path capacity for permanent
flows on common AAL2 class A/B and C path
BWuseSRB,avg average bandwidth used by the SRB
Nperm number of different permanent flow types
Ni number of flows from permanent flow type

i
i
BWuse , avg average
bandwidth used by permanent flow type i
The bandwidth need of the common VC can be calculated as follows:
 perm perm
CIub,common  MAX(CIubnon,common  CIub,common;CIub,R99) (17)
where
C Iub, common the necessary AAL2 path capacity of common
AAL2 class A/B and C path
non  perm
C Iub , common the necessary AAL2 path capacity for non-
permanent flows on common AAL2 class A/B and C
path
perm
C Iub ,common the necessary AAL2 path capacity for permanent
flows on common AAL2 class A/B and C path
C Iub , R 99 the required AAL2 path
capacity resulting from dimensioning for Release 99
flows only (includes CSRB)
3.3.4 Step 4b: Calculating capacity for SEPARATE resources

In this case no capacity gain can be achieved between HS and Rel-99. Rel-99
traffic is calculated by Kaufman-Roberts method. The HS traffic is calculated
according to Section 3.2.3
The total AAL2 needed capacity is:
CTotal _ AAL2  CAAL2 _ class _ A / B  CIubHSDPAclassC (18)
where:
CTotal_AAL2 total AAL2 needed capacity for Iub
CAAL2_class_A/B Needed capacity for Rel-99 traffic on class A/B
CIubHSDPAclassC Needed capacity for HS traffic on class C
3.4 Calculation Method Step 5
3.4.1 Determine link configuration case
1. The AAL2 traffic can be handled within a single VPC

1.1 One or more fixed capacity AAL2 paths for class A/B combined with one or
more flexible capacity AAL2 (UBR) paths for class C.
1.2 The AAL2 traffic can be handled within a single AAL2 path for class A, B and
C.
1.3 Different fixed capacity AAL2 paths for class A/B and for class C.
1.4 One or more fixed capacity AAL2 paths (CBR) for class A combined with one
or more flexible capacity AAL2 (UBR) paths for class B and class C.
2. The AAL2 traffic has to be distributed over multiple VPCs for capacity
reasons and lack of IMA
Single fixed capacity AAL2 path for either class A/B or for class C within each
VPC. The HSDPA must be dimension for separate VPCs. When several VPCs
are needed for configuration reasons e.g. using old hardware, which does not
support IMA following method, has to be used.
2.1 DCH path must be dimensioned as described in Ref [1].
2.2 HSDPA path has to be dimensioned by dividing the load evenly between
several paths.
2.3 Having more than one pipe for HSDPA traffic should be avoided if possible
(see details in section 2.7). The number of needed paths can be calculated and
determined by using following algorithm:
Input:
Maximum offered VPC capacity (CVPC,max)
Algorithm:
nVPCs=1 (the number of VPCs needed)
SEARCH
Dimension one VPC by dividing the total number of users by nVPCs
If the resulting required capacity is smaller than CVPC,max then the required
number of VPCs is nVPCs.
Otherwise increase nVPCs by one.
Go to SEARCH
3. The AAL2 traffic has to be distributed over two separate VPCs for
redundancy reasons
Having more than one pipe for HSDPA traffic should be avoided if possible.
However, if redundancy is introduced between the RNC and an aggregation
point, then the performance degradation because of having two pipes is

probably smaller, because these pipes has higher capacity (see details in
section 2.7).
3.1 One or more fixed capacity AAL2 paths for class A/B combined with one or
more flexible capacity AAL2 (UBR) paths for class C within each of two
VPCs
3.2 Single fixed capacity AAL2 path for class A, B and C within each of two
VPCs
3.3 Different fixed capacity AAL2 paths for class A/B and for class C within
each of two VPCs (typically between RNC and RXI)
3.4.2 Final dimensioning

For the selected configuration case, determine the number of AAL2 paths of each
type, indicating the AAL2 QoS classes allowed and the required peak cell rate per
AAL2 path.
3.5 Calculation Method step 6

HSDPA flow control must be configured in all RBSes, which should support
HSDPA services. The name of the attribute, which must be set, is MaxHSRate. The
bottleneck for AAL2 path(s) potentially carrying class C flows from a given RBS
must be taken into account when determining the MaxHSRate of an RBS.
In case of an End RBS the AAL2 path(s), which can carry class C traffic
contribute to the maxHSRate. The bottleneck is assumed to be the first hop towards
the RNC, the class C AAL2 VC capacities on this link determine the maxHSRate.
In case of a hub RBS the determination maxHSRate depends on the type of
switching used in the hub RBS.
1. If VC Cross Connect is used then only the Class C AAL2 paths (VCs)
having endpoint in the hub RBS contribute to the maxHSRate of the hub
RBS, because only these can carry the class C traffic of this RBS.
2. If AAL2 switching is used then all Class C AAL2 VCs going from this
RBS to the RNC contribute to the maxHSRate, because all AAL2 VCs can
carry the class C traffic of this RBS.
The method to determine MaxHSRate is described in Table 3.
Table 3 Value of MaxHSRate
Configuration Value of MaxHSRate

One path dedicated to HS (CBR) Capacity of that path multiplied with
HSRateCorrectionFator
One common path for HSDPA and Capacity of that path multiplied with
class A/B (CBR) HSRateCorrectionFator
Several paths (VCCs or VPCs), each Sum of the capacity of all HSDPA
dedicated to HS dedicated paths (VCCs or VPCs)
multiplied with HSRateCorrectionFator
Common VP for separated Rel-99 Capacity of that VP multiplied with

(class A/B on CBR) and HSDPA (class HSRateCorrectionFator
C on UBR)
Common VP for separated high Capacity of that VP multiplied with
priority/minimum delay Rel-99 (class A HSRateCorrectionFator
on CBR) together with low priority
Rel-99 (class B on UBR) and HSDPA
(class C on UBR)
MaxHSRate is expressed in kilobits per second. It represents the number of MAC-
d PDU bits per sec and thus includes the RLC overhead, 2 octets per 40 octets user
data. The AAL2 path capacities include all overheads on user traffic on the Iub
interface (HSDPA transport protocol overhead on Iub). Thus the
HSRateCorrectionFator can be calculated as in equation (19)
where we divide all overhead and apply only the MAC and RLC overhead.
1
HSRateCorrectionFator 
OH HSDPA TN
 42
40 (19)
where
42/40 is the RLC protocol overhead
OHHSDPATN Iub transport protocol overhead factor for HS-
DSCH, see chapter “HS-DSCH transport overhead on
Iub” in Appendix A.
3.6 HUB Iub link dimensioning

Hub -RBS or –RXI can be configured as an ordinary ATM VP cross connect node
or an AAL2 switched node. In the case of AAL2 switching all AAL2 classes (Class
A, B and C) will be AAL2 switched.
3.6.1 AAL2 Switching node

Using AAL2 switching it is possible to utilize multiplexing of flows, thus
bandwidth gains on the concentrated link can be achieved compared to ATM Cross
Connects. Thus it is recommended to use AAL2 switching if possible. An Iub link
to an AAL2 switching node is dimensioned as an End RBS link as described in
section 3.1. The total load of all RBSes connected to this concentration point must
be considered as input for this dimensioning.
3.6.2 Cross Connect node

Before dimensioning an Iub link to a cross connect node all connected End RBS
Iub links must be dimensioned. The link capacity of the Iub link to a cross connect
node will be the sum of the capacity of all connected End RBS Iub links. In this
case it is not possible to utilize multiplexing gains.
4 Examples
In this chapter different dimensioning examples are presented, based upon the
classification listed in section 3.1.3.
4.1 Separate resources - with IMA

This corresponds to bullet 1 in section 3.1.3: separate CBR VCs for AAL2 class
A/B and class C within the same VP will be dimensioned.
4.1.1 Step 1: Collection of data

The RBS has 3 cells and have 500 subscribers.
The busy hour traffic for Rel-99 is:
 16.1 mE AMR 12.2 kbps,
 1.4mE CS64/64,
 3.7 mE PS64/64,
 2.8 mE PS64/128,
 0.7 mE PS64/384
 0.5 mE PS 16/64.
Soft handover is assumed to be 44%.
The busy hour traffic for HSDPA is:
 1 kbps/user is the average busy hour load,
 400 kbps is the target average bit rate,
 1100 kbps is the target peak bit rate for single user.
We assume that common HS and Rel-99 resources cannot be used.

In this step we will calculate all three outputs presented in section 3.2.2, based
upon calculation method presented in § 3.2.3 and § 3.2.4.
1. The required ATM/AAL2 VC capacity can be calculated with equation (4):
According to equation (1) the Average BH Traffic Load is:
AvgLoad = 500  1 = 500 kbps
Equation (2) gives the following Elastic Dimensioning result:
ElasticDim = MAX (500+400; 1100) = 1100 kbps

The required RLC capacity is estimated according to equation (3):
CRLC_SDU = 1100/0.8 = 1375 kbps
Applying equation (4) we can finally obtain:
CIubHSDPAclassC = 1.33  1375 = 1828.8 kbps
2. The average number of active HSDPA users can be evaluated using
equation (8):
The average bit rate perceived by an user is calculated using equation (5):
ExpAvg = 1100 – 500 = 600 kbps
AvgNHSDPAUsers = 1100/600  [19/(19-10)] = 3.87 Erlang
3. The number of HSDPA VCs needed is calculated according to equation
(10):
The number of needed CIDs for HSDPA is evaluated using equation (9):
NHSDPACID = 25
nVCHSDPA = 1

Since common AAL2 VC for class A/B and C is not used we go to step 4b.
4.1.4 Step 4b: Calculate capacity for separated resources

Based upon equation (11) we can determine the capacity need of HSDPA Signaling
Radio Bearer:
CSRB = 3.87  (1+0.44)  1.3 = 7.2 kbps
The capacity need for R99 DCH RABs can be evaluated according to the
dimensioning method described in [1], using the Excel implementation of the
Kaufman –Roberts algorithm [5]:
Dimensioning
Check blocking for all classes FALSE
Rates of services [kbps] 13,7 72,5 72,3 76,8 150,2 445,9
Load [Erlang] 11,592 1,008 0,3636 2,6906 2,0362 0,50904
Target Blocking Probability 0,30% 0,30% 0,70% 0,70% 0,70% 0,70%
Resulting blocking probaility 0,007% 0,045% 0,044% 0,048% 0,111% 0,700%
Capacity needed [kbps] 2673,9
Dimensioning
The K-R algorithm result is the needed AAL2 bandwidth and therefore we should
add the AAL2/ATM Overhead and the Common Channels capacity need [1]:
CIub, R99 = [7.2 + 2673.9 + 356.4]  53/47 = 3425.3 kbps
The number of needed High priority CIDs is calculated according to formula (6)
and Table 1:
Dimensioning
Rates of services [kbps] 2,88 1,44
Load [Erlang] 12,6 3,87
Target Blocking Probability 0,03% 0,70%
Resulting blocking probaility 0,027% 0,013%
NclassABCID = 84.4 + 3  4 = 96.4
Therefore two AAL2 VCs, one dedicated to Rel-99 RBs, another one dedicated to
HSDPA RBs are needed.
The capacity of Rel-99 VC is 3425.3 kbps while the capacity of the HSDPA VC is
1828.8 kbps: the total AAL2 capacity need is 5254.1 kbps.

AAL2 capacity = 5254.1 kbps
AAL5 capacity (NBAP-C/D and Q.2630) = 400 kbps (see Ref [1]).
AAL0 capacity (sync)= 4 kbps (see Ref [1]).
Since IMA is used then the overhead of 2.8% must be included; the total link
capacity is: 5816.5 kbps
The number of needed E1s is: 5816.5/1920 = 3.03; therefore 3 E1s are needed.
4.1.6 Step 6: Determine the HSDPA flow control parameter

One VCC path is dedicated to HSDPA thus the MaxHSRate can be calculated as
Capacity of that HSDPA VCC including Iub transport protocol overhead.
MaxHSRate=1828.8/1.33  42/40=1443.8 kbps
4.2 Common resources - with IMA

This corresponds to bullet 2.1. in section 3.1.3: a common CBR VC for AAL2
class A/B and class C will be dimensioned.
4.2.1 Step 1 Collection of data

 16.1 mE AMR 12.2 kbps,
 1.4mE CS64/64,
 3.7 mE PS64/64,
 2.8 mE PS64/128,
 0.7 mE PS64/384
 0.5 mE PS 16/64.
We assume that common AAL2 CBR VC can be used.
QoS separation is used between Rel-99 and HS.

The results of this step are the same of the corresponding step of the previous
example (see section 4.1.2):
1. CIubHSDPAclassC = 1.33  1375 = 1828.8 kbps
2. AvgNHSDPAUsers = 1100/600  [19/(19-10)] = 3.87 Erlang
3. nVCHSDPA = 1

Since common AAL2 VC for class A/B and C is used we go to step 4a.
4.2.4 Step 4a: Calculate capacity for common resources

Radio Bearer:
CSRB = 3.87  (1+0.44)  1,3 = 7.2 kbps
The capacity need of the common AAL2 path is the maximum between the R99
RABs capacity need (increased by CSRB) and the common capacity need of HS &
R99 RABs (see equation (17)).
 The R99 RABs capacity need can be evaluated according to the
dimensioning method described in [1], whose result is the same as the one
we have calculated in the previous example (see section 4.1.4); therefore:
CIub, R99 = [7.2 + 2673.9 + 356.4]  53/47 = 3425.3 kbps
 The capacity need of permanent flows is calculated according to equation
(16):
perm
C Iub , common = [3.87 1.44 1.08+3 (24.8+22.4+23.6)] = 218.4
 The capacity need of non permanent flows is calculated according to

equation (12), using the Excel implementation of the modified version of
the Kaufman-Roberts algorithm [5]:
Dimensioning
Check blocking for all classes TRUE
Rates of services [kbps] 8,8 62,8 71,4 75,6 111,9 334,2 1621,722
Load [Erlang] 11,592 1,008 0,3636 2,69064 2,03616 0,50904 0
Target Blocking Probability 0,30% 0,30% 0,70% 0,70% 0,70% 0,70% 10,00%
Resulting blocking probaility 0,000% 0,000% 0,000% 0,000% 0,001% 0,006% 10,000%
Dimensioning
non _ perm
C Iub ,common = 2847.9 kbps
The resulting AAL2 capacity need is therefore the maximum between CIub, R99 and (
perm non _ perm
C Iub , common + C Iub ,common )  53/47 = 3457.8, that is 3457.8 kbps (equation
(17)).
The number of needed VCs can be calculated according to equation (7):
 The number of High priority CIDs is calculated according to formula (6)
and Table 1:
Dimensioning
NclassA/BCID = 100.8 + 3  4 = 112.8
One single AAL2 path can therefore be configured.


One common path is used for HSDPA and class A/B thus the MaxHSRate can be
calculated as Capacity of that common VCC including Iub transport protocol
overhead.
MaxHSRate = 3457.8/1.33  42/40 = 2729.8 kbps
4.3 Common resources - with IMA and UBR

This corresponds to bullet 2.2. in section 3.1.3: a CBR VC for AAL2 class A/B
and an UBR VC for AAL2 class C within same VP will be dimensioned.
The basic difference with the example presented in section 4.2 is the description of
the AAL2 VC carrying HSDPA traffic by means of Service Category UBR: this
implies that step 2, step 3, step 4a and step 5 results are the same

See section 4.2.1.
4.3.2 Step 2: Determine link capacity needed for AAL2 class C

3. nVCHSDPA = 1

Since common AAL2 VC for class A/B and C is not used we go to step 4a.
4.3.4 Step 4a: Calculate capacity for common resources

 CSRB = 3.87  (1+0.44)  1.3 = 7.2 kbps
 The capacity need for R99 DCH RABs is 2673.9 kbps
 CIub, R99 = [7.2 + 2673.9 + 356.4]  53/47 = 3425.3 kbps
 NclassA/BCID = 84.4 + 3  4 = 96.4
perm non _ perm
 C Iub , common + C Iub ,common = 3457.8
Therefore two AAL2 VCs, a CBR VC dedicated to Rel-99 RBs (with capacity
equal to 3457.8), and an UBR VC dedicated to HSDPA RBs are needed.


Since HSDPA VC is described as UBR the MaxHSRate can be calculated as
Capacity of the common VP including Iub transport protocol overhead.
MaxHSRate=3969.9/1.33  42/40=3134.1 kbps
4.4 Separate resources - without IMA

The differences between this example and the one in section 4.1 are:
 the number of subscribers
 lack of IMA (i.e. the maximum achievable VC capacity is 1 E1, 1920kbps)

 16.1 mE AMR 12.2 kbps,
 1.4mE CS64/64,
 3.7 mE PS64/64,
 2.8 mE PS64/128,
 0.7 mE PS64/384
 0.5 mE PS 16/64.
We assume that common HS and Rel-99 resources cannot be used.
4.4.2 Step 2: Determine link capacity needed for AAL2 class C

In this step we will calculate all three outputs presented in section 3.2.2, based
upon calculation method presented in § 3.2.3 and § 3.2.4.
1. The required ATM/AAL2 VC capacity can be calculated with equation (4):
According to equation (1) the Average BH Traffic Load is:
AvgLoad = 1000  1 = 1000 kbps
Equation (2) gives the following Elastic Dimensioning result:
ElasticDim = MAX (1000+400; 1100) = 1400 kbps
The required RLC capacity is estimated according to equation (3):

CRLC_SDU = 1400/0.8 = 1750 kbps
CIubHSDPAclassC = 1.33  1750 = 2327.5 kbps
2. The average number of active HSDPA users can be evaluated using equation
(8):
The average bit rate perceived by an user is calculated using equation (5):
ExpAvg = 1100 – 500 = 400 kbps
AvgNHSDPAUsers = 1400/400  [19/(19-10)] = 7.39 Erlang
3. The number of HSDPA VCs needed is calculated according to equation (10):
The number of needed CIDs for HSDPA is evaluated using equation (9):
NHSDPACID = 37
nVCHSDPA = 1
Since the resulting capacity is higher than the maximum allowed VP capacity
(1920 kbps) then we must dimension the system for separate VPCs according to
the method described in section 3.4.1, bullet 2.3; with nVPCs = 2, 500 users will
be handled by a single VPCs and Step 2 results are the same of previous examples:
3. nVCHSDPA = 1
This time the capacity need is lower than 1920 kbps.

Since common AAL2 VC for class A/B and C is not used we go to step 4b.
4.4.4 Step 4b: Calculate capacity for separated resources

Radio Bearer:
CSRB = 7.39  (1+0.44)  1.3 = 13.8 kbps
The capacity need for R99 DCH RABs can be evaluated according to the
dimensioning method described in [1], using the Excel implementation of the
Kaufman –Roberts algorithm [5]:
Dimensioning
Rates of services [kbps] 13,7 72,5 72,3 76,8 150,2 445,9
Load [Erlang] 23,184 2,016 0,7272 5,3813 4,07232 1,0181
Target Blocking Probability 0,30% 0,30% 0,70% 0,70% 0,70% 0,70%
42(47) Resulting
ERICSSON WIDE INTERNAL blocking probaility
INFORMATION 0,010% 0,057% 0,057% 56-HSD
137/100 0,061% 0,135%
10102/4 0,700%
Rev A 2005-12-05
Dimensioning
The K-R algorithm result is the needed AAL2 bandwidth and therefore we should
add the AAL2/ATM Overhead and the Common Channels capacity need [1]:
CIub, R99 = [13.8 + 4061.7 + 356.4]  53/47 = 4997.7 kbps
This capacity need is higher than 1920 kbps: we should increase the number of
needed VPCs, decreasing the number of users by the same factor1:
nVPCs = 2  500 subscribers

 CSRB = 3.87  (1+0.44)  1.3 = 7.2 kbps
 CIub, R99 = [(7.2/2) + 2673.9 + (356.4/2)]  53/47 = 3220.3 kbps

 CSRB = 2.73  (1+0.44)  1.3 = 5.1 kbps
 CIub, R99 = [(5.1/3) + 1887.6 + (356.4/3)]  53/47 = 2264.5 kbps

 CSRB = 2.38  (1+0.44)  1.3 = 4.5 kbps
 CIub, R99 = [(4.5/4) + 1437.6 + (356.4/4)]  53/47 = 1722.9 kbps
The number of needed High priority CIDs is calculated according to formula (6)
and Table 1:
Dimensioning
NclassABCID =38.1 + 3  4 = 50.1 that can be handled by a single AAL2 path
Therefore 2 AAL2 VCs dedicated to HSDPA RBs and 4 AAL2 VCs dedicated to
Rel-99 RBs are needed.

We also need to allocate the following capacity needs:
 AAL5 capacity (NBAP-C/D and Q.2630) = 400 kbps
 AAL0 capacity (sync)= 4 kbps (see Ref [1]).
Assuming the above VC configuration (1722.9 kbps for R99 traffic) another VCs
(i.e. another E1) would be needed: this can be avoided reallocating R99 AAL2
1 Please note that HSDPA signaling capacity and Common Channels capacity needs should also be decreased by the same factor.
needed capacity in order to fully occupy some of the dimensioned VCs, but keeping
the total capacity need (4  1722.9); this can be done since the unused capacity is
(1920 – 1722.9)  4 = 788.4 that is bigger than 404 kbps.

Two E1s are dedicated to HSDPA thus the MaxHSRate can be calculated as
MaxHSRate=(2  1920)/1.33  42/40= 3031.6 kbps
Note:
It’s worth pointing out that if we had used IMA and still keeping separate resources
(i.e. same situation as the example in section 4.1, but with doubled number of
users) the following results would have been obtained:
 Total link capacity = 7945.6
 Number of needed E1s = 4.14
 MaxHsRate =1837.5
which is very far from the 2+4 E1s solution; it’s also important to underline that
doubling the number of users doesn’t imply doubling the number of needed
transmission resources (3.03 E1s against 4.14 E1s)
4.5 Final Considerations

The following table summarizes the results of the previous examples:
Table 4 Examples summary results
Solution details Needed E1s MaxHsRate

Section # of users
Resources AAL2 VCs VPs IMA R99 HSDPA [kbps]
4.1 500 Separate CBR Common Yes 3 1443,8
4.2 500 Common CBR Common Yes 2 2729,8
4.3 500 Separete CBR & UBR Common Yes 2 3107,8
Separate No 4 2 3031,6
4.4 1000 Separate CBR
Common Yes 4 1837.5
From the above table the importance of using IMA and resource sharing policies is
evident.
5 References
[1] Traffic Calculation Guideline R99, 136/100 56-HSD 10102/4.
[2] Glossary of Terms WCDMA RAN, 2/00322-HSD10102/4
[3] Sándor Rácz, Balázs Péter Gero, Gábor Fodor, “Flow level performance
analysis of a multi-service system supporting elastic and adaptive
services”, Performance Evaluation 49 (2002) pp451-469
[4] Guideline for Best Effort support at Iub for Interactive PS 64/128 and PS
64/384 on DCH, 9/100 56-HSD 101 02/3
[5] “Implementation of Kaufman-Roberts algorithm for UTRAN, EAB/RGT
05:0103 Uen rev D
Kr_revd.zip
Appendix A: HSDPA overhead

HS-DSCH transport overhead on Iub
RLC/ MAC-d PDU overhead
User data segment for RLC PDU payload is 40 octets and RLC Header is 2 octets
will give the sum of 42 octets for MAC-d PDU size. With one byte spare bits and
padding bits will MAC-d PDU size be 43 octets.
RLC PDU payload = 40 octets
RLC Header +2 octets
MAC-d PDU size = 42 octets
Frame Protocol overhead

Frame Protocol payload is n times MAC-d PDU size, where n is the number of
MAC-d PDUs carried in an HS-DSCH data frame. There is a one octet overhead
per MAC-d PDU due to Spare extension and padding. The Frame Protocol header
and CRC will result in 9 octets. The sum of Frame Protocol payload, header and
CRC results the HS-DSCH data frame size. HS-DSCH data frames are carried as
AAL2 SSCS-SDUs.
Frame Protocol payload, n MAC-d PDU n*42 octets
Spare bits & padding (1 octet per MAC-d PDU) n octets
Frame Protocol header + CRC + 9 octets
Frame size or AAL2 SSCS-SDU size =9+n*(42+1) octets
AAL2/ATM overhead
The AAL2 SSCS-SDU is segmented to 45 octets long CPS SDUs and these are
transported in AAL2 CPS PDUs. The AAL2 CPS header is 3 octets long.
The number of AAL2 CPS PDUs =Ceil((9+n*43)/45)
The size of all AAL2 CPS PDUs = Ceil((9+n*43)/45)*3+(9+n*43)
where
AAL2 CPS PDUs are carried in ATM cells. Each ATM cell has a 5 octets ATM
header, a one octet Start Field (STF) and 47 octets remain for carrying AAL2 CPS
PDUs.
ATM size of HSDSCH data frame =the size of all AAL2 CPS PDUs *53/47=
= (Ceil((9+n*43)/45)*3+(9+n*43))*53/47
The total protocol overhead:
The total Iub protocol overhead can be calculated as follows.
Total Iub protocol overhead= ATM size of HSDSCH data frame /(n*40)=
(Ceil((9+n*43)/45)*3+(9+n*43))*53/47 /(n*40)
Examples:
n=1: (Ceil((9+1*43)/45)*3+(9+1*43))*53/47 /(1*40)=
=(2*3+52)*53/47/40=1.64
n=8: (Ceil((9+8*43)/45)*3+(9+8*43))*53/47 /(8*40)=

=(8*3+353)*53/47/320=1.33
1,7
Iub overhead factor
1,6
1,5
1,4
1,3
0 5 10 15 20 25
Number of PDUs per Data Frame
Figure 5 The value of Iub overhead in the function of the number of MAC-d PDUs
per HS-DSCH data frame
When the number of MAC-d PDUs per HS-DSCH data frame (n) is equal or
greater than 27 the Iub overhead factor is equal to 1.3.
In a normal case with 8 MAC-d PDUs per HS-DSCH data frame will result in
33% Iub overhead or Iub overhead factor to be 1.33.

Traffic Calculation Guideline Hsdpa

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Traffic Calculation Guideline Hsdpa

Încărcat de

Drepturi de autor:

Formate disponibile

ERICSSON WCDMA RADIO ACCESS NETWORK

 Ericsson Radio Systems AB 2005

1.1 Background, purpose, overview

2 Assumptions and definitions

 The additional transport network resources needed to carry HSDPA traffic

2.2 Traffic model

2.2.1 Mandatory HSDPA input data

2.3 Transport bearers for HSDPA

2.3.1 Types of transport bearer connections

 Iub transport bearer for HSDPA associated uplink DTCH on DCH

 Iub transport bearer for downlink DTCH on HS-DSCH

2.3.2 Parameters for AAL2 admission control

Iub/Iur transport bearer for DCCH on DCH

Iub transport bearer for downlink “Interactive PS RB on HS-DSCH”

Iub transport bearer for HSDPA associated uplink “Interactive 64 kbps PS

Iur transport bearer for HSDPA associated uplink “Interactive 64 kbps PS

2.4 Transport network topologies

2.4.1 Advantages of resource sharing

 Class A configured on a separate CBR VC, class B configured on a

HS-DSCH traffic (low priority)

DCH connections (high priority)

Figure 1 Class C adaptation to the varying available bandwidth

activity < 100%

Figure 2 The average utilization of PS DCHs is less than 100%

C. To fulfill the strict delay requirements of class A/B connections, the

Figure 3 The buffer server is not busy all the time.

Dimensioned capacity for common VC

Dimensionined capacity for high priority traffic only

Average capacity used by class A/B in busy hour

Figure 4 Dimensioning in a resource-sharing scenario

Guarantee some capacity for HSDPA

 CBR+CBR+UBR case i.e. AAL2 class A on CBR, AAL2 class B on CBR

 CBR+UBR+UBR case i.e. AAL2 class A on CBR, AAL2 class B on UBR

2.5 Dimensioning criteria

 Peak user data throughput for single active HSDPA user

 Session average user data throughput during busy hour

 Grade of Service for HSDPA transport bearers

2.6 Elastic user model used in HSDPA user model

 If there is user in the system then the link is utilized to 100%.

2.7 HS-DSCH transport efficiency

3. The achievable multiplexing gain is reduced, because fewer connections

3.1 The dimensioning steps

Step 4a : Step 4b:

3.1.1 Step 1: Collect input data

Network specific traffic model:

 See needed input data according to Ref. [1].

 Mean Holding Time for typical HSDPA session

 Soft Handover Factor for HSDPA connections

Data per link to be dimensioned:

 Determine the type of physical layer transmission interface to be used (for

Target values for performance measures:

 Peak user data throughput for single active HSDPA user

 Grade of Service for HSDPA transport bearers

3.1.2 Step 2: Determine capacity need for AAL2 class C

See calculation method described in Section 3.2.

3.1.3 Step 3: Determine if common or separate resources are used

2.2. Strict admission for a CBR VC containing AAL2 class A and

3.1.4 Step 4a: Calculate capacity for COMMON resources

3.1.5 Step 4b: Calculate capacity for SEPARATE resources

3.1.6 Step 5: Determine total link capacity and configuration

3.1.7 Step 6: Determine the HSDPA Flow Control parameter

3.2 Calculation Method for Step 2

3.2.3 AAL2 path capacity (class C)

3.2.4 CID occupation

n=8: (Ceil((9+843)/45)3+(9+843))53/47 /(8*40)=