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.
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 02 (2009-09-30)

Ltd.
iii
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.
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:
z
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:
z
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:
z
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 is None.

optimized.
Issue 02 (2009-09-30)

Ltd.
1-1
BSS
BSC Node Redundancy
01 (2009-0630)
This is the first commercial release of GBSS9.0.
1-2

Ltd.
Issue 02 (2009-09-30)
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).
z
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 02 (2009-09-30)

Ltd.
2-1
BSS
BSC Node Redundancy
2 Overview
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:
z
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.
2-2

Ltd.
Issue 02 (2009-09-30)
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.
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:
z
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 02 (2009-09-30)

Ltd.
2-3
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.
z
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 02 (2009-09-30)

Ltd.
3-1
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
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.
3-2

Ltd.
Issue 02 (2009-09-30)
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
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 02 (2009-09-30)

Ltd.
3-3
BSS
BSC Node Redundancy
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.
z
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.
3-4

Ltd.
Issue 02 (2009-09-30)
BSS
BSC Node Redundancy
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
Issue 02 (2009-09-30)

Ltd.
3-5
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
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:
z
The local BSC is faulty.
3-6

Ltd.
Issue 02 (2009-09-30)
BSS
BSC Node Redundancy
z
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.
z
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.
z
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.
Issue 02 (2009-09-30)

Ltd.
3-7
BSS
BSC Node Redundancy
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:
z
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.
3-8

Ltd.
Issue 02 (2009-09-30)
BSS
BSC Node Redundancy
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:
z
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.
Issue 02 (2009-09-30)

Ltd.
3-9
BSS
BSC Node Redundancy
4 Engineering Guidelines
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.
Issue 02 (2009-09-30)

Ltd.
4-1
BSS
BSC Node Redundancy
5 Parameters
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.
If no handshake message is received from the peer

Master Service Active Delay 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
Issue 02 (2009-09-30)

Ltd.
5-1
BSS
BSC Node Redundancy
5 Parameters
Table 5-2 Parameter description (2)

Parameter
Default GUI Value

Value Range
Local BSC ID None
Peer BSC ID None

BSC Node
Redundancy
Group Index None
Interval for
Sending
Heartbeat
CN Fault
Delay
30
Master
Service
Active Delay 45
Slave
Service
Active Delay 300
0~65534
0~65534
0~65534
1~60
1~60
1~600
1~600
Actual Value
Unit
Range
MML Command
0~65534
SET
GBSCREDGRP
None (Mandatory)
BSC
0~65534
SET
GBSCREDGRP
None (Mandatory)
BSC
0~65534
SET
GBSCREDGRP
None (Mandatory)
BSC
SET
GBSCREDGRP
(Optional)
BSC
SET
GBSCREDGRP
(Optional)
Cell
SET
GBSCREDGRP
(Optional)
BSC
SET
GBSCREDGRP
(Optional)
BSC
1~60
1~60
1~600
1~600
SINGLEHOST
(SINGLEHOS
T),
PRIMHOST(P
The host type
RIMHOST), SINGLEHOST
of signalling SINGLE SLAVEHOST( , PRIMHOST,
ADD OPC
point
HOST SLAVEHOST) SLAVEHOST None (Optional)
HostType
Impa
ct
SCCP
SINGLEHOST
(Single Host),
PRIMHOST(P
rimary Host), SINGLEHOST
SINGLE SLAVEHOST( , PRIMHOST,
SET BTSIP
HOST Slave Host) SLAVEHOST None (Optional)
BTS
Peer BTS ID None
0~2047
0~2047
SET BTSIP
None (Mandatory)
BTS
Peer BSC IP None
None
0.0.0.0~255.2
SET BTSIP
None (Mandatory)
55.255.255
BTS
Peer BSC
Mask
None
0.0.0.0~255.2
SET BTSIP
None (Mandatory)
55.255.255
BTS
5-2
None

Ltd.
Issue 02 (2009-09-30)
BSS
BSC Node Redundancy
Parameter
5 Parameters
Default GUI Value

Value Range
Actual Value
Unit
Range
MML Command
Impa
ct
REHOSTRIG
HTNOW(ReH
ostRightNow),
REHOSTDEL REHOSTRIG
AY(ReHostDe HTNOW,
REHOSTDEL
lay),
REHOSTWH AY,
REHOS EN(ReHostW REHOSTWHE
ReHost Type TDELAY hen)
None
N
SET
GREDGRPPRIM
HOSTPOLICY
Cell
(Mandatory)
ReHostDelay
600
Time
1~3600
SET
GREDGRPPRIM
HOSTPOLICY
Cell
(Mandatory)
ReHost
Absolute
Time
SET
GREDGRPPRIM
00:00:00~23:5
HOSTPOLICY
hour, min, sec 9:59
None (Mandatory)
Cell
None
Issue 02 (2009-09-30)
1~3600

Ltd.
5-3
BSS
BSC Node Redundancy
6 Counters
6 Counters
None.
Issue 02 (2009-09-30)

Ltd.
6-1
BSS
BSC Node Redundancy
7 Glossary
7 Glossary
For the acronyms, abbreviations, terms, and definitions, see the Glossary.
Issue 02 (2009-09-30)

Ltd.
7-1
BSS
BSC Node Redundancy
8 Reference Documents
8 Reference Documents
z
BSC6900 Feature List
BSC6900 Optional Feature Description
GBSS Reconfiguration Guide
BSC6900 GSM Parameter Reference
BSC6900 GSM MML Command Reference
Issue 02 (2009-09-30)

Ltd.
8-1

BSC Node Redundancy

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

BSC Node Redundancy

Загружено:

Авторское право:

Доступные форматы

BSC Node Redundancy Feature

Trademarks and Permissions

Huawei Proprietary and Confidential

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

The structure of the document is None.

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

Huawei Proprietary and Confidential

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

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

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 ReHost Type is set to REHOSTRIGHTNOW(ReHostRightNow), service objects switch back to the

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

Local BSC identity.

Peer BSC identity.

BSC Node Redundancy

Index of the BSC Node Redundancy Group.

Interval for Sending

Time interval for sending a handshake message

Time delay of the detection on core network interface

If no handshake message is received from the peer

If no handshake message is received from the peer

The host type of signalling

Host type of signaling point.

Host type of an IP BTS

Identifier of the peer BTS on the home BSC6900 side

IP address of the peer BSC6900 on the home BSC6900

Peer BSC Mask