Академический Документы
Профессиональный Документы
Культура Документы
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.
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)
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)
iii
BSS
BSC Node Redundancy
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
Issue 02 (2009-09-30)
1-1
BSS
BSC Node Redundancy
01 (2009-0630)
This is the first commercial release of GBSS9.0.
1-2
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)
2-1
BSS
BSC Node Redundancy
2 Overview
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.
2-2
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
Issue 02 (2009-09-30)
2-3
BSS
BSC Node Redundancy
3 Technical Description
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.
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)
3-1
BSS
BSC Node Redundancy
3 Technical Description
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
Issue 02 (2009-09-30)
BSS
BSC Node Redundancy
3 Technical Description
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)
3-3
BSS
BSC Node Redundancy
3 Technical Description
3-4
Issue 02 (2009-09-30)
BSS
BSC Node Redundancy
3 Technical Description
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.
Issue 02 (2009-09-30)
3-5
BSS
BSC Node Redundancy
3 Technical Description
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-6
Issue 02 (2009-09-30)
BSS
BSC Node Redundancy
z
3 Technical Description
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.
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.
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)
3-7
BSS
BSC Node Redundancy
3 Technical Description
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.
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-8
Issue 02 (2009-09-30)
BSS
BSC Node Redundancy
3 Technical Description
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.
Issue 02 (2009-09-30)
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)
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
Peer BSC ID
CN Fault Delay
HostType
Peer BTS ID
Peer BSC IP
ReHost Type
ReHostDelayTime
Issue 02 (2009-09-30)
5-1
BSS
BSC Node Redundancy
5 Parameters
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
0~2047
0~2047
SET BTSIP
None (Mandatory)
BTS
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
Issue 02 (2009-09-30)
BSS
BSC Node Redundancy
Parameter
5 Parameters
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
5-3
BSS
BSC Node Redundancy
6 Counters
6 Counters
None.
Issue 02 (2009-09-30)
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)
7-1
BSS
BSC Node Redundancy
8 Reference Documents
8 Reference Documents
z
Issue 02 (2009-09-30)
8-1