Professional Documents
Culture Documents
0 Dimensioning Rules
Issue
01
Date
2012-06-30
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.
Website:
http://www.huawei.com
Email:
support@huawei.com
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
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
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
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.
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.
Page 7 of 93
Output power
carriers
DTRU
40W or 60W
Page 8 of 93
Page 9 of 93
S1 to S2
DTRU&DCOM
Combining
DTRU Combining
No Combining
DDPU
DCOM
DDPU
DCOM
DDPU
DCOM
Page 10 of 93
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
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
The diagram for connection of S1, S3 and S4 configurations are shown below.
Page 11 of 93
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
Page 12 of 93
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
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
Page 14 of 93
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.
Page 15 of 93
Optional/Mandatory Maximum
Quantity
Slot
Configuration Restriction
GTMU
Mandatory
Slots 5 and 6
FAN
Mandatory
Slot 16
UPEU
Mandatory
Slot 18 or 19
USCU
Optional
Slot 0 or 1
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.
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.
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.
Page 17 of 93
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
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
Multiple Transceiver
(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
Multiple Transceiver
(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
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
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
S1/1/1
S2/2/2
S3/3/3
S4/4/4
S6/6/6
S8/8/8
BBU
RRU3008
Multiple Transceiver
(Per TRX)
15
18
Antenna system
Number of Antennas
1 TRX
2 TRXs
Number of Antennas
1 TRX
2 TRXs
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
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
Page 24 of 93
Page 25 of 93
Analyze coverage
requirements
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."
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
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
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
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.
Number of BTSs
Coveragearea
BTS coveragearea
Page 28 of 93
Capacity dimensioning
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."
Page 29 of 93
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
Page 30 of 93
Start
End
The formula for calculating the traffic volume of each service for a subscriber during busy hours is as
follows:
The number of maximum subscribers in a cell can be calculated by using the iteration algorithm.
Page 31 of 93
Maximum number of
subscribers in a cell
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)
End
Page 32 of 93
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.
Page 33 of 93
End
Page 34 of 93
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
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%.
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
Traffic related
CELL.KPI.TCH.TRAF.ERL.TRAF
CELL.KPI.TCH.AVAIL.NUM
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
TRX.PWR.ADJUST.OFF.DUR
TRX.TS.PWR.ADJUST.OFF.TIMES
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
BSC
BSC6000
BSC6900
GMPS
MPS
Extended Subrack
GEPS
EPS
Transport
BSC6900
BSC6810&BSC6900
Page 39 of 93
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
HW69 R13
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..
Contained Subrack
1 MPS, 02 EPSs Per
Configuration Principle
Only one MPR is configured.
Page 40 of 93
TCR
Quantity
Function
MPS
EPS
0-3
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.
Model Name
Model
Configuration Description
BSC6000/6900 Model
256
BSC6000/6900 Model
512
Page 41 of 93
Model
Configuration Description
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
BSC6000/6900 Model
2048
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
Configuration Description
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
*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 :
Page 43 of 93
Page 44 of 93
Description
Function
Description
Specification
Condition
WP1D000DPU02
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
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
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
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
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
Page 46 of 93
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
Description
Remarks
MaxActivePDCHPerBSC
The following table describes the network requirements that should be considered
during the configuration of WP1D000XPU01.
Item
Description
Remarks
BHCA requirement
TRX Number
ERL Number
Page 48 of 93
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
Short Name
Description
Interface
WP1D000EIU00
EIUa
TDM transmission:
A/Ater/Abis/Lb
WP1D000OIU00
OIUa
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
TDM/FR or IP
transmission:
A/Abis/Lb/Gb/Iur-g
Page 50 of 93
FG2c
IP transmission:
A/Ater/Abis/Lb/Gb/Iurg
WP1D000GOU01
GOUc
IP Interface Unit (4
GE, Optical)
IP transmission:
A/Ater/Abis/Lb/Gb/Iurg
The OIUa board has been replaced by the enhanced POUc board. OIUa boards can be added as
required.
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
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.
The following table lists the number of 16 kbit/s timeslots on the Abis interface
occupied per coding scheme.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
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
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.
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.
Page 53 of 93
1.
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.
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
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
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
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.
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
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.
Average packet length on each TCH and average Abis interface bandwidth (kbit/s) when
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, 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.
CSVAD 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 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:
CSVAD indicates the voice activation factor, which is an advanced input parameter.
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
Calculating the PS service bandwidth:
Total number of PDCHs:
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:
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.
Page 57 of 93
50: 50 packet frames per second; 1024: 1,024 bits, equal to 1 kbit/s.
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
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:
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
(kbps)
CS1
0%
536
26.2
CS2
0%
616
30.1
Page 58 of 93
Ratio
(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
Average packet length on each PDCH and average Abis interface bandwidth (kbit/s)
when 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/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, 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.
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
In the preceding formula, 3 x 8 indicates the multiplex overhead when the Abis MUX
function is enabled.
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:
PSUsage indicates the voice activation factor, which is an advanced input parameter.
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
Calculating the LAPD link bandwidth:
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.
1.
Page 60 of 93
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 FEGE frame header = 8 x (8 + 20 + 38). It in turn covers the UDP frame
header, IP frame header, and MAC frame header.
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 FEGE mode when different
voice versions are used:
Service Type
CS: TRAU
IP over FE/GE
Frame Len
IP over FE/GE
Tput per unit
(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
5.15
120
680
16.6
AMR(HR)
4.75
112
672
16.4
Average packet length on each TCH and average Abis interface bandwidth (kbit/s) when
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:
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.
Codec
Ratio
(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.
Average packet length on each TCH and average Abis interface bandwidth (kbit/s) when
the Abis MUX is enabled:
The principle of the Abis MUX is that: the Abis IP over FEGE 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 (1,000 bytes).
Average number of packets that can be multiplexed:
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.
CSVAD indicates the voice activation factor, which is an advanced input parameter.
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:
In the preceding formula, 3 x 8 indicates the multiplex overhead when the Abis MUX
function is enabled.
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:
CSVAD indicates the voice activation factor, which is an advanced input parameter.
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
Calculating the PS service bandwidth:
Total number of PDCHs:
Abis IP over FEGE Equivalent PDCH number for PS = TRXNoIPFEGE x
CHPerTRX x MaxPDCHRatio
Page 63 of 93
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.
50: 50 packet frames per second; 1024: 1,024 bits, equal to 1 kbit/s.
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
CS: TRAU
IP over FE/GE
Frame Len
IP over FE/GE
Tput per unit
(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
Ratio
(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
Average packet length on each PDCH and average Abis interface bandwidth (kbit/s)
when the Abis MUX is enabled:
The principle of the Abis MUX is that: the Abis IP over FEGE 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 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, 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.
PSUsage indicates the voice activation factor, which is an advanced input parameter.
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:
PSUsage indicates the voice activation factor, which is an advanced input parameter.
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
Calculating the LAPD link bandwidth:
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.
FEGEUsage is an advanced input parameter. The available bandwidth of one GE is: 1000 x 1024 x
FEGEUsage.
Page 66 of 93
2.
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.
Page 67 of 93
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.
CSVAD indicates the voice activation factor, which is an advanced input parameter.
Page 68 of 93
3.
Page 69 of 93
1.
TRAU frame: indicates the voice payload consisting of voice and Cbit. The value
varies with coding schemes.
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:
50: 50 voice frames per second. 1024: 1,024 bits, equal to 1 Kbits.
CSVAD indicates the voice activation factor, which is an advanced input parameter.
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
(Code
Scheme)
FR
13 kbit/s
EFR
Voice
Frame Bit
Rate/UM
Channel
(kbit/s)
(kbit/s)
UDPMUX
888
21.7
3856
11.8
12.2 kbit/s
872
21.3
3728
11.4
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
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:
CSVAD indicates the voice activation factor, which is an advanced input parameter.
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:
The value of MaxACICPerBSC is obtained through the calculation of the overall
capacity of the BSC.
2.
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.
Page 72 of 93
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.
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
TRAU frame: indicates the voice payload consisting of voice and Cbit. The value
varies with coding schemes.
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.
50: 50 voice frames per second. 1024: 1,024 bits, equal to 1 Kbits.
CSVAD indicates the voice activation factor, which is an advanced input parameter.
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:
The value of MaxAterCICPerBSC is obtained through the calculation of the overall
capacity of the BSC.
2.
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.
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
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.
Page 75 of 93
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:
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)
Page 76 of 93
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 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
CS BHCA Weight
LU to CS call
31.25%
31.25%
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%
4.00%
4.00%
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
Page 78 of 93
CS calls
MR Reports
Messages
CH310: Number of Outgoing Internal Inter-Cell
Handover Requests
CH330: Outgoing External Inter-Cell Handover
Requests+CH340: Incoming External Inter-Cell
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
Page 79 of 93
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.
3.
Page 80 of 93
BSCRPT.KPI.TCH.TRAF.ERL.TRAF
BSCRPT.KPI.TCH.AVAIL.NUM
BSC.PSTRAN.UP.CS1.RLC.BLK
BSC.PSTRAN.UP.CS2.RLC.BLK
BSC.PSTRAN.UP.CS3.RLC.BLK
BSC.PSTRAN.UP.CS4.RLC.BLK
BSC.PSTRAN.DOWN.CS1.RLC.BLK
BSC.PSTRAN.DOWN.CS2.RLC.BLK
BSC.PSTRAN.DOWN.CS3.RLC.BLK
BSC.PSTRAN.DOWN.CS4.RLC.BLK
BSC.PSTRAN.UP.EGPRS.MCS1.RLC.DATA.BLK
BSC.PSTRAN.UP.EGPRS.MCS2.RLC.DATA.BLK
BSC.PSTRAN.UP.EGPRS.MCS3.RLC.DATA.BLK
BSC.PSTRAN.UP.EGPRS.MCS4.RLC.DATA.BLK
BSC.PSTRAN.UP.EGPRS.MCS5.RLC.DATA.BLK
BSC.PSTRAN.UP.EGPRS.MCS6.RLC.DATA.BLK
BSC.PSTRAN.UP.EGPRS.MCS7.RLC.DATA.BLK
BSC.PSTRAN.UP.EGPRS.MCS8.RLC.DATA.BLK
BSC.PSTRAN.UP.EGPRS.MCS9.RLC.DATA.BLK
BSC.PSTRAN.DOWN.EGPRS.MCS1.RLC.DATA.BLK
BSC.PSTRAN. DOWN.EGPRS.MCS2.RLC.DATA.BLK
Page 81 of 93
BSC.PSTRAN. DOWN.EGPRS.MCS3.RLC.DATA.BLK
BSC.PSTRAN. DOWN.EGPRS.MCS4.RLC.DATA.BLK
BSC.PSTRAN. DOWN.EGPRS.MCS5.RLC.DATA.BLK
BSC.PSTRAN. DOWN.EGPRS.MCS6.RLC.DATA.BLK
BSC.PSTRAN. DOWN.EGPRS.MCS7.RLC.DATA.BLK
BSC.PSTRAN. DOWN.EGPRS.MCS8.RLC.DATA.BLK
BSC.PSTRAN. DOWN.EGPRS.MCS9.RLC.DATA.BLK
Page 82 of 93
OMC
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
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%.
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:
All-Counter
1/125
1/75
1 TRX
1 TRX
KPI-Counter
All-Counter
1/75
1/45
10
30
Rate (piece/s)
Page 85 of 93
15
50
24
90
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
38
125
38
125
(unit: 10,000pcs)
Server Configuration
Alarm List
Alarm Logs
Event Logs
Sun T5220
125
125
<3
1006
1006
<3
1006
1006
<3
Sun M4000
1258
1258
<3
Sun M5000
1258
1258
<3
1258
1258
<3
1258
1258
<3
Page 86 of 93
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.
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
Performance
Database
Space (MB)
Alarm
Database
Space (MB)
46,080
3,072
286,720
24,576
92,160
12,228
286,720
24,576
Page 87 of 93
286,720
24,576
153,600
24,576
286,720
24,576
286,720
24,576
92,160
24,576
460,800
No Fmdb
378,880
30,719
768,000
30,719
CPU
2*1.8GHz
8Gb
4*1.8GHz
16Gb
6*1.8GHz
24Gb
8*1.8GHz
32Gb
4*1.8GHz
16Gb
8*1.8GHz
32Gb
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;
Diskarray:16*146G/Diskarray:12*450G
Local:6 * 146 GB;
Diskarray:16*146G/Diskarray:12*450G
Local:6 * 146 GB;
Diskarray:16*146G/Diskarray:12*450G
Local:2 * 146 GB;
Diskarray:16*146G/Diskarray:12*450G
Local:2 * 146 GB;
Diskarray:16*146G/Diskarray:12*450G
Local:2 * 146 GB;
Diskarray:16*146G/Diskarray:12*450G
Local:6 * 146 GB
Local:2 * 146 GB;
Diskarray:16*146G/Diskarray:12*450G
Local:2 * 146 GB;
Diskarray:16*146G/Diskarray:12*450G
Equivalent
NEs
50
100
140
190
120
230
280
35
100
190
Page 88 of 93
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
190
Diskarray:16*146G/Diskarray:12*450G
Local:2 * 146 GB;
270
Diskarray:16*146G/Diskarray:12*450G
Local:2 * 146 GB;
340
Diskarray:16*146G/Diskarray:12*450G
Complexity
Remark
ExampleM5000 8P
Management Capability
Single
340 eNE
2:1
1.6
544 eNE
3:1
2.3
782 eNE
4:1
3.6
3.6slave share
1224eNE
5:1
4.8
4.8slave share
1632eNE
6:1
6slave share
2040eNE
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
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 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).
30
40
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.
N:1
120
100
100
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.
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 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.
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
100,000
50,000
50,000
800 eNEs
800 eNEs
800 eNEs
GSM
TRX
<=50000
<=35000
UMTS
Cell
<=50000
<=15000
LTE
Cell
<=10000
<=15000
<=1
<=1
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