Huawei GSM GBSS13.0 Dimensioning Rules

GBSS13.0 Dimensioning Rules

Issue V1.0

Date 2011-11-30

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2011. 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: [email protected]

http://www.huawei.com/

mailto:[email protected]


Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd. Page 3 of 81

Contents

1 Introduction ..................................................................................................................................... 4

2 BTS ................................................................................................................................................... 5

2.1 3900 Series BTS ............................................................................................................................................... 5

2.2 GSM Network Dimensioning ......................................................................................................................... 16

2.3 GSM Link Budget Procedure ......................................................................................................................... 17

2.4 GPRS/EDGE Coverage Dimensioning .......................................................................................................... 20

2.5 GSM Capacity Dimensioning Procedure ....................................................................................................... 20

2.6 Abis Transmission Dimensioning ................................................................................................................... 25

2.7 Case Study ...................................................................................................................................................... 28

2.8 Counters Related to Capacity ......................................................................................................................... 29

3 BSC ................................................................................................................................................. 31

3.1 Configurations Standards of BSC6900 .......................................................................................................... 31

3.2 BSC Service Processing Units Dimensioning ................................................................................................ 36

3.3 BSC Interface Dimensioning.......................................................................................................................... 41

3.4 BSC subrack and cabinet ................................................................................................................................ 67

3.5 Impact of traffic model on Configuration....................................................................................................... 68

3.6 Counters Related to Capacity ......................................................................................................................... 70

4 OMC .............................................................................................................................................. 72

4.1 Network Management Capability .................................................................................................................. 72

4.2 Equivalent NE Conversion Tables .................................................................................................................. 73

4.3 Data Storage Capability ................................................................................................................................. 74

4.4 Management Capability ................................................................................................................................. 77

4.5 Number of Concurrent Users ......................................................................................................................... 78

4.6 Impact Factors of the Management Capability............................................................................................... 80

4.7 Conditions and Restrictions ........................................................................................................................... 80

4.8 Nastar/PRS solution dimensioning rules ........................................................................................................ 80




1 Introduction

This document is to introduce the Dimensioning rules for Huawei’s GSM products including

BTS and BSC. It is based on release GBSS13.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).




2 BTS

3900 series BTS Dimensioning rules are included.

2.1 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.




FFFiiiggguuurrreee 222---111 Units and auxiliary devices of the 3900 series BTS




FFFiiiggguuurrreee 222---222 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.1.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.




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.

FFFiiiggguuurrreee 222---333 Structure of the BBU3900 Subrack

One GTMU is mandatory configuration. Others such as UTRPb4 are optional depended on requirements.

Table 2-1 Configuration principles of BBU3900 GO boards

Board Name Optional/Mandatory Maximum

Quantity Slot Configuration Restriction

GTMU Mandatory 1 Slots 5 and 6 Configured only in slot 6 (both slots 5

and 6 are occupied)

FAN Mandatory 1 Slot 16 Configured only in slot 16

UPEU Mandatory 2 Slot 18 or 19 Preferentially configured in slot 19 in

the case of only one UPEU

USCU Optional 1 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 1 Slot 0 or 4 Preferentially configured in slot 4

UEIU Optional 1 Slot 18 -

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.

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 multi-

carrier 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 multi-

carrier 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 dual-

polarized 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.1.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).




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-2 Typical configurations when BTS3900 GSM uses the DRFU

GSM Configurations

S1/1/1

(in Non-combining Mode)

S2/2/2


S3/3/3

(in Combining Mode)

S4/4/4

(in Combining Mode)

S4/4/4


S6/6/6

(in Combining Mode)

S8/8/8

(in Combining Mode)

Cabinet 1 1 1 1 1 2 2

BBU 1 1 1 1 1 1 1

GTMU 1 1 1 1 1 1 1

DRFU 3 3 5 6 6 9 12

Dual

Transceiver

(Per TRX)

0 3 4 6 6 9 12

Antenna

system

3 3 3 3 6 6 6




Table 2-3 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 1 1 1 1 1 1

BBU 1 1 1 1 1 1

GTMU 1 1 1 1 1 1

GRFU 3 3 3 3 3 6

Multiple Transceiver

(Per TRX)

0 3 6 9 15 18

Antenna system 3 3 3 3 3 3

BTS3900A

If the BBU3900 is housed in APM30 or TMC, RFU module is housed in outdoor RF cabinet,

they form a GSM BTS3900A.




FFFiiiggguuurrreee 222---444 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-4 Typical configurations when BTS3900A GSM uses the DRFU

GSM Configurations

S1/1/1


S2/2/2


S3/3/3

(in Combining Mode)

S4/4/4

(in Combining Mode)

S4/4/4


S6/6/6

(in Combining Mode)

S8/8/8

(in Combining Mode)

Cabinet 1 1 1 1 1 2 2

BBU 1 1 1 1 1 1 1

GTMU 1 1 1 1 1 1 1

DRFU 3 3 5 6 6 9 12

Dual

Transceiver

(Per TRX)

0 3 4 6 6 9 12

Antenna

system

3 3 3 3 6 6 6

Table 2-5 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 1 1 1 1 1 1

BBU 1 1 1 1 1 1

GTMU 1 1 1 1 1 1

GRFU 3 3 3 3 3 6


(Per TRX)

0 3 6 9 15 18





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-6 Typical configurations when BTS3900L GSM uses the DRFU

GSM Configurations

S1/1/1


S2/2/2


S3/3/3

(in Combining Mode)

S4/4/4

(in Combining Mode)

S4/4/4


S6/6/6

(in Combining Mode)

S8/8/8

(in Combining Mode)

Cabinet 1 1 1 1 1 1 1

BBU 1 1 1 1 1 1 1

GTMU 1 1 1 1 1 1 1

DRFU 3 3 5 6 6 9 12

Dual

Transceiver

(Per TRX)

0 3 4 6 6 9 12

Antenna

system

3 3 3 3 6 6 6

Table 2-7 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 1 1 1 1 1 1

BBU 1 1 1 1 1 1

GTMU 1 1 1 1 1 1

GRFU 3 3 3 3 3 6


(Per TRX)

0 3 6 9 15 18


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-8 Typical configurations when DBS3900 GSM uses the RRU3004

GSM Configuration

S1/1/1

in Non-combining Mode

S2/2/2


S3/3/3

in Combining Mode

S4/4/4

in Combining Mode

S4/4/4


S6/6/6

in Combining Mode

S8/8/8

in Combining Mode

Cabinet

(optional)

1 1 1 1 1 2 2

BBU 1 1 1 1 1 1 1

RRU3004 3 3 6 6 6 9 12

Dual

Transceiver

(Per TRX)

0 3 4 6 6 9 12

Antenna

system

3 3 3 3 6 6 6

Table 2-9 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) 1 1 1 1 1 1

BBU 1 1 1 1 1 1

RRU3008 3 3 3 3 3 6


(Per TRX)

0 3 6 9 15 18


2.1.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-10 PBT configurations

Number of TRXs in a Cell Number of DRFU and

RRU3004 Modules

Number of Antennas

1 TRX 1 1





RRU3004 Modules

Number of Antennas

2 TRXs 2 1

Transmit Diversity Configuration

Currently, only DRFU, RRU3004, and RRU3008 modules support transmit diversity. The transmit diversity

configurations are as follows:

Table 2-11 Transmit diversity configurations for DRFU and RRU3004


RRU3004 Modules

Number of Antennas

1 TRX 1 1

2 TRXs 2 2

Table 2-12 Transmit diversity configurations for RRU3008

Number of TRXs in a Cell Number of RRU3008

Modules

Number of Antennas Maximum Power

Configuration (Using

RRU3008 V2 Modules as

an Example)

1 TRX 1 1 40 W

2 TRXs 1 1 20 W

3 TRXs 1 1 13 W

4 TRXs 1 1 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-13 Inter-module RF FH configurations

Number of TRXs Supported by Two GRFU Modules Transmit Power with Inter-

Module RF FH Disabled

(Even Distribution of

Carriers on Each Module)

Transmit Power with Inter-

Module RF FH Enabled




Number of TRXs Supported by Two GRFU Modules Transmit Power with Inter-

Module RF FH Disabled

(Even Distribution of

Carriers on Each Module)

Transmit Power with Inter-

Module 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.2 GSM Network Dimensioning

2.2.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.




FFFiiiggguuurrreee 222---555 Radio network dimensioning process

2.3 GSM Link Budget Procedure

2.3.1 Introduction

Link budget dimensioning is used to obtain cell coverage range. After calculating rge maximum allowed

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.




FFFiiiggguuurrreee 222---666 Coverage dimensioning procedure

Analyze coverage

requirements

Create link budgets

Obtain the cell radius

Calculate the coverage area

for a BTS

Specify the number of BTSs

within areas

Maximum path loss

Maximum cell radius

Maximum BTS coverage area

For details about uplink budget dimensioning, see section 2.3.2 "Uplink Budget Dimensioning."

For details about downlink budget dimensioning, see section 2.3.3 "Downlink Budget Dimensioning."

For details about uplink/downlink budget balance dimensioning, see section 2.3.4 "Uplink/Downlink Budget

Balance Dimensioning."

2.3.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 - Lc–Lb + Ga_BTS + Gdb - LfBTS - RsBTS - P_Sur

where

PL_UL is the loss of uplink maximum transmission path

PoutMS is the MS power

Lf_MS is the MS feeder loss




Ga_MS is the MS antenna gain

Lc is the clutter loss

Lb is the manpower loss

Ga_BTS is the BTS antenna gain

Gdb is the diversity gain

Lf_BTS is the loss of BTS feeder

Rs_BTS is the BTS receiver sensitivity

P_Sur is the surplus power

2.3.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 - Ljb_BTS - Lcb_BTS - Lf_BTS + Ga_BTS - Lc - Lb + Ga_MS - Lf_MS - Rs_MS - P_Sur

PL_DL is the loss of downlink maximum transmission path

Pout_BTS is the BTS max. transmit power

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 manpower 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 surplus power

2.3.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

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:

Sector

Sector

SectorO

3radius Cell38

9

2radius Cell4

33

6mniradius Cell32

3

area coverage BTS

2

2

2

，

，，

，，

＝

3. Calculating the number of BTSs

area coverage BTS

area CoverageBTSs ofNumber ＝

2.4 GPRS/EDGE Coverage Dimensioning

2.4.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-to-

interference (C/I) ratio.

2.5 GSM Capacity Dimensioning Procedure

2.5.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.

FFFiiiggguuurrreee 222---777 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.5.2 "Capacity Dimensioning."

For details about traffic analysis, see section 2.5.3 "Traffic Analysis."

For details about calculation on the number of traffic channels, see section 2.5.4 "Calculation on the Number

of Traffic Channels."

For details about GPRS/EDGE capacity dimensioning, see section 2.5.5 "GPRS/EDGE/EGPRS2 Capacity

Dimensioning."

2.5.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.

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.5.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.5.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 half-

rate 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.5.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 high-

precision 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.




FFFiiiggguuurrreee 222---888 GPRS/EDGE/EGPRS2 capacity dimensioning procedure

Start

Calculate the IP bandwidth of each

PDCH for a service

End

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

The formula for calculating the traffic volume of each service for a subscriber during busy hours is as

follows:

(kbit/s) vhanneliceach traff ofBandwidth

bpsratio) average-to-peak theng(consideri

(bit/s)hour busy during subscribereach ofBandwidth

）（＝

Traffic volume of each

subscriber performing

data services during busy

hours

The number of maximum subscribers in a cell can be calculated by using the iteration algorithm.




FFFiiiggguuurrreee 222---999 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.




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.6 Abis Transmission Dimensioning

2.6.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.




2.6.2 Abis over TDM

FFFiiiggguuurrreee 222---111000 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.




2.6.3 Abis over IP

FFFiiiggguuurrreee 222---111111 Procedure for dimensioning Abis transmission in IP mode

Start

Calculate the peak traffic

volume in each cell

Calculate the number of 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.

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:

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 CS-

4 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.7 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




2.8 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

http://wirelessinfo/hedex/pages/31184922/05/31184922/05/resources/mbsc/m-perf/Mt-26983.html




LAPDLNK.DISC.PS.PAGS

VS.IPPM.Bits.MeansTx

VS.IPPM.Peak.Bits.RateTx

VS.IPPM.Peer.Bits.MeansRx

VS.IPPM.Peer.Peak.Bits.RateRx




3 BSC

3.1 Configurations Standards of BSC6900

3.1.1 Evolution of BSC6000 to BSC6900

GBSS13.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




Board Ports Board Ports

IP FG2c 12 FE / 4 GE electrical FG2a 8 / 2

IP GOUc 4 GE optical GOUa 2

IP over E1/T1 POUc 4 optical cSTM-1/OC-3 OIUa 1

The BSC6900 supports following hardware versions. The boards of HW68 R11 are the same as boards used in

BSC6810.

Hardware Version Corresponding Board

HW60 R8 DPUc, DPUd, XPUa, SCUa, TNUa, GCUa, OMUb, EIUa,

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, and POUc

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.

3.1.2 BSC6900 Hardware Architecture

Classification of BSC6900 GSM cabinets:

Cabinet Contained Subrack Configuration Principle

MPR 1 MPS, 0–2 EPSs Per

MPR

Only one MPR is configured.




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

0–1 EPR is configured.

TCR 1-3 TCS Per TCR, Max

4 TCS for one BSC

Based on the requirement for traffic capacity,

0–2 EPR is configured.

Classification of BSC6900 GSM subracks:

Subrack Quantity Function

MPS 1 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







BSC6000/6900 Model

768

GMIP00M76800 When the TRXNoPerBSC is in the range of 513-


BSC6000/6900 Model

1280



BSC6000/6900 Model

1536

GMIP0M153600 When the TRXNoPerBSC is in the range of

1281–1536, select this model.

BSC6000/6900 Model

2048

GMIP0M204800 When the TRXNoPerBSC is in the range of

1537–2048, select this model.

2. In GBSS12.0 The BSC6900 GSM supports 7 basic models as follows when HW69 R11 boards are used.


BSC6900 GSM

Model 640

GMIP00M64000 When the TRXNoPerBSC is in the range of 1-640,

select this model.

BSC6900 GSM

Model 1280



BSC6900 GSM

Model 1920



BSC6900 GSM

Model 2560



BSC6900 GSM

Model 3072



BSC6900 GSM

Model 3584



BSC6900 GSM

Model 4096



3. 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 in V900R013.




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.

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.

(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.




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)

IWF function:

3740 channels

For the TC

function, the left

column lists the

specifications of

WP1D000DPU02

when non-

wideband AMR

coding schemes

are used. When

wideband AMR

coding schemes

are used, the

specifications of

WP1D000DPU05

are 2/3 of those

listed in the left

column.

For the IWF

function, the

specifications of

WP1D000DPU02

remain unchanged

regardless of

whether non-

wideband 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+).




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 non-

wideband AMR

coding schemes

are used. When

wideband AMR

coding schemes

are used, the

specifications of

WP1D000DPU05

are 2/3 of those

listed in the left

column.

For the IWF

function, the

specifications of

WP1D000DPU05

remain unchanged

regardless of

whether non-

wideband 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

640 TRXs

640 Cells

640 BTSs

The BHCA is

based on Huawei

default traffic

model.

3.2.2 Configuration principles of Service processing units




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/76800)

+ 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:




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.




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. Cross-

MPU 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.




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/Iur-

g

WP1D000PEU00 PEUa IP Interface Unit (32

E1/T1)

TDM/FR or IP

transmission:

A/Abis/Lb/Gb/Iur-g




WP1D000FG201 FG2c IP Interface Unit (12

FE/4 GE, Electrical)

IP transmission:


g

WP1D000GOU01 GOUc IP Interface Unit (4

GE, Optical)

IP transmission:


g

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

Model Trans

mission

Type

Port Type Port No. Number 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 Throughput (Mbit/s)

WP1D000EIU00 TDM TDM E1 32 384 960 3840 N/A

WP1D000OIU00 TDM TDM

CSTM-1

1 384 1920 7168 N/A

WP1D000PEU00 TDM TDM

CSTM-1

32 384 6144 N/A 64

WP1D000POU01

TDM TDM

CSTM-1 4 512

3907(with

DPUc)/768

0(with

DPUf)

7168 504

HDLC HDLC

CSTM-1

4 2048 N/A N/A N/A

IP IP CSTM-1 4 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

4 2048 23,040 N/A 1024




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

Caution: Service links and LAPD signaling links cannot share one 64 kbit/s timeslot.

1. 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:

− TRXNoTDME1 and MaxPDCHRatio are input parameters for BSC and network

configuration.

− CHPerTRX is an advanced input parameter.

2. 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.

− 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% 1

CS2 0% 1

CS3 0% 2

CS4 0% 2

MCS1 0% 1

MCS2 0% 1

MCS3 0% 2

MCS4 0% 2

MCS5 0% 2

MCS6 100% 2

MCS7 0% 3

MCS8 0% 4

MCS9 0% 4

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.

− SiteNoTDME1, TRXNoTDME1 and AbisLAPDMultiRate are input parameters

for BSC and network configuration.

4. 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).

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

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 (1-

MaxPDCHRatio)

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

(kbps)

Frame Len(bit)

CS: TRAU

PS: RLC/MAC + Inband Control

IP over E1/STM1 Frame Len

(bit)

IP over E1/STM1 Thput per Unit

(kbps)

FR 13 264 576 14.1

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:



used as examples.

Codec Ratio IP over E1/STM1 Frame Len

(bit)


(kbps)

FR 70% 576 14.1




Codec Ratio IP over E1/STM1 Frame Len

(bit)


(kbps)

HR 30% 432 2x10.5

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:

− 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:

CSVAD indicates the voice activation factor, which is an advanced input parameter.

Total Abis interface bandwidth required by TCHs:

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:

− 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:


(kbps)

Frame Len(bit)

CS: TRAU


IP over E1/STM-1 Frame Len

(bit)

IP over E1/STM-1 Thput per Unit

(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 Len

(bit)


(kbps)

CS1 0% 536 26.2




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

(bit)


(kbps)

CS2 0% 616 30.1

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

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:

PSUsage indicates the voice activation factor, which is an advanced input parameter.

Total Abis interface bandwidth required by PDCHs:

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:

− 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.

4. 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

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:

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:


(kbps)

Frame Len(bit)

CS: TRAU


IP over FE/GE Frame Len

(bit)

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

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

(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




− 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:

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

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:


(kbps)

Frame Len(bit)

CS: TRAU


IP over FE/GE Frame Len

(bit)


(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





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:

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 IP over FE/GE Frame Len

(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:

− 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.

− 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:

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:

− 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.

4. 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.

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

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:



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:

− 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.

− The value of MaxACICPerBSC is obtained through the calculation of the overall


3. 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.

Simplified calculation of the BSC capacity:

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.

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.

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

1. 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))




Speech Version

(Code Scheme)

Voice Data Bit Rate

(Service Bit Rate in RLC/MAC layer)

Voice Frame Len/20 ms

(Bit)

Voice Frame Bit Rate/UM Channel (kbit/s)

Mux Total Size

(Bit) UDP MUX

Avg Frame Bit Rate

(kbit/s) UDPMUX

FR 13 kbit/s 888 21.7 3856 11.8

EFR 12.2 kbit/s 872 21.3 3728 11.4

AMR-FR12.2 12.2 kbit/s 888 21.7 3856 11.8

AMR-FR10.2 10.2 kbit/s 848 20.7 3536 10.8

AMR-FR7.95 7.95 kbit/s 800 19.5 3152 9.6

AMR-FR7.40 7.40 kbit/s 792 19.3 3088 9.4

AMR-FR6.70 6.70 kbit/s 776 18.9 2960 9.0

AMR-FR5.9 5.9 kbit/s 760 18.6 2832 8.6

AMR-FR5.15 5.15 kbit/s 744 18.2 2704 8.3

AMR-FR4.75 4.75 kbit/s 736 18.0 2640 8.1

HR 5.6 kbit/s 744 18.2 2704 8.3

AMR-HR7.95 7.95 kbit/s 800 19.5 3152 9.6

AMR-HR7.40 7.40 kbit/s 792 19.3 3088 9.4

AMR-HR6.70 6.70 kbit/s 776 18.9 2960 9.0

AMR-HR5.9 5.9 kbit/s 760 18.6 2832 8.6

AMR-HR5.15 5.15 kbit/s 744 18.2 2704 8.3

AMR-HR4.75 4.75 kbit/s 736 18.0 2640 8.1

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.




− 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:

− 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.



3. 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:




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

x 4

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.

− The value of MaxAterCICPerBSC is obtained through the calculation of the overall


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.


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




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:

The value of MaxAterCICPerBSC is obtained through the calculation of the overall


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:

− 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.

Important: In IP over STM1 mode, an SS7 link is switched from an Ater interface

to the BSC side according to the TDM timeslot.

4. Calculating the number of STM1 ports required by an Ater interface:




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:





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.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).

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 User’s behavior:

Below is the BHCA weight in BSC6900 V900R013:

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%




Service Type CS BHCA Weight

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)

In GBSS13.0, 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:

s

BASIC Procedure (User operation) Performance (Sum of Cell)

CS LUs (Location Update) A300F: A300F:Channel Requests (Location Updating)

average IMSI Attaches (IMSI Attaches) From MSC

average IMSI Detaches (IMSI Detaches) From MSC

CS calls

A300A:Channel Requests (MOC) + A300C:Channel

Requests (MTC) - CA334A:Total Uplink Point-to-Point

Short Messages - CA334B:Total Downlink Point-to-Point

Short Messages

MR Reports S329: Number of Power Control Messages per Cell

CS SMS (sending and receiving)

CA334A: Total Uplink Point-to-Point Short Messages

+CA334B: Total Downlink Point-to-Point Short

Messages




Intra-Hos (intra BSC)

CH310: Number of Outgoing Internal Inter-Cell

Handover Requests

Inter-HOs (Inter BSC)

CH330: Outgoing External Inter-Cell Handover

Requests+CH340: Incoming External Inter-Cell

Handover Requests

CS Paging A330: Delivered Paging Messages for CS Service

Uplink TBF Est

A9201: Number of Uplink EGPRS TBF Establishment

Attempts+A9001: Number of Uplink GPRS TBF

Establishment Attempts

Downlink TBF Est

A9301: Number of Downlink EGPRS TBF

Establishment Attempts+A9101: Number of Downlink

GPRS TBF Establishment Attempts

PS Paging A331: Delivered Paging Messages for PS Service

3.6 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











4 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:

（1）Processing the management information (including collection, import-to-database, query, and MML

commands) of the network within a unit time.

（2）Storing data for a certain period. For example, storing alarm data for x days and performance data for y

days.

（3）Supporting the number of concurrent users required by certain services (based on logical application

scenarios).




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




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)

NE Version Conversion Unit Number of Equivalent NEs

KPI-Counter All-Counter

GBSS12.0 1 TRX 1/125 1/75

GBSS13.0 1 TRX 1/125 1/75

Equivalent NE conversion of GSM NEs (15-minute)

NE Version Conversion Unit Number of Equivalent NEs

KPI-Counter All-Counter

GBSS12.0 1 TRX 1/75 1/45

GBSS13.0 1 TRX 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 General Alarm Processing Rate

(piece/s)

Peak Alarm Processing

Rate (piece/s)

Sun Fire V890 (2CPU) 10 30



Sun Fire E4900(4CPU) 18 55

Sun Fire E4900(8CPU) 30 100

Sun Fire E4900(12CPU) 38 125

Sun T5220 5 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

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

Server Configuration Maximum Number of Alarms (1,000pcs) Log Storage Duration (month)

Alarm List Alarm Logs Event Logs

Sun T5220 20k 1250 1250 <3

Sun Fire V890 20k 10060 10060 <3

Sun Fire E4900 20k 10060 10060 <3

Sun M4000 20k 12580 12580 <3

Sun M5000 20k 12580 12580 <3

4.3.3 Performance Data Storage Capability

The specific formula is as follows:




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.

Server Configuration

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 SE3320（8*73G HD） 92,160 12,228

SUN V890 single-server SE6140（16*146G HD） 286,720 24,576

SUN M4000 single-server S2600（12*450G HD） 286,720 24,576

SUN E4900 single-server SE6140（14*73G HD） 153,600 24,576




SUN E4900 single-server SE6140（16*146G HD） 286,720 24,576

SUN M5000 single-server S2600（12*450G HD） 286,720 24,576

SUN M5000 SLS(Master)S2600（12*450G HD） 92,160 24,576

SUN M5000 SLS(Dual)S2600（12*450G HD） 460,800 No Fmdb

4.4 Management Capability

4.4.1 Single Server and Local/Remote HA Management

Capability

Server Type CPU Memory Disk Equivalent

NEs

Sun Fire V890 2*1.8GHz 8Gb Local:6 * 146 GB;

Diskarray:16*146G/Diskarray:12*450G 50







Sun Fire E4900 4*1.8GHz 16Gb Local:2 * 146 GB;






SUN T5220 1*1.4GHz/4C

ore 8Gb Local:6 * 146 GB 35

SUN M4000 2*2.4GHz/8C

ore 16Gb

Local:2 * 146 GB;


SUN M4000 4*2.4GHz/16

Core 32Gb

Local:2 * 146 GB;


SUN M5000 4*2.4/2.5/2.6

GHz/16Core 32Gb

Local:2 * 146 GB;


SUN M5000 6*2.4/2.5/2.6

GHz/24Core 48Gb

Local:2 * 146 GB;


SUN M5000 8*2.4/2.5/2.6

GHz/32Core 64Gb

Local:2 * 146 GB;





4.4.2 Sun SLS Management Capability

This specification describe mainly management capability of standard configuration Sun SLS network

mode ,only Sun M5000 Server（8P、64G）, other nonstandard SLS isn’t included due to various machine and

various configuration.

It support 6+1 network mode at present, and only Sun M5000 Server（8P、64G） ,as the dual server

adding, the system management capability trend as follows：

N+1(M5000) Complexity Remark Example：M5000 8P

Management Capability

Single 1 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.6（slave share） 1224eNE

5:1 4.8 4.8（slave share） 1632eNE

6:1 6 6（slave share） 2040eNE

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

Server Configuration Maximum Number of Concurrent Users

Sun Fire V890(2CPU) 30



Sun Fire E4900(4CPU) 50



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) Maximum Number of Concurrent Users

N:1 120

Notes：N<=6; only Sun M5000（8P、64G） Server SLS




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%.

NetEco：If 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.

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

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

Hybrid type(*) Saturation

(P)(**)

<=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.

Documents

Huawei GSM GBSS13.0 Dimensioning Rules