Umts Ran Dimensioning Guidelines

UMTS RAN Dimensioning Guidelines
Ericsson

Ericsson Equipment
Version 1.3
T-Mobile FSC
RAN Engineering and Dimensioning Group
Version 1.3
Grace Jacinto

Ericsson
Document Name: UMTS Dimensioning Guidelines for Ericsson Equipment

Revision History:
Revision History
Version
Date
1.0
06/16/06
1.1
06/27/06
Changes
Add section 6
1.2
09/06/06
Update for P5 SW
Release
1.3
12/23/06
Node B sections, CE
dimensioning
sections, RNC
sections, Ericsson
counters/KPIs
Change Description
First issued full version
Additional: Summary of
Formulas, and Ericsson
counters
Update the BTS/cell capacity
and RNC dimensioning
example based on P5 specs
Update the sections with new
and additional information.
Added new sections.
Done by:
G. Jacinto
G. Jacinto
G. Jacinto
J. Javier
Scope:
This document presents the dimensioning process for Ericsson UMTS Radio Access Network specifically
the Node B Channel Elements, Iub interface and RNC. The dimensioning rules in this document are
intended for establishing a new or overlay UMTS network, considerations on network quality and
performance can be inputted on future versions when considerable amount of traffic and statistics are
already available.
For this version, Ericsson RNC 3810 R5 HW release capacity limitations were used for the dimensioning
exercises.
Purpose:
The purpose of this document is to provide the fundamental knowledge in dimensioning an Ericsson
UMTS Radio Access Network. This intends to support the engineers involved in planning and
dimensioning of UMTS RAN by providing detailed guidelines and computations of network requirements.
Version 1.3
Grace Jacinto

Ericsson
Table of Contents
1.
2.
3.
4.
5.
6.
Introduction.............................................................................................................................5
Node B ....................................................................................................................................6
2.1
Node B Description ..........................................................................................................6
2.2
Node B Capacity ..............................................................................................................8
2.3
Node B Dimensioning .......................................................................................................9
2.3.1 Channel Element Dimensioning .....................................................................................9
2.3.2 Output Power Dimensioning ....................................................................................... 12
Iub Dimensioning ................................................................................................................... 13
3.1
User Plane Bandwidth .................................................................................................... 14
3.2
Signaling Plane Bandwidth .............................................................................................. 15
RNC ...................................................................................................................................... 18
4.1
RNC Hardware Description.............................................................................................. 18
4.2
RNC Capacity ................................................................................................................. 19
4.3
RNC Dimensioning ......................................................................................................... 20
Iu Interface Dimensioning ...................................................................................................... 24
5.1
Iu-CS Interface .............................................................................................................. 24
5.2
Iu-PS Interface .............................................................................................................. 25
Summary of Formulas and Counters........................................................................................ 27
6.1
Channel Element Dimensioning Formulas ........................................................................ 27
6.2
Iub Dimensioning Formulas ............................................................................................ 27
6.3
RNC Dimensioning Formulas ........................................................................................... 27
6.4
Iu Dimensioning Formulas .............................................................................................. 28
6.5
Ericsson Counters .......................................................................................................... 28
Version 1.3
Grace Jacinto

Ericsson
List of Tables
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
1. Ericsson RRU Types

2. Ericsson Node B Specifications
3. Ericsson Baseband Board Capacity
4. CE Requirements per Service
5. Capacity of HS-TX15 board
6. Capacity of HS-TX45 board
7. Channel element dimensioning example
8. Ericsson Iub Virtual Channel Assignments
9. Common Transport Channel Bandwidth Requirements
10. Iub Equivalent Bandwidth of different services
11. Signalling Plane Bandwidth Requirements
12. Iub Dimensioning Example
13. RNC modules and ETB per Subrack Type
14. RNC Architecture and Capacity
15. RNC Module and Subrack Capacity
16. RNC 3810 R5 HW Capacity
17. R5 HW RNC Module and Subracks Capacity
18. RNC 3810 Physical Capacity Limitations
19. RNC Dimensioning example
20. RNC Dimensioning example
21. Ericsson Dimensioning KPIs
22. Ericsson Counters
List of Figures
Figure
Figure
Figure
Figure
Figure
Figure
Figure
1.
2.
3.
4.
5.
6.
7.
Ericsson 3106/3206 Hardware

Ericsson 3418/3518 Hardware
Ericsson Iub Configuration
RNC 3810 Hardware Units
RNC 3810 Subrack Types
Iu-CS Configuration example
Iu-PS Configuration example
Version 1.3
Grace Jacinto

Ericsson
1. Introduction
This document presents the dimensioning guidelines for the Node B channel elements, Iub interface and
the Radio Network Controller for Ericsson equipments. The dimensioning process is the initial phase of
planning where the estimate requirements for network elements count and configuration are calculated
based on the inputted values. The accuracy of the dimensioning output would primarily depends on the
inputs and assumptions used in the process, thus network element counts and configurations based on
the traffic and subscriber forecast might differ with the actual need when the network is in on operating
phase. Nonetheless this document will provide the necessary knowledge to dimension the Ericsson UMTS
RAN.
Node B dimensioning should involve not only the channel element capacity, but also the BTS power and
carrier because most of the times the channel element capacity of Node B cannot be maximized due to
power and carrier limitations brought by high UL interference. But this document focuses only with the
channel element capacity, the BTS power and carrier capacity which affects the RF design will be handled
by the RF Planning group.
Section 2 provides the description of the hardware, equipment capacity and dimensioning process for
Ericsson Node B. It is important to understand the hardware units and its functions and how they can
affect the dimensioning process. The capacity tables included in this section are taken from Ericsson
documents and roadmaps, and are used on the Node B dimensioning guidelines which include the
required inputs and assumptions, dimensioning process and a sample calculation. Some of the
assumptions and considerations can vary depending on the network performance and future service
requirements.
Section 3 is concerned with the Iub interface dimensioning; this illustrates a detailed calculation of the
user plane and control plane bandwidths and the allocation of VCs needed in Ericsson Iub.
Section 4 provides the description of the hardware, equipment capacity and dimensioning process for
Ericsson RNC. The different RNC configuration and corresponding capacity limits are included in this
section. The dimensioning section provides details on the limiting metrics in Ericsson RNC, the
throughput, BTS and cell count and TCPP. Other factors that might limit the RNC capacity such as the
interfaces and VP in traffic shaping feature were also included in the dimensioning exercise.
Section 5 discussed the dimensioning process for Iu interfaces, IuCS which is the RNC to circuit switched
core connection and IuPS for the RNC to packet switched core interface. This section also provides VC
allocations and contents of user plane and control plane VCs.
Finally, Section 6 summarizes all the formulas used in the calculations in this document and also provides
the description of Ericsson KPIs and counters.
Version 1.3
Grace Jacinto

Ericsson
2. Node B
This section provides the hardware description, capacity limits and dimensioning process for Ericsson
Node Bs.
2.1 Node B Description
The Node B implements the WCDMA radio path and performs layer 1 functions such as channel coding,
interleaving, rate adaptation and spreading. There is a wide selection of Ericsson Node B in terms of
application, processing capacity and power output.
One distinct characteristic of Ericsson Node B is its efficient and flexible baseband capacity. There are
separate functional units to handle the uplink and the downlink baseband processing. And the control
channels, softer handover and HSDPA were already provisioned that it does not require dedicated
allocations in the baseband capacity.
Two types of node B are currently planned to be deployed for Ericsson RBS3106 (outdoor
version)/RB3206 (indoor version) and the RBS 3418 (cabinet version 19 inch rack)/3518.
Ericsson 3106/3206
Fan Unit
Filter Units
Radio Units
Baseband and
Interface Units
Power Supply Unit
Figure 1. Ericsson 3106/3206 Hardware

Version 1.3
Grace Jacinto

Ericsson
Baseband Units - the baseband units include the RAX and TX boards for the UL and DL baseband
processing. Each board is consists of Channel Elements which are the baseband capacity required to
process voice or data services. Ericssons Channel element is flexible and efficient, the UL and DL
resources are provided on separate boards and pooled to all the sectors in the Node B. Also, it does not
require additional resources for control channels and other features such as HSDPA. However, when
HSDPA is activated on the cell, the full capacity of the baseband boards cannot be fully utilized by R99
traffic.
RAX boards used in the Node B receive or uplink data from the UE. It has the following functions:
deserializing, demodulating and decoding. The incoming data is shared by all RAX boards in the baseband
pool.
TX boards process the downlink data from the Node B to the users. It involves the functions such as
cell splitting combining, encoding, channel handling, modulation and spreading.
Filter Unit - it filters the transmit and receive signal to and from the radio unit, and amplifies and controls
the received signal gain from the antenna to the radio. It is comprises of RF filters, Low Noise amplifiers
and splitters.
Radio Unit receives data from the baseband units and converts the data into analog signal, amplifies
and feed it to the Filter Unit. It also receives radio signals from the Filter Unit and process and sends it
back to the baseband. One radio unit can support one or more sector carriers.
Interface Boards also known as Radio Unit Interface (RUIF) connects the baseband subrack to the radio
subrack.
There are other important Node B units such as the Control and Switching Unit, the Power supply, Fan
units and other optional devices attached to the Node B for additional functionality. But basically, the
Node B is being configured based on its baseband, filter and radio units.
Ericsson RBS3106/3206 is high capacity base stations. It can handle up to 6 sectors in one cabinet, max
of 4 carriers per sector, up to 1536 channel elements, support for radio remote units, 4-way RX diversity
and 2-way TX diversity, and multiple support voltage options.
Ericsson 3418/3518
Main Unit
Remote Radio Unit

Figure 2. Ericsson 3418/3518 Hardware
Ericsson RBS 3518/3418 has similar architecture to the other RBS3000 family but it has lower baseband
capacity and can support less carrier configuration. It however is more compact and allows main-remote
concept. It has two units: the main unit and remote radio unit (RRU).
Main Unit contains all the Node B parts except the Radio unit. It is consists of the Baseband units: TX
and RAX boards, Power Distribution unit, Fan Unit, Control Base Unit and Exchange Terminal boards.
Version 1.3
Grace Jacinto

Ericsson
Remote Radio Unit radio unit designed to be located near the antenna. It is connected to the main unit
using an optical fiber cable called the Optical Interface Link. It does not support TMAs as the RRU is
typically mounted near the antenna which minimizes the cable loss and negates the requirement for the
TMAs. The main unit can support both star and cascading connection of the RRUs. Two cascading chains
can support up to 3 RRUs in each chain.
RRU Types
RRU 22 (40 W)
Supported Frequencies
Number of Carriers
1700/2100 MHz
1/2
Table 1. Ericsson RRU Specs
Output Power per Carrier

40 W / 20 W
Ericsson RU (Radio Unit) and FU (Filter Unit) is the radio component of their Node B. It is collectively
called as radio block. RRU22 2IV40 supports 2 or 1 carrier and has maximum output power of 40 watts
for 1 carrier and 20 watts for 2 carriers. To determine the capacity requirement of the sector, average
radio link per user, number of users, services provided, maximum output power of the node B and the
output power allocated to the common channel needs to be taken account.
Both RBS is capable to supported 6x1 with 40 watts per carrier or 3x2 with 20 watts per carrier. Initial
launch configuration is 1carrier per sector.
2.2 Node B Capacity
The Node B capacity is dictated by the RF and baseband capability. RF capacity includes the output
power and the number of carriers that it can support. The baseband capacity mainly involves the Channel
elements capacity and also the number of transmission interfaces needed to pass the user data to other
network elements.
Node B Type
RBS 3106/3206
RBS 3418/3518
Maximum
Max UL CE
Max DL CE
Output
Carriers
Power
12
1536
1536
20/40 W
6
512
768
20/40 W
Table 2. Ericsson Node B Specifications
Interfaces
40 T1/16 STM1
12 T1/2 STM1
The RF unit of Ericsson Node B can carry more than 1 carrier. Each cell can have from 1 to 4 carriers,
which translates to 1 to 2 RF units. For example, RBS 3x06 which can support up to 12 carriers can have
3x4 (3 sectors with 4 carriers each), 6x2 or 12x1 configurations.
Ericsson Node B has separate baseband units for uplink and downlink. The RAX board is used for UL and
TX board is used for DL. This provides flexibility in allocating the resources for different applications. For
the macro Node B, 1536 CEs are available for UL and DL, which corresponds to 12 RAX-R2 and 4 HSTX45 boards. With R5 HW, each RAX2 and TX45 has 128 and 384 channel elements respectively. Also,
Ericssons baseband unit does not need additional resources for control channels, softer handover and
HSDPA, which allows it to have more user traffic capacity as compared to other vendors Node B.
The output power of each Node B carrier is based on the power amplifier type which typically comes with
20W and 40W units. The power amplifiers can be connected in parallel to further increase the output
power per carrier when needed for coverage and capacity improvements. But note that high powered
Node Bs does not guarantee a bigger coverage because the interference usually limits both the coverage
and capacity of UMTS networks.
Another factor that dictates the capacity of Node B is the number of available transmission interfaces.
Although during the initial phase of UMTS deployment, a T1 connection would typically be enough but as
Version 1.3
Grace Jacinto

Ericsson
traffic arises additional links will be needed to support the Iub throughput requirements. For Ericsson RBS
3000 family the maximum number of interfaces is 40 E1/T1s or 16 STM-1.
If any of these four factors meet its maximum capacity limits, a new Node B or traffic off-loading to
adjacent Node Bs is required to support the UMTS traffic.
The following tables show the CE capacity of different baseband boards of RBS 3418/3518 and RBS
3106/3206.
RBSType
3418/3518
3106/3006
Hardware
DL Baseband
(HS-TX15)
DL Baseband(HSTX45)
UL Baseband
(RAX R2)
DL Baseband
(HS-TX15)
DL Baseband(HSTX45)
UL Baseband
(RAX R2)
Max No
of Units
Max CE per
Unit
Max CE
per BTS
CE
Step
HS-Codes
Supported
Max HS
Users/cellcarrier
128
256
16
5,15
32
384
768
16
5,15
32
128
640
16
128
512
16
5,15
32
384
1536
16
5,15
12
128
1536
16
Modulation
Supported
QPSK,
16QAM
QPSK,
16QAM
32
-
QPSK
Yes
Node B needs to be dimensioned based on output power and carrier configuration (RRU), carriers and
channel elements (baseband units) which will be discussed in detail in the following subsections.
Channel Element Dimensioning
Channel Element is the the processing capacity for the Node B. It is used to determine the amount of
processing to support different services and signaling requirements. Minimum allocation per service is 1
CE in DL and 1 CE in UL. HSDPA requires static CE and cannot be allocated for R99.
Channel element is the required baseband processing capacity for speech or data connection. With
Ericssons implementation, the UL and DL channel element requirements are provisioned on separate
boards, the RAX and TX boards. The RAX board is used for UL baseband processing and handles
functions such as CRC handling, channel coding, spreading, interleaving and rate matching. The TX
board, on the other hand, is for the DL baseband processing and handles functions like demodulation,
rake receiving, despreading, decoding and CRC evaluation. The table below shows the required CEs for
the RAX and TX boards for different services.
SF
256
128
64
32
Version 1.3
Grace Jacinto
CE
required
1
1
1
2
Uplink
Service (Example)
SF
AMR4.75, AMR 5.9

AMR7.95, AMR12.2
PS32
CS57, CS64, CS64+PS8
128
64
32
16
CE
required
1
1
2
4
No
Yes
2.3 Node B Dimensioning
Downlink
No
QPSK
QPSK,
16QAM
QPSK,
16QAM
Table 3. Ericsson Baseband Board Capacity
2.3.1
HSUPA
Support
Service (Example)
AMR4.75
AMR7.95, AMR 12.2
CS32, PS64, PS16+PS8
CS57, CS64, CS64+PS8
9
No
No

Ericsson
PS64, AMR12.2+PS64
PS64+PS8
16
8
4
8
PS128, PS128+PS8
8
8
PS384
4
16
Table 4. CE Requirements per Service
PS64, AMR12.2+PS64
PS128
PS384
Ericsson has separate boards for transmit and receive which allows separate transmit and receive
dimensioning. Transmit baseband board has two types HS-TX15 which has a maximum of 128 CEs and
HS-TX45 which has maximum of 384 CEs. Fragmented channel element allocation on a service is not
allowed e.g. DL 384 requiring 8 CEs has to be allocated to the same baseband board. A high capacity
baseband board then will be more efficient than a lower capacity baseband board. For the receive
baseband board, TMO is using only one type of receive baseband board that is RAXR2 which has
maximum of 128 CEs.
Initial configuration is assuming that only high capacity sites (GSM sites with more than 12 TRUs) will use
HS-TX45.
Ericsson channel elements are dimensioned separately for UL and DL but have the same calculation.
Channel element dimensioning (UL or DL) is the sum of the all the services multiplied with the CE
requirement per service. Common channel and softer handover does not need to be considered.
With mixed R99 and HSDPA configuration, the HS-TX15 and HS-TX45 boards will follow the
characteristics shown in Table 5 and 6 respectively.
Max CE for R99 DCH
128
64
64
64
64
0
Max HSDPA users per cell

HSDPA capacity
16
5 HS codes for 1 cell carrier
32
15 HS codes for 1 cell carrier
16
5 HS codes per cell carrier
16
15 HS codes shared by 1-3 cell
32
Table 5. Capacity of HS-TX15 board
Max CE for R99 DCH

384
256
256
256
64
0
Max HSDPA users per cell

HSDPA capacity
16
5 HS codes per cell carrier
16
32
16
15 codes per cell carrier
32
15 codes per cell carrier
Table 6. Capacity of HS-TX45 board
HSDPA DL CE is static but the A-DCH for HSDPA in the UL needs to add to the UL CE dimensioning
calculation. For a 15 codes HSDPA allocation, the CE allocated or assigned depends on the number of
codes, the configuration and the number of users required. At a minimum, half of the CEs available in a
transmitter card need to be statically allocated for HSDPA. The number of users that can be supported
by HSDPA is the same number of users that can be supported for Enhanced uplink.
For the initial launch, 15 codes are allocated with 16 users. HS-TX15 requires 64 CE allocations while HSTX45 requires 192 CEs. To support 32 users, HS-TX15 still requires only 64 CEs while HS-TX45 requires
additional 64 CEs to be allocated for HSDPA.
Version 1.3
Grace Jacinto
10

Ericsson
Inputs Required:
- number of subscribers per Node B and
- Traffic usage per subscriber per application: AMR, CS64, PS64, PS128, PS384, PS512 UL/DL
Or
- Traffic usage per application
Assumptions:
- Soft Handover Overhead (SHO) = 30%
Dimensioning Process:
1. Compute separately for UL and DL CE R99 Requirements.
- Determine the total traffic per application per Node B.
- Based on Table 4, compute the number of CEs required per application.
2. Compute for the CEs required for HSDPA
- For UL, compute the CEs needed by A-DCH based on HSDPA bearer rate for UL.
- For DL, refer to Table 5 or 6 for the CEs that would be allocated for R99 and HSDPA for mixed
configuration.
Note that with CEs for HSDPA are statically reserved in DL, while the corresponding UL channel (UL
A-DCH) needed for HSDPA transactions are computed similarly to R99_CE. For DL, the capacity of the
TX board will not be fully used by R99 traffic, the allocation of CEs for R99 and HSDPA is shown in
Table 5 and 6.
3. Compute for the Soft Handover CE Requirement (SHO_CE)
- For UL, add the required CEs for R99 and A-DCH and multiply with SHO percentage.
- For DL, multiply the R99 CE requirements with SHO percentage.
5. Sum up the CEs required for R99, A-DCH and Soft Handover to get the total required CEs for UL and
DL.
CEs_DL_Required = (CE_service * Users) * (1+SHO) + CE_HSDPA

CEs_UL_Required = (CE_service * Users + CE_ADCH) * (1+SHO)
Where:
CE_Service*Users = Number of CEs required for each service*Number of users for each service
SHO = soft handover factor
CE_HSDPA = number of HSDPA CE. Note: HS-TX15 requires 64 CEs, HS-45 requires 192 CEs for 15 codes.
CE_A-DCH = number of CE for A-DCH
6. Compute for the number of RAX and TX boards by dividing the required CEs by the CE capacity per
board.
No_ of _TX boards = roundup (CEs_DL_required/Tx_board_CE)

No_ of _RX boards = roundup (CEs_UL_required/Rx_board_CE)
Where:
Tx_board CE and Rx_board CE is the baseband capacity per board based on Table 3
Example:
Node B with 3 sectors, using RAXB and HS-TX45 boards (5 codes per cell carrier)
BH Traffic mix: 12 x AMR, 3 x CS64, 5 x 64/128 PS, 2 x 64/384 PS, 2 x 384/HSPDA
SHO = 30%
-
Compute for the DL and UL CE Requirements
Version 1.3
Grace Jacinto
11

Ericsson
For HS-TX45 board, there are 384 CEs, but with HSDPA of 5 codes per cell carrier, 256 can only
be used for R99.
Number of users
12
3
5
2
2
R99 and ADCH Reqt
SHO Requirements
HSDPA CEs
Total CEs Required
No. of CEs/board
HW Requirements
Services
12.2 kbps AMR
CS 64 kbps
PS 64/128 kbps
PS 64/384 kbps
384 A-DCH HSDPA
UL CE Requirement
12*1 = 12
3*4 = 12
5*4 = 20
2*4 = 8
2*16 = 32
84
84*0.3= 26
110
RAXB = 128 CEs
110/128 = 1
1 RAXB, 1 HS-TX45
Table 7. Channel element dimensioning example
DL CE Requirement
12*1 = 12
3*2 = 6
5*4 = 20
2*8 = 16
54
54*0.3 = 17
128
199
HS-TX45 = 384 CEs
199/384 = 1
For Multi RAB configurations where an MS can have 2 or more simultaneous services, the CEs needed to
support such is still the sum of the CEs for each service. For example, an MS having AMR+ 3 PS64 would
require 1+3*4=15 CEs.
2.3.2
Output Power Dimensioning
Output power is limited resource in UMTS. For Ericsson as mentioned earlier, only one type of PA is
available 40 watts which can used for up to 2 carriers.
The following calculation equation can be used to calculate the DL capacity based on output power:
DL capacity = (Pmax Pcommon Preserved)/ (Plink x SHO)

Where:
Pmax = max power of the Node B power amplifier

Pcomm = power reserved for Common channels
Preserved = power reserved as headroom for in-progress calls
Plink = average power per radio link for each radio bearer type
There is UL or pole capacity calculation but it is depend on the Eb/No which is dependent on the noise. If
a system is UL limited then optimization is required as opposed to hardware change or upgrade.
UL_capacity (pole capacity) = 1 + ((W/R+F)/(Eb/No x V)

Where:
W = system bandwidth
R = user data rate
F = voice activity factor
Eb/No = Eb/No required to meet target BLER for this services
Version 1.3
Grace Jacinto
12

Ericsson
3. Iub Dimensioning
The Iub interface is the ATM connection between the Node B and RNC.
As illustrated in the figure below, the Iub bandwidth is composed of the user plane, node synchronization
and signaling plane: Common NBAP, Dedicated NBAP and ALCAP. The VC recommendation and
assignment for these components can be seen in Table 9, which is based on one virtual path allocation
per Iub interface. When multiple VPs will be used for redundancy or capacity, the VC assignment would
be distributed between the different virtual paths.
O&M
O&M
Figure 3. Ericsson Iub Configuration

1 T1
Ericsson VCs
# of
VCs
QoS
AAL
Multiple T1s
PCR
MCR
kbit/s
cell/s
kbit/s
Sync(Active VC)
CBR
AAL0
Sync(Standby VC)
CBR
AAL0
Mub (O&M)
UBR
AAL5
DNBAP
UBR+
AAL5
424
1000
34
CNBAP
UBR+
AAL5
424
1000
34
ALCAP
UBR+
AAL5
424
1000
34
User Plane
Voice[A]
R99 Data[B]
HSDPA+EUL[C+D]
# of
VCs
1
UBR+
PCR
MCR
kbit/s
cell/s
CBR
CBR
kbit/s
cell/s
UBR
80
UBR+
424
1000
34
80
80
UBR+
424
1000
34
80
80
UBR+
424
1000
34
80
CBR
1174
2770
UBR+
212
500
UBR
AAL2
CBR
QoS
cell/s
3
1174
2770
212
500
Table 8. Ericsson Iub Virtual Channel Assignments

The Iub User Plane is composed of Common and Dedicated Transport Channel data streams that are
transferred between the Node B and RNC containing radio interface user data and associated control
data.
The node synchronization plane provides timing and supervision of traffic frames between the Node B
and RNC for both the uplink and downlink directions. The node synchronization connections are
established with the highest priority class because it contains delay sensitive messages.
The Iub control plane is consists of Node B Application Protocols (NBAP), common and dedicated and
Access Link Control Application Part (ALCAP) or Q.2630. The ALCAP controls the AAL2 paths
The Common NBAP defines the signaling procedure across the common signaling link such as
establishing radio links and various broadcast information and indication messages while the Dedicated
NBAP handles all the signaling after the radio link setup procedure which includes the Radio Link
measurement reports, deletion commands, reconfiguration messages and soft handover related
commands.
Version 1.3
Grace Jacinto
13

Ericsson
The Node B O&M connection, also known as Mub interface, has a separate virtual channel connection on
the same virtual path as the Iub. Aside from the dedicated bandwidth allocated, O&M functions are also
allowed to use any available link capacity that is not currently used, this is to improve the response and
file transfer times.
3.1 User Plane Bandwidth
The user plane traffic can be configured as Constant Bit Rate (CBR) or Undefined Bit Rate (UBR), CBR is
used for Class A and B traffic which includes voice and data while the UBR is used for Class C traffic
which does not require specified QoS and delay such as HSDPA. Class C traffic usually have no reserved
capacity in Iub but it can use the available capacity on the virtual path including the unused bandwidth
for Class A and B traffic, signaling and O&M.
Usually the maximum link capacity allocated for user plane depends on the physical link rates and VP
rates. Typically, the full VP capacity is assigned to user plane traffic after deducting the bandwidth
requirements for signaling and O&M, this allows the traffic to get higher data rates and reduce
transmission delays. In this document, the VP size will be calculated by considering the individual VC
requirements.
For Ericsson, the user plane bandwidth requirement is further divided to the Common Transport Channel
capacity and the Dedicated Transport Channel Capacity. The common channel capacity would depend on
the Node B configuration while the dedicated channel capacity depends on the services. Table 9 shows
the bandwidth requirements for the common transport channels and Table 10 for the assumptions that
will be used in computing the dedicated channel capacity.
Node B configuration
UL BW Requirements
DL BW Requirements
1x1
90.4 kbps
118.8 kbps
3x1
271.2 kbps
356.4 kbps
3x2
542.4 kbps
712.8 kbps
Table 9. Common Transport Channel Bandwidth Requirements
Radio Bearer
UL Bandwidth
DL Bandwidth
AMR 12.2 kbps
14.6 kbps
13.7 kbps
CS 64 kbps Conversational Data
73.5 kbps
72.5 kbps
CS 57.6 kbps Streaming Data
64.3 kbps
63.8 kbps
PS 64/64 Interactive
77.8 kbps
76.8 kbps
77.8 kbps
150.2 kbps
77.8 kbps
445.9 kbps
PS 64/HSDPA
76 kbps
PS 384/HSDPA
439.2 kbps
Table 10. Iub Equivalent Bandwidth of different services
Inputs Required:
- number of subscribers per Node B and
- Traffic usage per subscriber per application: AMR, CS64, PS64, PS128, PS384, PS512
Or
1. Compute for the bandwidth requirement for each service based on the following procedures:
1. Get the traffic in Erlangs for each service.
Version 1.3
Grace Jacinto
14

Ericsson
2. Using Erlang B @ 5% GoS, compute the number of traffic channels.

3. Multiply the number of traffic channels by the Iub equivalent BW and SHO factor
(1+SHO) to get the Iub traffic for each service.
2. Compute for the Dedicated Transport Channel requirements by adding the voice, CS64, PS64, PS128,
PS256, PS384 Iub bandwidth requirements.
3. Using 9, determine the bandwidth required for the Common Transport Channels.
4. The total user plane Iub traffic is then equal to the sum of the Dedicated and Common Transport
Channel Capacity.
3.2 Signaling Plane Bandwidth
There must be a sufficient bandwidth or ATM cell capacity for the signaling links to ensure proper
performance. The bandwidth that must be allocated for the signaling plane is different for each
application part and for different Node B configurations. This should be determined based on the SDU
sizes, protocol profiles and service categories. The table below shows the Ericssons recommended
bandwidth for the signaling plane.
Signalling Bandwidth Requirements (cps)
1x1 Node B config
3x1 Node B config
3x2 Node B config
NBAP-C
40
80
80
NBAP-D
40
80
80
ALCAP
40
80
80
Node synchronization
5
5
5
Table 11. Signalling Plane Bandwidth Requirements
For Node synchronization, 5 cps or 4 kbps per VC should be allocated.
For O&M, a 64 kbps or 150 cps VC is recommended.
Example:
Node B with 3 sectors, 2 RAXB, 1 HS-TX45
SHO = 30%
- Determine the common channel bandwidth requirements:
For 3x1 Node B configuration, Common Channel BW = 271.2 kbps for UL and 356.4 kbps for DL
-
Compute for the dedicated channel bandwidth for UL and DL
For UL:
Iub voice = no. of channels * Iub equivalent BW * (1+SHO)
= 12*14.6*1.30
= 227.76 kbps
Iub CS64 = no. of channels * Iub equivalent BW * (1+SHO)
= 3*73.5*1.30
= 286.65 kbps
Iub PS64/128 = no. of channels * Iub equivalent BW * (1+SHO)
= 5*77.8*1.30
= 505.7 kbps
Version 1.3
Grace Jacinto
15

Ericsson
= 2*77.8*1.30
= 202.28 kbps
Iub 384ADCH = no. of channels * Iub equivalent BW * (1+SHO)
= 2*439.2*1.30
= 1141.92 kbps
UL dedicated channel requirement = Iub voice + Iub CS64 + Iub PS64/128 + Iub PS64/384 + Iub
384ADCH
= 227.76 + 286.65 + 505.7 + 202.28 + 1141.92 kbps
= 2369.81 kbps
For DL:
Iub voice = no. of channels * Iub equivalent BW * (1+SHO)
= 12*13.7*1.30
= 213.72 kbps
Iub CS64 = no. of channels * Iub equivalent BW * (1+SHO)
= 3*72.5*1.30
= 282.75 kbps
= 5*150.2*1.30
= 976.3 kbps
= 2*445.9*1.30
= 1159.34 kbps
DL dedicated channel requirement = Iub voice + Iub CS64 + Iub PS64/128 + Iub PS64/384
= 213.72 + 282.75 + 976.3 + 1159.34
= 2632.11 kbps
-
Compute for the user plane bandwidth requirement by adding the common and dedicated
channel requirements
UL user plane bandwidth = UL common channel + UL dedicated channel

= 271.2 kbps + 2369.81 kbps
= 2641.01 kbps or 6229 cps
DL user plane bandwidth = DL common channel + DL dedicated channel
= 356.4 kbps + 2632.11 kbps
= 2988.51 kbps or 7049 cps
-
Compare the uplink and downlink requirements, the higher value will be used as the user plane
Iub bandwidth requirement.
User Plane Bandwidth = 2988.51 kbps or 7049 cps

-
Compute for the signaling plane bandwidth. Refer to Table 11.
NBAP-C = 80 cps, NBAP-D = 80 cps, ALCAP = 80 cps, node sync = 5 cps

Signalling Plane Bandwidth = NBAP-C + NBAP-D + ALCAP + Node synchronization
= 80 + 80 + 80 + 5
= 245 cps
O&M = 150 cps (recommended per Node B)
-
Compute for the total Iub requirement by adding the user plane, signalling plane and O&M
requirements.
Version 1.3
Grace Jacinto
16

Ericsson
Iub Requirement = User Plane + Signaling Plane + O&M

= 7049 + 245 + 150 cps
= 7444 cps or 3156.26 kbps
Number of users
12
3
5
2
2
Dedicated Ch BW (kbps)
Common Ch BW (kbps)
User Plane Reqt (kbps)
User Plane Reqt (cps)
Iub Requirement UL
227.76 kbps
286.65 kbps
505.70 kbps
202.28 kbps
1141.92 kbps
2369.81 kbps
271.2 kbps
2641.01 kbps
6229 cps
Iub Requirement DL
213.72 kbps
282.75 kbps
976.3 kbps
1159.34 kbps
2632.11 kbps
356.4 kbps
2988.51 kbps
7049 cps
NBAP-C
NBAP-D
ALCAP
Node synchronization
Signaling Plane Reqt
O&M
80 cps
80 cps
80 cps
5 cps
245 cps
150 cps
80 cps
80 cps
80 cps
5 cps
245 cps
150 cps
Iub Reqt (cps)

Iub BW Requirement
6624 cps
7444 cps
7444 cps or 3.16 Mbps or 3 T1s
Table 12. Iub Dimensioning Example
Version 1.3
Grace Jacinto
Services
12.2 kbps AMR
CS 64 kbps
PS 64/128 kbps
PS 64/384 kbps
384 A-DCH HSDPA
17

Ericsson
4. RNC
This section provides the hardware description, capacity limits and dimensioning process for Ericsson
RNC.
4.1 RNC Hardware Description
Ericsson RNC 3810 has a modular architecture consisting of two types of subracks, the Main subrack (MS)
and the Extension subrack (ES). The minimum configuration of the RNC consists of only the Main subrack
and its full configuration has the MS and 5 ES.
The Main Subrack terminates the Iub interface from the Node B, Iur interface towards other RNC and Iu
interface towards the Core network, and duplicates the high speed links to interconnect with all extension
subracks. The Extension subracks only terminate the Iub interface and contain additional interfaces for
the Node Bs.
Extension Subrack
Extension Subrack
Extension Subrack
Extension Subrack
Main Subrack
Extension Subrack
Interface Units
Interface Units
Figure 4. RNC 3810 Hardware Units

Each RNC subrack is composed of smaller, manageable units known as RNC modules. Each RNC module
contains the General Purpose Boards (GPB) and Special Purpose Boards (SPB). Also each subrack has its
own interface connection boards to be used by the Node Bs connected to it. The following are the
different functional units found in the subracks.
GPB - General Purpose Board operates as the main processor and it contains the main part of the RNC
software. It contains ethernet and serial interfaces and disk drives.
SPB - SPB handles the following functionalities: ATM switch core functionality, interfaces for internal node
links and fan control, power filtering and over temperature protection.
Version 1.3
Grace Jacinto
18

Ericsson
SXB handles the interconnection of switch modules at the space switching layer.
TUB provides external clock and GPS input, and generates and stabilizes reference timing signals.
ETB contains hardware modules for AAL2 multiplexing and demultiplexing, and physical and ATM layer
adaptation.
Figure 5. RNC 3810 Subrack Types

The RNC subracks contain ETB hardware modules that provide ATM layer and physical layer connections
towards the Node B and/or Core networks. The ETB for Iu, Iur and O&M connections are placed on the
main subrack, usually 2 ETBs are allocated for this connections, the rest of the ETBs in the MS are used
for RBS connections. The ETBs in the extension cabinet are mainly used for Iub interface connections.
The table below shows the number of RNC modules and ETB in the main and extension subracks.
Main Subrack
Extension Subrack
No. of RNC modules

2
5
Table 13. RNC modules and ETB per Subrack Type
No of ETBs
6
8
4.2 RNC Capacity

Ericsson RNC 3810 has six capacity steps. Its main configuration involves only the main subrack, and as
the capacity increases 5 extension subracks can subsequently be installed. As shown in Figure 4, the full
configuration of RNC 3810 has 1 MS and 5 ES, using the main and extension cabinet. Each subrack
contains smaller manageable units called the RNC modules, which contains the functional units such as
the GPBs and SPBs. The Node Bs to be connected to the RNC will then be homed to a specific RNC
module and subracks. This means that a Node B in a particular subrack will use the functional units in
that subrack including the interface ports. When resources are not enough in that subrack, it cannot use
the available resources in other extension subracks but it can use the main subrack. Thus in computing
the capacity needed to support the traffic and Node B connections, the individual RNC modules and
subracks where the Node Bs will be connected should be considered.
RNC architecture differs based on the number of ES. It starts with RNC Architecture A which has only a
main sub-rack. RNC Architecture B will have 1 MS and 1 ES then C will have 2 ES and so on until F which
has 5 ES and 1 MS with 2 cabinets. Table 14 shows in detail the different architecture and and its
capacity.
Version 1.3
Grace Jacinto
19

Ericsson
Config
# of
cabinets
# of Main
Subrack
Max Cells
supported
TCPP
(Mbps)
A
B
C
D
E
F
1
2
2
2
2
2
1
1
1
1
1
1
384
1344
2304
2304
2304
2304
15
53
90
128
165
203
RNC Release
R5
RNC subunit
# of
Iub
Max Node Bs
Extension
Throughput
supported
Subrack
(Mbps)
0
50
128
1
175
448
2
300
768
3
425
768
4
550
768
5
675
768
Table 14. RNC Architecture and Capacity
IubThroughput
TCPP
Number of
(Mbps)
(Mbps)
BTS
RNC module
25
7.5
64
Main Subrack
50
15
128
Extension Subrack
125
37.5
320
Table 15. RNC Module and Subrack Capacity
Number of
cells
192
384
960
As shown in Table 14 and 15, the RNC 3810 capacity is dictated by the Iub throughput, Traffic Control
Processing Power, and the number of BTS and cells to be connected. There are also other physical
limitations such as the interface ports, VP shapers and AAL2 multiplexers, but this can be solved by
homing strategies. Table 14 shows the capacity for aech RNC3810 configurations while Table 15 provides
the capacity limits for each RNC modules and subrack types.
4.3 RNC Dimensioning
The number of Ericsson RNC to be deployed in the UMTS network depends on the following dimensioning
limits: the Iub throughput, the Traffic Control Processing Capacity (TCPP), the number of Node Bs and
cells to be connected, interface connections, and other physical limits such as number of VP shapers and
AAL2 multiplexers.
The sum of the individual Node B Iub connections must be supported by the RNC throughput. Ericsson
RNC has an extensive user plane capability thus usually the Iub throughput is not the typical limiting
factor for the RNC.
The Traffic Control Processing Capacity (TCPP) is the measure of the control plane capacity in Ericsson
RNC, this represents the control plane bandwidth used to carry the user traffic. TCPP is a fixed parameter
for each RNC module defined by simulations using Ericsson traffic model. The TCPP of the RNC
configuration, considering the individual RNC module and subrack must support the TCPP required to
handle the traffic load. The required TCPP can be calculated using the formula below:
Required TCPP = subs*[1.25*voice + 0.15*CS64 + 1.4(PS64 + 0.66*PS128 + 0.27*PS384 + 0.20*HS)
Mobility coefficient
where: subs number of subscriber
Voice, CS64, PS64, PS128, PS384, HS traffic for each service
Mobility coefficient user mobility based on the active set update rate. Typical value is 1.
For initial network roll-out and low traffic volume, the number of Node Bs and cells usually sets the limits
for RNC. Also, the physical limitations such as the number of interface ports, VP shapers and AAL2
multiplexers can limit the RNC from using its full traffic and radio network capability. Refer to tables
below for the RNC capacity limits for R5 hardware and P5 software.
Version 1.3
Grace Jacinto
20

Ericsson
RNC Configuration
RNC 50
RNC 175
RNC 300
RNC 425
RNC 550
RNC 675
Iub Throughput
TCPP (Mbps)
No. of Node Bs
(Mbps)
50
15
128
175
53
448
300
90
768
425
128
768
550
165
768
675
203
768
Table 16. RNC 3810 R5 HW Capacity
Iub Throughput
(Mbps)
per RNC module

Per Main Subrack
Per Extension Subrack
TCPP (Mbps)
No. of Node Bs
No. of cells
384
1336
2304
2304
2304
2304
No. of cells
25
7.5
64
50
15
128
125
37
320
Table 17. R5 HW RNC Module and Subracks Capacity
192
384
960
For the physical limitations, Table 18 show the interface ports, VP shapers and AAL2 multiplexers capacity
per ETB. As a rule, the Node B connected to a particular RNC module should use the interface ports on
the same subrack, if the ports in the subrack are not sufficient the Main Subrack can be used but not the
Extension subrack.
ETB type
ET-MC1
ET-MC3
ET-M4, ET-M4/22
ET-MC41
Interface ports
VP Shapers
8 E1/T1/J1
16
2 E3/T3
32
2 STM1
48
1 STM1 (63 E1/84 T1)
126
Table 18. RNC 3810 Physical Capacity Limitations
AAL2 multiplexers
16
32
128
126
Inputs
-
Required:
Iub Throughput Requirement
Number of Node Bs and cells to be connected
Number of subscribers per Node B and
Traffic usage per subscriber per application: AMR, CS64, PS64, PS128, PS384, PS512
Or
Assumptions:
- SHO = 30%
- Fill rate = 60-70% for new network, 80-90% for operating network
- Mobility coefficient =1
1. Compute for the RNC throughput requirements, by computing the throughput required by each
Node B considering all the different services, soft handover overhead, and protocol overheads. Or
by considering the Iub throughput for each Node Bs (refer to section 3).
2. Calculate the number of required RNCs based on the Iub throughput.
Number of RNC (throughput) = Iub throughput reqt/(RNC throughput*fill rate)
Version 1.3
Grace Jacinto
21

Ericsson
3. Compute for the required TCPP using formula:

4. Calculate the number of required RNCs based on TCPP.
Number of RNC (TCPP) = Required TCPP/(TCPP capacity*fill rate)
5. Calculate the number of required RNCs based on BTS and cell capacity.
Number of RNC (BTS) = number of connected BTS / (BTS capacity*fill rate)
Number of RNC (cell) = number of cells connected / (cell capacity*fill rate)
6. Compare the computed number of RNCs based on throughput, TCPP and BTS/cell count. The
highest RNC requirement must be considered.
7. The number of available interface ports, VP shapers and AAL2 multiplexers must be enough to
support the connected Node Bs.
Refer to Table 18 for the number of available interface ports, VP shapers and AAL2 multiplexers
in each RNC ETB.
Example:
100 Node Bs, each has the following specs:
SHO = 30%
Assumptions:
RNC with full config will be used
Channelized STM-1 connection from Node B to RNC (1 STM-1 = 63 E1s or 84 T1s)
Mobility coefficient =1
-
Compute for the RNC throughput requirements and the corresponding number of RNCs needed
to support it:
As computed earlier, each node B has an Iub throughput requirement of 3.16 Mbps, thus:
RNC throughput requirement = sum of all Node B Iub Requirements
= 100 * 3.16 Mbps
= 316 Mbps
1 RNC 425 is enough to support the Iub throughput requirement
-
Compute for the required RNC based on TCPP requirement:

Required TCPP (UL) = 1.25*12*12.2 + 0.15*3*64 + 1.4*(7*64 + 0.27*2*384)
1
Required TCPP (UL) = 1129.3 Kbps or 1.13 Mbps
Required TCPP (DL) = 1.25*12*12.2 + 0.15*3*64 + 1.4*(0.66*5*128 +0.27*2*384+ 0.20*2*512)
1
Required TCPP (DL) = 1380.2 Kbps or 1.38 Mbps
Required TCPP = No. of Node Bs * Required TCPP per Node B = 100*1.38 = 138 Mbps
Version 1.3
Grace Jacinto
22

Ericsson
1 RNC 550 (TCPP offered = 165 Mbps) can support the required TCPP.
-
Calculate the number of RNCs required based on number of BTSs and cells.
Number of RNC (BTS/cell) = BTS or cells to be connected / (BTS or cell capacity * fill rate)
= 100/(128*0.9) = 1 RNC 50
= 300/(384*0.9) = 1 RNC 50
1 RNC 50 is enough to support the BTS/cell connections
-
Based on the above computations, 1 RNC 550 is needed to satisfy all the dimensioning
requirements.
Number of required RNC = 1

-
Verify if the number of STM-1 interfaces would be enough to provide connections to Node B,
other RNCs, MSC and SGSN.
Based on Iub computations, 3 T1s per Node B, with 100 Node Bs 300 T1s are needed.
Number of STM-1 connections = sum of STM-1 for Iub, Iur, IuCS and IuPS
Iub = 3 T1s per Node B * 100 Node Bs = 300 T1s/84 = 4 STM-1
Iur = 5%*Iub = 0.05*426 Mbps = 21.3 Mbps
IuCS = 40.4 Mbps (please refer to section 5.1)
IuPS = 242.4 Mbps (please refer to section 5.2)
For
For
For
For
Iub = 4 STM-1
Iur = 21.3 Mbps, 1 STM1
IuCS = 40.4 Mbps, 1 STM1
IuPS = 242.4 Mbps, 3 STM1
Number of STM-1 connections = 9 STM-1 connections per RNC

For RNC 550, 1 MS + 4 ES configuration, there are 6 ETB for MS and 32 ETBs for the extension subracks.
Each ET-MC41 can handle 1 STM-1. Thus, 1 RNC 550 can support all the interface connections.
MS will handle all the Iur, IuCS and IuPS connections, which leaves 1 STM-1 available for Iub.
With 100 sites distributed evenly, there will be 20 Node Bs and 60 T1 requirements per subrack. The RNC
modules and subracks can support these requirements. At least 6 ET-MC41 for the MS and 4 ET-MC41 for
ES (1 for each extension subrack) is needed.
-
Verify the VP shaper and AAL2 limit per ETB.
There are 126 VP shapers for each ET-MC41. With 20 Node Bs per ETB and assuming 1 VP per Node B,
the VP shaper capacity is more than enough.
There are 126 AAL2 multiplexers for each ET-MC41. With 20 Node Bs per ETB and assuming 1 AAL2
multiplexer per Node B, the 6 ETB for MS + 1 ETB for each ES is enough to support the requirement.
Dimensioning factors
Iub throughput
TCPP
BTS count
Cell count
Version 1.3
Grace Jacinto
Requirement
RNC Capacity
316 Mbps
425 Mbps
138 Mbps
165 Mbps
100
128
300
384
Required RNC = 1 RNC 550, 9 ET-MC41
Table 19. RNC Dimensioning example
Required RNC
1 RNC 550
1 RNC 550
1 RNC 50
1 RNC 50
23

Ericsson
5. Iu Interface Dimensioning
The Iu interface is the connection from the radio access network to the core network. It has separate
user and control planes, the user plane uses AAL2 for IuCS and AAL5 for IuPS while the control plane is
AAL5.
5.1 Iu-CS Interface
The Iu-CS interface connects the radio access network to the circuit switched core network, between an
RNC and an MSC.
User Plane transfers user data related to radio access bearers over the Iu interface. It can be defined
as transparent mode where all traffic has predefined SDU sizes or support mode where SDU sizes change
during the connection such as in AMR call.
Control Plane contains both RANAP and Q.2630. RANAP (Radio Access Network Application Part)
handles the signaling between the RNC and MSC or SGSN, it contains all control information specified for
the radio network layer. Q.2630 is responsible for setting up and multiplexing AAL2 connections.
The control plane in the Iu-CS can be terminated in the MSC server and the user plane can be terminated
in the MGW
Dimensioning Process
User Plane:
- Calculate the bandwidth requirements for Circuit Switched service using the Iu Equivalent
bandwidth below:
Radio Bearer
UL Bandwidth
DL Bandwidth
AMR 12.2 kbps
12.1 kbps
12.1 kbps
CS 64 kbps Conversational Data
84.8 kbps
84.8 kbps
CS 57.6 kbps Streaming Data
75.2 kbps
75.2 kbps
Table 20. RNC Dimensioning example
-
Calculate the AAL2 paths required:

Number of AAL2 paths = Number of AAL2 connection/248
Control Plane:
- 1% of Iu-CS User Plane
Iu-CS Bandwidth = User Plane + Control Plane
Example:
SHO = 30%
Iu-CS User Plane = 100*(12*12.1+3*84.8) = 40 Mbps
AAL2 paths = 100*(12+3)/248 = 6 VCs
Iu-CS Control Plane = 1%*40 Mbps = 400 kbps
Iu-CS Bandwidth = 40 Mbps + 400 kbps = 40.4 Mbps
Version 1.3
Grace Jacinto
24

Ericsson
USER PLANE VCs
40 Mbps
MSC/
MGW
RNC
CONTROL PLANE VC
400 kbps
Iu-CS
Figure 6. Iu-CS Configuration example

5.2 Iu-PS Interface
The Iu-PS interface connects the radio access network to the packet switched core network, between the
RNC and SGSN
User Plane transfers user data related to radio access bearers over the Iu interface, the transparent
mode is used.
Control Plane RANAP (Radio Access Network Application Part) handles the signaling between the RNC
and MSC or SGSN, it contains all control information specified for the radio network layer. It performs the
RAN set-up/modification/release, releasing of all resources both signaling and user plane, identification of
the UE, tracing, paging, signaling transfer between UE and CN, load management of the Iu, and UE
locating.
Dimensioning Process
User Plane:
- Calculate the bandwidth requirements for Packet Switched services for both uplink and downlink
- Get the maximum between the uplink and downlink requirements and multiply by the Protocol
overhead (25%)
- Calculate the AAL5 path
Control Plane:
- 1% of Iu-PS User Plane
Iu-PS Bandwidth = User Plane + Control Plane
Example:
SHO = 30%
UL User Plane = 100*(5*64+2*64+2*384) = 121.6 Mbps
DL User Plane = 100*(5*128+2*384+2*512) = 192 Mbps
Iu-PS User Plane = 192*1.25 = 240 Mbps
Iu-PS Control Plane = 1%*240 Mbps = 2.4 Mbps
Iu-PS Bandwidth = 240 + 2.4 Mbps = 242.4 Mbps
Version 1.3
Grace Jacinto
25

Ericsson
USER PLANE VCs
242.4 Mbps
RNC
CONTROL PLANE VC
3G
SGSN
2.4 Mbps
Iu-PS
Figure 7. Iu-PS Configuration example
Version 1.3
Grace Jacinto
26

Ericsson
6. Summary of Formulas and Counters

Listed below are the formulas used in this document. Also, some of the Ericsson RNC counters which can
be used as inputs in the dimensioning process are laid in Section 6.4.
6.1 Channel Element Dimensioning Formulas
Total UL CEs Required = [sum of CEs per application + CE (hsdpa adch)]*(1+SHO)
Total DL CEs Required = sum of CEs per application * (1+SHO)
Number of RAX boards = roundup (Total UL CEs Required / CE capacity per RAX board)
Number of TX boards = roundup (Total DL CEs Required / CE capacity per TX board)
6.2 Iub Dimensioning Formulas
Iub Dedicated Channel BW (per service) = no. of channels * Iub equivalent bandwidth* (1+SHO)
UL Dedicated Channel Bandwidth = Iub voice + Iub CS + Iub PS + Iub ADCH
DL Dedicated Channel Bandwidth = Iub voice + Iub CS + Iub PS + Iub HSDPA
UL User Plane Bandwidth = UL Common Channel Bandwidth + UL Dedicated Channel Bandwidth
DL User Plane Bandwidth = DL Common Channel Bandwidth + DL Dedicated Channel Bandwidth
User Plane Bandwidth = max (UL User Plane Bandwidth, DL User Plane Bandwidth)
Control Plane Bandwidth = NBAP-C + NBAP-D + ALCAP + Node Synchronization
O&M = 150 cps
Iub Requirement = User Plane Bandwidth + Control Plane Bandwidth + O&M
6.3 RNC Dimensioning Formulas
RNC Throughput Requirement = sum of Iub Requirements of connected Node Bs
Number of RNC (throughput) = Iub throughput reqt/(RNC throughput*fill rate)
Number of RNC (TCPP) = Required TCPP/(TCPP capacity*fill rate)
Number of RNC (BTS) = number of connected BTS / (BTS capacity*fill rate)
Number of RNC (cell) = number of cells connected / (cell capacity*fill rate)
Number of STM-1 connections = sum of STM-1 for Iub, Iur, IuCS and IuPS
Iur = 5% * Iub Requirements
IuCS = (AMR users*12.2 kbps + CS64 users*64 kbps)*Protocol overhead*Signaling overhead
IuPS = PS users * bit rate * Protocol Overhead * Signaling Overhead
Version 1.3
Grace Jacinto
27

Ericsson
RNC Requirement = max [Number of RNC (throughput), Number of RNC (AAL2 connectivity), Number of
RNC (BTS), Number of RNC (cell)]
6.4 Iu Dimensioning Formulas
Iu-CS User Plane number of users*Iu equivalent bandwidth
Iu-CS Control Plane 1%*Iu-CS User Plane
Iu-CS Bandwidth = Iu-CS User Plane + Iu-CS Control Plane
Iu-PS User Plane number of users*Iu equivalent bandwidth
Iu-CS Control Plane 1%*Iu-CS User Plane
Iu-CS Bandwidth = Iu-CS User Plane + Iu-CS Control Plane
6.5 Ericsson Counters
Below are some of the Ericsson KPIs and counters for dimensioning use. Details on its used will be
described in a document for UMTS Resource Monitoring that is currently under development.
Table 21 Ericsson Dimensioning KPIs
Category
KPI Name
Soft/Softer Handover Overhead
Average number of Circuit Switched (CS) Speech Users
Circuit-Switched (CS) Speech Downlink Code Utilization
Circuit-Switched (CS) Speech Erlangs
Circuit-Switched (CS) 57 Users
Circuit-Switched (CS) 57 Downlink Code Utilization
Circuit-Switched (CS) 57 Erlangs
Circuit-Switched (CS) 64 Users
Voice and
Data
Circuit-Switched (CS) 64 Downlink Code Utilization

Circuit-Switched (CS) 64 Erlangs
PS Data Interactive Users
PS Data DCH Interactive Users
HS A-DCHs Users
PS Streaming + Packet 8kbps PS Users
PS Interactive Users on FACH
Grade of Service for Circuit-Switched (CS) Speech
Grade of Service for Circuit-Switched (CS) 64 and 57
Grade of Service for Packet-Switched Interactive
Grade of Service for Packet-Switched Streaming
ATM Port Utilization
ATM Cell Rate
ATM
Virtual Path Quality

Virtual Path Utilization
Virtual Path Cell Rate
Virtual Channel Quality
Version 1.3
Grace Jacinto
28

Ericsson
Virtual Channel Utilization
Virtual Channel Cell Rate
Lost Frame Ratio on Iub for HS
IP Data Link Layer(OAM Traffic Payload)
Counter Name
pmTransmittedCarrierPower
pmDpchCodePowerSf4
pmDpchCodePowerSf8
pmDpchCodePowerSf16
pmDpchCodePowerSf32
pmDpchCodePowerSf64
pmDpchCodePowerSf256
pmSumOfHsScchUsedPwr
pmTransmittedCarrierPowerNonH
S
pmNoOfTfc1OnFach1
pmNoOfTfc1OnFach2
pmNoOfTfc1OnFach3
Table 22 Ericsson Counters

Description
Tx Power
transmitter carrier power measured at the TX reference point
The average power transmitted over the DPCH with SF=4
HS-SCCH transmitted power per cell.If more than one HS-SCCH code is
used, then the registered value is the sum of each individual value. 0-50.5
dbm.
the transmitted carrier power for all non high speed codes in the cell.2550.5 dbm resolution of 0.5
the average transmitted output power for each GP on FACH1
pmHwCePoolEul
pmNoofRadioLinksSF4
pmNoofRadioLinksSF8
pmNoofRadioLinksSF16
this counter is used to observe the total DL power used for the E-AGCH,ERGCH and E-HICH in the cell.
UL CE
total sum of Ces allocation on the UL Hardware by the E-UL scheduler
the number of RLs used for the UL baseband pool with SF=4
pmNoULLimitEul
the number of times a scheduling decision is taken to increase the hardware

rate of an E-DCH user and there is a need to decrease the hardware rate for
another D-CH user owing to UL hardware resource limitations
pmCommonChPowerEul
pmsetupattemptsSf4
pmsetupattemptsSf8
pmsetupattemptsSf16
pmsetupattemptsSf32
pmsetupattemptsSf64
pmsetupattemptsSf128
pmsetupfailuresSf4
pmsetupfailuresSf8
pmsetupfailuresSf16
Version 1.3
Grace Jacinto
the number
the number
the number
SF16
the number
SF32
the number
SF64
the number
SF128
the number
SF256
the number
the number
the number
of setup attempts for each GP for the UL baseband pool for SF4
of setup attempts for each GP for the UL baseband pool for SF8
of setup attempts for each GP for the UL baseband pool for
of setup failures for each GP for the UL baseband pool for SF4
29

Ericsson
pmsetupfailuresSf32
pmsetupfailuresSf64
pmsetupfailuresSf128
pmNoodIbho
PmApomcofUl
pmApromcOfRACHCap
pmApomcofRakeRecUsed
pmNoOfRadioLinksSf4
pmNoOfRadioLinksSf8
pmNoOfRadioLinksSf16
pmsetupattemptsSf4
pmsetupattemptsSf8
pmsetupattemptsSf16
pmsetupattemptsSf32
pmsetupattemptsSf64
pmsetupfailuresSf4
pmsetupfailuresSf8
pmsetupfailuresSf16
pmsetupfailuresSf32
pmsetupfailuresSf64
pmNoOfRlAdditionFailuresSf4
pmApomcofMdsr
Version 1.3
Grace Jacinto
the number of setup failures for each GP for the UL baseband pool for SF32
the number of setup failures for each GP for the UL baseband pool for SF64
the number of setup failures for each GP for the UL baseband pool for
SF128
the number of setup failures for each GP for the UL baseband pool for
SF256
the number of redistributions of RLs between RAX boards in the RBS
(interboard handover) IBHO
the average RL usage of the maximum UL capacity, in percent
the average RACH usage of the maximum UL capacity in percent
the average rake receiver usage of the maximum UL capacity, in percent
DL CE
the number of Rls used for the DL baseband pool for SF4
the number of setup attempts for each GP for the DL baseband pool for SF4
the number of setup attempts for each GP for the DL baseband pool for SF8
the number of setup attempts for each GP for the DL baseband pool for
SF16
SF32
SF64
SF128
SF256
the number of setup failures for each GP for the DL baseband pool for SF4
the number of setup failures for each GP for the DL baseband pool for
SF128
the number of setup failures for each GP for the DL baseband pool for
SF256
the number of RL addition failures for the DL baseband pool caused by TXB
congestion for SF4
congestion for SF8
congestion for SF16
congestion for SF32
congestion for SF64
congestion for SF128
congestion for SF256
the average Mixed DL Service Rate (MDSR) usage of the Mixed DL Service
Capacity (MDSC) in percent. MDSR is the resource usage for transport
channel handling and it is independent from the traffic intensity for that
30

Ericsson
pmApomcOfMdlr
pmApomcOfSpreadersUsed
channel. The MDSC is the sum of all Channel Elements (CE) of the
configured TX boards in the RBS. The number of CEs for each TX board
depends on the type of TX board.
the average MDLR usage of the MDSC in percent. The MDLR is the resource
usage for the RL handling and it is dependent of the SF used.
the average spreader usage of the maximum DL spreader capacity in
percent.
HSDPA
pmAverageUserRate
pmTargetHsRate
pmNoOfHsUsersPerTti
pmRbsHsPdschCodePrio
pmRemainingResourceCheck
pmSampleNumHspdschCodesAdd
ed
pmSumNumHspdschCodesAdded
the distribution of the average user rate among all user allocated ti highspeed-DSCH in the cell.
the target high-speed bit rate as a percentage of the maxHsRate parameter
Average number of high speed users scheduled in the cell at each 2 ms TT1
the number of times there is an Hs-PDSCH HW shortage. The counter
accumulates the number of code shortage occurrences, that is, the number
of time priority resolve is entered in the algorithm for dynamic code
allocation
the reason why it is not possible to schedule another high-speed user for
immediate traffic. (1) Hs-SCCH code shortage; (2) HS-PDSCH code
shortage;(3)HS-PDSCH power shortage
the number of times the RBS dynamic code addition algorithm is executed.
sum of all codes that are allocated for HS-DSCH (RNC allocation codes
allocated by the RBS dynamic HS-PDSCH code addition algorithm)
EUL
pmNoUlUULoadLimitEul
pmNoSchEdchEul
pmEdchIubLimitingRatio-EUL
pmEdchIubMeasRate-EUL
pmNoUlIub Limit Eul
Counter for the number of time a scheduling decision is taken to increase

the Uu rate of an E-DCH user and there is a need to decrease the Uu rate
for another E-DCH user owing to ULUu load limitations.
This counter shows the total number of simultaneous scheduled E-DCH
users have a rate >0kbps
Iub
Counter for the number of 100 ms periods where the Iub has been the only
limiting factor dure at least one TTI is divided by the number of 100 ms
periods during which edchGrantrate has been bigger than zero.
Measurement of the E-DCH Iub Bit rate sent by the RBS in uplink over Iub.
The bit rate includes all bits sent in the Radio Network Layer E-DCH data
frames, including its overhead. AAL2 and ATM overhead is not included.
Counter for the number of time a scheduling decision is taken to increase
the Iub rate of an E-DCH u ser and there is a need to decrease the Iub rate
for another E-DCH user owing to ULUu load limitations.
RAB Denied
pmNoOfNonHoReqDeniedCs
pmNoOfNonHoReqDeniedInteract
ive
pmNoOfNonHoReqDeniedPsStrea
ming
pmNoOfNonHoReqDeniedSpeech
pmNoOfNonHoReqDeniedAdm
pmNoOf SwDownNgAdm
Version 1.3
Grace Jacinto
Number of CS data or CS streaming RAB establishments rejected by

admission control
Number of interactive RAB establishments rejected by admission control

Number of PS Streaming RAB establishments rejected by admission control
Number of Speech RAB establishments rejected by admission control
Number of RAB establishment and RRC requests denied due to admission
number of downswitch for non-guaranteed and guaranteed-hs users served
by this RNC switched down due to admission control. The counter is
incremented at downswitching from Cell_DCH 64/384-->64/128 or
31

Ericsson
pmNoofNonHoReqDeniedHs
Cell_DCH 64/128-->64/64 initiated by admission control to do Best Effort

Cleanup. This is done after admission rejection due to insufficient downlink
power or code utilization limits.
Number of NBAP: Radio Link Set-uo Messages reject by Admission control
due to User Network Interface Signaling ATM Adaptation Layer (UNI-SAAL)
congestion
Number of Interactive RAB establishments on a HS configuration rejected
by admission control
pmNoOf NonHoReqDenied Eul
Number of admission request denied at RAB establishments on E-DCH.
pmNoof Discarded NBAP

Messages
pmNoServingCellReqDeniedEul
pmNoNonServingCellReqDeniedE
ul
pmNoofNonHoReqDenied
PsStr128
Number of admission request denied when requesting the cell as serving

cell because the number of E-DCH users is above the admission threshold.
Number of admission request denied when requesting the cell as nonserving cell because the number of E-DCH users is above the admission
threshold.
Number of PS Streaming 128 RAB establishments rejected by admission
control.
PAGING
pmNoCellUpdAttempt
PmNoCellUpdSuccess
total number of attempted cell update procedures (periodic and cell

reselection, RRC cell update message received with Cell Update Cause =
Cell Reselection or Periodic Cell Update)
total number of successful cell update procedures (periodic and cell
reselection, RRC cell update message received with Cell Update Cause =
Cell Reselection or Periodic Cell Update)
Compressed Mode
pmSumCompMode
Total number of compressed mode users, reported per cell
pmSamplesCompMode
Number of samples of compressed mode users

Congestion
Number of circuit-switched data radio connections served by this RNC
terminated due to congestion
Number of times Congestion Control is triggered due to high DL power.
Number of E-DCH users served by this RNC which are down-switched due
to DL congestion in both EUL serving cell and EUL non-serving cell
pmNoOfTermCSCong
pmSum ofTimesMeasOlDl
pmNoOfSwDownEulCong
pmNoOfIurSwDownNgCong
Number of non-guaranteed users served by this RNC switched down to

common or terminated due to congestion
Number of non-guaranteed users served by another RNC terminated due to
congestion
pmNoOfIurTermSpeechCong
Number of speech Radio connections served by another RNC terminated

due to congestion.
pmNoOfSwDownNgCong
pmSumOfTimesMeasOlUl
Number of both CS Radio connections and PS streaming parts in a

connection, served over Iur and terminated due to congestion
Number of both CS Radio Connections and PS streaming parts in a
connection, served over Iur and terminated due to congestion
Number of times Congestion Control is triggered due to high Ul interference.
This counter is increased if congestion control function detects UL
congestion. It is done by monitoring NBAP Common Measurement Reports
for each cell to see if the UL power is above a threshold.
pmTotalTimeDLCellCong
The total amount of time (seconds) a cell was congested in DL during a

reporting period
pmTotalTimeULCellCong
The total amount of time (seconds) a cell was congested in UL during a

reporting period
pmNoOfIurTermCSCong
pmNoofIurTermCsCong
Version 1.3
Grace Jacinto
32

Ericsson
pmNoofSwDonwHsCong
pmNoSucccessOutIRATHOSpeech
pmNoSucccessOutIRATHOCS57
pmNoSucccessOutIRATHOMulti
pmNoInCSIratHoSuccess
pmNoInCSIRATHoAtt
pmNoInCsIratHoAdmFail
pmNoOutIratCcAtt
pmNoOutIratCcReturnOldCh
pmNoOutIratCcSuccess
pmTotNoRRcConnectAttIratCellR
esel
pmTotNoRRcConnectAttIratCcOrd
er
pmTotlNoRrcConnectFailCongIrat
CellResel
pmTotNoRrcConnectFailCongIrat
CcOrder
Number of Radio Connections served by this RNC, including an HSDPA

service, which are channel switched down due to congestion resolve actions
initiated on a serving Ue context.
IRAT
Number of successful speech outgoing Inter System Handovers
Number of successful CS57 outgoing Inter System Handovers
Number of successful multi-RAB outgoing Inter System Handovers
Number of successful CS incoming Inter System Handovers
Number of attempted CS incoming Inter System Handovers (counted before
module and central MP load control, after SCCP MP Load control)
of CS Incoming Inter System Handovers that failed due to admission
blocking in UTRAN.
Total number of the PS Inter-RATCC attempts on DCH
Total number of the PS Inter-RATCC attempts for Ue on DCH where the UE
returns to old channel
Number of successful PS Inter-RAT cell change attempts for UE on
dedicated channel. The counter is triggered by CN Iu Release Command
following the sending of the Cell Change Order from Utran message.
Total number of RRC connection establishment attempts with establishment
cause Inter-RAT cell reselection.
Total number of RRC connection establishment attempts with establishment
cause Inter-RAT cell change order
Number of unsuccessful RRC Connection establishments with establishment
cause Inter-RAT cell reselection, which failed due to congestion
Number of unsuccessful RRC Connection establishments with establishment
cause Inter-RAT cell change order, which failed due to congestion.
PAGING
pmNoPagingAttemptCnInitDcch
Number of CN-initiated pages set onDCCH to connected mode Ues.
pmNoPageDiscardCmpLoadC
pmNoPagingAttemptUtranRejecte
d
Number of pages discarded due to central MP Load control
pmCnInitPagingToIdleUeRa
Number of page requests rejected by UTRAN

Counting the number of page type 1 attempts to idle Ues in a cell
(excluding) retransmissions)
Counting the number of page type 1 attempts with cause 'Terminating
Conversational Call' to idle Ues in a cell (excluding retransmission).
Counting the number of page type 1attempts with cause 'Terminating
Interactive Call' or 'Terminating Background Call' to idle Ues in a cell
(excluding retransmission).
Number of CN-Initiated pages sent to idle mode Ues (with CN identity
specified in the RRC Paging Type 1 (message) in specified Location Area
(LA) (circuit-switched pages).
Number of CN-Initiated pages sent to idle mode Ues (with CN identity
specified in the RRC Paging Type 1 (message) in specified Routing Area
(RA) (packet switched pages).
pmUTRANInitPagingToUraUe
Number of Utran initiated pages attempted for Ues in URA-PCH state.
pmCnInitPagingToUraUe
Number of CN initiated pages attempted for Ues in URA_PCH
pmNoPagingType1Attempt
pmNoPagingType1AttemptCs
pmNoPagingType1AttemptPs
pmCnInitPagingToIdleUeLa
RAB
pmSumCs12RabEstablish
Version 1.3
Grace Jacinto
a snapshot of the total number of currently active speech 12.2 kbit RAB
33

Ericsson
pmSamplesCs12RabEstablish
connections is recorded once every 5 seconds. This counter contains the

sum of all the snapshot values taken in a ROP period added together
Number of samples recorded within the ROP period for number of active
speech 12.2 kbit RAB.
pmSumCs12RabEstablish/pmSamplesCs12RabEstablish gives the average
number of single CS12 RABs which were active during a ROP period.
a snapshot of the total number of currently active speech 64 kbitRAB
connections is recorded once every 5 seconds. This counter contains the
sum of all the snapshot values taken in a ROP period added together
Number of samples recorded within the ROP period for number of
conversational 64 kbit RAB.
pmSumCs64RabEstablish/pmSamplesCs64RabEstablish gives the average
number of single CS64 RABs which were active during a ROP period.
pmSamplesCs12Ps64RabEstablish
a snapshot of the total number of currently active CS 57 RABs connections

is recorded once every 5 seconds.This counter contains the sum of all the
snapshot values taken in a ROP period added together
Number of samples recorded within the ROP period for number of CS 57
RABs. pmSumCs57RabEstablish/pmSamplesCs57RabEstablish gives the
average number of single CS57 RABs which were active during a ROP
period.
a snapshot of the total number of currently active speech CS plus 64/64
connections PS multiRAB. It is recorded once every 5 seconds.This counter
contains the sum of all the snapshot values taken in a ROP period added
together
Number of samples recorded within the ROP period for number of speech
CS plus 64/64 PS multi RAB.
pmSumCs12Ps64RabEstablish/pmSamplesCs12Ps64RabEstablish gives the
average number of single CS12 RABs which were active during a ROP
period.
pmSamplesAmr12200RabEstablis
h
Number of samples recorded within the ROP period for "number of speech
AM12200 RABs established".
pmSumAmr12200RabEstablish
Sum of sample values recorded within ROP period for 'Number of Speech
AMR 12200 RABs established'.
pmSamplesAmr7950RabEstablish
AMR7950 RABs established".
pmSumCs12Ps64RabEstablish
pmSamplesBestAmr12200RabEst
ablish
pmSumBestAmr12200RabEstablis
h
pmSamplesBestAmr7950RabEsta
blish
pmSumBestAmr7950RabEstablish
Version 1.3
Grace Jacinto
AM12200 RABs established" for the best cell in the active set
AMR 12200 RABs established' for the best cell in the active set.
AMR7950 RABs established" for the best cell in the active set.
34

Ericsson
blish
blish
pmSumPsSTr64Ps8RabEstablish
pmSamplesPsSTr64Ps8RabEstabli
sh
pmSumRABEstablish
pmSamplesRABEstablish
pmNoRABEstablishSuccessPacket
InteractiveEul
A snapshot of the totla number of currently active PS Streaming 16/64 + PS
Interactive 8 kbps RAB recorded once every 30 seconds.
Number of samples recorded within the ROP period for number of active PS
streaming ply PS8 multi RABs.
A snapshot of the total number of currently active RABs is recored once
every 30 seconds.
Number of samples recorded within the ROP period for number of RABs
established.
pmNoRABEstablishSuccessCS64
Interactive
Stream
pmNoRABEstablishSuccessSpeec
h
The number of successful RAB establishments for PS Interactive RAB

mapped on E-DCH/HSDPA
The number of successful RAB establishments CS57 referred to the Best Cell
in the Active Set
The number of successful RAB establishments CS64 referred to the Best Cell
in the Active Set
The number of successful RAB establishments PS Data Interactive referred
to the Best Cell in the Active Set
The number of successful RAB establishments PS Streaming referred to the
Best Cell in the Active Set
The number of successful RAB establishments Speech referred to the Best
Cell in the Active Set
pmSumBestAmrCs12RabEstablish
Sum of all sample values recorded once every 5 seconds for 'number of
distinct speech users',referred to the best cell in the Active set.
pmNoRABEstablishSuccessCS57
pmSamplesBestCS12RabEstablish
pmNoFailedRABEstAttemptLackDl
Pwr
pmNoFailedRABEstAttemptLackC
hnlCode
pmNoFailedRABEstAttemptLackDl
ASE
pmNoFailedRABEstAttemptLackUl
ASE
pmSamplesCS64PS8Establish
pmSumCS64PS8Establish
InteractiveHS
pmSamplesBestPSEulRABEstablis
h
pmSumBestPSEulRABEstablish
pmSamplesPsEulRAbEstablish
pmSumPsEulRAbEstablish
pmSamplesPSHsAdchRABEstablis
hed
Version 1.3
Grace Jacinto
Number of samples recoreded once every 5 seconds within ROP predio for '
number of distinct speech users.', referred to the best cell in the Active Set.
Number of failed RAB establishment attempts due to lack of DL power
Number of failed RAB establishment attempts due to lack of DL
channelization codes
Number of failed RAB establishment attempts due to lack of DL ASE
Number of failed RAB establishment attempts due to lack of UL ASE
The number of samples recorded in the ROP period for the multi-RAB
UDI+8/8
The number of successful RAB establishments for PS Interactive RAB
mapped on HS-DSCH.
Stepped every time the corresponding sum counter of the best cell,
pmSumBestPSEUlRabEstablished, is incremented
Number of E-DCH radio bearers established in this cell when it is the best
cell, incremented every 5 seconds.
Stepped every time the corresponding sum counter of the best cell,
pmSumPSEUlRabEstablished, is incremented
Number of E-DCH radio bearers established in this cell, incremented every 5
seconds.
Number of samples recorded within the ROP period for 'Number of A-DCHs
established'.
35

Ericsson
pmSumPSHsAdchRABEstablished
pmSamplesBestPSHsAdchRABEst
ablished
pmSumBestPSHsAdchRABEstablis
hed
Stream128
pmSamplesPsStr128Ps8RabEstabl
ish
Sum of all sample values for 'Number of A-DCHs established'.

Number of samples recorded within the ROP period for 'Number of A-DCHs
radio bearers established' in the cell carrying HS-DSCH in the active set.
Sum of all sample values for 'Number of A-DCHs radio bearers established
in the cell carrying Hs-DSCH in the active set'.
Number of successful RAB establishments (PS Streaming 128) referred to
the best cell in the Active Set
Number of samples within the ROP period for the number of PS Streaming
16/128 and PS streaming 128/16 kbps RABs established.
pmSumBestPsStr128Ps8RabEstab
lish
Sum of all sample values recorded once every 5 seconds for number PS
Streaming 16/128 and PS Streaming 128/16 RAB established.
Number of samples within the ROP period for the number of PS Streaming
16/128 and PS streaming 128/16 kbps RABs established for the best cell in
the active set.
Sum of all sample values recorded once every 5 seconds for number PS
Streaming 16/128 and PS Streaming 128/16 RAB established for the best
cell in the active set.
Number of samples within the ROP period for the number of Streaming 57.6
kbps CS RABs established for the best cell in the active set.
pmSumBestCs57RabEstablish
Sum of all sample values recorded once every 5 seconds for number
Streaming 57.6 CS RAB established for the best cell in the active set.
Number of samples within the ROP period for the number of conversational
64 kbps CS RABs established for the best cell in the active set.
pmSumPsStr128Ps8RabEstablish
pmSamplesBestPsStr128Ps8RabE
stablish
pmSumBestCs64RabEstablish
pmSamplesBestPsStr64PS8RabEs
tablish
pmSumBestPsStr64Ps8RabEstabli
sh
pmsamplesPSInteractive
pmSumPSInteractive
pmNoFailedRabEstAttemptLackDl
HwBest
pmNoFailedRabEstAttemptLackUl
HwBest
pmNoFailedRabEstAttemptLackDl
Hw
pmNoFailedRabEstAttemptLackUl
Hw
Sum of all sample values recorded once every 5 seconds for number
conversational 64 kbps CS RAB established for the best cell in the active set.
Number of samples within the ROP period for the number of PS streaming
64/16 and PS streaming 16/64 kbps RABs established for the best cell in the
active set.
Sum of all sample values recorded once every 5 seconds for number of PS
streaming 64/16 and PS streaming 16/64 kbps RABs established for the best
cell in the active set.
Number of samples recorded within the ROP period for 'Number of
Interactive PS RABs established excluding RABs on HS configurations or
Cell_FACH
Sum of all sample values recorded for number of interactive PS RABs
established excluding RABs on HS configurations of cell_FACH.
Number of failed RAB establishment due to lack of DL hardware resources,
for the best cell in the active set.
Number of failed RAB establishment due to lack of UL hardware resources,
for the best cell in the active set.
Number of failed RAB establishment due to lack of DL hardware resources.
Number of failed RAB establishment due to lack of UL hardware resources.
ATM
pmTransmittedAtmCells
pmReceivedAtmCells
Number of transmitted ATM cells through the ATM port

Number of received ATM cells through the ATM port
pmReceivedAtmCells
Number of transmitted ATM cells.

Number of received ATM cells.
Number of transmitted ATM cells.
pmReceivedAtmCells
pmNoOfIfInUcastPkts
Number of received ATM cells.

The number of input unicast packets delivered to higher layer.
Version 1.3
Grace Jacinto
36

Ericsson
pmNoOfIfInNUcastPkts
pmNoOfIfInDiscards
The number of input broadcast or multicast packets delivered to higher

layer.
The number of input packets discarded due to resource limitations.
pmNoOfIfOutDiscards
The number of outbound packets discarded due to resource limitations.
pmNoOfIpInReceives
pmNoOfIpInDiscards
pmNoOfIpForwDatagrams
Total number of datagrams received.

The number of datagrams discarded due to resource limitations.
number of sent datagrams:
NoOfIpOutDiscards.
The number of discarded datagrams due to lack of resources
Version 1.3
Grace Jacinto
37

Umts Ran Dimensioning Guidelines

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Umts Ran Dimensioning Guidelines

Hochgeladen von

Copyright:

Verfügbare Formate

UMTS RAN Dimensioning Guidelines