Professional Documents
Culture Documents
RNC Node Redundancy (RAN15.0 - 01)
RNC Node Redundancy (RAN15.0 - 01)
Issue 01
Date 2013-04-28
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.
Website: http://www.huawei.com
Email: support@huawei.com
Contents
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
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.
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.
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.
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.
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.
3 Technical Description
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
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.
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:
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.
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
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.
The RNC stops sending heartbeat signals to the other RNC in the RNC pool in either of the
following cases:
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.
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.
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.
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.
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.
4 Feature Deployment
This section describes how to activate, verify, and deactivate the optional feature WRFD-040202
RNC Node Redundancy.
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
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.
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
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
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 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
Step 1 Check whether the heartbeat between RNC202 and RNC203 is normal, as shown in Figure 4-1
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.
Step 3 Power off RNC202 when RNC203 works properly. RNC203 then takes over the NodeB control
rights.
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
----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;
//RNC203
DSP UCELL: DSPT=BYCELL, CellId=2;
//RNC202
RST UIU: CnOpIndex=0, CNDOMAINID= ALL_DOMAIN, RSTCNTYPE=ALL_NODES;
//RNC202
DSP UCELL: DSPT=BYCELL, CellId=1;
//RNC203
DSP UCELL: DSPT=BYCELL, CellId=2;
//Deactivating RNC Node Redundancy
//RNC202&RNC203
DEA URNCPOOL: RncPoolIndex=0;
5 Parameters
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
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
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
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
Actual Value Range: 1~60
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
Actual Value Range: 1~10
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.
OOL GUI Value Range: 1~10
Unit: None
Actual Value Range: 1~10
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.
OOL GUI Value Range: 1~10
Unit: None
Actual Value Range: 1~10
Default Value: 2
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.
OOL GUI Value Range: 1~10
Unit: None
Actual Value Range: 1~10
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)
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
Actual Value Range: 0~3600
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
Actual Value Range: 0~3600
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
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
6 Counters
7 Glossary
For the acronyms, abbreviations, terms, and definitions, see the Glossary.
8 Reference Documents