Rnc node redundancy description
-
Upload
emerson-eduardo-rodrigues-pmp -
Category
Documents
-
view
27 -
download
2
Transcript of Rnc node redundancy description
RAN
RNC Node Redundancy Description
Issue 01
Date 2009-03-30
Huawei Proprietary and Confidential Copyright © Huawei
Technologies Co., Ltd
Huawei Proprietary and Confidential Copyright © Huawei
Technologies Co., Ltd
Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. For any assistance, please contact our local office or company headquarters.
Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: [email protected]
Copyright © Huawei Technologies Co., Ltd. 2009. 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 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 the warranty of any kind, express or implied.
Huawei Proprietary and Confidential Copyright © Huawei
Technologies Co., Ltd
RANRNC Node Redundancy Description
About This Document
About This Document
Author
Prepared by
Huang Yu Date 2008-12-16
Edited by Cheng Xiaoli Date 2009-01-05
Reviewed by
Date
Translated by
Wang Xiaofen Date 2009-01-15
Tested by Hu Zengqiang Date 2009-02-20
Approved by
Duan Zhongyi Date 2009-03-30
Issue 01 (2009-03-30) Huawei Proprietary and Confidential Copyright © Huawei
Technologies Co., Ltd
v
RANRNC Node Redundancy Description
Contents
Contents
1 Change History...........................................................................1-2
2 RNC Node Redundancy Introduction............................................2-2
3 RNC Node Redundancy Principles................................................3-23.1 Network Architecture.....................................................................................................................................3-2
3.2 RNC Pool........................................................................................................................................................3-2
3.2.1 Activation of the RNC Pool..................................................................................................................3-2
3.2.2 NodeB Controlling in the RNC Pool.....................................................................................................3-2
3.3 RNC Heartbeat Detection Mechanism...........................................................................................................3-2
3.4 Forced Homing...............................................................................................................................................3-2
3.5 Re-homing Policy...........................................................................................................................................3-2
3.6 Application Scenarios.....................................................................................................................................3-2
4 RNC Node Redundancy Parameters..............................................4-24.1 Description.....................................................................................................................................................4-2
4.2 Values and Ranges..........................................................................................................................................4-2
5 Reference Documents.................................................................5-2
Issue 01 (2009-03-30) Huawei Proprietary and Confidential Copyright © Huawei
Technologies Co., Ltd
vii
RANRNC Node Redundancy Description
1 Change History
1 Change History
The change history provides information on the changes in different document versions.
Document and Product Versions
Document Version RAN Version
01 (2009-03-30) 11.0
Draft (2009-03-10) 11.0
Draft (2009-01-15) 11.0
This document is based on the BSC6810 and 3900 series NodeBs.
The available time of each feature is subject to the RAN product roadmap.
There are two types of changes, which are defined as follows:
Feature change: refers to the change in the RNC node redundancy feature.
Editorial change: refers to the change in the information that was inappropriately described or the addition of the information that was not described in the earlier version.
01 (2009-03-30)
This is the document for the first commercial release of RAN11.0.
Compared with draft (2009-03-10), this issue optimizes the description.
Draft (2009-03-10)
This is the second draft of the document for RAN11.0.
Compared with draft (2009-01-15), draft (2009-03-10) optimizes the description.
Draft (2009-01-15)
This is the initial draft of the document for RAN11.0.
This is a new document.Issue 01 (2009-03-30) Huawei Proprietary and Confidential
Copyright © HuaweiTechnologies Co., Ltd
1
RNC Node Redundancy Description
2 RNC Node Redundancy Introduction
2 RNC Node Redundancy
Introduction
The RNC controls the radio resources of the radio network subsystem (RNS). When the RNC fails, none of the NodeBs of the RNS can access the network and thus the RNS cannot provide services in its coverage area. In addition, when the transmission link between the RNC and a NodeB fails, this NodeB cannot provide services in its coverage area.
To avoid these problems, RNC node redundancy is introduced at the network element (NE) level. Figure 2-1 shows the 1+1 backup mode supported by the RNC.
Figure 2-1 1+1 backup mode supported by the RNC
Each NodeB is configured with two transmission links towards two home RNCs, namely, the primary RNC and the secondary RNC. All the data related to NodeBs, cells, and their neighboring cells is stored on both the RNCs. In 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 and to resume the work.
The dual-homed NodeB has two Iub interfaces, including two sets of control plane links, user plane links, and management plane links. The two RNCs each can serve as the CRNC and implement cold backup with the exception that calls are not protected. In this way, the network reliability is improved. The two RNCs do not work in active/standby mode. In normal situations, both are employed and thus the equipment can be fully utilized. When one of the RNCs fails, the other takes over all the NodeBs to protect the NodeB from being out of service because of an RNC failure.
Intended Audience
This document is intended for:
Issue 01 (2009-03-30) Huawei Proprietary and Confidential Copyright © Huawei
Technologies Co., Ltd
1
RNC Node Redundancy Description
2 RNC Node Redundancy Introduction
System operators who need a general understanding of RNC node redundancy.
Personnel working on Huawei products or systems.
Impact Impact on system performance
RNC node redundancy improves the reliability and robustness of the RAN and shortens the duration of service disruption due to an RNC failure.
Impact on other features
None.
Network Element Involved
Table 2-1 lists the NEs involved in RNC node redundancy.
Table 2-1 NEs involved in RNC node redundancy
UE NodeB RNC MSC Server MGW SGSN GGSN HLR
- √ √ - - - - -
NOTE: –: not involved √: involved
UE = User Equipment, RNC = Radio Network Controller, MSC Server = Mobile Service Switching Center Server, MGW = Media Gateway, SGSN = Serving GPRS Support Node, GGSN = Gateway GPRS Support Node, HLR = Home Location Register
Issue 01 (2009-03-30) Huawei Proprietary and Confidential Copyright © Huawei
Technologies Co., Ltd
2
RANRNC Node Redundancy Description 3 RNC Node Redundancy Principles
3 RNC Node Redundancy
Principles
3.1 Network ArchitectureFigure 3-1 shows the network architecture for RNC node redundancy. On the network, each NodeB has two Iub interfaces, connecting two RNCs. One RNC has the preferential NodeB control rights; this RNC is called the primary RNC. The other RNC takes over the NodeB control rights when the primary RNC fails; this RNC is called the secondary RNC.
Figure 3-1 RNC node redundancy network architecture
In normal conditions, the primary RNC controls the NodeBs. When the primary RNC fails because of a natural disaster or other factors, the secondary RNC takes over the NodeB
Issue 01 (2009-03-30) Huawei Proprietary and Confidential Copyright © Huawei Technologies
Co., Ltd
1
RANRNC Node Redundancy Description 3 RNC Node Redundancy Principles
control rights to avoid service disruption and to improve the system reliability. If the primary RNC comes back to normal, the primary RNC will take over the NodeB control right again according to the re-homing policy, and the secondary NodeB will release the NodeB control right.
The primary and secondary RNCs of a NodeB are specified through the HostType parameter.
The constraints of RNC node redundancy in RAN11.0 are as follows:
Supporting only the preset redundancy
The secondary RNC takes over the NodeB control rights only when the primary RNC fails. When the primary Iub interface fails, the secondary RNC does not take over the NodeB control rights even if the secondary Iub interface works properly.
Not supporting automatic load sharing during busy hours
Even when the load of the primary RNC (including the control plane and the user plane) is higher than that of the secondary RNC, the NodeBs are not switched to the secondary RNC.
Supporting only the 1+1 backup mode
One NodeB can be configured with only one primary RNC and only one secondary RNC. It cannot be configured with multiple secondary RNCs.
Not considering the relay and service agent on the control plane when the primary RNC fails
Call drops are tolerable if they are caused by Iur switching, relocation, or inter-RAT handover from the failed RNC, which originally serves as the DRNC or TRNC.
Not considering the relation between performance statistics before disaster recovery and those after disaster recovery
If 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 RNC PoolDuring the configuration of RNC node redundancy, two RNCs, namely the primary RNC and the secondary RNCs, need to be added to an RNC pool. In RAN11.0, 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.
Issue 01 (2009-03-30) Huawei Proprietary and Confidential Copyright © Huawei Technologies
Co., Ltd
2
RANRNC Node Redundancy Description 3 RNC Node Redundancy Principles
Figure 3-1 RNC pool
The RNCs in the RNC pool detect the status of each other by using the heartbeat detection mechanism. When the secondary RNC finds that the primary RNC fails, it takes over the NodeB control rights. 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. The two ways guarantee the transmission of heartbeat signals between the RNCs.
The alternative routes over the Iu interfaces must cover all the CN domains to which the two RNCs connect. Assume that RNC 1 uses the Iu-Flex function. Then, alternative routes must be configured on the side of RNC 2 for every CN domain to which RNC 1 connects, and RNC 1 can send out heartbeat signals through any CN domain.
3.2.1 Activation of the RNC PoolThe RNC pool needs to be configured on both the primary RNC and the secondary RNC. The RNC node redundancy function can be used only when the RNC pool is activated on both the RNCs.
The RNC pool can be activated through the RncPoolIndex parameter in the ACT RNCPOOL command. After the activation, the RNCs can detect the status of each other through heartbeat signals.
3.2.2 NodeB Controlling in the RNC PoolIn the RNC node redundancy scheme, the NodeBs need to be configured on both the primary RNC and the secondary RNC. At the same time, however, only one RNC has the NodeB control rights because there is only one set of NodeB resources such as cells and radio links.
When both the RNCs work properly, the primary RNC has the preferential NodeB control rights.
When the primary RNC fails while the secondary RNC works properly, the secondary RNC takes over the NodeB control rights.
The RNC with the NodeB control rights manages the NodeB resources. When both the RNCs work properly, the secondary RNC does not maintain the logical resources such as cells. Instead, it only responds to the basic NBAP messages through the NCP and CCPs between the secondary RNC and each NodeB.
Issue 01 (2009-03-30) Huawei Proprietary and Confidential Copyright © Huawei Technologies
Co., Ltd
3
RANRNC Node Redundancy Description 3 RNC Node Redundancy Principles
When the primary RNC fails, the secondary RNC takes over the NodeB control rights and triggers cell setup again through the audit procedure.
The principles of message exchanging between the RNCs and the dual-homed NodeB are as follows:
Both the primary RNC and the secondary RNC can send messages to the NodeB. Upon reception of a message from one of the RNC, the NodeB responds to this RNC.
When the NodeB sends messages to the two RNCs at the same time, both respond to the NodeB.
3.3 RNC Heartbeat Detection MechanismAfter 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 parameter. Heartbeat signals can be sent to the peer RNC through the direct route over the Iur interface or the alternative routes over the Iu interface. The peer RNC regards that the local RNC is 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 ID
Parameter Name
Parameter Description
BeatSendingDis HeatBeat Sending Time Interval
This parameter specifies the 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 HeatBeat Lost Times Threshold
If the number of consecutive failures to receive heartbeat signals from the peer RNC exceeds the value of this parameter in the interval specified by the BeatSendingDis parameter, the local RNC regards that the peer RNC fails.
BeatRecvrThred
HeatBeat Recover Times Threshold
If the number of consecutive successes in receiving heartbeat signals from the peer RNC exceeds the value of this parameter in the interval specified by BeatSendingDis, the local RNC regards that the peer RNC becomes operational.
IuStatePolicyForPool
Iu State Policy For RncPool
This parameter can be set to NONE, IUCS, IUPS, or IUCS_IUPS, which are described as follows: NONE: The status of the RNC is unrelated to the status of the Iu
interface. 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 from the peer RNC for the NodeB control rights. As long as one CS domain is available, the RNC becomes available.
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 stops sending heartbeat signals to the peer RNC, and releases the NodeB control
Issue 01 (2009-03-30) Huawei Proprietary and Confidential Copyright © Huawei Technologies
Co., Ltd
4
RANRNC Node Redundancy Description 3 RNC Node Redundancy Principles
Parameter ID
Parameter Name
Parameter Description
rights after receiving the request from the peer RNC for the NodeB control rights. As long as one PS domain is available, the RNC becomes available.
IUCS_IUPS: The status of the RNC is related to the status of both the Iu-CS interface and the Iu-PS interface. If neither CS domain nor PS 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 from the peer RNC for the NodeB control rights. As 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:
The RNC fails.
When the Iu interface is faulty, the local RNC determines the status of the local RNC based on the value of IuStatePolicyForPool. If the local RNC fails, it stops sending heartbeat signals to the peer RNC.
As shown in Figure 3-2, if the number of consecutive failures to receive heartbeat signals from RNC 2 exceeds the value of BeatDectThred, RNC 1 regards that RNC 2 fails. In this case, RNC 1 takes over the NodeB control rights.
Figure 3-2 Detecting that the peer RNC fails
As shown in Figure 3-3, if the number of consecutive successes in receiving heartbeat signals from RNC 2 exceeds the value of BeatRecvrThred, RNC 1 regards that RNC 2 becomes operational. In this case, RNC 2 takes over the NodeB control rights again according to the policy specified by the ReHostPolicy parameter, and the secondary NodeB will release the
Issue 01 (2009-03-30) Huawei Proprietary and Confidential Copyright © Huawei Technologies
Co., Ltd
5
RANRNC Node Redundancy Description 3 RNC Node Redundancy Principles
NodeB control right. For details about ReHostPolicy parameter, see section "3.5 Re-homing Policy."
Figure 3-3 Detecting that the peer RNC becomes operational
3.4 Forced HomingRedundancy supported by RAN11.0 is at only the RNC level. Thus, even when the 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 HOSTNODEB command to manually switch the NodeB to the secondary RNC.
3.5 Re-homing PolicyWhen the primary RNC comes back to normal, the primary RNC will take over the NodeB control right again according to the re-homing policy specified by the ReHostPolicy parameter:
REHOSTRIGHNOW: The primary RNC immediately sends a request to the secondary RNC for the NodeB control rights.
REHOSTDELAY: The primary RNC waits for a while and then sends a request to the secondary RNC for the NodeB control rights. The delay time is specified by the Delay parameter.
REHOSTWHEN: The primary RNC does not send a request immediately to the secondary RNC for the NodeB control rights. Instead, it sends the request at the time specified by the AbsTime parameter.
Issue 01 (2009-03-30) Huawei Proprietary and Confidential Copyright © Huawei Technologies
Co., Ltd
6
RANRNC Node Redundancy Description 3 RNC Node Redundancy Principles
3.6 Application ScenariosAssume that RNC A and RNC B are grouped into an RNC pool. RNC A is installed in area A where earthquakes occur frequently, and RNC B is installed in area B where the earth's crust is stable. If RNC A serves as the primary RNC of the NodeBs and fails when an earthquake occurs in area A, RNC B takes over the NodeB control rights, and thus the NodeBs can resume the work.
Issue 01 (2009-03-30) Huawei Proprietary and Confidential Copyright © Huawei Technologies
Co., Ltd
7
RANRNC Node Redundancy Description
4 RNC Node Redundancy Parameters
4 RNC Node Redundancy
Parameters
4.1 Description
Table 4-1 RNC node redundancy parameter description
Parameter ID Description
RncPoolIndex RncPool index.
RncPoolName RncPool Name.
BeatSendingDis HeatBeat Sending Time Interval
BeatDectThred HeatBeat Sending Time Interval.
BeatRecvrThred HeatBeat Sending Time Interval.
IuStatePolicyForPool Iu State Policy For RncPool.
NrncId Neighboring RNC ID.
HostType Indicating NodeB Host Type In Disaster Recovery.
PeerRncId Indicating Peer RNC ID Of A RNCPOOL In Disaster Recovery.
PeerNodebIdIndicating Corresponding Peer NodeB ID Of The Local NodeB In A RNCPOOL In Disaster Recovery.
ReHostPolicy Re-host Policy Type.
Delay Delay Time Length In Re-host Policy.
AbsTime Specify Time In Re-host Policy.
NodebId This parameter is valid only when Adjacent Node Type is Iub.
RncPoolIndex RncPool index.
Issue 01 (2009-03-30) Huawei Proprietary and Confidential Copyright © Huawei Technologies
Co., Ltd
1
RANRNC Node Redundancy Description
4 RNC Node Redundancy Parameters
4.2 Values and Ranges
Table 4-1 RNC node redundancy parameter values and parameter ranges
Parameter ID
Default Value
GUI Value Range
Actual Value Range
Unit MML Command
NE
RncPoolIndex
- 0 0 NoneADD RNCPOOL
RNC
RncPoolName
- - 1~20 charaters NoneADD RNCPOOL
RNC
BeatSendingDis
1 1~60 1~60 sADD RNCPOOL
RNC
BeatDectThred
5 1~10 5ADD RNCPOOL
RNC
BeatRecvrThred
2 1~10 2ADD RNCPOOL
RNC
IuStatePolicyForPool
IUCS_IUPSNONE, IUCS, IUPS, IUCS_IUPS
NONE,IUCS,IUPS,IUCS_IUPS
NoneADD RNCPOOL
RNC
NrncId - 0~4095 0~4095 None
ADD NRNC(Mandatory)ADD NRNCURA(Mandatory)ADD NRNCCELL(Mandatory)ADD RNCPOOLMEMBER(Mandatory)
RNC
HostType SingleHost
SINGLEHOST(SingleHost), PRIMHOST(PrimHost), SECHOST(SecHost)
SingleHost, PrimHost, SecHost
NoneADD NODEB(Optional)
RNC
PeerRncId - 0~4095 0~4095 NoneADD NODEB(Mandatory)
RNC
PeerNodebId
- 0~65535 0~65535 NoneADD NODEB(Mandatory)
RNC
ReHostPolicy
- REHOSTRIGHNOW(RehostRighNow), REHOSTDELAY(RehostDelay),
RehostRighNow, RehostDelay, RehostWhen
None SET POOLPRIMHOSTPOLICY(Optional)
RNC
Issue 01 (2009-03-30) Huawei Proprietary and Confidential Copyright © Huawei Technologies
Co., Ltd
2
RANRNC Node Redundancy Description
4 RNC Node Redundancy Parameters
Parameter ID
Default Value
GUI Value Range
Actual Value Range
Unit MML Command
NE
REHOSTWHEN(RehostWhen)
Delay - 0~3600 0~3600 s
SET POOLPRIMHOSTPOLICY(Mandatory)
RNC
AbsTime - hour, min, sec 00:00:00~23:59:59 s
SET POOLPRIMHOSTPOLICY(Mandatory)
RNC
NodebId - 0~65535 0~65535 None
ADD ADJNODE(Mandatory)ADD NODEBIP(Mandatory)ADD NODEBESN(Mandatory)STR NODEBDETECT(Mandatory)
RNC
The Default Value column is valid for only the optional parameters.
The "-" symbol indicates no default value.
Issue 01 (2009-03-30) Huawei Proprietary and Confidential Copyright © Huawei Technologies
Co., Ltd
3
RANRNC Node Redundancy Description
4 RNC Node Redundancy Parameters
5 Reference Documents
The following lists the reference documents related to the feature:
1. Basic Feature Description of Huawei UMTS RAN11.0 V1.5
2. Optional Feature Description of Huawei UMTS RAN11.0 V1.5
Issue 01 (2009-03-30) Huawei Proprietary and Confidential Copyright © Huawei Technologies
Co., Ltd
1