BSC Node Redundancy

BSC Node Redundancy
GBSS12.0
Feature Parameter Description
Issue
01
Date
2010-06-30
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address:
Huawei Industrial Base

Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website:
http://www.huawei.com
Email:
support@huawei.com
GSM BSS
BSC Node Redundancy
Contents
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
Issue 01 (2010-06-30)
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.
GSM BSS
BSC Node Redundancy
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. (GBFD-113725 BSC Node Redundancy)
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:
01 (2010-06-30)
Draft (2010-03-30)
01 (2010-06-30)
This is the first release of GBSS12.0.
Compared with issue draft (2010-03-30) of GBSS12.0, issue 01 (2010-06-30) of GBSS12.0 incorporates
the changes described in the following table.
Change Type
Change Description
Parameter Change
Feature change
None.
None
Editorial change
Parameters are presented in the form of

Parameter ID instead of Parameter Name.
None
Issue 01 (2010-06-30)

1-1
GSM BSS
BSC Node Redundancy
Draft (2010-03-30)
This is the draft release of GBSS12.0.
Issue 01 (2010-06-30)

1-2
GSM BSS
BSC Node Redundancy
2 Overview
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.
Issue 01 (2010-06-30)

2-1
GSM BSS
BSC Node Redundancy
2 Overview
Figure 2-1 Networking diagram of BSC node redundancy

BTS
BSC
MSC
BSC
SGSN
BSC
MSC
BSC
SGSN
BTS
BTS
BTS
BTS
BTS
BTS
BTS
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.
Issue 01 (2010-06-30)

2-2
GSM BSS
BSC Node Redundancy
2 Overview
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.
LocalBSCID and PeerBSCID identify the two BSCs in a redundancy group. GROUPINDEX 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.
Issue 01 (2010-06-30)

2-3
GSM BSS
BSC Node Redundancy
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.
Issue 01 (2010-06-30)

3-1
GSM BSS
BSC Node Redundancy
Figure 3-1 IP bearer network on the Abis interface and BTS at the remote end of the IP bearer network
BSC 1
BSC 2
Router on BSC side
(Virtual) IP bearer network

Router on BTS side
Optical switcher
STM-16/64 ring
Convergence/Backbone layer
Optical transceiver
STM-1/4 ring
STM-1/4 ring
Access layer
BTS
BTS
BTS
BTS
BTS
BTS
BTS
Service data
IP over E1/T1
IP over FE/GE
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.
Issue 01 (2010-06-30)

3-2
GSM BSS
BSC Node Redundancy
Figure 3-2 IP bearer network on the Abis interface and BTS at the local end of the IP bearer network
BSC1
BSC2
Router on BSC side

Router on BTS side
BTS
BTS
BTS
Service data
BTS
BTS
IP over E1/T1
IP over FE/GE
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.
Issue 01 (2010-06-30)

3-3
GSM BSS
BSC Node Redundancy
Figure 3-3 No IP bearer network on the Abis interface

BSC 1
BSC 2
Branch router
Router
Optical switcher
STM-16/64 ring
Convergence/Backbone layer
Optical transceiver
STM-1/4 ring
STM-1/4 ring
Access layer
BTS
BTS
BTS
BTS
BTS
BTS
BTS
Service data
IP over E1/T1
IP over FE/GE
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.
Issue 01 (2010-06-30)

3-4
GSM BSS
BSC Node Redundancy
Figure 3-4 FE/GE Ethernet as the IP bearer network

MGW
MSC server
Router on MSC side

Router on BSC side
BSC
BSC
IP over FE/GE
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

MGW
MSC server
Optical switcher
SDH/PDH
network
BSC
BSC
IP over E1/T1
Issue 01 (2010-06-30)

3-5
GSM BSS
BSC Node Redundancy
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
MGW
MSC server
Router
BSC 1
BSC 2
Direct route
Alternative route
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 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 BEATSENDINGDIS.
When one of the following conditions is met, it indicates that the local BSC is faulty and the local BSC
stops sending heartbeat signals to the peer BSC:
The local BSC is faulty.
The local BSC detects that the duration of the failure of all the signaling links on the A interface
exceeds CNFAULTDELAY.
Issue 01 (2010-06-30)

3-6
GSM BSS
BSC Node Redundancy
When the peer BSC detects that the disruption time of heartbeat signal transmission exceeds
MSTSERVACTDELAY or SLVSERVACTDELAY, 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, HOSTTYPE of an OPC determines whether
the local BSC takes over the OPC.
If HOSTTYPE of an OPC is set to PRIMHOST(PRIMHOST), the OPC immediately provides services

and the Hosted state of the OPC is YES.
If HOSTTYPE of an OPC is set to SLAVEHOST(SLAVEHOST), the OPC does not provide services
and the Hosted state of the OPC is NO
If HOSTTYPE 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.
For a network topology in BSC node redundancy mode, the following parameters of the dual-homed
BTSs of the local BSC should be set: PEERBTSID, PEERBSCIP, PeerBSCID, and PEERBSCMASK.
The values of these parameters are sent by the local BSC to the BTSs.
Issue 01 (2010-06-30)

3-7
GSM BSS
BSC Node Redundancy
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
REHOSTTYPE:
If REHOSTTYPE is set to REHOSTRIGHTNOW(ReHostRightNow), service objects switch back to

the local BSC immediately after the local BSC becomes normal.
If REHOSTTYPE 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 REHOSTTYPE is set to REHOSTWHEN(ReHostWhen), service objects switch back to the local

BSC at the time specified by REHOSTABSTIME after the local BSC becomes normal.
REHOSTABSTIME 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.
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.
Issue 01 (2010-06-30)

3-8
GSM BSS
BSC Node Redundancy
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 MSTSERVACTDELAY and SLVSERVACTDELAY
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.
Issue 01 (2010-06-30)

3-9
GSM BSS
BSC Node Redundancy
4 Engineering Guidelines
4 Engineering Guidelines
A redundancy group consists of only two BSCs and both 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.
Issue 01 (2010-06-30)

4-1
GSM BSS
BSC Node Redundancy
5 Parameters
5 Parameters
Table 5-1 Parameters Description
Parameter ID
NE
MML Command
Description
LocalBSCID
Meaning: ID of the local BSC in the BSC node

BSC6900 SET
GBSCREDGRP(M redundancy group.
andatory)
GUI Value Range: 0~65534
Actual Value Range: 0~65534
Unit: None
Default Value: None
PEERBSCID
Meaning: ID of the peer BSC

BSC6900 SET
BTSIP(Mandatory)
Unit: None
Default Value: None
PeerBSCID
Meaning: ID of the peer BSC in the BSC node

BSC6900 SET
GBSCREDGRP(M redundancy group.
andatory)
Unit: None
Default Value: None
GROUPINDEX
Meaning: Index of the BSC Node Redundancy Group.

BSC6900 SET
GBSCREDGRP(M It identifies a BSC redundancy group. The BSC node
andatory)
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.
Unit: None
Default Value: None
BEATSENDINGD BSC6900 SET

Meaning: Time interval for sending a handshake
IS
GBSCREDGRP(O message between BSCs. The parameter checks
ptional)
whether the communication among BSCs in a
redundancy group is normal.
Unit: s
Default Value: 1
Issue 01 (2010-06-30)

5-1
GSM BSS
BSC Node Redundancy
Parameter ID
NE
5 Parameters
MML Command
Description
Meaning: Time delay in the detection of core network

CNFAULTDELAY BSC6900 SET
GBSCREDGRP(O interface failure. Within the preset value of this
ptional)
parameter, the BSC continuously detects core network
interface failures and then releases the management
right of service objects.
Unit: s
Default Value: 30
MSTSERVACTD BSC6900 SET
Meaning: If no handshake message is received from
ELAY
GBSCREDGRP(O the peer within the delay, the master service is
ptional)
activated. A master service object provides services at
the local BSC and its configuration data is backed up at
the peer BSC. A master 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.
Unit: s
Default Value: 45
SLVSERVACTDE BSC6900 SET
Meaning: If no handshake message is received from
LAY
GBSCREDGRP(O the peer within the delay, the slave service is activated.
ptional)
A slave service object provides services at the peer
BSC and its configuration data is backed up at the local
BSC. A slave 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.
Unit: s
Default Value: 300
HOSTTYPE
BSC6900 SET
BTSIP(Optional)
Meaning: Host type of an IP BTS

GUI Value Range: SINGLEHOST(Single Host),
PRIMHOST(Primary Host), SLAVEHOST(Slave Host)
Actual Value Range: SINGLEHOST, PRIMHOST,
SLAVEHOST
Unit: None
Default Value: SINGLEHOST
Issue 01 (2010-06-30)

5-2
GSM BSS
BSC Node Redundancy
5 Parameters
Parameter ID
NE
MML Command
HOSTTYPE
BSC6900 ADD
OPC(Optional)
MOD
OPC(Optional)
Description
Meaning: This parameter indicates the host type of the
signalling point.
When the BSC node redundancy feature is enabled,
the primary BSC and the secondary BSC each must be
configured with a signaling point coded in the same
mode. The host type of the signaling point of the
primary BSC is set to "PRIMHOST", and the host type
of the signaling point of the secondary BSC is set to
"SLAVEHOST". When the BSC node redundancy
feature is disabled, the host type of the signaling point
of the BSC is set to "SINGLEHOST".
GUI Value Range: SINGLEHOST(SINGLEHOST),
PRIMHOST(PRIMHOST),
SLAVEHOST(SLAVEHOST)
Actual Value Range: SINGLEHOST, PRIMHOST,
SLAVEHOST
Unit: None
Default Value: SINGLEHOST
PEERBTSID
Meaning: Identifier of the peer BTS on the homing BSC

BSC6900 SET
BTSIP(Mandatory) side
Unit: None
Default Value: None
PEERBSCIP
Meaning: IP address of the peer BSC on the homing

BSC6900 SET
BTSIP(Mandatory) BSC side
GUI Value Range: None
Actual Value Range: 0.0.0.0~255.255.255.255
Unit: None
Default Value: None
Meaning: Subnet mask of the port IP address at the

PEERBSCMASK BSC6900 SET
BTSIP(Mandatory) peer BSC.
GUI Value Range: None
Actual Value Range: 0.0.0.0~255.255.255.255
Unit: None
Default Value: None
REHOSTTYPE
Meaning: Policy type of re-homing

BSC6900 SET
GREDGRPPRIMH
OSTPOLICY(Mand GUI Value Range:
atory)
REHOSTRIGHTNOW(ReHostRightNow),
REHOSTDELAY(ReHostDelay),
REHOSTWHEN(ReHostWhen)
Actual Value Range: REHOSTRIGHTNOW,
REHOSTDELAY, REHOSTWHEN
Unit: None
Default Value: REHOSTDELAY
Issue 01 (2010-06-30)

5-3
GSM BSS
BSC Node Redundancy
Parameter ID
NE
5 Parameters
MML Command
Description
REHOSTDELAYT BSC6900 SET

Meaning: Delay time of re-homing
IME
GREDGRPPRIMH
OSTPOLICY(Mand GUI Value Range: 1~3600
atory)
Unit: s
Default Value: 600
Issue 01 (2010-06-30)

5-4
GSM BSS
BSC Node Redundancy
6 Counters
6 Counters
None.
Issue 01 (2010-06-30)

6-1
GSM BSS
BSC Node Redundancy
7 Glossary
7 Glossary
For the acronyms, abbreviations, terms, and definitions, see the Glossary.
Issue 01 (2010-06-30)

7-1
GSM BSS
BSC Node Redundancy
8 Reference Documents
8 Reference Documents
[1] BSC6900 Feature List
[2] BSC6900 Optional Feature Description
[3] GBSS Reconfiguration Guide
[4] BSC6900 GSM Parameter Reference
[5] BSC6900 GSM MML Command Reference
Issue 01 (2010-06-30)

8-1

BSC Node Redundancy

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

BSC Node Redundancy

Caricato da

Copyright:

Formati disponibili

BSC Node Redundancy

Feature Parameter Description

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

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

Huawei Proprietary and Confidential

1 Introduction to This Document

1 Introduction to This Document

1.2 Intended Audience

Personnel working on Huawei GSM products or systems

System operators who need a general understanding of this feature

1.3 Change History

Parameters are presented in the form of

Huawei Proprietary and Confidential

1 Introduction to This Document

Huawei Proprietary and Confidential

Huawei Proprietary and Confidential

Figure 2-1 Networking diagram of BSC node redundancy

Failure in the signaling links on the A interface

Huawei Proprietary and Confidential

Improved device reliability

Improved transmission reliability

Huawei Proprietary and Confidential

3.1.1 Network Topologies on the Abis Interface

Huawei Proprietary and Confidential

Router on BSC side

(Virtual) IP bearer network

Huawei Proprietary and Confidential

Router on BSC side

(Virtual) IP bearer network

Huawei Proprietary and Confidential

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

3.1.2 Network Topologies on the A and Gb Interfaces

Network topology 1: The bearer network on the A interface is an FE/GE Ethernet.

Huawei Proprietary and Confidential

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

Router on MSC side

(Virtual) IP bearer network

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

Huawei Proprietary and Confidential

3.1.3 Network Topology on the Inter-BSC Interface

3.2 Fault Detection

The local BSC is faulty.

Huawei Proprietary and Confidential

3.3 Migration of Service Objects

3.3.1 Dual-Homed OPCs

If HOSTTYPE of an OPC is set to PRIMHOST(PRIMHOST), the OPC immediately provides services

If HOSTTYPE of an OPC is set to SINGLEHOST(SINGLEHOST), the OPC immediately provides

3.3.2 Dual-Homed BTSs

Huawei Proprietary and Confidential

3.3.3 Dual-Homed Cells and PTP BVC Objects

3.3.4 Re-Homing Policy of Dual-Homed Service Objects

If REHOSTTYPE is set to REHOSTRIGHTNOW(ReHostRightNow), service objects switch back to

If REHOSTTYPE is set to REHOSTDELAY(ReHostDelay), service objects wait for a period specified

If REHOSTTYPE is set to REHOSTWHEN(ReHostWhen), service objects switch back to the local

3.4 Audit of Dual-Homed Service Objects

Huawei Proprietary and Confidential

3.5 Maintenance of Dual-Homed Service Objects

Huawei Proprietary and Confidential

Huawei Proprietary and Confidential

Meaning: ID of the local BSC in the BSC node