RNC Node Redundancy (RAN15.0 - 01)

WCDMA RAN
RNC Node Redundancy Feature

Parameter Description
Issue 01
Date 2013-04-28
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: support@huawei.com
Issue 01 (2013-04-28) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
WCDMA RAN
RNC Node Redundancy Feature Parameter Description Contents
Contents
1 About This Document..................................................................................................................1

1.1 Scope..............................................................................................................................................................................1
1.2 Intended Audience..........................................................................................................................................................1
1.3 Change History...............................................................................................................................................................1
1.4 Differences Between Base Station Types.......................................................................................................................2
2 Overview of RNC Node Redundancy.......................................................................................3

3 Technical Description...................................................................................................................5
3.1 Basic Principles..............................................................................................................................................................5
3.1.1 RNC Pool.....................................................................................................................................................................5
3.1.2 NodeB Control Rights in the RNC Pool......................................................................................................................6
3.1.3 Constraints of RNC Node Redundancy.......................................................................................................................6
3.2 Heartbeat Detection Between the Primary and Secondary RNCs..................................................................................7
3.3 Taking Over the NodeB Control Rights.......................................................................................................................12
3.4 Re-Homing of NodeB Control Rights..........................................................................................................................13
3.5 Forced Homing of NodeB Control Rights....................................................................................................................13
3.6 Requirements of RNC Node Redundancy on Transmission........................................................................................13
4 Feature Deployment....................................................................................................................15
4.1 Prerequisites..................................................................................................................................................................16
4.2 Procedure......................................................................................................................................................................16
4.2.1 Activation Procedure.................................................................................................................................................16
4.2.2 Verification Procedure...............................................................................................................................................18
4.2.3 Deactivation Procedure..............................................................................................................................................20
4.2.4 Example.....................................................................................................................................................................20
5 Parameters.....................................................................................................................................22
6 Counters........................................................................................................................................29
7 Glossary.........................................................................................................................................31
8 Reference Documents.................................................................................................................32
Issue 01 (2013-04-28) Huawei Proprietary and Confidential ii

WCDMA RAN
RNC Node Redundancy Feature Parameter Description 1 About This Document
1 About This Document
1.1 Scope
This document describes WRFD-040202 RNC Node Redundancy, including its technical
principles, related features, network impact, and engineering guidelines. The BSC6910 does not
support this feature.
1.2 Intended Audience

This document is intended for personnel who:
l Need to understand the features described herein

l Work with Huawei products
1.3 Change History

This section provides information about the changes in different document versions. There are
two types of changes, which are defined as follows:
l Feature change
Changes in features of a specific product version
l Editorial change
Changes in wording or addition of information that was not described in the earlier version
RAN15.0 01 (2013-04-28)
This issue does not include any changes.
RAN15.0 Draft A (2013-01-30)

Compared with Issue 03 (2012-11-30) of RAN14.0, Draft A (2013-01-30) of RAN15.0
optimizes some descriptions.
Issue 01 (2013-04-28) Huawei Proprietary and Confidential 1

WCDMA RAN
RNC Node Redundancy Feature Parameter Description 1 About This Document
1.4 Differences Between Base Station Types

This document applies to the following types of base stations.
Base Station Model
Macro l 3900 series base stations

l DBS3800
l BTS3812E
l BTS3812AE
Micro l BTS3803E
l BTS3902E
LampSite DBS3900
The features described in this document are implemented in the same way on macro, micro, and
LampSite base stations.

WCDMA RAN
RNC Node Redundancy Feature Parameter Description 2 Overview of RNC Node Redundancy
2 Overview of RNC Node Redundancy
In a traditional WCDMA RAN, one NodeB is connected to only one RNC. The RNC controls
the radio access services of all the UEs in the RNS coverage area. To achieve high reliability,
the RNC uses many redundancy technologies, such as control-board backup, resource pool setup
for data processing boards, interface-board backup, and transmission redundancy. The RNC,
however, may break down in a disaster such as fire, water damage, explosion, or earthquake. In
this case, the RNS cannot provide radio access service in the coverage area.
Recent technological improvements allow the RNC to provide increasingly higher capacity to
meet the rapid growth of mobile services. The RNC is the control center of the RNS. Therefore,
RNC reliability is a great concern because a failure in the RNC affects the security of the whole
RNS. To increase reliability, Huawei provides an RNC node redundancy solution. If one RNC
fails, another RNC automatically takes over all the dual-homed NodeBs under the failed RNC.
RNC node redundancy uses 1+1 backup mode. Figure 2-1 shows the basic principles of 1+1
backup mode.

WCDMA RAN
RNC Node Redundancy Feature Parameter Description 2 Overview of RNC Node Redundancy
Figure 2-1 RNC-supported 1+1 backup mode
As shown in Figure 2-1, each NodeB is configured with two transmission links pointed towards
two RNCs - the primary RNC and the secondary RNC. All the data related to NodeBs, cells,
and their neighboring cells is configured on both the RNCs. Under normal conditions, the
primary RNC serves as the controlling RNC (CRNC) of the NodeB. When the primary RNC
fails, the NodeB tries to connect to the secondary RNC to resume work.
Assume that RNC1 and RNC2 are grouped into an RNC pool. RNC1 is installed in area A, where
earthquakes occur frequently, and RNC2 is installed in area B, where earthquakes rarely occur.
If RNC1 serves as the primary RNC of the NodeBs and fails when an earthquake occurs in area
A, RNC2 automatically takes over the NodeB control rights, and the NodeBs resume work.
In the RNC node redundancy solution, the two RNCs do not work in active/standby mode. In
normal situations, both RNCs are in service and therefore the equipment can be fully utilized.
When one of the RNCs fails, the other automatically takes over all the dual-homed NodeBs to
protect the NodeBs from being out of service.

WCDMA RAN
RNC Node Redundancy Feature Parameter Description 3 Technical Description
3 Technical Description
3.1 Basic Principles
3.1.1 RNC Pool

During the configuration of RNC node redundancy, the primary RNC and the secondary RNC
need to be added to an RNC pool. The RNC pool supports only the 1+1 backup mode. That is,
the RNC pool contains only two RNCs, as shown in Figure 3-1.
Figure 3-1 RNC pool
The RNCs in the RNC pool detect each other's status by using the heartbeat detection mechanism.
When the secondary RNC finds that the primary RNC has failed, it takes over the NodeB control
rights automatically. Therefore, the RNCs in the RNC pool must be configured with a direct

WCDMA RAN
route over the Iur interface and alternative routes over the Iu interfaces. These two methods
guarantee the transmission of heartbeat signals between the RNCs.
The alternative routes over the Iu interfaces must cover all the CN domains that the two RNCs
connect to. Assume that RNC1 uses the Iu-Flex function. Then, alternative routes must be
configured at the RNC2 for every CN domain that RNC1 connects to, and RNC1 can send
heartbeat signals through any CN domain.
The RNC pool needs to be configured on both the primary and secondary RNC. The RNC node
redundancy function can be used when the RNC pool is activated on both RNCs and the
parameter SupAutoRehoming(BSC6900,BSC6910) is set to ON.
NOTE
When NodeB control rights are switched due to heartbeat loss, the license for urgency will be activated.
The license for urgency can be enabled only fifteen times for each R version for this kind of reason. For
detail information about the license for urgency, see the document License Management Feature Parameter
Description.
3.1.2 NodeB Control Rights in the RNC Pool

In the RNC node redundancy scheme, the NodeBs need to be configured on both the primary
and secondary RNCs. Only one RNC, however, has NodeB control rights.
The RNC with NodeB control rights manages the NodeB resources. When both the RNCs work
properly, the secondary RNC does not maintain logical resources such as cells. Instead, it only
establishes NCP and CCPs, and responds to basic NBAP messages through the NCP and CCPs
between the secondary RNC and each NodeB.
Under normal conditions, the primary RNC controls the NodeBs. The secondary RNC takes
over the NodeB control rights automatically to avoid service disruption and increase system
reliability in the following conditions:
l The primary RNC fails.

l The Iu interface is faulty according to the setting of the IuStatePolicyForPool
(BSC6900,BSC6910) parameter.
If the primary RNC recovers, it will take over the NodeB control rights automatically again
according to the re-homing policy, and the secondary RNC will release the NodeB control rights.
For details, see section 3.4 Re-Homing of NodeB Control Rights.
In addition, the NodeB can be forcibly switched to the secondary RNC by an MML command
according to the specific requirement. For details, see section 3.5 Forced Homing of NodeB
Control Rights.
NOTE
The primary and secondary RNCs of a NodeB are specified through the HostType(BSC6900,BSC6910)
parameter.
3.1.3 Constraints of RNC Node Redundancy

The constraints of RNC node redundancy are as follows:
l The secondary RNC takes over the NodeB control rights only when the primary RNC fails.
When the Iub interface of the primary RNC fails, the secondary RNC does not take over

WCDMA RAN
the NodeB control rights automatically, even if the Iub interface of the secondary RNC
works properly.
l The NodeBs are not switched to the secondary RNC even when the load of the primary
RNC (including the control plane and the user plane) is higher than that of the secondary
RNC.
l Call drops may occur if the failed RNC serves as the DRNC or TRNC in inter-RNC
handover, relocation, or inter-RAT handover.
l After the secondary RNC takes over the NodeB control rights, all the traffic counters and
alarms about the NodeBs are reported by the secondary RNC.
3.2 Heartbeat Detection Between the Primary and

Secondary RNCs
After the RNC node redundancy function is activated, the RNCs in the RNC pool send heartbeat
signals to each other at intervals specified by the BeatSendingDis(BSC6900,BSC6910)
parameter. Heartbeat signals can be sent to the peer RNC through a direct route over the Iur
interface or alternative routes over the Iu interface. The peer RNC regards the local RNC as
operational only if it can continuously receive heartbeat signals from the local RNC. Table
3-1 describes the heartbeat parameters used in RNC node redundancy.
Table 3-1 Heartbeat parameters used in RNC node redundancy
Parameter Identity Parameter Name Parameter Description
BeatSendingDis Heartbeat Sending Time This parameter specifies the

(BSC6900,BSC6910) Interval interval between heartbeat
signal transmissions from the
local RNC to the peer RNC.
It must be set to the same
value on the RNCs in the
RNC pool.
BeatDectThred Heartbeat Lost Times If the number of consecutive

(BSC6900,BSC6910) Threshold failures to receive heartbeat
signals from the peer RNC
reaches the value of this
parameter in the interval
specified by the
BeatSendingDis parameter,
the local RNC regards the
peer RNC as failed.

WCDMA RAN
BeatRecvrThred HeatBeat Recover Times If the number of consecutive

(BSC6900,BSC6910) Threshold successes in receiving
heartbeat signals from the
peer RNC reaches the value
of this parameter in the
interval specified by
BeatSendingDis, the local
RNC regards the peer RNC
as operational.

WCDMA RAN
IuStatePolicyForPool Iu State Policy For RncPool This parameter can be set to

(BSC6900,BSC6910) NONE, IUCS, IUPS, or
IUCS_IUPS, which are
described as follows:
l NONE: The status of the
RNC is unrelated to the
status of the Iu interface.
l IUCS: The status of the
RNC is related to the
status of the Iu-CS
interface. If no CS
domain is available, the
RNC is regarded as
unavailable for RNC node
redundancy. The RNC
stops sending heartbeat
signals to the peer RNC,
and releases the NodeB
control rights after
receiving the request for
the NodeB control rights
from the peer RNC. As
long as one CS domain is
available, the RNC
becomes available.
l IUPS: The status of the
RNC is related to the
status of the Iu-PS
interface. If no PS domain
is available, the RNC is
regarded as unavailable
for RNC node
redundancy. The RNC
long as one PS domain is
available, the RNC
becomes available.
l IUCS_IUPS: The status
of the RNC is related to
the status of both the Iu-
CS interface and the Iu-

WCDMA RAN
PS interface. If any one of

the CS or PS domains is
unavailable, the RNC is
regarded as unavailable
for RNC node
redundancy. The RNC
long as one CS or PS
domain is available, the
RNC becomes available.
The RNC stops sending heartbeat signals to the other RNC in the RNC pool in either of the
following cases:
l The RNC fails.

l The RNC determines that the Iu interface is faulty according to the setting of the
IuStatePolicyForPool(BSC6900,BSC6910) parameter.
As shown in Figure 3-2, if the number of consecutive failures to receive heartbeat signals from
RNC2 reaches the value of BeatDectThred(BSC6900,BSC6910), RNC1 regards the RNC2 as
failed. In this case, RNC1 takes over the NodeB control rights automatically.

WCDMA RAN
Figure 3-2 Peer RNC Failure Detection
As shown in Figure 3-3, if the number of consecutive successes in receiving heartbeat signals
from RNC2 reaches the value of BeatRecvrThred(BSC6900,BSC6910), RNC1 regards RNC2
as operational. In this case, RNC2 takes over the NodeB control rights automatically again
according to the policy specified by the ReHostPolicy(BSC6900,BSC6910) parameter, and
RNC1 releases the NodeB control rights.

WCDMA RAN
Figure 3-3 Detecting that the peer RNC becomes operational
3.3 Taking Over the NodeB Control Rights

Both the primary and secondary RNCs in an RNC pool configure the cells under the dual-homing
NodeBs and save the configuration information of those cells. The cells, however, are set up
and become available under only the primary RNC.
When the primary RNC fails, it removes the cells under the dual-homing NodeBs. After the
secondary RNC detects the failure of the primary RNC through heartbeat detection, it takes over
the NodeB control rights automatically from the primary RNC and sets up cells under the NodeBs
through an audit procedure. In this case, the cell configuration information saved under the
secondary RNC is used.
A delay occurs between the failure of the primary RNC and the setup and availability of all the
cells under all dual-homing NodeBs under the secondary RNC. Assume that there are 35 NodeBs
under an RNC and that the parameters related to the RNC pool heartbeat detection are set to
default values. It takes about six minutes before all the cells under the dual-homing NodeBs are
set up under the secondary RNC after the primary RNC fails.
When the primary RNC recovers, it takes the NodeB control rights back according to the re-
homing policy. The process of taking the NodeB control rights back for the primary RNC is
similar to that of taking over the NodeB control rights for the secondary RNC. During this
process, the secondary RNC removes the cells under the dual-homing NodeBs and then the cells
are set up and become available under the primary RNC. Services are also interrupted for about
six minutes during the process.

WCDMA RAN
3.4 Re-Homing of NodeB Control Rights

When the primary RNC is restored, the primary RNC takes over the NodeB control rights
automatically again according to the re-homing policy specified by the ReHostPolicy
(BSC6900,BSC6910) parameter:
l REHOSTRIGHNOW: The primary RNC immediately sends a request for the NodeB
control rights to the secondary RNC.
l REHOSTDELAY: The primary RNC waits for a while and then sends a request for the
NodeB control rights to the secondary RNC. The delay time is specified by the Delay
(BSC6900,BSC6910) parameter.
l REHOSTWHEN: The primary RNC does not immediately send a request for the NodeB
control rights to the secondary RNC. Instead, it sends the request at the time specified by
the AbsTime(BSC6900,BSC6910) parameter.
3.5 Forced Homing of NodeB Control Rights

In RNC node redundancy, when transmission between a NodeB and the primary RNC fails, the
secondary RNC cannot automatically take over this NodeB. To solve this problem, you can run
the FOC UHOSTNODEB command on the secondary RNC to manually switch the NodeB to
the secondary RNC.
When the primary RNC recovers, you can run the FOC UDEHOSTNODEB command on the
secondary RNC to manually switch the NodeB to the primary RNC again.
3.6 Requirements of RNC Node Redundancy on

Transmission
To enable RNC node redundancy, an Iub interface must be configured between the NodeB and
the primary RNC and between the NodeB and the secondary RNC. Moreover, a route over the
Iur interface and alternative routes over the Iu interface must be configured between the primary
and secondary RNCs to transmit heartbeat messages, as shown in Figure 3-4. The route over
the lur interface will be chosen first to transmit heartbeat messages.

WCDMA RAN
Figure 3-4 Routes over the interface between RNCs

WCDMA RAN
RNC Node Redundancy Feature Parameter Description 4 Feature Deployment
4 Feature Deployment
This section describes how to activate, verify, and deactivate the optional feature WRFD-040202
RNC Node Redundancy.

WCDMA RAN
4.1 Prerequisites
l Dependencies on Hardware
The BSC6910 does not support this feature.
l Dependencies on Other Features
This feature does not depend on other features.
l License
The license " RNC Node Redundancy" on the RNC side has been activated. For details
about the license items and how to activate the license, see License Management Feature
Parameter Description.
l The Iur, Iu-CS, Iub and Iu-PS interfaces have been configured. For details, see Configuring
the Interfaces.
l This feature has been available since RAN11.0 and is applicable only to the RNC.
4.2 Procedure
4.2.1 Activation Procedure

NOTE
This document uses RNC202, RNC203, and NodeB1 as examples to describe the procedures. Assume that
RNC202 and RNC203 are initially configured as the primary homing and secondary homing RNC of
NodeB1 respectively.
Step 1 Data configurations on the primary homing RNC (RNC202)

1. Run the RNC MML command ADD URNCPOOL (CME single configuration: UMTS
Global Configuration Express > Redundancy Backup Configuration > RNC Pool; CME
batch modification center: not supported) to add an RNC pool. In this step, set the
parameters such as RncPool Index, RncPool Name, Supporting Auto-Rehoming
Switch and so on.
NOTICE
If the license is activated, the primary homing RNC is physically broken down and
Supporting Auto-Rehoming Switch is set to OFF, the feature WRFD-040300 License
Control for Urgency will be activated. WRFD-040300 License Control for Urgency can be
enabled only fifteen times for each R version for this kind of reason.
2. Run the RNC MML command ADD URNCPOOLMEMBER (CME single configuration:
UMTS Global Configuration Express > Redundancy Backup Configuration > RNC Pool
Member; CME batch modification center: not supported) to add the primary homing RNC
(RNC203) to the RNC pool.
3. Run the RNC MML command ACT URNCPOOL (CME single configuration: UMTS
GLOBAL Configuration Express > Redundancy Backup Configuration > RNC Pool. Set

WCDMA RAN
active status to Activated; CME batch configuration: not supported) to activate the RNC
node redundancy feature.
4. Add a NodeB (NodeB1) of which the primary homing RNC is RNC202: Run the RNC
MML command ADD UNODEB (CME single configuration: Main View > Right Click
RNC > Create Logical NodeB; CME batch modification center: not supported) to add a
NodeB of which the primary homing RNC is RNC202.
5. Run the RNC MML command ADD UCELLQUICKSETUP (CME single configuration:
Main View > Right click NodeB > Add UMTS Cell; CME batch modification center: not
supported) to add the cell to the primary homing RNC and specify the peer cell ID under
the secondary homing RNC.
6. Run the RNC MML command SET UPOOLPRIMHOSTPOLICY (CME single
configuration: UMTS Global Configuration Express > Redundancy Backup Configuration
> Re-host Policy; CME batch modification center: Modifying RNC Parameters in Batches)
to set the rehoming strategy of the NodeB.
Step 2 Data configurations on the secondary homing RNC (RNC203)
1. Run the RNC MML command ADD URNCPOOL (CME single configuration: UMTS
Global Configuration Express > Redundancy Backup Configuration > RNC Pool; CME
batch modification center: not supported) to add an RNC pool. In this step, set the
parameters such as RncPool Index, RncPool Name, Supporting Auto-Rehoming
Switch and so on.
NOTICE
If the license is activated, the secondary homing RNC is physically broken down and
Supporting Auto-Rehoming Switch is set to OFF, and the feature WRFD-040300
License Control for Urgency will be activated. WRFD-040300 License Control for
Urgency can be enabled only fifteen times for each R version for this kind of reason.
2. Run the RNC MML command ADD URNCPOOLMEMBER (CME single configuration:
UMTS Global Configuration Express > Redundancy Backup Configuration > RNC Pool
Member; CME batch modification center: not supported) to add the primary homing RNC
(RNC202) to the RNC pool.
3. Run the RNC MML command ACT URNCPOOL (CME single configuration: UMTS
GLOBAL Configuration Express > Redundancy Backup Configuration > RNC Pool. Set
active status to Activated; CME batch configuration: not supported) to activate the RNC
node redundancy feature.
4. Add a NodeB (NodeB1) of which the secondary homing RNC is RNC203: Run the RNC
MML command ADD UNODEB (CME single configuration: Main View > Right Click
RNC > Create Logical NodeB; CME batch modification center: not supported) to add a
NodeB of which the secondary homing RNC is RNC203.
5. Run the RNC MML command ADD UCELLQUICKSETUP (CME single configuration:
Main View > Right click NodeB > Add UMTS Cell; CME batch modification center: not
supported) to add the cell to the secondary homing RNC and specify the peer cell ID under
the primary homing RNC.
Step 3 Data configurations on the NodeB (NodeB1) side
----End

WCDMA RAN
1. Configure information about the primary homing RNC.

2. Run the NodeB MML command ADD IUBCP (CME single configuration: NodeB
Configuration Express > IUB_NodeB > ATM Transport Layer > NBAP > NBIUBCP;
CME batch modification center: not supported) to add an NCP link.
CME batch modification center: not supported) to add a CCP link.
4. Configure information about the secondary homing RNC.
CME batch modification center: not supported) to add an NCP link.
CME batch modification center: not supported) to add a CCP link.
4.2.2 Verification Procedure

l Method 1: Verifying data configurations
Step 1 Run the RNC MML command DSP UCELL on the RNC202 LMT. The query result shows that
cell 1 is functional. Run the RNC MML command DSP UCELL on the RNC203 LMT. The
query result shows that cell 2 is unavailable due to no control rights.
Step 2 Perform an emulation test of the primary RNC fault.

l Run the RNC MML command RST UIU on RNC202 to make RNC202 become faulty.
l If the RNC recovers too fast after the RNC MML command RST UIU is executed, you can
remove the cable on the Iu-CS/Iu-PS interface instead.
Step 3 After RNC203 detects that RNC202 is faulty through the Iur interface, RNC203 takes over the
NodeB and initiates cell2 reestablishment.
Step 4 (Optional) When the connection between the NodeB and the primary homing RNC is
disconnected, the secondary homing RNC cannot obtain the NodeB control rights automatically.
To solve this problem, run the RNC MML command FOC UHOSTNODEB on the RNC203
LMT to manually switch over the NodeB control rights to the secondary homing RNC.
NOTICE
Switching over NodeB control rights manually interrupts the ongoing services when the
connection between the NodeB and the primary homing RNC is normal.
Step 5 On both the RNC203 LMT and the RNC202 LMT, run the RNC MML command DSP
UCELL. If the query result on the RNC203 LMT shows that cell 2 is operational and the query
result on the RNC202 LMT shows that cell 1 is unavailable due to no control rights, this feature
has been activated. Otherwise, this feature is not activated.
----End

WCDMA RAN
l Method 2: Verifying services
Step 1 Check whether the heartbeat between RNC202 and RNC203 is normal, as shown in Figure 4-1
Figure 4-1 Normal heartbeat between RNC202 and RNC203
Step 2 Check that the cell under RNC202 is available, and then use the UE to establish a CS AMR
service, as shown in Figure 4-2 and Figure 4-3.
Figure 4-2 NodeB control rights obtained by RNC202
Figure 4-3 CS AMR service setting up successfully
Step 3 Power off RNC202 when RNC203 works properly. RNC203 then takes over the NodeB control
rights.

WCDMA RAN
Step 4 When RNC202 restores normal services, it takes over the NodeB control rights again according
to the rehoming strategy, and RNC203 releases the NodeB control rights.
----End
l Method 3: Verifying this feature on the U2000
Step 1 Create the RNCs and NodeB on the RNC POOL monitor of the U2000. When creating a NodeB,
the U2000 checks the homing state of the NodeB. If the RNC is the secondary homing RNC of
the NodeB, the NodeB cannot be created under that RNC.
Step 2 When the U2000 starts, it starts NE status subscribing. When the homing state of the NodeB
changes, the RNC reports the NodeB homing state to the U2000. The U2000 then updates the
network topology displayed in the RNC POOL monitor.
----End
4.2.3 Deactivation Procedure

Step 1 On RNC202 and RNC203, run the RNC MML command DEA URNCPOOL (CME single
configuration: UMTS GLOBAL Configuration Express > Redundancy Backup Configuration
> RNC Pool. Set active status to Deactivated; CME batch configuration: not supported) to
deactivate the feature.
----End
4.2.4 Example
/*Activation procedure*/
/*Data configuration script on the primary homing RNC side*/
/*Configuring an RNC pool*/
ADD URNCPOOL: RncPoolIndex=0, RncPoolName="redundancy_RNCPOOL";
ADD URNCPOOLMEMBER: RncPoolIndex=0, NrncId=203;
ACT URNCPOOL: RncPoolIndex=0;
//Adding a dual-homing NodeBADD UNODEB: NodeBName="Redundancy_NODEB500",

NodeBId=500, SRN=0, SN=0, SSN=1,
TnlBearerType=IP_TRANS,IPTRANSAPARTIND=NOT_SUPPORT, HostType=PRIMHOST,
PeerRncId=203, PeerNodebId=500, SharingType=RANSHARING;
//Setting cell parameters

ADD UCELLQUICKSETUP: CellId=1, CellName="Redundancy_NODEB500_00",
PeerIsValid=VALID, PeerCellId=2, CnOpGrpIndex=0, BandInd=Band1,
UARFCNDownlink=10668, PScrambCode=500, TCell=CHIP0, LAC=H'0046, SAC=H'0000,
CfgRacInd=REQUIRE, RAC=H'00, SpgId=1, URANUM=D1, URA1=0,
NodeBName="Redundancy_NODEB500", LoCell=500, SupBmc=FALSE;
/*Data configuration script on the secondary homing RNC side*/

/*Configuring an RNC pool*/
ADD URNCPOOL: RncPoolIndex=0, RncPoolName="redundancy_RNCPOOL";
ADD URNCPOOLMEMBER: RncPoolIndex=0, NrncId=202;
ACT URNCPOOL: RncPoolIndex=0;
//Adding a dual-homing NodeB

ADD UNODEB: NodeBName="Redundancy_NODEB500", NodeBId=500, SRN=0, SN=0, SSN=1,
TnlBearerType=IP_TRANS, IPTRANSAPARTIND=NOT_SUPPORT, HostType=SECHOST,
PeerRncId=202, PeerNodebId=500, SharingType=RANSHARING;
//Setting cell parameters

ADD UCELLQUICKSETUP: CellId=2, CellName="Redundancy_NODEB500_00",
PeerIsValid=VALID, PeerCellId=1, CnOpGrpIndex=0, BandInd=Band1,
UARFCNDownlink=10668, PScrambCode=500, TCell=CHIP0, LAC=H'0046, SAC=H'0000,

WCDMA RAN
CfgRacInd=REQUIRE, RAC=H'00, SpgId=1, URANUM=D1, URA1=0,

NodeBName="Redundancy_NODEB500", LoCell=500, SupBmc=FALSE;
/*Data configuration script on the NodeB side*/

/*Configuring information about the primary homing RNC on the NodeB*/
/*Configuring NCP and CCP*/
ADD IUBCP: CPPT=NCP, BEAR=IPV4;
ADD IUBCP: CPPT=CCP, BEAR=IPV4, LN=1;
/*Configuring information about the secondary homing RNC on the NodeB*/

/*Configuring NCP and CCP*/
ADD IUBCP: CPPT=NCP, BEAR=IPV4, LN=2, BELONG=SLAVE;
ADD IUBCP: CPPT=CCP, BEAR=IPV4, LN=3, BELONG=SLAVE;
/*Verifying RNC Node Redundancy*///RNC202
DSP UCELL: DSPT=BYCELL, CellId=1;
//RNC203
//RNC202
RST UIU: CnOpIndex=0, CNDOMAINID= ALL_DOMAIN, RSTCNTYPE=ALL_NODES;
//RNC202
//RNC203
//Deactivating RNC Node Redundancy
//RNC202&RNC203
DEA URNCPOOL: RncPoolIndex=0;

WCDMA RAN
RNC Node Redundancy Feature Parameter Description 5 Parameters
5 Parameters
Table 5-1 Parameter description
Parame NE MML Feature Feature Description

ter ID Comma ID Name
nd
SupAuto BSC690 ADD WRFD- RNC Meaning: When RNC POOL feather is activated, RNC
Rehomi 0 URNCP 040202 Node supports auto-rehoming of NodeB's control right. This
ng OOL Redunda parameter is an advanced parameter. To modify this
MOD ncy parameter, contact Huawei Customer Service Center for
URNCP technical support.
OOL GUI Value Range: OFF, ON
Unit: None
Actual Value Range: OFF, ON
Default Value: OFF
SupAuto BSC691 ADD None None Meaning: When RNC POOL feather is activated, RNC
Rehomi 0 URNCP supports auto-rehoming of NodeB's control right. This
ng OOL parameter is an advanced parameter. To modify this
MOD parameter, contact Huawei Customer Service Center for
URNCP technical support.
OOL GUI Value Range: OFF, ON
Unit: None
Actual Value Range: OFF, ON
Default Value: OFF

WCDMA RAN

nd
IuStateP BSC690 ADD WRFD- RNC Meaning: How the RNC state is affected by the Iu
olicyFor 0 URNCP 040202 Node interface service state. If the value is NONE, the RNC
Pool OOL Redunda state is independent of the Iu interface state (faulty or
MOD ncy recovery). If the value is IUCS, the RNC state is
URNCP considered to be faulty when the Iu-CS interface is
OOL faulty. If the value is IUPS, the RNC state is considered
to be faulty when the Iu-PS interface is faulty. If the
value is IUCS_IUPS, the RNC state is considered to be
faulty when either the Iu-CS or the Iu-PS interface is
faulty.
GUI Value Range: NONE, IUCS, IUPS, IUCS_IUPS
Unit: None
Actual Value Range: NONE, IUCS, IUPS, IUCS_IUPS
Default Value: IUCS_IUPS
IuStateP BSC691 ADD None None Meaning: How the RNC state is affected by the Iu
olicyFor 0 URNCP interface service state. If the value is NONE, the RNC
Pool OOL state is independent of the Iu interface state (faulty or
MOD recovery). If the value is IUCS, the RNC state is
URNCP considered to be faulty when the Iu-CS interface is
OOL faulty. If the value is IUPS, the RNC state is considered
to be faulty when the Iu-PS interface is faulty. If the
value is IUCS_IUPS, the RNC state is considered to be
faulty when either the Iu-CS or the Iu-PS interface is
faulty.
GUI Value Range: NONE, IUCS, IUPS, IUCS_IUPS
Unit: None
Actual Value Range: NONE, IUCS, IUPS, IUCS_IUPS
Default Value: IUCS_IUPS

WCDMA RAN

nd
HostTyp BSC690 ADD WRFD- RNC in Meaning: This parameter specifies the NodeB host type
e 0 UNODE 150212 Pool in RNC Node Redundancy function. If the parameter
B WRFD- Node value is SINGLEHOST, the physical NodeB is
MOD 040202 Redunda managed only by one logic RNC. If the parameter value
UNODE ncy is PRIMHOST or SECHOST, the physical NodeB can
B RNC be managed by two logic RNCs. If the parameter value
Node is DUALHOST, the physical NodeB is managed by two
Redunda physical RNCs under a logical RNC.
ncy GUI Value Range: SINGLEHOST(SingleHost),
PRIMHOST(PrimHost), SECHOST(SecHost),
DUALHOST(DUALHOST)
Unit: None
Actual Value Range: SINGLEHOST, PRIMHOST,
SECHOST, DUALHOST
Default Value: SINGLEHOST(SingleHost)
HostTyp BSC691 ADD WRFD- RNC in Meaning: This parameter specifies the NodeB host type
e 0 UNODE 150212 Pool in RNC Node Redundancy function. If the parameter
B Node value is SINGLEHOST, the physical NodeB is
MOD Redunda managed only by one logic RNC. If the parameter value
UNODE ncy is PRIMHOST or SECHOST, the physical NodeB can
B be managed by two logic RNCs. If the parameter value
is DUALHOST, the physical NodeB is managed by two
physical RNCs under a logical RNC.
GUI Value Range: SINGLEHOST(SingleHost),
PRIMHOST(PrimHost), SECHOST(SecHost),
DUALHOST(DUALHOST)
Unit: None
Actual Value Range: SINGLEHOST, PRIMHOST,
SECHOST, DUALHOST
Default Value: SINGLEHOST(SingleHost)
BeatSen BSC690 ADD WRFD- RNC Meaning: Interval at which the local RNC sends
dingDis 0 URNCP 040202 Node heartbeat messages to the peer RNC in the same RNC
OOL Redunda POOL.
MOD ncy GUI Value Range: 1~60
URNCP Unit: s
OOL
Actual Value Range: 1~60
Default Value: 3

WCDMA RAN

nd
BeatSen BSC691 ADD None None Meaning: Interval at which the local RNC sends
dingDis 0 URNCP heartbeat messages to the peer RNC in the same RNC
OOL POOL.
MOD GUI Value Range: 1~60
URNCP Unit: s
OOL
Default Value: 3
BeatDec BSC690 ADD WRFD- RNC Meaning: Threshold of continuously failed heartbeat
tThred 0 URNCP 040202 Node detection between two RNCs in an RNC POOL. If the
OOL Redunda heartbeat is not detected from the peer RNC for a
MOD ncy successive number of times specified by this parameter,
URNCP the local RNC considers that the peer RNC is faulty.
OOL GUI Value Range: 1~10
Unit: None
Default Value: 5
BeatDec BSC691 ADD None None Meaning: Threshold of continuously failed heartbeat
tThred 0 URNCP detection between two RNCs in an RNC POOL. If the
OOL heartbeat is not detected from the peer RNC for a
MOD successive number of times specified by this parameter,
URNCP the local RNC considers that the peer RNC is faulty.
Unit: None
Default Value: 5
BeatRec BSC690 ADD WRFD- RNC Meaning: Heartbeat recovery times threshold. If the
vrThred 0 URNCP 040202 Node heartbeats are detected from the peer RNC for a
OOL Redunda successive number of times specified by this parameter,
MOD ncy the local RNC considers that the peer RNC is working
URNCP properly.
Unit: None
Default Value: 2

WCDMA RAN

nd
BeatRec BSC691 ADD None None Meaning: Heartbeat recovery times threshold. If the
vrThred 0 URNCP heartbeats are detected from the peer RNC for a
OOL successive number of times specified by this parameter,
MOD the local RNC considers that the peer RNC is working
URNCP properly.
Unit: None
Default Value: 2
ReHostP BSC690 SET WRFD- RNC Meaning: This parameter specifies re-host policy type
olicy 0 UPOOL 040202 Node for NodeB. The value "REHOSTRIGHTNOW"
PRIMH Redunda indicates to perform re-host policy for the NodeB
OSTPO ncy immediately when the RNC recovers from disaster. The
LICY value "REHOSTDELAY" indicates to perform re-host
policy for the NodeB after a specified delayed period
when the RNC recovers from disaster. The value
"REHOSTWHEN" indicates to perform re-host policy
for the NodeB at a specific time.
GUI Value Range: REHOSTRIGHNOW
(RehostRighNow), REHOSTDELAY(RehostDelay),
REHOSTWHEN(RehostWhen)
Unit: None
Actual Value Range: REHOSTRIGHNOW,
REHOSTDELAY, REHOSTWHEN
Default Value: REHOSTRIGHNOW
(RehostRighNow)

WCDMA RAN

nd
ReHostP BSC691 SET None None Meaning: This parameter specifies re-host policy type
olicy 0 UPOOL for NodeB. The value "REHOSTRIGHTNOW"
PRIMH indicates to perform re-host policy for the NodeB
OSTPO immediately when the RNC recovers from disaster. The
LICY value "REHOSTDELAY" indicates to perform re-host
policy for the NodeB after a specified delayed period
when the RNC recovers from disaster. The value
"REHOSTWHEN" indicates to perform re-host policy
for the NodeB at a specific time.
GUI Value Range: REHOSTRIGHNOW
(RehostRighNow), REHOSTDELAY(RehostDelay),
REHOSTWHEN(RehostWhen)
Unit: None
Actual Value Range: REHOSTRIGHNOW,
REHOSTDELAY, REHOSTWHEN
Default Value: REHOSTRIGHNOW
(RehostRighNow)
Delay BSC690 SET WRFD- RNC Meaning: This parameter specifies the delay time.
0 UPOOL 040202 Node When the RNC recovers from disaster and starts to
PRIMH Redunda operate, it performs re-host policy for the primary
OSTPO ncy hosted NodeB after the specified delay time.
LICY GUI Value Range: 0~3600
Unit: s
Default Value: 0
Delay BSC691 SET None None Meaning: This parameter specifies the delay time.
0 UPOOL When the RNC recovers from disaster and starts to
PRIMH operate, it performs re-host policy for the primary
OSTPO hosted NodeB after the specified delay time.
LICY GUI Value Range: 0~3600
Unit: s
Default Value: 0
AbsTim BSC690 SET WRFD- RNC Meaning: This parameter specifies the time to execute
e 0 UPOOL 040202 Node re-host policy for the primary hosted NodeB, after the
PRIMH Redunda RNC recovers from disaster and starts to operate.
OSTPO ncy GUI Value Range: 00:00:00~23:59:59
LICY
Unit: s
Actual Value Range: 00:00:00~23:59:59
Default Value: None

WCDMA RAN

nd
AbsTim BSC691 SET None None Meaning: This parameter specifies the time to execute
e 0 UPOOL re-host policy for the primary hosted NodeB, after the
PRIMH RNC recovers from disaster and starts to operate.
OSTPO GUI Value Range: 00:00:00~23:59:59
LICY
Unit: s
Actual Value Range: 00:00:00~23:59:59
Default Value: None

WCDMA RAN
RNC Node Redundancy Feature Parameter Description 6 Counters
6 Counters
Table 6-1 Counter description
Counter ID Counter Name Counter NE Feature ID Feature Name

Description
73423639 VS.SHO.FailRL Number of BSC6900 WRFD-020203 Inter RNC Soft

SetupIur.NodeB Radio Link WRFD-040202 Handover
ReHost.Rx Setup Failures RNC Node
on Iur interface Redundancy
for SRNC
(NodeB
Rehoming)
73423640 VS.SHO.FailRL Number of BSC6900 WRFD-040202 RNC Node

AddIur.NodeB Failed Radio WRFD-020203 Redundancy
ReHost.Rx Link Additions Inter RNC Soft
on Iur interface Handover
for SRNC
(NodeB
Rehoming)

SetupIur.NodeB Failed Radio WRFD-040202 Handover
ReHost.Tx Link Setups on RNC Node
Iur interface for Redundancy
DRNC (NodeB
Rehoming)

AddIur.NodeB Failed Radio WRFD-040202 Handover
ReHost.Tx Link Additions RNC Node
on Iur interface Redundancy
for DRNC
(NodeB
Rehoming)

WCDMA RAN
RNC Node Redundancy Feature Parameter Description 6 Counters
Counter ID Counter Name Counter NE Feature ID Feature Name

Description
73423643 VS.DRELOC.F Number of BSC6900 WRFD-040202 RNC Node

ailPrep.NodeBR Failed WRFD-020605 Redundancy
eHost Relocation SRNS
Preparations for Relocation
TRNC (NodeB Introduction
Rehoming) Package
73423644 RELOC.FailPre Number of BSC6900 WRFD-040202 RNC Node

pUEInvolCS.N Failed CS WRFD-020605 Redundancy
odeBReHost Relocation SRNS
SRNC (UE Introduction
Involved) Package
(NodeB
Rehoming)
73423645 RELOC.FailPre Number of BSC6900 WRFD-040202 RNC Node

pUEInvolPS.No Failed PS WRFD-020605 Redundancy
deBReHost Relocation SRNS
SRNC (UE Introduction
Involved) Package
(NodeB
Rehoming)

WCDMA RAN
RNC Node Redundancy Feature Parameter Description 7 Glossary
7 Glossary
For the acronyms, abbreviations, terms, and definitions, see the Glossary.

WCDMA RAN
RNC Node Redundancy Feature Parameter Description 8 Reference Documents
8 Reference Documents
License Management Feature Parameter Description


RNC Node Redundancy (RAN15.0 - 01)

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

RNC Node Redundancy (RAN15.0 - 01)

Încărcat de

Drepturi de autor:

Formate disponibile

WCDMA RAN

RNC Node Redundancy Feature

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2013-04-28) Huawei Proprietary and Confidential i

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

2 Overview of RNC Node Redundancy.......................................................................................3

Issue 01 (2013-04-28) Huawei Proprietary and Confidential ii

1 About This Document

1.2 Intended Audience

l Need to understand the features described herein

1.3 Change History

RAN15.0 Draft A (2013-01-30)

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 1

1.4 Differences Between Base Station Types

Base Station Model

Macro l 3900 series base stations

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 2

2 Overview of RNC Node Redundancy

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 3

Figure 2-1 RNC-supported 1+1 backup mode

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 4

3.1 Basic Principles

3.1.1 RNC Pool

Figure 3-1 RNC pool

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 5

3.1.2 NodeB Control Rights in the RNC Pool

l The primary RNC fails.

3.1.3 Constraints of RNC Node Redundancy

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 6

3.2 Heartbeat Detection Between the Primary and

Table 3-1 Heartbeat parameters used in RNC node redundancy

Parameter Identity Parameter Name Parameter Description

BeatSendingDis Heartbeat Sending Time This parameter specifies the

BeatDectThred Heartbeat Lost Times If the number of consecutive

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 7

Parameter Identity Parameter Name Parameter Description

BeatRecvrThred HeatBeat Recover Times If the number of consecutive

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 8

Parameter Identity Parameter Name Parameter Description

IuStatePolicyForPool Iu State Policy For RncPool This parameter can be set to

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 9

Parameter Identity Parameter Name Parameter Description

PS interface. If any one of

l The RNC fails.

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 10

Figure 3-2 Peer RNC Failure Detection

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 11

Figure 3-3 Detecting that the peer RNC becomes operational

3.3 Taking Over the NodeB Control Rights

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 12

3.4 Re-Homing of NodeB Control Rights

3.5 Forced Homing of NodeB Control Rights

3.6 Requirements of RNC Node Redundancy on

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 13

Figure 3-4 Routes over the interface between RNCs

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 14

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 15

4.2.1 Activation Procedure

Step 1 Data configurations on the primary homing RNC (RNC202)

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 16

Issue 01 (2013-04-28) Huawei Proprietary and Confidential 17

/Data configuration script on the secondary homing RNC side/

/Data configuration script on the NodeB side/

/Configuring information about the secondary homing RNC on the NodeB/