BSC Node Redundancy (GBSS14.0 - 02)

GSM BSS
GBSS14.0
BSC Node Redundancy Feature

Parameter Description
Issue 02
Date 2013-04-12
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2013. 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 a 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
Issue 02 (2013-04-12) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
GSM BSS
BSC Node Redundancy Feature Parameter Description Contents
Contents
1 Introduction to This Document..................................................................................................1

1.1 Scope..................................................................................................................................................................1
1.2 Intended Audience..............................................................................................................................................1
1.3 Change History...................................................................................................................................................1
2 Overview.........................................................................................................................................3
2.1 Introduction........................................................................................................................................................3
2.2 Benefits...............................................................................................................................................................4
3 Technical Description...................................................................................................................6
3.1 Dual- and Single-Homed Service Objects..........................................................................................................6
3.1.1 OPC...........................................................................................................................................................6
3.1.2 BTS............................................................................................................................................................7
3.2 Network Topologies...........................................................................................................................................7
3.2.1 Typical Scenarios......................................................................................................................................7
3.2.2 Networking Modes over the Abis/A/Gb/Inter-BSC Interface...................................................................9
3.3 Fault Detection.................................................................................................................................................15
3.4 Migrating Service Objects in the Event of a Failure........................................................................................16
3.4.1 Migrating Dual-Homed OPCs.................................................................................................................16
3.4.2 Migrating Dual-Homed BTSs.................................................................................................................17
3.5 Neighboring Cells.............................................................................................................................................18
3.5.1 All Dual-Homed BTSs............................................................................................................................18
3.5.2 Combination of Dual- and Single-Homed BTSs.....................................................................................19
3.6 Migrating Back Dual-Homed Service Objects.................................................................................................20
3.7 Maintaining Dual-Homed Service Objects.......................................................................................................21
4 Related Features...........................................................................................................................22
4.1 Abis over IP or Abis IP over E1/T1.................................................................................................................22
4.2 A over IP or A IP over E1/T1...........................................................................................................................22
4.3 Local Multiple Signaling Points.......................................................................................................................22
5 Network Impact...........................................................................................................................23
5.1 System Capacity...............................................................................................................................................23
5.2 Network Performance.......................................................................................................................................23
6 Engineering Guidelines.............................................................................................................24
Issue 02 (2013-04-12) Huawei Proprietary and Confidential ii

GSM BSS
BSC Node Redundancy Feature Parameter Description Contents
6.1 When to Use BSC Node Redundancy..............................................................................................................24

6.2 Required Information.......................................................................................................................................24
6.3 Planning............................................................................................................................................................24
6.4 Deployment......................................................................................................................................................25
6.5 Performance Monitoring...................................................................................................................................25
6.6 Parameter Optimization....................................................................................................................................25
6.7 Troubleshooting................................................................................................................................................25
7 Parameters.....................................................................................................................................26
8 Counters........................................................................................................................................40
9 Glossary.........................................................................................................................................41
10 Reference Documents...............................................................................................................42
Issue 02 (2013-04-12) Huawei Proprietary and Confidential iii

GSM BSS
BSC Node Redundancy Feature Parameter Description 1 Introduction to This Document
1 Introduction to This Document
1.1 Scope
This document describes the implementation principles of the GBFD-113725 BSC Node
Redundancy feature, including network topologies, fault detection, migrating, migrating back,
and maintaining service objects.
1.2 Intended Audience

This document is intended for personnel who:
l Need to understand the BSC Node Redundancy feature

l Work with Huawei GSM products
1.3 Change History

This section provides information about the changes in different document versions.
There are two types of changes, which are defined as follows:
l Feature change: refers to a change in the BSC Node Redundancy feature of a specific
product version.
l Editorial change: refers to a change in wording or the addition of information that was not
described in the earlier version.
Document Issues
The document issues are as follows:
l 02 (2013-04-12)
l 01 (2012-04-28)
l Draft A (2012-02-15)
Issue 02 (2013-04-12) Huawei Proprietary and Confidential 1

GSM BSS
BSC Node Redundancy Feature Parameter Description 1 Introduction to This Document
02 (2013-04-12)
This is the second release of GBSS14.0.
Compared with issue 01 (2012-04-28) of GBSS14.0, issue 02 (2013-04-12) of GBSS14.0
incorporates the changes described in the following table.
Change Type Change Description Parameter Change
Feature change None None
Editorial change Optimized the descriptions None

throughout the document.
01 (2012-04-28)
This is the first release of GBSS14.0.
Compared with issue draft A (2012-02-15) of GBSS14.0, issue 01 (2012-04-28) of GBSS14.0
has no change.
Draft A (2012-02-15)
This is the draft release of GBSS14.0.
Compared with issue 01 (2011-03-31) of GBSS13.0, issue Draft A (2012-02-15) of GBSS14.0
has no change.

GSM BSS
BSC Node Redundancy Feature Parameter Description 2 Overview
2 Overview
2.1 Introduction
Huawei introduces the BSC Node Redundancy feature, which is a BSC-level redundancy
solution, to prevent the following problems:
In traditional wireless networks, each BTS connects to only one BSC. If a BSC fails or all the
signaling links on the A interface are disconnected, none of the BTSs served by the BSC can
access the network, and the BSC cannot provide services.
NOTE
This feature applies to the following scenarios:

l BSC failure
A BSC fails or all the A interface boards are faulty. In either case, the BSC cannot process services.
l Failure in signaling links on the A interface
All the signaling links on the A interface are disconnected.
The BSC Node Redundancy feature enables two BSCs to form a redundancy group in all-IP
networking mode (the A, Abis, and inter-BSC interfaces all use IP transmission). Two BSCs in
a redundancy group work in 1+1 backup mode. If one BSC fails or all the signaling links on the
A interface of one BSC are disconnected, the other BSC takes over all services.
Figure 2-1 shows the networking diagram of two BSCs working in a redundancy group.

GSM BSS
Figure 2-1 Networking diagram of two BSCs working in a redundancy group
In a redundancy group, each BSC considers itself as the local BSC and the other as the peer
BSC. To enable or disable this feature, simultaneously run the ACT GBSCREDGRP or DEA
GBSCREDGRP command, respectively, on the local and peer BSCs.
LocalBSCID and PeerBSCID specify the local and peer BSCs in a redundancy group,
respectively. GROUPINDEX specifies a redundancy group.
2.2 Benefits
This feature provides the following benefits:
l More reliable BSCs

Two BSCs in a redundancy group work in 1+1 backup mode. If one BSC fails, the other
BSC immediately takes over services from the failed BSC.

GSM BSS
l More reliable transmission

Both BSCs in a redundancy group connect to a core network (CN) over the A interface. If
all the signaling links on the A interface of one BSC are disconnected, the other BSC
immediately takes over services from the failed BSC.

GSM BSS
BSC Node Redundancy Feature Parameter Description 3 Technical Description
3 Technical Description
3.1 Dual- and Single-Homed Service Objects

The BSC Node Redundancy feature introduces the concepts of dual- and single-homed service
objects. Dual-homed service object: The service object is configured on two BSCs but is
activated only on one BSC at a time.
Single-homed service object: The service object is configured only on one BSC.
A dual-homed service object is configured as primary-homed on one BSC and as secondary-
homed on the other BSC.
l Primary-homed: The service object provides services on the local BSC and its configuration
data is backed up on the peer BSC. The peer BSC takes over the service objects only when
the local BSC fails or all the signaling links on the A interface of the local BSC are
disconnected.
l Secondary-homed: The service object provides services on the peer BSC and its
configuration data is backed up on the local BSC. The local BSC takes over the service
objects only when the peer BSC fails or all the signaling links on the A interface of the peer
BSC are disconnected.
Each BSC controls its primary- and single-homed service objects and backs up the configuration
data of its secondary-homed service objects. If one BSC fails or all the signaling links on the A
interface of one BSC are disconnected, the other BSC automatically detects the failure and
enables the backup configuration data of the secondary-homed service objects to take effect.
The BSC then takes over services from the failed BSC.
Dual-homed service objects consist of dual-homed originating point codes (OPCs) and BTSs.
3.1.1 OPC
In a redundancy group, HOSTTYPE of an OPC determines whether the OPC works on the local
or peer BSC:
l If HOSTTYPE is set to PRIMHOST(Primary Host), the OPC provides services on the
local BSC.
l If HOSTTYPE is set to SLAVEHOST(Slave Host), the OPC provides services on the peer
BSC.

GSM BSS
l If HOSTTYPE is set to SINGLEHOST(Single Host), the OPC provides services only on

the local BSC.
3.1.2 BTS
In a redundancy group, HOSTTYPE of a BTS determines whether the BTS works under the
local or peer BSC:
l If HOSTTYPE is set to PRIMHOST(Primary Host), the BTS communicates with the
local BSC.
l If HOSTTYPE is set to SLAVEHOST(Slave Host), the BTS communicates with the peer
BSC.
l If HOSTTYPE is set to SINGLEHOST(Single Host), the BTS communicates only with
the local BSC.
When BSC Node Redundancy is enabled, specify the PEERBTSID, PEERBSCIP,
PEERBSCID, and PEERBSCMASK parameters for dual-homed BTSs under the local BSC.
The local BSC sends the values of these parameters to the BTSs.
NOTE
The BSCIP and PEERBSCIP parameters specify the IP addresses of the two BSCs to which a BTS is
connected.
3.2 Network Topologies
3.2.1 Typical Scenarios

The BSC Node Redundancy feature is used in two typical scenarios: load sharing and active/
standby modes.
Load Sharing Mode

Some dual-homed BTSs are configured as primary-homed BTSs under BSC 1, and other dual-
homed BTSs are configured as primary-homed BTSs under BSC 2. In load sharing mode, if one
BSC fails or all the signaling links on the A interface are disconnected, the peer BSC takes over
services carried by the dual-homed BTSs from the failed BSC.
Figure 3-1 shows an example of using BSC Node Redundancy in load sharing mode.

GSM BSS
Figure 3-1 BSC Node Redundancy in load sharing mode
As shown in Figure 3-1, BTSs a and b are dual-homed BTSs. Specifically, BTS a is configured
as a primary-homed BTS under BSC 1 and a secondary-homed BTS under BSC 2, whereas BTS
b is configured as a primary-homed BTS under BSC 2 and a secondary-homed BTS under BSC
1. BTSs 1 and 2 are single-homed BTSs.
Primary- and secondary-homed OPCs are configured for BSCs 1 and 2. The primary-homed
OPC configured for BSC 1 is the same as the secondary-homed OPC configured for BSC 2, and
the primary-homed OPC configured for BSC 2 is the same as the secondary-homed OPC
configured for BSC 1.
A single-homed OPC needs to be configured if BSC 1 or 2 is configured with single-homed

BTSs.
The following table describes the binding between cells and an OPC in a BSC.
Cells Bound OPC
Cells served by primary-homed BTSs under Primary-homed OPC

the BSC
Cells served by secondary-homed BTSs Secondary-homed OPC

under the BSC
Cells served by single-homed BTSs under the Single-homed OPC

BSC
Active/Standby Mode
All dual-homed BTSs are configured as primary-homed BTSs under BSC 1 and as secondary-
homed BTSs under BSC 2. In active/standby mode, if BSC 1 fails or all the signaling links on
the A interface of BSC 1 are disconnected, BSC 2 takes over services carried by the dual-homed
BTSs from BSC 1.
Figure 3-2 shows an example of using BSC Node Redundancy in active/standby mode

GSM BSS
Figure 3-2 BSC Node Redundancy in active/standby mode
As shown in Figure 3-2, BTS a is a dual-homed BTS. It is configured as a primary-homed BTS

under BSC 1 and a secondary-homed BTS under BSC 2. BTSs 1 and 2 are single-homed BTSs.
A primary-homed OPC is configured for BSC 1, and a secondary-homed OPC is configured for
BSC 2. The two OPCs are the same.
A single-homed OPC needs to be configured if BSC 1 or 2 is configured with single-homed
BTSs.
The following table describes the binding between cells and an OPC in a BSC.
Cells Bound OPC
Cells served by primary-homed BTSs under Primary-homed OPC

the BSC
Cells served by secondary-homed BTSs Secondary-homed OPC

under the BSC
Cells served by single-homed BTSs under the Single-homed OPC

BSC
3.2.2 Networking Modes over the Abis/A/Gb/Inter-BSC Interface

The BSC Node Redundancy feature applies only to all-IP networking mode (the A, Abis, and
inter-BSC interfaces all use IP transmission). The Gb interface can use any transmission mode.
Abis Interface
A dual-homed BTS can be connected to the primary- and secondary-homed BSCs according to
their IP addresses by using routers. A BTS supports two transmission links connecting to the
primary- and secondary-homed BSCs, respectively. In direct connection mode, a BTS does not
support automatic link switchover. A BTS can be connected to two BSCs working in a
redundancy group only through routers.
Three networking scenarios are applicable to the Abis interface:

GSM BSS
l Networking scenario 1: An IP bearer network is available on the Abis interface, and the
BTS is deployed at the remote end of the IP bearer network.
The BTS is connected to an optical transceiver in IP over E1/T1 mode. The BSC is
connected to the border router on the BSC side in IP over ETH transmission mode. The
border router on the BTS side is connected to the primary- and secondary-homed BSCs
according to the IP addresses.
Figure 3-3 shows this networking scenario.
Figure 3-3 IP bearer network on the Abis interface and the BTS at the remote end
l Networking scenario 2: An IP bearer network is available on the Abis interface, and the
BTS is deployed 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
ETH mode. The BSC is connected to the border router on the BSC side in IP over ETH
mode. The border router on the BTS side is connected to the primary- and secondary-homed
BSCs according to the IP addresses.

GSM BSS
Figure 3-4 IP bearer network on the Abis interface and the BTS at the local end
l Networking scenario 3: No IP bearer network is available on the Abis interface.

An intermediate router is required in Abis over IP mode.
The BTS is connected to an optical transceiver in IP over E1/T1 mode. The BSC is
connected to the border router on the BSC side in IP over ETH mode. The intermediate
router is connected to the primary- and secondary-homed BSCs according to the IP
addresses.
NOTE
To prevent a single-point of failure during network transmission, the intermediate router must support
redundancy backup. It is recommended that the intermediate router and the router on the BSC side
be placed in different locations. This ensures that the redundancy function is operational even if the
intermediate router is faulty.

GSM BSS
Figure 3-5 No IP bearer network on the Abis interface
A Interface
Two BSCs in a redundancy group are connected to the CN by using routers.
Two networking scenarios are applicable to the A interface:
l Networking scenario 1: The bearer network on the A interface is an Ethernet network.
The BSC is connected to the border router on the BSC side in IP over ETH mode. The MSC
is connected to the border router on the MSC side in IP over ETH mode.

GSM BSS
Figure 3-6 Ethernet network as the IP bearer network
l Networking scenario 2: The bearer network on the A interface is a synchronous digital

hierarchy (SDH) or plesiochronous digital hierarchy (PDH) network.
The BSC uses an optical interface to connect to the CN in IP over E1/T1 mode.
Figure 3-7 SDH or PDH network as the IP bearer network

GSM BSS
Gb Interface
BSC Node Redundancy has no special requirements for the networking mode used by the Gb
interface. In Gb interface-related protocols, the BSC is virtualized as a network service entity
(NSE). For an SGSN, different NSEs are configured for different BSCs, and the point-to-point
BSSGP virtual connections (PTP BVCs) under different NSEs can be bound to the same cell.
BSC Node Redundancy implements inter-NSE handovers, and the SGSN cannot perceive a BSC
switchover. In addition, the same cell served by different BSCs can be bound to different NSEs.
Figure 3-8 shows this networking mode.
Figure 3-8 Networking mode used by the Gb interface
Inter-BSC Interface
The inter-BSC interface is used for fault detection on two BSCs in a redundancy group.
Two BSCs in a redundancy group are connected to each other by using routers on the inter-BSC
interface.
NOTE
The routes configured over the inter-BSC interface consist of two types: a direct route between BSCs and
an alternative route that passes through a router on the MSC side.
l Direct route: A router is configured between two BSCs to establish communication links over the inter-
BSC interface.
l Alternative route: The signaling network on the A interface is reused. The IP address of the A interface
signaling plane is used to establish communication links. However, the alternative route cannot be
implemented if the BSC connects to the CN without using a router.
The alternative route helps improve the reliability of inter-BSC fault detection. If the direct route is
disconnected but the two BSCs are functional, information can still be transmitted through the alternative
route, thereby preventing a BSC from mistakenly determining that the peer BSC has failed.
Figure 3-9 shows this networking mode.

GSM BSS
Figure 3-9 Routes on the inter-BSC interface
3.3 Fault Detection

Fault detection is implemented between two BSCs in a redundancy group by checking the
heartbeat messages periodically transmitted from the peer end over the inter-BSC interface. The
BEATSENDINGDIS parameter specifies the interval for sending heartbeat messages between
two BSCs.
Heartbeat messages are transmitted over the Signaling Control Transmission Protocol (SCTP)
link on the inter-BSC interface. To check the status of the SCTP link, run the DSP
SCTPLNK command.
The local BSC is considered unable to provide services and will stop sending heartbeat messages
to the peer BSC when either of the following problems occurs:
l The local BSC fails and thereby cannot provide services.
l The CNSTATEPOLICYFORGROUP parameter is set to AINTFBLOCK(AInterf
Block), and the local BSC detects that the failure of all the signaling links on the A interface
lasts longer than the duration specified by CNFAULTDELAY.
NOTE
l The BSC Node Redundancy feature is allowed only if a BSC in a redundancy group fails or all the
signaling links on the A interface are disconnected. That is, service migration is not triggered if some
boards on a BSC become faulty.
l The transmission status of the Abis interface has no impact on this feature. Consequently, service
migration is not triggered if the transmission over the Abis interface is faulty.
l Service migration is not triggered if a BTS fails.
Upon detecting that the transmission of heartbeat messages has been interrupted for a period
longer than that specified by SLVSERVACTDELAY, the peer BSC considers that the local BSC
cannot provide services. The peer BSC then takes over the primary-homed service objects from
the local BSC.

GSM BSS
Under extreme circumstances, if the peer BSC also fails after taking over the service objects, all
services are interrupted. In this case, if the local BSC recovers before the peer BSC does, the
local BSC takes back its primary-homed service objects from the peer BSC after a period
specified by MSTSERVACTDELAY.
3.4 Migrating Service Objects in the Event of a Failure

Two BSCs in a redundancy group manage their respective primary-homed service objects.
If the local BSC cannot provide services, the peer BSC takes over the dual-homed service objects
but not the single-homed service objects from the local BSC. The peer BSC takes over the control
rights of dual-homed OPCs and then dual-homed BTSs.
NOTE
If BSC Node Redundancy is deactivated after control rights are taken over, the peer BSC automatically
releases the control rights of the secondary-homed service objects. The local BSC then takes back the
control rights of the primary-homed service objects.
3.4.1 Migrating Dual-Homed OPCs

If the local BSC in a redundancy group cannot provide services, the single-homed OPCs of the
local BSC stop providing services and become faulty. The peer BSC then takes over the primary-
homed OPCs from the local BSC. These OPCs (secondary-homed OPCs of the peer BSC) are
immediately activated and start to provide services, and therefore these OPCs are changed from
not homed to homed.
MTP3-User Adaptation Layer (M3UA) links are configured to connect the OPC on the MSC
side to each OPC on the BSC side.
The M3UA link carrying the secondary-homed OPC of a BSC is deactivated, and the M3UA
link carrying the primary-homed OPC of a BSC is activated. However, if a BSC in a redundancy
group fails, the M3UA link carrying the primary-homed OPC of the BSC is deactivated, and the
M3UA link carrying the secondary-homed OPC of the other BSC is activated.

GSM BSS
Figure 3-10 Migrating dual-homed OPCs
If the direct and alternative routes carrying heartbeat messages simultaneously become faulty
but the BSCs communicate with the CN correctly, the fault detection mechanism determines
that the dual-homed OPCs of the two BSCs are homed and the M3UA links for all the OPCs are
activated. In this scenario, only one OPC can be observed in the CN, and multiple M3UA links
can be observed under the OPC. When BSC 1 sends a message to the CN, the CN may send a
response message to BSC 2 through another M3UA link, thereby probably confusing message
transmission and interrupting all the services provided by the two BSCs.
3.4.2 Migrating Dual-Homed BTSs

After dual-homed OPCs are taken over, the control rights of dual-homed BTSs corresponding
to the dual-homed OPCs are migrated.
If the local BSC in a redundancy group cannot provide services, the single-homed BTSs of the
local BSC stop providing services and become faulty. The peer BSC then takes over the primary-
homed BTSs from the local BSC. These BTSs (secondary-homed BTSs of the peer BSC) are
immediately activated and start to provide services, and the value of Hosted for these BTSs is
therefore changed from No to Yes.
The procedure for migrating the control rights of dual-homed BTSs is as follows:

GSM BSS
1. When the local BSC cannot provide services, the signaling links between the local BSC
and its dual-homed BTSs are disconnected.
2. The primary-homed BTS of the local BSC sends a signaling link establishment request to
the peer BSC according to the IP address sent by the local BSC.
3. After a signaling link is established, the peer BSC instructs the BTS to reset.
4. After the BTS resets, it sends a DHCP request to the peer BSC.
5. The peer BSC responds to the BTS with a DHCP response message, which carries the IP
address allocated to the BTS.
6. After receiving the IP address, the BTS resends a signaling link establishment request to
the peer BSC.
7. After a signaling link is established, the peer BSC sends the configuration data to the BTS.
The BTS is then taken over by the peer BSC and starts to provide services.
3.5 Neighboring Cells

The configuration of neighboring cells varies depending on the following scenarios:
l The BTSs controlled by a BSC are all dual-homed BTSs.

l The BTSs controlled by a BSC consist of dual- and single-homed BTSs.
3.5.1 All Dual-Homed BTSs

This scenario has high requirements for the BSC reliability. To meet the requirements, you must
configure all the BTSs and OPCs under two BSCs as dual-homed BTSs and OPCs. Specifically,
configure all the primary-homed BTSs under one BSC, or evenly configure the primary-homed
BTSs under the two BSCs.
If BSC 1 fails or all the signaling links on the A interface of BSC 1 are disconnected, BSC 2
takes over services from BSC 1, and all the BTSs previously controlled by BSC 1 now provide
services under BSC 2. BSCs 1 and 2 work in active/standby mode. Therefore, the maximum
number of services supported by the two BSCs together equals the specification of one BSC.
Figure 3-11 shows the network topology in this scenario.
Figure 3-11 All dual-homed BTSs

GSM BSS
If two dual-homed BTSs are configured with a neighbor relationship, configure neighboring
cells using either of the following methods:
l Configure two cells in two separate BSCs as a pair of external neighboring cells.
l Configure two cells in a BSC as a pair of internal neighboring cells.
Figure 3-12 shows the two configuration methods.
Figure 3-12 Configuring neighboring cells
l Method 1: On BSC 1, configure cell 2 as an external neighboring cell of cell 1. On BSC 2,

configure cell 1 as an external neighboring cell of cell 2.
l Method 2: On BSC 1, configure cell 1 and cell 2' as a pair of internal neighboring cells. On
BSC 2, configure cell 1' and cell 2 as a pair of internal neighboring cells.
Each cell is bound to two OPCs. The BSC considers a handover that occurs between two OPCs
as an inter-BSC handover, regardless of whether the two OPCs belong to the same BSC.
Therefore, a handover from cell 1 to cell 2' is considered an inter-BSC handover.
3.5.2 Combination of Dual- and Single-Homed BTSs

This scenario enables a key BTS to quickly provide services when the serving BSC fails. In this
scenario, only one BTS is configured as a dual-homed BTS under two BSCs.
Figure 3-13 shows the network topology in this scenario.
Figure 3-13 Combination of dual- and single-homed BTSs

GSM BSS
If BSC 1 fails or all the signaling links on the A interface of BSC 1 are disconnected, BTS 2 (the
only dual-homed BTS under the two BSCs) provides services under BSC 2. Since BTS 1 is
configured as a single-homed BTS under BSC 1, the services provided by the BTS are
interrupted. In this scenario, cells served by the dual-homed BTS must be bound to a dual-homed
OPC, and cells served by single-homed BTSs must be bound to a single-homed OPC. Therefore,
at least two OPCs are required.
If a dual-homed BTS and a single-homed BTS are configured with a neighbor relationship,
configure two cells in a BSC as a pair of internal neighboring cells and two cells in two separate
BSCs as a pair of external neighboring cells.
Figure 3-14 shows the configuration method.
Figure 3-14 Configuring neighboring cells
On BSC 1, configure cell 1 and cell 2 as a pair of internal neighboring cells. On BSC 2, configure
cell 2 as an external neighboring cell of cell 1'.
The two cells are bound to different OPCs. Therefore, an inter-cell handover is considered an
inter-BSC handover.
3.6 Migrating Back Dual-Homed Service Objects

If the local BSC in a redundancy group fails, the peer BSC takes over the primary-homed service
objects from the local BSC. When the local BSC recovers, the service objects taken over by the
peer BSC can be migrated back, depending on the policy specified by REHOSTTYPE:
l If REHOSTTYPE is set to REHOSTRIGHTNOW(ReHostRightNow), service objects
are migrated back immediately after the local BSC recovers.
l If REHOSTTYPE is set to REHOSTDELAY(ReHostDelay), service objects are migrated
back N seconds after the local BSC recovers, where N is specified by
REHOSTDELAYTIME.
l If REHOSTTYPE is set to REHOSTWHEN(ReHostWhen), service objects are migrated
back at the time specified by REHOSTABSTIME after the local BSC recovers.
REHOSTABSTIME must be set to a value in the format of hh:mm:ss.
The procedure for migrating back service objects and that for migrating service objects from a
failed BSC are the same except that they have reverse orders.

GSM BSS
3.7 Maintaining Dual-Homed Service Objects

A service object is managed by only one BSC at a time. If the control rights of a dual-homed
service object are migrated from the local BSC to the peer BSC, the local BSC can no longer
maintain the service object. Therefore, a BSC can maintain only service objects that are homed.

GSM BSS
BSC Node Redundancy Feature Parameter Description 4 Related Features
4 Related Features
4.1 Abis over IP or Abis IP over E1/T1

The BSC Node Redundancy feature requires the GBFD-118601 Abis over IP or GBFD-118611
Abis IP over E1/T1 feature over the Abis interface.
4.2 A over IP or A IP over E1/T1

The BSC Node Redundancy feature requires the GBFD-118602 A over IP or GBFD-118622 A
IP over E1/T1 feature over the A interface.
4.3 Local Multiple Signaling Points

The BSC Node Redundancy feature requires the GBFD-115301 Local Multiple Signaling Points
feature when either of the following conditions is true:
l The BSC has single-homed BTSs.
l The BSC works in load sharing mode.

GSM BSS
BSC Node Redundancy Feature Parameter Description 5 Network Impact
5 Network Impact
5.1 System Capacity

None
5.2 Network Performance

The BSC Node Redundancy feature improves the reliability of BSC equipment and transmission
over the A interface and shortens the service downtime. Services are interrupted for 10 to 20
minutes when service objects are being migrated or migrated back.

GSM BSS
BSC Node Redundancy Feature Parameter Description 6 Engineering Guidelines
6 Engineering Guidelines
6.1 When to Use BSC Node Redundancy

It is recommended that the BSC Node Redundancy feature be enabled in areas that have high
requirements for network reliability.
6.2 Required Information

Before deploying BSC Node Redundancy, collect the following information:
l Networking over different interfaces
l Networking in the CN
l Type of transmission interface boards on the BSC and BTS
6.3 Planning
RF Planning
None
Network Planning
The A, Abis, and inter-BSC interfaces use IP transmission. The Gb interface can use any
transmission mode. For details, see section 3.2.2 Networking Modes over the Abis/A/Gb/
Inter-BSC Interface.
A redundancy group consists of only two BSCs.
The two BSCs in a redundancy group connect to only one MSC/SGSN or MSC/SGSN pool.
A BTS cannot directly connect to a BSC over the Abis interface. Therefore, BTSs use routers
to connect to the two BSCs in a redundancy group.
Hardware Planning
IP interface boards are required for the BSC and BTS.

GSM BSS
BSC Node Redundancy Feature Parameter Description 6 Engineering Guidelines
BTSs other than the BTS3006C, BTS3002E, BTS3900B, and BTS3900E are supported.
6.4 Deployment
For details about how to activate, verify, and deactivate this feature, see Configuring BSC Node
Redundancy.
6.5 Performance Monitoring

None
6.6 Parameter Optimization

None
6.7 Troubleshooting
When two BSCs in a redundancy group work correctly, they regularly check the homing
attributes of BTSs and the homing status of service objects of each other.
l When a BSC detects that the homing attributes of a BTS conflict on the two BSCs, the BSC
reports ALM-21815 Dual-Hosted BTS Configuration Error.
l When a BSC detects that the homing status of a service object conflicts on the two BSCs,
the BSCs perform different operations depending on the actual conditions:
– If a service object is not homed onto the two BSCs, the primary- and secondary-homed
BSCs wait a period specified by MSTSERVACTDELAY and
SLVSERVACTDELAY respectively and then initiate negotiations with the peer BSC
to determine which BSC can obtain the control rights of the service object.
– If a service object is homed on both BSCs, the primary-homed BSC takes over the
service object from the secondary-homed BSC immediately after the link carrying
heartbeat messages recovers.

GSM BSS
BSC Node Redundancy Feature Parameter Description 7 Parameters
7 Parameters
Table 7-1 Parameter description

Parameter ID NE MML Feature ID Feature Name Description
Command
BEATSENDIN BSC6900 SET GBFD-113725 BSC Node Meaning:Time

GDIS GBSCREDGR Redundancy interval for
P sending a
handshake
message
between BSCs.
The parameter
checks whether
the
communication
among BSCs in
a redundancy
group is normal.
GUI Value
Range:1~60
Unit:s
Actual Value
Range:1~60
Default Value:1

GSM BSS

Command
BSCIP BSC6900 SET BTSIP GBFD-118601 Abis over IP Meaning:When

"BTS MultiIP
Switch" is set to
NO, this
parameter
indicates the IP
address of the
interface board
on the BSC side.
When "BTS
MultiIP Switch"
is set to YES,
this parameter
indicates the IP
address of the
maintenance
plane on the
BSC side.
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default Value:
255.255.255.25
5

GSM BSS

Command
CNFAULTDE BSC6900 SET GBFD-113725 BSC Node Meaning:Time

LAY GBSCREDGR Redundancy delay in the
P detection of core
network
interface failure.
Within the
preset value of
this parameter,
the BSC
continuously
detects core
network
interface
failures and then
releases the
management
right of service
objects.
GUI Value
Range:1~60
Unit:s
Actual Value
Range:1~60
Default Value:
30

GSM BSS

Command
CNSTATEPO BSC6900 SET GBFD-113725 BSC Node Meaning:Policy

LICYFORGR GBSCREDGR Redundancy of the BSC for
OUP P judging whether
the interface
status of the core
network is
normal. If the
value is NONE,
the BSC does
not change the
service
management
right. If the
value is
AINTFBLOCK,
the BSC releases
the service
management
right when
detecting
disconnection at
the A interface.
GUI Value
Range:NONE
(None),
AINTFBLOCK
(AInterf Block)
Unit:None
Actual Value
Range:NONE,
AINTFBLOCK
Default
Value:NONE
(None)

GSM BSS

Command
GROUPINDE BSC6900 SET GBFD-113725 BSC Node Meaning:Index

X GBSCREDGR Redundancy of the BSC Node
P Redundancy
Group. It
identifies a BSC
redundancy
group. The BSC
node
redundancy is a
function through
which two BSCs
form a
redundancy
group when the
all-IP
transmission
mode is applied.
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.
GUI Value
Range:0~65534
Unit:None

GSM BSS

Command
Actual Value
Range:0~65534
Default
Value:None
HOSTTYPE BSC6900 SET BTSIP GBFD-113725 BSC Node Meaning:Host

Redundancy type of an IP
BTS.
GUI Value
Range:SINGLE
HOST(Single
Host),
PRIMHOST
(Primary Host),
SLAVEHOST
(Slave Host)
Unit:None
Actual Value
Range:SINGLE
HOST,
PRIMHOST,
SLAVEHOST
Default
Value:SINGLE
HOST(Single
Host)

GSM BSS

Command
HOSTTYPE BSC6900 ADD OPC GBFD-113725 BSC Node Meaning:Indi-

MOD OPC Redundancy cates 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:SINGLE
HOST
(SINGLEHOST
), PRIMHOST
(PRIMHOST),
SLAVEHOST
(SLAVEHOST)
Unit:None

GSM BSS

Command
Actual Value
Range:SINGLE
HOST,
PRIMHOST,
SLAVEHOST
Default
Value:SINGLE
HOST
(SINGLEHOST
)
LocalBSCID BSC6900 SET GBFD-113725 BSC Node Meaning:ID of

GBSCREDGR Redundancy the local BSC in
P the BSC node
redundancy
group.
GUI Value
Range:0~65534
Unit:None
Actual Value
Range:0~65534
Default
Value:None

GSM BSS

Command
MSTSERVAC BSC6900 SET GBFD-113725 BSC Node Meaning:If no

TDELAY GBSCREDGR Redundancy handshake
P message is
received from
the peer within
the delay, the
master service at
the local BSC is
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.
GUI Value
Range:1~600
Unit:s
Actual Value
Range:1~600
Default Value:
45

GSM BSS

Command
PeerBSCID BSC6900 SET GBFD-113725 BSC Node Meaning:ID of

GBSCREDGR Redundancy the peer BSC in
P the BSC node
redundancy
group.
GUI Value
Range:0~65534
Unit:None
Actual Value
Range:0~65534
Default
Value:None
PEERBSCID BSC6900 SET BTSIP GBFD-118601 Abis over IP Meaning:ID of

the peer BSC on
the homing BSC
side
GUI Value
Range:0~65534
Unit:None
Actual Value
Range:0~65534
Default
Value:None
PEERBSCIP BSC6900 SET BTSIP GBFD-118601 Abis over IP Meaning:IP

GBFD-113725 BSC Node address of the
Redundancy peer BSC on the
homing BSC
side
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None

GSM BSS

Command
PEERBSCMA BSC6900 SET BTSIP GBFD-118601 Abis over IP Meaning:Subnet

SK GBFD-113725 BSC Node mask of the port
Redundancy IP address at the
peer BSC.
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None
PEERBTSID BSC6900 SET BTSIP GBFD-118601 Abis over IP Meaning:Identi-

GBFD-113725 BSC Node fier of the peer
Redundancy BTS on the
homing BSC
side
GUI Value
Range:0~2047
Unit:None
Actual Value
Range:0~2047
Default
Value:None

GSM BSS

Command
REHOSTABS BSC6900 SET GBFD-113725 BSC Node Meaning:Absol

TIME GREDGRPPR Redundancy ute service re-
IMHOSTPOLI host time. If
CY "REHOSTTYP
E" is set to
"ReHostWhen"
and the local
BSC recovers, it
reclaims service
objects at the
time specified
by this
parameter.
GUI Value
Range:hour,
min, sec
Unit:None
Actual Value
Range:
00:00:00~23:59
:59
Default
Value:None
REHOSTDEL BSC6900 SET GBFD-113725 BSC Node Meaning:Delay

AYTIME GREDGRPPR Redundancy of service re-
IMHOSTPOLI host. If
CY "REHOSTTYP
E" is set to
"ReHostDelay"
and the local
BSC recovers, it
reclaims service
objects after a
delay specified
by this
parameter.
GUI Value
Range:1~3600
Unit:s
Actual Value
Range:1~3600
Default Value:
600

GSM BSS

Command
REHOSTTYP BSC6900 SET GBFD-113725 BSC Node Meaning:Servic

E GREDGRPPR Redundancy e re-host policy.
IMHOSTPOLI If the local BSC
CY in a BSC node
redundancy
group is faulty,
the peer BSC
takes over the
primary-hosted
service objects
on the local
BSC. If the local
BSC recovers, it
reclaims these
service objects
from the peer
BSC according
to a certain
policy if related
requirements are
met.
GUI Value
Range:REHOS-
TRIGHTNOW
(ReHostRightN
ow),
REHOSTDELA
Y
(ReHostDelay),
REHOSTWHE
N
(ReHostWhen)
Unit:None
Actual Value
Range:REHOS-
TRIGHTNOW,
REHOSTDELA
Y,
REHOSTWHE
N
Default
Value:REHOST
DELAY
(ReHostDelay)

GSM BSS

Command
SLVSERVAC BSC6900 SET GBFD-113725 BSC Node Meaning:If no

TDELAY GBSCREDGR Redundancy handshake
P message is
received from
the peer within
the delay, the
slave service at
the local BSC is
activated. 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.
GUI Value
Range:1~600
Unit:s
Actual Value
Range:1~600
Default Value:
300

GSM BSS
BSC Node Redundancy Feature Parameter Description 8 Counters
8 Counters
There are no specific counters associated with this feature.

GSM BSS
BSC Node Redundancy Feature Parameter Description 9 Glossary
9 Glossary
For the acronyms, abbreviations, terms, and definitions, see the Glossary.

GSM BSS
BSC Node Redundancy Feature Parameter Description 10 Reference Documents
10 Reference Documents
None


BSC Node Redundancy (GBSS14.0 - 02)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BSC Node Redundancy (GBSS14.0 - 02)

Uploaded by

Copyright:

Available Formats

GSM BSS

BSC Node Redundancy Feature

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2013-04-12) Huawei Proprietary and Confidential i

1 Introduction to This Document..................................................................................................1

Issue 02 (2013-04-12) Huawei Proprietary and Confidential ii

6.1 When to Use BSC Node Redundancy..............................................................................................................24

Issue 02 (2013-04-12) Huawei Proprietary and Confidential iii

1 Introduction to This Document

1.2 Intended Audience

l Need to understand the BSC Node Redundancy feature

1.3 Change History

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

Issue 02 (2013-04-12) Huawei Proprietary and Confidential 1

Change Type Change Description Parameter Change

Feature change None None

Editorial change Optimized the descriptions None

Issue 02 (2013-04-12) Huawei Proprietary and Confidential 2

This feature applies to the following scenarios:

Issue 02 (2013-04-12) Huawei Proprietary and Confidential 3

Figure 2-1 Networking diagram of two BSCs working in a redundancy group

l More reliable BSCs

Issue 02 (2013-04-12) Huawei Proprietary and Confidential 4

l More reliable transmission

Issue 02 (2013-04-12) Huawei Proprietary and Confidential 5

3.1 Dual- and Single-Homed Service Objects

Issue 02 (2013-04-12) Huawei Proprietary and Confidential 6

l If HOSTTYPE is set to SINGLEHOST(Single Host), the OPC provides services only on

3.2 Network Topologies

3.2.1 Typical Scenarios

Load Sharing Mode

Issue 02 (2013-04-12) Huawei Proprietary and Confidential 7

Figure 3-1 BSC Node Redundancy in load sharing mode

A single-homed OPC needs to be configured if BSC 1 or 2 is configured with single-homed

Cells Bound OPC

Cells served by primary-homed BTSs under Primary-homed OPC

Cells served by secondary-homed BTSs Secondary-homed OPC

Cells served by single-homed BTSs under the Single-homed OPC

Issue 02 (2013-04-12) Huawei Proprietary and Confidential 8

Figure 3-2 BSC Node Redundancy in active/standby mode

As shown in Figure 3-2, BTS a is a dual-homed BTS. It is configured as a primary-homed BTS

Cells Bound OPC

Cells served by primary-homed BTSs under Primary-homed OPC

Cells served by secondary-homed BTSs Secondary-homed OPC

Cells served by single-homed BTSs under the Single-homed OPC

3.2.2 Networking Modes over the Abis/A/Gb/Inter-BSC Interface

Issue 02 (2013-04-12) Huawei Proprietary and Confidential 9

Issue 02 (2013-04-12) Huawei Proprietary and Confidential 10

l Networking scenario 3: No IP bearer network is available on the Abis interface.

Issue 02 (2013-04-12) Huawei Proprietary and Confidential 11

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

Issue 02 (2013-04-12) Huawei Proprietary and Confidential 12

Figure 3-6 Ethernet network as the IP bearer network

l Networking scenario 2: The bearer network on the A interface is a synchronous digital

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

Issue 02 (2013-04-12) Huawei Proprietary and Confidential 13

Figure 3-8 shows this networking mode.

Figure 3-8 Networking mode used by the Gb interface

Figure 3-9 shows this networking mode.

Issue 02 (2013-04-12) Huawei Proprietary and Confidential 14

Figure 3-9 Routes on the inter-BSC interface