0% found this document useful (0 votes)
52 views65 pages

DBS3900 LTE FDD Configuration Principles

THANKS

Uploaded by

AbdikaniMohamoud
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
52 views65 pages

DBS3900 LTE FDD Configuration Principles

THANKS

Uploaded by

AbdikaniMohamoud
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 65

RAN16.

0 RNC in Pool
Configuration Principles

Issue 02

Date 2014-09-15

HUAWEI TECHNOLOGIES CO., LTD.


Copyright © Huawei Technologies Co., Ltd. 2014. 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 trademarks 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 contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in 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]

Huawei Proprietary and Confidential


Issue 02 (2014-09-15) Copyright © Huawei i
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles Contents

Contents

1 Overview...................................................................................... 1
2 RNC in Pool Features and Networking............................................3
2.1 Introduction....................................................................................................................................................................3
2.2 Introduction to RNC in Pool Node Redundancy............................................................................................................3
2.3 Introduction to RNC in Pool Load Sharing....................................................................................................................4
2.4 Constraints on RNC in Pool Networking Scenarios.....................................................................................................10
2.5 Configuration Constraints............................................................................................................................................13
2.5.1 RNC in Pool Networking Constraints and Configuration Principles........................................................................13
2.5.2 Constraints on Iur-p Interface Configuration............................................................................................................16

3 RNC Capacity Dimensioning.........................................................17


3.1 Planning Dimensions....................................................................................................................................................17
3.2 Key Steps for Planning RNC in Pool Dimension Configurations................................................................................19
3.2.1 Capacity Planning......................................................................................................................................................19
3.2.2 Dimensioning Process for RNC in Pool....................................................................................................................21
3.2.3 Capacity Planning in Each Dimension......................................................................................................................22
3.3 Capacity Planning Procedures for RNC in Pool Configurations..................................................................................27
3.3.1 BSC6900....................................................................................................................................................................27
3.3.2 BSC6910....................................................................................................................................................................36

4 Software Configuration Principles for RNC in Pool Features...........54


4.1 Software and License Configuration Principles for RNC in Pool Overall Functions..................................................54
4.2 License Configuration Principles for Each Physical RNC on an RNC in Pool Network............................................55
4.3 Software and License Configurations for RNC in Pool Load Sharing........................................................................56
4.4 Software and License Configurations for RNC in Pool Node Redundancy................................................................57

Issue 02 (2014-09-15) Huawei Proprietary and Confidential ii


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles Figures

Figures

Figure 2-1 RNC in Pool Node Redundancy............................................................................................................4

Figure 2-2 RNC in Pool Load Sharing....................................................................................................................7

Figure 2-3 Control-plane and user-plane load sharing............................................................................................9

Figure 2-4 Resource pool formed by BSC6900s and a BSC6910........................................................................11

Figure 2-5 Resource pool formed by the BSC6910s (RAN16.0).........................................................................12

Figure 2-6 Resource pool overlapping in one BSC6910 that supports a maximum of 4 logical RNCs(RAN16.0)
...............................................................................................................................................................................13

Figure 3-1 Planning dimensions for RNC hardware requirements.......................................................................17

Figure 3-2 Dimensioning procedure for RNC in Pool configurations..................................................................21

Issue 02 (2014-09-15) Huawei Proprietary and Confidential iii


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles Tables

Tables

Table 2-1 Capacity specifications of the BSC6900 and BSC6910 that use and not use RNC in Pool features......5

Table 2-2 RNC in Pool networking scenarios supported in RAN15.0 and RAN16.0..........................................10

Table 3-1 Capacity dimensions for the control plane, user plane, and transmission plane...................................18

Table 3-2 Hardware and hardware licenses affected by capacity planning for the control plane, user plane, and
transmission plane..................................................................................................................................................18

Table 3-3 Capacity specifications in each dimension for node redundancy.........................................................23

Table 3-4 Capacity specifications of each dimension for load sharing.................................................................24

Table 3-5 RNC role in a resource pool and the corresponding dimensions..........................................................25

Table 3-6 Input control parameters and capacity requirement parameters...........................................................27

Table 3-7 Output parameters related to capacity transferred from the master RNC to the backup RNC or
overflow RNC(for Node Redundancy)..................................................................................................................28

Table 3-8 Output parameters related to capacity transferred from the master RNC to the backup RNC or
overflow RNC(for Load Sharing)..........................................................................................................................30

Table 3-9 Output parameters related to hardware and hardware licenses in the RNC in Pool configuration for a
BSC6900................................................................................................................................................................32

Table 3-10 Output parameters related to software licenses in the RNC in Pool configuration for a BSC6900. . .36

Table 3-11 Input control parameters......................................................................................................................36

Table 3-12 Input parameters when a BSC6910 serves as the master RNC...........................................................38

Table 3-13 Output parameters related to capacity transferred to the backup RNC(for Node Redundancy).........39

Table 3-14 Output parameters related to capacity transferred to the overflow RNC(for Load Sharing)..............40

Table 3-15 Output parameters related to hardware and hardware licenses when a BSC6910 serves as the master
RNC.......................................................................................................................................................................41

Table 3-16 Output parameters related to software licenses when a BSC6910 serves as the master RNC............45

Table 3-17 Input parameters (intermediate parameters related to capacity transferred from the master RNC to
the backup RNC) when a BSC6910 serves as the backup RNC and the calculation results.................................45

Table 3-18 Input parameters (intermediate parameters related to capacity transferred from the master RNC)
when a BSC6910 serves as the overflow RNC in load sharing.............................................................................47

Table 3-19 Output parameters related to hardware and hardware licenses when a BSC6910 serves as the backup
RNC or overflow RNC..........................................................................................................................................49

Issue 02 (2014-09-15) Huawei Proprietary and Confidential iv


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles Tables

Table 4-1 Configuration scenarios of the RNC in Pool features...........................................................................56

Table 4-2 Configuration scenarios of the RNC in Pool features (the BSC6910 works as master or overflow
RNC)......................................................................................................................................................................56

Table 4-3 Configuration scenarios of the RNC in Pool features (the BSC6910 works as both the master and
overflow RNC)......................................................................................................................................................57

Table 4-4 Configuration scenarios of the RNC in Pool features...........................................................................57

Table 4-5 Configuration scenarios of the RNC in Pool features (the BSC6910 works as master or overflow
RNC)......................................................................................................................................................................58

Table 4-6 Configuration scenarios of the RNC in Pool features (the BSC6910 works as both the master and
overflow RNC)......................................................................................................................................................58

Issue 02 (2014-09-15) Huawei Proprietary and Confidential v


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 1 Overview

1 Overview

This document describes the RNC in Pool features, networking requirement, and
configuration principles, and procedures and key factors for planning the capacity required for
the RNC in Pool features on an UMTS network that contains the BSC6900 V900R016C00
and BSC6910 V100R016C00 It aims to help readers understand the impact of RNC in Pool
configurations on network and configure an RNC pool.
Constraints on RAN15.0 RNC in Pool features are as follows:
Only the following resource pools are supported:
 Scenario A: 1 to 3 BSC6900s and 1 BSC6910
 Scenario B: 1 BSC6910 and 1 BSC6910
Networking constraints are as follows:
 An RNC cannot be configured in two resource pools.
 RAN15.0 supports only control-plane load sharing but not user-plane load sharing.
RAN16.0 supports the following resource pools:
 Scenario A (same as scenario A in RAN15.0): 1 to 3 BSC6900s and 1 BSC6910
 Scenario B (expanded scenario B in RAN15.0): 1 to 3 BSC6910s and 1 BSC6910
 Scenario C (new): 4 BSC6900s and 2 BSC6910s
This scenario allows one BSC6910 to be configured in two resource pools.This
consumes ext
1. Resource pool 1: 1 to 2 BSC6900s and 1 BSC6910
2. Resource pool 2: 1 to 2 BSC6900s and 1 BSC6910
3. Resource pool 3: 2 BSC6910s, with one from resource pool 1 and the other from
resource pool 2
 A BSC6910 supports a maximum of four logical RNCs.
 In RAN16.0, user-plane load sharing binding with control-plane load sharing is
supported besides the control-plane load sharing onlycontrol plane load sharing only that
is introduced in RAN15.0.
 In SRAN16.0, the SPUc replaces the SPUb, the GOUe replaces the GOUc, and the
GCUb/GCGb replaces the GCUa/GCGa because life cycles of these boards in BSC6900s
are due. RNC in Pool configuration principles are also applicable to the new boards.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 1


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 1 Overview

In this document, BSC6900 and BSC6910 configurations required for the RNC in Pool
configurations, namely changed dimensions among RNCs due to introduction of the RNC in
Pool features, are provided only.
For detailed BSC6900 and BSC6910 configurations, including board configuration principles
applicable to both BSC6900 and BSC6910, traffic model, capacity and hardware quantity that
are derived from the traffic models and target subscribers, see
SRAN9.0&GBSS16.0&RAN16.0 BSC6910 Configuration Principles and
SRAN9.0&GBSS16.0&RAN16.0 BSC6900 Configuration Principles. It is a good practice for
you to familiarize yourself with the two documents before reading this document.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 2


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 2 RNC in Pool Features and Networking

2 RNC in Pool Features and


Networking

About This Chapter


2.1 Introduction
2.2 Introduction to RNC in Pool Node Redundancy
2.3 Introduction to RNC in Pool Load Sharing
2.4 Constraints on RNC in Pool Networking Scenarios
2.5 Configuration Constraints

2.1 Introduction
RNC in Pool involves the following features:
 WRFD-150212 RNC in Pool Node Redundancy
 WRFD-150211 RNC in Pool Load Sharing
The two features are independently configured.
You can enable one or both of the features.
When planning capacity for the RNC in Pool features, calculate the following based on roles
(master RNC, backup RNC, or overflow RNC) of physical RNCs and the capacity required
for implementing node redundancy or load sharing:
 Hardware and hardware licenses for the control plane, user plane, and transmission plane
 Target capacity that can be provided by each physical RNC Number of required
software licenses
A resource pool consists of both BSC6900s and BSC6910s. Therefore, this document covers
both BSC6900s and BSC6910s.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 3


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 2 RNC in Pool Features and Networking

2.2 Introduction to RNC in Pool Node


Redundancy
With RNC in Pool Node Redundancy, one NodeB can be dual-homed to two physical RNCs.

Figure 1.1 RNC in Pool Node Redundancy

A master RNC refers to a physical RNC to which a dual-homing NodeB is primarily homed.
A backup RNC refers to a physical RNC to which a dual-homing NodeB is secondarily
homed.
In Figure 2-1, as an example, RNC P_RNC1 is the master RNC to which the dual-homing
NodeBs are primarily homed, and RNC P_RNC2 is the backup RNC to which the dual-
homing NodeBs are secondarily homed. If RNC P-RNC1 goes faulty, or links connecting
RNC P-RNC1 to NodeBs or to the CN do not work properly, an RNC control right change is
triggered such that RNC P_RNC2 takes over control of dual-homing NodeBs. All data over
the dual-homing NodeBs are then processed by RNC P_RNC2, including control-plane data,
user-plane data, and transmission-plane data.
In practice, master RNCs and backup RNCs need to be planned having the same capacity
requirement on the control plane, user plane, and transmission plane. Such requirement covers
hardware and hardware licenses for both the master RNC and backup RNC.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 4


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 2 RNC in Pool Features and Networking

2.3 Introduction to RNC in Pool Load Sharing


Load sharing among physical RNCs is implemented by adding physical RNCs, thereby
temporarily increasing the traffic absorption capability of logical RNCs and resisting traffic
bursts.
RAN15.0 support control-plane load sharing only.
RAN16.0 supports the following load sharing modes:
 Control-plane load sharing only
 User-plane load sharing binding with control-plane load sharing
 Both of the above

Capacity Improved by RNC in Pool Load Sharing


After RNC in Pool Load Sharing is enabled, the BSC6900 and BSC6910 use the BSC6910s to
expand capacity of the original logical RNC. In control-plane load sharing only, the BHCA of
the original logical RNC improves to 1.6 times the maximum specifications. In user-plane
load sharing binding with control-plane load sharing, capacity of the original logical RNC
improves to 1.9 times the maximum specifications. The following table lists detailed
specifications.

Table 1.1 Capacity specifications of the BSC6900 and BSC6910 that use and not use RNC in Pool
features
Scenario/Specific Number of Base BHCA (K) PS
ations Stations/Cells Throughput
(Gbit/s)

RNC Not Using the RNC in Pool Features and RNC Using Node Redundancy
BSC6900 3060/5100 12800 (See Note 40 (See Note 2.)
1.)
BSC6910 (two cabinets) 10000/20000 64000 (See Note 120 (See Note
1.) 2.)
BSC6910 (one cabinet) 5000/10000 32000 (See Note 60 (See Note 2.)
1.)
RNC Using Control-Plane Load Sharing Only
BSC6900 (master) 3060/5100 12800x1.6 40
+BSC6910 (overflow)
BSC6910 (master) 10000/20000 64000x1.6 120
+BSC6910 (overflow)
(two cabinets)
BSC6910 (master) 5000/10000 32000x1.6 60
+BSC6910 (overflow)
(one cabinet)
RNC Using User-Plane Load Sharing Binding with Control-Plane Load Sharing
BSC6900 (master) 3060/5100 12800x1.9 40x1.9

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 5


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 2 RNC in Pool Features and Networking

Scenario/Specific Number of Base BHCA (K) PS


ations Stations/Cells Throughput
(Gbit/s)

+BSC6910 (overflow)
BSC6910 (master) 10000/20000 64000x1.9 120x1.9
+BSC6910 (overflow)
(two cabinets)
BSC6910 (master) 5000/10000 32000x1.9 60x1.9
+BSC6910 (overflow)
(one cabinet)

NOTE
Note 1: The BSC6900 12800 K BHCA and BSC6910 64000K/32000K BHCA are calculated based on
the Smartphones Traffic Model.
Note 2: The PS throughput of the BSC6900 and BSC6910 is calculated based on the High-PS Model.
For details about Huawei typical Smartphones Traffic Model and High-PS Model, see
SRAN9.0&GBSS16.0&RAN16.0 BSC6910 Configuration Principles and
SRAN9.0&GBSS16.0&RAN16.0 BSC6900 Configuration Principles.

Control-Plane Load Sharing


A master RNC refers to a physical RNC from which call processing load is transferred to
other RNCs. An overflow RNC refers to the RNC to which call processing load is transferred
from a master RNC. Calls over the NodeBs under a master RNC is processed on the master
RNC. When control-plane load sharing conditions are satisfied, the master RNC transfers
partial control-plane call load to overflow RNCs.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 6


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 2 RNC in Pool Features and Networking

Figure 1.1 RNC in Pool Load Sharing

In Figure 2-2, as an example, calls over the NodeBs under RNC P_RNC1 are primarily
processed on RNC P_RNC1. When control-plane capacity of RNC P_RNC1 is not enough for
calls over the NodeBs under RNC P_RNC1, the RNC P_RNC1 transfers some calls to RNC
P_RNC2 and the transferred calls are then processed on RNC P_RNC2. For the RNC, the
transferred calls are overflow calls. For the transferred calls, RNC P_RNC1 is the master
RNC, and RNC P_RNC2 is an overflow RNC.
In practice, hardware and hardware licenses for requirements on user-control plane and
transmission-plane need to be planned on the master RNC, and hardware and hardware
license for control-plane requirements need to be planned on the overflow RNCs. In addition,
some calls may be being transferred from RNC P_RNC1 to RNC P_RNC2 at the time when
other calls are being transferred from RNC P_RNC2 to RNC P_RNC1. Therefore,
overflowing direction needs to be considered in planning control-plane capacity.
In control-plane load sharing, only shareable load is transferred from the master RNC to the
overflow RNC, and the unshareable load remains on the master RNC.
In addition, when an overflow call is processed on the two RNCs, some coordination and
control messages need to be transferred between the two RNCs. This consumes extra control-
plane resources and interface bandwidth, which needs to be considered during capacity
planning:
 Extra resource consumption on the control plane: Resources consumed by an overflow
subscriber are about 57% of those consumed by a non-overflow subscriber on the master
RNC. Resources consumed by an overflow subscriber are about 63% of those consumed
by a non-overflow subscriber on the overflow RNC. Therefore, load sharing consumes

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 7


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 2 RNC in Pool Features and Networking

an extra control-plane resource of about 10%~20% (calculated by 57%+63%-100%) on


both the master RNC and overflow RNC.
 Iur-p bandwidth consumption: Bandwidth for control plane information on bear on Iur-p
interface.
Iur-p control plane bandwidth: Extra bandwidth is consumed over the Iur-p interface
through which coordination and control messages are transferred between two RNCs,
including 10Mbit/s of base bandwidth and 20kbit/s consumed by each active user during
load sharing process. An active user refers to the UE in the CELL_DCH or
CELL_FACH state.

User-Plane Load Sharing


User-plane load sharing is performed together with control-plane load sharing. Both user-
plane data and transmission-plane data can be transferred to the overflow RNC for processing.
The following figure shows data flow on the control plane and user plane.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 8


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 2 RNC in Pool Features and Networking

Figure 1.1 Control-plane and user-plane load sharing

Therefore, during capacity planning for both control-plane load sharing and user-plane load
sharing, the hardware and hardware licenses need to be planned for the control plane, user
plane, and transmission plane on the overflow RNC.
Control-plane data of overflow subscribers over the Iu, Iur, or Iub interface is transmitted to
other NEs through the master RNC in both load sharing modes.
When an overflow call is processed on two RNCs, some coordination and control messages
need to be transferred between the two RNCs. This consumes extra control-plane resources
and interface bandwidth, which needs to be considered during capacity planning:

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 9


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 2 RNC in Pool Features and Networking

 Extra resource consumption on the control plane: Resources consumed by an overflow


subscriber are about 53% of those consumed by a non-overflow subscriber on the master
RNC. Resources consumed by an overflow subscriber are about 55% of those consumed
by a non-overflow subscriber on the overflow RNC. Therefore, load sharing consumes
an extra control-plane resource of about 8% (calculated by 53%+55%-100%) on both the
master RNC and overflow RNC. This is the same as that in control-plane load sharing
onlycontrol plane load sharing only.
 Iur-p bandwidth consumption: including bandwidth of control plane and user plane bear
on Iur-p interface.
Iur-p control plane bandwidth: Extra bandwidth is consumed over the Iur-p interface
through which coordination and control messages are transferred between two RNCs,
including 10Mbit/s of base bandwidth and 15kbit/s consumed by each active user during
load sharing process. An active user refers to the UE in the CELL_DCH or
CELL_FACH state.
Iur-p user plane bandwidth: including user plane throughput when load shared user in
Cell_FACH state, and when load sharing user using IUB ATM transmission in Overflow
RNC.

2.4 Constraints on RNC in Pool Networking


Scenarios
The following table lists the networking scenarios that support the RNC in Pool features in
RAN15.0 and RAN16.0.

Table 1.1 RNC in Pool networking scenarios supported in RAN15.0 and RAN16.0
Scenario RAN15.0 RAN16.0

Scenario A: 1 to 3 BSC6900s and 1 1 to 3 BSC6900s and 1


6900+6910 BSC6910 BSC6910

Scenario B: 1 BSC6910 and 1 BSC6910 1 to 3 BSC6910s and 1


6910+6910 BSC6910

Scenario C: Not supported 4 BSC6900s and 2


n BSC6900s+2 BSC6910s BSC6910s

Maximum number of logical 4 4


RNCs that can be
configured on a BSC6910

Scenario A (1 to n BSC6900s and 1 BSC6910): The BSC6900 serves as the master RNC in
both node redundancy and load sharing. The BSC6910 serves as both the backup RNC in
node redundancy and the overflow RNC in load sharing.
RAN15.0 and RAN16.0 support scenario A where the maximum value of n is 3. A BSC6910
supports a maximum of four logical RNCs.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 10


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 2 RNC in Pool Features and Networking

Scenario B (1 to mBSC6910s and 1 BSC6910): The BSC6910 serves as both the master RNC
and backup RNC in node redundancy, and serves as both the master RNC and overflow RNC
in load sharing.
RAN15.0 supports scenario B where m is 1. RAN16.0 supports scenario B where m is 3. In
RAN15.0 and RAN16.0, the BSC6910 supports a maximum of four logical RNCs.
Scenario C (four BSC6900s and two BSC6910s): In this scenario, one BSC6910 can be
configured in resource pools in both scenario A and scenario B.
RAN15.0 does not support scenario C and one RNC cannot be configured in two RNC pools.
RAN16.0 supports scenario C.
Typical networking scenarios supported in RAN16.0 for scenario C are as follows:
 Resource pool 1: 1 to 2 BSC6900s and 1 BSC6910
 Resource pool 2: 1 to 2 BSC6900s and 1 BSC6910
 Resource pool 3: 2 BSC6910s, with one from resource pool 1 and the other from
resource pool 2

The BSC6910 can not only serve as an overflow or backup RNC in a resource pool, but also be
configured with its own logical RNC.

Scenario A: BSC6900s and a BSC6910 form a resource pool.


RAN16.0 supports the resource pool formed by one to three BSC6900s and one BSC6910.
The BSC6910 can serve as the backup RNC and overflow RNC for all BSC6900s
simultaneously. The BSC6900 cannot serve as the backup RNC or overflow RNC for the
BSC6910.

Figure 1.2 Resource pool formed by BSC6900s and a BSC6910

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 11


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 2 RNC in Pool Features and Networking

Scenario B: BSC6910s form a resource pool.


RAN16.0 supports the resource pool formed by a maximum of four BSC6910s in the 1+1,
2+1, and 3+1 networking modes. As shown in the following figure, the BSC6910 on the right
serves as the backup RNC and overflow RNC for the three BSC6910s on the left. Meanwhile,
one of the three BSC6910s on the left serves as the backup RNC and overflow RNC for the
BSC6910 on the right.

Figure 1.3 Resource pool formed by the BSC6910s (RAN16.0)

Scenario C: One BSC6910 serve in two resource pools (the BSC6910 supports a
maximum of four logical RNCs).
In RAN15.0, one RNC can be configured in one resource pool only. In other words, resource
pools cannot overlap. In RAN16.0, one BSC6910 can be configured in two resource pools. In
other words, two resource pools overlap in one BSC6910. In fact, this is a combination of
scenario A and scenario B.
Resource pool overlap is introduced because of the following reason: In a resource pool
formed by BSC6900s and a BSC6910 in RAN15.0, the BSC6910 provides backup and load
sharing for logical RNCs of the BSC6900s, but the logical RNC of this BSC6910 cannot be
backed up and its load cannot be shared. Therefore, in RAN16.0, a BSC6910 can form a
resource pool with another BSC6910 when it forms another resource pool with BSC6900s. In
this way, this BSC6910 provides backup and load sharing for BSC6900s, and its logical RNC
provides backup and load sharing for another BSC6910.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 12


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 2 RNC in Pool Features and Networking

Figure 1.4 Resource pool overlapping in one BSC6910 that supports a maximum of 4 logical
RNCs(RAN16.0)

2.5 Configuration Constraints


2.5.1 RNC in Pool Networking Constraints and
Configuration Principles
MBSC Working mode:
WRFD-150211 RNC in Pool Load Sharing is only supported in MBSC UO mode, not
supported in GU and GO mode.
WRFD-150212 RNC in Pool Node Redundancy is supported in MBSC UO and GU mode.
When in GU mode, both WRFD-150212 RNC in Pool Node Redundancy and GBFD-113725
BSC Node Redundancy should be activated.

Directivity
In a resource pool formed by the BSC6900s and BSC6910, node redundancy and load sharing
can be performed in one direction. In other words, only the BSC6910 can serve as the backup
RNC and overflow RNC for the BSC6900s.
A BSC6900 cannot serve as the backup RNC or overflow RNC for either the BSC6900 or
BSC6910.
In a resource pool formed by BSC6910s, node redundancy and load sharing can be performed
in two directions.

Constraints on Networking
Different resource pools can overlap in a BSC6910. A BSC6910 supports a maximum of 4
logical RNCs. One BSC6910 can form a resource pool with a maximum of 3 BSC6900s. One
BSC6910 can also form a resource pool with a maximum of other three BSC6910s. One

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 13


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 2 RNC in Pool Features and Networking

BSC6910 can form two resource pools simultaneously. For details, see section 2.4
"Constraints on RNC in Pool Networking Scenarios."

Control-Plane Load Sharing


RNC in Pool Load Sharing has the following impacts on control-plane load of the master
RNC and overflow RNC:
Only shareable load is transferred from the master RNC to the overflow RNC, and un-
shareable load remains on the master RNC. During load sharing, an overflow call processed
on two RNCs consumes extra control-plane resources for coordination and commutation
between the two RNCs. As a result,
For control plane load sharing only, control-plane resources consumed by an overflow
subscriber are about 57% of those consumed by a non-overflow subscriber on the master
RNC. Resources consumed by an overflow subscriber are about 63% of those consumed by a
non-overflow subscriber on the overflow RNC..
For user-plane load sharing performed together with control-plane load sharing, control-plane
resources consumed by an overflow subscriber are about 53% of those consumed by a non-
overflow subscriber on the master RNC. Resources consumed by an overflow subscriber are
about 55% of those consumed by a non-overflow subscriber on the overflow RNC.

(Optional) Constraints on Boards


In RNC in Pool Node Redundancy, if the master RNC is configured with the ESAUa/SAUc,
GCG, or ENIUa/NIUa, the backup RNC must also be configured with the ESAUa, GCG, or
ENIUa, respectively.
In control plane load sharing only, if the master RNC is configured with the ESAUa/SAUc or
GCG, the overflow RNC must also be configured with the ESAUa or GCG.
In user-plane load sharing binding with control-plane load sharing, if the master RNC is
configured with the ESAUa/SAUc, GCG, or ENIUa/NIUa, the overflow RNC must also be
configured with the ESAUa, GCG, or ENIUa.

Constraints on Transmission (1)


Constraints on transmission in RNC in Pool Node Redundancy are as follows:
 Iu-CS/Iur interface: The Iu-CS/Iur interfaces of the master RNC and backup RNC must
use the same transmission mode, either IP or ATM. When multiple master RNCs are
backed up by one BSC6910, the Iu-CS/Iur interfaces of these master RNCs and the
backup RNC (BSC6910) must use the same transmission mode, either IP or ATM. When
the Iu/Iur interface uses the IP transmission mode, only the layer 3 transmission network
supports RNC in Pool Node Redundancy.
 Iu-PS interface: RNC in Pool Node Redundancy is not supported when the Iu-PS
interface uses ATM transmission.

Constraints on Transmission (2)


Constraints on transmission in control-plane load sharing onlycontrol plane load sharing only
are as follows:
All control-plane data is transferred back to the master RNC through the Iur-p interface for
interaction with other NEs. Therefore, the Iu/Iur/Iub interface does not need to be configured

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 14


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 2 RNC in Pool Features and Networking

for the overflow RNC. Only the Iur-p and O&M interfaces need to be configured for the
overflow RNC.

Constraints on Transmission (3)


Constraints on transmission in user-plane load sharing binding with control-plane load sharing
are as follows:
 Iu-CS/Iu-PS/Iur interface: Both the master RNC and overflow RNC must use the same
transmission mode, either IP or ATM. The type of transmission ports is not specified.
 (2) The overflow RNC must be configured with the Iu-CS and Iu-PS interfaces for user-
plane transmission. The Iur interface is recommended. If the overflow RNC is not
configured with the Iur interface, the Iur interface traffic of an overflow subscriber can
only be transferred back to the master RNC, which consumes extra Iur-p bandwidth.
 Iub interface: The overflow RNC must be configured with the Iub interface using IP
transmission. The type of port for IP transmission is not specified. User-plane data of an
overflow subscriber can only be processed by the overflow RNC whose Iub interface
uses IP transmission.
 Control-plane data over the Iu/Iur/Iub interface of an overflow subscriber is transmitted
to other NEs through the master RNC. Only the user-plane data is transmitted to other
NEs through the overflow RNC.

Iur-p Interface Bandwidth


Iur-p bandwidth = base bandwidth + control plane bandwidth of load sharing + user plane
throughput bear on Iur-p
Base bandwidth: 10Mbit/s bandwidth is should be planed for base information exchange
between Master RNC and Backup/Overflow RNC.
Control plane bandwidth of load sharing: for control plane load sharing only, calculate this
value according to overflow active user number * 20kbit/s. For user-plane load sharing
together with control-plane load sharing, calculate this value according to overflow active
user number * 15kbit/s.
User plane throughput bear on Iur-p = ATM NodeB number ratio on Overflow RNC *
Overflow subscriber * (Proportion of SHO for CS Voice traffic * 12.2kbps * 2 * CS Voice
Traffic per sub per BH + Proportion of SHO for PS call * Total PS throughput (HSPA and
R99, UL+DL) per sub) + dual state NodeB number ratio on Overflow RNC * Overflow
subscriber * Proportion of SHO for CS Voice traffic * 12.2kbps * 2 * CS Voice Traffic per sub
per BH + throughput of common channel user (default, 10kbit/s per cell) * Total cell number
on Master RNC * Overflow subscribers / Total subscribers.

Constraints on Number of NodeBs/Cells


When multiple logical RNCs are configured on one BSC6910, NodeBs/cells configured on
the master RNC occupy the capability of the BSC6910 serving as the backup or overflow
RNC. The total number of NodeBs/cells on the logical RNC of the BSC6910 and the
NodeBs/cells on the master RNC cannot exceed the specifications and hardware capability of
this BSC6910. The detailed constraints are as follows:
For Node Redundancy:
Max/Sum(Dual-homing NodeB&cell number of each master RNC) + NodeB&cells number
configured in the BSC6910 logical RNC <= Min(NodeB&Cell number supported by EGPUa
board of Overflow/Backup BSC6910, NodeB&Cell number supported by Iub interface board

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 15


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 2 RNC in Pool Features and Networking

of Overflow/Backup BSC6910, the maximum capacity as 10000NodeB&20000cell of


BSC6910).
For Load Sharing:
Sum(NodeB&cell number of each master RNC) + NodeB&cells number configured in the
BSC6910 logical RNC <= the maximum capacity as 10000NodeB&20000cell of BSC6910.

2.5.2 Constraints on Iur-p Interface Configuration


The Iur-p interface is a Huawei proprietary interface for transmitting necessary device data
among RNCs in a resource pool. Such data includes device load and heartbeat information. In
load sharing, some control-plane data and user-plane data need to be transmitted through the
Iur-p interface.
 Control-plane and user-plane data can be transmitted through the Iur-p interface only in
IP transmission.
 On the BSC6900, the GOUc/GOUe and FG2c can be configured with the Iur-p interface.
On the BSC6910, the GOUc/GOUe, FG2c, and EXOUa can be configured with the Iur-p
interface.
 In a resource pool, the Iur-p interface can be configured only between the BSC6900 and
BSC6910 or between BSC6910s.
 If only node redundancy is used, you are advised to configure the Iur-p and Iur interfaces
on the same interface board. If a BSC6900 or BSC6910 configured with the Iur-p
interface is not configured with the GOUc/GOUe, FG2c, or EXOUa interface board for
the Iur interface, an interface board needs to be configured for independently
implementing IP over Iur-p.
 Load sharing may generate heavy control-plane and the user-plane traffic over the Iur-p
interface. When this feature is enabled, you are advised to configure the Iur-p interface
on an independent interface board. However, the Iur-p and Iur interfaces can be
configured on one EXOUa.
 Iur-p transmission requirements in RNC in Pool Load Sharing are as follows: the
unidirectional transmission delay is shorter than or equal to 10 ms, the transmission jitter
is shorter than or equal to 5 ms, and the packet loss rate is smaller than 0.01%.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 16


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

3 RNC Capacity Dimensioning

About This Chapter


3.1 Planning Dimensions
3.2 Key Steps for Planning RNC in Pool Dimension Configurations
3.3 Capacity Planning Procedures for RNC in Pool Configurations

3.1 Planning Dimensions


Planning dimensions for RNC hardware requirements are as follows:

Figure 1.1 Planning dimensions for RNC hardware requirements

As shown in Figure 3-1, planning dimensions for RNC hardware requirements include control
plane, user plane, and transmission plane:
 The control plane is dimensioned by BHCA, number of NodeBs/cells, number of active
users, and number of online users.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 17


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

 The user plane is dimensioned by CS Erl, PS throughput, number of cells, and number of
active users.
 The transmission plane is dimensioned by CS Erl, PS throughput, number of NodeBs,
number of active users, number of online users, and number of Iu-PS connections.
A resource pool differs from a common RNC in the following aspects:
 The Iur-p interface transmission capacity is planned for a resource pool, including Iur-p
control-plane bandwidth and Iur-p user-plane bandwidth.
 The control-plane load of an overflow subscriber consists of shareable and unshareable
parts that are processed by the master RNC and overflow RNC, respectively.

Table 1.1 Capacity dimensions for the control plane, user plane, and transmission plane
Dimension User Plane Control Plane Transmission
Plane

Common CS Erlang BHCA CS Erlang


Dimension PS Throughput Number of Cells and PS Throughput
Number of and NodeBs Number of and NodeBs
cells Number of active users Number of online UEs
Number of active Number of online UEs Number of active users
users
RNC in Pool- None BHCA (unshareable Iur-p Throughput
dedicated part)
Dimension BHCA (shareable part)

The following table lists capacity planning objectives for RNC in Pool.

Table 1.2 Hardware and hardware licenses affected by capacity planning for the control plane,
user plane, and transmission plane
Hardware and User Plane Control Transmission
Hardware Plane Plane
License

Hardw BSC6910 EGPUa (UP) EGPUa (CP) Iu interface board


are ENIUa Iub interface board
BSC6900 DPUe SPUb Iur interface board
NIUa Iur-p interface
board
Hardw BSC6910 RNC Throughput RNC Active
are Hardware Capacity (per User Hardware
Licens 50Mbps) Capacity(per
e Evolved Network 1000 Active
Intelligence Throughput Users)
License(50Mbps)
BSC6900 Hardware Capacity

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 18


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Hardware and User Plane Control Transmission


Hardware Plane Plane
License

License(165Mbps)
Hardware Capacity
License(300Mbps)
Network Intelligence
Throughput
License(50Mbps)

The hardware and hardware licenses are related only to physical RNCs, and they do not transfer with
logical RNCs.

Following are licenses related to the RNC in Pool features:


 RNC in Pool Load Sharing (per 500 Active Users)
 RNC in Pool Node Redundancy (per NodeB)
 RNC in Pool Multiple Logical RNCs

3.2 Key Steps for Planning RNC in Pool


Dimension Configurations
3.2.1 Capacity Planning
Node Redundancy
The backup capacity needs to be provided by the backup RNC (involving the control plane,
user plane, and transport plane) is equal to the backup capacity required by the master RNC
(involving the control plane, user plane, and transport plane).

Control-Plane Load Sharing Only


Master RNC capacity:
 Control plane: Unshareable control-plane data remains on the master RNC, and
performing load sharing among RNCs consumes extra control-plane resources.
Resources consumed by the two parts are 57% of one user the master RNC.
 Transmission: More Iur-p bandwidths are required. An overflow active user consumes 20
kbit/s bandwidth (UL+DL).
Overflow RNC capacity:
 Control plane: Shareable control-plane data of an overflow subscriber is processed by the
overflow RNC, and performing load sharing among RNCs consumes extra control-plane
resources. Resources consumed by the two parts are 63% of one user the master RNC.
 Transmission: More Iur-p bandwidths are required. An overflow active user consumes 20
kbit/s bandwidth (UL+DL).

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 19


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

User-Plane Load Sharing Binding with Control-Plane Load


Sharing
Master RNC capacity:
 Control plane: Unshareable control-plane data remains on the master RNC, and
performing load sharing among RNCs consumes extra control-plane resources.
Resources consumed by the two parts are 53% of one user the master RNC.
 User plane: User-plane data on the common channel remains on the master RNC. User-
plane data on the dedicated channel is transferred to the overflow RNC.
 Transmission:
1. The master RNC processes only the control-plane data of an overflow subscriber on the
Iu/Iur interface, but does not process the user-plane data on the Iu/Iur interface.
2. Iub user-plane data on the dedicated channel is transferred to the overflow RNC. The
master RNC processes only the Iub user-plane data on the common channel and control-
plane data over the Iub interface.
3. Iur-p control plane interface: 15 kbit/s bandwidth is provided for each overflow active
user for transmitting control-plane data during RNC interactions and user-plane data.
4. Iur-p user plane interface: Iub user-plane data on the dedicated channel is transferred to
the overflow RNC. The mMaster RNC processes only the Iub user-plane data on the
common channel of overflow user and dedicated channel data of overflow user when
ATM transport type is configured on Iub between Overflow RNC and NodeBcontrol-
plane data over the Iub interface.
Overflow RNC capacity:
 Control plane: Shareable control-plane data of an overflow subscriber is processed by the
overflow RNC, and performing load sharing among RNCs consumes extra control-plane
resources. Resources consumed by the two parts are 55% of one user the master RNC.
 User plane: User-plane data of an overflow subscriber on the dedicated channel is
processed by the overflow RNC.
 Transmission plane:
1. Iu/Iur transmission-plane data is processed by the overflow RNC.
2. Iub transmission-plane data on the dedicated channel is processed by the overflow RNC.
3. Iur-p control plane interface: 15 kbit/s bandwidth is provided for each overflow active
user for transmitting control-plane data during RNC interactions and user-plane data.
4. Iur-p user plane interface: Overflow RNC processes the Iur/Iu user plane data, the Iub
user plane data on IP.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 20


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

3.2.2 Dimensioning Process for RNC in Pool


Figure 1.1 Dimensioning procedure for RNC in Pool configurations

As shown in figure 3-2, the dimension planning for RNC in Pool configurations includes the
following procedures:
Step 1 Determine the RNC types and networking scenarios within an RNC pool.
The RNC in Pool solution supports BSC6900 V900R016 and BSC6910 V100R016 in an
RNC pool. For details, see section 2.4 "Constraints on RNC in Pool Networking Scenarios."
The RNC in Pool solution supports the following networking scenarios:
 Scenario A: 1 to 3 BSC6900s and 1 BSC6910
 Scenario B: 1 to 3 BSC6910s and 1 BSC6910
 Scenario C: 4 BSC6910s and 2 BSC6910s

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 21


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Step 2 Determine the RNC in Pool feature to be used.


The RNC in Pool features include WRFD-150212 RNC in Pool Node Redundancy and
WRFD-150211 RNC in Pool Load Sharing.
Step 3 Determine the role of each RNC in the RNC pool.
For WRFD-150212 RNC in Pool Node Redundancy, determine an RNC works as a master
RNC or backup RNC. For WRFD-150211 RNC in Pool Load Sharing, determine an RNC
works as a master RNC or an overflow RNC.
Step 4 Determine the target capacity in given dimensions.
For RNC in Pool Node Redundancy, the initial target capacity means the number of UEs
served by the NodeB and the cells under the NodeB that requires to be backed up on the
backup RNC.
For RNC in Pool Load Sharing, the initial target capacity means the number of UEs of which
the load needs to be shared on the overflow RNC and whether control-plane or user-plane
load sharing is performed.
Step 5 Calculate each specific capacity dimension based on the traffic model after importing the
initial target capacity.
Step 6 Determine capacity distribution on the master RNC, backup RNC, and overflow RNC based
on the characters and requirements of the RNC in Pool features.
Step 7 Calculate the number of required hardware and hardware licenses based on the capacity
requirements of each physical RNC for each feature and the actual hardware specifications.
----End

 If a physical RNC serves both node redundancy and load sharing, the hardware/hardware license
capacity of this RNC depends on the greater capacity among those required by the two features,
instead of the sum of those required by the two features.
 If a physical RNC serves as the backup RNC and/or overflow RNC, and it has its independent
logical RNC (irrelevant to the RNC in Pool features) and independent capacity, the
hardware/hardware license capacity of this physical RNC consists of two parts: one for the RNC in
Pool features and the other for the non-RNC in Pool features.

----End

3.2.3 Capacity Planning in Each Dimension


WRFD-150212 RNC in Pool Node Redundancy
 Source:
1. Based on the traffic model, calculate the backup capacity in each dimension for the
master RNC using the imported initial target capacity.
2. Based on the calculation results of multiple master RNCs, calculate the capacity that
need to be provided by the backup RNC in each dimension.
 Impact:
The hardware and hardware license take effect only on the backup RNC and only on the
BSC6910.
The following table lists capacity specifications in each dimension for node redundancy.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 22


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Table 1.1 Capacity specifications in each dimension for node redundancy


Description Capacity Impacted Hardware
Dimension And Hardware
(Calculated by the License (Backup
Master RNC and RNC)
then Transferred to
the Backup RNC)

Iub traffic capacity, which Iub CS Traffic (Erl) EGPUa (UP), Iub interface
impacts the user-plane and board, and ENIUa
Iub interface hardware, and RNC Throughput Hardware
user-plane hardware license Capacity(per 50Mbps)
Evolved Network
Intelligence Throughput
License(50Mbps)
Iub PS DL Payload
Throughput (Mbps)
Iub PS UL Payload
Throughput (Mbps)
Iu/Iur traffic capacity, which Iu-CS Traffic (Erl) Iu/Iur interface board
impacts Iu/Iur hardware
Iu PS DL Payload
Throughput (Mbps)
Iu PS UL Payload
Throughput (Mbps)
Iur DL Payload Throughput
(Mbps)
Iur UL Payload Throughput
(Mbps)
Control-plane traffic BHCA EGPUa (CP)
capacity, which impacts BHCA per EGPUa
control-plane hardware and
hardware licenses Active Users EGPUa (CP), EGPUa (UP),
and Iub interface board
RNC Active User Hardware
Capacity (per 1000 Active
Users)
Number of connected UEs, Online Users Iu interface board
which has auxiliary
constraints on hardware NodeB number EGPUa (CP) and Iub
quantities interface board
Cell Number EGPUa (CP/UP)

WRFD-150211 RNC in Pool Load Sharing


 Source:

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 23


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

1. Based on the traffic model, calculate the capacity to be shared in each dimension for the
master RNC by importing the initial target capacities.
2. Based on the calculation results of multiple master RNCs, calculate the capacity that
need to be shared by the overflow RNC in each dimension.
 Impact:
Iur-p interface boards impact both the master RNC and overflow RNC. Control-plane
hardware and hardware licenses impact both the master RNC and overflow RNC.
The following table lists capacity specifications in each dimension for load sharing.

Table 1.2 Capacity specifications of each dimension for load sharing


Description Capacity Impacte Impacted
Dimension d Hardware and
Hardwar Hardware
e and License on the
Hardwar Overflow RNC
e
License
on the
Master
RNC

Control-plane capacity, Overflow Subscribers EGPUa/SP EGPUa (CP)


which impacts the Subscribers Capacity Ua/SPUb/S RNC Active User
control-plane hardware per EGPUa PUc Hardware Capacity
and hardware licenses of (per 1000 Active
the master RNC and Overflow Active Users Users)
overflow RNC
Iu/Iur traffic capacity, Iu CS Traffic (Erl) Iu/Iur interface board,
which impacts the user- EGPUa (UP), and
plane boards, Iu/Iur Iu PS DL Payload ENIUa
interface hardware, and Throughput (Mbps)
RNC Throughput
user-plane hardware Iu PS UL Payload Hardware Capacity
licenses of the overflow Throughput (Mbps) (per 50Mbps)
RNC
Iur DL Payload Evolved Network
Throughput (Mbps) Intelligence
Throughput
Iur UL Payload
License(50Mbps)
Throughput (Mbps)
Iub traffic capacity, Iub CS Traffic (Erl) Iub interface Iub interface board
which impacts Iub board
hardware of the Iub PS DL Payload
overflow RNC Throughput (Mbps)
Iub PS UL Payload
Throughput (Mbps)
Iur-p traffic, which Iur-p throughout Iur-p Iur-p interface board
impacts the Iur-p (Mbps) interface
interface hardware of board
both the master RNC
and overflow RNC

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 24


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

After the capacity requirements in each dimension are obtained, calculate the quantity of
required hardware and hardware licenses based on the hardware specifications. For details
about hardware specifications and how to calculate quantity of hardware and hardware
licenses, see SRAN9.0&GBSS16.0&RAN16.0 BSC6910 Configuration Principles and
SRAN9.0&GBSS16.0&RAN16.0 BSC6900 Configuration Principles.

Table 1.3 RNC role in a resource pool and the corresponding dimensions
Item Node Redundancy Load Sharing

RNC Role Master RNC Backup RNC Master RNC Overflow RNC
Applicable BSC6900 and BSC6910 BSC6900 and BSC6910
Product BSC6910 BSC6910
Number of BSC6900: 1~3 1 BSC6900: 1~3 1
RNCs BSC6910: 1~3 BSC6910: 1~3
Customer Number of Number of overflow
Input redundancy subscribers
NodeBs Load sharing mode
(control-plane load
sharing or user-
plane load sharing)
Intermediat Capacity Master RNC Capacity Master RNC
e requirements capacity requirements capacity
Parameter (involving the requirements (involving the requirements for
control plane, control plane, user load sharing and
user plane, and plane, transmission Iur-p bandwidth
transmission plane, and Iur-p
plane) interface)
Software RNC in Pool RNC in Pool RNC in Pool Load RNC in Pool
Feature Node Multiple Sharing (per 500 Multiple Logical
License Redundancy Logical RNCs Active Users) RNCs (0~3)(
(per NodeB) (0~3)(
Hardware - EGPUa EGPUa (CP) EGPUa, ENIUa,
(CP/UP) and Iur-p interface board Iu/Iur/Iub/Iur-p
ENIUa interface board
Iu/Iur/Iub
interface board
Hardware - RNC BSC6910: RNC Active
License Throughput RNC Throughput User Hardware
Hardware Hardware Capacity Capacity (per
Capacity (per (per 50Mbps) 1000 Active
50Mbps) Users)
Evolved Network
RNC Active Intelligence RNC
User Hardware Throughput Throughput
Capacity (per License(50Mbps) Hardware
1000 Active Capacity (per
Users) BSC6900: 50Mbps)

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 25


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Item Node Redundancy Load Sharing

300Mbps/165Mbps Evolved
license Network
Network Intelligence
Intelligence Throughput
Throughput License(50Mbps
License(50Mbps) )

Capacity - Capacity change Unshareable Capacity change


Change values refer to capacity of overflow values refer to
the capacities subscribers on the the capacities
provided by the control plane provided by this
backup RNC to Capacity of RNC to the
master RNCs subscribers except overflow
overflow subscribers subscribers on
on the control plane, the control
user plane, and plane, user
transmission plane plane, and
transmission
Iur-p interface plane
traffic
Iur-p interface
traffic
Note:
 In node redundancy, if more than one master RNC is configured, the following two
backup modes apply:
1. 1+1: The hardware, hardware license, or capacity change is equal to the sum of
backup requirements of all master RNCs. This mode applies to scenarios where all
master RNCs may become faulty at the same time.
2. N+1: The hardware, hardware license, or capacity change is equal to the maximum
value of backup requirements in each dimension of all master RNCs. This mode
applies to scenarios where only one master RNC becomes faulty at one time.
 In load sharing, the capacity, hardware, or hardware license needs to be provided by the
overflow RNC is the sum of the corresponding requirements of all master RNCs.
 If an RNC serves as both the backup RNC and overflow RNC, the greater capacity
requirement among the two is used for this RNC.
 If the master RNC is configured with optional service boards, such as the
NIU/SAU/GCG, the backup or overflow RNC also needs to be configured with such
board. In node redundancy, if the master RNC is configured with the NIU/SAU/GCG,
the backup RNC also needs to be configured with the NIU/SAU/GCG. Otherwise,
related optional functions on the logical RNC of this backup RNC are unavailable when
the master RNC malfunctions. The number of required boards is calculated based on the
backup capacity ratio. In user-plane load sharing, if the master RNC is configured with
the NIU/SAU/GCG, the overflow RNC also needs to be configured with the
NIU/SAU/GCG. Otherwise, related optional functions are unavailable for overflow
subscribers. The number of required boards is calculated based on the overflow ratio.
The overflow RNC needs to be configured with such boards as SAU/GCG in control-
plane load sharing onlycontrol plane load sharing only.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 26


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

3.3 Capacity Planning Procedures for RNC in


Pool Configurations
3.3.1 BSC6900
A BSC6900 can only serve as a master RNC no matter in node redundancy or load sharing.

Table 1.1 Input control parameters and capacity requirement parameters


Input Parameter Value Description

Logical Master RNC Capacity Parameters


Total Subscribers Indicates the number of subscribers, NodeBs,
or cells configured on a logical master RNC.
Total NodeBs
NOTE
Total Cells The logical master RNC refers to the logical RNC
that belongs to the master RNC.

Control Parameters
Peer BSC6910 RNC ID of the peer Indicates the ID of the peer RNC that forms a
RNC that resource pool with the local RNC.
forms a
resource pool
with the local
RNC
Node Redundancy Yes/No Indicates whether node redundancy is
supported.
>Master RNC in Node Yes Indicates whether the BSC serves as the
Redundancy master RNC in node redundancy. This
parameter is always set to Yes for BSC6900s.
Load Sharing Yes/No Indicates whether load sharing is supported.
>Master RNC in Load Yes Indicates whether the BSC serves as the
Sharing master RNC in load sharing. This parameter
is always set to Yes for BSC6900s.
>User-Plane Load Yes/No Indicates whether user-plane load sharing
Sharing Binding with binding with control-plane load sharing is
Control-Plane Load supported.
Sharing
Input Parameters for the Master RNC in Node Redundancy
They are requirement parameters for node redundancy and are displayed only when the
Node Redundancy parameter is set to Yes.
Redundancy NodeBs 0~Total Indicates the number of NodeBs that need to
NodeBs be backed up on the backup RNC.
This parameter is set to the same value as that
of the license item RNC in Pool Node
Redundancy (per NodeB), which is planned

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 27


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Input Parameter Value Description

by customers.
Redundancy Cells 0~Total Cells The value of this parameter can be planned
by the customer, or a default value can be
derived from the ratio of Redundancy
NodeBs to Total NodeBs.
Redundancy Subscribers 0~Total The value of this parameter can be planned
Subscribers by the customer, or a default value can be
derived from the ratio of Redundancy
NodeBs to Total NodeBs.
Input Parameters for the Master RNC in Load Sharing
They are requirement parameters for load sharing and are displayed only when the Load
Sharing parameter is set to Yes.
Overflow Subscribers 0~Total Indicates the number of subscribers that need
Subscribers to be transferred to the overflow RNC.
Iur-p Interface Parameter
Sharing Board with Iur Yes/No Indicates whether to share an interface board
with the Iur interface.
It is recommended that the interface board
not be shared with the Iur interface when load
sharing is enabled.

Table 1.2 Output parameters related to capacity transferred from the master RNC to the backup
RNC or overflow RNC(for Node Redundancy)
Output Parameter Calculation Method

Redundancy Iub CS Traffic The value of this parameter is calculated by the traffic
(including SHO) (Erl) model used by the local RNC based on the number of
redundancy subscribers. The calculation method is similar
Redundancy Iub PS DL to that used in section "Single BSC6900 Dimensioning
Payload Throughput Process" in SRAN9.0&GBSS16.0&RAN16.0 BSC6900
(including SHO) (Mbps) Configuration Principles.
Redundancy Iub PS UL  Redundancy Iub CS traffic (including SHO) (Erl) =
Payload Redundancy subscribers x [CS voice penetration ratio
Throughput(including SHO) x CS voice traffic per subscriber per BH x (1 +
(Mbps) Proportion of SHO for CS voice traffic) + CS data
penetration ratio x CS data traffic per subscriber per
Redundancy Iu-CS Traffic BH x (1 + Proportion of SHO for CS data traffic) x 2]
(Erl)  Redundancy Iub PS DL payload throughput (including
Redundancy Iu-PS DL SHO) (Mbps) = Redundancy subscribes x PS
Payload Throughput (Mbps) (including R99 and HSPA) penetration ratio x Total PS
throughput (HSPA and R99, UL+DL) per subscriber x
Redundancy Iu-PS UL Proportion of DL PS throughput x [R99 share of DL PS
Payload Throughput (Mbps) throughput per subscriber x (1 + Proportion of SHO for
PS call) + HSDPA share of DL PS throughput per
Redundancy BHCA

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 28


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Output Parameter Calculation Method

subscriber]
BHCA per EGPUa
 Redundancy Iub PS UL payload throughput (including
SHO) (Mbps) = Redundancy subscribers x PS
Redundancy Active Users (including R99 and HSPA) penetration ratio x Total PS
throughput (HSPA and R99, UL+DL) per subscriber x
Redundancy Online Users Proportion of UL PS throughput x (1 + Proportion of
SHO for PS call)
Redundancy Control Plane
Active Users  Redundancy Iu-CS traffic (Erl) = Redundancy
subscribers x (CS voice penetration ratio x CS voice
Redundancy Control Plane traffic per subscriber per BH + CS data penetration
Online Users ratio x CS data traffic per subscriber per BH x 2)
 Redundancy Iu-PS DL payload throughput (Mbps) =
Redundancy subscribers x PS (including R99 and
HSPA) penetration ratio x Total PS throughput (HSPA
and R99, UL+DL) per subscriber x Proportion of DL
PS throughput
 Redundancy Iu-PS UL payload throughput (Mbps) =
Redundancy subscribers x PS (including R99 and
HSPA) penetration ratio x Total PS throughput (HSPA
and R99, UL+DL) per subscriber x Proportion of UL
PS throughput
 Redundancy BHCA = Redundancy subscribers x [CS
voice penetration ratio x CS voice call per subscriber+
CS data penetration ratio x CS data call per subscriber
per BH+ PS (including R99 and HSPA) penetration
ratio x PS call per subscriber per BH]
NOTE
For how to calculate BHCA per EGPUa, see the BHCA capacity
of EGPUa (for Control Plane) based on given traffic model in
section "Single BSC6910 Dimensioning Process" in
SRAN9.0&GBSS16.0&RAN16.0 BSC6910 Configuration
Principles.
 Redundancy active users = Redundancy Iu-CS (Erl) +
Redundancy subscribers x PS (including R99 and
HSPA) penetration ratio x PS call per subscriber per
BH x Mean holding time (MHT) in DCH/H/FACH
state per PS call /3600)
 Redundancy online users = Redundancy active users +
Redundancy subscribers x PS (including R99 and
HSPA) penetration ratio x PS call times per subscriber
in BH x Mean holding time (MHT) in PCH per PS
call/3600
 Redundancy control plane active users = (Total
subscribers - Overflow subscribers) x [(CS voice
penetration ratio x CS voice traffic per subscriber per
BH + CS data penetration ratio x CS data traffic per
subscriber per BH x 2) + PS (including R99 and
HSPA) penetration ratio x PS call per subscriber per
BH x Mean holding time (MHT) in DCH/H/FACH
state per PS call/3600)]

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 29


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Output Parameter Calculation Method


 Redundancy control plane online users = Redundancy
control plane active users + (Total subscribers -
Overflow subscribers) x PS (including R99 and HSPA)
penetration ratio x PS call times per subscriber in BH x
Mean holding time (MHT) in PCH per PS call/3600
Redundancy NodeBs Input value of the Redundancy NodeBs parameter
Redundancy Cells Input value of the Redundancy Cells parameter
Redundancy PS Throughput Indicates the NIU capacity that needs to be provided by
Supported by NIU (Mbps) the backup RNC.
The value of this parameter is calculated by Redundancy
Iu-PS DL data plane payload throughput (Mbps)
+Redundancy Iu-PS UL data plane payload throughput
(Mbps) when the following features are enabled: WRFD-
020132 Web Browsing Acceleration, WRFD-020133 P2P
Downloading Rate Control during Busy Hour, WRFD-
150252 Video Service Rate Adaption, and WRFD-150253
VoIP Application Management or WRFD-150254
Differentiated Service Based on Application Resource
Reservation. Otherwise, this parameter is set to 0.

Table 1.3 Output parameters related to capacity transferred from the master RNC to the backup
RNC or overflow RNC(for Load Sharing)
Output Calculation Method
Parameter

Overflow Subscribers This parameter is planned by customers.


Overflow Subscribers Indicates overflow subscribers on the control plane of each
Capacity per EGPUa EGPUa on an overflow RNC, which is calculated by the
(CP) following formula:
Overflow subscribers capacity per EGPUa (CP) = Supported
subscriber number per EGPUa (for Control Plane)/B , where B
= 63% for control plane load sharing, 55% for user plane
binding with control plane load sharing.
NOTE
For how to calculate Supported subscriber number per EGPUa (for
Control Plane), see SRAN9.0&GBSS16.0&RAN16.0 BSC6910
Configuration Principles.

Overflow Active Users The following formulas are derived from the number of
overflow subscribers and the traffic model:
Overflow Online Users
 Overflow active users = Overflow subscribers x (CS voice
penetration ratio x CS Voice traffic per subscriber per BH +
CS data penetration ratio x CS data traffic per subscriber per
BH + Overflow subscribers x PS (including R99 and HSPA)
penetration ratio x PS call per subscriber per BH x Mean
holding time (MHT) in DCH/H/FACH state per PS

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 30


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Output Calculation Method


Parameter

call/3600)
 Overflow online users = Overflow active users + Overflow
subscribers x PS (including R99 and HSPA) penetration ratio
x PS call times per subscriber in BH x Mean holding time
(MHT) in PCH per PS call/3600
Iur-p throughout (Mbps)  10Mbit/s for RNC in Pool base bandwidth.
For control plane load sharing,
 Iur-p throughout = 10 + Overflow active users x 20/1000.
For user plane binding with control plane load sharing,
 Iur-p throughout = 10 + Overflow Active Users x 15/1000 +
Master RNC Cell number x 10/1000 x Overflow
subscribers/Total subscribers + ATM NodeB ratio of
Overflow RNC x Overflow subscriber x (Proportion of SHO
for CS Voice traffic x 12.2kbps x 2 x CS Voice Traffic per
sub per BH + Proportion of SHO for PS call x Total PS
throughput (HSPA and R99, UL+DL) per sub) + dual stack
NodeB ratio of Overflow RNC x Overflow subscriber x
Proportion of SHO for CS Voice traffic x 12.2kbps x 2 x CS
Voice Traffic per sub per BH.
Overflow Iub CS Traffic This parameter is valid only when user-plane load sharing
(including SHO) (Erl) binding with control-plane load sharing is enabled (when the
User-Plane Load Sharing Binding with Control-Plane Load
Overflow Iub PS DL Sharing parameter is set to Yes). Otherwise, this parameter is
Payload Throughput set to 0.
(including SHO) (Mbps)
 Overflow Iub CS traffic (including SHO) (Erl) = Overflow
Overflow Iub PS UL subscribers x [CS voice penetration ratio x CS voice traffic
Payload Throughput per subscriber per BH x (1 + Proportion of SHO for CS
(including SHO) (Mbps) voice traffic) + CS data penetration ratio x CS data traffic
per subscriber per BH x (1 + Proportion of SHO for CS data
Overflow Iu-CS Traffic traffic) x 2]
(Erl)  Overflow Iub PS DL payload throughput (including SHO)
Overflow Iu-PS DL (Mbps) = Overflow subscribes x PS (including R99 and
Payload Throughput HSPA) penetration ratio x Total PS throughput (HSPA and
(Mbps) R99, UL+DL) per subscriber x Proportion of DL PS
throughput x [R99 share of DL PS throughput per subscriber
Overflow Iu-PS UL x (1 + Proportion of SHO for PS call) + HSDPA share of DL
Payload Throughput PS throughput per subscriber]
(Mbps)  Overflow Iub PS UL payload throughput (including SHO)
(Mbps) = Overflow subscribers x PS (Including R99 and
HSPA) penetration ratio x Total PS throughput (HSPA and
R99, UL+DL) per subscriber x Proportion of UL PS
throughput x (1 + Proportion of SHO for PS call)
 Overflow Iu-CS Traffic (Erl) = Overflow subscribers x (CS
voice penetration ratio x CS voice traffic per subscriber per
BH + CS data penetration ratio x CS data traffic per
subscriber per BH x 2)
 Overflow Iu-PS DL payload throughput (Mbps) = Overflow

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 31


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Output Calculation Method


Parameter

subscribers x PS (including R99 and HSPA) penetration ratio


x Total PS throughput (HSPA and R99, UL+DL) per
subscriber x Proportion of DL PS throughput;
 Overflow Iu-PS UL payload throughput (Mbps) = Overflow
subscribers x PS (including R99 and HSPA) penetration ratio
x Total PS throughput (HSPA and R99, UL+DL) per
subscriber x Proportion of UL PS throughput
Number of Overflow These parameters are valid only when user-plane load sharing
NodeBs binding with control-plane load sharing is enabled (when the
User-Plane Load Sharing Binding with Control-Plane Load
Number of Overflow Sharing parameter is set to Yes). Otherwise, this parameter is
Cells set to 0.
 Number of Overflow NodeBs = Number of total NodeBs of
the master RNC
 Number of Overflow Cells = Number of total cells of the
master RNC
Overflow PS Indicates the PS capacity that needs to be provided by the NIU
Throughput Supported of the overflow RNC.
by NIU (Mbps) The value of this parameter is calculated by Overflow Iu-PS DL
payload throughput (Mbps)+Overflow Iu-PS UL payload
throughput (Mbps) when user-plane load sharing binding with
control-plane load sharing is enabled (when the User-Plane
Load Sharing Binding with Control-Plane Load Sharing
parameter is set to Yes) and the following features are enabled:
WRFD-020132 Web Browsing Acceleration, WRFD-020133
P2P Downloading Rate Control during Busy Hour, WRFD-
150252 Video Service Rate Adaption, and WRFD-150253 VoIP
Application Management or WRFD-150254 Differentiated
Service Based on Application Resource Reservation. Otherwise,
this parameter is set to 0.

Table 1.4 Output parameters related to hardware and hardware licenses in the RNC in Pool
configuration for a BSC6900
Output Calculation Method
Parameter

Number of Iur-p  When load sharing is not used:


Interface Boards 1. The value of this parameter is 0 when the
GOUc/GOUe/FG2c is configured for the Iur interface
and no traffic is processed over the Iur-p interface.
2. The value of this parameter is 2 when the
GOUc/GOUe/FG2c is configured for the Iur interface.
 When load sharing is used:
It is recommended that the Iur-p and Iur interfaces not share the

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 32


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Output Calculation Method


Parameter

same interface board.


Number of Iur-p Interface Boards is calculated by the following
Number of Iur-p Interface Boards = Iur-p throughout
(Mbps)/Interface Iub throughput specifications
The specifications of a board depend on the port type. For
details about the Iub throughput of interface boards, see section
"Interface Boards" in SRAN9.0&GBSS16.0&RAN16.0BSC6900
Configuration Principles.
Number of the  If load sharing is not used, the number of SPUs on the master
SPUb/SPUc Boards RNC is not affected.
 If load sharing is used, the unshareable part of an overflow
subscriber needs to be processed by the SPU on the master
RNC. The number of required SPUs is calculated by the
following formula:
Number of SPU boards = Overflow subscribers x A/
(Supported subscriber number per SPU), where A is 57% for
control plane load sharing only, 53% for user plane binding
control plane load sharing.
 The number of total SPU boards required on a master RNC is
calculated by the following formula: Number of SPU boards
= ROUNDUP [(Total subscribers - Overflow
subscribers)/Supported subscriber number per SPU +
Overflow subscribers x A/Supported subscriber number per
SPU].
NOTE
For how to calculate Supported subscriber number per SPU, see
SRAN9.0&GBSS16.0&RAN16.0 BSC6900 Configuration Principles.

Number of the DPUe  If user-plane load sharing binding with control-plane load
Boards sharing is not used, the number of DPUe boards on the
master RNC is not affected.
 If user-plane load sharing binding with control-plane load
sharing is used, the number of required DPUe boards
decreases on the master RNC (or the number remains but the
maximum CPU load decreases). The number of DPUe
boards required on the master RNC after overflow
subscribers are transferred is calculated by the following
formula (the target average CPU load is 70%):
1. Csun (Iub CS Erlang dimension) = [Iub CS traffic -
Overflow Iub CS traffic (including SHO)]/3350
2. Ps_a (Iub PS throughput traffic Mbps) = (Total
subscribers - Overflow subscribers) x PS (including R99
and HSPA) penetration ratio x Total PS throughput
(HSPA and R99, UL+DL) per subscriber x {Proportion of
DL PS throughput x [R99 share of DL PS throughput per
subscriber x (1 + Proportion of SHO for PS call) +
HSDPA share of DL PS throughput per subscriber] +
Proportion of UL PS throughput x (1 + Proportion of

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 33


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Output Calculation Method


Parameter

SHO for PS call)}


3. Psun (PS throughput dimension) = Ps_a /Actual PS
throughput capability of the DPUe
4. Auun (Active user dimension) = (Total subscribers -
Overflow subscribers) x (CS voice penetration ratio x CS
voice traffic per subscriber per BH + CS data penetration
ratio x CS data traffic per subscriber per BH + PS
(including R99 and HSPA) penetration ratio x PS call per
subscriber per BH x Mean holding time (MHT) in
DCH/H/FACH state per PS call (sec) /3600)/5880
5. Cun (Cell dimension) = Total cells/300
6. DPUe_Number = ROUNDUP[Max (Csun + Psun, Auun,
Cun)]
NOTE
Total subscribers refer to those subscribers that need to be processed by
the logical RNC of the master physical RNC. Total subscribers consist of
two parts: overflow subscribers and subscribers remained on the master
RNC. In user-plane load sharing binding with control-plane load sharing,
the control-plane data and user-plane data of overflow subscribers are
both processed on the overflow RNC. Only data of those except the
overflow subscribers is processed on the master RNC. The number of
such subscribers is calculated by deducting overflow subscribers from
total subscribers. For the traffic model related to the preceding formula,
see SRAN9.0&GBSS16.0&RAN16.0 BSC6900 Configuration Principles.
For how to evaluate the actual PS throughput capability and for details
about the traffic model, see SRAN9.0&GBSS16.0&RAN16.0 BSC6900
Configuration Principles.

FG2c (Iub)  If user-plane load sharing binding with control-plane load


sharing is not used, the number of Iub interface boards on the
GOUc/GOUe (Iub) master RNC is not affected.
 If user-plane load sharing binding with control-plane load
sharing is used, the number of required Iub interface boards
decreases on the master RNC (or the number remains but the
maximum CPU load decreases). The number of Iub interface
boards for overflow subscribers on the user plane needs to be
deducted by the number of Iub interface boards for total
subscribers on the BSC6910.
1. Cs_nbnt (CS Erlang dimension) = [Iub CS traffic -
Overflow Iub CS traffic (including SHO)]/Board Erlang
specifications
2. Ps_a = Iub PS throughput - Overflow Iub PS DL payload
throughput (including SHO) - Overflow Iub PS UL
payload throughput (including SHO)
3. Ps_nbnt (PS throughput dimension) = PS_a/Board Iub PS
throughput
4. ActUser_nbnt (Active user dimension) = (Iub active users
(CID/UDP) - Overflow active users x (1 + Proportion of
SHO for CS traffic) x 3)/Board UDPCID
5. Nb_nbnt (NodeB dimension) = Total NodeBs /Board

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 34


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Output Calculation Method


Parameter

NodeB specifications
6. Sess_nbnt (connection dimension) = (Total subscribers -
Overflow subscribers) x [CS voice penetration ratio x
(CS voice call per subscriber x 2 + CS voice call per
subscriber x Handover times per CS voice call x 1) + CS
data penetration ratio x (CS Data call per subscriber x 2 +
CS Data call per subscriber x Handover times per CS
Data call x 1) + PS (including R99 and HSPA)
penetration ratio x (PS call per subscriber per BH x 3 +
PS call per subscriber per BH x Handover times per PS
call +PS call per subscriber per BH x PS channel switch
per PS call x 1 + PS call per subscriber per BH x Cell
update per PS call x 1) + NAS signaling per subscriber
per BH x 1]/3600/Board sessions specifications
7. IUB_INT_Number = Max(Cs_nbnt + Ps_nbnt,
ActUser_nbnt, Nb_nbnt, sess_nbnt)
UOIc (Iu-CS, Iu-PS,  If user-plane load sharing binding with control-plane load
and Iur) sharing is not used, the number of Iu/Iur interface boards on
the master RNC is not affected.
FG2c (Iu-CS, Iu-PS,
and Iur)
 If user-plane load sharing binding with control-plane load
sharing is used, the number of required Iub interface boards
GOUc/GOUe (Iu-CS, decreases on the master RNC (or the number remains but the
Iu-PS, and Iur) maximum CPU load decreases). The number of Iu/Iur
interface boards for overflow subscribers on the user plane
needs to be deducted by the number of Iu/Iur interface
boards for total subscribers on the BSC6900.
1. Cs_ncnt (CS Erlang dimension) = [Iu CS traffic -
Overflow Iu-CS Traffic (including SHO)]/Board Erlang
specifications
2. Ps_a = Iu PS throughput - Overflow Iu-PS DL payload
throughput (including SHO) - Overflow Iu-PS UL
payload throughput(including SHO)
3. Ps_npnt (PS throughput dimension) = PS_a/Board PS
throughput specifications
4. OnUser_npnt (Online user dimension) = (Online users -
Overflow online users)/Board IUPS online user
specifications
5. Sess_npnt (IUPS connection dimension) = [Iu-PS session
set-up and release requirement in BH - Overflow
subscribers x PS (including R99 and HSPA) penetration
ratio x PS call times per subscriber in BH x (1 + PS
channel switch per PS call x 0.5 + Cell update per PS call
x 0.5)]/3600/Board sessions specifications
6. IUB_INT_Number = Max(Cs_nbnt + Ps_nbnt,
ActUser_nbnt, Nb_nbnt, Sess_npnt)

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 35


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Output Calculation Method


Parameter

NOTE
For capacity parameters related to Total subscribers, see section "Single BSC6900 Dimensioning
Process" in SRAN9.0&GBSS16.0&RAN16.0 BSC6900 Configuration Principles.
The calculation results are not the actual numbers of boards to be configured. The calculation results
need to be doubled in the 1+1 backup mode and one more board needs to be added in the N+1 backup
mode.

Table 1.5 Output parameters related to software licenses in the RNC in Pool configuration for a
BSC6900
Feature Software License Calculation Method
Item

RNC in Pool Node Redundancy (per Value = Redundancy NodeBs


NodeB)
RNC in Pool Load Sharing (per 500 Active Value = ROUNDUP(Overflow Active
Users) Users/500)

3.3.2 BSC6910
A BSC6910 can form a resource pool with BSC6900s or BSC6910s.
A BSC6910 can only serve as the backup/overflow RNC instead of the master RNC when it
forms a resource pool with BSC6900s.
A BSC6910 can serve as the backup/overflow RNC or the master RNC when it forms a
resource pool with BSC6910s.
Focus on the following:
This section describes the dimension of only one resource pool. When a BSC6910 serves two
resource pools, the dimension is performed for the two resource pools respectively, and the
dimension of this BSC6910 is the sum of the dimensions of the two resource pools.
The hardware and hardware license requirements obtained by referring to this section is not
the final output of the BSC6910 RNC. To totalize the hardware and hardware license
requirements of the BSC6910 RNC, perform the following three steps:
Step 1 Calculate the hardware and hardware license requirements by referring to this section.
Step 2 Accumulate the hardware and hardware license requirements in step 1 and the hardware and
hardware license requirements that are not planned for the RNC in Pool solution of the RNC.
Step 3 Round up the result obtained in step 2, and add the rounded result to the redundant hardware
and hardware requirements.
----End

1. The networking, function, and RNC role of a BSC6910 are determined by the input
control parameters.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 36


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Table 1.1 Input control parameters


Input Value Description
Parameter

Logical Master RNC Capacity Parameters


Total Subscribers Indicates the number of subscribers, NodeBs, or
cells configured on a logical master RNC.
Total NodeBs
NOTE
Total Cells The logical master RNC refers to the logical RNC that
belongs to the master RNC.

Control Parameters
Peer site RNC Type BSC6900/ Indicates the ID of the peer RNC that forms a
in the Resource Pool BSC6910/ resource pool with the local RNC. A BSC6910 can
BSC6900& form a resource pool with BSC6900s, BSC6910s, or
BSC6910 both BSC6900s and BSC6910s. You need to find
out which one of the preceding scenarios is used.
>Peer BSC6910 Peer RNC This parameter is valid when the Peer Site RNC
RNC1 ID Type in the Resource Pool parameter is set to
BSC6910 or BSC6900&BSC6910.
>Peer BSC6910 Peer RNC This parameter is valid when the Peer Site RNC
RNC2 ID Type in the Resource Pool parameter is set to
BSC6910 or BSC6900&BSC6910 and more than
one peer BSC6910 is configured.
>Peer BSC6910 Peer RNC This parameter is valid when the Peer Site RNC
RNC3 ID Type in the Resource Pool parameter is set to
BSC6910 or BSC6900&BSC6910 and more than
two peer BSC6910s are configured.
>Peer BSC6900 Peer RNC This parameter is valid when the Peer Site RNC
RNC1 ID Type in the Resource Pool parameter is set to
BSC6900 or BSC6900&BSC6910.
>Peer BSC6900 Peer RNC This parameter is valid when the Peer Site RNC
RNC2 ID Type in the Resource Pool parameter is set to
BSC6900 or BSC6900&BSC6910 and more than
one peer BSC6900 is configured.
>Peer BSC6900 Peer RNC This parameter is valid when the Peer Site RNC
RNC3 ID Type in the Resource Pool parameter is set to
BSC6900 or BSC6900&BSC6910 and more than
two peer BSC6900s are configured.
Node Redundancy YES/NO Indicates whether node redundancy is supported.
>Master RNC in YES/NO Indicates whether the local RNC serves as the
Node Redundancy master RNC in node redundancy. This parameter is
valid when the Peer Site RNC Type in the
Resource Pool parameter is set to BSC6910 or
BSC6900&BSC6910.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 37


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Input Value Description


Parameter

>Backup RNC in YES/NO Indicates whether the local RNC serves as the
Node Redundancy backup RNC in node redundancy.
>>Redundancy Mode 1+1/N+1 Indicates whether the backup mode is 1+1(Sum) or
in Backup RNC N+1(Max). This parameter is valid only when more
than one peer RNC is configured.
Load Sharing YES/NO Indicates whether load sharing is supported.
>Master RNC in YES/NO Indicates whether the local RNC serves as the
Load Sharing master RNC in load sharing. This parameter is valid
when the Peer Site RNC Type in the Resource
Pool parameter is set to BSC6910 or
BSC6900&BSC6910.
>>User-Plane Load YES/NO Indicates whether the master RNC supports user-
Sharing Banding with plane load sharing binding with control-plane load
Control-Plane Load sharing.
Sharing(Master RNC)
>Overflow RNC in YES/NO Indicates whether the local RNC serves as the
Load Sharing overflow RNC in load sharing.
>>User-Plane Load YES/NO Indicates whether the overflow RNC supports user-
Sharing Banding with plane load sharing binding with control-plane load
Control Plane Load sharing.
Sharing (Overflow
RNC)
Sharing Board with YES/NO Indicates whether to share an interface board with
Iur the Iur interface.
It is recommended that the board be shared with the
Iur interface when 10 GE boards are configured for
the Iur interface, but not be shared with the Iur
interface when 10 GE boards are not used for the
Iur interface and when load sharing is used.

2. A BSC6910 serves as the master RNC in node redundancy or load sharing.

Table 1.2 Input parameters when a BSC6910 serves as the master RNC
Input Value Description
Parameter

Input Parameters Related to the Master RNC in Node Redundancy


Redundancy NodeBs 0~Total NodeBs Indicates the number of NodeBs that need to be
backed up on the backup RNC, which is
planned by customers.
Redundancy Cells 0~Total Cells Indicates the number of cells that need to be
backed up on the backup RNC, which can be

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 38


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Input Value Description


Parameter

planned by customers or be calculated by the


following formula: Total Cells x Redundancy
NodeBs/Total NodeBs
Redundancy 0~Total Indicates the number of subscribers that need
Subscribers Subscribers to be backed up on the backup RNC, which can
be planned by customers or be calculated by
the following formula: Total Subscribers x
Redundancy NodeBs/Total NodeBs
NOTE
Total subscribers refer to the total subscribers on the
local logical RNC.

Input Parameters Related to the Master RNC in Load Sharing


Overflow Subscribers 0~Total Indicates the number of overflow subscribers,
Subscribers which is planned by customers.

Information provided in the preceding table is the same as that for BSC6900s.

Table 1.3 Output parameters related to capacity transferred to the backup RNC(for Node
Redundancy)
Output Parameter Calculation Method

Parameters Related to Capacity Transferred from the Master RNC to the Backup RNC in
Node Redundancy
Redundancy Iub CS Traffic The value of this parameter is calculated by the traffic
(including SHO) (Erl) model used by the local RNC based on the number of
redundancy subscribers. The calculation method is
Redundancy Iub PS DL Payload the same as that in Table 3-7.
Throughput (including SHO)
(Mbps)
Redundancy Iub PS UL Payload
Throughput (including SHO)
(Mbps)
Redundancy Iu-CS Traffic (Erl)
Redundancy Iu-PS DL Payload
Throughput (Mbps)
Redundancy Iu-PS UL Payload
Throughput (Mbps)
Redundancy BHCA
BHCA per EGPUa
Redundancy Active Users
Redundancy Online Users

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 39


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Output Parameter Calculation Method

Redundancy Control Plane Active


Users
Redundancy Control Plane Online
Users
Redundancy NodeBs Input parameters
Redundancy Cells Input parameters
Redundancy PS Throughput Indicates the NIU capacity that needs to be provided
Supported by NIU (Mbps) by the backup RNC.
The value of this parameter is calculated by
Redundancy Iu-PS DL data plane payload throughput
(Mbps)+Redundancy Iu-PS UL data plane payload
throughput (Mbps) when the following features are
enabled: WRFD-020132 Web Browsing Acceleration,
WRFD-020133 P2P Downloading Rate Control
during Busy Hour, WRFD-150252 Video Service
Rate Adaption, and WRFD-150253 VoIP Application
Management or WRFD-150254 Differentiated
Service Based on Application Resource Reservation.
Otherwise, this parameter is set to 0.

Table 1.4 Output parameters related to capacity transferred to the overflow RNC(for Load
Sharing)
Output Parameter Calculation Method

Overflow Subscribers This parameter is planned by customers.


Overflow Subscribers Capacity per Overflow subscribers on the control plane of each
EGPUa (CP) EGPUa in an overflow RNC, which is calculated in
the same method in Table 3-8.
Overflow Active Users The value of this parameter is calculated by the
traffic model used by the local RNC based on the
Overflow Online Users number of overflow subscribers. The calculation
method is the same as that in Table 3-8.
Iur-p Throughout (Mbps) 10 Mbit/s basic traffic consumption + 20 kbit/s
signaling traffic required by each overflow active
user10Mbit/s for RNC in Pool.
For control plane load sharing,
Iur-p throughout = 10 + Overflow active users x
20/1000.
For user plane binding with control plane load
sharing,
Iur-p throughout = 10 + Overflow Active Users *
15/1000 + Cell number of Master RNC * 10/1000 *

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 40


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Output Parameter Calculation Method

Overflow subscribers/Total subscribers + ATM


NodeB ratio of Overflow RNC * Overflow
subscriber * (Proportion of SHO for CS Voice traffic
* 12.2kbps * 2 * CS Voice Traffic per sub per BH +
Proportion of SHO for PS call * Total PS throughput
(HSPA and R99, UL+DL) per sub) + dual stack
NodeB ratio of Overflow RNC * Overflow
subscriber * Proportion of SHO for CS Voice traffic
* 12.2kbps * 2 * CS Voice Traffic per sub per BH.
Overflow Iub CS Traffic (including The value of this parameter is calculated by the
SHO) (Erl) traffic model used by the local RNC based on the
number of overflow subscribers. The calculation
Overflow Iub PS DL Payload method is the same as that in Table 3-8.
Throughput (including SHO)
(Mbps)
Overflow Iub PS UL Payload
Throughput (including SHO)
(Mbps)
Overflow Iu-CS Traffic (Erl)
Overflow Iu-PS DL Payload
Throughput (Mbps)
Overflow Iu-PS UL Payload
Throughput (Mbps)
Overflow NodeB Number Overflow NodeB number = Total NodeBs
Overflow Cell Number Overflow Cell number = Total Cells

Overflow PS Throughput Indicates the PS capacity that needs to be provided


Supported by NIU (Mbps) by the NIU of the overflow RNC.
The value of this parameter is calculated by
Overflow Iu-PS DL data plane payload throughput
(Mbps)+Overflow Iu-PS UL data plane payload
throughput (Mbps) when user-plane load sharing
binding with control-plane load sharing is used and
the following features are enabled: WRFD-020132
Web Browsing Acceleration, WRFD-020133 P2P
Downloading Rate Control during Busy Hour,
WRFD-150252 Video Service Rate Adaption, and
WRFD-150253 VoIP Application Management or
WRFD-150254 Differentiated Service Based on
Application Resource Reservation. Otherwise, this
parameter is set to 0.

Information in the preceding table is similar to that for BSC6900s.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 41


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Table 1.5 Output parameters related to hardware and hardware licenses when a BSC6910 serves
as the master RNC
Output Parameter Calculation Method

Number of Iur-p Interface  When load sharing is not used:


Boards 1. The value of this parameter is 0 when the
GOUc/GOUe/FG2c/EXOUa is configured for the
Iur interface and no traffic is processed over the Iur-
p interface.
2. The value of this parameter is 2 when the
GOUc/GOUe/FG2c/EXOUa is configured for the
Iur interface. The specifications of a board depend
on the port type.
 When load sharing is used:
1. It is recommended that the Iur-p and Iur interfaces
not share one interface board when the
GOUc/GOUe/FG2c is used, but share one interface
board when the EXOUa is used.
2. Number of Iur-p Interface Boards = Iur-p
throughout(Mbps)/Board Iub throughput capability.
The board type (GOUc/GOUe/FG2c/EXOUa) is
determined the port type. For Iub throughput specifications
of interface boards, see section "Interface boards" in
SRAN9.0&GBSS16.0&RAN16.0 BSC6910 Configuration
Principles.
Number of EGPUa (CP)  If load sharing is not used, the number of EGPUa (CP)
Boards boards on the master RNC is not affected.
 If load sharing is used, the unshareable part of an
overflow subscriber needs to be processed by the
EGPUa (CP) boards on the master RNC. The number
of required EGPUa (CP) boards is calculated by the
following formula: Number of EGPUa (CP) boards =
Overflow subscribers x A/Supported subscriber number
per EGPUa (for the control plane), where A is 57% for
control plane load sharing, 53% for user plane binding
with control plane load sharing.
The number of total EGPUa (CP) boards required on a
master RNC is calculated by the following formula:
Number of EGPUa (CP) boards = ROUNDUP[(Total
subscribers - Overflow subscribers)/Supported subscriber
number per EGPUa (for the control plane) + Overflow
subscribers x A/Supported subscriber number per EGPUa
(for Control Plane)].
For how to calculate Supported subscriber number per
EGPUa (for the control plane), see
SRAN9.0&GBSS16.0&RAN16.0 BSC6910 Configuration
Principles. .
Number of EGPUa (UP)  If control-plane load sharing only, the number of EGPUa
Boards (UP) boards on the master RNC is not affected.
 If user-plane load sharing binding with control-plane

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 42


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Output Parameter Calculation Method

load sharing is used, the number of required EGPUa


(UP) boards decreases on the master RNC (or the
number remains but the maximum CPU load
decreases). The number of EGPUa (UP) boards
required on the master RNC after overflow subscribers
are transferred is calculated by the following formula:
1. Csun (Iub CS Erlang dimension) = [Iub CS traffic -
Redundancy Iub CS traffic (including SHO)]/10050
2. Ps_a (Iub PS throughput traffic dimension Mbps) =
(Total Subscribers - Overflow subscribers) x PS
(including R99 and HSPA) penetration ratio x Total
PS throughput (HSPA and R99, UL+DL) per
subscriber x {Proportion of DL PS throughput x
[R99 share of DL PS throughput per subscriber x (1
+ Proportion of SHO for PS call) + HSDPA share of
DL PS throughput per subscriber] + Proportion of
UL PS throughput x (1 + Proportion of SHO for PS
call)}
3. Psun (PS throughput dimension) = Ps_a/EGPUa
(UP) only board actual PS throughput capability
4. Auun (Active user dimension) = (Total subscribers -
Overflow subscribers) x (CS voice penetration ratio
x CS voice traffic per subscriber per BH + CS data
penetration ratio x CS data traffic per subscriber per
BH + PS (including R99 and HSPA) penetration
ratio x PS call per subscriber per BH x Mean
holding time (MHT) in DCH/H/FACH state per PS
call (sec)/3600)/28000
5. Cun (Cell dimension) = Total cells/1400
6. EGPU_UP_Number = Max(Csun + Psun, Auun,
Cun)
NOTE
Total subscribers refer to those subscribers that need to be
processed by the logical RNC of the master physical RNC. Total
subscribers consist of two parts: overflow subscribers and
subscribers remained on the master RNC. In user-plane load
sharing binding with control-plane load sharing, the control-plane
data and user-plane data of overflow subscribers are both
processed on the overflow RNC. Only data of those except the
overflow subscribers is processed on the master RNC. The
number of such subscribers is calculated by deducting overflow
subscribers from total subscribers. For the traffic model related to
the preceding formula, see section "Single BSC6910
Dimensioning Process" in SRAN9.0&GBSS16.0&RAN16.0
BSC6910 Configuration Principles.
For how to obtain the actual PS throughput capability of an
EGPUa (UP) only board, see section "Impact of the Traffic Model
on Configurations" in SRAN9.0&GBSS16.0&RAN16.0 BSC6910
Configuration Principles.

FG2c (Iub)  If control-plane load sharing only, the number of Iub


interface boards on the master RNC is not affected.
GOUc/GOUe (Iub)

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 43


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Output Parameter Calculation Method

EXOUa (Iub)  If user-plane load sharing binding with control-plane


load sharing is used, the number of required Iub
interface boards decreases on the master RNC (or the
number remains but the maximum CPU load
decreases). The number of Iub interface boards for
overflow subscribers on the user plane needs to be
deducted by the number of Iub interface boards for
total subscribers on the BSC6910.
1. Cs_nbnt (CS Erlang dimension) = [Iub CS traffic -
Overflow Iub CS traffic (including SHO)]/Board
Erlang specifications
2. Ps_a = Iub PS throughput - Overflow Iub DL
payload throughput for PS (including SHO) -
Overflow Iub UL payload throughput for PS
(including SHO)
3. Ps_nbnt (PS Throughput dimension) = Ps_a/Board
PS throughput specifications (see Note.)
4. ActUser_nbnt (Active user dimension) = [Iub active
users (CID/UDP) -Overflow active users x (1 +
Proportion of SHO for CS traffic) x 3]/Board
UDPCID specifications
5. Nb_nbnt (NodeB dimension) = Total NodeBs/Board
NodeB specifications
6. IUB_INT_Number = Max(Cs_nbnt + Ps_nbnt,
ActUser_nbnt, Nb_nbnt)
NOTE
The PS throughput capability of an EXOUa over the Iub interface
is related to the actual average transmission packet size over the
Iub interface. For details, see section "Impact of the Traffic Model
on Configurations" in SRAN9.0&GBSS16.0&RAN16.0 BSC6910
Configuration Principles. .

UOIc (Iu-CS, Iu-PS, and Iur)  If control-plane load sharing only, the number of Iu/Iur
interface boards on the master RNC is not affected.
FG2c (Iu-CS, Iu-PS, and Iur)
 If user-plane load sharing binding with control-plane
GOUc/GOUe (Iu-CS, Iu-PS, load sharing is used, the number of required Iub
and Iur) interface boards decreases on the master RNC (or the
number remains but the maximum CPU load
EXOUa (Iu-CS, Iu-PS, and decreases). The number of Iu/Iur interface boards for
Iur) overflow subscribers on the user plane needs to be
deducted by the number of Iu/Iur interface boards for
total subscribers on the BSC6910.
1. Cs_ncnt (CS Erlang dimension) = [Iu CS traffic -
Overflow Iu - CS traffic (including SHO)]/Board
Erlang specifications
2. Ps_a = Iu PS throughput - Overflow Iu-PS DL
payload throughput (including SHO) - Overflow Iu-
PS UL payload throughput (including SHO)
3. Ps_npnt (PS throughput dimension) = PS_a/Board
PS throughput specifications (see Note.)

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 44


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Output Parameter Calculation Method

4. OnUser_npnt (Online user dimension) = Overflow


online users/Board Iu-PS online user specifications
5. Sess_npnt (Iu-PS connection dimension) = Iu-PS
session setup and release requirement in BH -
Overflow subscribers x PS (including R99 and
HSPA) penetration ratio x PS call times per
subscriber in BH x (1 + PS channel switch per PS
call x 0.5 + Cell update per PS call x 0.5)/3600
6. IUIUR_INT_Number = Max(Cs_nbnt + Ps_nbnt,
ActUser_nbnt, Nb_nbnt, Sess_npnt)
NOTE
The Iu-PS throughput capability of an EXOUa is related to the
actual average transmission packet size over the Iu-PS interface.
For details, see section "Impact of the Traffic Model on
Configurations" in SRAN9.0&GBSS16.0&RAN16.0 BSC6910
Configuration Principles. .

Hardware license: Number of actually required hardware licenses =


RNC Active User Hardware ROUNDUP[(Control plane active users - Overflow Active
Capacity (per 1000 Active Users)/1000]
Users)
Hardware license: Number of actually required hardware licenses =
RNC Throughput Hardware ROUNDUP{[Iub CS traffic - Overflow Iub CS traffic
Capacity (per 50Mbps) (including SHO)] x 12.2 kbit/s x 2/1000 + Iub PS
throughput - Overflow Iub PS DL payload throughput
(including SHO) - Overflow Iub PS UL payload
throughput (including SHO)}

NOTE
For capacity parameters related to Total subscribers, see section "Single BSC6900 Dimensioning
Process" in SRAN9.0&GBSS16.0&RAN16.0 BSC6910 Configuration Principles. .
The calculation results are not the actual numbers of boards to be configured. The calculation results
need to be doubled in the 1+1 backup mode and one more board needs to be added in the N+1 backup
mode.

Table 1.6 Output parameters related to software licenses when a BSC6910 serves as the master
RNC
Feature Software License Calculation Method
Item

RNC in Pool Node Redundancy (per Value = Redundancy NodeBs


NodeB)
RNC in Pool Load Sharing (per 500 Active Value = ROUNDUP(Overflow Active
Users) Users/500)

Information provided in the preceding table is the same as that for BSC6900s.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 45


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

3. A BSC6910 serves as the backup RNC or overflow RNC in node redundancy or load
sharing.

Table 1.7 Input parameters (intermediate parameters related to capacity transferred from the
master RNC to the backup RNC) when a BSC6910 serves as the backup RNC and the calculation
results
Input Parameter Calculation Method

Capacity Requirements from Peer Master RNC 1


Redundancy Iub CS Traffic (including These parameters serve as the input for the
SHO) (Erl) local RNC, which come from the calculation
results of the intermediate parameters for
Redundancy Iub PS DL Payload peer master RNC 1 (see Table 3-7 or Table
Throughput (including SHO) (Mbps) 3-13). They can be used as impact factors to
calculate the hardware and hardware license
Redundancy Iub PS UL Payload
requirements.
Throughput (including SHO) (Mbps)
Redundancy Iu-CS Traffic (Erl)
Redundancy Iu-PS DL Payload Throughput
(Mbps)
Redundancy Iu-PS UL Payload Throughput
(Mbps)
Redundancy BHCA
BHCA per EGPUa
Redundancy Active Users in BH
Redundancy Online Users in BH
Redundancy Control Plane Active Users
Redundancy Control Plane Online Users
Redundancy NodeBs
Redundancy Cells
Redundancy PS Throughput Supported by
NIU (Mbps)
Capacity Requirements from Peer Master RNC 2
Same as the output of peer master RNC 1. These parameters serve as the input for the local
RNC, which come from the calculation results of the intermediate parameters for peer
master RNC 2 (see Table 3-7 or Table 3-13).
Capacity Requirements from Peer Master RNC 3
Same as the output of peer master RNC 1. These parameters serve as the input for the local
RNC, which come from the calculation results of the intermediate parameters for peer
master RNC 3 (see Table 3-7 or Table 3-13).

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 46


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Input Parameter Calculation Method

Output Parameter (Calculated Intermediate Calculation Method


Parameters)
Backup Iub CS Traffic(including SHO)  Based on the value of the Redundancy
(Erl) Mode in Backup RNC parameter:
Backup Iub PS DL Payload Throughput 1. 1+1: Sum up the values of the same
(including SHO) (Mbps) parameter of master RNC 1 to master
RNC 3.
Backup Iub PS UL Payload Throughput 2. N+1: Use the maximum value of the
(including SHO) (Mbps) same parameter of master RNC 1 to
master RNC 3.
Backup Iu-CS Traffic (Erl)
Calculate the values of these parameters
Backup Iu-PS DL Payload Throughput using the preceding method.
(Mbps)  The Backup BHCA and Backup BHCA
Backup Iu-PS UL Payload Throughput per EGPUa parameters are not
(Mbps) calculated using the preceding methods.
1. In 1+1 backup mode:
Backup BHCA
Backup BHCA = BHCA for master
Backup BHCA per EGPUa RNC1 + BHCA for master RNC2 +
BHCA for master RNC3 .
Backup Active Users in BH
Backup BHCA per EGPUa = Backup
Backup Online Users in BH BHCA/(BHCA for master RNC1/
Backup BHCA per EGPUa for master
Backup Control Plane Active Users RNC1 + BHCA for master RNC2/
Backup BHCA per EGPUa for master
Backup Control Plane Online Users RNC2 + BHCA for master RNC3/
Backup NodeB Number Backup BHCA per EGPUa for master
RNC3 ).
Backup Cell Number 2. In N+1 backup mode:
Backup PS Capacity Supported by NIU Calculate the BHCA and BHCA per
(Mbps) EGPUa parameters of each master
RNC and use the corresponding
maximum values.

Table 1.8 Input parameters (intermediate parameters related to capacity transferred from the
master RNC) when a BSC6910 serves as the overflow RNC in load sharing
Input Parameter Calculation Method

Capacity Requirements from Peer Master RNC 1


Overflow Subscribers These parameters serve as the input for the
local RNC, which come from the calculation
Overflow Subscribers Capacity per EGPUa results of the intermediate parameters for
(CP) peer master RNC 1 (see Table 3-8 or Table
3-14). They can be used as impact factors to
Overflow Active Users
calculate the hardware and hardware license
Overflow Online Users requirements.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 47


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Input Parameter Calculation Method

Overflow Iub CS Traffic (including SHO)


(Erl)
Overflow Iub PS DL Payload Throughput
(including SHO) (Mbps)
Overflow Iub PS UL Payload Throughput
(including SHO) (Mbps)
Overflow Iu-CS Traffic (Erl)
Overflow Iu-PS DL Payload Throughput
(Mbps)
Overflow Iu-PS UL Payload Throughput
(Mbps)
Iur-p Throughout (Mbps)
Overflow NodeB Number
Overflow Cell Number
Overflow PS Throughput Supported by NIU
(Mbps)
Capacity Requirements from Peer Master RNC 2
Same as the output of peer master RNC 1These parameters serve as the input for the local
RNC, which come from the calculation results of the intermediate parameters for peer
master RNC 2 (see Table 3-8 or Table 3-14).
Capacity Requirements from Peer Master RNC 3
Same as the output of peer master RNC 1These parameters serve as the input for the local
RNC, which come from the calculation results of the intermediate parameters for peer
master RNC \3 (see Table 3-8 or Table 3-14).

Output Parameter (Calculated Intermediate Calculation Method


Parameters)
Total Overflow Subscribers Sum up the values of the same parameter of
master RNC 1 to master RNC 3.
Average Overflow Subscribers Capacity per
EGPUa (CP)
Total Overflow Active Users
Total Overflow Online Users
Total Overflow Iub CS Traffic (including
SHO) (Erl)
Total Overflow Iub PS DL Payload
Throughput (including SHO) (Mbps)
Total Overflow Iub PS UL Payload

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 48


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Input Parameter Calculation Method

Throughput (including SHO) (Mbps)


Total Overflow Iu-CS Traffic (Erl)
Total Overflow Iu-PS DL Payload
Throughput (Mbps)
Total Overflow Iu-PS UL Payload
Throughput (Mbps)
Total Iur-p Throughout (Mbps)
Total Overflow NodeB Number
Total Overflow Cell Number
Total Overflow PS Throughput Supported
by NIU (Mbps)

Table 1.9 Output parameters related to hardware and hardware licenses when a BSC6910 serves
as the backup RNC or overflow RNC
Hardware Calculation Method
and
Hardware
License
Item

EGPUa for  When a BSC6910 serves as the backup RNC in node redundancy:
Control Plane in 1. Nr_bn (BHCA dimension) = Backup BHCA/Backup BHCA per
RNC Pool EGPUa
2. Nr_aucn (Active user dimension) = Backup active users/35000
3. Nr_oucn (Online user dimension) = Backup online users/70000
4. Nr_nbcn (NodeB dimension) = Backup NodeB number/700
5. Nr_ccn (Cell dimension) = Backup cell number/1400
6. Nr_EGPUa_CP_Number = Max(Nr_bn, Nr_aucn, Nr_oucn,
Nr_nbcn, Nr_ccn)
 When a BSC6910 serves as the overflow RNC in load sharing:
1. Ls_bn (BHCA dimension) = Total overflow subscribers /Average
overflow subscribers capacity per EGPUa (CP)
2. Ls_aucn (Active user dimension) = Total overflow active
users/35000
3. Ls_oucn (Online user dimension) = Total overflow online
users/70000
4. Ls_nbcn (NodeB dimension) = Total overflow NodeB
number/700
5. Ls_ccn (Cell dimension) = Total overflow cell number/1400
6. Ls_EGPUa_CP_Number = Max(Ls_bn, Ls_aucn, Ls_oucn,

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 49


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Hardware Calculation Method


and
Hardware
License
Item

Ls_nbcn, Ls_ccn)
 When a BSC6910 serves as both the backup RNC in node redundancy
and the overflow RNC in load sharing:
EGPUa_CP_Number = Max(Nr_EGPUa_CP_Number,
Ls_EGPUa_CP_Number)
EGPUa for  When a BSC6910 serves as the backup RNC in node redundancy:
User Plane in 1. Nr_a (Total Iub PS throughput) = Backup Iub DL payload
RNC Pool throughput for PS (including SHO)+ Backup Iub UL payload
throughput for PS (including SHO)
2. Nr_aun (PS throughput dimension) = Nr_a/ EGPUa (UP) only
board actual PS throughput capability(see Note)
3. Nr_bun (CS Erlang dimension) = Backup Iub CS traffic
(including SHO)/10050
4. Nr_auun (Active user dimension) = Backup active users/28000
5. Nr_cun (Cell dimension) = Backup cell number/1400
6. Nr_EGPU_UP_Number = Max(Nr_aun+Nr_bun, Nr_auun,
Nr_cun)
 When a BSC6910 serves as the overflow RNC in load sharing:
1. Ls_a (Total Iub PS Throughput) = Total overflow Iub DL payload
throughput for PS (including SHO)+ Total overflow Iub UL
payload throughput for PS (including SHO)
2. Ls_aun (PS throughput dimension) = Ls_a/ EGPUa (UP) only
board actual PS throughput capability(see Note)
3. Ls_bun (CS Erlang dimension) = Total Overflow Iub CS traffic
(including SHO)/10050
4. Ls_auun (Active user dimension) = Total overflow active
users/28000
5. Ls_cun (Cell dimension) = Total overflow cell number/1400
6. Ls_EGPU_UP_Number = Max(Ls_aun + Ls_bun, Ls_auun,
Ls_cun)
 When a BSC6910 serves as both the backup RNC in node redundancy
and the overflow RNC in load sharing:
EGPUa_UP_Number = Max(Nr_EGPUa_UP_Number,
Ls_EGPUa_UP_Number)
NOTE
For how to obtain the EGPUa (UP) only board actual PS throughput capability,
see section "Impact of the Traffic Model on Configurations" in
SRAN9.0&GBSS16.0&RAN16.0 BSC6910 Configuration Principles.

EGPUa = ROUNDUP(EGPUa for Control Plane in RNC Pool + EGPUa for


(CP+UP) User Plane in RNC Pool + EGPUa for the BSC6910 itself*) + 1
*EGPUa for the BSC6910 itself refers to the EGPUa required for

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 50


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Hardware Calculation Method


and
Hardware
License
Item

processing the data that is irrelevant to any resource pools.


For details about the capacity planning, see section "Single BSC6910
Dimensioning Process" in SRAN9.0&GBSS16.0&RAN16.0 BSC6910
Configuration Principles. This capacity may be 0 when the BSC6910
has no independent logical RNC.
ENIUa  When a BSC6910 serves as the backup RNC in node redundancy:
Nr_ENIUa_Number = Total overflow PS throughput supported by
NIU/8000
 When a BSC6910 serves as the overflow RNC in load sharing:
Ls_ENIUa_Number = Backup PS capacity supported by NIU/8000
 When a BSC6910 serves as both the backup RNC in node redundancy
and the overflow RNC in load sharing:
ENIUa_Number = Max(Nr_ENIUa_Number, Ls_ENIUa_Number)
AOUc(Iub)  When a BSC6910 serves as the backup RNC in node redundancy:
UOIc(Iub) 1. Nr_a (Total Iub PS Throughput) = Backup Iub PS DL payload
throughput (including SHO) + Backup Iub PS UL payload
FG2c(Iub) throughput (including SHO)
2. Nr_btpn (PS throughput dimension) = Nr_a/Interface board Iub
GOUc/GOUe(I
interface PS throughput specifications (See Note.)
ub)
3. Nr_btcn (CS Erlang dimension) = Backup Iub CS traffic
EXOUa(Iub) (including SHO)/Interface board Erlang specifications
4. Nr_btan (Active user dimension) = (Backup active users x
3/Interface board CID_UDP specifications
5. Nr_btnn (NodeB dimension) = Backup NodeB number/Interface
board NodeB specifications
6. Nr_Iub_INT_Number = Max(Nr_btpn + Nr_btcn, Nr_btan,
Nr_btnn)
 When a BSC6910 serves as the overflow RNC in load sharing:
1. If user-plane load sharing binding with control-plane load sharing is
used:
a. Ls_a (Total Iub PS Throughput) = Total overflow Iub PS DL
payload throughput (including SHO) + Total overflow Iub PS UL
payload throughput (including SHO)
b. Ls_btpn (PS throughput dimension) = Ls_a/Interface board Iub
interface PS throughput specifications (See Note.)
c. Ls_btcn (CS Erlang dimension) = Total overflow Iub CS traffic
(including SHO)/Interface board Erlang specifications
d. Ls_btan (Active user dimension) = Total overflow active users x
3)/Interface board CID_UDP specifications
e. Ls_btnn (NodeB dimension) = Total overflow NodeB
number/Interface board NodeB specifications

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 51


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Hardware Calculation Method


and
Hardware
License
Item

f. Ls_Iub_INT_Number = Max(Ls_btpn + Ls_btcn, Ls_btan,


Ls_btnn)
2. If control-plane load sharing is used, the value of
Ls_Iub_INT_Number is 0.
 When a BSC6910 serves as both the backup RNC in node redundancy
and the overflow RNC in load sharing:
IUB_INT_Number = Max(Nr_Iub_INT_Number,
Ls_Iub_INT_Number)
NOTE
The PS throughput capability of an EXOUa over the Iub interface is related to the
actual average transmission packet size over the Iub interface. For details, see
SRAN9.0&GBSS16.0&RAN16.0 BSC6910 Configuration Principles.

UOIc  When a BSC6910 serves as the backup RNC in node redundancy:


(IuCS&IuPS&I 1. Iu-CS
ur) a. Nr_ctn (CS Erlang dimension) = Backup Iu-CS traffic/Interface
FG2c board Erlang specification
(IuCS&IuPS&I b. Nr_Iu-CS_INT_Number = Nr_ctn
ur) 2. Iu-PS
c. Nr_Ptan (PS throughput dimension) = (Backup Iu-PS DL payload
GOUc/GOUe
throughput + Backup Iu-PS UL payload throughput) / Iu-PS
(IuCS&IuPS&I interface board PS throughput specifications (See Note.)
ur)
d. Nr_Puun (Online user dimension) = Backup online users/Number
EXOUa of online users on the Iu-PS interface board
(IuCS&IuPS&I e. Nr_Iu-PS_INT_NUM = Max(Nr_ptan, Nr_puun)
ur)  When a BSC6910 serves as the overflow RNC in load sharing:
1. Iu-CS
a. Ls_ctn (CS Erlang dimension) = Total overflow Iu-CS
traffic/Interface board Erlang specifications
b. Ls_Iu-CS_INT_Number = Ls_ctn
2. Iu-PS
c. Ls_Ptan (PS Throughput dimension) = (Total overflow Iu-PS DL
data plane payload throughput + Total overflow Iu-PS UL data
plane payload throughput)/Iu-PS interface board PS throughput
specifications (See Note.)
d. Ls_Puun (Online user dimension) = Total overflow online
users/Number of online users on the Iu-PS interface board
e. Ls_Iu-PS_INT_NUM = Max(Ls_ptan, Ls_puun)
 When a BSC6910 serves as both the backup RNC in node redundancy
and the overflow RNC in load sharing:
1. Iu-CS_INT_Number = Max(Nr_Iu-CS_INT_Number, Ls_Iu-
CS_INT_Number)

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 52


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Hardware Calculation Method


and
Hardware
License
Item

2. Iu-PS_INT_Number = Max(Nr_Iu-PS_INT_Number, Ls_Iu-


PS_INT_Number)
NOTE
Iu-PS interface board PS throughput specifications: The specifications of an
EXOUaare related to the actual packet size over the Iu-PS interface. For details,
see SRAN9.0&GBSS16.0&RAN16.0 BSC6910 Configuration Principles. The
specifications of other boards are fixed.

RNC  When a BSC6910 serves as the backup RNC in node redundancy:


Throughput Nr_Throughput_hw_license = [BackupIub DL payload throughput for
Hardware PS (including SHO) + Backup Iub UL payload throughput for PS
Capacity (per (including SHO) + Backup Iub CS traffic (including SHO) x 12.2 x
50Mbps) 2/1000]/50
 When a BSC6910 serves as the overflow RNC in load sharing:
Ls_Throughput_hw_license = [Total overflowIub DL payload
throughput for PS (including SHO) + Total overflowIub UL payload
throughput for PS (including SHO) + Total overflowIub CS traffic
(including SHO) x 12.2 x 2/1000]/50
 When a BSC6910 serves as both the backup RNC in node redundancy
and the overflow RNC in load sharing:
Throughput_hw_license =
ROUNDUP[ Max( Nr_Throughput_hw_license,
Ls_Throughput_hw_license)]
RNC Active  When a BSC6910 serves as the backup RNC in node redundancy:
User Hardware Nr_ActiveUser_hw_license = Backup active users/1000
Capacity (per
1000 Active
 When a BSC6910 serves as the overflow RNC in load sharing:
Users) Nr_AcitiveUser_hw_License = Total overflow active user/1000
 When a BSC6910 serves as both the backup RNC in node redundancy
and the overflow RNC in load sharing:
ActiveUser_hw_license =
ROUNDUP[ Max( Nr_ActiveUser_hw_license,
Nr_AcitiveUser_hw_License)]
Network  When a BSC6910 serves as the backup RNC in node redundancy:
Intelligence Nr_NewInteTpt_hw_license = Total overflow PS throughput supported
Throughput(per by NIU / 50
50Mbps)
 When a BSC6910 serves as the overflow RNC in load sharing:
Ls_ NewInteTpt_hw_license = Overflow PS capacity supported by
NIU/50
 When a BSC6910 serves as both the backup RNC in node redundancy
and the overflow RNC in load sharing:
NewInteTpt_hw_license =
ROUNDUP[ Max( Nr_NewInteTpt_hw_license, Ls_

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 53


Copyright © Huawei
Technologies Co., Ltd.
RAN16.0 RNC in Pool Configuration Principles 3 RNC Capacity Dimensioning

Hardware Calculation Method


and
Hardware
License
Item

NewInteTpt_hw_license)]

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 54


Copyright © Huawei
Technologies Co., Ltd.
4 Software Configuration Principles for RNC in Pool
RAN16.0 RNC in Pool Configuration Principles Features

4 Software Configuration
Principles for RNC in Pool Features

About This Chapter


4.1 Software and License Configuration Principles for RNC in Pool Overall Functions
4.2 License Configuration Principles for Each Physical RNC on an RNC in Pool Network
4.3 Software and License Configurations for RNC in Pool Load Sharing
4.4 Software and License Configurations for RNC in Pool Node Redundancy

4.1 Software and License Configuration


Principles for RNC in Pool Overall Functions
 If the BSC6910 works as a backup RNC or an overflow RNC, hardware functions, and
licenses for optional features WRFD-150240 RNC in Pool Multiple Logical RNCs and
WRFD-141201RNC User Plane/Control Plane Dynamically Sharing need to be
configured only.
 On an RNC in Pool network, after the effective licenses on the master RNC are
synchronized to the backup RNCs or overflow RNCs. Therefore, licenses for the RNC in
Pool features and features that are already planned on the master BSC6900 or BSC6910
need not to be planned on the backup RNCs or overflow RNCs.
 If the backup RNCs or overflow RNCs also function as NodeBs providing services not
included in the RNC in Pool solution, licenses for these services still need to be planned.
 RNC in Pool Node Redundancy and RNC in Pool Load Sharing are independent features
and can be configured together or separately.
In SRAN8.0, RNC in Pool features are applicable only in the following two scenarios:
1. Resource Pool with BSC6900 and BSC6910 (one to three BSC6900s+one BSC6910):
In load sharing scenarios, a BSC6910 can share load on the BSC6900, but a BSC6900
cannot share load on the BSC6910. In node redundancy scenarios, a BSC6910 can take
over the faulty BSC6900, but a BSC6900 cannot take over the faulty BSC6910.
2. Resource Pool with BSC6910 Alone (one BSC6910+one BSC6910):

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 55


Copyright © Huawei
Technologies Co., Ltd.
4 Software Configuration Principles for RNC in Pool
RAN16.0 RNC in Pool Configuration Principles Features

In load sharing scenarios, two BSC6910s can work mutually as overflow and backup
RNC.

4.2 License Configuration Principles for Each


Physical RNC on an RNC in Pool Network
One BSC6900 has one and only one license file for both hardware and software
configurations. The license file can be configured only on the master RNC.
A BSC6910 has one and only one license file. If the BSC6910 works an overflow RNC, the
license file is the hardware license file and is applied using the hardware electronic serial
number (ESN). If the BSC6910 works a master RNC, the license file is the software license
file and is applied using the software electronic serial number (ESN).
The RNC in Pool features do not differentiate operators. Therefore, if a network is shared by
multiple operators, the preceding license control items are not exclusive to one operator.
However, these licenses, when being queried, are displayed on the equipment of the primary
operator.

Feature ID Feature Name Sales Unit Remarks


Name

WRFD-150211 RNC in Pool RNC per 500 Active


Load Sharing (BSC6900/BSC Users
6910)
WRFD-150212 RNC in Pool RNC per NodeB
Node (BSC6900/BSC
Redundancy 6910)
WRFD-150240 RNC in Pool RNC per Logical Supported only
Multiple (BSC6910) RNC on the
Logical RNCs BSC6910

1. WRFD-150211 RNC in Pool Load Sharing and WRFD-150212 RNC in Pool Node Redundancy can
be used together or separately.
2. WRFD-150240 RNC in Pool Multiple RNC cannot be used separately. It is used in combination
with the WRFD-150211 RNC in Pool Load Sharing or WRFD-150212 RNC in Pool Node
Redundancy features. The BSC6910 can work as a backup RNC or an overflow RNC to share the
signaling load on one BSC6910 or several BSC6900s. Besides, it can work as an independent logical
RNC to provide services for its NodeBs at the same time.
3. The sales unit for WRFD-150240 RNC in Pool Multiple Logical RNCs is per logical RNC. If one
BSC6910 functions as more than one logical RNC, for example, it functions as a logical RNC under
the control of the physical RNC and as a logical RNC for RNC in Pool Node Redundancy or RNC in
Pool Load Sharing, the license for WRFD-150240 RNC in Pool Multiple Logical RNCs is required.
The number of the license observes the following rule:
Number of the licenses for WRFD-150240 RNC in Pool Multiple Logical RNCs = Total RNCs
supported on the BSC6910 - 1.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 56


Copyright © Huawei
Technologies Co., Ltd.
4 Software Configuration Principles for RNC in Pool
RAN16.0 RNC in Pool Configuration Principles Features

4.3 Software and License Configurations for


RNC in Pool Load Sharing
If an RNC pool contains the BSC6900 and BSC6910, configuration scenarios of the RNC in
Pool features are described in Table 4-1.

Table 1.1 Configuration scenarios of the RNC in Pool features


Load Sharing WRFD-150211 WRFD-150212 WRFD-150240
(Expansion) RNC in Pool RNC in Pool RNC in Pool
Load Sharing Node Multiple
Redundancy Logical RNCs

Master BSC6900 Required


Master BSC6900 Required
Master BSC6900 Required
Overflow BSC6910 Determined
according to the
following criteria

The following criteria are used for determining whether an overflow BSC6910 is required:
An overflow BSC6910 is not required when the BSC6910 works only as an overflow RNC for a master
BSC6900.
An overflow BSC6910 is required when the BSC6910 works as an overflow RNC for two or more
BSC6900s or when the BSC6910 works as an overflow RNC and provides services for its NodeBs.

If an RNC pool contains the BSC6910 alone, configuration scenarios of the RNC in Pool
features (the BSC6910 works as a master or overflow RNC) are described in Table 4-2.

Table 1.2 Configuration scenarios of the RNC in Pool features (the BSC6910 works as master or
overflow RNC)
Load Sharing WRFD-150211 WRFD-150212 WRFD-150240
(Expansion) RNC in Pool RNC in Pool RNC in Pool
Load Sharing Node Multiple
Redundancy Logical RNCs

Master BSC6910 Required


Overflow BSC6910 Determined
according to the
following criteria

The following criteria are used for determining whether an overflow BSC6910 is required in this
configuration scenario:
An overflow BSC6910 is not required when the BSC6910 works only as an overflow RNC for a master
BSC6910.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 57


Copyright © Huawei
Technologies Co., Ltd.
4 Software Configuration Principles for RNC in Pool
RAN16.0 RNC in Pool Configuration Principles Features

An overflow BSC6910 is required when the BSC6910 works as an overflow RNC and provides services
for its NodeBs.

If an RNC pool contains the BSC6910 alone, configuration scenarios of the RNC in Pool
features (the BSC6910 works as both the master and overflow RNC) are described in Table 4-
3.

Table 1.3 Configuration scenarios of the RNC in Pool features (the BSC6910 works as both the
master and overflow RNC)
Load Sharing WRFD-150211 WRFD-150212 WRFD-150240
(Expansion) RNC in Pool RNC in Pool RNC in Pool
Load Sharing Node Multiple
Redundancy Logical RNCs

Master and overflow Required Required


BSC6910s
Master and overflow Required Required
BSC6910s

4.4 Software and License Configurations for


RNC in Pool Node Redundancy
If an RNC pool contains the BSC6900 and BSC6910, configuration scenarios of the RNC in
Pool features are described in Table 4-4.

Table 1.1 Configuration scenarios of the RNC in Pool features


Node WRFD-150211 WRFD-150212 WRFD-150240
Redundancy RNC in Pool RNC in Pool RNC in Pool
Load Sharing Node Multiple
Redundancy Logical RNCs

Master BSC6900 Required


Master BSC6900 Required
Master BSC6900 Required
Backup BSC6910 Determined
according to the
following criteria

The following criteria are used for determining whether a backup BSC6910 is required:
A backup BSC6910 is not required when the BSC6910 works only as a backup RNC for a master
BSC6900 and does not provide any services.
An overflow BSC6910 is required when the BSC6910 works as a backup RNC for two or more
BSC6900s or when the BSC6910 works as a backup RNC and provides services for its NodeBs.

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 58


Copyright © Huawei
Technologies Co., Ltd.
4 Software Configuration Principles for RNC in Pool
RAN16.0 RNC in Pool Configuration Principles Features

If an RNC pool contains the BSC6910 alone, configuration scenarios of the RNC in Pool
features (the BSC6910 works as a master or backup RNC) are described in Table 4-5.

Table 1.2 Configuration scenarios of the RNC in Pool features (the BSC6910 works as master or
overflow RNC)
Node WRFD-150211 WRFD-150212 WRFD-150240
Redundancy RNC in Pool RNC in Pool RNC in Pool
Load Sharing Node Multiple
Redundancy Logical RNCs

Master BSC6910 Required


Backup BSC6910 Determined
according to the
following criteria

The following criteria are used for determining whether a backup BSC6910 is required in this scenario:
A backup BSC6910 is not required when the BSC6910 works only as a backup RNC for a master
BSC6910 and does not provide any services.
An overflow BSC6910 is required when the BSC6910 works as a backup RNC and provides services for
its NodeBs.

If an RNC pool contains the BSC6910 alone, configuration scenarios of the RNC in Pool
features (the BSC6910 works as both the master and overflow RNC) are described in Table 4-
6.

Table 1.3 Configuration scenarios of the RNC in Pool features (the BSC6910 works as both the
master and overflow RNC)
Node WRFD-150211 WRFD-150212 WRFD-150240
Redundancy RNC in Pool RNC in Pool RNC in Pool
Load Sharing Node Multiple
Redundancy Logical RNCs

Master and backup Required Required


BSC6910s
Master and backup Required Required
BSC6910s

Issue 02 (2014-09-15) Huawei Proprietary and Confidential 59


Copyright © Huawei
Technologies Co., Ltd.

You might also like