BSC Node Redundancy

BSC Node Redundancy Feature Parameter Description

Copyright © Huawei Technologies Co., Ltd. 2010. 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.

Issue 02 (2009-09-30) Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

i

BSS BSC Node Redundancy Contents

Issue 02 (2009-09-30) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co.,

Ltd.

iii

Contents 1 Introduction to This Document .............................................................................................1-1

1.1 Scope ............................................................................................................................................ 1-1 1.2 Intended Audience ........................................................................................................................ 1-1 1.3 Change History.............................................................................................................................. 1-1

2 Overview .....................................................................................................................................2-1

3 Technical Description ..............................................................................................................3-1 3.1 Network Topologies ....................................................................................................................... 3-1

3.1.1 Network Topologies on the Abis Interface ............................................................................ 3-1 3.1.2 Network Topologies on the A and Gb Interfaces .................................................................. 3-4 3.1.3 Network Topology on the Inter-BSC Interface...................................................................... 3-6

3.2 Fault Detection .............................................................................................................................. 3-6 3.3 Migration of Service Objects ......................................................................................................... 3-7

3.3.1 Dual-Homed OPCs............................................................................................................... 3-7 3.3.2 Dual-Homed BTSs................................................................................................................ 3-7 3.3.3 Dual-Homed Cells and PTP BVC Objects............................................................................ 3-8 3.3.4 Re-Homing Policy of Dual-Homed Service Objects ............................................................. 3-8

3.4 Audit of Dual-Homed Service Objects........................................................................................... 3-8 3.5 Maintenance of Dual-Homed Service Objects .............................................................................. 3-9

4 Engineering Guidelines...........................................................................................................4-1

5 Parameters .................................................................................................................................5-1

6 Counters......................................................................................................................................6-1

7 Glossary ......................................................................................................................................7-1

8 Reference Documents .............................................................................................................8-1

BSS BSC Node Redundancy 1 Introduction to This Document


Ltd.

1-1

1 Introduction to This Document 1.1 Scope This document describes BSC node redundancy of Huawei GBSS. It covers the function of and technology mechanisms regarding BSC node redundancy, including network topologies, fault detection betwwen BSCs, migration of service objects, audit of dual-homed service objects, and maintenance of dual-homed service objects.

1.2 Intended Audience It is assumed that users of this document are familiar with GSM basics and have a working knowledge of GSM telecommunication.

This document is intended for:

Personnel working on Huawei GSM products or systems System operators who need a general understanding of this feature

1.3 Change History The change history provides information on the changes in different document versions.

There are two types of changes, which are defined as follows:

Feature change Feature change refers to the change in the BSC node redundancy feature of a specific product version.

Editorial change Editorial change refers to the change in wording or the addition of the information that was not described in the earlier version.

Document Issues The document issues are as follows:

02 (2009-09-30) 01 (2009-06-30)

02 (2009-09-30) This is the second commercial release of GBSS9.0.

Compared with issue 01 (2009-06-30) of GBSS9.0, issue 02 (2009-09-30) of GBSS9.0 incorporates the changes described in the following table.

Change Type Change Description Parameter Change

Feature change

None. None.

Editorial change

The structure of the document isoptimized.

None.

1 Introduction to This Document BSS

BSC Node Redundancy

1-2 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co.,

Ltd.

Issue 02 (2009-09-30)

01 (2009-06–30) This is the first commercial release of GBSS9.0.

BSS BSC Node Redundancy 2 Overview


Ltd.

2-1

2 Overview A BSC controls the radio resources of all the BTSs under the BSC. When the BSC is faulty, none of the BTSs under the BSC can access the network because the BSC cannot provide services in its coverage area. Similarly, if the transmission links between the BSC and the core network (CN) are faulty, the BSC is not operational and thus the BSC cannot provide services in its coverage area. To prevent the occurrence of the preceding situations, Huawei provides a BSC node redundancy solution at the BSC level.

The BSC node redundancy is a function through which two BSCs form a redundancy group. The two BSCs in a redundancy group work in 1+1 load sharing mode. When one BSC in a redundancy group is faulty or all the signaling links on the A interface are faulty, the other BSC in this group takes over the voice and data services. In this manner, the reliability and robustness of the network are improved, the service disruption time due to BSC failure is reduced, and the quality of service (QoS) is improved.

In a redundancy group, each of the two BSCs considers itself as the local BSC and the other as the peer BSC. A service object may be an originating signaling point code (OPC), BTS, cell, neighboring cell, or point-to-point BSSGP virtual connection (PTP BVC).

Normally, a primary service object provides services at the local BSC (the primary BSC) and its configuration data is backed up at the peer BSC (the secondary BSC). A primary service object provides services at the peer BSC only when the local BSC is faulty or when all the signaling links on the A interface of the local BSC are faulty.

Similarly, a secondary service object provides services at the peer BSC and its configuration data is backed up at the local BSC. A secondary service object provides services at the local BSC only when the peer BSC is faulty or when all the signaling links on the A interface of the peer BSC are faulty.

The primary service object and the secondary service object are collectively called dual-homed service objects. A single-homed service object exists only at one BSC in a redundancy group.

Each BSC in a redundancy group backs up the configuration data of the primary service objects of the other BSC. Normally, each BSC controls its primary service objects and backs up the configuration data of its secondary service objects. When one BSC is faulty, the other BSC can detect the failure automatically. Then, it makes the backup configuration data of the secondary service objects take effect and takes over the services from the faulty BSC. The backup configuration data includes the information about OPCs, BTSs, and cells.

Figure 2-1 shows the networking diagram of BSC node redundancy.

2 Overview BSS

BSC Node Redundancy


Ltd.

Issue 02 (2009-09-30)

Figure 2-1 Networking diagram of BSC node redundancy

BSC node redundancy can be implemented only in an all-IP networking scenario, that is, IP transmission is used on the A, Abis, Gb, and inter-BSC interfaces. The inter-BSC interface is a fault detection and audit channel between the two BSCs in a redundancy group. If the peer BSC detects through the inter-BSC interface that the local BSC is faulty, the peer BSC takes over the control rights of the dual-homed service objects from the local BSC. The service objects that are taken over include OPCs, BTSs, cells, and PTP BVCs.

BSC node redundancy is applicable to the following scenarios:

BSC failure All the boards of a BSC are faulty or all the A interface boards of a BSC are faulty.

Failure in the signaling links on the A interface All the signaling links on the A interface are faulty.

BSS BSC Node Redundancy 2 Overview


Ltd.

2-3

The MML commands ACT GBSCREDGRP and DEA GBSCREDGRP can be executed at the local BSC or peer BSC to enable and disable the BSC node redundancy function respectively.

Local BSC ID and Peer BSC ID identify the two BSCs in a redundancy group. BSC Node Redundancy Group Index identifies a redundancy group.

The benefits of the BSC node redundancy feature are as follows:

Improved device reliability The BSCs in a redundancy group work in 1+1 load sharing mode. When one BSC in a redundancy group is faulty, the other BSC immediately takes over the services of the faulty BSC. In this manner, the device reliability is improved without reduction of the system capacity.

Improved transmission reliability Cross connections are established between the two BSCs in a redundancy group and the CN. The A interface of one BSC provides redundancy for the A interface of the other BSC in the case that all the signaling links on the A interface of the other BSC are faulty. In this manner, the reliability of the network is improved.

BSS BSC Node Redundancy 3 Technical Description


Ltd.

3-1

3 Technical Description 3.1 Network Topologies BSC node redundancy is applicable only to an all-IP networking scenario. In such a scenario, IP transmission is used on the A, Abis, Gb, and inter-BSC interfaces.

3.1.1 Network Topologies on the Abis Interface A dual-homed BTS can be connected to the primary and secondary BSCs through IP routers according to the IP addresses.

Three network topologies are applicable to the Abis interface.

Network topology 1: The telecom operator has an IP bearer network on the Abis interface, and the BTS is located at the remote end of the IP bearer network. The BTS is connected to an optical transceiver in IP over E1/T1 transmission mode. The BSC is connected to the border router on the BSC side in IP over FE/GE transmission mode. Then, the border router on the BTS side is connected to the primary and secondary BSCs according to the IP addresses. See Figure 3-1.

3 Technical Description BSS

BSC Node Redundancy


Ltd.

Issue 02 (2009-09-30)

Figure 3-1 IP bearer network on the Abis interface and BTS at the remote end of the IP bearer network

Network topology 2: The telecom operator has an IP bearer network on the Abis interface, and the BTS is located at the local end of the IP bearer network. The BTS is connected to the border router on the BTS side in IP over E1/T1 or IP over FE/GE transmission mode. The BSC is connected to the border router on the BSC side in IP over FE/GE transmission mode. Then, the border router on the BTS side is connected to the primary and secondary BSCs according to the IP addresses. See Figure 3-2.



Ltd.

3-3

Figure 3-2 IP bearer network on the Abis interface and BTS at the local end of the IP bearer network

Network topology 3: The telecom operator does not have an IP bearer network on the Abis interface. In this scenario, a branch router is required to implement the IP network topology on the Abis interface. The BTS is connected to an optical transceiver in IP over E1/T1 transmission mode. The BSC is connected to the router on the BSC side in IP over FE/GE transmission mode. Then, the intermediate branch router is connected to the primary and secondary BSCs according to the IP addresses. See Figure 3-3. To prevent a single-point failure in the transmission network, the intermediate branch router should support redundancy backup, and the intermediate branch router and the router on the BSC side should be placed in different geographical locations. This ensures that the redundancy function is operational even if an intermediate branch router is faulty.


BSC Node Redundancy


Ltd.

Issue 02 (2009-09-30)

Figure 3-3 No IP bearer network on the Abis interface

3.1.2 Network Topologies on the A and Gb Interfaces The two BSCs in a redundancy group can be connected to the NEs in the CN through the A and Gb interfaces according to the IP addresses.

The network topology on the A interface is similar to that on the Gb interface. The following takes the A interface as an example to describe the network topologies.

Two network topologies are applicable to the A interface.

Network topology 1: The bearer network on the A interface is an FE/GE Ethernet. The BSC is connected to the border router on the BSC side in IP over FE/GE transmission mode. The MSC is connected to the border router on the MSC side in IP over FE/GE transmission mode. Cross connections are established between the BSCs in a redundancy group and the CN. See Figure 3-4.



Ltd.

3-5

Figure 3-4 FE/GE Ethernet as the IP bearer network

Network topology 2: The bearer network on the A interface is an SDH or a PDH network. The BSC is connected to the CN through an optical transceiver in IP over E1/T1 transmission mode. See Figure 3-5.

Figure 3-5 SDH or PDH network as the IP bearer network


BSC Node Redundancy


Ltd.

Issue 02 (2009-09-30)

3.1.3 Network Topology on the Inter-BSC Interface The BSCs in a redundancy group are connected to each other through IP routers. The routes on the inter-BSC interface are of two types: direct route between BSCs in a redundancy group and alternative routes that pass through the routers on the MSC side. Alternative routers help to improve the reliability of inter-BSC fault detection. See Figure 3-6.

Figure 3-6 Routes on the inter-BSC interface

The inter-BSC interface is used for two purposes: heartbeat detection and exchange of the information about dual-homed BTSs between the BSCs in a redundancy group.

The FG2a/FG2c board should be added to the BSC. This board is used to carry the inter-BSC communication links on the inter-BSC interface.

3.2 Fault Detection Fault detection is implemented between two BSCs by checking for the heartbeat signals from the peer end. The information contained in the heartbeat signals includes local BSCID, homing states of the primary service objects, and homing states of the secondary service objects.

The heartbeat signals are carried by the signaling channels on the inter-BSC interface. One signaling channel corresponds to one SCTP channel using IP transmission.

Each BSC in a redundancy group sends heartbeat signals to the peer BSC at regular intervals specified by Interval for Sending Heartbeat.

When one of the following conditions is met, it is regarded that the local BSC is faulty and the local BSC stops sending heartbeat signals to the peer BSC:

The local BSC is faulty.



Ltd.

3-7

The local BSC detects that the duration of the failure of all the signaling links on the A interface exceeds CN Fault Delay.

When the peer BSC detects that the disruption time of heartbeat signal transmission exceeds Master Service Active Delay or Slave Service Active Delay, the peer BSC considers that the local BSC cannot provide services. Then, the peer BSC takes over the primary service objects from the faulty BSC.

3.3 Migration of Service Objects In normal conditions, the two BSCs in a redundancy group manage their own primary service objects.

When the local BSC fails to provide services, the peer BSC takes over the control rights of the dual-homed service objects from the local BSC but does not take over the control rights of single-homed service objects from the local BSC. The sequence of taking over the control rights is as follows: Firstly, the control rights of dual-homed OPCs are taken over. Then, the control rights of the dual-homed BTSs and cells corresponding to the dual-homed OPCs are taken over.

If the BSC node redundancy function is disabled after control rights are taken over, the peer BSC automatically releases the control rights of the secondary service objects. The local BSC takes over the control rights of the primary service objects again.

3.3.1 Dual-Homed OPCs When the local BSC in a redundancy group works properly, The host type of signalling point of an OPC determines whether the local BSC takes over the OPC.

If The host type of signalling point of an OPC is set to PRIMHOST(PRIMHOST), the OPC immediately provides services and the Hosted state of the OPC is YES.

If The host type of signalling point of an OPC is set to SLAVEHOST(SLAVEHOST), the OPC does not provide services and the Hosted state of the OPC is NO

If The host type of signalling point of an OPC is set to SINGLEHOST(SINGLEHOST), the OPC immediately provides services and the Hosted state of the OPC is YES.

When the local BSC in a redundancy group cannot provide services, the single-homed OPCs of the local BSC cannot provide services either and they become faulty. The peer BSC takes over the dual-homed OPCs from the local BSC. That is, the Hosted state of the secondary OPCs of the peer BSC is changed from NO to YES, and the secondary OPCs of the peer BSC are immediately activated and provide services.

3.3.2 Dual-Homed BTSs After dual-homed OPCs are taken over, the dual-homed BTSs corresponding to the dual-homed OPCs are taken over.

When the local BSC in a redundancy group works properly, HostType of a BTS determines whether the local BSC takes over the BTS.

If HostType of a BTS is set to PRIMHOST(PRIMHOST), the BTS provides services and the Hosted state of the BTS is Yes.

If HostType of a BTS is set to SLAVEHOST(SLAVEHOST), the BTS does not provide services and the Hosted state of the BTS is No.

If HostType of a BTS is set to SINGLEHOST(SINGLEHOST), the BTS provides services and the Hosted state of the BTS is Yes.


BSC Node Redundancy


Ltd.

Issue 02 (2009-09-30)

For a network topology in BSC node redundancy mode, the following parameters of the dual-homed BTSs of the local BSC should be set: Peer BTS ID, Peer BSC IP, Peer BSC ID, and Peer BSC Mask. The values of these parameters are sent by the local BSC to the BTSs.

When the local BSC cannot provide services, the single-homed BTSs of the local BSC do not provide services either and they become faulty; the Hosted state of the secondary BTSs of the peer BSC is changed from No to Yes; the peer BSC takes over the primary BTSs of the local BSC.

The procedure for taking over the BTSs from the local BSC is as follows:

1. When the local BSC is faulty, the signaling link between the local BSC and its primary BTS is faulty. 2. According to the IP address of the peer BSC sent by the local BSC, the primary BTS sends a link

establishment request to the peer BSC. 3. After the link between the peer BSC and the primary BTS of the local BSC is established, the peer

BSC sends a reset command to the BTS. 4. After the BTS is reset, it sends a DHCP request to the peer BSC. The peer BSC sends the BTS a

DHCP response message. The message carries the IP address allocated to the BTS and the IP address of the peer BSC.

5. After receiving the two IP addresses, the BTS sends a signaling link establishment request to the peer BSC.

6. After the signaling link is established, the peer BSC sends the related configuration data to the BTS. Then, the BTS is taken over by the peer BSC and starts providing services.

3.3.3 Dual-Homed Cells and PTP BVC Objects The homing attributes of the dual-homed OPCs, BTSs, and cells of a BSC in a redundancy group are the same. Therefore, after a dual-homed BTS is taken over by a BSC, the dual-homed cells under the BTS are automatically taken over by the BSC.

The homing attributes of PTP BVC objects are the same as those of dual-homed cells. Therefore, after the dual-homed cells under a BTS are taken over by a BSC, the dual-homed PTP BVC objects under the BTS are automatically taken over by the BSC.

3.3.4 Re-Homing Policy of Dual-Homed Service Objects When the local BSC in a redundancy group is faulty, the peer BSC takes over the primary service objects from the local BSC. When the local BSC becomes normal, the service objects that are taken over by the peer BSC can switch back to the local BSC according to the re-homing policy specified by ReHost Type:

If ReHost Type is set to REHOSTRIGHTNOW(ReHostRightNow), service objects switch back to the local BSC immediately after the local BSC becomes normal.

If ReHost Type is set to REHOSTDELAY(ReHostDelay), service objects wait for a period specified by ReHostDelayTime after the local BSC becomes normal and then switch back to the local BSC.

If ReHost Type is set to REHOSTWHEN(ReHostWhen), service objects switch back to the local BSC at the time specified by ReHost Absolute Time after the local BSC becomes normal. ReHost Absolute Time must be set in the format of hh:mm:ss.

The procedure for switching back service objects is similar to the procedure for switching the service objects from a faulty BSC to a normal BSC, except the switching is performed in the reverse direction.

3.4 Audit of Dual-Homed Service Objects When the two BSCs in a redundancy group work properly, they regularly audit the homing attributes of BTSs and the homing states of service objects of each other.



Ltd.

3-9

When a BSC detects that the homing attributes of a BTS at the two BSCs are inconsistent, a Dual-Hosted BTS Configuration Error alarm is generated.

When a BSC detects that the homing states of a service object at the two BSCs are inconsistent, the following processing may be performed as required:

If the Hosted state of a service object at both the primary and secondary BSCs is No, the primary and secondary BSCs wait for the periods specified by Master Service Active Delay and Slave Service Active Delay respectively. Then, the control rights negotiation procedure is initiated to determine which BSC can obtain the control rights of the service object.

If the Hosted state of a service object at both the primary and secondary BSCs is Yes, the primary BSC immediately takes over the control rights of the service object, and the secondary BSC does not take over the control rights of the service object.

3.5 Maintenance of Dual-Homed Service Objects A service object is managed by only one BSC at a time. After the control rights of a dual-homed service object are switched from the local BSC to the peer BSC, the local BSC cannot maintain the service object. Therefore, a BSC can maintain the service object whose Hosted state is Yes. This service object can be a primary or secondary service object of the BSC.

BSS BSC Node Redundancy 4 Engineering Guidelines


Ltd.

4-1

4 Engineering Guidelines A redundancy group consists of only two BSCs and the two BSCs work in 1+1 backup mode.

Each BSC in a redundancy group is configured with dual-homed service objects. The sum of the number of single-homed service objects and the number of dual-homed service objects at each BSC cannot exceed the capacity specification of the BSC.

The two BSCs in a redundancy group must be connected to the same MSC or MSC pool.

The two BSCs in a redundancy group must be connected to the same SGSN or SGSN pool.

When service objects are switched or switched back from one BSC to another, services are disrupted.

BSC node redundancy is applicable only to an all-IP networking scenario. In such a scenario, IP transmission is used on the A, Abis, Gb, and inter-BSC interfaces.

A BTS cannot be directly connected to a BSC in a redundancy group in IP over E1/T1 or IP over FE/GE transmission mode. That is, the BTS must be connected to a BSC in a redundancy group through routers.

A transmission failure on the Abis interface does not trigger the switching of services from one BSC to the other BSC in a redundancy group.

The cell broadcast center (CBC) service does not support BSC node redundancy.

The built-in PCU supports BSC node redundancy, whereas the external PCU does not.

During the upgrade of a BSC, BSC node redundancy should be disabled.

BSS BSC Node Redundancy 5 Parameters


Ltd.

5-1

5 Parameters This chapter describes the parameters related to BSC node redundancy.

For the meaning of each parameter, see Table 5-1. For the default value, value ranges, and MML commands of each parameter, see Table 5-2.

Table 5-1 Parameter description (1)

Parameter Description

Local BSC ID Local BSC identity.

Peer BSC ID Peer BSC identity.

BSC Node Redundancy Group Index Index of the BSC Node Redundancy Group.

Interval for Sending Heartbeat

Time interval for sending a handshake message between BSC6900s.

CN Fault Delay

Time delay of the detection on core network interface failure. Within the preset value of this parameter, the BSC6900 continuously detects core network interface failures and then releases the management right of service objects.

Master Service Active Delay If no handshake message is received from the peer within the delay, the master service is activated.

Slave Service Active Delay If no handshake message is received from the peer within the delay, the slave service is activated.

The host type of signalling point Host type of signaling point.

HostType Host type of an IP BTS

Peer BTS ID Identifier of the peer BTS on the home BSC6900 side

Peer BSC IP IP address of the peer BSC6900 on the home BSC6900 side

Peer BSC Mask IP subnet mask of the peer BSC6900 port

ReHost Type Policy type of re-homing

ReHostDelayTime Delay time of re-homing

ReHost Absolute Time Absolute time of re-homing

5 Parameters BSS

BSC Node Redundancy


Ltd.

Issue 02 (2009-09-30)

Table 5-2 Parameter description (2)

Parameter Default Value

GUI Value Range

Actual Value Range Unit MML Command Impa

ct

Local BSC ID None 0~65534 0~65534 None

SET GBSCREDGRP (Mandatory) BSC

Peer BSC ID None 0~65534 0~65534 None


BSC Node Redundancy Group Index None 0~65534 0~65534 None


Interval for Sending Heartbeat 1 1~60 1~60 s

SET GBSCREDGRP (Optional) BSC

CN Fault Delay 30 1~60 1~60 s

SET GBSCREDGRP (Optional) Cell

Master Service Active Delay 45 1~600 1~600 s


Slave Service Active Delay 300 1~600 1~600 s


The host type of signalling point

SINGLEHOST

SINGLEHOST(SINGLEHOST), PRIMHOST(PRIMHOST), SLAVEHOST(SLAVEHOST)

SINGLEHOST, PRIMHOST, SLAVEHOST None

ADD OPC (Optional) SCCP

HostType SINGLEHOST

SINGLEHOST(Single Host), PRIMHOST(Primary Host), SLAVEHOST(Slave Host)

SINGLEHOST, PRIMHOST, SLAVEHOST None

SET BTSIP (Optional) BTS

Peer BTS ID None 0~2047 0~2047 None SET BTSIP (Mandatory) BTS

Peer BSC IP None None 0.0.0.0~255.255.255.255 None

SET BTSIP (Mandatory) BTS

Peer BSC Mask None None

0.0.0.0~255.255.255.255 None

SET BTSIP (Mandatory) BTS

BSS BSC Node Redundancy 5 Parameters


Ltd.

5-3

Default GUI Value Actual Value ImpaParameter Unit MML CommandValue Range Range ct

ReHost Type REHOSTDELAY

REHOSTRIGHTNOW(ReHostRightNow), REHOSTDELAY(ReHostDelay), REHOSTWHEN(ReHostWhen)

REHOSTRIGHTNOW, REHOSTDELAY, REHOSTWHEN None

SET GREDGRPPRIMHOSTPOLICY (Mandatory) Cell

ReHostDelayTime 600 1~3600 1~3600 s


ReHost Absolute Time None hour, min, sec

00:00:00~23:59:59 None


BSS BSC Node Redundancy 6 Counters


Ltd.

6-1

6 Counters None.

BSS BSC Node Redundancy 7 Glossary


Ltd.

7-1

7 Glossary For the acronyms, abbreviations, terms, and definitions, see the Glossary.

BSS BSC Node Redundancy 8 Reference Documents


Ltd.

8-1

8 Reference Documents BSC6900 Feature List BSC6900 Optional Feature Description GBSS Reconfiguration Guide BSC6900 GSM Parameter Reference BSC6900 GSM MML Command Reference

BSC Node Redundancy

Documents

Transcript of BSC Node Redundancy