DBS3900 LTE FDD Configuration Principles
DBS3900 LTE FDD Configuration Principles
0 RNC in Pool
Configuration Principles
Issue 02
Date 2014-09-15
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.
Website: http://www.huawei.com
Email: [email protected]
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
Figures
Figure 2-6 Resource pool overlapping in one BSC6910 that supports a maximum of 4 logical RNCs(RAN16.0)
...............................................................................................................................................................................13
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-5 RNC role in a resource pool and the corresponding dimensions..........................................................25
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-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
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-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
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.
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.
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.
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.
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
+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.
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
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:
Table 1.1 RNC in Pool networking scenarios supported in RAN15.0 and RAN16.0
Scenario RAN15.0 RAN16.0
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.
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 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.
Figure 1.4 Resource pool overlapping in one BSC6910 that supports a maximum of 4 logical
RNCs(RAN16.0)
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
BSC6910 can form two resource pools simultaneously. For details, see section 2.4
"Constraints on RNC in Pool Networking Scenarios."
for the overflow RNC. Only the Iur-p and O&M interfaces need to be configured for the
overflow RNC.
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.
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
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
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.
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
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
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)
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.
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)
300Mbps/165Mbps Evolved
license Network
Network Intelligence
Intelligence Throughput
Throughput License(50Mbps
License(50Mbps) )
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
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
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)]
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 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
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
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 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
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)
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
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.
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.
>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.
Table 1.2 Input parameters when a BSC6910 serves as the master RNC
Input Value Description
Parameter
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
Table 1.4 Output parameters related to capacity transferred to the overflow RNC(for Load
Sharing)
Output Parameter Calculation Method
Table 1.5 Output parameters related to hardware and hardware licenses when a BSC6910 serves
as the master RNC
Output Parameter Calculation Method
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.)
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
Information provided in the preceding table is the same as that for BSC6900s.
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
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
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,
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.
NewInteTpt_hw_license)]
4 Software Configuration
Principles for RNC in Pool Features
In load sharing scenarios, two BSC6910s can work mutually as overflow and backup
RNC.
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.
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
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.
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
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.
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
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