GBSS14 0 Dimensioning Rules 01 (20120630)

GBSS14.
0 Dimensioning Rules
Issue
01
Date
2012-06-30
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2012. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are the property of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services, and features are stipulated by the commercial contract made between
Huawei and the customer. All or partial products, services, and features described in this document may not
be within the purchased scope or the usage scope. Unless otherwise agreed by the contract, all statements,
information, and recommendations in this document are provided AS IS without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents; but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address:
Huawei Industrial Base

Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website:
http://www.huawei.com
Email:
support@huawei.com
GBSS14.0 Dimensioning Rules
Contents
1 Introduction ..................................................................................................................................... 4
2 BTS ................................................................................................................................................... 5
2.1 BTS3012 .......................................................................................................................................................... 5
2.2 3900 Series BTS............................................................................................................................................. 13
2.3 GSM Network Dimensioning ......................................................................................................................... 24
2.4 GSM Link Budget Procedure ......................................................................................................................... 25
2.5 GPRS/EDGE Coverage Dimensioning .......................................................................................................... 28
2.6 GSM Capacity Dimensioning Procedure ....................................................................................................... 28
2.7 Abis Transmission Dimensioning ................................................................................................................... 33
2.8 Case Study...................................................................................................................................................... 36
2.9 Counters Related to Capacity ......................................................................................................................... 37
3 BSC ................................................................................................................................................. 39
3.1 Configurations Standards of BSC6900 .......................................................................................................... 39
3.2 BSC Service Processing Units Dimensioning ................................................................................................ 45
3.3 BSC Interface Dimensioning.......................................................................................................................... 50
3.4 BSC subrack and cabinet ................................................................................................................................ 77
3.5 Impact of traffic model on Configuration....................................................................................................... 77
3.6 Impact of VAMOS on Configuration ............................................................................................................. 79
3.7 Counters Related to Capacity ......................................................................................................................... 81
4 OMC .............................................................................................................................................. 83
4.1 Network Management Capability .................................................................................................................. 83
4.2 Equivalent NE Conversion Tables.................................................................................................................. 84
4.3 Data Storage Capability ................................................................................................................................. 85
4.4 Management Capability ................................................................................................................................. 88
4.4.3 ATAE Cluster Management Capability ....................................................................................................... 89
4.5 Number of Concurrent Users ......................................................................................................................... 90
4.5.3 ATAE Support Number of Concurrent Users .............................................................................................. 91
4.6 Impact Factors of the Management Capability............................................................................................... 91
4.7 Conditions and Restrictions ........................................................................................................................... 92
4.8 Nastar/PRS solution dimensioning rules ........................................................................................................ 92
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.
Page 3 of 93
Introduction
This document is to introduce the Dimensioning rules for Huaweis GSM products including
BTS and BSC. It is based on release GBSS14.0 including the introduction of capacity of
baseband board and transmission of BTS, the traffic processing capability of BSC and
interface capability (A, Abis and Gb).

Page 4 of 93
BTS
BTS3012 and 3900 series BTS Dimensioning rules are included.

.
2.1 BTS3012
2.1.1 BTS3012/BTS3012AE Basic Module Configuration
The BTS3012E/BTS3012AE has the following subsystems:
Common Subsystem
Signal Protection Subsystem
Double-Transceiver Subsystem
RF Front-End Subsystem
Antenna Subsystem
Power Subsystem
Environment Monitoring Subsystem

Page 5 of 93
FFiigguurree22--11 Logical structure of the BTS3012/BTS3012AE
Common Configurations
The functions of the BTS3012/BTS3012AE common subsystem are performed by the
common subrack, which consists of the DTMU, DEMU, DATU, DCSU, DCCU, DPTU,
DABB, and DGPS.
Figure shows the board configurations of the BTS3012/BTS3012AE common subrack.
FFiigguurree22--22 Board configurations of the BTS3012/BTS3012AE common subrack

Table lists the mapping relations between the boards and the slot numbers.
Table 2-1 Mapping relations between the boards and slot numbers of the BTS3012/BTS3012AE
common subrack
Board Name
Slot No.
DTMU
Slot 0 or 1
DEMU
Slot 2, 3, 4, or 7
DABB
Slot 2, 3, 4, or 7

Page 6 of 93
Board Name
Slot No.
DPTU
Slot 3 or 4
DGPS
Slot 2, 3, 4, or 7
DATU
Slot 2, 3, 4, or 7
DCSU
Slot 5
DCCU
Slot 6
The DTMU is a mandatory board, which can work in active/standby mode. A maximum of two DTMUs can be
configured.
The DEMU is not configured in the common subrack of the BTS3012AE cabinet with AC power supply.
The DGPS cannot be configured in the BTS3012AE (for DCU) cabinet.
The DPTU can work in active/standby mode. A maximum of two DPTUs can be configured.
The DABB and the DPTU cannot be configured at the same time.
RF Unit Configurations
The RF unit consists of the DTRU subrack and DAFU subrack. The DTRU subrack houses the DTRUs and the
DAFU can be configured with the DDPU, DCOM, DFCU, DFCB, or the combination of these modules.
Figure shows a fully configured BTS3012/BTS3012AE DTRU subrack.
FFiigguurree22--33 Fully configured DTRU subracks

Part A in figure shows the DAFU subrack configured with the DDPU and part B shows the
DAFU subrack configured with the DFCU.

Page 7 of 93
FFiigguurree22--44 Fully configured DAFU subrack

A maximum of six DDPUs can be configured in the DAFU subrack. The DCOM is used with the DDPU only
when a cell is configured with more than four TRXs.
The DFCU is applied only over EGSM900 MHz and DCS1800 MHz bands. It is used only in the S4/4/4 or
higher cell configurations.
A maximum of six DFCUs can be configured in the DAFU subrack. The DFCB is cascaded with the DFCU only
when the DFCU is expanded to enable the six-in-one function.
The DDPU and the DFCU can be configured in the same subrack.
Table 2-2 BTS3012/BTS3012AE RF Unit Specification

RF Unit
Output power
carriers
DTRU
40W or 60W
2.1.2 BTS3012/BTS3012AE Typical Configuration

Figure shows the BTS3012 in full configuration.

Page 8 of 93
(1) Transmission subrack
(2) Common subrack (3) Fan subrack
(4) DTRU subrack
(5) DAFU subrack
(6) Power supply unit
(7) Signal lightning protection subrack
FFiigguurree22--55 BTS3012 (-48V DC) in full configuration

Figure shows the BTS3012AE in full configuration.

Page 9 of 93
FFiigguurree22--66 BTS3012AE in full configuration

BTS3012/3012AE supports four frequency bands: 850 MHz, 900 MHz, 1800 MHz, and 1900
MHz. The following boards are the main boards of the BTS3012/3012AE: DTRU, DDPU,
DCOM, DFCU, DFCB, and DATU. The antennas mentioned below all refer to the dual
polarization antenna system.
Table 2-3 Configuration of the DDPU and DCOM in different combining modes
Cell TRX
S1 to S2
DTRU&DCOM
Combining
DTRU Combining
No Combining
DDPU
DCOM
DDPU
DCOM
DDPU
DCOM

Page 10 of 93

DTRU&DCOM
Combining
DTRU Combining
No Combining
DDPU
DCOM
DDPU
DCOM
DDPU
DCOM
S3 to S4
S5 to S6
S7 to S8
S9 to S10
S11 to S12
Cell TRX
Note:In the above table, each DDPU is configured with an antenna.

Table 2-4 Configuration principle of the DDPU and cavity in different combing mode
Cell TRX
DFCU+DDPU
DFCU (+DFCB)
DDPU
DFCU
DDPU
DFCU
DFCB
S1 to S2
S3 to S4
S5 to S6
S7 to S8
S9 to S10
S11 to S12
Note: In the above table, each cell is configured with an antenna.
The diagram for connection of S1, S3 and S4 configurations are shown below.

Page 11 of 93

S2
S3
ANTA
DPX
S4
ANTB
ANTA
DPX
RXDI
DPX
RXDI
RXDI
ANTB
ANTA
DPX
DPX
RXDI
RXDI
ANTB
DPX
RXDI
COM
COM
COM
COM
COM
TRX4
TRX3
TRX2
TRX1
TRX4
TRX3
TRX2
TRX1
TRX2
TRX1
FFiigguurree22--77 The S1, S3 and S4, DTRU is 40w configurations
2.1.3 BTS3012/3012AE Feature Configurations

80 W PBT and Four-Way Diversity Configuration
The following figure shows the configuration to achieve a transmit power of 80 W by using
the PBT and the configuration to increase uplink coverage by using the four-way diversity
mechanism.

Page 12 of 93

S2
ANT1DP ANT2D 80W
X
PX
DPX
ANT1DP ANT2DP
X
X
DPX
RXDI
DPX
RXDI
DPX
RXDI
ANT3DP ANT4DP
X
X
DPX
RXDI
DPX
RXDI
S4
80W
4way
Diversity
RXDI
COM
COM
COM
COM
COM
COM
TRX4
TRX4
TRX3
TRX3
TRX2
TRX2
TRX1
TRX1
TRX2
TRX2
TRX1
TRX1
2.2 3900 Series BTS

The 3900 series BTS basically comprise the following three units:
The indoor baseband processing unit BBU3900
The indoor radio frequency unit RFU
The outdoor Remote Radio Unit (RRU)
Flexible combinations of the three units and auxiliary devices can provide different BTS that apply to different
scenarios such as indoor centralized installation, outdoor centralized installation, outdoor distributed installation,
site sharing of multiple network systems, and multi-mode application.

Page 13 of 93
FFiigguurree22--88 Units and auxiliary devices of the 3900 series BTS

Page 14 of 93
FFiigguurree22--99 Application scenarios of the 3900 series BTSs

Different combinations of the units and auxiliary devices form the following 3900 series BTSs:
Cabinet macro BTS
The cabinet macro BTS, integrating the BBU3900 and the DRFU/GRFU, consists of the indoor BTS3900
and the outdoor BTS3900A. The cabinet macro BTS applies to centralized installation, where the BTS3900
and the BTS3900A, as mentioned above, are recommended for indoor application and outdoor application
respectively.
Distributed BTS
The distributed BTS, known as the DBS3900, consists of the BBU3900 and the RRU3004/RRU3008. For
the distributed installation, the RRU is placed close to the antenna. This can reduce feeder loss and improve
BTS performance.
2.2.1 3900 Series BTS Basic Module Configuration

The 3900 series BTS consists of the BBU3900 and RF unit (RRU or RFU).
The BBU3900 is an indoor base band unit. The maximum is 1 BBU3900 in one BTS. It is used for all 3900
series GSM BTS products. The BBU3900 consists of the boards for control, switching and Abis
transmission interface functionalities. All the boards support the plug-and-play function.
The BBU3900, powered with 48 V/ 24V DC, provides environmental protection and cooling functions. It
has FE and E1 connections for the Abis interface, for 6 optical CPRI links, and for up to 16 external alarms.
The BBU3900 is 19 inch wide and 2 U high. It can be installed on the floor, on the wall, or mounted in a
19-inch rack.

Page 15 of 93

BBU3900 subrack is composed of power and environment interface unit and universal BBU fan unit. These
units are plug in a backplane of the subrack.
The BBU3900 also provides 8 slots for GTMU, UTRPb4, USCU. Every slot of BBU subrack supports to
plug in several kinds of board flexibly.
FFiigguurree22--1100 Structure of the BBU3900 Subrack

One GTMU is mandatory configuration. Others such as UTRPb4 are optional depended on requirements.
Table 2-5 Configuration principles of BBU3900 GO boards
Board Name
Optional/Mandatory Maximum
Quantity
Slot
Configuration Restriction
GTMU
Mandatory
Slots 5 and 6
Configured only in slot 6 (both slots 5

and 6 are occupied)
FAN
Mandatory
Slot 16
Configured only in slot 16
UPEU
Mandatory
Slot 18 or 19
Preferentially configured in slot 19 in

the case of only one UPEU
USCU
Optional
Slot 0 or 1
Preferentially configured in slot 1

Configured in slot 1 in the case of 1U
dual-satellite-card (slot 0 is also
occupied)
UTRPb4
Optional
Slot 0 or 4
UEIU
Optional
Slot 18
UTRPc
Optional
Slot 0 or 4
GTMU
GSM Transmission & Timing & Management Unit for BBU (GTMU) is the basic transmission and control
function entity for the BBU and provides reference clock, power monitoring, maintenance interfaces, and
external alarm collection interfaces to control and manage BTSs.
UTRPb4
UTRPb4 provides four extended GSM E1/T1 interfaces in TDM and is available in GBSS12.0 and later versions.

Page 16 of 93
UTRPc
UTRPc provides four electrical FE/GE interfaces and two optical FE/GE interfaces in GBSS14.0 and later
versions.
RF Unit Configurations (RFU)

For cabinet BTS BTS3900, BTS3900A and BTS3900L, the RF module is RFU.
Depending on the number of supported TRXs, RFU modules are classified into double-transceiver and multicarrier RFU modules.
DRFU: double-transceiver RFU module, which supports a maximum of two TRXs and is available in
GBSS8.0 and later versions. In a cell, one pair of dual-polarized antennas is configured and two DRFUs
are interconnected. Therefore, a maximum of four TRXs are supported in a cell.
GRFU: multi-carrier RFU module (1T2R), which supports a maximum of six TRXs and is available in
GBSS8.1 and later versions. In a cell, one pair of dual-polarized antennas is configured and two GRFUs
are interconnected. Therefore, a maximum of twelve TRXs are supported in a cell.
RF Unit Configurations (RRU)

For distributed BTS, the RF module is RRU.
Depending on the number of supported TRXs, RRU modules are classified into double-transceiver and multicarrier RFU modules.
RRU3004: double-transceiver RRU module, which supports a maximum of two TRXs and is available
in GBSS8.0 and later versions. In a cell, one pair of dual-polarized antennas is configured and two
RRU3004 modules are interconnected. Therefore, a maximum of four TRXs are supported in a cell.
RRU3008: multi-carrier RRU module (2T2R), which supports a maximum of eight TRXs. RRU3008 is
classified into RRU3008 V1 and RRU3008 V2. RRU3008 V1 is available in GBSS8.0 and later
versions, while RRU3008 V2 is available in GBSS9.0 and later versions. In a cell, one pair of dualpolarized antennas and one RRU3008 are configured. Therefore, a maximum of eight TRXs are
supported in a cell.
If the BBU3900 is configured with RRU3004, each BBU3900 supports a maximum of 36 carriers. If the
BBU3900 is configured with RRU3008, each BBU3900 supports a maximum of 72 carriers.
2.2.2 3900 Series BTS Typical Configurations

BTS3900
If the BBU and RFU are housed in an indoor cabinet, they form a BTS3900. The following
figure shows the BTS3900 (-48V DC).

Page 17 of 93
Step 1 BTS3900 (-48V DC) in full configuration

The following typical configurations are applied to BTS3900 sites which are implemented by
V1 GRFUs or V2 GRFUs.
The BTS3900 is configured with an indoor macro cabinet, a BBU, a GTMU, and an RFU in
minimum configuration. The capacity of the BTS3900 can be smoothly expanded through
addition of licenses, RFUs, and an indoor macro cabinet.
When DRFUs are configured in the BTS3900, the CPRI ports on the GTMU in the BTS3900
support a maximum of 36 TRXs. The capacity of the BTS3900 can be smoothly expanded
from S1/1/1 to S12/12/12. The table lists the typical configurations of the BTS3900 with
DRFUs.
Table 2-6 Typical configurations when BTS3900 GSM uses the DRFU
GSM
Configura
tions
S1/1/1
S2/2/2
S3/3/3
S4/4/4
S4/4/4
S6/6/6
S8/8/8
(in Noncombinin
g Mode)
(in Noncombinin
g Mode)
(in
Combinin
g Mode)
(in
Combinin
g Mode)
(in Noncombinin
g Mode)
(in
Combinin
g Mode)
(in
Combinin
g Mode)
Cabinet
BBU
GTMU
DRFU
12
Dual
Transceiver
(Per TRX)
12
Antenna
system

Page 18 of 93
Table 2-7 Typical configurations when BTS3900 GSM uses the GRFU
GSM
Configuration
S1/1/1
S2/2/2
S3/3/3
S4/4/4
S6/6/6
S8/8/8
Cabinet
BBU
GTMU
GRFU
Multiple Transceiver
(Per TRX)
15
18
Antenna system
BTS3900A
If the BBU3900 is housed in APM30 or TMC, RFU module is housed in outdoor RF cabinet,
they form a GSM BTS3900A.

Page 19 of 93

FFiigguurree22--1111 BTS3900A in full configuration
The following typical configurations are applied to BTS3900A sites which are implemented
by V1 GRFUs or V2 GRFUs.
The BTS3900A is configured with an APM30H cabinet, an RF cabinet, a BBU, a GTMU, and
an RFU in minimum configuration. The capacity of the BTS3900A can be smoothly expanded
through addition of licenses, RFUs, and APM30H cabinets, RF cabinets.
When DRFUs are configured in the BTS3900A, the CPRI ports on the GTMU in the
BTS3900 support a maximum of 36 TRXs. The capacity of the BTS3900A can be smoothly
expanded from S1/1/1 to S12/12/12. The table lists the typical configurations of the
BTS3900A with DRFUs.
Table 2-8 Typical configurations when BTS3900A GSM uses the DRFU
GSM
Configura
tions
S1/1/1
S2/2/2
S3/3/3
S4/4/4
S4/4/4
S6/6/6
S8/8/8
(in Noncombinin
g Mode)
(in Noncombinin
g Mode)
(in
Combinin
g Mode)
(in
Combinin
g Mode)
(in Noncombinin
g Mode)
(in
Combinin
g Mode)
(in
Combinin
g Mode)
Cabinet
BBU
GTMU
DRFU
12
Dual
Transceiver
(Per TRX)
12
Antenna
system
Table 2-9 Typical configurations when BTS3900A GSM uses the GRFU
GSM
Configuration
S1/1/1
S2/2/2
S3/3/3
S4/4/4
S6/6/6
S8/8/8
Cabinet
BBU
GTMU
GRFU
(Per TRX)
15
18
Antenna system

Page 20 of 93
BTS3900L
The BTS3900L is configured with an indoor macro cabinet, a BBU, a GTMU, and an RFU in
minimum configuration. The capacity of the BTS3900L can be smoothly expanded through
addition of licenses, and RFUs.
When DRFUs are configured in the BTS3900L. The capacity of the BTS3900L can be
smoothly expanded from S1/1/1 to S8/8/8.
Table 2-10 Typical configurations when BTS3900L GSM uses the DRFU
GSM
Configura
tions
S1/1/1
S2/2/2
S3/3/3
S4/4/4
S4/4/4
S6/6/6
S8/8/8
(in Noncombinin
g Mode)
(in Noncombinin
g Mode)
(in
Combinin
g Mode)
(in
Combinin
g Mode)
(in Noncombinin
g Mode)
(in
Combinin
g Mode)
(in
Combinin
g Mode)
Cabinet
BBU
GTMU
DRFU
12
Dual
Transceiver
(Per TRX)
12
Antenna
system
Table 2-11 Typical configurations when BTS3900L GSM uses the GRFU
GSM
Configuration
S1/1/1
S2/2/2
S3/3/3
S4/4/4
S6/6/6
S8/8/8
Cabinet
BBU
GTMU
GRFU
(Per TRX)
15
18
Antenna system
BTS3900AL
The BTS3900AL is configured with an outdoor macro cabinet, a BBU, a GTMU, and an RFU
in minimum configuration. The capacity of the BTS3900AL can be smoothly expanded
through addition of licenses, and RFUs.

Page 21 of 93

Table 2-12 Typical configurations when BTS3900AL GSM uses the GRFU
GSM
Configuration
S1/1/1
S2/2/2
S3/3/3
S4/4/4
S6/6/6
S8/8/8
Cabinet
BBU
GTMU
GRFU
(Per TRX)
15
18
Antenna system
DBS3900
The BBU and RRU are the main parts of DBS3900. The two units support independent
installation, capacity expansion, and evolution, thus meeting the requirements of GSM
network construction. The two units can be connected by electrical or optical cables through
the CPRI interface, thus facilitating site acquisition, device transportation, equipment room
construction, and equipment installation.
Table 2-13 Typical configurations when DBS3900 GSM uses the RRU3004
GSM
Configura
tion
S1/1/1
S2/2/2
S3/3/3
S4/4/4
S4/4/4
S6/6/6
S8/8/8
in Noncombinin
g Mode
in Noncombinin
g Mode
in
Combinin
g Mode
in
Combinin
g Mode
in Noncombinin
g Mode
in
Combinin
g Mode
in
Combini
ng Mode
Cabinet
(optional)
BBU
RRU3004
12
Dual
Transceiver
(Per TRX)
12
Antenna
system
Table 2-14 Typical configurations when DBS3900 GSM uses the RRU3008 module
GSM
Configuration
S1/1/1
S2/2/2
S3/3/3
S4/4/4
S6/6/6
S8/8/8
Cabinet (optional)

Page 22 of 93

GSM
Configuration
S1/1/1
S2/2/2
S3/3/3
S4/4/4
S6/6/6
S8/8/8
BBU
RRU3008
(Per TRX)
15
18
Antenna system
2.2.3 3900 Series BTS Feature Configurations

PBT Configuration
Currently, only DRFU and RRU3004 modules support power boost technology (PBT). The PBT configurations
are as follows:
Table 2-15 PBT configurations
Number of TRXs in a Cell
Number of DRFU and

RRU3004 Modules
Number of Antennas
1 TRX
2 TRXs
Transmit Diversity Configuration

Currently, only DRFU, RRU3004, and RRU3008 modules support transmit diversity. The transmit diversity
configurations are as follows:
Table 2-16 Transmit diversity configurations for DRFU and RRU3004
Number of DRFU and

RRU3004 Modules
Number of Antennas
1 TRX
2 TRXs
Table 2-17 Transmit diversity configurations for RRU3008

Number of RRU3008
Modules
Number of Antennas

Maximum Power
Configuration (Using
RRU3008 V2 Modules as
an Example)
Page 23 of 93
Number of RRU3008
Modules
Number of Antennas
Maximum Power
Configuration (Using
RRU3008 V2 Modules as
an Example)
1 TRX
40 W
2 TRXs
20 W
3 TRXs
13 W
4 TRXs
10 W
Inter-Module RF FH Configuration
Two GRFU modules need to be configured if inter-module RF FH is enabled. Two GRFU modules in a cell
support a maximum of six TRXs, not twelve TRXs. The transmit power must be configured as follows (Using
GRFU V2 as an example):
Table 2-18 Inter-module RF FH configurations
Number of TRXs Supported by Two GRFU Modules
Transmit Power with InterModule RF FH Disabled

(Even Distribution of
Carriers on Each Module)
Transmit Power with InterModule RF FH Enabled
2 TRXs
60 W
40 W
3 TRXs
40 W
27 W
4 TRXs
40 W
20 W
5 TRXs
27 W
16 W
6 TRXs
27 W
12 W
2.3 GSM Network Dimensioning

2.3.1 Introduction
The radio network dimensioning is the process of obtaining the network capacity including the number of
BTSs and configuration of each BTS. The network dimensioning is based on the following information
provided by the operators: coverage objective, subscriber scale, service ratio, and quality requirement. The
network dimensioning result is closely related to the investment of the customer. The result also determines
whether the network meets the operator's expectation. Therefore, the purpose of the radio network
dimensioning is to obtain the appropriate network scale under the condition that the operator's expected
coverage, capacity, and quality are all met.

Page 24 of 93

FFiigguurree22--1122 Radio network dimensioning process
2.4 GSM Link Budget Procedure

2.4.1 Introduction
Link budget dimensioning is used to obtain cell coverage range. After calculating allowed maximum path
losses on the uplink and downlink, you can calculate the maximum coverage distance on the uplink and
downlink by selecting a proper propagation model. For tasks, users need to define the gains and losses to
calculate the final path loss.

Page 25 of 93

FFiigguurree22--1133 Coverage dimensioning procedure
Analyze coverage
requirements
Create link budgets

Maximum path loss
Obtain the cell radius
Maximum cell radius
Calculate the coverage area
for a BTS
Maximum BTS coverage area
Specify the number of BTSs
within areas
For details about uplink budget dimensioning, see section 2.4.2 "Uplink Budget Dimensioning."
For details about downlink budget dimensioning, see section 2.4.3 "Downlink Budget Dimensioning."
For details about uplink/downlink budget balance dimensioning, see section 2.4.4 "Uplink/Downlink Budget
Balance Dimensioning."
2.4.2 Uplink Budget Dimensioning

1.
Uplink budget dimensioning is used to obtain the maximum path loss on the uplink (PL_UL).
2.
The formula for calculating the maximum path loss on the uplink (PL_UL) is as follows:
PL_UL= PoutMS - LfMS + GaMS - LcLb + Ga_BTS + Gdb - LfBTS - Ljb_BTS - RsBTS - PSur
where
PL_UL is the loss of uplink maximum transmission path
PoutMS is the MS power
Lf_MS is the MS feeder loss

Page 26 of 93

Ga_MS is the MS antenna gain
Lc is the clutter loss
Lb is the body loss
Ga_BTS is the BTS antenna gain
Gdb is the diversity gain
Lf_BTS is the loss of BTS feeder
Ljb is the jumper loss
Rs_BTS is the BTS receiver sensitivity
P_Sur is the fading margin
2.4.3 Downlink Budget Dimensioning

Downlink budget dimensioning is used to obtain the maximum path loss on the downlink (PL_DL).
1.
The formula for calculating the maximum path loss on the uplink (PL_DL) is as follows:
PL_DL = Pout_BTS + Gdivd - Ljb_BTS - Lcb_BTS - Lf_BTS + Ga_BTS - Lc - Lb + Ga_MS - Lf_MS - Rs_MS - PSur
PL_DL is the loss of downlink maximum transmission path
Pout_BTS is the BTS max. transmit power
Gdivd is the TD gain
Ljb is the jumper loss
Lcb_BTS is the BTS combiner loss
Lf_BTS is the BTS feeder loss
Ga_BTS is the BTS antenna gain
Lc is the clutter loss
Lb is the body loss
Ga_MS is the MS antenna gain
Lf_MS is the MS feeder loss
Rs_MS is the MS receiver sensitivity
P_Sur is the fading margin
2.4.4 Uplink/Downlink Budget Balance Dimensioning

When the uplink and downlink budgets are balanced, the maximum allowed path loss on the downlink must
be equal to the maximum allowed path loss on the uplink.
1.
Calculating the cell radius
According to the maximum path loss, calculate the cell radius using the propagation model.
Following lists common propagation models:
Free space propagation model
Okumura/Hata model

Page 27 of 93

COST231-Hata model
COST231 Walfish-Ikegami model
Keenan-Motley model
Computer-assisted calculation model
SPM
Okumura/Hata models are widely applied.
2.
Calculating coverage area for a single BTS

The formula for calculating coverage area (km2) for a single BTS is as follows:
3
2
6Sector
2 3 Cell radius Omni
3 3
BTS coveragearea
Cell radius 2
2Sector
4
9
2
3Sector
8 3 Cell radius
3.
Calculating the number of BTSs
Number of BTSs
Coveragearea
BTS coveragearea
2.5 GPRS/EDGE Coverage Dimensioning

2.5.1 Introduction
8 phase shift keying (8PSK) has a higher peak-to-average ratio than Gaussian minimum shift-frequency
keying (GMSK). The output power for multiple modules in GMSK and 8PSK modes is different. As a
result, equivalent isotropically radiated power (EIRP) is different.
The transmitter and receiver experience the same losses except their own body losses.
The receiver sensitivity is not the key point, GPRS/EDGE services are mainly restricted by the carrier-tointerference (C/I) ratio.
2.6 GSM Capacity Dimensioning Procedure

2.6.1 Introduction
As the second-generation mobile communication system, Global System for Mobile
Communications (GSM) has been widely applied around world. With the development of mobile
communication technology and service diversification, there are increasing demands for data
services, and therefore capacity dimensioning becomes more important than before.

Page 28 of 93

FFiigguurree22--1144 Capacity dimensioning procedure
Capacity dimensioning
Analyze traffic distribution
Determine the site type and

channel configuration
Determine the channel type

and number of TRXs
Plan LAC areas
For details about capacity dimensioning, see section 2.6.2 "Capacity Dimensioning."
For details about traffic analysis, see section 2.6.3 "Traffic Analysis."
For details about calculation on the number of traffic channels, see section 2.6.4 "Calculation on the Number
of Traffic Channels."
For details about GPRS/EDGE capacity dimensioning, see section 2.6.5 "GPRS/EDGE/EGPRS2 Capacity
Dimensioning."
2.6.2 Capacity Dimensioning

Before planning a cellular network, you must determine system capacity requirement first, specifically, the
number of subscribers whose services need to be processed by the system and the traffic volume generated
by these subscribers. This provides a basis for engineering design of an entire cellular network.

Page 29 of 93

System capacity analysis aims at reflecting the actual and future capacity requirements to estimate the
number of channels required by the system. Based on capacity dimensioning duration, capacity
dimensioning is classified into short-term (one to two years) capacity dimensioning and long-term (three to
five years) capacity dimensioning.
2.6.3 Traffic Analysis

Generally, the following factors must be taken into account during traffic analysis:
1.
Urban population increase in future one or two years
2.
Congestion
3.
2G/3G traffic sharing and transfer, and 900/1800 MHz traffic sharing in 2G networks
4.
Roaming percentage
5.
Abruption percentage
6.
Others
2.6.4 Calculation on the Number of Traffic Channels

After half-rate is enabled, the proportion of subscribers supporting half-rate in the network has a great
impact on the network capacity, that is, the network capacity increases when the proportion of subscribers
supporting half-rate increases.
Assume that the number of TRXs for a cell is k and the number of available service timeslots is a. After
half-rate is enabled, this cell can provide a to 2a traffic channels. The proportion of calls supporting full-rate
in a cell is related to the traffic volume that can be increased after half-rate is enabled. Specifically, when the
proportion of calls supporting full-rate in a cell increases, the traffic volume that can be increased after halfrate is enabled decreases.
Assume that x full-rate timeslots need to be configured, x/(2a-x)=c%. The number of full-rate timeslots to
be configured is calculated by using the following formula: x = 2ac/(100 + c). The remaining timeslots can
be configured as half-rate channels.
According to traffic volume required in a cell and GOS requirements, query the number of traffic channels
from the ErlangB table.
2.6.5 GPRS/EDGE/EGPRS2 Capacity Dimensioning

Purpose: With the development of mobile communication technology and service diversification, there are
increasing demands for data services, and therefore the original data rate used by GSM networks cannot
meet the requirements for mobile data communications. The GPRS/EDGE technology is applied as a
transitive data communication technology between the second-generation mobile communication system
and the third-generation mobile communication system. The latest technology progress shows that EGPRS2
(enhanced data services) has been accepted by Tier-1 operators. Based on the GSM core network,
EDGE/EGPRS2 provides high-speed packet data transmission with a high-order modulation mode, a highprecision packet scheduling algorithm, and a quick correction mechanism. In GPRS/EDGE/EGPRS2
networks, radio channel capacity dimensioning aims at configuring an appropriate number of PDCHs to
provide mobile data services.
Page 30 of 93

FFiigguurree 22--1155 GPRS/EDGE/EGPRS2 capacity dimensioning procedure
Start
Calculate the IP bandwidth of each

PDCH for a service
Calculate the maximum number of

subscribers in a cell
Calculate total number of PDCHs
required by GPRS/EDGE/EGPRS2
services
Calculate the number of static PDCHs
performing data services
Calculate the number of dynamic

PDCHs performing data services
Calculate the number of static and

dynamic PDCHs performing
GPRS/EDGE/EGPRS2 services
End
The formula for calculating the traffic volume of each service for a subscriber during busy hours is as
follows:
Traffic volume of each

subscriber performing
data services during busy
hours
Bandwidth of each subscriber during busy hour (bit/s)

(considering the peak - to - average ratio)
bps
Bandwidth of each traffic vhannel (kbit/s)
The number of maximum subscribers in a cell can be calculated by using the iteration algorithm.

Page 31 of 93

FFiigguurree22--1166 Procedure for dimensioning the number of dynamic and static PDCHs to be
configured
Start
Maximum number of
subscribers in a cell
Traffic volume of a cell

performing CS services
Equivalent traffic
volume of data
services
Number of timeslots
occupied by CS
services (N1)
Total number of
timeslots occupied by
data services (N2)
N---Number
of available
timeslots in a
cell (N)
Number of static PDCHs

(N3) = N N1
Calculate the number of

dynamic PDCHs (N4)
End
The total number of PDCHs for data services is calculated as follows:

(1) Calculate the traffic volume of a cell that performing CS services by using the following formula:
Traffic volume of a cell that performs CS services = Maximum number of subscribers in a cell x Traffic
volume of a subscriber that performs CS services during busy hours
(2) Calculate the number of timeslots occupied by CS services (N1) by using the following formula:
N1 = ErlangB (Traffic volume of a cell performing CS services (erl), gos cs)/(1 + hs_tch_proportion)
hs_tch_proportion is the proportion of half-rate channels performing services.
(3) Calculate the total number of timeslots occupied by data services.

Page 32 of 93
a) When GPRS/EDGE/EGPRS2 channels are not shared:

According to the maximum number of subscribers in a cell calculated by iteration, calculate the
number of PDCHs required by GPRS, EDGE, and EGPRS2 services, that is, N_GPRS, N_EDGE,
and N_EGPRS2. Then, calculate the total number of timeslots occupied by data services by using
the following formula: Total number of timeslots occupied by data services (N2) = N_GPRS +
N_EDGE + N_EGPRS2
b)
When GPRS/EDGE/EGPRS2 channels are shared:
According to the maximum number of subscribers in a cell obtained from the iteration process, calculate the
total number of PDCHs required by GPRS, EDGE, and EGPRS2 services during the iteration process.
2.7 Abis Transmission Dimensioning

2.7.1 Abis Bandwidth Dimensioning
The Abis bandwidth dimensioning is used to dimension the link bandwidth requirements for a single site
based on the relevant parameters and obtain the number of TRXs carried on a single transmission resource
(E1/FE). The parameters are service bearer mode (TDM or IP), site type, channel configuration, and coding
mode.

Page 33 of 93
2.7.2 Abis over TDM

FFiigguurree22--1177 Procedure for dimensioning Abis transmission in TDM mode
Start

channels configured in a cell
Calculate the number of LAPD

links
Calculate the number of timeslots

performing services
Calculate the total number of

Abis timeslots
Calculate the number of TRXs

carried on an E1
End
1. Calculate the number of TRXs according to the site type.

2. Calculate the number of LAPD links.
The number of LAPD links in TDM mode is composed of the number of multiplexed LAPD
links and the number of 16 kbit/s LAPD signaling links.
(a) Number of CS timeslots (16 kbit/s): CS traffic channels
(b) Number of PS timeslots (16 kbit/s): number of PDCHs and coding mode for data
services
(c) Number of signaling timeslots (64 kbit/s)
(d) Total number of Abis timeslots (64 kbit/s)
i.
(Number of CS timeslots + Number of PS timeslots)/4 + Number of signaling
timeslots + Number of monitoring timeslots
3. Query the number of service timeslots from the relevant table.

Page 34 of 93
2.7.3 Abis over IP

FFiigguurree 22--1188 Procedure for dimensioning Abis transmission in IP mode
Start
Calculate the peak traffic

volume in each cell

LAPD links, number of CS
speech paths, and signaling
load
Calculate the bandwidth

required by each type of
service

TRXs carried on an E1
End
In IP transmission mode, the transmission on the Abis interface can be operated in FE/GE or E1/T1 mode.
Therefore, the total number of timeslots on the Abis interface can be calculated for FE/GE or E1/T1 mode.
IP MUX: multiple speech packets are multiplexed onto a packet for transmission, saving resources on the
Abis interface.
Local switching technology: internal loopback is performed on the point-to-point speech paths. BTS internal
loopback saves resources on the Abis interface.
IPHCcompress the IP/UDP header over PPP/MLPPP links, improves bandwidth utilization, saving
resources on the Abis interface.
1. Calculate the bandwidth of CS channels by using the following formula:
(1 Bandwidth resources saved by the calls processed on the BTS) x (Number of FR speech paths during
busy hours x Frame rate corresponding to FR coding mode + Number of HR speech paths during busy hours
x Frame rate corresponding to HR coding mode)
Calculate the bandwidth of PDCHs by using the following formula:

Page 35 of 93

Total number of PDCHs for a BTS x Maximum PS coding rate x PDCH usage for a BTS
When EDGE is enabled, the maximum PS coding rate is MCS-9. When GPRS is enabled but CS-3 and CS4 are not enabled, the maximum PS coding rate is CS-2. When CS-3 and CS-4 are enabled, the maximum
PS coding rate is CS-4.
3. Signaling bandwidth: Bandwidth required by CS channels x Signaling load
4. Calculate the total bandwidth on the Abis interface by using the following formula:
Total bandwidth on the Abis interface = (Bandwidth of CS channels + Bandwidth of PS channels +
Signaling bandwidth)/Bandwidth usage of transmission links
5. Calculate the total number of timeslots on the Abis interface by using the following formula:
Total number of timeslots on the Abis interface = Bandwidth on the Abis interface/64 kbit/s
2.8 Case Study

Case study of capacity will be described in details in this section for your easy understanding of the
dimensioning principles and procedures. To simplify the process, GPRS/EDGE/EDGESare not included
here.
1.
Assumptions
A local network will be constructed. After two years, the number of subscribers may attain 100,000.
Provide that the traffic per subscriber is 0.02Erl, 120 BTSs are required, and the call loss rate is 2%.
Subscriber quantity: 100,000
Call loss rate: 2%
Traffic model: 0.02Erl
Number of BTSs: 120

2.
Procedures
Roaming factor (traffic and developing trend): 10%; dynamic factor (burst traffic): 15%
Network capacity: 10 x (1 + 10% + 15%) = 125000
In terms of congestion, use 85% to calculate the bearer capability for traffic. Therefore, the design
capacity of network is: 12.5/(85%)=147100, that is 150000.
According to the provided traffic model, that is average 0.02Erl traffic, forecast the busy-hour traffic of
the whole network: 150000 x 0.02 = 3000Erl.
The average traffic per BTS is: 3000/120=15Erl, average traffic per cell: 15/3=5Erl.
Based on 2% call loss rate, query the Erlang-B to find the number of voice channels: 10 channels/every
cell
The number of control channels: 12 channels/every cell, 2TRX/every cell

Page 36 of 93
2.9 Counters Related to Capacity

There are following main counters (not limited to) related to capacity which will help you to better understand
your networks status.
Traffic related
CELL.KPI.TCH.TRAF.ERL.TRAF
CELL.KPI.TCH.AVAIL.NUM
Base band resources: MS related
CELL.SPT.PHASEI.CALL.NUM
CELL.SPT.PHASEII.CALL.NUM
VS.LC.DLMean.LicenseGroup.Shared
CELL.SPT.R99LATER.CALL.NUM
CELL.SPT.CECS.CALL.NUM
CELL.SPT.VBS.RCPT.CALL.NUM
CELL.SPT.VGCS.RCPT.CALL.NUM
CELL.SPT.DTM.CALL.NUM
CELL.SPT.VAMOS1.CALL.NUM
CELL.SPT.VAMOS2.CALL.NUM
RF resources: TRX
CELL.TRX.CFG.NUM
CELL.TRX.CFG.AVAIL.NUM
RF resources: Power related
TRX.PWR.ADJUST.OFF.DUR
TRX.TS.PWR.ADJUST.OFF.TIMES
Abis resources related
BS.RES.USE.ABIS.AVG
BS.RES.FLTTS.ABIS.TIME
LAPDLNK.DISC.SMS.PAGS
LAPDLNK.DISC.CS.PAGS

Page 37 of 93
LAPDLNK.DISC.PS.PAGS
VS.IPPM.Bits.MeansTx
VS.IPPM.Peak.Bits.RateTx
VS.IPPM.Peer.Bits.MeansRx
VS.IPPM.Peer.Peak.Bits.RateRx

Page 38 of 93
BSC
3.1 Configurations Standards of BSC6900

3.1.1 Evolution of BSC6000 to BSC6900
GBSS14.0 is supported by GSM BSC6900.
The BSC6900 is Huawei multi-mode BSC. The BSC6900 can be flexibly configured as a BSC6900 GSM,
BSC6900 UMTS, or BSC6900 GU mode as required in different networks. The BSC6900 GSM is compatible
with the hardware configuration of the BSC6000. Through software loading, the BSC6000 in the existing
network can be upgraded to the BSC6900 GSM.
Following is the compare of BSC6000 to BSC6900.
1) BSC6000 can be upgraded to BSC6900 with only software upgrade without hardware change.
2) Naming changes
BSC
BSC6000
BSC6900
Main Process Subrack
GMPS
MPS
Extended Subrack
GEPS
EPS
3) New boards are introduced while legacy boards are compatible .

User Plane
DPUc -> DPUf
DPUd->DPUg
Control Plane
XPUa -> XPUb
Transmission
Transport
BSC6900

BSC6810&BSC6900
Page 39 of 93

Board
Ports
Board
Ports
IP
FG2c
12 FE / 4 GE electrical
FG2a
8/2
IP
GOUc
4 GE optical
GOUa
IP over E1/T1
POUc
4 optical cSTM-1/OC-3
OIUa
The BSC6900 supports following hardware versions. The boards of HW68 R11 are the same as boards used in
BSC6810.
Hardware Version
Corresponding Board
DPUc, DPUd, XPUa, SCUa, TNUa, GCUa, OMUb, EIUa,
HW60 R8
FG2a, GOUa, OIUa, and PEUa

HW69 R11
DPUc, DPUd, XPUb, SCUa, TNUa, GCUa, GCGa, OMUa,

EIUa, FG2c, GOUc, OIUa, PEUa, POUc
HW69 R13
DPUf, DPUg, XPUb, SCUb, TNUa, GCUa, GCGa, OMUc,

EIUa, FG2c, GOUc, PEUa, POUc, SAUc
HW69 R14
NIUa
The HW69R11 hardware is launched from GBSS9.0, and GBSS12.0 use HW69 R11 hardware default.
The HW69R13 hardware is launched from GBSS13.0. DPUf, DPUg, SCUb and OMUc are new boards from
GBSS13.0. And SAU board will be configured by BSC(SAUc is used as SAU board now.)
The HW69R14 hardware is launched from GBSS14.0. NIUa is new board from GBSS14.0..
3.1.2 BSC6900 Hardware Architecture
Classification of BSC6900 GSM cabinets:

Cabinet
MPR
Contained Subrack
1 MPS, 02 EPSs Per
Configuration Principle
Only one MPR is configured.

Page 40 of 93

MPR
EPR
1 EPS Per EPR
Based on the requirement for traffic capacity,

01 EPR is configured.
TCR
1-3 TCS Per TCR, Max

4 TCS for one BSC
Based on the requirement for traffic capacity,

02 EPR is configured.
Classification of BSC6900 GSM subracks:

Subrack
Quantity
Function
MPS
The MPS performs centralized switching and

provides service paths for other subracks. It
also provides the service processing interface,
OM interface, and system clock interface.
EPS
0-3
The EPS performs the functions of user plane

processing and signaling control.
In MPS, 8 slots for Rear side can be used for processing board and interface boards and 10 slots for front side can be used for
only processing boards.
In EPS, 14 slots for Rear side can be used for processing board and interface boards and 10 slots for front side can be used for
only processing boards.
Note:
Two boards working as an active/standby pair must be the same. If a single-core board in a slot is to be replaced with a
multi-core board, you must remove the single-core board and add the multi-core board in the configuration data.
Under BSC6900 GSM, some UMTS boards can work in GSM-only mode, but GSM boards cannot work in UMTS mode.
SPUa boards can be used in place of XPUa boards and provide the same specifications.
SPUb boards can be used in place of XPUb boards and provide the same specifications.
DPUb boards can be used in place of DPUc boards and provide the same specifications.
DPUb boards can be used in place of DPUd boards and provide the same specifications.
3.1.3 BSC6900 Basic Models

1. The BSC6900 GSM supports 6 basic models as follows when HW60 R8 boards are used.
Model Name
Model
Configuration Description
BSC6000/6900 Model
256
GMIP00M25600 When the TRXNoPerBSC is in the range of 1

256, select this model.
BSC6000/6900 Model
512


Page 41 of 93

Model Name
Model
BSC6000/6900 Model
768
GMIP00M76800 When the TRXNoPerBSC is in the range of 513768, select this model.
BSC6000/6900 Model
1280

BSC6000/6900 Model
1536
GMIP0M153600 When the TRXNoPerBSC is in the range of

BSC6000/6900 Model
2048
GMIP0M204800 When the TRXNoPerBSC is in the range of

2. In GBSS12.0 The BSC6900 GSM supports 7 basic models as follows when HW69 R11 boards are used.
Model Name
BSC6900 GSM
Model 640
BSC6900 GSM
Model 1280
BSC6900 GSM
Model 1920
BSC6900 GSM
Model 2560
BSC6900 GSM
Model 3072
BSC6900 GSM
Model 3584
BSC6900 GSM
Model 4096
Model
GMIP00M64000 When the TRXNoPerBSC is in the range of 1-640,

select this model.
3. In GBSS13.0 and GBSS14.0 The BSC6900 GSM use flexible configuration do no have basic model only MPS
and EPS when HW69 R13 boards are used. And how many XPUb boards are needed depends on the TRX
number and BHCA requirement.
The different between Basic model(HW60 R8/HW69 R11) and flexible configuration is that Basic
model define the XPU number and Subrack number by default, And flexible configuration do not define.
When flexible , how many subrack we need depends on the number of boards need to be configured.
Note:
1. The BSC6900 GSM specification is as below when HW69 R13 boards are used. The HW69 R13 hardware is
introduced from V900R013 software version.

Page 42 of 93

Specifications of the BSC6900 GSM that adopts GBSS12.0 and GBSS13.0
Performance
Specifications
Maximum traffic volume (Erl): 24000

Maximum overall Busy Hour Call Attempts* (BHCA) 5, 900, 000
Maximum number of TRXs: 4096
Maximum number of base stations: 2048
Maximum number of CIC circuits over the A interface: 30720
Maximum number of CIC circuits supported by a single TC subrack in a TC pool:
38400
Maximum number of E1 ports over the Abis interface: 640
Maximum number of packet data channels (PDCHs): 30720
Number of active PDCHs: 16384
Traffic over the Gb interface: 1536 Mbit/s
Maximum total number of XPUa and XPUb boards 14 pairs
Maximum number of BM subracks: 4
Maximum number of TC subracks:4
*In the Huawei traffic model, the reference BHCA involving only voice calls is 1, 440, 000.
GBSS14.0s Specification is the same as GBSS13.0 when the BSC type is not all IP .
When GBSS14.0 use type of all IP , the Specifications would be below :
Specifications of the BSC6900 GSM that adopts GBSS14.0 all IP

Performance
Specifications
Maximum traffic volume (Erl):45000

Maximum overall Busy Hour Call Attempts* (BHCA) 11,000, 000
Maximum number of TRXs: 8192
Maximum number of base stations: 2048
Maximum number of CIC circuits over the A interface: 61440
Maximum number of CIC circuits supported by a single TC subrack in a TC pool:
38400
Maximum number of packet data channels (PDCHs): 61440
Number of active PDCHs: 32768
Traffic over the Gb interface: 3072 Mbit/s
Maximum total number of XPUa and XPUb boards 20 pairs / 4 pairs extra for IBCA
Maximum number of BM subracks: 4
The hardware configuration procedure is as follows:

(1) Obtain the traffic model, network parameters (number of MSs, number of BTSs, and
number of cells), and interface requirements of the operator's network.
(2) Perform network dimensioning to obtain the user plane requirements (PS throughput and
CS Erlang), control plane requirements (BHCAs), and interface requirements.

Page 43 of 93

(3) Determine hardware configurations according to the network requirements.
a. Calculate the number of required data processing units and hardware capacity licenses
based on the user plane requirements (PS throughput and CS Erlang), number of cells, and
processing capability of one data processing unit.
b. Calculate the number of required signaling processing units based on the control plane
requirements (BHCAs), number of BTS, number of cells.
c. Calculate the number of interface boards required on each interface based on the CIC
requirement, PS throughput requirement, transmission type, port requirement, number of BTS,
and TRX number on the interface.
d. Calculate the number of required subracks based on the number of data processing units,
number of signaling processing units, and number of interface boards.
e. Calculate the number of required cabinets based on the number of subracks.

Page 44 of 93
3.2 BSC Service Processing Units Dimensioning

3.2.1 Service processing units
Table 3-1 Service processing units
Name
Description
Function
Description
Specification
Condition
WP1D000DPU02
CS Data Processing Unit

(960CIC/3740 IWF)
Provides CS
service
processing
(including the
TC function
and IWF
function) and
works in N+1
backup mode
TC function: 960
CIC circuits (A
over TDM)
For the TC
function, the left
column lists the
specifications of
WP1D000DPU02
when nonwideband AMR
coding schemes
are used. When
wideband AMR
coding schemes
are used, the
specifications of
WP1D000DPU05
are 370CIC of
those listed in the
left column.
IWF function:
3740 channels
For the IWF

function, the
specifications of
WP1D000DPU02
remain unchanged
regardless of
whether nonwideband or
wideband AMR
coding schemes
are used. This is
because TC
coding is not
involved in the
IWF function.
WP1D000DPU01
PS Data Processing Unit (1024

PDCH)
Provides PS
service
processing
and works in
N+1 backup
mode
1024 activated
PDCHs

The specifications
remain unchanged
regardless of the
coding schemes
(CS1 to CS4,
MCS1 to MCS9,
and EDGE+).
Page 45 of 93

WP1D000DPU05
CS Data Processing Unit

(1920CIC/3840
IWF(TDM&IP)/7680IWF(IP&IP))
Provides CS
service
processing
(including the
TC function
and IWF
function) and
works in N+1
backup mode
TC function:
1920 CIC
circuits (A over
TDM)
IWF function:
3840 channels
(Abis over IP
and Ater over
TDM, or Abis
over TDM and A
over IP)
7680 CIC
circuits (Abis
over IP and A
over IP)
For the TC
function, the left
column lists the
specifications of
WP1D000DPU05
when nonwideband AMR
coding schemes
are used. When
wideband AMR
coding schemes
are used, the
specifications of
WP1D000DPU05
are 960CIC of
those listed in the
left column.
For the IWF
function, the
specifications of
WP1D000DPU05
remain unchanged
regardless of
whether nonwideband or
wideband AMR
coding schemes
are used. This is
because TC
coding is not
involved in the
IWF function.
WP1D000DPU06
PS Data Processing Unit (1024

PDCH)
Provides PS
service
processing
and works in
N+1 backup
mode
1024 activated
PDCHs
The specifications
remain unchanged
regardless of the
coding schemes
(CS1 to CS4,
MCS1 to MCS9,
and EDGE+).
WP1D000XPU01
Extended Processing Unit (640)
Provides
signaling
processing
and works in
active/standby
mode
1,050,000
BHCA
The BHCA is
based on Huawei
default traffic
model.
640 TRXs
640 Cells
640 BTSs
3.2.2 Configuration principles of Service processing units

Page 46 of 93

Configuration principles of WP1D000DPU05/ WP1D000DPU02:
The number of DPUf/DPUc to be configured depends on the number of required CIC circuits.
The boards can work in N+1 backup mode.
1. In BM/TC separated configuration mode (or TDM/IP hybrid transmission in A over IP)
On the BM side:
The number of WP1D000DPU05s to be configured depends on the number of CIC circuits
that require IWF conversion between TDM and IP and between IP and IP.
If DPUf is used:
Number of DPUf= ROUNDUP(MaxIWFPerBSCTDMIP/3840 + MaxIWFPerBSCIPIP/7680)
+1
If DPUc is used:
Number of DPUc= ROUNDUP(MaxIWFPerBSCTDMIP/3740)+1
On the TC side:
If DPUf is used:
Number of DPUf = ROUNDUP(MaxACICPerBSCTDM/1920) + 1
If DPUc is used:
Number of DPUc= ROUNDUP(MaxACICPerBSCTDM/960) + 1
2. In BM/TC combined configuration mode (or TDM/IP hybrid transmission in A over IP)
The DPUc/DPUf providing the TC function can support the IWF function of the same
specifications as DPUc/DPUf.
Extra DPUc/DPUf s should be configured to provide the IWF function for the A-interface
CIC circuits in A over IP transmission.
If DPUf is used:
Number of DPUf = ROUNDUP(MaxACICPerBSCTDM/1920) +
ROUNDUP(MAXIWFPerBSCTDMIP/3840 + MAXIWFPerBSCIPIP/7680) + 1
If DPUc is used:
Number of DPUc = ROUNDUP(MaxACICPerBSCTDM/960) +
ROUNDUP(MAXIWFPerBSC/3740) + 1
3. A over IP:
The number of DPUc/DPUf to be configured depends on the number of CIC circuits that
require IWF conversion between TDM and IP and between IP and IP.
If DPUf is used:
Number of DPUf = ROUNDUP(MaxACICPerBSCTDM/1920) +
ROUNDUP(MAXIWFPerBSCTDMIP/3840 + MAXIWFPerBSCIPIP/7680) + 1
If DPUc is used:

Page 47 of 93

Number of DPUc = ROUNDUP(MaxACICPerBSCTDM/960) +
ROUNDUP(MAXIWFPerBSC/3740) + 1
4. IP transmission on all interfaces of the BSC6900 GSM

If DPUf is used:
Number of DPUf = ROUNDUP(MaxACICPerBSCIP/7680) + 1
If DPUc is used:
Number of DPUc = ROUNDUP(MaxACICPerBSCIP/3740) + 1
Configuration principles of DPUd/DPUg:

The following table describes the network requirements that should be considered during the
configuration of DPUd/DPUg
Item
Description
Remarks
MaxActivePDCHPerBSC
Maximum number of activated PDCHs
Calculated based on the number of

users and the traffic model
DPUd and DPUg are the same in capacity.

If the PS function is configured, the number of DPUd/DPUg to be configured depends on the
number of activated PDCHs that are configured. DPUd/DPUg can work in N+1 backup mode.
Number of DPUd/DPUg = ROUNDUP(MaxActivePDCHPerBSC/1024, 0) + 1
The following table describes the network requirements that should be considered
during the configuration of WP1D000XPU01.
Item
Description
Remarks
BHCA requirement
BHCA that need to be supported in the

network
Calculated based on the number of

users and the traffic model
TRX Number
Total number of TRXs
Determined based on the network plan
ERL Number
CS traffic volume (Erlang) that needs

to be supported in the network
Determined based on the network plan
The number of WP1D000XPU01s to be configured depends on the total number of TRXs,

BHCA requirement, and CS traffic volume (Erlang) requirement.
Number of WP1D000XPU01s = 2 x ROUNDUP(max[TRX Number/640, BHCA
requirement/1,050,000, ERL Number/3900], 0)
If the IBCA function is required, an extra pair of WP1D000XPU01s should be configured to
work as XPUI.

Page 48 of 93
3.2.3 Description of Other Restrictions

The following figure shows the system resource management structure of the BSC.
The MPU (main processing unit) manages the control plane processing resources, user plane
processing resources, and interface processing resources. It corresponds to subsystem 0 of a
XPUb (one XPUb consists of eight subsystems). Each subrack can be configured with a
maximum of two MPUs.
The processing resources managed by different MPUs can work in load sharing mode. CrossMPU and cross-subrack processing may increase the load of MPUs. To maximize the
efficiency of MPUs, the processing procedure of a single user should be implemented in one
MPU. Therefore, it is recommended that Service processing units and interface boards be
evenly distributed in each MPU and subrack. The specifications of an MPU are as follows: If
SPUs and interface boards are deployed under an MPU, the MPU can process the traffic
corresponding to three XPUbs (including the XPUb in which the MPU is located).
As shown in the following figure, a BTS is connected to the BSC through an interface board
managed by MPU1 but is configured at an XPU managed by MPU2. But it is not
recommended that we configure like this because it will waste the switching capacity.

Page 49 of 93
3.3 BSC Interface Dimensioning

3.3.1 Interface Board specification
The BSC6900 provides various interfaces to meet the requirements of different network
structures.
Interface boards required by the BSC6900 GSM that adopts the HW69 R13 hardware
Part Number
Short Name
Description
Interface
WP1D000EIU00
EIUa
TDM Interface Unit

(32 E1/T1)
TDM transmission:
A/Ater/Abis/Lb
WP1D000OIU00
OIUa
TDM Interface Unit (1

STM-1, Channelized)
TDM transmission:
A/Ater/Abis/Lb
WP1D000POU01
POUc
IP Interface Unit (4
STM-1, Channelized)
TDM/FR or IP
transmission:
A/Ater/Abis/Lb/Gb/Iurg
WP1D000PEU00
PEUa

E1/T1)
TDM/FR or IP
transmission:
A/Abis/Lb/Gb/Iur-g

Page 50 of 93

WP1D000FG201
FG2c

FE/4 GE, Electrical)
IP transmission:
WP1D000GOU01
GOUc
GE, Optical)
IP transmission:
The OIUa board has been replaced by the enhanced POUc board. OIUa boards can be added as
required.
Table 3-2 Specifications of interface boards on different interfaces

Trans
mission
Type
Port Type
Port No.
Numb
er of
TRXs
Number
of CIC
circuits
(64 kbit/s)
on the A
Interface
Number
of CIC
circuits
(16 kbit/s)
on the
Ater
Interface
Gb
Throughp
ut (Mbit/s)
WP1D000EIU00
TDM
TDM E1
32
384
960
3840
N/A
WP1D000OIU00
TDM
TDM
CSTM-1
384
1920
7168
N/A
WP1D000PEU00
TDM
TDM
CSTM-1
32
384
6144
N/A
64
512
3906(with
DPUc)/768
0(with
DPUf)
7168
504
Model
TDM
TDM
CSTM-1
WP1D000POU01
HDLC
HDLC
CSTM-1
2048
N/A
N/A
N/A
IP
IP CSTM-1
2048
23,040
23,040
N/A
WP1D000FG201
IP
FE/GE
electrical
port
12/4
2048
23,040
N/A
1024
WP1D000GOU01
IP
GE optical
port
2048
23,040
N/A
1024

Page 51 of 93
3.3.2 Abis Interface Board Dimensioning

1. Calculating the Abis interface board number
Number of Abis interface boards = 2 x ROUNDUP(MAX(Number of TRXs in a transmission
mode/Number of TRXs supported by the interface board, Number of ports in a transmission
mode/Number of ports supported by the interface board), 0)
The bandwidth is not the bottleneck of the Interface board, so bandwidth will not be used for calculated
the number of interface boards.
3.3.3 Abis Interface Bandwidth Dimensioning

1. Calculating the Abis interface bandwidth in the case of TDM over E1
Reference for calculating the detailed bandwidth of the BTS

In the case of TDM over E1, the required transmission bandwidth of the Abis interface
can be calculated by using the following formula:
Abis-interface bandwidth of a site = CS service bandwidth + PS service bandwidth
+ LAPD signaling link bandwidth
1.
Caution: Service links and LAPD signaling links cannot share one 64 kbit/s timeslot.
Calculating the CS service bandwidth:
Total number of TCHs:
Abis TDM over E1 Equivalent TCH number for CS = ROUNDUP(CHPerCell
(SPDCHPerCell + DPDCHPerCell x DynPDCHActiveRadio))
Number of 16 kbit/s timeslots on the Abis interface required by TCHs:
Abis TDM over E1 16ksts for CS = Abis TDM over E1 Equivalent TCH number for
CS
Note:
2.
TRXNoTDME1 and MaxPDCHRatio are input parameters for BSC and network
configuration.
CHPerTRX is an advanced input parameter.
Calculating the PS service bandwidth:

Total number of PDCHs:
Abis TDM over E1 Equivalent PDCH number for PS = SPDCHPerCell +
DPDCHPerCell x DynPDCHActiveRadio
Number of 16 kbit/s timeslots on the Abis interface required by PDCHs:
Abis TDM over E1 16ksts for PS = Abis TDM over E1 Equivalent PDCH number
for PS x SUMPRODUCT(Coding Scheme Ratio in PS Traffic Model, 16k TS
number per Coding Scheme)
Note:
Coding Scheme Ratio in PS Traffic Model is specified in the PS traffic model.
The following table lists the number of 16 kbit/s timeslots on the Abis interface
occupied per coding scheme.
Page 52 of 93
The result can be obtained by multiplying the data in the corresponding two columns,
and then calculating the sum of all the values. The following data marked yellow is
used as examples.
Code Scheme
Ratio
16k TS number per Code Scheme
CS1
0%
CS2
0%
CS3
0%
CS4
0%
MCS1
0%
MCS2
0%
MCS3
0%
MCS4
0%
MCS5
0%
MCS6
100%
MCS7
0%
MCS8
0%
MCS9
0%
3.
Calculating the LAPD link bandwidth:

Number of Abis-interface 16 kbit/s timeslots occupied by the Abis interface signaling
links:
Abis TDM over E1 16sts for OML/RSL = IF(AbisLAPDMultiRate = "16K",
(SiteNoTDME1 + TRXNoTDME1), IF(AbisLAPDMultiRate = "2:1 multiplex",4 x
ROUNDUP((SiteNoTDME1 + TRXNoTDME1) x 2/4,0), IF(AbisLAPDMultiRate =
"4:1 multiplex", 4 x ROUNDUP((SiteNoTDME1 + TRXNoTDME1)/4, 0), 0)))
Note:
By default, the multiplexing ratio of Abis interface signaling links is 4:1, that is, four
RSLs or OMLs share 64 kbit/s bandwidth.
For HR traffic, the multiplexing ratio of Abis interface signaling links is 2:1, that is,
two RSLs or OMLs share 64 kbit/s bandwidth.
For satellite transmission, the Abis interface uses 16 kbit/s LAPDs, and one RSL or
OML occupies 16 kbit/s bandwidth.
4.
SiteNoTDME1, TRXNoTDME1 and AbisLAPDMultiRate are input parameters

for BSC and network configuration.
Calculating the number of E1 ports required by the Abis interface:

Number of required E1 ports when the Abis interface uses the TDM transmission mode:
AbisTDME1No = MAX((Abis TDM over E1 16ksts for CS + Abis TDM over E1
16ksts for PS + Abis TDM over E1 16sts for
OML/RSL)/31/4,TRXNoTDME1/TrxNumPerE1).

Page 53 of 93

Then, calculate the sum of the ports required by all the BTSs, namely, the number
of E1 ports required by the BSC.
Note:
TRXNoTDME1 is the input parameter for BSC and network configuration.
2. Calculating the Abis interface bandwidth in the case of IP over E1
1.
Reference for detailed calculation of the BTS bandwidth

In the case of IP over E1, the required transmission bandwidth of the Abis interface can
be calculated by using the following formula:
Abis IP over E1 Equivalent TCH number for CS = TRXNoIPE1 x CHPerTRX x (1MaxPDCHRatio)
Abis interface bandwidth occupied by a single call per voice coding scheme:
In IP over E1/STM1 mode, the IP bandwidths vary with voice coding rates. The size of a
single IP voice frame:
Abis IP over E1/STM1 CS frame len(bit) = TRAU frame (voice payload) + PTRAU
frame header + Abis IP over E1/STM1 frame header
Note:
TRAU frame: indicates the voice payload consisting of voice and Cbit. The value
varies with coding schemes.
PTRAU frame header: encapsulates the PTRAU frame. It consists of four bytes,
namely, 32 bits.
Abis IP over E1/STM1 frame header = 8 x (8 + 20 + 7). It in turn covers the UDP
frame header, IP frame header, and PPP frame header.
Bandwidth occupied by a single CS call in IP over E1/STM1 mode:

Abis IP over E1/STM1 CS Thput per unit(kbps) = Abis IP over E1/STM1 CS frame
len(bit) x 50 x CSVAD/1024
Note:
50: 50 voice frames per second; 1024: 1,024 bits, equal to 1 kbit/s.
CSVAD indicates the voice activation factor, which is an advanced input parameter.
Assume that the value of CSVAD is 0.5. Then, the following table lists the frame lengths
and bandwidths occupied by a single CS call in the IP over E1/STM1 mode when
different voice versions are used:
Service Type
Bit Rate Frame Len(bit)

(kbps)
CS: TRAU
PS: RLC/MAC +
Inband Control
FR
13
264

IP over
E1/STM1
Frame Len
IP over
E1/STM1 Thput
per Unit
(bit)
(kbps)
576
14.1
Page 54 of 93

Service Type

(kbps)
CS: TRAU
PS: RLC/MAC +
Inband Control
IP over
E1/STM1
Frame Len
IP over
E1/STM1 Thput
per Unit
(bit)
(kbps)
HR
5.6
120
432
10.5
EFR
12.2
248
560
13.7
AMR
12.2
264
576
14.1
AMR
10.2
224
536
13.1
AMR
7.95
176
488
11.9
AMR
7.4
168
480
11.7
AMR
6.7
152
464
11.3
AMR
5.9
136
448
10.9
AMR
5.15
120
432
10.5
AMR
4.75
112
424
10.4
AMR(HR)
7.95
176
488
11.9
AMR(HR)
7.4
168
480
11.7
AMR(HR)
6.7
152
464
11.3
AMR(HR)
5.9
136
448
10.9
AMR(HR)
5.15
120
432
10.5
AMR(HR)
4.75
112
424
10.4
Average packet length on each TCH and average Abis interface bandwidth (kbit/s) when
the Abis MUX is disabled:
avg Abis IP over E1/STM1 CS frame len(bit) = SUMPRODUCT(Coding Scheme
Ratio in CS Traffic Model, IP over E1/STM1 frame len)
avg Abis IP over E1/STM1 CS Thput per unit(kbps) = SUMPRODUCT(Coding
Scheme Ratio in CS Traffic Model, IP over E1/STM1 Thput per unit)
Note:
Codec
used as examples.
Ratio
IP over E1/STM1
Frame Len
IP over E1/STM1
Thput per Unit
(bit)
(kbps)
FR
70%
576
14.1
HR
30%
432
2x10.5

Page 55 of 93

Codec
Ratio
IP over E1/STM1
Frame Len
IP over E1/STM1
Thput per Unit
(bit)
(kbps)
EFR
0%
560
13.7
AMR
0%
576
14.1
AMR
0%
536
13.1
AMR
0%
488
11.9
AMR
0%
480
11.7
AMR
0%
464
11.3
AMR
0%
448
10.9
AMR
0%
432
10.5
AMR
0%
424
10.4
AMR(HR)
0%
488
2x11.9
AMR(HR)
0%
480
2x11.7
AMR(HR)
0%
464
2x11.3
AMR(HR)
0%
448
2x10.9
AMR(HR)
0%
432
2x10.5
AMR(HR)
0%
424
2x10.4
Important: Each TCH (air interface) can carry two HR services when it uses the
HR function. Therefore, as shown in the preceding table, the bandwidth occupied
by a call must multiply by 2 to calculate the average Abis interface bandwidth per
TCH.
When the ratio of AMR of each voice version is inaccessible, if the simplified
configuration is used, only the ratio of FR channels and HR channels can be used for
calculation.
the Abis MUX is enabled:
The principle of the Abis MUX is that: the Abis IP over E1/STM1 frame header can be
shared by different calls reaching the same BTS within the specified time and the
specified maximum multiplex length.
The average number of packets that can be multiplexed by different calls indicates the
number of calls that can be multiplexed within the specified time (20 ms) and within the
specified maximum multiplex length (1000 bytes).
Average number of packets that can be multiplexed:
Abis IP over E1 CS mux frame number = MAX(1, ROUNDDOWN(MIN(Abis IP
over E1 Equivalent TCH number for CS/SiteNoIPE1 x CSVAD, 8 x 1000/avg Abis
IP over E1/STM1 CS frame len), 0))
Note:

Page 56 of 93
In the formula, Abis IP over E1 Equivalent TCH number for CS /SiteNoIPE1 x

CSVAD indicates the average number of concurrent calls per site within the 20-ms
multiplex time.
In the formula, 8 x 1000/avg Abis IP over E1/STM1 CS frame len indicates the
average number of calls that can be carried within the 1000-byte multiplex length.
SiteNoIPE1 is the input parameter for BSC and network configuration.
The value 1000 indicates that the maximum multiplexed packet length is 1000 bytes
in the IP over E1/STM1 mode when the Abis MUX function is enabled.
avg Abis IP over E1/STM1 CS frame len indicates the average packet length on
each TCH in the IP over E1/STM1 mode when the Abis MUX function is disabled.
avg Abis IP over E1/STM1 CS mux frame len(bit) = (Abis IP over E1 CS mux frame
number x (avg Abis IP over E1/STM1 CS frame len - Abis IP over E1/STM1 frame
header + 3 x 8) + Abis IP over E1/STM1 frame header)/ Abis IP over E1 CS mux
frame number
Note:
In the preceding formula, 3 x 8 indicates the multiplex overhead when the Abis MUX
function is enabled.
avg Abis IP over E1/STM1 CS frame len indicates the average packet length on
each TCH in IP over E1/STM1 mode when the Abis MUX function is disabled.
avg IP over E1/STM1 CS mux Thput per unit(kbps) = avg Abis IP over E1/STM1
CS mux frame len x CSVAD x 50/1024
Note:
Total Abis interface bandwidth required by TCHs:
2.
Abis IP over E1 Thput for CS(Mbps) = Abis IP over E1 Equivalent TCH number
for CS x avg Abis IP over E1/STM1 CS mux Thput per unit/1024
Abis IP over E1 Equivalent PDCH number for PS = TRXNoIPE1 x CHPerTRX x
MaxPDCHRatio
Abis interface bandwidth occupied by a single PDCH per coding scheme:
In IP over E1/STM1 mode, the IP bandwidths vary with PS coding rates. The size of a
single IP frame:
Abis IP over E1/STM1 PS frame len(bit) = RLC/MAC data block + TRAU inband
control signaling + PTRAU frame header + Abis IP over E1/STM1 frame header
Note:
The size of an RLC/MAC data block varies with coding schemes.
A TRAU inband control signaling message consists of eight bytes.
TRAU frame header: encapsulates the PTRAU frame. It consists of four bytes.
Abis IP over E1/STM1 frame header = 8 x (8 + 20 + 7). It in turn covers the UDP
frame header, IP frame header, and PPP frame header.
Bandwidth occupied by a single PS call in the IP over E1/STM1 mode:

Abis IP over E1/STM1 PS Thput per unit = IP over E1/STM1 PS frame len x 50 x
PSUsage/1024
Note:

Page 57 of 93
50: 50 packet frames per second; 1024: 1,024 bits, equal to 1 kbit/s.
PSUsage indicates the PDCH usage. It is an advanced input parameter.
Assume that the value of PSUsage is 0.5. Then, the following table lists the frame
lengths and the bandwidths occupied by a single PS channel in the IP over E1/STM1
mode when different PS coding schemes are used:
Service Type

(kbps)
CS: TRAU
PS: RLC/MAC +
Inband Control
IP over
E1/STM-1
Frame Len
IP over
E1/STM-1
Thput per Unit
(bit)
(kbps)
CS1
9.05
224
536
26.2
CS2
13.4
304
616
30.1
CS3
15.6
352
664
32.4
CS4
21.4
464
776
37.9
MCS1
8.8
240
552
27.0
MCS2
11.2
288
600
29.3
MCS3
13.6/14.8 360
672
32.8
MCS4
17.6
416
728
35.5
MCS5
22.4
512
824
40.2
MCS6
27.2/29.6 656
968
47.3
MCS7
44.8
960
1272
62.1
MCS8
54.4
1152
1464
71.5
MCS9
59.2
1248
1560
76.2
Average packet length on each PDCH and average Abis interface bandwidth (kbit/s)
when the Abis MUX is disabled:
avg IP over E1/STM1 PS frame len(bit) = SUMPRODUCT(Coding Scheme Ratio in
PS Traffic Model, IP over E1/STM1 frame len)
avg IP over E1/STM1 PS Thput per unit(kbps) = SUMPRODUCT(Coding Scheme
Ratio in PS Traffic Model, IP over E1/STM1 Thput per unit)
Note:
used as examples.
Code Scheme
Ratio
IP over E1/STM-1 Frame IP over E1/STM-1

Len
Thput per Unit
(bit)
(kbps)
CS1
0%
536
26.2
CS2
0%
616
30.1

Page 58 of 93

Code Scheme
Ratio
IP over E1/STM-1 Frame IP over E1/STM-1

Len
Thput per Unit
(bit)
(kbps)
CS3
0%
664
32.4
CS4
0%
776
37.9
MCS1
0%
552
27.0
MCS2
0%
600
29.3
MCS3
0%
672
32.8
MCS4
0%
728
35.5
MCS5
0%
824
40.2
MCS6
100%
968
47.3
MCS7
0%
1272
62.1
MCS8
0%
1464
71.5
MCS9
0%
1560
76.2
when the Abis MUX is enabled:
The principle of the Abis MUX is that: the Abis IP over E1/STM1 frame header can be
Abis IP over E1/STM1 PS mux frame number = MAX(1, ROUNDDOWN(MIN(avg
IP over E1 Equivalent PDCH number for PS/SiteNoIPE1 x PSUsage,8 x 1000/avg
Abis IP over E1/STM1 PS frame len), 0))
Note:
In the formula, avg IP over E1 Equivalent PDCH number for PS

/SiteNoIPE1xPSUsage indicates the average number of concurrent PS calls per site
within the 20-ms multiplex time.
In the formula, 8 x 1000/avg Abis IP over E1/STM1 PS frame len indicates the
average number of PS calls that can be carried within the 1000-byte multiplex length.
SiteNoIPE1 is the input parameter for BSC and network configuration.
PSUsage indicates the voice activation factor, which is an advanced input parameter.
The value 1000 indicates that the maximum multiplexed packet length is 1000 bytes
in the IP over E1/STM1 mode when the Abis MUX function is enabled.
avg Abis IP over E1/STM1 PS frame len indicates the average packet length on
each PDCH in the IP over E1/STM1 mode when the Abis MUX function is disabled.
avg Abis IP over E1/STM1 PS mux frame len(bit) = (Abis IP over E1/STM1 PS mux
frame number x (avg Abis IP over E1/STM1 PS frame len - Abis IP over E1/STM1

Page 59 of 93

frame header + 3 x 8) + Abis IP over E1/STM1 frame header)/ Abis IP over
E1/STM1 PS mux frame number
Note:
The avg Abis IP over E1/STM1 PS frame len parameter indicates the average
packet length on each PDCH in IP over E1/STM1 mode when the Abis MUX
function is disabled.
avg IP over E1/STM1 PS mux Thput per unit(kbps) = avg Abis IP over E1/STM1
PS mux frame len x PSUsage x 50/1024
Note:
Total Abis interface bandwidth required by PDCHs:
3.
Abis IP over E1 Thput for PS(Mbps) = Abis IP over E1 Equivalent PDCH number
for PS x avg Abis IP over E1/STM1 PS mux Thput per unit/1024
Bandwidth occupied by Abis interface links:
Abis IP over E1 Thput for OML/RSL = (SiteNoIPE1 x 64 + TRXNoIPE1 x 16)/1024
Note:
4.
In HDLC mode, the bandwidth occupied by OMLs per site is 64 kbit/s, and the
bandwidth occupied by RSLs per TRX is 16 kbit/s.
SiteNoIPE1 and TRXNoIPE1 are input parameters for BSC and network
configuration.
Calculating the number of ports required by the Abis interface:

Total bandwidth when the Abis interface uses the IP over E1/STM1 mode:
AbisIPE1bandwidth(kbps) = (Abis IP over E1 Thput for CS(Mbps) + Abis IP over
E1 Thput for PS(Mbps) + Abis IP over E1 Thput for OML/RSL) x 1024
Number of E1 ports required by the Abis interface using IP over E1/STM1 mode:
AbisIPE1No = MAX(AbisIPE1bandwidth/(31 x 64 x E1T1STM1Usage),
TRXNoIPE1/18)
Note:
TRXNoIPE1 is the input parameter for BSC and network configuration.
3. Calculating the Abis interface bandwidth in the case of IP over Ethernet
1.
Reference for detailed calculation of the BTS bandwidth

In actual applications, if you need to calculate the bandwidth of each BTS and then
calculate the sum, you can use the following formula:
Abis IP over FEGE Equivalent TCH number for CS = TRXNoIPFEGE x
CHPerTRX x (1-MaxPDCHRatio)
Abis interface bandwidth occupied by a single call per voice coding scheme:

Page 60 of 93

In IP over FEGE mode, the IP bandwidths vary with voice coding rates. The size of a
single IP voice frame:
Abis IP over FEGE CS frame len(bit) = TRAU frame (voice payload) + PTRAU
frame header + Abis IP over FEGE frame header
Note:
PTRAU frame header: encapsulates the PTRAU frame. It consists of four bytes,
namely, 32 bits.
Abis IP over FEGE frame header = 8 x (8 + 20 + 38). It in turn covers the UDP frame
header, IP frame header, and MAC frame header.
Bandwidth occupied by a single CS call in the IP over FEGE mode:

Abis IP over FEGE CS Thput per unit(kbps) = Abis IP over FEGE CS frame len(bit)
x 50 x CSVAD/1024
Note:
50: 50 voice frames per second; 1024: 1,024 bits, equal to 1 kbit/s.
Assume that the value of CSVAD is 0.5. Then, the following table lists the frame lengths
and bandwidths occupied by a single CS call in the IP over FEGE mode when different
voice versions are used:
Service Type

(kbps)
CS: TRAU
IP over FE/GE
Frame Len
IP over FE/GE
Tput per unit
PS: RLC/MAC + (bit)

Inband Control
(kbps)
FR
13
264
824
20.1
HR
5.6
120
680
16.6
EFR
12.2
248
808
19.7
AMR
12.2
264
824
20.1
AMR
10.2
224
784
19.1
AMR
7.95
176
736
18.0
AMR
7.4
168
728
17.8
AMR
6.7
152
712
17.4
AMR
5.9
136
696
17.0
AMR
5.15
120
680
16.6
AMR
4.75
112
672
16.4
AMR(HR)
7.95
176
736
18.0
AMR(HR)
7.4
168
728
17.8
AMR(HR)
6.7
152
712
17.4
AMR(HR)
5.9
136
696
17.0

Page 61 of 93

AMR(HR)
5.15
120
680
16.6
AMR(HR)
4.75
112
672
16.4
the Abis MUX is disabled:
avg Abis IP over FEGE CS frame len(bit) = SUMPRODUCT(Coding Scheme Ratio
in CS Traffic Model, IP over FEGE frame len)
avg Abis IP over FEGE CS Thput per unit(kbps) = SUMPRODUCT(Coding
Scheme Ratio in CS Traffic Model, IP over FEGE Thput per unit)
Note:
used as examples.
Codec
Ratio
IP over FE/GE Frame

Len
IP over FE/GE Tput

per unit
(bit)
(kbps)
FR
70%
824
20.1
HR
30%
680
2x16.6
EFR
0%
808
19.7
AMR
0%
824
20.1
AMR
0%
784
19.1
AMR
0%
736
18.0
AMR
0%
728
17.8
AMR
0%
712
17.4
AMR
0%
696
17.0
AMR
0%
680
16.6
AMR
0%
672
16.4
AMR(HR)
0%
736
2x18.0
AMR(HR)
0%
728
2x17.8
AMR(HR)
0%
712
2x17.4
AMR(HR)
0%
696
2x17.0
AMR(HR)
0%
680
2x16.6
AMR(HR)
0%
672
2x16.4

Page 62 of 93
When the ratio of AMR of each voice version is inaccessible, if the simplified
configuration is used, only the ratio of FR channels and HR channels can be used for
calculation.
the Abis MUX is enabled:
The principle of the Abis MUX is that: the Abis IP over FEGE frame header can be
specified maximum multiplex length (1,000 bytes).
Abis IP over FEGE CS mux frame number = MAX(1, ROUNDDOWN(MIN(Abis
IP over FEGE Equivalent TCH number for CS/SiteNoIPFEGE x CSVAD, 8 x
1000/avg Abis IP over FEGE CS frame len), 0))
Note:
In the formula, "Abis IP over FEGE Equivalent TCH number for CS /SiteNoIPFEGE
x CSVAD" indicates the average number of concurrent calls per site within the 20 ms
multiplex time.
In the formula, 8 x 1000/avg Abis IP over FEGE CS frame len indicates the average
number of calls that can be carried within the 1000-byte multiplex length.
SiteNoIPFEGE is an input parameter for BSC and network configuration.
The value 1000 indicates that the maximum multiplexed packet length is 1,000 bytes
in the IP over FEGE mode when the Abis MUX function is enabled.
The avg Abis IP over FEGE CS frame len parameter indicates the average packet
length on each TCH in IP over FEGE mode when the Abis MUX function is disabled.
avg Abis IP over FEGE CS mux frame len(bit) = (Abis IP over FEGE CS mux
frame number x (avg Abis IP over FEGE CS frame len - Abis IP over FEGE frame
header + 3 x 8) + Abis IP over FEGE frame header)/Abis IP over FEGE CS mux
frame number
Note:
avg Abis IP over FEGE CS frame len indicates the average packet length on each
TCH in IP over FEGE mode when the Abis MUX function is disabled.
avg Abis IP over FEGE CS mux Thput per unit(kbps) = avg Abis IP over FEGE CS
mux frame len x CSVAD x 50/1024
Note:
Total Abis interface bandwidth required by TCHs:
2.
Abis IP over FEGE Thput for CS(Mbps) = Abis IP over FEGE Equivalent TCH
number for CS x avg Abis IP over FEGE CS mux Thput per unit/1024
Abis IP over FEGE Equivalent PDCH number for PS = TRXNoIPFEGE x
CHPerTRX x MaxPDCHRatio

Page 63 of 93

Abis interface bandwidth occupied by a single PDCH per coding scheme:
In the IP over FEGE mode, the IP bandwidths vary with PS coding rates. The size of a
single IP frame:
Abis IP over FEGE PS frame len(bit) = RLC/MAC data block + TRAU inband
control signaling + PTRAU frame header + Abis IP over FEGE frame header
Note:
The size of an RLC/MAC data block varies with coding schemes.
A TRAU inband control signaling message consists of eight bytes.
TRAU frame header: encapsulates the PTRAU frame. It consists of four bytes.
Abis IP over FEGE frame header = 8 x (8 + 20 + 38). It in turn covers the UDP frame
header, IP frame header, and MAC frame header.
Bandwidth occupied by a single PS call in IP over FEGE mode:

Abis IP over FEGE PS Thput per unit = Abis IP over FEGE PS frame len x 50 x
PSUsage/1024
Note:
50: 50 packet frames per second; 1024: 1,024 bits, equal to 1 kbit/s.
PSUsage parameter the PDCH usage, which is an advanced input parameter.
Assume that the value of PSUsage is 0.5. Then, the following table lists the frame
lengths and the bandwidths occupied by a single PS channel in the IP over FEGE mode
when different PS coding schemes are used:
Service Type

(kbps)
CS: TRAU
IP over FE/GE
Frame Len
IP over FE/GE
Tput per unit
PS: RLC/MAC + (bit)

Inband Control
(kbps)
CS1
9.05
224
784
38.3
CS2
13.4
304
864
42.2
CS3
15.6
352
912
44.5
CS4
21.4
464
1024
50.0
MCS1
8.8
240
800
39.1
MCS2
11.2
288
848
41.4
MCS3
13.6/14.8 360
920
44.9
MCS4
17.6
416
976
47.7
MCS5
22.4
512
1072
52.3
MCS6
27.2/29.6 656
1216
59.4
MCS7
44.8
960
1520
74.2
MCS8
54.4
1152
1712
83.6
MCS9
59.2
1248
1808
88.3

Page 64 of 93

when the Abis MUX is disabled:
avg Abis IP over FEGE PS frame len(bit) = SUMPRODUCT(Coding Scheme Ratio
in PS Traffic Model, IP over FEGE frame len)
avg Abis IP over FEGE PS Thput per unit(kbps) = SUMPRODUCT(Coding
Scheme Ratio in PS Traffic Model, IP over FEGE Thput per unit)
Note:
and then calculating the sum of all the values. The following data marked yellow is used
as examples.
Code Scheme
Ratio
IP over FE/GE Frame

Len
IP over FE/GE Tput per

unit
(bit)
(kbps)
CS1
0%
784
38.3
CS2
0%
864
42.2
CS3
0%
912
44.5
CS4
0%
1024
50.0
MCS1
0%
800
39.1
MCS2
0%
848
41.4
MCS3
0%
920
44.9
MCS4
0%
976
47.7
MCS5
0%
1072
52.3
MCS6
100%
1216
59.4
MCS7
0%
1520
74.2
MCS8
0%
1712
83.6
MCS9
0%
1808
88.3
when the Abis MUX is enabled:
The principle of the Abis MUX is that: the Abis IP over FEGE frame header can be
Abis IP over FEGE PS mux frame number = MAX(1, ROUNDDOWN(MIN(Abis IP
over FEGE Equivalent PDCH number for PS /SiteNoIPFEGE x PSUsage, 8 x
1000/avg Abis IP over FEGE PS frame len), 0))
Note:

Page 65 of 93
In the formula, "Abis IP over FEGE Equivalent PDCH number for

PS/SiteNoIPFEGExPSUsage" indicates the average number of concurrent PS calls
per site within the 20 ms multiplex time.
In the formula, 8 x 1000/avg IP over FEGE frame len indicates the average number
of PS calls that can be carried within the 1000-byte multiplex length.
SiteNoIPFEGE is an input parameter for BSC and network configuration.
The value 1000 indicates that the maximum multiplexed packet length is 1,000 bytes
in IP over FEGE mode when the Abis MUX function is enabled.
avg Abis IP over FEGE PS frame len indicates the average packet length on each
PDCH in IP over FEGE mode when the Abis MUX function is disabled.
avg IP over FEGE PS mux frame len(bit) = (PS mux frame number x (avg Abis IP
over FEGE PS frame len - Abis IP over FEGE frame header + 3 x 8) + Abis IP over
FEGE frame header)/Abis IP over FEGE PS mux frame number
Note:
In the preceding formula, "3 x 8" indicates the multiplex overhead when the Abis
MUX function is enabled.
avg Abis IP over FEGE frame len indicates the average packet length on each
PDCH in IP over FEGE mode when the Abis MUX function is disabled.
avg Abis IP over FEGE PS mux Thput per unit(kbps) = avg Abis IP over FEGE PS
mux frame len x PSUsage x 50/1024
Note:
Total Abis interface bandwidth required by PDCHs:
3.
Abis IP over FEGE Thput for PS(Mbps) = Abis IP over FEGE Equivalent PDCH
number for PS x avg Abis IP over FEGE PS mux Thput per unit/1024
Bandwidth occupied by Abis interface links:
Abis IP over FEGE Thput for OML/RSL = (SiteNoIPFEGE x 64 + TRXNoIPFEGE
x 16)/1024
Note:
4.
In IP mode, the bandwidth occupied by OMLs per site is 64 kbit/s, and the bandwidth
occupied by RSLs per TRX is 16 kbit/s.
SiteNoIPFEGE and TRXNoIPFEGE are input parameters for BSC and network
configuration.
Calculating the number of ports required by the Abis interface:

Total bandwidth when the Abis interface uses the IP over FEGE mode:
AbisIPFEGEbandwidth(kbps) = (Abis IP over FEGE Thput for CS(Mbps) + Abis
IP over FEGE Thput for PS(Mbps) + Abis IP over FEGE Thput for OML/RSL) x
1024
Number of required GE ports when the Abis interface uses the IP over FEGE mode:
AbisIPFEGENo = AbisIPFEGEbandwidth/(1000 x 1024 x FEGEUsage)
Note:
TRXNoIPFEGE is an input parameter for BSC and network configuration.
FEGEUsage is an advanced input parameter. The available bandwidth of one GE is: 1000 x 1024 x
FEGEUsage.

Page 66 of 93
3.3.4 Iur-g Interface Dimensioning

Usually, Iur-g only deal with the signaling between BSCs, so a bandwidth of no more than 2Mbps is
recommended to configure.
3.3.5 A Interface Dimensioning

1.
Bandwidth occupied by an A interface circuit:

Number of 64K timeslots required by an A interface CIC:
A 64ksts for CS = MaxACICPerBSC
Note:
The value of MaxACICPerBSC is obtained through the calculation of the overall
capacity of the BSC.
2.
Calculating the bandwidth occupied by an SS7 link:

Calculate or estimate the bandwidth according to the input by a customer. Sometimes,
the customer can provide only the number of TRXs instead of a traffic model. In this
case, you can estimate the bandwidth as follows:
Simplified calculation of the BSC capacity:

Number of 64K timeslots occupied by an A interface signaling link:
A 64ksts for No7 = IF(MaxACICPerBSC > 4096,
ROUNDUP(MaxACICPerBSC/256, 0), POWER(2,
ROUNDUP(LOG(ROUNDUP(MaxACICPerBSC/256, 0), 2), 0)))
Note:
When the total number of A interface CICs is greater than and equal to 4,096,
configure a 64 kbit/s SS7 link for every 256 A interface CICs.
When the total number of A interface CICs is less than and equal to 4,096, to
ensure that the bandwidth is allocated evenly to each SS7 link, configure a 64
kbit/s SS7 for every 256 A interface CICs and round up the result to 2, 4, 8, 16, or
32.
For example, in the case of MaxACICPerBSC/256 = 13, it indicates that 13 SS7

links are required. According to the formula POWER(2, ROUNDUP(LOG(13, 2),
0) = 16, round up the result to 16.
The value of MaxACICPerBSC is obtained through the calculation of the

overall capacity of the BSC.
Detailed calculation of the BSC capacity:

The average of signaling bytes in a call is 695.
A 64ksts for No7 = Call rate x Number of signaling in each call/Signaling load =
695 x 8 x CSErlPerBSC x 3600/average Call duration/1024/64/3600/Signaling
load = 695 x CSErlPerBSC/average Call duration/8192/Signaling load

Page 67 of 93

3.
Calculating the number of ports required by the A interface:

Number of E1 ports required by the A interface in TDM mode:
ATDME1No = A 64ksts for CS/30
For an E1, the 0th timeslot as the synchronization timeslot, and the rest 31 timeslots are
available. Various signaling messages, however, must also be delivered, and therefore
each E1 can bear 30 CICs evenly.
2. Calculating the Abis interface bandwidth in the case of IP over E1

When the A interface uses the IP over E1 mode, board specification is used as a criterion for
measuring the CIC bearing capability. The following calculation process is not recorded in the
dimension, but it is used during communication with customers or by executive departments
such as the transmission or after-sales department.
1.
Calculating the bandwidth occupied by the user plane of A interface:

The maximum bandwidth of A interface occupied by a call:
The IP bandwidths vary with different voice coding rates. The voice coding scheme of A
interface is controlled on the core network, and thus it is difficult to predict the AMR
ratio at different rates. As popular coding schemes, FR, EFR, and AMR/12.2K jointly
account for the maximum bandwidth usage. Upon comprehensive considerations, the
voice coding scheme reporting the maximum bandwidth usage serves as the basis for
calculating the A interface bandwidth.
A over E1/STM1 frame len(bit) = TRAU frame (voice payload) + A IP over
E1/STM1 frame header
Note:
TRAU frame: voice payload, including the voice and Cbit. The values vary with
different coding schemes.
When the UDP or IP header compression algorithm is used for the A interface: A IP
over E1 or STM1 frame header = 8 x (12 + 12), which includes an RTP frame header
and the average length after the UDP, IP, or PPP frame header is compressed.
Important: When the UDP or IP header compression algorithm is not used for the A
interface: A IP over E1 or STM1 frame header = 8 x (12 + 8 + 20 + 7), which
includes an RTP frame header, a UDP frame header, an IP frame header, and a PPP
frame header. Both the BSC and the core network of Huawei support the UDP or IP
header compression algorithm. Therefore, the compression mode is selected in the
default configuration.
In the IP over E1 or STM1 mode, calculate the maximum bandwidth occupied by a call
as follows:
A IP over E1/STM1 Thput per unit(kbit/s) = A IP over E1/STM1 frame len(bit) x 50
x CSVAD/1024
Note:
50: 50 voice frames per second. 1024: 1,024 bits, equal to 1 Kbits.
Calculate the total bandwidth occupied by the user plane of A interface:

A IP over E1/STM1 Thput for CS (kbit/s) = MaxACICPerBSC x A IP over
E1/STM1 Thput per unit
Note:

Page 68 of 93

2.
Calculating the bandwidth occupied by an SS7 link:

Bandwidth occupied by a signaling link of A interface:
A IP over E1/STM1 Thput for No7(kbit/s) = MaxACICPerBSC x 0.5
Note:
3.
In A IP over E1 or STM1 mode, when the UDP or IP header compression algorithm is

used on the A interface, the SS7 link resources occupied by equivalent CICs of each
A interface in busy hour are set to 0.5 kbit/s.

Calculating the number of ports required by the A interface:

AIPE1No = (A IP over E1/STM1 Thput for CS + A IP over E1/STM1 Thput for
No7)/(31 x 64 x E1T1STM1Usage)
Note:
E1T1STM1Usage is an advanced input parameter.

In Ethernet IP transmission mode, the throughput of the BSC board is no longer a bottleneck
but can meet the bandwidth requirements. Therefore, the calculation of bandwidth is for
reference and not typically used in the calculation of devices.
The calculation of bandwidth can be performed in simplified or detailed mode.

When the A interface adopts the Ethernet IP transmission mode, the A IP bandwidth on
the BSC side can be estimated according to the average traffic of each CIC:
AIPThrought= ACICNo x A CIC IP bandwidth/2
Where, ACIC IP bandwidth/2 represents the average unidirectional Abis bandwidth
requirement, and ACIC IP bandwidth represents the bidirectional bandwidth
requirement.
When the IP MUX is disabled, it is recommended that A-CIC IP bandwidth is 39.6
kbit/s. When the IP MUX is enabled, it is recommended that A-CIC IP bandwidth is
20.2 kbit/s.
The recommended values 39.6 kbit/s and 20.2 kbit/s derive from the following
traffic model:
During a conversation, usually one person speaks when the other person listens or both
people keep silent. Seldom both the two parties speak to each other (in the case, neither
of them can hear each other). Therefore:
VAD (average) = (VAD (UP) + VAD (down))/2 < 1/2
In comparison with the Abis interface, higher bandwidth can be specified for the A
interface because of a higher reuse rate on the A interface. Therefore, a greater value is
estimated for the VAD.
Suppose that VAD (UP) = 0.5, VAD (down) = 0.45, and the voice coding is AMR 7.95
kbit/s, the signaling bandwidth that is allocated averagely to each CIC is about 0.9 kbit/s.
A-CIC IP bandwidth/2 = (0.5 x 19.5/0.5 + 0.45 x 19.5/0.5)/2 + 0.9 kbit/s = 19.8
Therefore, Abis - CIC IP bandwidth = 39.6
Similarly, when the IP MUX is enabled, Abis - CIC IP bandwidth is 20 because
MUX packets are multiplexed.

Page 69 of 93

Note that both the values are estimated on the basis of a specific site type and coding
scheme. The values are in inverse proportion to the site type and in proportion to the
coding rate. If the number of PDCHs increases, the values become larger accordingly.
For the specific calculation of both values, refer to the calculation of single BTS
bandwidth.
1.
Reference for detailed bandwidth calculation

In practice, to accumulate the bandwidth of a single BTS in detail, take the following
formula:
AIPThrought = Bandwidth of user plane of A interface + SS7 service bandwidth
Calculating the bandwidth occupied by the user plane of A interface as follows:
Maximum packet length occupied by each CS call in IP over FE/GE mode
The IP bandwidths vary with voice coding rates. The voice coding scheme of A interface
is controlled on the core network, and thus it is difficult to predict the AMR ratio at
different rates. As popular coding schemes, FR, EFR, and AMR/12.2K jointly account
for the maximum bandwidth usage. Upon comprehensive considerations, the voice
coding scheme reporting the maximum bandwidth usage serve as the basis for
calculating the A interface bandwidth.
A IP over FEGE frame len(bit) = TRAU frame (voice payload) + A IP over FEGE
frame header
Note:
A IP over FEGE frame header = 8 x (12 + 8 + 20 + 38), which includes the length of
RTP, UDP, IP, or MAC frame header.
When the UDP MUX of A interface is disabled, calculate the maximum bandwidth
occupied by a call in IP over FE/GE mode as follows:
A IP over FEGE Thput per unit(kbit/s) = A IP over FEGE frame
len(bit)*50*CSVAD/1024
Note:
When the UDP MUX of A interface is enabled, calculate the maximum bandwidth
occupied by a call in IP over FE/GE mode as follows:
The principle of UDP MUX of A interface is that different calls destined for the same
BTS in a specified time period and within the specified maximum multiplex length can
share an Abis IP over FEGE frame header.
The average number of packets that can be multiplexed in different calls is the number of
multiplexed calls in the specified time period (20 ms) and within the specified maximum
multiplex length (1,000 bytes).
Calculate the average number of packets that can be multiplexed as follows:
A IP over FEGE CS mux frame number = MAX(1, ROUNDDOWN(8 x 1000/A IP
over FEGE frame len, 0))

Page 70 of 93

Speech
Version
Voice Data Bit

Rate
(Code
Scheme)
(Service Bit Rate

in RLC/MAC
layer)
FR
13 kbit/s
EFR
Voice
Frame Bit
Rate/UM
Channel
(kbit/s)
Mux Total Avg Frame

Size
Bit Rate
(Bit) UDP
MUX
(kbit/s)
UDPMUX
888
21.7
3856
11.8
12.2 kbit/s
872
21.3
3728
11.4
AMR-FR12.2 12.2 kbit/s
888
21.7
3856
11.8
848
20.7
3536
10.8
800
19.5
3152
9.6
792
19.3
3088
9.4
776
18.9
2960
9.0
AMR-FR5.9
760
18.6
2832
8.6
744
18.2
2704
8.3
736
18.0
2640
8.1
HR
744
18.2
2704
8.3
AMR-HR7.95 7.95 kbit/s
800
19.5
3152
9.6
792
19.3
3088
9.4
776
18.9
2960
9.0
AMR-HR5.9
760
18.6
2832
8.6
744
18.2
2704
8.3
736
18.0
2640
8.1
5.9 kbit/s
5.6 kbit/s
5.9 kbit/s
Voice
Frame
Len/20 ms
(Bit)
Note:
In the preceding formula, 8 x 1000/A IP over FEGE frame len indicates the average
number of calls carried in the multiplex length of 1,000 bytes.
1000 indicates that the maximum length of Abis Mux packets is 1,000 bytes in IP
over FEGE mode.
A IP over FEGE frame len indicates that the maximum length of packets occupied
by each CS in IP over FEGE mode when the UDP MUX function of A interface is
disabled.
avg A IP over FEGE frame len(bit) = (A IP over FEGE CS mux frame number x (A
IP over FEGE frame len - A IP over FEGE frame header + 5 x 8) + A IP over FEGE
frame header)/A IP over FEGE CS mux frame number
Note:
In the formula, 5 x 8 indicates the multiplex overhead when the UDP MUX function
of A interface is enabled.

Page 71 of 93
A IP over FEGE frame len indicates that the maximum length of packets occupied
by each CS in IP over FEGE mode when the UDP MUX function of A interface is
disabled.
avg A IP over FEGE Thput per unit (kbit/s) = avg A IP over FEGE frame len x
CSVAD x 50/1024
Note:
Calculate the total bandwidth occupied by the user plane of A interface:
A IP over FEGE Thput for CS (kbit/s) = MaxACICPerBSC x avg A IP over FEGE
Thput per unit
Note:
2.
Calculating the bandwidth occupied by an SS7 link as follows:

Bandwidth occupied by a signaling link of A interface:
A IP over FEGE Thput for No7 (kbit/s) = MaxACICPerBSC x 0.9
Note:
3.
In A IP over FEGE mode, the SS7 link resources occupied by the equivalent CICs of
each A interface in busy hour are supposed to be 0.9 kbit/s.

Calculating the number of GE ports required by an A interface:

AIPSTM1No = (A IP over FEGE Thput for CS + A IP over FEGE Thput for
No7)/(1000 x 1024 x FEGEUsage)
Note:
FEGEUsage is an advanced parameter. The available bandwidth of a GE is obtained
from 1000 x 1024 x FEGEUsage.
Calculating the Number of M3UA Links in IP Transmission

It is recommend that the traffic volume be firstly converted into signaling bandwidth in TDM
transmission, and then be converted into the number of M3UA links. One M3UA link must be
configured for every 1 Mbit/s signaling (16 x 64 kbit/s) bandwidth.
That is, one M3UA link must be configured for every 4000 CICs.
3.3.6 Ater Interface Dimensioning

1.
Calculate the bandwidth occupied by the A interface circuit as follows:

Number of 16 kbit/s timeslots required by the Ater interface CIC:
Ater 16ksts for CS = MaxAterCICPerBSCTDM
Note:

Page 72 of 93

The value of MaxAterCICPerBSC is obtained through the calculation of the overall
2.
Calculate the bandwidth occupied by an Ater interface signaling link as follows:

Number of 16 kbit/s timeslots occupied by an Ater interface signaling link including the
Ater RSL and Ater OML:
Ater 16ksts for RSL/OML = ROUNDUP (MaxAterCICPerBSC/512, 0) x 4 x 2 + 16
x4
Note:
Two 64 kbit/s Ater RSLs are configured for every 512 Ater interface CICs.
16 x 4 indicates that each BSC is configured with 16 Ater OML links, each occupying
64 kbit/s bandwidth by default.

GBSS9.0 requires more Ater Radio Signaling Link (RSL) bandwidth than GBSS8.1.
Therefore, check the number of Ater RSLs after the upgrade from BSC6000 to BSC6900
GBSS9.0 or later versions.
Assume that the BSC is configured with 640 TRXs, a minimum of twelve 64 kbit/s Ater
RSLs must be configured.
The number of Ater RSLs is calculated according to the number of CICs on the A
interface: Two 64 kbit/s Ater RSLs (or RSLs with the same bandwidth, for example, one
128 kbit/s RSL) must be configured for every 512 CICs, and a maximum of 64 Ater
RSLs can be configured.
If the number Ater RSLs calculated in last step is less than 12, then 12 Ater RSLs should
be configured.
3.

Number of 16 kbit/s timeslots occupied by an Ater interface SS7 link because an A
interface SS7 link needs to pass through the Ater interface.
Ater 16ksts for No7 = A 64ksts for No7 x 4
Note:
A 64ksts for No7 is acquired by calculating the A interface transmission throughput.
4.
Calculating the number of ports required by an Ater interface:

Number of E1 ports required by the Ater interface in TDM mode:
AterTDME1No = (Ater 16ksts for CS + Ater 16ksts for No7 + Ater 16ksts for
RSL/OML)/31/4
2. Calculating the Abis interface bandwidth in the case of IP over E1 over STM-1
1.
Calculating the bandwidth occupied by the user plane of Ater interface as follows:
Maximum bandwidth of Ater interface occupied by a call:
The IP bandwidths vary with voice coding rates. The voice coding scheme reporting the
maximum bandwidth usage serve as the basis for calculating the A interface bandwidth
when the Ater interface bandwidth is calculated.
Ater over E1/STM1 frame len(bit) = TRAU frame (voice payload) + PTRAU frame
header + Ater IP over STM1 frame header

Page 73 of 93

Note:
PTRAU frame header: Encapsulate a PTRAU frame which includes four bytes, that is,
32 bits.
When the UDP or IP header compression algorithm is used for the Ater interface:
Ater IP over STM1 frame header = 8 x 12, which includes the average length after
the UDP, IP, or PPP frame header is compressed.
Important: The compression mode is selected in the default configuration of Ater

interface.
In IP over E1 or STM1 mode, calculate the maximum bandwidth occupied by a call as
follows:
Ater IP over STM1 Thput per unit (kbit/s) = Ater IP over STM1 frame len(bit) x 50
x CSVAD/1024
Note:
Calculate the total bandwidth occupied by the user plane of Ater interface:
Ater IP over STM1 Thput for CS (kbit/s) = MaxAterCICPerBSC x Ater IP over
STM1 Thput per unit
Note:
2.
Calculating the bandwidth occupied by an Ater interface signaling link as follows:

Number of 16 kbit/s timeslots occupied by an Ater interface signaling link including the
Ater RSL and Ater OML:
Ater IP over STM1 Thput for RSL/OML (kbit/s) = MaxAterCICPerBSC x 0.4 +
1600
Note:
3.
In Ater IP over STM1 mode, the AterRSL signaling link resources occupied by the
equivalent CICs of each Ater interface in busy hour are supposed to be 0.4 kbit/s.
In Ater IP over STM1 mode, the AterOML bandwidth occupied by each BSC in busy
hour is fixedly set to 1,600 kbit/s.


Number of 16 kbit/s timeslots occupied by an Ater interface SS7 because an A interface
SS7 link needs to pass through the Ater interface.
Ater 16ksts for No7 = A 64ksts for No7 x 4
Note:
A 64ksts for No7 is acquired by calculating the A interface transmission throughput.
4.
Important: In IP over STM1 mode, an SS7 link is switched from an Ater interface
to the BSC side according to the TDM timeslot.
Calculating the number of STM1 ports required by an Ater interface:

Page 74 of 93

AterIPSTM1No = (Ater IP over STM1 Thput for CS + Ater IP over STM1 Thput
for RSL/OML)/(31 x 64 x E1T1STM1Usage x 32/33)/63 + Ater 16ksts for
No7/31/4/63
Note:
E1T1STM1Usage is an advanced parameter. The available bandwidth of an E1 in IP
mode is: 31 x 64 x E1T1STM1Usage x 32/33.
Note:
3.3.7 Gb Interface Dimensioning

1. Calculating the Abis interface bandwidth in the case of FR over E1
The calculation of Gb interface traffic is closely related to the average length of packets on the
Gb interface. Parameters that should be provided by a customer, however, may be unavailable
in the quotation phase, and only the simplified calculation method is used:

After the amount of service data carried by each 64 k timeslots is estimated simply, the
number of required FR E1s can be acquired:
GbFRE1No =GbTputPerBSC/UsPer64kpbs/1024/31
Where, UsPer64kpbs is 35k averagely, which can be adjusted and construed as
UsPer64kpbs = PayloadLenGb/(PayloadLenGb + 53) x 64 kbit/s
Precise calculation for the BSC:

The precise calculation formula is as follows:
GbFRE1No =GbTputPerBSC x (1 + 1%)/(PayloadLenGb/(PayloadLenGb +
53))/1024/(31 x 64 x GbFRUsage)
Note:
The value of GbTputPerBSC is obtained through the calculation of the overall

1% indicates the average retransmission ratio of Gb interface packets.
PayloadLenGb is an advanced parameter.
53 indicates the length of an FR packet header when the Gb interface uses the FR.
UsPer64kpbs indicates the valid number of bytes carried in each 64K timeslot in the
FR mode. The value is 35 k averagely, which can be adjusted and construed as
UsPer64kpbs = PayloadLenGb/(PayloadLenGb + 53) x (GbFRUsage) x 64 kbit/s
GbFRUsage is an advanced parameter.

The calculation of Gb interface traffic is closely related to the average length of packets on the
Gb interface. Parameters that should be provided by a customer, however, may be unavailable
in the quotation phase:

Page 75 of 93

After estimating the valid data carried by each GB IP and the average ratio of the
total bandwidth, you can acquire the required IP bandwidth:
GbIPTputPerBSC (Mbps) = GbTputPerBSC/GbUtiRatio/1024/1024
GbUtiRatio indicates the average ratio of the valid data to the total bandwidth in
Gb over IP mode. The value is 0.7 by default, which can be adjusted and construed
as GbUtiRatio = PayloadLenGb/(PayloadLenGb + 124)
Precise calculation for the BSC:
The precise calculation formula is as follows:
GbIPTputPerBSC (Mbps) = GbTputPerBSC x (1 +
1%)/(PayloadLenGb/(PayloadLenGb + 124))/1024/1024
Note:
The value of GbTputPerBSC is obtained through the calculation of the overall

1% indicates the average retransmission ratio of Gb interface packets.
PayloadLenGb is an advanced parameter.
124 indicates the length of a packet header when the Gb interface works in the IP
transmission mode.
GbUtiRatio indicates the average ratio of the valid data to the total bandwidth
in Gb over IP mode. The value is 0.7 by default, which can be adjusted and
construed as GbUtiRatio = PayloadLenGb/(PayloadLenGb + 124)
Number of GE ports required by a Gb interface:

GbGENo = GbIPTputPerBSC/(1000 x 1024 x GbIPUsage)
Note:
GbIPUsage is an advanced parameter, ranges from 0 to 1. The default value is 1. If the
operator wants more resources, the operator can calculate the number by using this
formula.
3.3.8 NIUa Throughput Dimensioning

The NIUa board provides the BSC service awareness function. This board is used with service
boards to implement priority-based service scheduling, which provides differentiated service
quality to different services.
A single NIUa board supports a throughput of 3.2 Gbit/s on the user plane. By default, NIUa
provides 50 Mbit/s throughput processing capability. If Gb throughput is higher than 50
Mbit/s, subscribers are required to purchase extra flow licenses (The step size is 50 Mbit/s,
and one board is configured with a maximum of 63 licenses, that is, an NIUa supports up to
3.2 Gbit/s).
If GbTputPerBSC > 50M bit/s
NIUa License quantity = ROUNDUP[(GbTputPerBSC 50)/50, 0]
Otherwise,
NIUa License quantity = 0
To ensure system reliability however, two NIUa boards are recommended.

Page 76 of 93
3.4 BSC subrack and cabinet

1. Configuration principles of the MPS:
One MPS must be configured in a BSC6900 GSM. For a BSC6900 GSM or a BSC6900 GU
in BM/TC separated configuration mode, the MPS must work in GSM mode.
2. Configuration principles of the EPS: A maximum of three EPSs can be configured in a
BSC6900 GSM. Adhere to the following principles when configuring EPSs for a BSC6900
GSM:
All interface boards must be configured in the rear slots of an EPS. Service processing
units can be configured in the front or rear slots of an EPS.
10 rear slots of the GSM MPS are used to house GSM service processing units and
interface boards, and 8 front slots are used to house GSM service processing units.
14 rear slots of a GSM EPS are used to house GSM service processing units and
interface boards, and 10 front slots are used to house GSM service processing units.
The number of GSM subracks cannot exceed 4.
Configuration principle of QM1P00UEPS01: The number of GSM subracks is calculated

based on the number of service processing units and the number of interface boards.
Number of GSM_EPSs = MAX((Total number of interface boards Number of slots for
interface boards in MPS)/14, (Total number of interface boards + Total number of service
processing boards Total number of slots in MPS)/24)
The number of slots for interface boards in the MPS is 10, and the total number of slots in the
MPS is 18. The number of slots for interface boards in an EPS is 14, and the total number of
slots in the MPS is 24.
The MPS needs to house two clock boards, two OMUc boards, and one SAUc board.
Therefore, a maximum of 10 interface boards or a maximum of 18 boards can be configured
in the MPS.
3.5 Impact of traffic model on Configuration

The processing capability of a given device is fixed. The claimed specification of a device,
however, varies with the traffic model.
1. BHCA will effect the control plane Board:
BHCAs supported by XPUb is a static Number.
The processing resources consumed by a single user depend on the traffic model. When the
traffic model changes, the processing resources of XPUb remain unchanged, but the
processing resources consumed by a single user change.
Therefore, the user number and traffic may change as the traffic model changed.
The traffic model in a live network changes with time and the user behavior. Therefore, the
system may be congested because of limited control plane processing resources, even when
the traffic in the network does not reach the claimed capacity (Erlang or throughput).

Page 77 of 93

When the traffic model changes, the control plane processing resources required by the
network need to be recalculated according to the current traffic model. Then, necessary XPUb
should be added according to the requirements.
2. the effects of Users behavior:
Below is the BHCA weight:
Service Type
CS BHCA Weight
LU to CS call
31.25%
IMSI Attaches to CS call
31.25%
IMSI Detaches to CS call
31.25%
CS calls to CS call
100.00%
MR Reports to CS call
0.75%
CS SMS to CS call
50.00%
Intra-HOs to CS call
40.00%
Inter-HOs to CS call
50.00%
CS Paging to CS call
0.08%
Uplink TBF Est & Rel to CS call
4.00%
Downlink TBD Est & Rel to CS call
4.00%
PS Paging/Second per cell to CS call
0.08%
The BHCA per BSC is calculated according to the BHCA weight of each service type of the
BSC6900.
CSBHCAPerBSC = SubPerBSC x (CSLUPerSubinBH x LU to CS call weight +
CSAttachPerSubinBH x IMSI Attaches to CS call weight + CSDetachPerSubinBH x
IMSI Detaches to CS call weight + (CSMOCPerSubinBH + CSMTCPerSubinBH) x CS
calls to CS call weight + CSMRPerSubinBH x MRs to CS call weight +
(CSMOSMSPerSubinBH + CSMTSMSPerSubinBH) x CS SMS to CS call weight +
CSIntraHOPerSubinBH x Intra-HOs to CS call weight + CSInterHOPerSubinBH x
Inter-HOs to CS call weight + (CSMTCPerSubinBH + CSMTSMSPerSubinBH +
CSRetransferPagingPerSubinBH) x CS Paging to CS call weight)
PS services are considered in calculation of the BHCA per BSC. Therefore, the formula is
changed as follows:
AllBHCAPerBSC = CSBHCAPerBSC +PS BHCA
PSBHCAPerBSC = PSUpTBFinBH x Uplink TBF Est & Rel to CS call weight +
PSDownTBFinBH x Downlink TBF
Est & Rel to CS call weight +
PSPaginginBH x PS Paging/Second per cell to CS call
2. Get the traffic model relative parameters counter from NE:

Page 78 of 93

s
BASIC Procedure (User operation)
CS LUs (Location Update)

average IMSI Attaches (IMSI Attaches)
average IMSI Detaches (IMSI Detaches)
Performance (Sum of Cell)
A300F: A300F:Channel Requests (Location Updating)

From MSC
From MSC
A300A:Channel Requests (MOC) + A300C:Channel
Requests (MTC) - CA334A:Total Uplink Point-to-Point
Short Messages - CA334B:Total Downlink Point-to-Point
Short Messages
CS calls
S329: Number of Power Control Messages per Cell
MR Reports
CA334A: Total Uplink Point-to-Point Short Messages

+CA334B: Total Downlink Point-to-Point Short
CS SMS (sending and receiving)
Messages
CH310: Number of Outgoing Internal Inter-Cell
Intra-Hos (intra BSC)
Handover Requests
CH330: Outgoing External Inter-Cell Handover
Requests+CH340: Incoming External Inter-Cell
Inter-HOs (Inter BSC)
Handover Requests
A330: Delivered Paging Messages for CS Service
CS Paging
A9201: Number of Uplink EGPRS TBF Establishment
Attempts+A9001: Number of Uplink GPRS TBF
Uplink TBF Est
Establishment Attempts
A9301: Number of Downlink EGPRS TBF
Establishment Attempts+A9101: Number of Downlink
Downlink TBF Est

PS Paging
GPRS TBF Establishment Attempts

A331: Delivered Paging Messages for PS Service
3.6 Impact of VAMOS on Configuration

VAMOS function can increase the number of channels in Um interface , That means
there can be possible more traffic in one TRX/CELL/BTS/BSC.
So, the bandwidth of Abis interface or A interface would increase with traffic increased.

Page 79 of 93
Cell Traffic Per BSC

1.
The maximum number of TCHs per cell can be obtained by querying the table or using
the following formulas:
Full rate:
CHPerCell = TRXPerCell x 8 - ROUNDUP(TRXPerCell/2,0) - 1
Half rate:
CHPerCell = TRXPerCell x 8 - ROUNDUP(TRXPerCell,0) - 1
Note:
2.
TRXPerCell is a network configuration input parameter. If the number of TRXs per

cell is not available, you can estimate the number of TRXs per cell by using the
following formula:
TRXPerCell = Total TRX/BTS Num/3
Simply assume that each cell is configured with one primary BCCH. In the full rate
mode, every two TRXs share one SDCCH; in the half rate mode, every TRX uses one
SDCCH.
Assuming that each cell is configured with one primary BCCH, the maximum
number of TCHs per cell can also be calculated by using the following formula:
CHPerCell = TRXPerCell x CHPerTRX

Number of TCH/Fs + TCH/Hs per cell +TCH/VAMOS:
Number of TCH/Fs , TCH/Hs per cell and +TCH/VAMOS =
ROUNDUP((CHPerCell - (SPDCHPerCell + DPDCHPerCell x
DynPDCHActiveRadio)) x (1 + TCHHRatio +2* VAMOSRatio), 0)
Note:
VAMOS can be used when Abis over IP or Flex Abis , but can not be used when Abis
over TDM over E1/ STM-1.
TCHHRatio is the input data of network parameters.
3.
Traffic per cell

Traffic per cell = erlangB_traffic(CHPerCell x (1 + TCHHRatio+2* VAMOSRatio),
UmBlockRatio)
Note:
UmBlockRatio is the input parameter Grade of Service (GoS) on Um interface in

the traffic model.
VAMOSRatio is the input parameter on Um interface .
erlangB_traffic(number of channels, block ratio) indicates the ErlangB table

formula used for calculating the cell traffic based on the number of channels and the
block ratio.
Total Traffic of the BSC

CSErlPerBSC = SUMPRODUCT(number of nTRX cells, nTRX cell traffic volume) x
AUmRatio
Note:
SUMPRODUCT (number of nTRX cells, nTRX cell traffic volume) indicates the sum of
the product of the number of cells with n TRXs and the traffic of these cells.
Important:

Page 80 of 93

When the user inputs the CS traffic of the BSC (InputCSErlPerBSC), the BSC capacity is
calculated according to the CS traffic input by the user.
When the user does not input the CS traffic of the BSC, the BSC capacity is calculated
according to the maximum traffic supported per cell.
Therefore, the user must ensure the input correctness when the user manually inputs the traffic.
3.7 Counters Related to Capacity

There are following main counters (not limited to) related to capacity which will help you to better understand
your networks status.
BSCRPT.KPI.TCH.TRAF.ERL.TRAF
BSCRPT.KPI.TCH.AVAIL.NUM
BSC.PSTRAN.UP.CS1.RLC.BLK
BSC.PSTRAN.DOWN.CS1.RLC.BLK
BSC.PSTRAN.UP.EGPRS.MCS1.RLC.DATA.BLK
BSC.PSTRAN.DOWN.EGPRS.MCS1.RLC.DATA.BLK
BSC.PSTRAN. DOWN.EGPRS.MCS2.RLC.DATA.BLK

Page 81 of 93

Page 82 of 93
OMC
This specification is based on iManager M2000 V200R011.
4.1 Network Management Capability

4.1.1 Evaluation Dimensions
When the data processing capability, data storage capability, and number of concurrent users of an M2000
meet certain specifications, the M2000 runs normally. In this case, the size of the network managed by the M2000
is considered as the network management capability of the M2000. The network management capability of the
M2000 is evaluated on the basis of the following dimensions:
Data processing capability
Data storage capability
Number of concurrent users
When all the preceding dimensions are met, the M2000 system meets the requirements for network
management capability.
Example: A GSM network consists of N TRX. To manage this network, the M2000 system should be capable
of:
1Processing the management information (including collection, import-to-database, query, and MML
commands) of the network within a unit time.
2Storing data for a certain period. For example, storing alarm data for x days and performance data for y
days.
3Supporting the number of concurrent users required by certain services (based on logical application
scenarios).

Page 83 of 93
4.1.2 Evaluation Principles

On condition that the M2000 meets the requirements for data storage capability and number of concurrent
users, the data processing capability of the M2000 is evaluated on the basis of hardware resources (including CPU,
memory, and database) used by the M2000 during operations. The CPU usage is the most important indicator
reflecting hardware resource consumption. When running at the maximum processing rate, the M2000 needs to
meet the following conditions concurrently:
Within a measurement period (excluding the five-minute period), the CPU usage cannot exceed 90%
for longer than five minutes.
Within a measurement period (excluding the five-minute period), the CPU usage cannot exceed 80%
for longer than nine minutes.
Within one hour, the average CPU usage cannot exceed 60%.
4.1.3 Evaluation Method

The maximum network management capability of the M2000 system is evaluated on condition that the
preceding requirements are met (corresponding to the dimensions described in 4.1.1).
4.2 Equivalent NE Conversion Tables

Tables in this section describe the rules for converting a wireless TRX into equivalent NEs in the cases of
different measurement periods and different measurement settings. The M2000 uses different amounts of
resources in managing NEs of different types. Therefore, a constant ratio is specified for converting physical NEs
of each type to equivalent NEs. The user can convert the physical NEs in a network into equivalent NEs based on
this ratio, calculate the size of the network based on equivalent NEs, and thus obtain the management capability of
the M2000.
This section describes how to convert physical NEs of different types into equivalent NEs. Notes: During the
conversion, the following factors should be taken into account:
Physical NE type and version: Different NE types and versions use different amounts of M2000
resources. As a result, the number of equivalent NEs converted varies according to the NE type.
Number of measurement counters: KPI counters or all counters can be set to measure an NE's

Page 84 of 93
performance. In either scenario, the required amount of M2000 hardware resources is different.
Therefore, the number of measurement counters has an impact on the equivalent NE conversion.
Performance statistical period: Each NE reports performance data to the M2000 at certain intervals.
Processing data reported every 60 minutes requires different amount of M2000/PRS hardware
resources from that reported every 15 minutes.
The operator should calculate the network size and the required management capability of the M2000
accurately. Otherwise, the M2000 configured may fail to meet the actual requirements for network management.
For the formulas for converting physical NEs of different types into equivalent NEs in GSM scenarios, see 4.2.1:
4.2.1 Equivalent NE Conversion of GSM NEs

Equivalent NE conversion of GSM NEs (30-minute/60-minute)
Number of Equivalent NEs
Conversion Unit
KPI-Counter
All-Counter
1/125
1/75
1 TRX
Equivalent NE conversion of GSM NEs (15-minute)

Number of Equivalent NEs
Conversion Unit
1 TRX
KPI-Counter
All-Counter
1/75
1/45
4.3 Data Storage Capability

4.3.1 Alarm Data Processing Capability
Generally, it takes less than five seconds to generate an alarm on the NE and display the alarm on the M2000
client (excluding the relevance analysis process).
Server Configuration
Sun Fire V890 (2CPU)
General Alarm Processing Rate

(piece/s)
Peak Alarm Processing
10
30

Rate (piece/s)
Page 85 of 93

15
50
24
90
Sun Fire E4900(4CPU)
18
55
30
100
38
125
Sun T5220
20
Sun M4000(2CPU)
15
50
Sun M4000(4CPU)
24
85
Sun M5000(4CPU)
24
90
Sun M5000(6CPU)
30
100
Sun M5000(8CPU)
38
125
ATAE Cluster (400eNEs)
38
125
38
125
Note: The alarm reporting peak lasts for eight minutes.
4.3.2 Alarm Data Storage Capability

One alarm is 1 KB in size. Thus, 10,000 alarms occupy the database space of 10 MB. Maximum number of
alarms stored on the M2000 server
Maximum Number of Alarms
(unit: 10,000pcs)
Log Storage Duration (month)
Alarm List
Alarm Logs
Event Logs
Sun T5220
125
125
<3
Sun Fire V890
1006
1006
<3
Sun Fire E4900
1006
1006
<3
Sun M4000
1258
1258
<3
Sun M5000
1258
1258
<3
1258
1258
<3
1258
1258
<3
4.3.3 Performance Data Storage Capability

The specific formula is as follows:

Page 86 of 93
F indicates the performance database space.
i indicates the number of measurement object types.
62 indicates that 62 KB is fixedly occupied by the result of each measurement unit.
U indicates the number of measurement units set for the measurement object. The performance
result table is established on the basis of measurement units. A piece of record is generated for each
measurement unit at each measurement period. Therefore, U also indicates the number of
performance results of the measurement object generated at each measurement period.
6 indicates that 6 KB is allocated for each counter fixedly.
C indicates the number of counters set for the measurement object.
O indicates the number of object instances in the function subset.
(60/T) x 24 x D indicates the number of measurement periods, in which T indicates the

measurement period and can be set to 15 (minutes) , 30 (minutes), or 60 (minutes), and D indicates
the storage duration (days).
1.5 indicates the ratio of the database space to the actual data amount.
For the database space allocation for performance data on various M2000 server models, seechapter 4.3.4
4.3.4 M2000 Database Space Allocation

The database space on an M2000 server depends on the disks or disk array that is configured. Table 4.3.4
describes the database space allocation for performance data and alarm data on mainstream M2000 server models.
If the customer's M2000 does not fit any of the following specifications, contact Huawei R&D engineers for
assistance.
Performance
Database
Space (MB)
Alarm
Database
Space (MB)
SUN T5220single-server (Local 4*146G HD)
46,080
3,072
SUN T5220 S3100 16*146G HD
286,720
24,576
SUN V890 single-server SE33208*73G HD
92,160
12,228
SUN V890 single-server SE614016*146G HD
286,720
24,576

Page 87 of 93

SUN M4000 single-server S260012*450G HD
286,720
24,576
SUN E4900 single-server SE614014*73G HD
153,600
24,576
SUN E4900 single-server SE614016*146G HD
286,720
24,576
SUN M5000 single-server S260012*450G HD
286,720
24,576
SUN M5000 SLS(Master)S260012*450G HD
92,160
24,576
SUN M5000 SLS(Dual)S260012*450G HD
460,800
No Fmdb
ATAE Cluster (400eNEs) S3900 (24*600G)
378,880
30,719
ATAE Cluster (800eNEs) S3900 (24*600G)
768,000
30,719
4.4 Management Capability

4.4.1 Single Server and Local/Remote HA Management
Capability
Server Type
CPU
Sun Fire V890
2*1.8GHz
8Gb
Sun Fire V890
4*1.8GHz
16Gb
Sun Fire V890
6*1.8GHz
24Gb
Sun Fire V890
8*1.8GHz
32Gb
Sun Fire E4900
4*1.8GHz
16Gb
Sun Fire E4900
8*1.8GHz
32Gb
Sun Fire E4900
12*1.8GHz
48Gb
SUN T5220
SUN M4000
SUN M4000
1*1.4GHz/4C
ore
2*2.4GHz/8C
ore
4*2.4GHz/16
Core
Memory
8Gb
16Gb
32Gb
Disk
Local:6 * 146 GB;
Diskarray:16*146G/Diskarray:12*450G
Local:6 * 146 GB;
Local:6 * 146 GB;
Local:6 * 146 GB;
Local:2 * 146 GB;
Local:2 * 146 GB;
Local:2 * 146 GB;
Local:6 * 146 GB
Local:2 * 146 GB;
Local:2 * 146 GB;

Equivalent
NEs
50
100
140
190
120
230
280
35
100
190
Page 88 of 93

4*2.4/2.5/2.6
SUN M5000
GHz/16Core
6*2.4/2.5/2.6
SUN M5000
GHz/24Core
8*2.4/2.5/2.6
SUN M5000
GHz/32Core
32Gb
48Gb
64Gb
Local:2 * 146 GB;
190
Local:2 * 146 GB;
270
Local:2 * 146 GB;
340
4.4.2 Sun SLS Management Capability

This specification describe mainly management capability of standard configuration Sun SLS network
mode ,only Sun M5000 Server8P64G, other nonstandard SLS isnt included due to various machine and
various configuration.
It support 6+1 network mode at present, and only Sun M5000 Server8P64G ,as the dual server
adding, the system management capability trend as follows
N+1(M5000)
Complexity
Remark
ExampleM5000 8P
Management Capability
Single
Master share all
340 eNE
2:1
1.6
Master share 0.5
544 eNE
3:1
2.3
Master share 0.2
782 eNE
4:1
3.6
3.6slave share
1224eNE
5:1
4.8
4.8slave share
1632eNE
6:1
6slave share
2040eNE
4.4.3 ATAE Cluster Management Capability

Configuration
Modes (eNEs)
3G Cells
2G TRX
LTE Cells
(GP=30/60)
(GP=30/60)
(GP=30/60)
KPI
ALL
KPI
ALL
KPI
ALL
400
20,000
14,000
50,000
30,000
24,000
16,800
800
40,000
28,000
100,000
60,000
48,000
33,600

Page 89 of 93
4.5 Number of Concurrent Users

The maximum number of concurrent users refers to the maximum number of clients connected to the M2000
server running under full load. In typical scenarios, these clients cannot perform the same operations concurrently.
We can assume that the clients are performing the following operations:
The maximum number of concurrent users refers to the maximum number of clients connected to
the M2000 server running under full load. In typical scenarios, these clients cannot perform the
same operations concurrently. We can assume that the clients are performing the following
operations:
At most a third of clients are generating reports (such as performance reports, configuration reports,
and alarm reports) and making analysis.
At most a third of clients are performing the following operations alternatively: monitoring and
tracing panel status, querying configuration data or performance results, starting MML clients,
issuing maintenance commands, and analyzing results.
At most a sixth of clients are performing security operations, such as user and rights information
maintenance and log analysis.
At most a third of clients are upgrading software and managing licenses.
At most a third of clients are analyzing and transmitting configuration data to NEs.
At most a sixth of clients are performing CME-related operations (when the CME is deployed on
the M2000 server).
4.5.1 Single Server Support Number of Concurrent Users

Maximum Number of Concurrent Users
Sun Fire V890(2CPU)
30
Sun Fire V890(4CPU)
40
Sun Fire V890(8CPU)
60
50
80

Page 90 of 93

80
Sun T5220
25
Sun M4000(2CPU)
40
Sun M4000(4CPU)
60
Sun M5000(4CPU)
60
Sun M5000(6CPU)
80
Sun M5000(8CPU)
100
The preceding table is also applicable to the M2000 that adopts the Citrix networking solution.
4.5.2 Sun SLS Support Number of Concurrent Users

Server Configuration(Net Type)
N:1
120
NotesN<=6; only Sun M50008P64G Server SLS
4.5.3 ATAE Support Number of Concurrent Users

Server Configuration(Net Type)
100
100
4.6 Impact Factors of the Management Capability
PRS: If the PRS application developed together with M2000 will use M2000 resources, and the
management capability will descend 30%.
NetEcoIf the NetEco application developed together with M2000 will use M2000 resources, and
the management capability will descend 10%.
iSStar scripts or scheduled tasks: if self-develeped scripts or scheduled tasks are excuted, there
might be impact on the system resources usage and CPU workloads. The exact impact differs
greatly depends on the actual commands excuted.

Page 91 of 93
Owing to the differences between the onsite and laboratory environments, the actual management capability
of the M2000 system may differ from that described in this document. The data in this document only serves as a
reference.
4.7 Conditions and Restrictions

The management capability of the M2000 is evaluated on the basis of the following conditions:
Each M2000 server model supports a fixed maximum number of concurrent users.
The measurement periods for NEs of the same type (such as BSS8 and BSS9) are the same.
The following restriction should be taken into account:
The later the NE version, the more the performance measurement counters required to be set or
cancel. More counters require larger database space. As a result, the storage duration has to be
reduced when the counters increase.
4.8 Nastar/PRS solution dimensioning rules

4.8.1 ATAE Cluster Management Capability
Nastar
Configuration
Modes (eNEs)
GSM
UMTS
LTE
(1 eNE=125TRX)
(1 eNE=125TRX)
(1 eNE=20eNodeB)
400
50,000
25,000
800
100,000
50,000
Maxium
100,000
50,000
2,000
800 eNEs
800 eNEs
100 eNEs
PRS:
Configuration
Modes (eNEs)
GSM
UMTS
LTE
(1 eNE=125TRX)
(1 eNE=62.5CELL)
(1 eNE=62.5CELL)
400
50,000
25,000
25,000
800
100,000
50,000
50,000

Page 92 of 93

Maxium
100,000
50,000
50,000
800 eNEs
800 eNEs
800 eNEs
4.8.2 HP DL 580 Management Capability

The typical computers for the Nastar/PRS server is HP DL580. The system capacity of Nastar/PRS
for HP DL580 is listed as below.
Network Type Traffic Index
Nastar Management Capability
PRS Management Capability
GSM
TRX
<=50000
<=35000
UMTS
Cell
<=50000
<=15000
LTE
Cell
<=10000
<=15000
<=1
<=1
Hybrid type(*) Saturation

(P)(**)
Note:
*: Hybrid type means the network consists of 2 standard network or more. For example, GSM +
UMTS.
**: Management capability saturation: P = x / m + y / n +
x , y: number of the actual network dimensioning in a mode
m , n: value of system management capability in the relevant mode.
The Management capability is calculated based on the common performance counter measurement
with period of half an hour.

Page 93 of 93

GBSS14 0 Dimensioning Rules 01 (20120630)

Hochgeladen von

Dokumentinformationen

Originaltitel

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

GBSS14 0 Dimensioning Rules 01 (20120630)

Hochgeladen von

Copyright:

Verfügbare Formate

GBSS14.

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2012. All rights reserved.

Huawei Technologies Co., Ltd.

Huawei Industrial Base

GBSS14.0 Dimensioning Rules

Huawei Proprietary and Confidential

GBSS14.0 Dimensioning Rules

Huawei Proprietary and Confidential

GBSS14.0 Dimensioning Rules

BTS3012 and 3900 series BTS Dimensioning rules are included.

Huawei Proprietary and Confidential

GBSS14.0 Dimensioning Rules

FFiigguurree22--11 Logical structure of the BTS3012/BTS3012AE

FFiigguurree22--22 Board configurations of the BTS3012/BTS3012AE common subrack

Huawei Proprietary and Confidential

GBSS14.0 Dimensioning Rules

FFiigguurree22--33 Fully configured DTRU subracks

Huawei Proprietary and Confidential

GBSS14.0 Dimensioning Rules

FFiigguurree22--44 Fully configured DAFU subrack

Table 2-2 BTS3012/BTS3012AE RF Unit Specification

2.1.2 BTS3012/BTS3012AE Typical Configuration

Huawei Proprietary and Confidential

GBSS14.0 Dimensioning Rules

(1) Transmission subrack

(2) Common subrack (3) Fan subrack

(4) DTRU subrack

(5) DAFU subrack

(6) Power supply unit

(7) Signal lightning protection subrack

FFiigguurree22--55 BTS3012 (-48V DC) in full configuration

Huawei Proprietary and Confidential

GBSS14.0 Dimensioning Rules

FFiigguurree22--66 BTS3012AE in full configuration

Huawei Proprietary and Confidential

GBSS14.0 Dimensioning Rules

Note:In the above table, each DDPU is configured with an antenna.

Note: In the above table, each cell is configured with an antenna.

Huawei Proprietary and Confidential

GBSS14.0 Dimensioning Rules

FFiigguurree22--77 The S1, S3 and S4, DTRU is 40w configurations

2.1.3 BTS3012/3012AE Feature Configurations

Huawei Proprietary and Confidential

GBSS14.0 Dimensioning Rules

2.2 3900 Series BTS

The indoor baseband processing unit BBU3900

The indoor radio frequency unit RFU

The outdoor Remote Radio Unit (RRU)

Huawei Proprietary and Confidential

GBSS14.0 Dimensioning Rules

FFiigguurree22--88 Units and auxiliary devices of the 3900 series BTS

Huawei Proprietary and Confidential

GBSS14.0 Dimensioning Rules

FFiigguurree22--99 Application scenarios of the 3900 series BTSs

Cabinet macro BTS

2.2.1 3900 Series BTS Basic Module Configuration

Huawei Proprietary and Confidential

GBSS14.0 Dimensioning Rules

FFiigguurree22--1100 Structure of the BBU3900 Subrack

Configured only in slot 6 (both slots 5

Configured only in slot 16

Preferentially configured in slot 19 in