10 UMTS RNC in Pool Solution Guide (RAN18.1 01)

WCDMA RAN
UMTS RNC in Pool Solution Guide
Issue 01
Date 2016-02-29
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2016. 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: support@huawei.com
Issue 01 (2016-02-29) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
WCDMA RAN
UMTS RNC in Pool Solution Guide Contents
Contents
1 About This Document.................................................................................................................. 1

1.1 Overview........................................................................................................................................................................ 1
1.2 Intended Audience.......................................................................................................................................................... 1
1.3 Change History............................................................................................................................................................... 1
2 Solution Overview........................................................................................................................ 2
2.1 Background.....................................................................................................................................................................2
2.2 Application Scenarios.....................................................................................................................................................4
2.3 Overall Solution..............................................................................................................................................................5
3 Solution Application Guidelines............................................................................................... 7

3.1 Scenario 1: Signaling Capacity Expansion, Load Decrease, or Burst Traffic Handling................................................ 7
3.1.1 Scenario Description....................................................................................................................................................7
3.1.2 Solution Purpose..........................................................................................................................................................7
3.1.3 Solution Description.................................................................................................................................................... 8
3.1.4 Implementation............................................................................................................................................................ 9
3.2 Scenario 2: RNC Node Redundancy and Hitless Upgrade...........................................................................................10
3.2.1 Scenario Description..................................................................................................................................................10
3.2.2 Solution Purpose........................................................................................................................................................10
3.2.3 Solution Description.................................................................................................................................................. 10
3.2.4 Implementation.......................................................................................................................................................... 13
4 List of Features Involved in the Solution............................................................................... 15

5 Acronyms and Abbreviations................................................................................................... 16
6 Reference Documents................................................................................................................. 17
Issue 01 (2016-02-29) Huawei Proprietary and Confidential ii

WCDMA RAN
UMTS RNC in Pool Solution Guide 1 About This Document
1 About This Document
1.1 Overview
This document describes the RNC in Pool solution for different application scenarios.
It helps customers choose one or more features to better suit network deployment
requirements. The technical principles, deployment, and maintenance of each feature are
beyond the scope of this document. For details, see the corresponding feature parameter
description.
1.2 Intended Audience

This document is intended for personnel who:
l Need to understand the RNC in Pool solution

l Work with Huawei products
1.3 Change History

This section provides information about the changes in different document versions.
RAN18.1 01 (2016-02-29)
This issue does not include any changes.
RAN18.1 Draft A (2015-12-30)

Compared with Issue 01 (2015-04-20) of RAN17.1, Draft A (2015-12-30) of RAN18.1
includes the following changes.
l Added descriptions of automatic NodeB control switchover to 3.2.4 Implementation.

l Modified node redundancy specifications. For details. see 3.2.3 Solution Description.
Issue 01 (2016-02-29) Huawei Proprietary and Confidential 1

WCDMA RAN
UMTS RNC in Pool Solution Guide 2 Solution Overview
2 Solution Overview
2.1 Background
The rapid development of mobile networks brings not only rapid business growth but also
unprecedented challenges for operators.
The smartphone penetration rate is increasing rapidly. As shown in Figure 2-1, from July
2011 to May 2013, the smartphone penetration rate increased by eight times. This increase
required operators to expand network capacity, especially signaling processing capabilities.
Operators have urgent requirements for sustainable RNC equipment expansion. Conventional
RNC splitting cannot meet operators' requirements and more effective capacity expansion
measures are required.
Figure 2-1 Smartphone penetration rate
Mobile network services are interrupted in a large scale if an operator's equipment room
encounters disasters such as floods and earthquakes, which may cause equipment to power
off. The RNC is a service convergence node of the UMTS network and has high reliability
requirements. Service disruptions caused by RNC failures have severe impacts.
To meet the preceding requirements, Huawei has developed the RNC in Pool solution. This
solution enables interconnected RNCs to form a resource pool and provides the following
benefits:

WCDMA RAN
l Breaks the hardware specification limitations of a single RNC

l Allows smooth RNC capacity expansion
l Supports remote backup
l Improves RNC reliability
Traditional RNC Capacity Expansion

In the traditional RNC capacity expansion method, expansion is achieved by adding boards,
subracks, or cabinets. However, the maximum number of subracks and cabinets are six and
two, respectively. When this limit is reached, RNC splitting is performed. Then, some base
stations under the original RNC are reparented to a new RNC, thereby reducing the load of
the original RNC.
RNC splitting involves the following operations:

1. Purchasing a new set of RNC hardware and hardware licenses.
2. Purchasing a set of software license packages for the new RNC, including all the
required software features.
3. Planning a new set of RNC configuration parameters for the Iu, Iur, and Iub interfaces.
In addition to configuring interface parameters on the new RNC, you need to configure
related interface parameters on the CN and other network elements (NEs), such as the
neighboring RNCs, GSM BSCs, and LTE eNodeBs.
4. For base stations that have been reparented to the new RNC, you need to update the
neighbor relationships of cells under the old and new RNCs as well as the neighbor
relationships of cells under the neighboring RNCs, GSM BSCs, and LTE eNodeBs.
5. Reparenting base stations in batches during off-peak hours. You need to observe network
KPIs and ensure integrity of configurations.
Steps 3, 4, and 5 involve network planning and implementation. Any error or omission in
planning and implementation may deteriorate network KPIs. Data configurations and base
station reparenting for RNC splitting are complicated and therefore need to be optimized.
RNC Capacity Expansion Using RNC in Pool

RNC capacity expansion using RNC in Pool involves the following operations:
1. Purchasing a new set of RNC hardware and hardware licenses.
2. Purchasing a license for the RNC in Pool Load Sharing feature. You may also need to
purchase a license for the RNC in Pool Multiple Logical RNCs feature.

WCDMA RAN
3. Planning the Iur-p interface parameters. Compared with the Iu interface parameter
configuration, the Iur-p interface parameter configuration is simpler. Activate the RNC
in Pool Load Sharing feature during off-peak hours.
When RNC capacity expansion is performed using the RNC in Pool feature, the following
operations do not need to be performed:
l Reparenting base stations

l Planning a set of configuration parameters for the Iu, Iur, and Iub interfaces of the new
RNC
l Planning neighbor relationship changes
l Modifying interface and neighbor relationship configurations of the CN, neighboring
RNCs, GSM BSCs, and LTE eNodeBs
Operation and maintenance costs are greatly reduced since the preceding operations are not
required. RNC capacity expansion using the RNC in Pool feature enables smooth RNC
capacity expansion and postpones or even avoids RNC splitting.
2.2 Application Scenarios

Signaling Capacity Expansion, Load Decrease, or Burst Traffic Handling
For a BSC6900 in an inventory network, if the maximum hardware specifications of two
cabinets and six subracks are reached but the signaling processing capability cannot meet the
requirements, the RNC in Pool Load Sharing feature can be used for capacity expansion. If
this feature is used, RNC splitting is not required and the complex operations and high
maintenance costs related to RNC splitting can be avoided.
If the average SPU load of an RNC is greater than 45%, the operator can implement load
sharing among multiple BSC6900s and one BSC6910 to improve network reliability and
prevent the impact of burst signaling or data traffic on the RNC. The load sharing solution
prevents KPI deterioration caused by a continuous increase in CPU load and improves
hardware usage.
RNC Node Redundancy and Hitless Upgrade

The RNC in Pool Node Redundancy feature is applicable in the following scenarios: The
operator has high RNC reliability requirements. The government has high reliability
requirements for the operator's services (for example, the service interruption duration cannot
exceed 30 minutes). The operator requires that the RNC provide redundancy in the event of
system failures, such as power failure, transmission interruptions, or device failures. If there
are multiple BSC6900s in an existing network, it is recommended that node redundancy be
implemented among multiple BSC6900s and one BSC6910. In this case, the BSC6910 is used
as the backup RNC for multiple BSC6900s.
Currently, an RNC upgrade may interrupt services provided by the RNC for several minutes.
During the upgrade, idle UEs are out of service and online users experience call drops. If an
operator requires a smooth RNC upgrade and wants to prevent upgrade impacts, the RNC in
Pool Node Redundancy feature can be used. The feature ensures that idle UEs are not out of
service during the upgrade and limits any interruption of services experienced by online users
to less than 20s. If the RNC in Pool Node Redundancy feature is enabled before the RNC
upgrade, services are switched over to the backup RNC and therefore not affected during the

WCDMA RAN
upgrade. After the upgrade, services are switched back to the master RNC. This process is
called hitless upgrade.
NOTE
The RNC in Pool Load Sharing and RNC in Pool Node Redundancy features can be used together if the
preceding two scenarios co-exist.
2.3 Overall Solution

With the RNC in Pool feature, interconnected RNCs form a resource pool over the private
interface Iur-p (Iur-pool), a Huawei-proprietary interface. Figure 2-2 shows the network
architecture for RNC in Pool.
Figure 2-2 Network architecture for RNC in Pool
RNC in Pool consists of the following three optional features:

l WRFD-150211 RNC in Pool Load Sharing (control plane and user plane)
l WRFD-150212 RNC in Pool Node Redundancy
l WRFD-150240 RNC in Pool Multiple Logical RNCs
3GPP has defined the MSC/SGSN Pool networking function, which provides load sharing
and node redundancy for the CN nodes. The differences between MSC/SGSN Pool and RNC
in Pool are as follows:
1. MSC Pool is defined by 3GPP, whereas RNC in Pool is a Huawei-proprietary function.
2. For MSC Pool, the NAS node selection function (NNSF) is performed by lower-layer
NEs (RNC or MGW). For RNC in Pool, the RNC node selection function is performed

WCDMA RAN
through the communication between RNCs in the pool (through Iur-p interface
communication).
Figure 2-3 Differences between MSC Pool and RNC in Pool

WCDMA RAN
UMTS RNC in Pool Solution Guide 3 Solution Application Guidelines
3 Solution Application Guidelines
3.1 Scenario 1: Signaling Capacity Expansion, Load

Decrease, or Burst Traffic Handling
3.1.1 Scenario Description

An operator has deployed BSC6900s/BSC6910s in UO mode in the network. The average
CPU load of an RNC exceeds 45% during busy hours. In addition to adding boards to the
RNC for capacity expansion, the operator expects to expand the CP and UP capacity so as to
reduce the average load of SPU and DPU boards. Alternatively, the operator expects to solve
the insufficient SPU/DPU/GPU board capacity problem caused by burst traffic. The planned
busy hour call attempts (BHCA) and data throughput to be expanded do not exceed 90% of
the original BSC6900/BSC6910 specifications.
3.1.2 Solution Purpose

The RNC in Pool solution reduces the average CPU load (SPU and DPU load) of existing
BSC6900s, prevents service interruptions caused by burst traffic, and eliminates the need to
perform complex O&M operations after RNC splitting is performed. This solution enables
smooth capacity expansion.
With the RNC in Pool solution, next-generation large-capacity BSC6910s can be used for
network expansion.
In addition, load sharing can be implemented between two BSC6910s to handle burst traffic.

WCDMA RAN
3.1.3 Solution Description

List of Features Involved in the Solution
Table 3-1 List of features involved in the solution

Feature ID Feature Name Introduced In... Reference
Document
WRFD-150211 RNC in Pool Load Control plane load RNC in Pool Feature
Sharing sharing is introduced in Parameter
RAN15.0, and user Description
plane load sharing is
introduced in RAN16.0.
WRFD-150240 WRFD-150240 RAN15.0 RNC in Pool Feature

RNC in Pool Parameter
Multiple Logical Description
RNCs
Description of Features Involved in the Solution

l WRFD-150211 RNC in Pool Load Sharing
The RNC in Pool Load Sharing feature enables the BSC6910 to share load with other
BSC6900s or BSC6910s in the same pool. Load sharing decisions are made during the
RRC connection setup of each user.
NOTE
Load sharing has no impact on other NEs except RNCs in the pool.
Figure 3-1 Load sharing provided by a BSC6910 for a BSC6900

WCDMA RAN
Figure 3-2 Load sharing between BSC6910s

When the WRFD-150240 RNC in Pool Multiple Logical RNCs feature is used together
with the RNC in Pool Load Sharing feature, a BSC6910 can carry multiple logical RNCs
(up to 7, one of which is the logical RNC of the BSC6910 itself) and share load with
multiple BSC6900s (n ≤ 6) or BSC6910s (n ≤ 3). Figure 3-3 and Figure 3-4 assume that
the value of n is 3. The BSC6900 does not support the WRFD-150240 RNC in Pool
Multiple Logical RNCs feature.
Figure 3-3 BSC6910 carrying multiple logical RNCs and sharing load with multiple
BSC6900s (n + 1, n = 3)
Figure 3-4 BSC6910 carrying multiple logical RNCs and sharing load with multiple
BSC6910s (n + 1, n = 3)
3.1.4 Implementation
The RNC in Pool Load Sharing feature does not affect other NEs except RNCs in the pool.
The CME automatically synchronizes the parameter settings of the logical RNCs in a pool

WCDMA RAN
from the master RNC (BSC6900 or BSC6910) to the overflow RNC (BSC6910). You do not
need to manually synchronize parameter settings on the two RNCs.
The signaling of a UE whose load is shared between RNCs is transmitted over the Iur-p
interface. Therefore, transmission delay and QoS over the Iur-p interface must meet the
specified requirements. Otherwise, call signaling processing causes call loss. For this sake, it
is recommended that RNCs in the same equipment room form a pool for load sharing.
For details about transmission requirements and feature deployment, see RNC in Pool Feature
Parameter Description.
The RNC in Pool Load Sharing feature does not provide load sharing for cell signaling
processing capabilities. If the cell signaling processing load of some CPU subsystems in a
BSC6900 is high, the CPU load may not decrease after the RNC in Pool Load Sharing feature
is enabled. Base stations and cells must be adjusted among the CPU subsystems of the RNC
to balance the cell signaling processing load.
The RNC in Pool Load Sharing feature is used to reduce and balance the average CPU load of
RNCs. It cannot be used to balance the load between the subracks, boards, and CPU
subsystems within an RNC.
3.2 Scenario 2: RNC Node Redundancy and Hitless

Upgrade
3.2.1 Scenario Description

The operator has a high requirement for RNC reliability and requires shorter service
interruption durations to achieve fast recovery of RNC services in the event of disasters or
software/hardware failures.
To use the RNC in Pool Node Redundancy feature, you must add dual-homed Iub links for
base stations. It is recommended that this feature be enabled when IP transmission is used on
the Iub interface.
3.2.2 Solution Purpose

The RNC in Pool solution improves RNC reliability.
3.2.3 Solution Description

The RNC in Pool solution uses next-generation large-capacity BSC6910s to improve the
reliability of both existing and newly deployed networks. In addition, this solution shortens
the service interruption duration of RNC software upgrade, achieving hitless upgrade.

WCDMA RAN
List of Features Involved in the Solution
Table 3-2 List of features involved in the solution

Feature ID Feature Name Introduce Reference Document
d In...
WRFD-150212 RNC in Pool Node RAN15.0 RNC in Pool Feature Parameter

Redundancy Description
WRFD-150240 WRFD-150240 RAN15.0 RNC in Pool Feature Parameter

RNC in Pool Description
Multiple Logical
RNCs
Description of Features Involved in the Solution

l WRFD-150212 RNC in Pool Node Redundancy
The RNC in Pool Node Redundancy feature enables a BSC6910 to provide node
redundancy for other BSC6900s or BSC6910s.
NOTE
The RNC in Pool Node Redundancy feature does not have any impact on the neighboring cells of
neighboring NEs. After services on the backup RNC are recovered, the RNC ID and neighbor
relationships remain unchanged. The backup Iu/Iur/Iub links must be configured on the backup
RNC. Related interface data must be configured on the CN and neighboring RNC.
Figure 3-5 Node redundancy provided by a BSC6910 for a BSC6900

WCDMA RAN
Figure 3-6 Node redundancy between BSC6910s

When the WRFD-150240 RNC in Pool Multiple Logical RNCs feature is used together
with the RNC in Pool Node Redundancy feature, a BSC6910 can carry multiple logical
RNCs (up to 7, one of which is the logical RNC of the BSC6910 itself) and provide node
redundancy for multiple BSC6900s (n ≤ 6) or BSC6910s (n ≤ 6). Figure 3-7 and Figure
3-8 assume that the value of n is 3. The BSC6900 does not support the WRFD-150240
RNC in Pool Multiple Logical RNCs feature.
Figure 3-7 BSC6910 carrying multiple logical RNCs and providing node redundancy for
multiple BSC6900s (n + 1, n = 3)

WCDMA RAN
Figure 3-8 BSC6910 carrying multiple logical RNCs and providing node redundancy for
multiple BSC6910s (n + 1, n = 3)
For a GU dual-mode BSC, the 2G and 3G controller function can be simultaneously

backed up or switched over in either of the following scenarios: one BSC6900 (master
RNC)+one BSC6910 (backup RNC), and one BSC6910+one BSC6910 (the two
BSC6910s provide node redundancy for each other). GU dual-mode BSCs do not
support simultaneous 2G and 3G backup and switchover in other scenarios.
3.2.4 Implementation
The CME automatically synchronizes the parameter settings of the logical RNCs in a pool
from the master RNC (BSC6900 or BSC6910) to the backup RNC (BSC6910). You do not
need to manually synchronize parameter settings on the two RNCs.
After the master RNC becomes faulty and services are resumed on the backup RNC, logical
RNC parameter modification on the backup RNC cannot be automatically synchronized to the
master RNC. Therefore, you need to record the modification and manually change the logical
RNC parameters on the master RNC after the master RNC recovers. This ensures that the
same parameter modifications are made on the master RNC.
The node redundancy solution should be planned based on the actual networking scenarios.
Generally, it is recommended that the master RNC and backup RNC be located in different
places (remote disaster recovery) to avoid simultaneous master and backup RNC failures.
If the RNC switchover mode is set to manual mode, the maintenance personnel need to
observe whether an RNC is faulty based on device alarms and then determine whether to
trigger an RNC switchover. An RNC switchover will lead to call drops of all online users.
Therefore, exercise caution when performing this operation.
If the RNC switchover mode is set to automatic mode, the system automatically detects
whether an RNC is faulty and triggers an RNC switchover. In addition, the system can check
the status of the Iu interface according to data configurations. If the Iu interface status is
abnormal, the system triggers an RNC switchover.
For details about feature deployment, see RNC in Pool Feature Parameter Description.
In the case of hitless upgrade, switch services of the master RNC to the backup RNC before
upgrading the master RNC. After the upgrade is complete, switch services back to the master
RNC. In this way, two RNC switchovers are performed.

WCDMA RAN
If the operator has high reliability requirements for RNCs, multiple RNCs among N+1 RNCs
may require node redundancy. In this case, the sum of the capacity of N RNCs must be
planned on the backup RNC.
When upgrading the R version of the RNCs in a pool, you do not need to upgrade all RNCs in
a day, but you need to disable the automatic synchronization function. During the period when
the RNCs in a pool have different R versions, you need to manually synchronize parameter
updates between the master and backup RNCs.

WCDMA RAN
UMTS RNC in Pool Solution Guide 4 List of Features Involved in the Solution
4 List of Features Involved in the Solution
Feature ID Feature Name Introduced In... Reference

Document
WRFD-150211 RNC in Pool Load Control plane load RNC in Pool Feature
Sharing sharing is introduced in Parameter
RAN15.0. Description
User plane load sharing
is introduced in
RAN16.0.
WRFD-150212 RNC in Pool Node RAN15.0 RNC in Pool Feature

Redundancy Parameter
Description
WRFD-150240 WRFD-150240 RAN15.0 RNC in Pool Feature

RNC in Pool Parameter
Multiple Logical Description
RNCs

WCDMA RAN
UMTS RNC in Pool Solution Guide 5 Acronyms and Abbreviations
5 Acronyms and Abbreviations
Acronym and Full Name

Abbreviation
CP Control Plane
Iur-p Iur interface for Pool
UP User Plane

WCDMA RAN
UMTS RNC in Pool Solution Guide 6 Reference Documents
6 Reference Documents
1. RNC in Pool Feature Parameter Description


10 UMTS RNC in Pool Solution Guide (RAN18.1 01)

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

10 UMTS RNC in Pool Solution Guide (RAN18.1 01)

Caricato da

Copyright:

Formati disponibili

WCDMA RAN

UMTS RNC in Pool Solution Guide

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2016-02-29) Huawei Proprietary and Confidential i

1 About This Document.................................................................................................................. 1

3 Solution Application Guidelines............................................................................................... 7

4 List of Features Involved in the Solution............................................................................... 15

Issue 01 (2016-02-29) Huawei Proprietary and Confidential ii

1 About This Document

1.2 Intended Audience

l Need to understand the RNC in Pool solution

1.3 Change History

RAN18.1 Draft A (2015-12-30)

l Added descriptions of automatic NodeB control switchover to 3.2.4 Implementation.

Issue 01 (2016-02-29) Huawei Proprietary and Confidential 1

Figure 2-1 Smartphone penetration rate

Issue 01 (2016-02-29) Huawei Proprietary and Confidential 2

l Breaks the hardware specification limitations of a single RNC

Traditional RNC Capacity Expansion

RNC splitting involves the following operations:

RNC Capacity Expansion Using RNC in Pool

Issue 01 (2016-02-29) Huawei Proprietary and Confidential 3

l Reparenting base stations

2.2 Application Scenarios

RNC Node Redundancy and Hitless Upgrade

Issue 01 (2016-02-29) Huawei Proprietary and Confidential 4

2.3 Overall Solution

Figure 2-2 Network architecture for RNC in Pool

RNC in Pool consists of the following three optional features:

Issue 01 (2016-02-29) Huawei Proprietary and Confidential 5

Figure 2-3 Differences between MSC Pool and RNC in Pool

Issue 01 (2016-02-29) Huawei Proprietary and Confidential 6

3 Solution Application Guidelines

3.1 Scenario 1: Signaling Capacity Expansion, Load

3.1.1 Scenario Description

3.1.2 Solution Purpose

Issue 01 (2016-02-29) Huawei Proprietary and Confidential 7

3.1.3 Solution Description

Table 3-1 List of features involved in the solution

WRFD-150240 WRFD-150240 RAN15.0 RNC in Pool Feature

Description of Features Involved in the Solution

Figure 3-1 Load sharing provided by a BSC6910 for a BSC6900

Issue 01 (2016-02-29) Huawei Proprietary and Confidential 8

Figure 3-2 Load sharing between BSC6910s

l WRFD-150240 RNC in Pool Multiple Logical RNCs

Issue 01 (2016-02-29) Huawei Proprietary and Confidential 9

3.2 Scenario 2: RNC Node Redundancy and Hitless

3.2.1 Scenario Description

3.2.2 Solution Purpose

3.2.3 Solution Description

Issue 01 (2016-02-29) Huawei Proprietary and Confidential 10

List of Features Involved in the Solution

Table 3-2 List of features involved in the solution

WRFD-150212 RNC in Pool Node RAN15.0 RNC in Pool Feature Parameter

WRFD-150240 WRFD-150240 RAN15.0 RNC in Pool Feature Parameter

Description of Features Involved in the Solution

Figure 3-5 Node redundancy provided by a BSC6910 for a BSC6900

Issue 01 (2016-02-29) Huawei Proprietary and Confidential 11

Figure 3-6 Node redundancy between BSC6910s

l WRFD-150240 RNC in Pool Multiple Logical RNCs

Issue 01 (2016-02-29) Huawei Proprietary and Confidential 12