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 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.



mailto:[email protected]

http://www.huawei.com/

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


v


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



vii


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


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:



1


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



2

RANRNC Node Redundancy Description 3 RNC Node Redundancy Principles


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


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.


Co., Ltd

2


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.


Co., Ltd

3


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


Co., Ltd

4


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


Co., Ltd

5


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.


Co., Ltd

6


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.


Co., Ltd

7


4 RNC Node Redundancy Parameters


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.


Co., Ltd

1



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


Co., Ltd

2



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.


Co., Ltd

3



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


Co., Ltd

1