Homing User Manual PDF

Part 1 Overview
Table of Contents ......................................................................................... Chapter 1 Overview ...................................................................................... 1.1 Concepts ........................................................................................... 1.2 Application ........................................................................................ 1.2.1 Application of DH Networking ................................................... 1.2.2 Application of DH + Multi-Area Networking .............................. 1.3 Implementation Principle of DH ........................................................ 1.3.1 Introduction to DH of End Office ............................................... 1.3.2 DH Switch Mode ....................................................................... 1.3.3 Triggering Condition of DH Switch ........................................... 1.3.4 Impact of DH Switch ................................................................. 1.3.5 Derivation of DH Virtual Server ................................................ Chapter 2 FAQ ............................................................................................. i 1-1 1-1 1-4 1-4 1-4 1-5 1-5 1-8 1-9 1-10 1-12 2-1
Part 2 1+1 Assistant Dual-Homing Networking

Table of Contents ......................................................................................... Chapter 1 Introduction to Networking ........................................................... 1.1 Virtual Server Networking ................................................................. 1.2 Mc Interface Networking ................................................................... 1.2.1 Networking Before Switch ........................................................ 1.2.2 Networking After Switch ........................................................... 1.2.3 Impact on Peripheral Network Elements .................................. 1.3 Narrowband Signaling Networking .................................................... 1.3.1 Networking Before Switch ........................................................ 1.3.2 Networking After Switch ........................................................... 1.3.3 Impact on Peripheral Network Elements .................................. 1.4 SIGTRAN Signaling Networking ....................................................... 1.4.1 Networking Before Switch ........................................................ 1.4.2 Networking After Switch ........................................................... 1.4.3 Impact on Peripheral Network Elements .................................. 1.5 Trunk Networking .............................................................................. 1.5.1 Networking Before Switch ........................................................ 1.5.2 Networking After Switch ........................................................... 1.5.3 Impact on Peripheral Network Elements .................................. Chapter 2 Data Planning .............................................................................. 2.1 Capacity Planning ............................................................................. 2.2 Planning Method ............................................................................... 2.3 Data Planning ................................................................................... Chapter 3 Data Configuration ....................................................................... i 1-1 1-1 1-1 1-2 1-3 1-4 1-4 1-5 1-6 1-8 1-9 1-10 1-10 1-12 1-12 1-12 1-13 1-13 2-1 2-1 2-1 2-4 3-1
3.1 Background ....................................................................................... 3.2 Procedure ......................................................................................... 3.3 Configuration Step ............................................................................ 3.3.1 Overview of Configuration Steps .............................................. 3.3.2 Proprietary Data ....................................................................... 3.3.3 Internal Data ............................................................................. 3.3.4 Interconnection Data ................................................................ 3.3.5 Service Data ............................................................................. Chapter 4 Operation and Maintenance ........................................................ 4.1 DH Commissioning ........................................................................... 4.1.1 Verifying That Network Connections Are Normal ..................... 4.1.2 Verifying That DH Heartbeat Link Is Normal ............................ 4.1.3 Verifying Services Before DH Switch ....................................... 4.1.4 Verifying Services Taken Over After DH Switch ....................... 4.2 DH Switch ......................................................................................... 4.2.1 Auto Switch ............................................................................... 4.2.2 Manual Switch .......................................................................... 4.3 DH Backward .................................................................................... 4.3.1 Auto Backward ......................................................................... 4.3.2 Manual Backward ..................................................................... Chapter 5 Commissioning Items .................................................................. 5.1 Networking Description ..................................................................... 5.2 Before Switch .................................................................................... 5.3 After Switch ....................................................................................... 5.4 Backward .......................................................................................... 5.5 Switch Commissioning ......................................................................
3-1 3-1 3-2 3-2 3-3 3-9 3-10 3-13 4-1 4-1 4-1 4-1 4-1 4-1 4-2 4-2 4-3 4-4 4-4 4-4 5-1 5-1 5-2 5-4 5-9 5-11
Part 3 N+1 Backup Dual-Homing Networking

Table of Contents ......................................................................................... Chapter 1 Introduction to Networking ........................................................... 1.1 Virtual Server Networking ................................................................. 1.2 Mc Interface Networking ................................................................... 1.2.1 Networking Before Switch ........................................................ 1.2.2 Networking After Switch ........................................................... 1.2.3 Impact on Peripheral Network Elements .................................. 1.3 Narrowband Signaling Networking .................................................... 1.3.1 Networking Before Switch ........................................................ 1.3.2 Networking After Switch ........................................................... 1.3.3 Impact on Peripheral Network Elements .................................. 1.4 SIGTRAN Signaling Networking ....................................................... 1.4.1 Networking Before Switch ........................................................ i 1-1 1-1 1-1 1-2 1-3 1-4 1-5 1-7 1-8 1-11 1-12 1-13
1.4.2 Networking After Switch ........................................................... 1.4.3 Impact on Peripheral Network Elements .................................. 1.5 Trunk Networking .............................................................................. 1.5.1 Networking Before Switch ........................................................ 1.5.2 Networking After Switch ........................................................... 1.5.3 Impact on Peripheral Network Elements .................................. Chapter 2 Data Planning .............................................................................. 2.1 Capacity Planning ............................................................................. 2.2 Planning Method ............................................................................... 2.3 Planning Data ................................................................................... Chapter 3 Data Configuration ....................................................................... 3.1 Background ....................................................................................... 3.2 Procedure ......................................................................................... 3.3 Configuration Step ............................................................................ 3.3.1 Overview of Configuration Steps .............................................. 3.3.2 Proprietary Data ....................................................................... 3.3.3 Internal Data ............................................................................. 3.3.4 Interconnection Data ................................................................ 3.3.5 Service Data ............................................................................. Chapter 4 Operation and Maintenance ........................................................ 4.1 DH Commissioning ........................................................................... 4.1.1 Verifying That Network Connections Are Normal ..................... 4.1.2 Verifying That DH Heartbeat Link Is Normal ............................ 4.1.3 Verifying Services Before DH Switch ....................................... 4.1.4 Verifying Services Taken Over After DH Switch ....................... 4.2 DH Switch ......................................................................................... 4.2.1 Auto Switch ............................................................................... 4.2.2 Manual Switch .......................................................................... 4.3 DH Backward .................................................................................... 4.3.1 Auto Backward ......................................................................... 4.3.2 Manual Backward ..................................................................... Chapter 5 Commissioning Items .................................................................. 5.1 Networking Description ..................................................................... 5.2 Before Switch .................................................................................... 5.3 After Switch ....................................................................................... 5.4 Backward .......................................................................................... 5.5 Switch Commissioning ......................................................................
1-13 1-15 1-15 1-16 1-16 1-17 2-1 2-1 2-1 2-5 3-1 3-1 3-1 3-2 3-2 3-3 3-9 3-10 3-13 4-1 4-1 4-1 4-1 4-1 4-1 4-2 4-2 4-3 4-4 4-4 4-4 5-1 5-1 5-1 5-4 5-8 5-9
Part 4 Appendix
Table of Contents ......................................................................................... Appendix A Acronyms and Abbreviations .................................................... i A-1
Index ................................................................................................
HUAWEI
1.Overview 2. 1+1 Assistant Dual-Homing Networking 3. N+1 Backup Dual-Homing Networking 4. Appendix
HUAWEI MSOFTX3000 Mobile SoftSwitch Center Dual-Homing User Manual V100R003
Huawei Technologies Proprietary
HUAWEI MSOFTX3000 Mobile SoftSwitch Center Dual-Homing User Manual

Manual Version Product Version BOM T2-030107-20060430-C-3.05 V100R003 31016107
Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. Please feel free to contact our local office or company headquarters.
Huawei Technologies Co., Ltd.

Address: Administration Building, Huawei Technologies Co., Ltd., Bantian, Longgang District, Shenzhen, P. R. China Postal Code: 518129 Website: http://www.huawei.com Email: support@huawei.com
Copyright 2006 Huawei Technologies Co., Ltd.
All Rights Reserved

No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks
, HUAWEI, C&C08, EAST8000, HONET,
, ViewPoint, INtess, ETS, DMC,
TELLIN, InfoLink, Netkey, Quidway, SYNLOCK, Radium, M900/M1800, TELESIGHT, Quidview, Musa, Airbridge, Tellwin, Inmedia, VRP, DOPRA, iTELLIN, HUAWEI OptiX, C&C08 iNET, NETENGINE, OptiX, iSite, U-SYS, iMUSE, OpenEye, Lansway, SmartAX, infoX, and TopEng are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this manual are the property of their respective holders.
Notice
The information in this manual is subject to change without notice. Every effort has been made in the preparation of this manual to ensure accuracy of the contents, but all statements, information, and recommendations in this manual do not constitute the warranty of any kind, express or implied.
About This Manual

Release Notes
This manual applies to HUAWEI MSOFTX3000 Mobile SoftSwitch Center V100R003.
Organization
The manual introduces the dual-homing principle of HUAWEI MSOFTX3000 Mobile SoftSwitch Center (hereinafter referred to as MSOFTX3000). It also details the data planning method of two dual-homing networking schemes. The manual consists of the following parts: Part 1 Overview Chapter 1 Overview introduces the concept, application, and implementation principle of the MSOFTX3000 in the mobile network. Chapter 2 FAQ lists the frequently asked questions involved with the dual-homing application and offers the solutions.
Part 2 1+1 Assistant Dual-Homing Networking Chapter 1 Introduction to Networking focuses on the application of 1+1 assistant dual-homing network, such as virtual server networking, narrowband signaling networking, and trunk networking. Chapter 2 Data Planning details data planning methods in the 1+1 assistant dual-homing network. Chapter 3 Data Configuration concentrates on the data configuration flow and procedures in the 1+1 assistant dual-homing network. Chapter 4 Operation and Maintenance is an introduction to the routine operation and maintenance, including commissioning and switch, in the 1+1 assistant dual-homing network. Chapter 5 Commissioning Items provides the commissioning items used in the dual-homing network.
Part 3 N+1 Backup Dual-Homing Networking Chapter 1 Introduction to Networking focuses on the application of N+1 backup dual-homing network, such as virtual server networking, narrowband signaling networking, and trunk networking. Chapter 2 Data Planning details data planning methods in the N+1 backup dual-homing network. Chapter 3 Data Configuration concentrates on the data configuration flow and procedures in the N+1 backup dual-homing network. Chapter 4 Operation and Maintenance is an introduction to the routine operation and maintenance, including commissioning and switch, in the N+1 backup dual-homing network. Chapter 5 Commissioning Items provides the commissioning items used in the dual-homing network.
Part 4 Appendix Appendix A Acronyms and Abbreviations lists some frequently used acronyms and abbreviations as well as their full names.
Intended Audience
The manual is intended for the following readers:
z z z z
Operation and maintenance engineers Marketing technical personnel Engineering technical personnel Operation and maintenance personnel
Conventions
The manual uses the following conventions:
I. General conventions
Convention Arial Boldface Courier New Description Normal paragraphs are in Arial. Headings are in Boldface. Terminal Display is in Courier New.
II. GUI conventions

Convention <> Description Button names are inside angle brackets. For example, click the <OK> button. Window names, menu items, data table and field names are inside square brackets. For example, pop up the [New User] window. Multi-level menus are separated by forward slashes. For example, [File/Create/Folder].
[]
III. Keyboard operation

Format <Key> <Key1+Key2> <Key1, Key2> Description Press the key with the key name inside angle brackets. For example, <Enter>, <Tab>, <Backspace>, or <A>. Press the keys concurrently. For example, <Ctrl+Alt+A> means the three keys should be pressed concurrently. Press the keys in turn. For example, <Alt, A> means the two keys should be pressed in turn.
IV. Mouse operation

Action Click Double-Click Drag Description Select and release the primary mouse button without moving the pointer. Press the primary mouse button twice continuously and quickly without moving the pointer. Press and hold the primary mouse button and move the pointer to a certain position.
V. Symbols
Eye-catching symbols are also used in the manual to highlight the points worthy of special attention during the operation. They are defined as follows:
Caution: Means reader be extremely careful during the operation. Note: Means a complementary description.
Dual-Homing User Manual HUAWEI MSOFTX3000 Mobile SoftSwitch Center
Table of Contents
Table of Contents
Part 1 Overview
Chapter 1 Overview ....................................................................................................................... 1-1 1.1 Concepts............................................................................................................................ 1-1 1.2 Application ......................................................................................................................... 1-4 1.2.1 Application of DH Networking ................................................................................. 1-4 1.2.2 Application of DH + Multi-Area Networking............................................................. 1-4 1.3 Implementation Principle of DH ......................................................................................... 1-5 1.3.1 Introduction to DH of End Office ............................................................................. 1-5 1.3.2 DH Switch Mode...................................................................................................... 1-8 1.3.3 Triggering Condition of DH Switch .......................................................................... 1-9 1.3.4 Impact of DH Switch.............................................................................................. 1-10 1.3.5 Derivation of DH Virtual Server ............................................................................. 1-12 Chapter 2 FAQ ............................................................................................................................... 2-1

Chapter 1 Introduction to Networking......................................................................................... 1-1 1.1 Virtual Server Networking .................................................................................................. 1-1 1.2 Mc Interface Networking .................................................................................................... 1-1 1.2.1 Networking Before Switch ....................................................................................... 1-2 1.2.2 Networking After Switch .......................................................................................... 1-3 1.2.3 Impact on Peripheral Network Elements................................................................. 1-4 1.3 Narrowband Signaling Networking .................................................................................... 1-4 1.3.1 Networking Before Switch ....................................................................................... 1-5 1.3.2 Networking After Switch .......................................................................................... 1-6 1.3.3 Impact on Peripheral Network Elements................................................................. 1-8 1.4 SIGTRAN Signaling Networking ........................................................................................ 1-9 1.4.1 Networking Before Switch ..................................................................................... 1-10 1.4.2 Networking After Switch ........................................................................................ 1-10 1.4.3 Impact on Peripheral Network Elements............................................................... 1-12 1.5 Trunk Networking............................................................................................................. 1-12 1.5.1 Networking Before Switch ..................................................................................... 1-12 1.5.2 Networking After Switch ........................................................................................ 1-13 1.5.3 Impact on Peripheral Network Elements............................................................... 1-13 Chapter 2 Data Planning............................................................................................................... 2-1 2.1 Capacity Planning .............................................................................................................. 2-1 2.2 Planning Method ................................................................................................................ 2-1
Huawei Technologies Proprietary i
Table of Contents
2.3 Data Planning .................................................................................................................... 2-4 Chapter 3 Data Configuration ...................................................................................................... 3-1 3.1 Background........................................................................................................................ 3-1 3.2 Procedure .......................................................................................................................... 3-1 3.3 Configuration Step ............................................................................................................. 3-2 3.3.1 Overview of Configuration Steps............................................................................. 3-2 3.3.2 Proprietary Data ...................................................................................................... 3-3 3.3.3 Internal Data............................................................................................................ 3-9 3.3.4 Interconnection Data ............................................................................................. 3-10 3.3.5 Service Data.......................................................................................................... 3-13 Chapter 4 Operation and Maintenance........................................................................................ 4-1 4.1 DH Commissioning ............................................................................................................ 4-1 4.1.1 Verifying That Network Connections Are Normal ................................................... 4-1 4.1.2 Verifying That DH Heartbeat Link Is Normal........................................................... 4-1 4.1.3 Verifying Services Before DH Switch ...................................................................... 4-1 4.1.4 Verifying Services Taken Over After DH Switch ..................................................... 4-1 4.2 DH Switch .......................................................................................................................... 4-2 4.2.1 Auto Switch ............................................................................................................. 4-2 4.2.2 Manual Switch ......................................................................................................... 4-3 4.3 DH Backward ..................................................................................................................... 4-4 4.3.1 Auto Backward ........................................................................................................ 4-4 4.3.2 Manual Backward.................................................................................................... 4-4 Chapter 5 Commissioning Items ................................................................................................. 5-1 5.1 Networking Description...................................................................................................... 5-1 5.2 Before Switch..................................................................................................................... 5-2 5.3 After Switch........................................................................................................................ 5-4 5.4 Backward ........................................................................................................................... 5-9 5.5 Switch Commissioning..................................................................................................... 5-11

Chapter 1 Introduction to Networking......................................................................................... 1-1 1.1 Virtual Server Networking .................................................................................................. 1-1 1.2 Mc Interface Networking .................................................................................................... 1-1 1.2.1 Networking Before Switch ....................................................................................... 1-2 1.2.2 Networking After Switch .......................................................................................... 1-3 1.2.3 Impact on Peripheral Network Elements................................................................. 1-4 1.3 Narrowband Signaling Networking .................................................................................... 1-5 1.3.1 Networking Before Switch ....................................................................................... 1-7 1.3.2 Networking After Switch .......................................................................................... 1-8 1.3.3 Impact on Peripheral Network Elements............................................................... 1-11 1.4 SIGTRAN Signaling Networking ...................................................................................... 1-12
Huawei Technologies Proprietary ii
Table of Contents
1.4.1 Networking Before Switch ..................................................................................... 1-13 1.4.2 Networking After Switch ........................................................................................ 1-13 1.4.3 Impact on Peripheral Network Elements............................................................... 1-15 1.5 Trunk Networking............................................................................................................. 1-15 1.5.1 Networking Before Switch ..................................................................................... 1-16 1.5.2 Networking After Switch ........................................................................................ 1-16 1.5.3 Impact on Peripheral Network Elements............................................................... 1-17 Chapter 2 Data Planning............................................................................................................... 2-1 2.1 Capacity Planning .............................................................................................................. 2-1 2.2 Planning Method ................................................................................................................ 2-1 2.3 Planning Data .................................................................................................................... 2-5 Chapter 3 Data Configuration ...................................................................................................... 3-1 3.1 Background........................................................................................................................ 3-1 3.2 Procedure .......................................................................................................................... 3-1 3.3 Configuration Step ............................................................................................................. 3-2 3.3.1 Overview of Configuration Steps............................................................................. 3-2 3.3.2 Proprietary Data ...................................................................................................... 3-3 3.3.3 Internal Data............................................................................................................ 3-9 3.3.4 Interconnection Data ............................................................................................. 3-10 3.3.5 Service Data.......................................................................................................... 3-13 Chapter 4 Operation and Maintenance........................................................................................ 4-1 4.1 DH Commissioning ............................................................................................................ 4-1 4.1.1 Verifying That Network Connections Are Normal ................................................... 4-1 4.1.2 Verifying That DH Heartbeat Link Is Normal........................................................... 4-1 4.1.3 Verifying Services Before DH Switch ...................................................................... 4-1 4.1.4 Verifying Services Taken Over After DH Switch ..................................................... 4-1 4.2 DH Switch .......................................................................................................................... 4-2 4.2.1 Auto Switch ............................................................................................................. 4-2 4.2.2 Manual Switch ......................................................................................................... 4-3 4.3 DH Backward ..................................................................................................................... 4-4 4.3.1 Auto Backward ........................................................................................................ 4-4 4.3.2 Manual Backward.................................................................................................... 4-4 Chapter 5 Commissioning Items ................................................................................................. 5-1 5.1 Networking Description...................................................................................................... 5-1 5.2 Before Switch..................................................................................................................... 5-1 5.3 After Switch........................................................................................................................ 5-4 5.4 Backward ........................................................................................................................... 5-8 5.5 Switch Commissioning....................................................................................................... 5-9
Huawei Technologies Proprietary iii
Table of Contents
Part 4 Appendix
Appendix A Acronyms and Abbreviations .................................................................................A-1 Index ................................................................................................................................................ i-1
Huawei Technologies Proprietary iv
HUAWEI
Part 1 Overview
Table of Contents
Table of Contents
Chapter 1 Overview ....................................................................................................................... 1-1 1.1 Concepts............................................................................................................................ 1-1 1.2 Application ......................................................................................................................... 1-4 1.2.1 Application of DH Networking ................................................................................. 1-4 1.2.2 Application of DH + Multi-Area Networking............................................................. 1-4 1.3 Implementation Principle of DH ......................................................................................... 1-5 1.3.1 Introduction to DH of End Office ............................................................................. 1-5 1.3.2 DH Switch Mode...................................................................................................... 1-8 1.3.3 Triggering Condition of DH Switch .......................................................................... 1-9 1.3.4 Impact of DH Switch.............................................................................................. 1-10 1.3.5 Derivation of DH Virtual Server ............................................................................. 1-12 Chapter 2 FAQ ............................................................................................................................... 2-1
Chapter 1 Overview
Chapter 1 Overview
In the 3GPP R4 networking and later, the MSOFTX3000, as the mobile softswitch center (MSC Server), is located at the control layer of the circuit-switched core network and often covers wide areas. When a disaster occurs, such as maloperation, equipment failure, and a natural disaster, services will be interrupted over a large area, which may lead to great loss. To ensure the security and reliability of mobile networks, Huawei adds a standby MSC Server for a running one. This is called remote disaster recovery of the MSC Server. Normally, the active MSC Server can process all signaling and services. But when the active one becomes faulty, the backup one can provide the same functions as the active one and hence ensure normal running of the mobile network.
1.1 Concepts
The following introduces the key concepts involved with dual homing (DH).
I. MSC Server
MSC Server, also Server or SX (SoftSwitch), is applied to the R4 network, and the MSOFTX3000 acts as the MSC Server.
II. DH
DH is a networking mode. In the 3GPP R4 networking and later, one MGW is homed to two MSC Servers. Normally, an MGW registers with the active MSC Server. When the active MSC Server becomes faulty, the MGW registers with the standby MSC Server so that the subscribers can still enjoy services. Based on the number of MSC Servers in a DH network, there are 1+1 DH and N+1 DH schemes. However, both schemes are the same for the MGW, because each MGW is configured with one active MSC Server and one standby MSC Server.
III. Active MSC Server

When the system runs normally, the active MSC Server, instead of the standby MSC Server, processes all services over the network. As shown in Figure 1-1, SX1 and SX3 are active MSC Servers.
IV. Standby MSC Server

The standby MSC Server, also disaster recovery MSC Server, provides data and backup services for the active MSC Server. As shown in Figure 1-1, SX2 is a standby MSC Server.
Huawei Technologies Proprietary 1-1
Chapter 1 Overview
V. Virtual Server
Virtual Server, also a virtual node, aims at providing the function that a standby MSC Server manages services in multiple active MSC Servers. In such a network, the standby MSC Server (representing 1 in N+1) is logically partitioned into N+1 virtual MSC Servers. The virtual MSC Servers are identified according to Server indexes. Server 0 always serves its own node while others respectively serve as N (the number of virtual Servers except Server 0) standby MSC Servers. See Figure 1-1.
SX1 Heartbeat link SX2 Virtual Server0 Virtual Server1 Virtual Server2 Heartbeat link SX3
MGW1
MGW2
MGW3
Figure 1-1 Schematic illustration of virtual Server
VI. Status of Virtual Server

Each virtual Server has two kinds of status (Active and Deactive). The status of different virtual Servers in the local office is determined by related heartbeat messages. When an active MSC Server is broken down and then restarted, the status of different standby MSC Servers is determined by both the work mode and heartbeat status.
z
Deactive: It indicates the MSOFTX3000 does not activate the node or take over services that belong to the node. Active: It indicates the MSOFTX3000 activates the node and takes over services that belong to the node.
VII. Types of Virtual Server

There are two types of the virtual Server as follows:
z
Local virtual Server: It is the local virtual Server node with the index always as 0 and is auto configured by the system. It manages local services of its own. Virtual Server 0 in SX2, as shown in Figure 1-1, is a local virtual Server.
Non-local virtual Server: It simulates virtual Server nodes of other offices. There can be more than one non-local virtual Servers with the index as 15. It needs to be manually configured. Virtual Server 1 and virtual Server 2 in SX2, as shown in Figure 1-1, are non-local virtual Servers.
Moreover, the non-local virtual Server node is classified as follows:

z
Chapter 1 Overview
Non-assistant Server node: It is a virtual Server node that is not capable of taking over services of its local virtual Server node. Assistant Server node: It is a virtual Server node capable of taking over services of its local virtual Server node.
VIII. Work Mode of MSC Server

MSC Servers work in the following two modes:
z
Standalone: In the work mode, MSC Servers manages services alone. The work mode is not applied to DH. Assistant: In the work mode, if MSC Server B becomes faulty, MSC Server A takes over services of MSC Server B. Then, MSC Server A is considered to be capable of assistance. The work mode is applied to dual homimg.
In the assistant mode, there are two switch modes as follows:

z
Manual: In the Manual switch mode, it is allowed to manually set status of virtual Servers to Active or Deactive. Automatic: In the Automatic switch mode, the system is allowed to auto set DH status based on the status of heartbeat links in a DH network.
In the Automatic switch mode, there are the following takeover modes:
z
Auto takeover: In the Auto takeover mode, a virtual Server can auto take over services of its peer end during an automatic switch. Auto backward: In the Auto backward mode, a virtual Server can auto switch back services of its peer end during an automatic switch. All: In the mode, a virtual Server cannot only auto take over services, but also auto switch back services of its peer end during an automatic switch.
Figure 1-2 shows status conversion of non-local virtual Server nodes when Work mode is set to Assistant, and Switch mode is set to Automatic.
Heartbeat is faulty and Switch mode is set to Auto takeover. Deactive Active DEACTIVE Heartbeat recovers and Switch mode is set to Auto backward. Deactive Active ACTIVE
Figure 1-2 Status conversion of virtual Server
IX. DH Networking Mode

Following are two DH networking modes:

z
Chapter 1 Overview
Assistant: Two parties are each others assistant nodes. They can take over each others services. Backup: The virtual Server node of active MSC Servers is the non-assistant Server node of a standby MSC Server, while the virtual Server node of a standby MSC Server is the assistant Server node of active MSC Servers. Therefore, only the virtual MSC Server of the standby MSC Server can take over services of the active MSC Servers. The virtual MSC Server of the active MSC Servers does not take over services of the standby MSC Server.
1.2 Application
1.2.1 Application of DH Networking
The following are suggestions about the different DH schemes:
z
For disaster recovery for gateway offices and tandem offices, the 1+1 assistant DH scheme is recommended. For disaster recovery for end offices, the N+1 backup DH scheme is recommended.
1.2.2 Application of DH + Multi-Area Networking

DH: It is a Server-based disaster recovery function. One MSC Server can be divided into multiple virtual Servers. Each virtual Server acts as a standby MSC Server and hence one standby MSC Server provides the disaster recovery function for multiple active MSC Servers. Multi area: Logically, in the multi-area network, one MSOFTX3000 manages and maintains multiple local networks. Nowadays, capacity of softswitch becomes larger and softswitch equipment is widely used. Then, the reliability, disaster recovery, and management and maintenance based on different virtual Servers become more and more important. Therefore, the application of the combination of DH and multi-area networking occurs. In a DH network, the standby MSC Server considers a physical active MSC Server a logical MSC Server. Each logical MSC Server performs functions of an independent office. Then the standby MSC Server provides the disaster recovery function of active MSC Servers. In a standby MSC Server, each logical MSC Server is an equivalent of an active MSC Server. In each logical MSC Server, you can create multiple local networks, which bearing services of the multiple local networks. The combination of DH and multi-area networking in the softswitch technology combines disaster recovery and multi-area functions. For example, city A adopts the 2+1 DH scheme in the network, as shown in Figure 1-3. Two active MSC Servers, as independent offices, are respectively divided into three local networks. Each of the active MSC Servers manages and maintains the three local
Chapter 1 Overview
networks of its own. In the standby MSC Server, there are two virtual Servers, which manage six local networks. In this way, not only the DH-based disaster recovery, but also the multi-area-based maintenance and management are performed.
MSOFTX30000 A Heartbeat link MSOFTX30000 B MSOFTX3000 C
Heartbeat link
MGW 1
MGW 2
MGW 3
MGW 4
MGW 5
MGW 6
Active control channel
Standby control channel
Figure 1-3 DH networking in city A (2+1 active and standby DH end offices)
1.3 Implementation Principle of DH

1.3.1 Introduction to DH of End Office
The DH service scheme of the end office adopts N+1 DH backup mechanism. In actual use, the N+1 backup scheme should be adopted for the DH network. Figure 1-4 shows an N+1 backup network.
SX1 Heartbeat link SX2 Heartbeat link SX3
MGW 1
MGW 2
MGW 3 Local network 2
MGW 4 Local network 3
Local network 1
Figure 1-4 N+1 backup scheme (N=2)
Chapter 1 Overview
SX2 is the standby MSC Server of SX1 and SX3. When SX1 (or SX3) is faulty, SX2 will take over its services. Figure 1-5 shows the logical architecture of a DH network. The virtual Server node 0 is the local node of SX1 (active MSC Server), while virtual Server node 1 in SX2 (standby MSC Server) is its assistant node. Bearing services and signaling services managed by MGW 1 are simultaneously connected to the same logical nodes in SX1 and SX2. The service management of the logical node can be flexibly switched according to node activation.
SX1 Node 0 Node 1 BICC UDP heartbeat SX2 Node 1 Node 0
M3UA
MC UA M3
MC MT P3 /M 2U A
MTP3/ M2UA MGW2

MT P3 /M TP 2
MC
MGW1
MT P3 /M TP 2
HLR1
TMSC1
ISUP
HLR1
HLR1
BSC1
Figure 1-5 Logical architecture of 1+1 assistant networking As shown in Figure 1-6, each physical MSC Server can be divided into multiple virtual Servers based on functions. Each virtual Server is configured with related signaling, gateway, trunk and service data of its own.
MC
2 TP /M P3 MT
3B TP M
Chapter 1 Overview
MSC Server-A
Heartbeat control O&M Switch arbitration MSC Server-0 Service subsystem MSC Server-1 Trunk subsystem MSC Server-2 MSC Server-N Gateway subsystem Signaling subsystem
...
...
Figure 1-6 Architecture of MSC Server in DH network
I. Virtual Server Configuration

Logically partition the standby MSC Server (representing 1 in N+1) into N+1 virtual Servers. Then organize and configure the service and data based on the virtual Servers. Adopt the default configuration for virtual Server 0 and manually configure other virtual Servers. In the table of virtual Server nodes, item 0 is always configured for a local MSC Server, while other items are configured for assistant or standby MSC Servers of the local MSC Server. The node ID is uniquely valid in the local MSC Server, and serves as the configuration reference of other service data. Related command: ADD SRVNODE
II. Work Mode Setting

Set DH work mode according to the virtual Server. One virtual Server of the local office and N virtual Servers of other offices can be set to different switch mode. For example,
Chapter 1 Overview
the switch mode of virtual Server 1 can be set to Manual, while that of virtual Server 2 is set to Automatic. Related command: SET DHWM
III. Heartbeat Configuration and Management

Configure and check the heartbeat according to the virtual Server. For different MSC Servers, configure different IP addresses, port numbers and secret keys. To facilitate the check, heartbeat information, transported between two virtual Servers, needs to carry management status of two local Servers. Related command: ADD DHHCFG
IV. Switch Notification

After the status of a virtual Server changes in a local office, the system informs the service module of its original status and destination status. It often occurs when the DH status is manually set or auto switched.
V. Service Takeover of Virtual Server

When a DH status management module informs service modules that a virtual Server node is activated, the service modules will activate the local office information, MGW, BICC link and related signaling and bearer that are homed to the node. Then the virtual Server takes over services of the node.
1.3.2 DH Switch Mode

To realize the DH function between different DH MSC Servers, MSC Server needs to be configured with automatic DH switch function. Following are principles of DH switch:
z
Service logic does not change after the DH switch. For example, between active and standby MSC Servers, the call is the inter-office call, and the switch is the inter-office switch. After the DH switch, and services are transferred to a same MSC Server, the call is still the inter-office call, and the switch is still the inter-office switch. That is to say, physically, there is only one MSC Server, but logically, there is more than one partition.
The DH switch is performed based on the MSC Server. The fault of part of MGW, controlled by on MSC Server, does not trigger the DH switch. The DH switch is triggered, only when the MSC Server becomes faulty. Moreover, all MGWs, controlled by the MSC Server, will be switched to a new MSC Server.
The MSC Server supports the following four DH switch modes:

z
SX-level auto switch
Chapter 1 Overview
If an active MSC Server becomes faulty completely due to power failure or other causes, all MGWs, controlled by the active MSC Server, will auto register to the standby MSC Server.
z
SX-level manual switch When an active MSC Server is going to be moved or upgraded, you can manually transfer its services to the standby MSC Server. To transfer the services, execute the MML command on the active MSC Server.
SX-level manual backward After an active MSC Server is switched to a standby MSC Server, and then the original active MSC Server is recovered and restarted, switch back all services to the original active MSC Server. To switch back all the services, execute the MML command on the original standby MSC Server.
SX-level auto backward After switched to a standby MSC Server, the active MSC Server will auto switch back and take back all services from the standby MSC Server, if it is recovered and restarted, and its heartbeat link is recovered.
In actual conditions, to minimize the time of service interruption and avoid repeated switches during system abnormality, auto switch and manual backward are recommended.
Note: For such network elements as HLR, GMLC, and PSTN except the active and standby MSC Servers, no fault happens to the active and standby MSC Servers during switch (except intermittent blinking of links).
1.3.3 Triggering Condition of DH Switch

DH switch is based on the status of MSC Servers. Therefore, it is triggered by MSC Servers. Different DH switch modes are triggered by different conditions. Following is the introduction to triggering conditions of DH switch:
I. Triggering Condition of Auto Switch

The interruption of heartbeat links is the unique triggering condition of auto switch. Through data configuration, you can specify whether switch and backward is allowed. Following are possible causes of the interruption of heartbeat links:
z
Softswitch equipment is broken down due to power failure.


z z
Chapter 1 Overview
Both the active and standby WIFMs are faulty. All softswitch network ports are faulty.
II. Triggering Condition of Manual Switch

Manually setting the DH status is the unique triggering condition of manual switch. In this case, whether to perform DH switch completely depends on manual setting. If the DH switch cannot be auto triggered, you can trigger it manually. For example, the heartbeat between the active and standby MSC Servers is normal, but all calls are blocked, or CDB is completely faulty, which also causes interruption of all services. In this case, you can manually trigger DH switch.
III. Triggering Condition of Auto Backward

The recovery of heartbeat status is the unique triggering condition of auto backward. If you specify DH backward is allowed through data configuration, and the original active MSC Server and heartbeat are recovered, the original active MSC Server will auto switch back all services from the original standby MSC Server.
IV. Triggering Condition of Manual Backward

Manually setting the DH status is the unique triggering condition of manual backward. In this case, whether to perform DH backward completely depends on manual setting. If you specify DH backward is not allowed through data configuration, and the original active MSC Server and heartbeat are recovered, you can manually switch back all services.
1.3.4 Impact of DH Switch

The DH switch may impact on the mobile communication network.
I. Impact on Call
During the DH switch, all calls, being processed by the original active MSC Server, will be interrupted.
II. Impact on Billing

During the DH switch, bills, not generated by an original active MSC Server in time, will be lost. Bills of calls, made after the switch, are generated on the iGWB of an activated standby MSC Server. The billing center retrieves bill files on the related directory of the iGWB. See Figure 1-7.
Chapter 1 Overview
Bill center
iGWB A (active)
iGWB A (standby)
iGWB B (active)
iGWB B (standby)
MSOFTX3000 A
MSOFTX3000 B
Figure 1-7 Illustration of DH bill principle Before the DH switch, bills, sent from MSOFTX3000 A to iGWB A (active and standby) will be saved in the hard disk of the iGWB A (active and standby), and the bill data will not be lost. Then the billing center can continue to obtain the data from the iGWB (active and standby). During the DH switch, if bills of calls, stably established in the MSOFTX3000 A, have not been generated or sent to the iGWB A, the bills will be lost. The loss of bills does not directly relate to the bill type. Therefore, it is recommended to configure four iGWB addresses for a billing center. Then the billing center can directly obtain bill data from the iGWB, which generates the bill data, instead of considering whether the DH switch takes place. After the DH switch, the iGWB B of the MSOFTX3000 B does not sense the DH switch. The iGWB B generates bills and directories by the same rule as that of the iGWB A of the MSOFTX3000 A.
III. Impact on MGW

During the DH switch, the MGW re-registers to another MSC Server. Calls, borne on resources provided by the MGW, and those are being forwarded, are interrupted because the MGW reclaims all resources.
IV. Impact on Access Side and Trunk Side

During the DH switch or backward, the MSC Server, which is to take over services, will initiate reset to the trunk group. Then, terminals (including callers and callees) whose calls are established will be released on the base station side.
Chapter 1 Overview
V. Impact on Subscriber Data

After the DH switch, the VLR of the original standby MSC Server does not have data of subscribers served by the original active MSC Server. This is because data in the VLR will not be synchronized. When each of the subscribers makes the first call after the DH switch, the MSC Server will refuse the call and force the terminal to perform location update. When the subscriber makes the second call, the call can be successfully connected. When the first call is made to each of the subscribers, the VLR will recover data, obtain the subscriber data from the HLR, and initiate global paging. Then the call can be successfully connected. In the MSOFTX3000V100R003C01B035 and later versions, proceed as follows:
z
Before each of the subscribers makes a call, execute the MML command: SET MAPPARA:ULFORUNUSRMO=YES (default value: NO). Then the first call can be successfully connected.
Before the first call made to each of the subscribers, set bit 3 of software parameter 140 to 0 (default value). Then the first call can be successfully connected.
VI. Impact on Monitoring

The XPTU of an active MSC Server and that of a standby MSC Server are independent of each other. After the DH switch, monitoring data cannot be backed up to the standby MSC Server. So the standby MSC Server does not store the monitoring data and, therefore, cannot auto take over monitoring services. Then, after the DH switch, to generate monitoring, it is necessary to manually re-establish communication between the XPTU of the standby MSC Server and the LIG, re-register, and set related data. The monitoring data set in an MSC Server by the billing center is valid for multiple virtual Server nodes of its own. In addition, there must be voice routes between the billing center and the virtual Server nodes for monitoring output.
1.3.5 Derivation of DH Virtual Server

The derivation of the virtual Server is useful in the following two cases:
z
When activating or deactivating a virtual Server, you need to activate or deactivate related circuits and links according to the index of the virtual Server. During data configuration or data planning, based on the derivation principles, you can make clear the usage scope of the data, and the virtual Server on which the data is configured.
I. Basic Derivation Principle

Following are basic derivation principles:

z
Chapter 1 Overview
The local office information table (ADD OFI) indicates the index of a virtual Server related to a signaling point (SP). The index of a virtual Server, to which the local mobile office information table (ADD INOFFMSC) is homed, is equal to the index of a virtual Server, to which OFI is homed. This is because the local mobile office information table is related to OFI one by one. Note that, the system auto sets that the first SP (set with the command SET OFI) belongs to virtual Server node 0.
z z
Each MGW directly indicates the index of a virtual Server to which it is homed. Multi-area information (MASI) indicates the index of a virtual Server to which one multi-area belongs. If every active MSC Server is a multi-area, make sure that the multi-are indexes of the active MSC Servers are different. Note that, the system has auto created the MASI with the index as 0, which is related to the virtual Server 0.
The BICC SCTP link (ADD BICCSCTPLNK) directly indicates the index of a virtual Server to which the link belongs.
II. Indirect Derivation Principle

Following are indirect derivation principles:
z
Determine the index of a virtual Server Based on OPC
The BSC, RNC and related location area cell obtain the index of an MSC Server through the local office information related to the originating signaling point code (OPC). The MSC Server node, to which an OPC is homed, determines the MSC Server node, to which M3LE and its related data configuration (M3DE, M3LKS, M3RT and M3LNK) are homed. The MSC Server node, to which an OPC is homed, determines the MSC Server node, to which N7DSP and its related data configuration (N7LKS, N7RT and N7LNK) are homed. The MSC Server node, to which an OPC is homed, determines the MSC Server node, to which data configuration of SCCPDSP and SCCPSSN over the SCCP layer is homed.
z
Determine the index of a virtual Server Based on MGW
The trunk group of the ISUP, TUP, PRA, A interface, BICC and TK directly indicates the index of the MGW, to which the trunk group belongs. The office direction of the ISUP, TUP, PRA and R2, based on the trunk group, and the index of the virtual Server, to which trunk circuits of the trunk group belong, are determined by trunk group. The virtual Server node, to which the ESG is homed, determines the virtual Server node, to which link sets and links of M2UA or IUA are homed. The virtual Server node, to which the MGW is homed, determines the virtual Server node, to which the ESG is homed.
Chapter 1 Overview
The virtual Server node, to which the MGW is homed, determines the virtual Server node, to which the H248LNK is homed.
z
Determine the index of a virtual Server Based on BICCSCTPLNK
The BICC office direction determines the index of a virtual Server to which it is homed through the related BICCSCTPLNK. BICCCICMDU determines the index of a virtual Server to which it is homed through the BICC office direction.
III. Relation of Activation and Deactivation Between Node and Data

The data of activation and deactivation of virtual Server nodes is processed according to the previous derivation principles. Data of all virtual Servers is stored in the BAM database and host database. When a virtual Server node is activated, the functional block of service application layers loads data of the virtual Server from the host database. When a virtual Server node is deactivated, the functional block of service application layers unloads data of the virtual Server from the host database.
Chapter 2 FAQ
Chapter 2 FAQ
The following are frequently asked questions (FAQs) in applications of DH networking and answers to them.
Q: How Are the HLR and LSTP Connected to the MSC Server?
A: For pure signaling network elements such as the HLR, LSTP, and SCP, network operators normally require to connect them with the MSC server through TDM/ATM direct signaling connections. The networking scheme at the route priority level is recommended. Figure 2-1 shows a networking model. If MGW/SG is used to convert the signaling into IP signaling, the networking scheme at the link priority level is used for the MSC server.
Link set 1 HLR (C)
Link set 2
SX1 (Active SPC: A)
SX2 (Active SPC: B)
Figure 2-1 Networking model There are two routes from SPC C to SPC A:
z z
Route 1 goes through link set 1. The priority of this route is high. Route 2 goes through link set 2. The priority of this route is low.
All links from SPC C to SPC A are in the path between the HLR and SX1. A maximum of 16 links can be configured. The advantages of this mode is as follows: None of the links of the HLR is wasted. This is a big advantage in the case of TDM signaling and 1+1 assistant mode or N+1 backup mode. It avoids the situation that half of the links of the HLR are faulty. The prerequisite of this mode is that the SG or external network elements need to be capable of configuring signaling route priorities.
Q: How Is the Data of an Active MSC Server Synchronized with That of a Standby MSC Server and keep their data consistent?
A: Manually configure the data of an active MSC server and a standby MSC server respectively, and keep the data consistent manually.
Chapter 2 FAQ
Q: Why Is 5 the Maximum Value for N in the N+1 Backup Mode?

A: In the N+1 backup mode, the host of the standby MSC server stores data of N servers (mapping to N virtual nodes). In the case of switchover, the standby MSC server activates a virtual node and uses its data. If N is too big, the amount of data in the standby MSC server is too large. This causes the amount of data of a table to exceed the maximum number of tuples of the table. If N is too big or the capacity of each virtual node is too large, tables whose maximum number of tuples may be exceeded include the trunk circuit table (10,000 trunks at most per module and 45 WCCU modules at most) and the LAI information table whose maximum number of tuples is 4,096. The tables are related to both N and the total capacity. Therefore, the total backup capacity is 2,000,000 subscribers.
Q: How Many LICENSE Subscribers Can a Network Operator Apply for in the Case of DH Networking?
A: The number of LICENSE subscribers of each MSC server is the number of subscribers of each MSC server plus the number of subscribers of a standby MSC server with the largest capacity. In the 1+1 assistant mode, if the numbers of subscribers of two MSC servers are 500,000 and 1,000,000, apply for 600,000 LICENSE subscribers for each MSC server. In the 3+1 backup mode, if the numbers of subscribers of three MSC servers are 100,000, 200,000, and 300,000, apply for 300,000 LICENSE subscribers for the standby MSC server. When configuring the processing capability of MSC servers, reserve some redundancy as well.
Q: Can I Use DH and IU-FLEX at the Same Time?

A: DH and IU-FLEX cannot be used at the same time. Both features are designed to achieve disaster tolerance purposes. If both features are used at the same time, the network structure is too complicated and makes maintenance and configuration difficult. Huawei has not tested or verified an application using both features at the same time.
Q: What Is the Limitation of DH in the Actual Applications?

A: Only the following basic signaling is supported: MTP3, M2UA, M3UA, and IUA. Only the following trunk signaling is supported: BICC, ISUP, TUP, and PRA. The N+1 DH networking mode in which N is greater than 5 is not supported. The switchover in which services of multiple MSC servers are taken over is not supported. DH switchover cannot be triggered by partial fault of the MSC server or Mc interface fault. The switchover is only based on heartbeat messages. The DH mode in which the MSC server directly provides MTP3B links is not supported. Dynamic synchronization of data between MSC servers is not supported.
Chapter 2 FAQ
Dynamic synchronization of VLR subscriber data between MSC servers is not supported.
Q: What Should I Note in an Application Combining DH and Multi-Area Features?

A: A virtual server in the DH networking is an independent office. It can control several multi-area networks. You need to configure data of the multi-area networks by segmenting it. The total number of multi-area networks managed by a virtual server should not be greater than 8.
Q: How Do I Configure the Number of the WBSGs When M2UA Links Are Adopted?
A: When MTP3 is borne over M2UA links, 32 N7LNKs can be configured at most for each WBSG. In the DH link priority scheme, the number of N7LNKs configured for an SX is the number of N7LNKs of the node plus that of the standby node. Therefore, the number of WBSGs configured for the MSC server is the total number of N7LNKs divided by 32.
Q: What Is the Suggested Heartbeat Duration for a DH Network? Why?

A: By default, the heartbeat link is considered interrupted if a heartbeat message is not detected within 150 seconds (30 signals x 5 seconds/signal = 150 seconds). If the threshold is set to a period much shorter than 150 seconds, frequent DH switchover may occur because heartbeat links may be interrupted intermittently when the quality of IP network is poor. If the threshold is set to a period much longer than 150 seconds, services may be interrupted for a long time because the MSC server is down. By default, a heartbeat link is considered restored if a heartbeat message is detected within 75 seconds.
Q: What Should I Do After the DH Switchover Occurs?

A: You need to notify personnel at the billing center, lawful interception center, and network management center to modify the configuration of interfaces for interworking with the MSC.
Q: Should I Remove Subscriber Data in the VLR After Manual DH Switchover?

A: During manual DH switchover, the virtual server node of the MSC server whose services are taken over is deactivated. The VDB removes all subscriber data of the virtual server node without waiting for the location update of subscribers. The VLR timer is set to 50 milliseconds. Every time timeout occurs, data of up to 200 subscribers can be removed. Because each board can be configured with 200,000 subscribers at most, removing the data takes 50 seconds.
Chapter 2 FAQ
Q: Do Inter-Office Calls and Inter-Office Handover Change After DH Switchover? Why?

A: No logical change is made to calls after the DH switchover. Inter-office calls remain inter-office, and inter-office handover remains inter-office. Inter-office calls are distinguished by DN sets. Calls in the same virtual MSC server are considered as intra-office ones. Calls in different virtual MSC servers are considered as inter-office ones. If the original and destination location areas of handover belong to different virtual MSC servers, the handover is considered as an inter-office one.
Q: Why Are Auto Switchover and Manual Backward Recommended in DH? How Do I Set Them?
A: Auto switchover means that the system switches over to the standby MSC server when the active server is down. This meets the requirement of network operators. If the system is automatically switched back immediately after the faulty MSC server is restored, call loss rate may be increased during the switchover. Therefore, you are recommended to configure backward manually when the traffic is lightest. To configure backward, proceed as follows: Set DH work mode on the active MSC server. Set Work mode to Assistant, Server node index to 0, Switch mode to Automatic, and Takeover mode to No auto takeover:
SET DHWM: WM=ASSIST, SI=0, SM=AUTO, TM=MODE1-0;
Set DH work mode on the standby MSC server. Set Work mode to Assistant, Server node index to 1, Switch mode to Automatic, and Takeover mode to Auto takeover and no auto backward:
SET DHWM: WM=ASSIST, SI=1, SM=AUTO, TM=MODE1-1&MODE2-0;
Q: What Is Dual Activation? Why Does It Happen? What Effect Does It Have?
A: Dual activation means that both node 0 of the active MSC server and other office nodes of the standby MSC server are active. That is, the same logical virtual node is active on two MSC servers. Dual activation may occur when either of the following happens: Dual activation is configured manually. The status of both MSC servers is normal. Loss of heartbeat signals, however, triggers dual activation. In case of dual activation, signaling links of the active MSC server are preferred. If the MGW also registers with the active MSC server, services are not affected. Because the standby MSC server node is active, backup data is loaded and some alarms are generated. If the MGW registers with the standby MSC server, you need to configure DH switchover manually.
Chapter 2 FAQ
If dual activation occurs, repair heartbeat links immediately so that the active and standby MSC servers use heartbeat links to auto check the states of virtual nodes. As a result, virtual node 0 of the active MSC server is active, and the virtual node of the standby MSC server is deactivated. Or set DH mode manually. Set a virtual node to deactivated.
Q: Why Should TDM Signaling Be Transferred by MGW/SG?

A: Because heartbeat links are borne over IP, dual activation occurs if the IP bearer network of the active MSC server is faulty. H.248 signaling is also borne over IP. TDM signaling of network elements is transferred by the MGW/SG in link priority mode, not directly processed by the WEPI of the MSC server in route priority mode. This avoids the situation in which TDM signaling is routed to the active MSC server, and IP signaling to the activated standby MSC server in dual activation.
Q: Can DH Be Implemented by Narrowband Signaling in Direct Connection Mode? Why?

A: Narrowband signaling in direct connection mode supports DH as well. DH in this case can be implemented in two modes: homing to different virtual MSC servers and DH in route priority mode. In the first mode, narrowband signaling such as MTP3 links queries the local office table according to the original signaling point (OSP) used by the link set that the MTP3 links belong to. This clarifies the mapping between each link and a virtual MSC server. Then the system determines whether to load dynamic data of a link according to the state of the virtual MSC server. The active and standby link feature is implemented. Because of link alarms and limitations on the number of links, the second mode is recommended. For details, see question one of this section.
Q: What Is the Difference Between the Data Configuration of an Active MSC Server and That of a Standby MSC Server?
A: In pure active and standby mode, the standby MSC server does not provide services, and it acts as a pure standby office. The active MSC does not need to assist other offices. In active and standby mode, the data configuration of the active and standby MSC servers is different. The data configuration of the active MSC server includes two parts:
z z
All service data of the active MSC server Virtual node and heartbeat links mapping to the standby MSC server
This data configuration is for the heartbeat connection between the active and standby MSC servers. The data configuration of the standby MSC server also includes two parts:
z z
Backup service data of the active MSC servers Virtual node of the standby MSC server
Chapter 2 FAQ
This is for the standby MSC server to run without load in normal cases.
Q: How Is the System Affected if an MGW Switches Over to the Standby MSC Server in Dual Activation? Why Are Calls Not Affected When an MGW of the Active MSC Server Registers with the Standby One?
A: If dual activation occurs because heartbeat links are interrupted, an MGW is disconnected from the active MSC server. So the MGW registers with the standby MSC server. Check whether signaling links to the active MSC server are normal. If yes, the circuits of the MGW are unavailable. All calls processed by the MGW fail. If SS7 signaling links to the active MSC server are faulty, the circuits of the MGW are available. The call connection depends on whether the HLR interface and IN interface related to the calls can switch over to the standby MSC server. If all signaling interfaces used by the call through the MGW switch over to the standby MSC server, calls can be connected as well. Calls of the standby MSC server are not affected. You are recommended to repair faulty MGW or links.
Q: Which Data Tables Need an Increase of the Maximum Number of Tuples? What Value Should the Number Be Increased to?
A: See the data planning restriction of related sections of networking in this manual.
Q: How Do I Configure the DH Data if I Want to Change an Ordinary Office in Service to a DH Office?
A: The office to be changed bears services independently. To change it to a DH office: Set Work mode to Assistant. Set Force state of local office node 0 to Activated. Set Force state of other office nodes (with Server node index greater than or equal to 1) to Deactivated.
HUAWEI
Table of Contents
Table of Contents
Chapter 1 Introduction to Networking......................................................................................... 1-1 1.1 Virtual Server Networking .................................................................................................. 1-1 1.2 Mc Interface Networking .................................................................................................... 1-1 1.2.1 Networking Before Switch ....................................................................................... 1-2 1.2.2 Networking After Switch .......................................................................................... 1-3 1.2.3 Impact on Peripheral Network Elements................................................................. 1-4 1.3 Narrowband Signaling Networking .................................................................................... 1-4 1.3.1 Networking Before Switch ....................................................................................... 1-5 1.3.2 Networking After Switch .......................................................................................... 1-6 1.3.3 Impact on Peripheral Network Elements................................................................. 1-8 1.4 SIGTRAN Signaling Networking ........................................................................................ 1-9 1.4.1 Networking Before Switch ..................................................................................... 1-10 1.4.2 Networking After Switch ........................................................................................ 1-10 1.4.3 Impact on Peripheral Network Elements............................................................... 1-12 1.5 Trunk Networking............................................................................................................. 1-12 1.5.1 Networking Before Switch ..................................................................................... 1-12 1.5.2 Networking After Switch ........................................................................................ 1-13 1.5.3 Impact on Peripheral Network Elements............................................................... 1-13 Chapter 2 Data Planning............................................................................................................... 2-1 2.1 Capacity Planning .............................................................................................................. 2-1 2.2 Planning Method ................................................................................................................ 2-1 2.3 Data Planning .................................................................................................................... 2-4 Chapter 3 Data Configuration ...................................................................................................... 3-1 3.1 Background........................................................................................................................ 3-1 3.2 Procedure .......................................................................................................................... 3-1 3.3 Configuration Step ............................................................................................................. 3-2 3.3.1 Overview of Configuration Steps............................................................................. 3-2 3.3.2 Proprietary Data ...................................................................................................... 3-3 3.3.3 Internal Data............................................................................................................ 3-9 3.3.4 Interconnection Data ............................................................................................. 3-10 3.3.5 Service Data.......................................................................................................... 3-13 Chapter 4 Operation and Maintenance........................................................................................ 4-1 4.1 DH Commissioning ............................................................................................................ 4-1 4.1.1 Verifying That Network Connections Are Normal ................................................... 4-1 4.1.2 Verifying That DH Heartbeat Link Is Normal........................................................... 4-1 4.1.3 Verifying Services Before DH Switch ...................................................................... 4-1 4.1.4 Verifying Services Taken Over After DH Switch ..................................................... 4-1
Table of Contents
4.2 DH Switch .......................................................................................................................... 4-2 4.2.1 Auto Switch ............................................................................................................. 4-2 4.2.2 Manual Switch ......................................................................................................... 4-3 4.3 DH Backward ..................................................................................................................... 4-4 4.3.1 Auto Backward ........................................................................................................ 4-4 4.3.2 Manual Backward.................................................................................................... 4-4 Chapter 5 Commissioning Items ................................................................................................. 5-1 5.1 Networking Description...................................................................................................... 5-1 5.2 Before Switch..................................................................................................................... 5-2 5.3 After Switch........................................................................................................................ 5-4 5.4 Backward ........................................................................................................................... 5-9 5.5 Switch Commissioning..................................................................................................... 5-11
Chapter 1 Introduction to Networking

The 1+1 assistant dual homing (DH) scheme is recommended to disaster recovery for gateway offices and tandem offices.
1.1 Virtual Server Networking

Figure 1-1 shows the virtual Server networking of the 1+1 assistant dualhoming scheme.
index 0 1 server SX-1 SX-2 index 0 1 server SX-2 SX-1
SX-1
SX-2
Figure 1-1 Virtual Server node configuration of 1+1 assistant dualhoming scheme For two assistant MSC Servers, virtual Server 0s are fixedly configured as local virtual Server nodes respectively, while virtual Server 1s are configured as nonlocal virtual Server nodes respectively. When configuring nonlocal virtual Server node 1s in the two MSC Servers, set them to the nodes which are assistant ones of the local ones.
1.2 Mc Interface Networking

In the network adopting the 1+1 assistant dualhoming scheme, telecom operators offer two MSOFTX3000s in the MSC Server layer and configure both of them as active MSC Servers, which also back up each other. In other words, both of MSOFTX3000s are active MSC Servers, and also assistant MSC Servers of each other. Figure 1-2 shows the typical networking. In such a network, MSOFTX3000 A and MSOFTX3000 B are in charge of their own services. At the same time, they act as standby MSC Servers of each other.

MSOFTX30000 A Heartbeat link MSOFTX3000 B
MGW 1
MGW 2
MGW 3
MGW 4
Local network A
Local network B
Figure 1-2 1+1 assistant dualhoming networking scheme
1.2.1 Networking Before Switch

Normally, MSOFTX3000 A controls services of local network A, that is, MGW 1 and MGW 2 initiate register requests to MSOFTX3000 A only. Likewise, in normal cases, MSOFTX3000 B controls services of local network B, that is, MGW 3 and MGW 4 initiate register requests to MSOFTX3000 B only. See Figure 1-3.
MSOFTX30000 A Heartbeat link MSOFTX3000 B
MGW 1
MGW 2
MGW 3
MGW 4
Local network A
Local network B
Figure 1-3 1+1 assistant dualhoming networking before switch
1.2.2 Networking After Switch

I. When the SOFTX3000 A Is Faulty
When MSOFTX3000 A becomes faulty or suffers from burst disasters, MSOFTX3000 B will take over services of local network A. In other words, MGW 1 and MGW 2 will initiate register requests to MSOFTX3000 B instead of MSOFTX3000 A, which is the original active MSC Server of them. Figure 1-4shows the networking after switch.
MSOFTX30000 A MSOFTX30000 B
Heartbeat link
MGW 1
MGW 2
MGW 3
MGW 4
Local network A
Local network B
Figure 1-4 1+1 assistant dualhoming networking after switch due to fault of MSOFTX3000 A
II. When the SOFTX3000 B Is Faulty

When MSOFTX3000 B becomes faulty or suffers from burst disasters, MSOFTX3000 A will take over services of local network B. In other words, MGW 3 and MGW 4 will initiate register requests to MSOFTX3000 A instead of MSOFTX3000 B, which is the original active MSC Server of them. Figure 1-5 shows the networking after switch.

MSOFTX30000 A MSOFTX30000 B
Heartbeat link
MGW 1
MGW 2
MGW 3
MGW 4
Local network A
Local network B
Figure 1-5 1+1 assistant dualhoming networking after switch due to fault of MSOFTX3000 B
1.2.3 Impact on Peripheral Network Elements

If dual activation occurs (for example, only the heartbeat link between MSOFTX3000 A and MSOFTX3000 B is interrupted), the virtual Server corresponding to MSOFTX3000 A in MSOFTX3000 B will be activated and backup data of MSOFTX3000 A configured in MSOFTX3000 B will be loaded. However, IP connection between MSOFTX3000 A and the MGWs works normally, so MGW 1 and MGW 2 still register with MSOFTX3000 A instead of MSOFTX3000 B. The only difference is that two faulty MGWs are added to MSOFTX3000 B and there is no impact on services.
1.3 Narrowband Signaling Networking
Note: The narrowband signaling networking is not recommended to the 1+1 assistant networking. However, if you have to adopt the networking mode, apply it to the STP (including HSTP and LSTP) connected to a toll office only. In such a network, the STP and the local MSC Server are connected over TDM.
If the MSOFTX3000 directly offers TDMbased narrowband signaling links, it is recommended to set routing priority for networking. Figure 1-6 shows the network layout.
LSTP A SP C LSTP B SP D
Priority 3
Priority 1 Priority 2
MSOFTX3000 A SP A MSOFTX3000 B SP B
Heartbeat link
MGW 1
MGW 2
Active control channel Link set A<->D Link set B<->D Link set C<->D
Standby control channel Link set A<->C Link set B<->C
Figure 1-6 1+1 assistant dualhoming network with narrowband signaling routing priority In Figure 1-6, MSOFTX3000 A and MSOFTX3000 B correspond to LSTP A and LSTP B respectively. All narrowband signaling messages are transmitted to other local central offices through the LSTP of its own. In the dualhoming network, there are two signaling routes from LSTP A to its DSP (SP A). One with the higher priority is the link set CA, and the other with the lower priority is the link set CB. Between LSTP A and LSTP B, there is a signaling route which serves as the final standby route.

Take MSOFTX3000 A as an example and the rule is also applied to other MSC Servers. From LSTP A to SP A, the direct signaling route is link set CA, while from LSTP B to SP B, the direct signaling route is link set DB. Other signaling routes are standby routes with lower priorities. Figure 1-7 shows the networking before switch.
LSTP A SP C
Priority 3
LSTP B SP D
Priority 1 Priority 2
MSOFTX3000 A SP A
Priority 1
MSOFTX3000 B SP B
Heartbeat link
MGW 1
MGW 2
Link set A<->D Link set B<->D Link set C<->D
Link set A<->C Link set B<->C
Figure 1-7 1+1 assistant dualhoming narrowband signaling networking before switch

I. MSOFTX3000 A Fault
After MSOFTX3000 A is switched, SP B takes over signaling services of SP A. From LSTP A to SP A, the second signaling route SP CSP B is adopted. Then, through the SP assistance function of MSOFTX3000 B, the signaling services to SP A are performed. Figure 1-8 shows the networking after the switch.
LSTP A SP C
LSTP B SP D
MSOFTX3000 A SP A
Heartbeat link
MSOFTX3000 B SP B/SP A
MGW 1
MGW 2
Figure 1-8 1+1 assistant dualhoming narrowband signaling networking after switch of MSOFTX3000 A
II. MSOFTX3000 B Fault

After MSOFTX3000 B is switched, SP A takes over signaling services of SP B. From LSTP B to SP B, the second signaling route SP DSP A is adopted. Then, through the SP assistance function of MSOFTX3000 A, the signaling services to SP B are performed. Figure 1-9 shows the networking after the switch.
LSTP A SP C
LSTP B SP D
MSOFTX3000 A SP A/SP B
Heartbeat link
MSOFTX3000 B SP B
MGW 1
MGW 2
Figure 1-9 1+1 assistant dualhoming narrowband signaling networking after switch of MSOFTX3000 B

Following are impacts on peripheral network elements:
z
Two signaling routes with different priorities need to be configured between the destination signaling point (DSP) (active/standby MSC Server) and peripheral equipment. The signaling route with higher priority is configured between an active MSC and the peripheral equipment, and the signaling route with lower priority is configured between a standby MSC and the peripheral equipment.
After the switch, a standby MSC Server takes over signaling services of an active MSC Server through the original signaling link of the standby MSC Server. Therefore, the load of the signaling link will be increased, especially when MSC Servers use multiSP services. Then, it is suggested to adopt the 2 Mbit/s link for the narrowband link between the standby MSC Server and the peripheral equipment.
Such problems as link alarm and limitation to the number of links will not occur, because different link sets are used for the connection between the active MSC Server and the peripheral equipment and that between the standby MSC Server and the peripheral equipment.
If dual activation occurs (for example, due to interruption of heartbeat between MSOFTX3000 A and MSOFTX3000 B is interrupted), the virtual Server, corresponding to MSOFTX3000 A, in the MSOFTX3000 B (standby MSC Server)
will be activated. In addition, the backup data of MSOFTX3000 configured in the virtual Server will be loaded. However, MSOFTX3000 A and MSOFTX3000 B are configured with active narrowband link data of their own only. Therefore, the status of narrowband links will not be changed. Moreover, signaling routes are configured with different priorities so that straight link sets take precedence of other signaling routes from the peripheral equipment to MSOFTX3000 A and MSOFTX3000 B.
1.4 SIGTRAN Signaling Networking
Caution: The networking is recommended to pure gateway offices or tandem offices. If the offices are connected to STP, HLR, other MSCs in the network, or network elements in other networks, the M3UA configuration of the SIGTRAN signaling networking is recommended. The MSOFTX3000 directly offers IP bearerbased M3UA wideband signaling links.
Figure 1-10 shows the SIGTRAN networking layout, where the MSC and PSTN in other networks are connected.
MSOFTX3000 A
Heartbeat link
MSOFTX3000 B
SG 1
SG2
SG3
Local network A
Loca network B
MSC1
PSTN
MSC2
High priority link (active)
Low priority link (standby)
Figure 1-10 1+1 assistant SIGTRAN signaling networking

Before the switch, SIGTRAN signaling between the signal gateway (SG) and the MSOFTX3000 is delivered over the SIGTRAN link with the higher priority (connected to an active MSC Server). Figure 1-11 shows the networking before the switch.
MSOFTX3000 A
Heartbeat link
MSOFTX3000 B
SG 1
SG2
SG3
Local network A
Local network B
MSC1
PSTN
MSC2
Figure 1-11 1+1 assistant dualhoming SIGTRAN signaling networking before switch

I. MSOFTX3000 A Fault
Figure 1-12 shows the networking after MSOFTX3000 A is switched due to fault. In the network, the link between SGs (1 and 2) and their active MSC Server (MSOFTX3000 A) is interrupted. Then, SIGTRAN signaling from SG 1 and SG 2 is delivered over the SIGTRAN link (with lower priority) connected to their standby MSC Server (MSOFTX3000 B).
MSOFTX3000 A
Heartbeat link
MSOFTX3000 B
SG 1
SG2
SG3
Local network A
Local network B
MSC1
PSTN
MSC2
Figure 1-12 1+1 assistant dualhoming SIGTRAN signaling networking after switch of MSOFTX3000 A
II. MSOFTX3000 B Fault

Figure 1-13 shows the networking after MSOFTX3000 B is switched due to fault. In the network, the link between SG 3 and their active MSC Server (MSOFTX3000 A) is interrupted. Then, SIGTRAN signaling from SG 3 is delivered over the SIGTRAN link (with lower priority) connected to their standby MSC Server (MSOFTX3000 A).
MSOFTX3000 A
Heartbeat link
MSOFTX3000 B
SG 1
SG2
SG3
Local network A
Local network B
BSC1
PSTN
BSC2
Figure 1-13 1+1 assistant dualhoming SIGTRAN signaling networking after switch of MSOFTX3000 B

Following are impacts on peripheral network elements:
z
The priorities of SIGTRAN links, configured from SG to MSC Server, are different. The SIGTRAN link configured from the SG to its active MSC Server takes precedence of the one from the SG to its standby MSC Server.
If dual activation occurs (for example, only the heartbeat link between MSOFTX3000 A and MSOFTX3000 B is interrupted), the virtual Server corresponding to MSOFTX3000 A in MSOFTX3000 B will be activated, backup data of MSOFTX3000 A configured in MSOFTX3000 B will be loaded, and the SIGTRAN link from SG 1 and SG 2 to MSOFTX3000 B will be activated. For signaling originated by MSOFTX3000 A, there is no impact because the signaling is still forwarded by SG 1 and SG 2 to the corresponding MSC and PSTN. For signaling originated by MSC 1 or PSTN, there is no impact either because the signaling is still forwarded by SG 1 and SG 2 to MSOFTX3000 A over the link with the higher priority. Since the link from SG 1 and SG 2 to MSOFTX3000 B is activated, there is no impact because the priority of the link is lower.
1.5 Trunk Networking

Figure 1-14 shows the trunk networking before the dualhoming switch.
MSOFTX3000 A
Heartbeat link
MSOFTX3000 B
SG 1
SG2
SG3
Local network A
Local network B
MSC1
PSTN
MSC2
Figure 1-14 1+1 assistant trunk networking In the network of 3GPP R4, the call control and bearer of MSC Server are separated. For signaling networking application in the DH network, refer to the last three sections.
Trunk voice route networking means the voice route networking between SG and its peripheral network elements or other SGs. During a dualhoming switch, only SG might be switched and register with another MSC Server. The trunk voice routes between SGs remain unchanged.

No matter whether DH switch is performed, trunk voice routes, in the trunk networking between assistant offices, still serve as bearers between two SGs, and calls are still inter-office calls. The only difference after the DH switch is that signaling between assistant offices auto generates the MTP3 layer-based self-loop. See Figure 1-15.
MSOFTX3000 A
Heartbeat link
MSOFTX3000 B
SG1
SG2
SG3
Local network A
Local network B
MSC1
PSTN
MSC2
High priority link (active) Low priority link (standby) Signaling link between assistant offices Trunk circuit between assistant offices
Figure 1-15 Trunk networking between 1+1 assistant offices

z z
There is no impact on data configuration of peripheral network elements. During the switch, some idle circuits might become faulty, and then idle. Then, such messages as hardware block and circuit reset might be generated. All this is normal.
Chapter 2 Data Planning

2.1 Capacity Planning
DH, often together with large capacity, can effectively promote system security, enhance networking flexibility, and reduce cost. However, the larger the better is not always the case. The capacity planning can not exceed the total capacity of the system. For each MSC Server, the number of LICENSE subscribers is the total number of local subscribers and that of a standby MSC Server with the highest capacity. For example, in a 1+1 assistant DH network, if the number of subscribers of two MSC Servers is 500,000 and 100,000 respectively, apply for a LICENSE of 600,000 subscribers for each of the two MSC Servers. Capacity planning for trunks: In the 1+1 assistant DH network, configure the trunk capacity for one office according to the sum of trunk capacity of two offices. Capacity planning for links:
z
For M3UA-based links, configure the number of WBSGs on an MSC Server according to the total number of M3UA links in two active MSC Servers. For MTP2-based SS7 links, configure the number of WCSUs on an MSC Server according to the total number of SS7 links in two active MSC Servers. For M2UA-based SS7 links, configure the number of WBSGs on an MSC Server according to the total number of SS7 links in two active MSC Servers.
2.2 Planning Method

There are three data planning methods. In actual conditions, adopt different methods for planning different data.
I. Method One
Adopt independent segments for data. With the method, the segments of data on both of two assistant MSC Servers are put together to be planned and two separate data segments are completely independent. Note that, before planning an independent data segement for each active MSC Server, reserve some resources for subsequent capacity expansion. Data feature: The data is unique in a global table. In a standby MSC Server, the sum of a kind of data on all active MSC Servers should not exceed the maximal tuple number in the table. Key data: SRVNODE, DHWM, DHHCFG, local office information, INOFFMSC, MGW, trunk group, ESG, M3LE, M3DE, N7DSP, SCCPDSP, SCCPSSN, link set, signaling
route, route, sub-route, routing analysis, MHPREFIX, MHSUFFIX, MHMSCCFG, MASI, RNC, BSC, LAIGCI, LAISAI, and ACPOOL. See Figure 2-1.
SX 0
Trunk group 0 - 99 100 - 199
SX 1
0 - 99 100 - 199 Trunk group

Data segment A of virtual Server in SX 0 Data segment B of virtual Server in SX 1
Figure 2-1 Data segment in 1+1 assistant DH network (method one) Following are planning steps: 1) 2) 3) Plan data segment ranges (A and B) for two active MSC Servers respectively. Configure data for each of the active MSC Server within its own data segment range. Copy the configured data of active MSC Servers to each others peer office as backup data.
II. Method Two

Adopt the combination of public segment and independent segments for data. With the method, a public data segment is reserved for common use by MSC Servers. Then, allocate data segments for independent use of each active MSC Server. Data feature: The data is unique in a global table. In the table, some data might be shared among multiple MSC Servers. For example, for offices connecting to a same provinceclass tandem office, they share a same index of the office direction. Key data: Office direction, SCCPGT, dialed number set (DN set), call source, and callee analysis. See Figure 2-2.
SX0 0-99 OFC 100-599 600-1099
0-99
100-599 OFC SX1
600-1099
Public data segment A Data segment B of virtual Server in SX 0 Data segment C of virtual Server in SX 1
Figure 2-2 Data segment in 1+1 assistant DH network (method two) Following are planning steps: 1) 2) Plan a public data segment range A and two independent data segment ranges B and C for two active MSC Servers. Configure data for each of the active MSC Server within the public data segment range and its own data segment range.
III. Method Three

Plan data segment in a standby MSC Server and randomly configure data in an active MSC Server. With the method, independent data segments are planned in standby MSC Servers for active MSC Servers according to the amount of the data of the active MSC Servers. Then, the data of the active MSC Servers are mapped to the corresponding data segments in the standby MSC Servers. Data feature: The data is unique in a module table. Data of modulerelated physical resources such as links, circuits and BICC CIC, are configured with the maximal tuple number. If a data segment is planned for each module, it will cause a great loss of physical resources and the configured maximal tuple is easy to be insufficient. Then, there is no data segment planned in active MSC Servers. For better maintenance, plan data segments in standby MSC Servers and perform capacity expansion when necessary. In a network adopting narrowband links, the 2-Mbit/s link or SIGTRAN networking is recommended. Key data: All kinds of links, circuits, and BICC CIC. See Figure 2-3.

MN22 Link 1 Link 2 ... Link X Link X+1 Link X+2 ... Link X+Y MN23 Link 1 Link 2 ... Link X Link X+1 Link X+2 ... Link X+Y MN=22 Link 1 Link 2 ... Link X Link X+1 Link X+2 ... Link X+Y MN=23 Link 1 Link 2 ... Link X Link X+1 Link X+2 ... Link X+Y

MN=24 Link 1 Link 2 ... Link X Link X+1 Link X+2 ... Link X+Y
SX0 Data segment A in SX 0 Data segment B in SX 1
SX1
Figure 2-3 Data segment in 1+1 assistant DH network (method three) Following are planning steps: 1) Obtain the capacity ratio (A:B) of two offices according to link configuration of active MSC Servers and the capacity plan of customers. Then separate data of standby MSC Servers into two data segment ranges (1 to X, X+1 to X+Y) according to the ratio and the configured maximal tuple number of the data in each module. 2) Configure link (circuit or BICC CIC) data of SX 0 and SX 1 in the backup data segment allocated in the peer office. Note that the load of links in a same link set (or circuits of a same office direction) should be separated on different modules.
2.3 Data Planning

Virtual Server node: Independently configure index parameter of virtual Server node. By default, virtual Server node 0 is auto configured for a local office, while other nodes need to be manually configured. The index of a standby virtual Server node on an active MSC Server should always be set to 1. In the 1+1 assistant DH network, virtual Server nodes 0 and 1 need to be configured on both of the active MSC Servers. The configured virtual Server node 1 is the assistant node, where the data of a peer office is configured. If the peer office is faulty, the virtual Server node 1 will take over its services. Table 2-1 lists detailed data restrictions.
Note: In the table, N represents N in N+1, while 1 represents 1 in N+1.
Table 2-1 Detailed data planning Object Command ADD DHHCFG DH heartbeat port MOD DHHCFG RMV DHHCFG LST DHHCFG DH configuration SET DHWM LST DHWM ADD FECFG Local IP configuration MOD FECFG RMV FECFG LST FECFG Independent Independent Heartbeat timeout number: 1180 Heartbeat timeout number 4 The IP address of each board of two nodes must be different. Heartbeat timeout number 4 The IP address of each board of two nodes must be different. 6 The switch mode (auto or manual) configured for two nodes must be consistent. Independent Port number: 165535 =1000 =1000 10 The port number smaller than 1000 might be reserved and it is not suggested to use them. Restriction Value range Example (SX 0) Example (SX 1) Default tuple Comment
256
Configure the IP address for a local WIFM.
Call source code
ADD CALLSRC
Method one
065533
049
5099
255
After a DH switch, the system performs called number analysis on the virtual Server node 1 according to different call sources and DN sets. Therefore, it is necessary to distinguish the call source of each MSC Server. By default, the maximal tuple number of the call source table is 255.
DN set
ADD CALLSRC ADD CNACLD
Method one
0253
019
2039
255
DN set is for internal use in the system and it is should be skipped during planning.
Object
Command ADD CNACLD,
Restriction
Value range
Example (SX 0)
Example (SX 1)
Default tuple
Comment If the destination code of N nodes is not distinguished, the destination code-related statistics will be affected when any of the N nodes is switched to node 1.
Destination code
ADD FORWARDCOD E
Method one
065535
09999
100001999
Office direction
ADD OFC
Method two
02047
Public office direction: 099; Other office direction: 100499
Public office direction: 099; Other office direction: 500799 2048
400 office directions are allocated for each node.
Sub-route Route Trunk group
ADD SRT ADD RT ADD N7TG ADD BICCTG
Method one Method one Method one
019999 01999 019999
0199 0199 0999
200399 200399 10001999 If the active and backup data are consistent, it is unnecessary to perform DH planning and configure them as the data of an independent office.
2000 2000 4000/40 00
200 sub-routes are allocated for each node N. 200 routes are allocated for each node N. 1000 trunk groups are allocated for each node.
ADD N7TKC Trunk circuit ADD BICCCIC ADD AIETKC Method three 09999 01999
10000
Note: Versions released later than May, 2006 support the configuration mode (configure data as that of an independent office). For earlier versions, it is suggested to plan data segments with method one.
Object Route selection code
Command
Restriction
Value range
Example (SX 0) It equals to the route number.
Example (SX 1) It equals to the route number.
Default tuple -
Comment
ADD CNACLD
Method one
065535
Route selection source code
ADD CALLSRC
Method one
065535
It equals to the call source code.
It equals to the call source code.
To reduce the amount of routing analysis data and promote system performance, it is suggested to use the wildcard of route selection source codes when you configure routing analysis data with the command ADD RTANA. -
MTP index
DSP
ADD N7DSP
Method one
065534
0199 It equals to the MTP DSP index.
200399 It equals to the MTP DSP index.
256
MTP link set index
ADD N7LKS
Method one
065534
256
To make data of two nodes consistent, try to separate the link numbers between two nodes into segments before using them.
MTP link
ADD N7LNK
Method three
031
015
1631
32
M3UA local entity index M3UA destination entity index
ADD M3LE
Method one
015
It equals to the index of the local office SP. 049
It equals to the index of the local office SP.
16
ADD M3DE
Method one
065534
5099
128
Object
Command
Restriction
Value range
Example (SX 0) It equals to the M3UA destination entity index.
Example (SX 1) It equals to the M3UA destination entity index.
Default tuple
Comment
M3UA link set index
ADD M3LKS
Method one
065534
128
M3UA link
ADD M3LNK
Method three
063
031
3263
64
To make data of two nodes consistent, try to separate the link number between two nodes into segments and then use the link number. -
Signaling gateway ID M2UA link set index M2UA link IUA link set index SCCP index SCCP index SCCP index MGW ID DSP SSN
ADD ESG
Method one
0299
It equals to the MGW index. 0255 015 049 0255 0511 Public GT: 01999 Other GT: 20009999 09
It equals to the MGW index. 256511 1631 5099 256511 5121023 Public GT: 01999 Other GT: 1000015999 1019
64
ADD M2LKS ADD M2LNK ADD IUALKS ADD SCCPDSP ADD SCCPSSN
Method one Method three Method one Method one Method one
0511 031 065534 065534 065534
512 32 256 512 1024
GT
ADD SCCPGT
Method two
080000
80000
ADD MGW
Method one
0299
300
Object Service check index Number change index CLIP Called Number Correlation Processing Authority check original called associated processing record Incoming caller number correlation index Incoming original called number correlation index
Command ADD SRVCHK ADD DNC
Restriction Method one Method two
Value range 065534 065534
Example (SX 0) 0199 0199
Example (SX 1) 200399 200399
Default tuple 512 1024 -
Comment
ADD CLCRPRO
Method one
04095
0199
200399
1024
ADD PRICHKORICLDI DX
Method one
065534
049
5099
256
ADD INCLRIDX
Method one
065534
0199
200399
1024
ADD INORICLDIDX
Method one
065534
0199
200399
1024
Object Outgoing caller number correlation index Outgoing original called number correlation index Location number Location area group number CALLGAP index SCP parameter index SCP address index TDP access code index
Command
Restriction
Value range
Example (SX 0)
Example (SX 1)
Default tuple
Comment
ADD OUTCLRIDX
Method one
065534
0199
200399
1024
ADD OUTORICLDIDX
Method one
065534
0199
200399
1024
ADD LAIGCI, ADD LAISAI
Method one
065535
049
5099
It is used when the function of enhancing roaming restriction is enabled. It is used when the function of enhancing roaming restriction is enabled. If the CALLCAP parameter of each node is consistent with each other, you can configure a same index. -
ADD LOCGRP
Method one
065535
049
5099
ADD CALLGAP
Method one
0311
049
5099
312
ADD SCPPARA
Method one
0254
049
5099
256
ADD SCPINFO ADD TDPAC
Method one Method one
0254 0311
049 049
5099 5099
256 32
Object
Command
Restriction
Value range
Example (SX 0)
Example (SX 1)
Default tuple
Comment Because one VLR is shared by multiple virtual MSC Servers, there is only one allocation principle of roaming numbers. Note that random allocation cannot be applied to the case and it is suggested to allocate the roaming numbers according to the MSC number. In addition, configure the number of subscribers according to the sum of subscribers in both offices. -
VLR function
ADD VLRCFG
Consistent
N nodes must be consistent.
MAP function
SET MAPACCFG
Consistent
N nodes must be consistent. N nodes must be consistent. N nodes must be consistent. N nodes must be consistent.
Bill control
MOD GBILLCTRL
Consistent
Tone configuration Software parameter
ADD TONECFG
Consistent
MOD MSFP
Consistent
Chapter 3 Data Configuration

3.1 Background
Consistency and concertedness of data between two assistant MSOFTX3000s are vital for configuring DH data. Therefore, data planning is the core for correctly configuring DH data. The following information must be consistent between an active MSOFTX3000 and its standby MSOFTX3000:
z z z z z z
Gateway register information Signaling interconnection information Trunk interconnection information Routing selection scheme Number dialing scheme Service configuration scheme
Only when all of the data are consistent, and an active MSOFTX3000 is switched in a dualhoming network, its assistant standby MSOFTX3000 can take over part of or all of its services. Before data configuration, make clear the following information:
z z z
Networking scheme Equipment (such as frame, board and link) configuration Interworking negotiation data (such as SS7 link, IP address, port number) for connecting to external interfaces
3.2 Procedure
There is a basic principle of sequence for configuring MSOFTX3000 data, that is, configuring internal data first, then interconnection data and finally service data. In addition, apply the sequence during data planning. Figure 3-1 shows the basic flow of DH data configuration.
Start Prepare data Internal data Configure hardware data Configure local data Interconnection data Configure data for connecting to MGW Configure data for connecting to RNC Configure data for connecting to BSC Configure data for connecting to HLR Configure data for connecting to other MSC Configure data for connecting to PSTN Configure data for connecting to SMC Configure data for connecting to SCP Configure data for connecting to SGSN Configure data for connecting to GMLC Service data
Configure data for number analysis Configure data for mobile service Configure data for IN service End
Figure 3-1 DH data configuration procedure
3.3 Configuration Step

3.3.1 Overview of Configuration Steps
The section introduces steps for configuring the following data:
z z
Proprietary Data Internal Data

z z
Interconnection Data Service Data
3.3.2 Proprietary Data

DH proprietary data, a kind of MSOFTX3000 basic data, is used to define the DH virtual Server node, working mode and heartbeat link.
I. Setting DH Work Mode

Work mode, a parameter, is used to define the work mode of a local office in a network. You can use the command SET DHWM to set Work mode to Standalone or Assistant. Following is the description of key parameters. Work mode It defines the work mode of the local MSOFTX3000 (MSC Server) in the network. The default option is Standalone. Options of the parameter are as follows:
z z
Standalone: indicates the local MSOFTX3000 does not work in DH mode. Assistant: indicates the local MSOFTX3000 works in the DH mode.
Server node index It is only valid when Work mode is set to Assistant. It specifies the virtual Server node whose work mode is to be set here. Configure the parameter by the following principles:
z
If it is set to 0, the DH work mode of the local Server node is to be set. Precondition: There is an MSOFTX3000 in the network which is the assistant Server node for the local MSOFTX3000 in networking.
If it is set to a value other than 0, the DH work mode of that Server node is to be set. And this parameter must be defined by ADD SRVNODE before it can be used here. Precondition: The local MSOFTX3000 is the assistant Server node for a certain physical MSOFTX3000 that the virtual Server node defined here corresponds to.
Switch mode It is only valid when Work mode is set to Assistant. It defines the switch mode of a certain virtual Server node in the local office. The default option is Manual. Options of the parameter are as follows:
z
Manual: When the MSC Servers work in assistant mode, the state of the appropriate virtual Server node can be switched over after the operator executes the switch command SET DHWM through the LMT or NMS.
Automatic: When working in assistant DH mode, the MSC Server switches the state of the appropriate virtual server node automatically according to the state of the heartbeat link between the assistant MSC server and itself. For example, when there is no heartbeat signal from the peer, the local MSC server sets the state of
an appropriate virtual server node to be activated automatically; when the heartbeat recovers, the local MSC server switches the state to be deactivated. Note that if Switch mode of a virtual Server node in the local office is set to Automatic, proceed as follows to configure data: 1) 2) 3) 4) Use the command SET DHWM to set Work mode of virtual Server node 0 to Assistant, Switch mode to Manual, and Force state to Activated. Use the command ADD SRVNODE to set the assistant MSOFTX3000 of a local one (for example, virtual Server node 1) to a DH MSC Server node. Use the command ADD DHHCFG to add a DH heartbeat link between a local MSOFTX3000 and its assistant MSOFTX3000. Use the command SET DHWM to set Work mode of the virtual Server node corresponding to the assistant MSOFTX3000 to Assistant, and Switch mode to Automatic. Following are configuration scripts of the previous steps:
SET DHWM: WM=ASSIST, SI=0, SM=MANUAL, FS=ACTIVE; ADD SRVNODE: SI=1, SN="LGMSOFTX3000"; ADD DHHCFG: SI=1, MN=132, IP="191.169.1.33", KEY="123456"; SET DHWM: WM=ASSIST, SI=1, SM=AUTO;
Force state It is valid when Switch mode is set to Manual. It defines the assistant state of a proper local virtual server node. The default value is Deactivated.Options of the parameter are as follows:
z
Deactivated: to force the virtual Server node to work in the DH deactivated mode manually. Then this virtual server node cannot process any service under its control, that is, in an idle state.
Activated: to force the virtual Server node to work in the DH activated mode manually. Then this virtual Server node can process all of its services.
Takeover mode It is valid when Switch mode is set to Automatic. It defines the takeover mode when a certain local virtual Server node is switched over automatically. The system supports all the modes. Options of the parameter are as follows:
z
Auto takeover: indicates that during the automatic switch, the system allows corresponding virtual Server node to switch from deactivated state to activated state. That is, the local MSOFTX3000 is able to take over services of the MSOFTX3000 that this virtual Server node corresponds to. If virtual server node 0 is not able to take over the services (Auto takeover is not selected), then after the local MSOFTX3000 is restarted, virtual server node 0 will be switched to deactivated state automatically.

z
Auto backward: indicates that during the switch, the system allows a certain virtual Server node to switch from activated state to deactivated state. That is, the local MSOFTX3000 is able to give back the services to the MSOFTX3000 that this virtual Server node corresponds to.
If the carrier wants to implement the automatic DH switch function, then you have to set Takeover mode to All for virtual Server node 0 and its corresponding node at the two MSOFTX3000s sides working in assistant mode. However, to ensure reliability of the system operation, it is suggested to set Takeover mode to Non-Auto Takeover and Non-Auto Backward for virtual Server node 0 and set Takeover mode to Auto Takeover and Non-Auto Backward for its corresponding virtual Server node. Thus it can prevent frequent switch when the bearer network is unstable. In other words, when an MSOFTX3000 is faulty, its assistant Server can take over the services automatically. After recovery, the faulty MSOFTX3000 is in the deactivated state and its assistant Server continues to process its services. After confirming the system or network is stable, the operator can execute SET DHWM to deactivate the assistant virtual Server node at the assistant MSOFTX3000 side and then to activate virtual Server node 0 at the original MSOFTX3000 side. Handshake timeout (*5s) It is valid when Work mode is set to Assistant and Server node index to a value other than 0. After the local MSOFTX3000 sends a heartbeat signal to its assistant MSOFTX3000, this parameter specifies the maximum duration for the local MSOFTX3000 to wait for the handshake signal from the peer. That is to say, if the local MSOFTX3000 does not receive a handshake signal from the assistant side within the specified duration, it considers the assistant MSOFTX3000 faulty. It depends on the switch mode of the appropriate virtual server node whether to switch or not. The unit of this parameter is five seconds. The default value is 30 x 5, that is, 150s.
II. Setting DH Virtual Server Node

In the table of virtual Server nodes, item 0 is always configured for a local MSC Server, while other items are configured for assistant or standby MSC Servers. The node ID is uniquely valid in the local MSC Server, and serves as the configuration reference of other service data. To add a virtual Server node, use the command ADD SRVNODE. Before adding a virtual Server node in the MSC Server, set Work mode of the virtual Server node 0 to Assistant with the command SET DHWM to activate the dualhoming function of the local office. Following is the description of key parameters: Server node index
It defines a DH Server node index in the configuration database of the MSOFTX3000. The local MSOFTX3000 (MSC Server) can interwork with at most five MSOFTX3000s in the 5+1 backup DH network. So, the value ranges from 1 to 5. Note that in the local configuration database, the local MSOFTX3000 Server node index is always 0. You cannot modify it. Server node name It identifies an MSC Server with a string of characters. Assistant server node It defines whether the Server node configured here can take over the services of the local MSOFTX3000. The default value is No, indicating that this MSC server is not the assistant Server node for the local MSOFTX3000. If the Server node (MSC Server) configured here is the assistant Server node for the local MSOFTX3000, set the parameter to Yes. Internal MGW media type For the internal MGWs controlled by the Server node (MSC Server) configured here, this parameter defines the bearer type of the media stream among these MGWs. The default value is IP. Options of the parameter are as follows:
z
AAL1: indicates that the media stream is ATM data packet after unstructured AAL1 adaptation, that is, the media streams among the MGWS are borne over the ATM packet network. AAL1 supports the transmission of real-time and connection-oriented media streams with constant bit rate, for example, uncompressed audio and video packets. Unstructured AAL1 only supports mapping the whole E1 link onto the ATM cell, instead of mapping one or several time slots in the E1 link onto the ATM cell. That is to say, it does not support the N x 64-kbit/s service.
AAL2: indicates that the media stream is ATM packet after AAL2 adaptation. In other words, the media streams between the MGWS are borne over the ATM packet network. AAL2 supports the transmission of real-time and connection-oriented media streams with variable bit rate, for example, compressed audio and video packets.
AAL1 structure: indicates that the media stream is ATM packet after structured AAL1 adaptation. In other words, the media streams between the MGWS are borne over the ATM packet network. AAL1 supports the transmission of real-time and connection-oriented media streams with constant bit rate, for example, uncompressed audio and video packets. Structured AAL1 supports mapping the whole E1 link onto the ATM cell and mapping one or several time slots in the E1 link onto the ATM cell. That is to say, it supports the N x 64-kbit/s service.
IP: indicates that the media stream is IP packet. In other words, the media streams between the MGWS are borne over the IP packet network.

z
TDM: indicates that the media stream is PCM code stream. In other words, the media streams between the MGWS are borne over the TDM circuit network.
Internal MGW connection type For the internal MGWs controlled by the Server node (MSC Server) configured here, this parameter defines the topology type of the media streams between these MGWs. The default value is All MGW connection. Options of the parameter are as follows:
z
Not all MGW connection: indicates that when the media streams between any two MGWs go through the bearer network, only part of them can be transmitted directly while other streams have to be transferred by other MGWs. When Internal MGW media type is set to TDM, since the TDM circuit network cannot serve as a switch itself, generally you must set this parameter to Not all MGW connection, unless the media streams are transmitted on mesh network topology. If the media streams are transmitted on mesh network topology, you must set this parameter to All MGW connection.
All MGW connection: indicates that the media streams between any two MGWs can be transmitted over the bearer network directly. When Internal MGW media type is set to AAL1, AAL2, AAL1 structure or IP, since the ATM or IP packet network can serve as a switch itself, the media streams between any two MGWs can be transmitted directly over the bearer network. So you must set Internal MGW connection type to All MGW connection.
When Internal MGW connection type is set to Not All MGW connection, you have to configure the path information between MGWs with ADD MGWPATH. Internal MGW path select mode It is valid when Internal MGW connection type is set to Not All MGW connection. For the internal MGWs controlled by the Server node configured here (MSC Server), when the media streams between two MGWs are transmitted over two or more communication paths, this parameter specifies the mode used by the system to select the paths. The default value is Automatic. Options of the parameter are as follows:
z
Automatic: The system always selects the shortest path between the source MGW and the destination MGW first. If there are several shortest paths, the system selects them in turn. If all the shortest paths are invalid, the system selects the shorter path. It is true with other conditions.
z z
Random: The system selects a path randomly. It is seldom used. Recycle: The system selects within all available paths according to a certain order, that is, in the load-sharing mode. Suppose there are N available paths, the probability of a path to be selected is 1/N.
Percent: The system selects the path according to the percent preset in the configuration database. The percent of a path to be selected is defined by ADD MGWPATH.
III. Setting Local Port of DH Heartbeat Link (Optional)

In actual networking, the signals in the DH heartbeat link are borne through the UDP protocol. By default, the UDP port number of the heartbeat link of the local MSOFTX3000 is 1000. You do not have to change the port number normally. However, if carriers have special requirements, you can change the UDP port number with SET DHLOCPORTNO. Following is the description of key parameters. WIFM module number It specifies the module number of the WIFM through whose FE port the local MSOFTX3000 sends heartbeat signals to the peer. This parameter is defined by ADD BRD before it can be used here. If there are two or more pairs of WIFMs in the whole system, you should configure two heartbeat links between the two MSOFTX3000s to guarantee the reliability of heartbeat signal transmission. Local port number As one of the parameters used for interworking with the peer MSOFTX3000, it specifies the UDP port number used when the local MSOFTX3000 sends heartbeat signals. The value ranges from 1 to 65535.
IV. Setting DH Heartbeat Link

In a network, signals of DH heartbeat link are transmitted through the UDP protocol. The heartbeat link between a local office and its assistant office is added with the command ADD DHHCFG. By default, the UDP port number used by the heartbeat link of the local MSOFTX3000 is 1000, which needs not to be modified in common situations. Those port numbers, smaller than 1000, might be reserved and it is suggested not using them. Unless there are some special requirements of telecom operators, use the command SET DHLOCPORTNO to set the local UDP port number for the dualhoming heartbeat link. In addition, to ensure the reliability of heartbeat signals for a system that configured with two pairs of WIFMs or more, configure two heartbeat links between the two MSOFTX3000s. Following is the description of key parameters. Server node index It specifies the server node that is connected to the local MSOFTX3000 by the DH heartbeat link. This parameter must be defined by ADD SRVNODE before it can be used here. WIFM module number
It specifies the module number of the WIFM through whose FE port the local MSOFTX3000 sends heartbeat signals to the peer. This parameter must be defined by ADD BRD before it can be used here. If there are two or more pairs of WIFMs in the whole system, you should configure two heartbeat links between the two MSOFTX3000s to guarantee the reliability of heartbeat signal transmission. Peer IP address As one of the parameters used for interworking with the peer MSOFTX3000, it specifies the IP address of the WIFM in the peer MSOFTX3000 that sends heartbeat signals. Peer port number As one of the parameters used for interworking with the peer MSOFTX3000, it specifies the UDP port number used when the peer MSOFTX3000 sends heartbeat signals. The value ranges from 1 to 65535. The default value is 1000. Encryption method As one of the parameters used for interworking with the peer MSOFTX3000, it specifies whether the heartbeat signals between the two MSOFTX3000s needs encrypting, and if needed, what the type of encryption is. The default type is MD5. This means the heartbeat signals needs encrypting and the MD5 encryption algorithm is employed. Key As one of the parameters used for interworking with the peer MSOFTX3000, it specifies the key required by the MD5 encryption algorithm when the heartbeat signals between the two MSOFTX3000s needs encrypting. The value should be a character string of at most 16 characters.
3.3.3 Internal Data

In a DH network, the configuration of internal data is the same as that configured for a network not adopting the dualhoming networking. The internal data is listed as follows:
I. Hardware Data
The hardware data is used to define the composition of equipment hardware, parameter of physical ports, configuration of module functions, and mode of clock synchronization. The configuration of hardware data depends on physical configuration. To avoid conflicts between virtual Server nodes, the parameter (for example, the SCTP parameter) of physical ports should be uniformly allocated.
II. Local Data

Before local data, complete configuring dualhoming proprietary data and add corresponding virtual Server nodes. Then configure corresponding local information for the virtual Server nodes. The local data is used to define the following information of a local office:
z z z z z z z z
Signaling point code Country code and area code National toll area code Multi-area statistics index DN set Call source code Local MSC number Local VLR number
Caution: During configuration, set Multi-area flag to True. Otherwise, the data of traffic statistics for different virtual nodes cannot be distinguished. All statistics will be regarded to be for virtual Server node 0.
3.3.4 Interconnection Data

During the DH configuration, the interconnection data is used to restrict commands and parameters sent to assistant network elements.
Note:
z
At present, the DH configuration is not involved in the data connecting to the SMC, SGSN and GMLC interfaces and this chapter does not introduce the data configuration for connecting these interfaces.
z z
The previous data configuration is optional and depends on the actual networking, The data of each interface is independent and there is fixed sequence for the data. It is recommended to configure the data in the sequence described in the manual. External interfaces of the MSOFTX3000 include multiple protocols of the transport layer. Before configuration, make clear the networking scheme.
I. Mc Interface Data for Connecting to MGW

The data for connecting to the MGW is an interconnection data of the MSOFTX3000. It defines the following information:
z z z
The data of H.248 links between the MSOFTX3000 and the MGW The Media connection relationship between MGWs The information of paths between MGWs
The parameter MGW index (ADD MGW) is directly associated with the index of virtual Server nodes and determines the virtual Server node to which the MGWs belong.
II. Signaling Interface Data

The configuration data of signaling interfaces refers to the data used for configuring public underlying signaling links. It includes the data of MTP, M2UA/IUA and M3UA signaling.
z
Note to MTP Configuration
The MSC Server node to which MTP DSP and subsequent data to be configured (such as MTP link set, MTP routing and MTP link) belong is determined by the MSC Server node to which a local SP belongs. If a local SP specified by the MTP DSP belongs to virtual Server node 0, the MTP DSP and subsequent data to be configured are also in the charge of virtual Server node 0. Proceed as follows to implement the M2UA-based MTP3 configuration: 1) 2) 3)
z
Configure active N7DSP, N7LKS, N7RT and N7LNK for virtual MSC Server node 0. Configure standby N7DSP, N7LKS, N7RT and N7LNK for other virtual MSC Server nodes. Follow the share-alike principle to select the WBSG module on the MSOFTX3000 and try to make all WBSGs share services of one SG. Note to M2UA/IUA Configuration
The virtual Server node to which the ESG is homed, determines the virtual Server node, to which links and link sets of M2UA or IUA are homed. The virtual Server node to which the MGW is homed, determines the virtual Server node, to which ESG is homed. Therefore, if the ESG is homed to virtual Server node 0, the links and link sets of M2UA or IUA are in the charge of virtual Server node 0. Proceed as follows to implement the M2UA/IUA configuration: 1) 2) 3) Configure active ESG, M2UA link sets and links for virtual Server node 0. Configure standby ESG and M2UA links and link sets for other virtual Server nodes. Configure one M2UA link set for the MGW (embedded ESG). The link set contains two links, one of which is connected to an active MSC Server and the other is connected to a standby MSC Server.
4)
z
Configure an M2UA link on the MGW (embedded ESG). Then the M2UA link set makes the link be managed by the virtual Server node that manages itself. Note to M3UA Configuration
The MSC Server node, to which a local SP is homed, determines the MSC Server node, to which M3LE and its subsequent data configuration (M3DE, M3LKS, M3RT and M3LNK) are homed. If local SP node 0 is specified for M3LE, the configuration of its subsequent data is in the charge of local SP node 0. Proceed as follows to implement the M3UA configuration: 1) 2) 3) Configure active M3UA local entities, destination entities, link sets, routes and links for virtual Server node 0. Configure standby M3UA local entities, destination entities, link sets, routes and links for other virtual Server nodes. Configure a link set between the MGW (embedded SG) and its corresponding SP. In the link set, configure links according to the number of the SPFs. In addition, set priorities of the links connecting to two MSOFTX3000s. Configure the link connecting to the active MSOFTX3000 with a higher priority, and the link connecting to the standby MSOFTX3000 with a lower priority. 4) Follow the share-alike principle to select the WBSG module on the MSOFTX3000 and try to make all WBSGs share services of one SG.
Note: Configure the management area on the assistant MSC Server according to the virtual Server nodes. For signaling interfaces, except the physical port and address, adopt the same configuration as that of the virtual Server nodes.
III. Trunk Office Direction Data

Configure the data of A interfaces, ISUP, TUP, R2, PRA, BICC office directions, sub-routes, routes, routing analysis, trunk groups and circuits in the same way as configure the common data.
IV. Nc Interface Data

When configuring the BICCSCTP link according to a planned BICC office direction, adopt the planned virtual Server node, to which the office direction is homed, as the virtual Server node, to which the link is homed.
3.3.5 Service Data

I. Paging Optimization in DH Network
When paging in a global network is initiated after the DH switch, to avoid overload in the access layer, it is necessary to avoid simultaneously sending paging messages to multiple virtual Servers. If the optimization function of global multi-area network paging is enabled, and data is restored after the DH switch, the paging is performed only in the local network (MSC/VLR) where a callee is located. P164 BIT4:
z
=0: Optimize the global multi-area network paging and perform the paging in a local network (MSC/VLR) only. =1: Not to optimize the global multi-area network paging and perform the paging in a multi-area network.
Default value: 1.
II. Service Data Switch

Intra-office data switch: The switch between location areas in a same virtual Server node is the intra-office switch. The data configuration is the same as that in common cases. Inter-office data switch between different virtual Server node: A location area whose local office is configured with a virtual Server node will be configured as a local VLR location area cell/service area. Therefore, it is unnecessary to configure adjacent cells for the switch between assistant offices. Cells that belong to different virtual Servers are considered as adjacent cells, and the switch performed between them is inter-office switch. The SCCP data configuration is the same as that in common cases. Inter-office data handover between different MSC Servers: The DH networking makes no difference to the configuration of SCCP data, adjacent cells, and adjacent BSC/RNCs. Then configure the data as common data.
III. Number Analysis and Routing Function

Configure the data in the same way as configure the common data.
Chapter 4 Operation and Maintenance

4.1 DH Commissioning
After the data configuration, proceed as follows to verify the services:
z z z z
Verifying That Network Connections Are Normal Verifying That DH Heartbeat Link Is Normal Verifying Services Before DH Switch Verifying Services Taken Over After DH Switch
4.1.1 Verifying That Network Connections Are Normal

In the MSOFTX3000 LMT, choose Trace Management > Interface Trace Task > PING in the Maintenance tab and check whether two assistant MSOFTX3000s are normally connected. If they are connected normally, proceed the subsequent steps. If not, remove faults and then proceed the subsequent steps. For example, check whether network cables are connected normally and whether IP routing data is configured correctly.
4.1.2 Verifying That DH Heartbeat Link Is Normal

Use the command DSP DHSTA to check whether the DH heartbeat works normally. After the execution, the output displays the number and the status of DH heartbeats of virtual Server nodes (no heartbeat link connected to node 0) in a local office. Normally, only virtual Server node 0 in a local office should be active, while other virtual Server nodes are inactive, and heartbeat links work normally.
4.1.3 Verifying Services Before DH Switch

Normally, every MSC Server works in good conditions and only virtual Server node 0 is active. In the case, check the signaling link status, circuit status, MO call service, MT call service and supplementary service of the MSC Server, namely, virtual Server node 0.
4.1.4 Verifying Services Taken Over After DH Switch

Verify the DH switch of active MSC Servers: Manually set the status of an active Server to the breakdown state or make the MSC Server breakdown by simulating power failure. In this case, the corresponding virtual Server node in the standby MSC Server should be activated. When the virtual Server node is activated, verify the signaling link status, circuit status, MO call service, MT call service and supplementary service of the original active MSC Server.
Verify services of another MSC Server in the same way after it is switched over.
4.2 DH Switch
If the triggering conditions of the DH switch is satisfied, all MGWs connected to MSOFTX3000 A will register with MSOFTX3000 B. After the corresponding service data is activated, MSOFTX3000 B takes over all services. Following are two dualhoming switch modes:
z z
Auto Switch Manual Switch
4.2.1 Auto Switch

I. Triggering Condition
The interruption of the heartbeat link is the unique triggering condition of auto switch. Following are possible causes of interruption of heartbeat links:
z z z
The MSC Server is broken down due to power failure. Both the active and standby WIFMs are faulty. All network ports of the MSC Server are faulty.
In the 1+1 assistant DH network, if any of the two MSOFTX3000s is faulty, the assistant MSOFTX3000 will auto take over its services.
II. Operation
You can specify whether switch and backward is allowed through data configuration. If the switch is allowed, the MSC Server will auto switch when the heartbeat link is interrupted. In the assistant DH network, to perform the auto switch, use the command SET DHWM to set Work mode of all nodes to Assistant, Switch mode to Automatic, and Takeover mode to Auto takeover. Then if anyone is faulty, and the heartbeat link is interrupted, the standby MSOFTX3000 will auto take over all services.
III. Precaution
z
Avoid the C/D interface congestion.
After the DH switch, the data of subscribers of the active MSC Server is not restored in the standby VLR. When a subscriber initiates a location update or service request for the first time, the VLR needs to take subscriber data and authentication set from the HLR. In this case, the flow through the C/D interface rises and the link might be congested. To avoid the congestion, use the command SET MAPPARA to switch on the flow control of location update after the DH switch. For each WCCU, set Inter-VLR location update count upon dual-home flow control to 10 in unit of count/second, and
Intra-VLR location update count upon dual-home flow control to 2 in unit of count/second. If the count of location updates reaches the value that has been set, the subsequent location updates will be processed as fake access to the network, that is, the location updates are not processed by the HLR, but the handsets are informed that the location updates are accepted. In addition, if the load remains heavy after the switch, disable the authentication and encryption functions for a while. When the flow of messages reduces, enable the functions again.
z
Avoid the paging channel congestion.
After a DH switch, the location data of subscribers served by the active MSC Server is not stored in the standby VLR at the beginning. When each of the subscribers is called for the first time, the MSC will initiate the global network paging, which might increase the paging volume and cause paging channel congestion. To reduce the paging volume and avoid the congestion, set the count of global network paging to 1 (through P164 bit 2-1).In addition, you can switch on the optimization function of global network paging (through P164 Bit 4), and the paging is performed only in the minimum local network. For any modification involved in the parameter, contact local technical engineers of Huawei.
4.2.2 Manual Switch

Manually setting the DH status is the unique triggering condition of manual switch. In this case, whether to perform DH switch completely depends on manual setting. If the DH switch cannot be auto triggered, you can trigger it manually. For example, the heartbeat between an active and standby MSC Servers is existing, but all calls are blocked, or CDB is completely faulty, which also causes interruption of all services. In this case, you can manually trigger DH switch.
II. Operation
Carry out the command SET DHWM on the active MSC Server, and set the status of the active Server node 0 to Deactivated. Then, carry out the command SET DHWM on the standby MSC Server, and set the status of the proper virtual Server node to Activated. Thus, services of the active MSC Server are taken over by the corresponding virtual Server node on the standby MSC Server.
III. Precaution
The precaution of the manual switch is the same as that of the auto switch. In addition, before the DH manual switch, make sure that the standby MSC Server works normally. Otherwise, services will be interrupted after the manual switch.
4.3 DH Backward
Following are two DH backward modes:
z z
Auto Backward Manual Backward
4.3.1 Auto Backward

After switched to a standby MSC Server, the active MSC Server will auto switch back and take back all services from the standby MSC Server, if it is recovered and restarted, and its heartbeat link is recovered. Following are triggering conditions of auto backward:
z z
Recovery of the heartbeat link Takeover mode of the standby virtual Server node is set to Auto backward.
II. Operation
Before the DH switch, use the command SET DHWM to set Work mode of all virtual Server nodes to Assistant, Switch mode to Automatic, and Takeover mode to Auto backward. Then, when the active MSC Server recovers, all services can auto transfer from the standby MSC Server to the active MSC Server.
III. Precaution
In actual use, auto switch and manual backward are recommended to minimize the time of service interruption and avoid repeated switches during system abnormality.
4.3.2 Manual Backward

Manually setting the DH status is the unique triggering condition of manual backward. In this case, whether to perform dualhoming backward completely depends on manual setting.
II. Operation
Carry out the command SET DHWM on the standby MSC Server, and set the status of the standby virtual Server node to Deactivated. Then, carry out the command SET DHWM on the active MSC Server, and set the status of the active virtual Server node 0 to Deactivated. Thus, the virtual Server node 0 takes back all services from the standby MSC Server.
III. Precaution
Before the manual backward, make sure that the active MSC Server recovers. Otherwise, services will be interrupted after the manual backward.
Chapter 5 Commissioning Items

The commissioning items listed in this chapter are to verify some functions after configuration of the DH data before or after switch. Following sections are for your information only.
5.1 Networking Description

Figure 5-1 shows the 1+1 assistant DH networking of MSC Servers 1 and 2. MSC Server 1 controls MGWs 1 and 2 while MSC Server 2 controls MGWs 3 and 4.
MSC Server 1 Heartbeat link MSC Server 2
MGW 1
MGW 2
MGW 3
MGW 4
Local network A Main control channel
Local network B Slave control channel
Figure 5-1 1+1 assistant DH networking When MSC Server 1 becomes faulty, MGWs 1 and 2 can register with MSC Server 2. Likewise, when MSC Server 2 becomes faulty, MGWs 3 and 4 can register with MSC Server 1. The following commissioning items are designed for this networking mode. There is no difference which MSC Server is faulty. Data configuration description: Configure the DH data so that MSC Servers 1 and 2 can work in 1+1 assistant mode. Following are just commissioning items for verification of basic functions.
5.2 Before Switch

Suppose the services of MSC Server 1 are to be switched over to MSC Server 2. Table 5-1 Commissioning items for the network before switch Item 1 Description Mobile subscriber (MS) 1 initiates a location update request (first time) to MSC Server 1. MS1 initiates a location update request (first time) to MSC Server 2.
z
Expected result The location information is updated successfully. The subscriber information in the VDB is correct. The location information is updated successfully. The subscriber information in the VDB is correct. The location information is updated successfully. The subscriber information in the VDB is correct. The call is established successfully. The bills generated by MSC Server 1 are correct. The call is established successfully. The bills generated by MSC Server 2 are correct. The call is established successfully. The bills generated by MSC Servers 1 and 2 are correct. The call is established successfully. The MTC bills generated by MSC Server 1 are correct. The call is established successfully. The MOC bills generated by MSC Server 2 are correct. The call is established successfully. The MTC bills generated by MSC Server 1 are correct. The call is established successfully. The MOC bills generated by MSC Server 2 are correct.
Location update
MS 1 changes the location from MSC Server 1 to MSC Server 2.
MS 1 served by MSC Server 1 calls MS 2 served by the same Server.
MS 1 served by MSC Server 2 calls MS 2 served by MSC Server 2.
Basic call
A PSTN subscriber calls MS 1 served by MSC Server 1.
MS 2 served by MSC Server 2 calls a PSTN subscriber. MS A in another office (not MSC Server 1 or 2) calls MS 1 served by MSC Server 1. MSC 2 served by MSC Server 2 calls MS A in another office (not MSC Server 1 or 2).
Item 1 Intelligent call 2
Description PPS subscriber MS 1 served by MSC Server 1 calls PPS subscriber MS 2 served by the same Server. PPS subscriber MS 1 served by MSC Server 1 calls PPS subscriber MS 2 served by MSC Server 2.
z
Expected result The call is established successfully. The bills generated by MSC Server 1 are correct. The call is established successfully. The bills generated by MSC Servers 1 and 2 are correct. The handover succeeds and calls can be established successfully. The bills generated by MSC Server 1 are correct. The circuits are released correctly. The handover succeeds and calls can be established successfully. The bills generated by MSC Servers 1 and 2 are correct. The circuits are released correctly. The short messages can be sent and received successfully. The bills generated for short messages are correct. The short messages can be sent and received successfully. The bills generated for short messages are correct.
MSC Server 1 performs intra-office handover.
Handover
z
The services of MSC Server 1 are handed over to MSC Server 2.
1 Short message 2
MS 1 served by MSC Server 1 sends short messages to MS 2 served by the same Server.
MS 1 served by MSC Server 1 sends short messages to MS 2 served by MSC Server 2. Query the states of MGWs 1 and 2 on MSC Server 1. Query the states of MGWs 3 and 4 on MSC Server 1.
Management of circuits and links
1 2
The states of MGWs 1 and 2 are normal. The query fails and the system prompts that the device is invalid. The states of active circuits are normal. The active circuits here refer to the circuits configured for the local Server node while the standby circuits are those configured for the assistant Server node. The query fails and the system prompts that the circuits are not installed.
Query the states of active circuits, such as N7TKC and AIETKC, on MSC Servers 1 and 2 respectively.
Query the states of standby circuits on MSC Servers 1 and 2 respectively.
Item 5
Description Query the states of active links, such as MTP3, M3UA, and M2UA, on MSC Servers 1 and 2 respectively. Query the states of standby links on MSC Servers 1 and 2 respectively.
Expected result The states of active links are normal. The query fails and the system prompts that the links are not configured.
z
Traffic statistics
Register the traffic measurement results of MSC Server 1 and virtual MSC Server 2, such as M2UA and M3UA link sets measurement results, on MSC Server 1 before switch.
The traffic measurement results of MSC Servers 1 are correct. The traffic measurement results of virtual MSC Server 2 are 0.
Notes: VDB: VLR database MOC: mobile originated call MTC: mobile terminated call MS: mobile subscriber PPS: prepaid service
5.3 After Switch

Suppose the services of MSC Server 1 are to be switched over to MSC Server 2. Table 5-2 Commissioning items for the network after switch Item Description
z
Expected result
z
location update
MS 1 served by MSC Server 1 before switch initiates a call for the first time after switch.
The call is rejected. The location update flow is activated. The location information is updated successfully. The identity authentication flow is activated. The location information is updated successfully. The subscriber information in the VDB is correct. The location information is updated successfully. The subscriber information in the VDB is correct. The location information is updated successfully. The subscriber information in the VDB is correct.
MS 1 served by MSC Server 1 before switch requests to update the location back to MSC Server 1 with TMSI after switch .
MS 1 served by MSC Server 1 requests to update the location with IMSI. MS 2 served by MSC Server 2 requests to update the location.
Item 5
Description
z
Expected result The location information is updated successfully. The subscriber information in the VDB is correct. The data restoration flow is activated during call connection. The call is established successfully. The bills are generated correctly. The call is rejected. The location update flow is activated. The location information is updated successfully. The call is established successfully. The bills are generated correctly. The call is established successfully. The bills are generated correctly. The call is established successfully. The call is processed as an inter-office call. The bills are generated correctly. The call is established successfully. The call is processed as an inter-office call. The bills are generated correctly. The call is established successfully. The bills are generated correctly. The call is established successfully. The bills are generated correctly. The call is established successfully. The bills are generated correctly.
MS 2 requests to update the location from MSC Server 2 to MSC Server 1
Basic call
MS 1 served by MSC Server 1 before switch is called for the first time after switch.
MS 1 served by MSC Server 1 before switch calls others for the first time after switch.
Carry out an intra-office call in MSC Server 1 after switch.
MS 1 served by MSC Server 1 calls MS 2 served by MSC Server 2 after switch.
MS A in another office (not MSC Server 2) calls MS 1 served by MSC Server 1. MS A in another office (not MSC Server 1) calls MS 2 served by MSC Server 2. MS 1 served by MSC Server 1 calls MS A in another office (not MSC Server 2).
Item 10
Description MS 2 served by MSC Server 2 calls MS A in another office (not MSC Server 1). A PSTN subscriber calls MS 1 served by MSC Server 1.
z
Expected result The call is established successfully. The bills are generated correctly. The call is established successfully. The bills are generated correctly. The call is established successfully. The bills are generated correctly. The call is forwarded successfully. The call is established successfully after being forwarded. The bills generated for call forwarding, caller and callee are all correct. The call is forwarded successfully. The call is established successfully after being forwarded. The bills generated for call forwarding, caller and callee are all correct. The call is forwarded successfully. The call is established successfully after being forwarded. The bills generated for call forwarding, caller and callee are all correct. The call is forwarded successfully. The call is established successfully after being forwarded. The bills generated for call forwarding, caller and callee are all correct.
11
12
Call forwarding
MS 1 served by MSC Server 1 calls MS 2 served by the same Server after switch and the call is fowarded unconditionally to MS 3 served by MSC Server 1.
MS 1 served by MSC Server 1 calls MS 2 served by the same Server after switch and the call is forwarded unconditionally to MS 3 served by MSC Server 2.
MS 1 served by MSC Server 1 calls MS 2 served by MSC Server 2 after switch and the call is forwarded to MS 3 served by MSC Server 1 due to callee busy.
Item
Description
z
Expected result The call is forwarded successfully. The call is established successfully after being forwarded. The bills generated for call forwarding, caller and callee are all correct. The call is forwarded successfully. The call is established successfully after being forwarded. The bills generated for call forwarding, caller and callee are all correct. The call is forwarded successfully. The call is established successfully after being forwarded. The bills generated for call forwarding, caller and callee are all correct. The short messages can be sent and received successfully. The bills generated for short messages are correct. The short messages can be sent and received successfully. The bills generated for short messages are correct. The handover succeeds and calls can be established successfully. The bills generated by MSC Server 1 are correct. The circuits are released correctly. The handover succeeds and calls can be established successfully. The bills generated by MSC Server 1 are correct. The circuits are released correctly.
MS 1 served by MSC Server 1 calls MS 2 served by the same Server after switch and the call is forwarded to MS 3 served by MSC Server 2 after the callee rejects the call.
MS 1 served by MSC Server 1 calls MS 2 served by the same Server after switch and the call is forwarded unconditionally to a PSTN subscriber.
MS 1 served by MSC Server 1 calls MS 2 served by MSC Server 2 after switch and the call is forwarded to MS A in another office (not MSC Server 1) due to no reply.
1 Short massage 2
MS 1 served by MSC Server 1 sends short messages to MS 2 served by MSC Server 2.
Handover
MSC Server 1 performs intra-office handover within the same MGW.
MSC Server 1 performs intra-office handover from MGW 1 to MGW 2.
Item
Description
z
Expected result The handover succeeds and calls can be established successfully. The bills generated by MSC Server 2 are correct. The circuits are released correctly. The handover succeeds and calls can be established successfully. The bills generated by MSC Server 1 are correct. The circuits are released correctly. The handover succeeds and calls can be established successfully. The bills generated by MSC Servers 1 and 2 are correct. The circuits are released correctly.
1 2 3
Query the states of MGWs 1 and 2 on MSC Server 1. Query the states of MGWs 1 and 2 on MSC Server 2. Query the states of MGWs 3 and 4 on MSC Server 2.
The query fails and the system prompts that the device is invalid. The states of MGWs 1 and 2 are normal. The states of MGWs 1 and 2 are normal.
z
Query the states of active circuits, such as N7TKC and AIETKC, on MSC Servers 1 and 2.
The query on MSC Server 1 fails and the system prompts that the circuits are not installed. The states of active circuits queried out on MSC Server 2 are normal. The query on MSC Server 1 fails and the system prompts that the circuits are not installed. The states of circuits, configured for the assistant Server node, queried out on MSC Server 2 are normal. The query on MSC Server 1 fails and the system prompts that no link is configured. The states of links queried out on MSC Server 2 are normal.
Query the states of standby circuits on MSC Servers 1 and 2 respectively.
Query the states of active links, such as MTP3 link and M3UA link, on MSC Servers 1 and 2 respectively.
Item
Description
z
Expected result The query on MSC Server 1 fails and the system prompts that no link is configured. The states of links, configured for the assistant Server node, queried out on MSC Server 2 are normal. The traffic measurement results of MSC Server 2 are correct. The traffic measurement results of virtual MSC Server 1 are correct. The tracing task is created successfully. The messages can be traced normally. The tracing task is created successfully. The messages can be traced normally.
Query the states of standby links on MSC Servers 1 and 2 respectively.
Traffic measuremen t
Register the traffic measurement results of MSC Server 2 and virtual MSC Server 1, such as M3UA and M2UA link set measurement, on MSC Server 2 after switch. Set up a tracing task on MSC Server 2 to trace subscribers served by MSC Servers 1 and 2 after switch. Set up a tracing task on MSC Server 2 to trace links such as M3UA link, M2UA link and MTP3 link of MSC Server 2 and virtual MSC Server 1 after switch.
1 Tracing function 2
5.4 Backward
Suppose the services taken over by MSC Server 2 are to be switched back to MSC Server 1. Table 5-3 Commissioning items for services backward Item Description
z
Expected result The location information is updated successfully. The subscriber information in the VDB is correct. The location information is updated successfully. The subscriber information in the VDB is correct. The location information is updated successfully. The subscriber information in the VDB is correct. The call is established successfully. The MOC bills generated by MSC Server 1 are correct.
MS 1 initiates a location update request (first time) to MSC Server 1.
Location update
MS1 initiates a location update request (first time) to MSC Server 2.
MS 1 requests to update the location from MSC Server 1 to MSC Server 2.
Basic call
Item 2
Description
z
Expected result The call is established successfully. The bills generated by MSC Server 2 are correct. The call is established successfully. The bills generated by MSC Servers 1 and 2 are correct. The call is established successfully. The bills generated by MSC Server 1 are correct. The call is established successfully. The bills generated by MSC Servers 1 and 2 are correct. The handover succeeds and calls can be established successfully. The bills generated by MSC Server 1 are correct. The circuits are released correctly. The handover succeeds and calls can be established successfully. The bills generated by MSC Servers 1 and 2 are correct. The circuits are released correctly.
MS 1 served by MSC Server 1 calls MS 2 served by MSC Server 2. PPS subscriber MS 1 served by MSC Server 1 calls PPS subscriber MS 2 served by the same Server. PPS subscriber MS 1 served by MSC Server 1 calls PPS subscriber MS 2 served by MSC Server 2.
1 Intelligent call
Handover
z
Query the states of MGWs 1 and 2 on MSC Server 1. Query the states of MGWs 3 and 4 on MSC Server 1. Query the states of active circuits, such as N7TKC and AIETKC, on MSC Servers 1 and 2 respectively. Query the states of standby circuits on MSC Servers 1 and 2 respectively. Query the states of active links, such as MTP3 link and M3UA link, on MSC Servers 1 and 2 respectively. Query the states of standby links on MSC Servers 1 and 2.
The states of MGWs 1 and 2 are normal. The query fails and the system prompts that the device is invalid. The states of active circuits are normal. The query fails and the system prompts that the circuits are not installed. The states of active links are normal. The query fails and the system prompts that the links are not configured.
3 Management of circuits and links
5.5 Switch Commissioning

Suppose the services of MSC Server 1 are to be switched over to MSC Server 2. Table 5-4 Commissioning items for services switch Item 1) Description Set the takeover mode of Sever node 1 on MSC Server 2 to auto takeover and non-auto backward. Expected result
SET DHWM: WM=ASSIST, SI=1, SM=AUTO, TM=MODE1-1&MODE2-0; 1 2) Set the takeover mode of Sever node 0 on MSC Server 1 to non-auto takeover and non-auto backward.
MSC Server 2 can take over the services of MSC Server 1 automatically.
SET DHWM: WM=ASSIST, SI=0, SM=AUTO, TM=MODE1-0&MODE2-0, HT=6; 3) Auto takeover 1) Power off MSC Server 1 to make it break down. Set the takeover mode of Server node 1 on MSC Server 1 to auto takeover and non-auto backward.
SET DHWM: WM=ASSIST, SI=1, SM=AUTO, TM=MODE1-1&MODE2-0; 2 2) Set the takeover mode of Server node 0 on MSC Server 2 to non-auto takeover and non-auto backward.
SET DHWM: WM=ASSIST, SI=0, SM=AUTO, TM=MODE1-0&MODE2-0, HT=6; 3) 1) Power off MSC Server 2 to make it break down. After MSC Server 1 recovers, deactivate Server node 1 on MSC Server 2 manually. The services are switched back successfully.
SET DHWM: WM=ASSIST, SI=1, SM=MANUAL, FS=DEACTIVE; 2) Activate node 0 on MSC Server 1 manually:
Manual backward
SET DHWM: WM=ASSIST, SI=0, SM=MANUAL, FS=ACTIVE; 1) After MSC Server 2 recovers, deactivate ServerNode1 on MSC Server 1 manually. The services are switched back successfully.
SET DHWM: WM=ASSIST, SI=0, SM=MANUAL, FS=ACTIVE;
Item 1)
Description Deactivate node 0 on MSC Server 1 manually:
Expected result
The services of MSC Server 1 can be switched over to MSC Server 2 manually.
Manual switch
SET DHWM: WM=ASSIST, SI=1, SM=MANUAL, FS=ACTIVE; 1) Deactivate node o on MSC Server 2 manually: The services of MSC Server 2 can be switched over to MSC Server 1 manually
HUAWEI
Table of Contents
Table of Contents
Chapter 1 Introduction to Networking......................................................................................... 1-1 1.1 Virtual Server Networking .................................................................................................. 1-1 1.2 Mc Interface Networking .................................................................................................... 1-1 1.2.1 Networking Before Switch ....................................................................................... 1-2 1.2.2 Networking After Switch .......................................................................................... 1-3 1.2.3 Impact on Peripheral Network Elements................................................................. 1-4 1.3 Narrowband Signaling Networking .................................................................................... 1-5 1.3.1 Networking Before Switch ....................................................................................... 1-7 1.3.2 Networking After Switch .......................................................................................... 1-8 1.3.3 Impact on Peripheral Network Elements............................................................... 1-11 1.4 SIGTRAN Signaling Networking ...................................................................................... 1-12 1.4.1 Networking Before Switch ..................................................................................... 1-13 1.4.2 Networking After Switch ........................................................................................ 1-13 1.4.3 Impact on Peripheral Network Elements............................................................... 1-15 1.5 Trunk Networking............................................................................................................. 1-15 1.5.1 Networking Before Switch ..................................................................................... 1-16 1.5.2 Networking After Switch ........................................................................................ 1-16 1.5.3 Impact on Peripheral Network Elements............................................................... 1-17 Chapter 2 Data Planning............................................................................................................... 2-1 2.1 Capacity Planning .............................................................................................................. 2-1 2.2 Planning Method ................................................................................................................ 2-1 2.3 Planning Data .................................................................................................................... 2-5 Chapter 3 Data Configuration ...................................................................................................... 3-1 3.1 Background........................................................................................................................ 3-1 3.2 Procedure .......................................................................................................................... 3-1 3.3 Configuration Step ............................................................................................................. 3-2 3.3.1 Overview of Configuration Steps............................................................................. 3-2 3.3.2 Proprietary Data ...................................................................................................... 3-3 3.3.3 Internal Data............................................................................................................ 3-9 3.3.4 Interconnection Data ............................................................................................. 3-10 3.3.5 Service Data.......................................................................................................... 3-13 Chapter 4 Operation and Maintenance........................................................................................ 4-1 4.1 DH Commissioning ............................................................................................................ 4-1 4.1.1 Verifying That Network Connections Are Normal ................................................... 4-1 4.1.2 Verifying That DH Heartbeat Link Is Normal........................................................... 4-1 4.1.3 Verifying Services Before DH Switch ...................................................................... 4-1 4.1.4 Verifying Services Taken Over After DH Switch ..................................................... 4-1
Table of Contents
4.2 DH Switch .......................................................................................................................... 4-2 4.2.1 Auto Switch ............................................................................................................. 4-2 4.2.2 Manual Switch ......................................................................................................... 4-3 4.3 DH Backward ..................................................................................................................... 4-4 4.3.1 Auto Backward ........................................................................................................ 4-4 4.3.2 Manual Backward.................................................................................................... 4-4 Chapter 5 Commissioning Items ................................................................................................. 5-1 5.1 Networking Description...................................................................................................... 5-1 5.2 Before Switch..................................................................................................................... 5-1 5.3 After Switch........................................................................................................................ 5-4 5.4 Backward ........................................................................................................................... 5-8 5.5 Switch Commissioning....................................................................................................... 5-9

The N+1 backup DH (DH) scheme (1<N5) is recommended for disaster recovery of the MSOFTX3000 in the following situations:
z z
Works as an end office Doubles as a gateway office when working as an end office
1.1 Virtual Server Networking

Figure 1-1 shows the virtual Server networking of the N+1 backup DH scheme.
index 0 SX-1 1 server SX-1 SX-A
index 0 1 2 ... n
server SX-A SX-1 SX-2 ... SX-n n5 SX-A
index 0 SX-2 ...... index 0 SX-n 1 1
server SX-2 SX-A
server SX-n SX-A
Figure 1-1 Virtual Server node configuration of N+1 backup DH scheme A virtual Server node is configured on the active Server to set up a heartbeat link with the standby Server. This virtual Server node is not configured with service data, so set its index to 1
1.2 Mc Interface Networking

In N+1 backup networking, N + 1 MSOFTX3000s work in "N active, one standby" mode in the MSC Server layer. That is, N MSOFTX3000s work as active MSC Servers, the other one as the standby MSC Server. Figure 1-2 shows the networking.
MSOFTX3000 A
Heartbeat link
MSOFTX3000 B
Heartbeat link
MSOFTX3000 C
MGW 1
MGW 2
MGW3
MGW 4
Local network A Active control channel
Local network C Standby control channel
Figure 1-2 N+1 backup networking (N = 2) Normally MSOFTX3000 B does not control any service in the networking. It works as the standby Server for MSOFTX3000s A and C.

Normally, MSOFTX3000 A controls the services in local network A, that is, MGW 1 and MGW 2 initiates registration requests to MSOFTX3000 A only. Likewise, in normal cases, MSOFTX3000 C controls the services in local network C, that is, MGW 3 and MGW 4 initiates registration requests to MSOFTX3000 C only. See Figure 1-3.
MSOFTX3000 A Heartbeat link MSOFTX3000 B Heartbeat link MSOFTX3000 C
MGW 1
MGW 2
MGW 3
MGW 4
Local network A
Local network C
Figure 1-3 N+1 backup networking (N = 2) before switch

I. When MSOFTX3000 A Is Faulty
When MSOFTX3000 A becomes faulty or suffers from burst disasters, MSOFTX3000 B will take over the service control of local network A. That is, MGW 1 and 2 will initiate registration requests to MSOFTX3000 B instead of MSOFTX3000 A. Figure 1-4 shows the networking after switch.
MGW 1
MGW 2
MGW 3
MGW 4
Figure 1-4 N+1 backup networking (N = 2) after switch due to fault of MSOFTX3000 A
II. When MSOFTX3000 C Is Faulty

When MSOFTX3000 C becomes faulty or suffers from burst disasters, MSOFTX3000 B will take over the service control of local network C. That is, MGW 3 and 4 will initiate registration requests to MSOFTX3000 B instead of MSOFTX3000 C. Figure 1-5 shows the networking after switch.
MSOFTX3000 A
Heartbeat link
MSOFTX3000 B
Heartbeat link
MSOFTX3000 C
MGW 1
MGW 2
MGW 3
MGW 4
Figure 1-5 N+1 backup networking (N = 2) after switch due to fault of MSOFTX3000 C
III. When MSOFTX3000 B Is Faulty

When the standby Server MSOFTX3000 B becomes faulty or suffers from burst disasters, MSOFTX3000 A and MSOFTX3000 C will detect the interruption of heartbeat links only. There is no service on MSOFTX3000 B. The services of local networks A and C will not be affected.
MGW 1
MGW 2
MGW 3
MGW 4
Figure 1-6 N+1 backup networking (N = 2) after switch due to fault of MSOFTX3000 B

If dual activation occurs (for example, due to interruption of the heartbeat link between MSOFTX3000s A and B), the virtual Server, corresponding to MSOFTX3000 A, in
MSOFTX3000 B will be activated and the backup data of MSOFTX3000 A configured on MSOFTX3000 B will be loaded. However, the IP connections between MSOFTX3000 A and the MGWs work normally, so MGW 1 and MGW 2 still register with MSOFTX3000 A instead of MSOFTX3000 B. The only difference is that two faulty MGWs are added to MSOFTX3000 B and there is no impact on services.
Note: In N+1 backup DH networking, the standby MSC Server can take over the service control of only one faulty MSC Server at a time.
1.3 Narrowband Signaling Networking
Note: Recommended application: The STP (including HSTP and LSTP) connected to a toll office uses SIGTRAN in networking. If the conditions cannot be satisfied, employ direct connection of MSC Servers.
If the MSOFTX3000 directly offers TDM-based narrowband signaling links, it is recommended to set routing priority for networking. Figure 1-7 shows the network layout. Take STP as an example. MSOFTX3000 A and C correspond to LSTPs A and C respectively. The narrowband signaling is interchanged with other local offices through their own LSTPs. In DH networking, for LSTP A, there are two signaling routes to its destination SP A: link set DA of higher priority and link set DB of lower priority.

LSTP A SP D

LSTP C SP F
MSOFTX3000 A SP A
Heartbeat link
MSOFTX3000 B SP B
Heartbeat link
MSOFTX3000 C SP C
MGW 1
MGW 2
MGW 5
MGW 6
Local network A Active control channel Standby control channel Link set A->D
Local network C Link set Link set Link set B->F C->F B->D
Figure 1-7 N+1 backup (N = 2) narrowband signaling routing priority
Note: A pair of STPs often work in mutual assistant mode when a local MSC Server connects to an STP. There are two signaling routes between an STP and an MSC Server: one is the prior direct signaling route and the other is a signaling route of lower priority transferred through the standby STP. Another signaling route transferred through the standby Server is added in DH networking. Its priority is lower than the direct route but higher than others. See Figure 1-8.

LSTP A SP D Priority 1

LSTP C SP F
Priority 3 Priority 2 MSOFTX3000 B SP B
MSOFTX3000 A SP A
Heartbeat link
Heartbeat link
MSOFTX3000 C SP C
MGW 1
MGW 2
MGW 5
MGW 6
Local network A Active control channel Standby control channel Link set A->D Link set B->D
Local network C Link set B->F Link set C->F Link set D->F
Figure 1-8 N+1 backup (N = 2) narrowband signaling routing priority

Take an active MSC Server MSOFTX3000 A as an example and the rule is also applied to other MSC Servers. From SP A to SP D, the signaling is routed directly and only through the link set AD. Actually the links between SP B and SP D and between SP B and SP F also work normally. But the signaling transferred through SP B cannot reach SP A and SP C. (Use MOD OFI to add mutual assistant relationship between SPs.) Figure 1-9 shows the networking before switch.

LSTP A SP D

LSTP C SP F
MSOFTX3000 A SP A
Heartbeat link
MSOFTX3000 B SP B
Heartbeat link
MSOFTX3000 C SP C
MGW 1
MGW 2
MGW 5
MGW 6
Local network C Link set B->F Link set C->F Link set B->D
Figure 1-9 N+1 backup (N = 2) narrowband signaling networking before switch

After the services of MSOFTX3000 A are switched over to MSOFTX3000 B, SP B takes over signaling services of SP A. The signaling from LSTP A to SP A is routed through the second signaling route SP DSP B. Then, through the SP assistance function of MSOFTX3000 B, the signaling services to SP A are performed. Figure 1-10 shows the networking after switch.
LSTP A SP D
LSTP C SP F
MSOFTX3000 A SP A
Heartbeat link
MSOFTX3000 B SP B/SP A
Heartbeat link
MSOFTX3000 C SP C
MGW 1
MGW 2
MGW 5
MGW 6
Local network C Link set B->F Link set C->F Link set B->D
Figure 1-10 N+1 backup (N = 2) narrowband signaling networking after the switch of MSOFTX3000 A

The networking after the switchover of MSOFTX3000 C is similar to that when MSOFTX3000 A is faulty, as shown in Figure 1-11.
LSTP A SP D
LSTP C SP F
MSOFTX3000 A SP A
Heartbeat link
MSOFTX3000 B SP B/SP C
Heartbeat link
MSOFTX3000 C SP C
MGW 1
MGW 2
MGW 5
MGW 6
Figure 1-11 N+1 backup (N = 2) narrowband signaling networking after the switch of MSOFTX3000 C
III. When MSOFTX3000 B Is Faulty

Figure 1-12 shows the narrowband signaling networking after MSOFTX3000 B becomes faulty. The signaling links between SP B and SP A and between SP B and SP C are all interrupted. But the services of the active Server will not be affected.

LSTP A SP D

LSTP C SP F
MSOFTX3000 A SP A
Heartbeat link
MSOFTX3000 B SP B
Heartbeat link
MSOFTX3000 C SP C/SP B
MGW 1
MGW 2
MGW 5
MGW 6
Figure 1-12 N+1 backup (N = 2) narrowband signaling networking after the switch of MSOFTX3000 B

The impacts on peripheral NEs are as follows:
z
Two signaling routes with different priorities need to be configured between the DSPs (active and standby MSC Servers) and the peripheral equipment. The signaling route with higher priority is configured between an active MSC Server and the peripheral equipment, and the signaling route with lower priority is configured between a standby MSC Server and the peripheral equipment.
After the switch, the standby MSC Server takes over the signaling services of an active MSC Server through the original signaling link of the standby MSC Server. Therefore, the load of the signaling link will be increased, especially when MSC Servers use multi-SP services. Then, it is suggested to adopt the 2-Mbit/s link for the narrowband link between the standby MSC Server and the peripheral equipment.
Such problems as link alarm and limitation to the number of links will not occur, because different link sets are used for the connection between an active MSC Server and the peripheral equipment and that between the standby MSC Server and the peripheral equipment.
If dual activation occurs (for example, due to the interruption of connection between MSOFTX3000s A and B), the virtual Server, corresponding to MSOFTX3000 A, in the MSOFTX3000 B (standby MSC Server) will be activated.
In addition, the backup data of MSOFTX3000 A configured on the virtual Server will be loaded. However, MSOFTX3000 A and MSOFTX3000 B are configured with active narrowband link data of their own only. Therefore, the states of narrowband links will not be changed. Moreover, signaling routes are configured with different priorities, so that direct link sets are prior to other signaling routes from the peripheral equipment to MSOFTX3000 A and MSOFTX3000 B.
1.4 SIGTRAN Signaling Networking
Note: Recommended application: Use M2UA of SIGTRAN signaling networking to connect all the office directions to the local office, such as the BSC, local MSC and local HLR, and other local networks. The MSOFTX3000 offers M2UA broadband signaling links over IP directly.
Figure 1-13 shows the network layout of the SIGTRAN networking. Take the connection between the BSC and the PSTN in another network as an example. The signaling from BSC 1 or PSTN the MSOFTX3000 goes through the prior link from the SG to MSOFTX3000 A. When MSOFTX3000 A becomes faulty, the signaling is routed through the link of lower priority from the SG to MSOFTX3000 B.
MSOFTX3000 A MSOFTX3000 B MSOFTX3000 C
Heartbeat link
Heartbeat link
SG 1
SG2
SG4
Local network A
Local network C
BSC1
PSTN High priority link (active)
PSTN Low priority link (standby)
Figure 1-13 N+1 backup SIGTRAN signaling networking (N = 2)

Before switch, SIGTRAN signaling between the SG and the MSOFTX3000 is delivered over the SIGTRAN link with higher priority (connected to an active MSC Server). Figure 1-14 shows the networking before switch.
Heartbeat link
Heartbeat link
SG 1
SG2
SG4
Local network A
Local network C
BSC1
Figure 1-14 N+1 backup (N = 2) SIGTRAN signaling networking before switch

Figure 1-15 shows the networking after MSOFTX3000 A hands over services due to fault. In the network, the links between SGs (1 and 2) and their active MSC Server (MSOFTX3000 A) are interrupted. Then, the SIGTRAN signaling from SG 1 and SG 2 is delivered over the SIGTRAN links (with lower priority) connected to their standby MSC Server (MSOFTX3000 B).
MSOFTX3000 A
Heartbeat link
MSOFTX3000 B
Heartbeat link
MSOFTX3000 C
SG 1
SG2
SG4
Local network A
Local network C
BSC1
Figure 1-15 N+1 backup (N = 2) SIGTRAN signaling networking after the switch of MSOFTX3000 A

Figure 1-16 shows the networking after MSOFTX3000 C hands over services due to fault. In the network, the link between SG 4 and its active MSC Server (MSOFTX3000 C) is interrupted. Then, the SIGTRAN signaling from SG 4 is delivered over the SIGTRAN link (with lower priority) connected to their standby MSC Server (MSOFTX3000 B).
Heartbeat link
Heartbeat link
SG 1
SG2
SG4
Local network A
Local network C
BSC1
Figure 1-16 N+1 backup (N = 2) SIGTRAN signaling networking after the switch of MSOFTX3000 C

z
The SIGTRAN links between an SG and the MSOFTX3000s are of different priorities. The link from the SG to an active MSC Server is of higher priority and that to the standby MSC Server is of lower priority.
If the dual activation occurs (for example, due to the interruption of connection between MSOFTX3000s A and B), the virtual Server node, corresponding to MSOFTX3000 A, in MSOFTX3000 B will be activated. The backup data configured on it will be loaded. The SIGTRAN links from SG 1 and 2 to MSOFTX3000 B are activated. The signaling originated from MSC Server A will not be affected, still being transferred from SG 1 or SG 2 to the proper BSC and PSTN. The signaling originated from BSC 1 or PSTN is transferred through the prior signaling link to MSOFTX3000 A. The activated link between SG 1 (or SG 2) and MSOFTX3000 B will not affect the signaling transmission because they are of lower priority.
1.5 Trunk Networking

Figure 1-17 shows the structure of the trunk networking.
Heartbeat link
Heartbeat link
SG 1
SG2
SG4
Local network A
Local network C
MSC1
Figure 1-17 N+1 backup (N = 2) trunk networking In the network of 3GPP R4, the call control and bearer of an MSC Server are separated. For the DH application in signaling networking, refer to the previous three sections. Voice channel networking means the voice channel networking between an SG and its peripheral NEs or other SGs. During DH switch, only the SGs might register with another MSC Server. The voice channels between SGs do not change.

Figure 1-18 shows the trunk networking before switch. The voice channels in each local network belong to their own MGWs respectively.
Heartbeat link
Heartbeat link
SG 1
SG2
SG4
Local network A
Local network C
MSC1
Figure 1-18 N+1 (N = 2) backup trunk networking before switch

Figure 1-19 shows the trunk networking after MSOFTX3000 A hands over services due to fault. The trunk networking keeps the same as that before switch. The voice channels still belong to their original MGWs. But the signaling routes change.
MSOFTX3000 A
Heartbeat link
MSOFTX3000 B
Heartbeat link
MSOFTX3000 C
SG 1
SG2
SG4
Local network A
Local network C
MSC1
Figure 1-19 N+1 backup (N = 2) trunk networking after the switch of MSOFTX3000 A

Figure 1-20 shows the trunk networking after MSOFTX3000 C hands over services due to fault. The trunk networking keeps the same as that before switch.
Heartbeat link
Heartbeat link
SG 1
SG2
SG4
Local network A
Local network C
MSC1
Figure 1-20 N+1 backup (N = 2) trunk networking after the switch of MSOFTX3000 C

z
There is no impact or requirement on data configuration of peripheral NEs.


z
During the switch, some idle circuits might become faulty and then become idle. Then, such messages as hardware blocking and circuit resetting might be generated. All of these are normal.

2.1 Capacity Planning
Dual homing, often together with large capacity, can effectively promote system security, enhance networking flexibility, and reduce cost. However, the larger the better is not always the case. The capacity planning can not exceed the total capacity of the system. In N+1 backup DH networking, the number of LICENSE subscribers for the standby MSC Server is same as that of local subscribers for an active MSC Server with the highest capacity. For example, in a 3+1 backup networking, if the capacities of the three MSC Servers are 100,000, 200,000, and 300,000 subscribers respectively, apply for a LICENSE of 300,000 subscribers for the standby MSC Server. Redundancy is also required for processing capability planning. In N+1 networking mode, the host of the standby Server stores the office data of N Servers (corresponding to N virtual Server nodes). When the switch occurs, the standby Server activates a certain virtual node and uses the data configured on it. Therefore, If N is a large number, the data configured on the standby Server may exceed the total capacity: 2,000,000 subscribers. Capacity planning for links:
z
For M3UA-based links, configure the number of WBSGs on the standby MSC Server according to the total number of M3UA links in all active MSC Servers. For MTP2-based SS7 links, configure the number of WCSUs on a standby MSC Server according to the total number of SS7 links in all active MSC Servers. For M2UA-based SS7 links, configure the number of WBSGs on the standby MSC Server according to the total number of SS7 links in all active MSC Servers.
2.2 Planning Method

There are three data planning methods. In actual conditions, adopt different methods for different data planning.
I. Method One
Adopt independent segments for data of each Server. The backup data of each active MSC Server is planned on the standby MSC Server by segment and the divided data segments are completely independent. Plan the data on the standby MSC Server. Assign an independent segment for each active MSC Server. Reserve some resources for subsequent capacity expansion. Data features are as follows:

z z
The data is unique in a global table. In the standby MSC Server, the sum of a kind of data of all active Servers should not exceed the maximum tuple number in the data table.
Key data includes SRVNODE, DHWM, DHHCFG, local office information, INOFFMSC, MGW, trunk group, ESG, M3LE, M3DE, N7DSP, SCCPDSP, SCCPSSN, link set, signaling route, route, sub-route, route analysis, MHPREFIX, MHSUFFIX, MHMSCCFG, MASI, RNC, BSC, LAIGCI, LAISAI, ACPOOL. See Figure 2-1. Take 3+1 backup networking as an example. SX 1, SX 2 and SX 3 are active MSC Servers while SX 0 is the standby MSC Server.
SX0 (standby Server) OFC 0 - 99 100-199 200-299 ...
0 - 99 Trunk group SX1
100 - 199 Trunk group
200 - 299 Trunk group
SX2
SX3
Data segment A of virtual Server in SX 1 Data segment B of virtual Server in SX 2 Data segment C of virtual Server in SX 3
Figure 2-1 Data segments in 3+1 backup networking (method one) To plan the data with method one, proceed as follows: 1) 2) 3) Specify the data segment ranges for each active MSC Server: A, B and C. Configure data for each active Server within its own data segment range. Combine the data of the active Servers SX 1, SX 2 and SX 3 together to be the data of A, B and C on the standby Server SX 0.
II. Method Two

Adopt the combination of a public data segment and several independent data segments. Reserve a certain segment range for the public data of the Servers, and then assign an independent segment range for each active Server. Data features are as follows:
z
The data is unique in a global table.

z
In the table, some data might be shared among multiple MSC Servers. For example, for offices connecting to a same province-class tandem office, they share a same index of office direction.
Key data includes office direction, SCCPGT, DN set, call source and called number analysis data. See Figure 2-2. (Take 3+1 backup as an example.)
SX 0 (standby Server) OFC 0-99 100-399 400-799 800-1199
0-99
100-399 OFC SX1
0-99
400-799 OFC SX2
0-99
800-1199 OFC SX3
Public data segment A Data segment B of virtual Server in SX 1 Data segment C of virtual Server in SX 2 Data segment D of virtual Server in SX 3
Figure 2-2 Data segments in 3+1 backup networking (method two) To plan the data with method two, proceed as follows: 1) Specify a public data segment A and independent data segments B, C and D for the three active Servers. Configure the public data of each Server within the public segment range. Different data should be configured within their independent segments. 2) 3) Configure data for each active Server within the public data segment range or its own data segment range. Combine the independent data of the active Servers SX 1, SX 2 and SX 3 together to be the data of B, C and D on the standby Server SX 0.
III. Method Three

Only plan the data by segment in the standby MSC Server and randomly configure the data on active MSC Servers. With the method, independent data segments are planned on the standby MSC Server for active MSC Servers according to the data volume of each active MSC Server. Then, the data of each active MSC Server is mapped to the corresponding data segment in the standby MSC Server.
Data features are as follows:

z z
The data is unique in a module table. Data of module-related physical resources such as links, circuits and BICC CIC, are configured with a maximal tuple number. If a data segment is planned for each module, it will cause a great waste of physical resources and the specified maximal tuples might be insufficient. Therefore, there is no data segment planned in active MSC Servers. For better maintenance, plan data segments in the standby MSC Server and perform capacity expansion when necessary.
In a network adopting narrowband links, 2-Mbit/s links or SIGTRAN networking is adopted to solve the problem.
Key data includes the data of all kinds of links, circuits, and BICC CIC. See Figure 2-3. (Take 3+1 backup as an example.)
MN22 Link 1 Link 2 Link 3 Link 4 ... Data segment A in SX 1 MN22 Link 1 Link 2 Link 3 Link 4 ... MN22 Link 1 Link 2 Link 3 Link 4 ... SX 0 standby Server MN=22 Link 1 Link 2 Link 3 ... Link X Link X+1 Link X+2 ... Link X+Y Link X+Y+1 Link X+Y+2 ... Data segment C in SX 3 MN=23 Link 1 Link 2 Link 3 ... Link X Link X+1 Link X+2 ... Link X+Y Link X+Y+1 Link X+Y+2 ... MN=24 Link 1 Link 2 Link 3 ... Link X Link X+1 Link X+2 ... Link X+Y Link X+Y+1 Link X+Y+2 ...
SX1
SX2
Data segment B in SX 2
SX3
Figure 2-3 Data segments in 3+1 backup networking (method three) To plan the data with method three, proceed as follows: 1) Configure data for active MSC Servers SX 1, SX 2 and SX 3 separately. Combine link data of a same link set (or circuit data of a same office direction) together and share the loads on several modules. 2) Obtain the capacity ratio (A:B:C) of the three offices according to link configuration of active MSC Servers and the capacity plan of customers. Then divide the data of the standby MSC Server into three data segment ranges according to the ratio and the configured maximum number of tuples of the data in each module. 3) Map the link (circuit or BICC CIC) data of SX 1, SX 2 and SX 3 to the proper data segments allocated on the standby MSC Server. Note that the load of links in a same link set (or circuits of a same office direction) should be divided on different modules.
2.3 Planning Data

Plan the data in N+1 backup networking mode according to the following principles:
z z
Allocate an SP and MSC ID for the standby MSC Server. Configure indexes for virtual Server nodes separately. By default, virtual Server node 0 is automatically configured for a local office, while other nodes need to be manually configured. The index of the standby virtual Server node on active MSC Servers should always be set to 1. The index of each active MSC Server is configured on the standby Server to represent Server 1 to server N. In 3+1 backup DH network, virtual Server nodes 0 and 1 need to be configured on the three active MSC Servers (virtual Server 1 is for interchanging heartbeat signals with the standby Server). Virtual Server nodes 0, 1, 2, and 3 need to be configured on the standby Server (nodes 1, 2 and 3 are configured for the standby Server to take over services of the three active Servers and related data).
Configure DH work mode: Set the DH work mode between the local office and a virtual Server node according to the indexes added before. For MTP2-based SS7 links, configure the number of WCSUs on the standby MSC Server according to the total number of SS7 links in all active MSC Servers. For M2UA-based SS7 links, configure the number of WBSGs on the standby MSC Server according to the total number of SS7 links in all active MSC Servers.
Table 2-1 lists the detailed data restrictions.
Note: In the table, N represents "N" in "N+1", while 1 represents "1" in "N+1".
Table 2-1 Detailed data planning Object Command ADD DHHCFG DH heartbeat port MOD DHHCFG RMV DHHCFG LST DHHCFG DH configuration SET DHWM LST DHWM ADD FECFG Local IP configuration MOD FECFG RMV FECFG LST FECFG Independent Heartbeat timeout number: 1180 Heartbeat timeout number 4 The automatic or manual switch mode configured for the N nodes and the 1 node must be consistent. Independent Port number: 165535 =1000 10 The port numbers smaller than 1000 might be reserved by the system and it is not suggested to use them. Restriction Value range Example Default tuple Comment
Independent
The IP address of each board of the N + 1 nodes must be different.
256
Configure the IP address for a local WIFM.
Call source code
ADD CALLSRC
Method one
065533
(N - 1) x 50 to N x 50 - 1, N = (15)
255
z
After DH switch, the system performs called number analysis on the standby Server node according to different call sources and DN sets. Therefore, it is necessary to distinguish the call source of each MSC Server. By default, the maximal tuple number of the call source table is 255. When the 5+1 backup is configured, expand the maximal tuple number of the standby Server node to 300 if necessary.
DN set
ADD CALLSRC ADD CNACLD
Method one
0253
(N - 1) x 10 to N x 10 - 1, N = (15)
255
DN set 9 is for internal use in the system. Skip it during planning.
Object Destination code
Command ADD CNACLD ADD FORWARDCO DE
Restriction
Value range
Example (N - 1) x 10000 to N x 10000 - 1, N = (15) Public office direction: 099; other office direction: N x 100 to (N + 1) x 100 1, N = (15) (N - 1) x 200 to N x 200 - 1, N = (15) (N - 1) x 200 to N x 200 - 1, N = (15) (N - 1) x 1000 to N x 1000 - 1, N = (15)
Default tuple
Comment If the destination codes of all these N nodes are not distinguished, related statistics will be affected after switch.
Method one
065535
Office direction
ADD OFC
Method two
02047
2048
Each of the N nodes is allocated with 100 office directions. The maximal tuple number needs to be expanded when N is greater than 3. Each of the N nodes is allocated with 200 sub-routes. Each of the N nodes is allocated with 200 routes. Each of the N nodes is allocated with 1000 trunk groups.
Sub-route
ADD SRT
Method one
019999
2000
Route
ADD RT
Method one
01999
2000
Trunk group
ADD N7TG, ADD BICCTG
Method one
019999
4000
The maximal tuple number of trunk groups is 4000. It needs to be expanded when N is greater than 3.
Object
Command
Restriction
Value range
Example As the active and backup data are consistent, it is unnecessary to perform DH planning. Configure them as the data of an independent office. It equals to the route number. DN set is used to distinguish virtual Servers.
Default tuple
Comment
Trunk circuit
ADD N7TKC, ADD BICCCIC, ADD AIETKC
Method three
09999
10000
Versions released later than May, 2006 support this configuration mode (configure data as that of an independent office). For earlier versions, it is suggested to plan data segments with method one.
Route selection code
ADD CNACLD
Method one
065535
Route selection source code
ADD CALLSRC
Method one
065535
Route selection source code is used to distinguish greater local network. It equals to the call source code.
To reduce the amount of routing analysis data and promote system performance, it is suggested to use the wildcard of route selection source codes when you configure routing analysis data with the command ADD RTANA.
MTP index
DSP
ADD N7DSP
Method one
065534
(N - 1) x 100 to N x 100 - 1, N = (15)
Each of the N Servers is allocated with 100 SS7 SPs. 256 By default, the maximal tuple number of MTP SPs is 256. If N is greater than 2, you need to expand the tuple number range accordingly.
Object MTP link set index
Command ADD N7LKS
Restriction Method one
Value range 065534
Example It equals to the MTP DSP index. The active Servers are configured separately. Currently the standby Server is configured manually. A tool will be provided to generate the link data automatically on the standby Server in the future. =N
Default tuple 256
Comment If N is greater than 2, you need to expand the tuple number range of the MTP link sets accordingly.
Try to divide the link numbers of those N nodes into segments to keep consistent with data of the 1 node. 32 Make up the shortage of link number segments of the N Servers by mapping. Expand and segmentalize the link number range only on the standby Server.
MTP link
ADD N7LNK
Method three
031
M3UA local entity index
ADD M3LE
Method one
015
16
The values 615 are for the configuration of multiple signaling points on one of the N Servers. Each of the N Servers is allocated with 100 M3UA SPs.
M3UA destination entity index
ADD M3DE
Method one
065534
(N - 1) x 50 to N x 50 - 1, N = (15)
128
By default, the maximal tuple number of M3UA destination entities is 128. If N is greater than 2, you need to expand the tuple number range accordingly. -
M3UA link set index
ADD M3LKS
Method one
065534
It equals to the M3UA destination entity index.
128
Object
Command
Restriction
Value range
Example
Default tuple
Comment Try to divide the link numbers of those N Servers into segments to keep consistent with data of the one standby Server.
M3UA link
ADD M3LNK
Method three
063
(N - 1) x 12 to N x 12 - 1, N = (15)
64
Make up the shortage of link number segments of the N Servers by mapping. Expand and segmentalize the link number range only on the standby Server. -
Signaling gateway ID M2UA link set index
ADD ESG
Method one
0299
It is the same as the MGW index. (N - 1) x 100 to N x 100 - 1, N = (15)
64
ADD M2LKS
Method one
0511
512
Try to divide the link numbers of those N Servers into segments to keep consistent with data of the one standby Server.
M2UA link
ADD M2LNK
Method three
031
32
Make up the shortage of link number segments of the N Servers by mapping. Expand and segmentalize the link number range only on the standby Server. -
IUA link set index SCCP index SCCP index DSP
ADD IUALKS ADD SCCPDSP ADD SCCPSSN
Method one
065534
(N - 1) x 50 to N x 50 - 1, N = (15) (N - 1) x 100 to N x 100 - 1, N = (15) (N - 1) x 200 to N x 200 - 1, N = (15)
256
Method one
065534
512
SSN
Method one
065534
1024
Object SCCP index GT
Command
Restriction
Value range
Example Public GT: 0999 Other GT: 2000 x (N - 1) + 1000 to 2000 x N + 1999 (N - 1) x 10 to N x 10 - 1, N = (15) (N - 1) x 100 to N x 100 - 1, N = (15) (N - 1) x 200 to N x 200 - 1, N = (15) Public: 019, (N - 1) x 200 + 20 to N x 200 + 19, N = (15)
Default tuple
Comment Configure the SCCP GT on the active Servers separately and combine the GTs into one set of data on the standby Server. All the GTs are in DPC. To facilitate the maintenance and reduce faults on the standby Server, it is suggested to use these number processing indexes in segment on active Servers. -
ADD SCCPGT
Method two
080000
80000
MGW ID
ADD MGW
Method one
0299
300
Service check index Number change index CLIP Correlation Processing Authority check original called associated processing record Incoming caller number correlation index
ADD SRVCHK
Method one
065534
512
ADD DNC
Method one
065534
1024
ADD CLCRPRO
Method two
04095
1024
ADD PRICHKORICL DIDX
Method one
065534
(N - 1) x 50 to N x 50 - 1, N = (15)
256
ADD INCLRIDX
Method one
065534
(N - 1) x 200 to N x 200 - 1, N = (15)
1024
Object Incoming original called number correlation index Outgoing caller number correlation index Outgoing original called number correlation index Location number Location area group number CALLGAP index SCP parameter index SCP address index
Command
Restriction
Value range
Example (N - 1) x 200 to N x 200 - 1, N = (15)
Default tuple
Comment
ADD INORICLDIDX
Method one
065534
1024
ADD OUTCLRIDX
Method one
065534
(N - 1) x 200 to N x 200 - 1, N = (15)
1024
ADD OUTORICLDID X ADD LAIGCI, ADD LAISAI ADD LOCGRP
Method one
065534
(N - 1) x 200 to N x 200 - 1, N = (15) (N - 1) x 50 to N x 50 - 1, N = (15) (N - 1) x 50 to N x 50 - 1, N = (15) (N - 1) x 50 to N x 50 - 1, N = (15) (N - 1) x 50 to N x 50 - 1, N = (15) (N - 1) x 50 to N x 50 - 1, N = (15)
1024
Method one Method one
065535 065535
It is used when the advanced roaming restriction is enabled. It is used when the advanced roaming restriction is enabled. If the CALLCAP parameter of each active Server is consistent with each other, you can configure a same index. -
ADD CALLGAP
Method one
0311
312
ADD SCPPARA ADD SCPINFO
Method one
0254
256
Method one
0254
256
Object TDP access code index
Command ADD TDPAC
Restriction Method one
Value range 0311
Example (N - 1) x 50 to N x 50 - 1, N = (15)
Default tuple 32
Comment The maximal tuple number of SCP addresses need to be expanded if the DH networking mode is configured. There is only one set of principles for allocating roaming numbers because several virtual Server nodes on the standby Server share one VLR. It is suggested to allocate the roaming numbers according to the MSCs. Use the number of subscribers of the Server with highest capacity. -
VLR function
ADD VLRCFG
Consistent
MAP function Bill control Tone configuration Software parameter
SET MAPACCFG MOD GBILLCTRL ADD TONECFG
Consistent Consistent Consistent Consistent

3.1 Background
Consistency and concertedness of data between two assistant MSOFTX3000s are vital for configuring DH data. Therefore, data planning is the core for correctly configuring DH data. The following information must be consistent between an active MSOFTX3000 and its standby MSOFTX3000:
z z z z z z
Gateway register information Signaling interconnection information Trunk interconnection information Routing selection scheme Number dialing scheme Service configuration scheme
Only when all of the data are consistent, and an active MSOFTX3000 is switched in a dualhoming network, its assistant standby MSOFTX3000 can take over part of or all of its services. Before data configuration, make clear the following information:
z z z
Networking scheme Equipment (such as frame, board and link) configuration Interworking negotiation data (such as SS7 link, IP address, port number) for connecting to external interfaces
3.2 Procedure
There is a basic principle of sequence for configuring MSOFTX3000 data, that is, configuring internal data first, then interconnection data and finally service data. In addition, apply the sequence during data planning. Figure 3-1 shows the basic flow of DH data configuration.

Start Prepare data Internal data Configure hardware data Configure local data Interconnection data
Configure data for connecting to MGW Configure data for connecting to RNC Configure data for connecting to BSC Configure data for connecting to HLR Configure data for connecting to other MSC Configure data for connecting to PSTN Configure data for connecting to SMC Configure data for connecting to SCP Configure data for connecting to SGSN Configure data for connecting to GMLC Service data
Configure data for number analysis Configure data for mobile service Configure data for IN service End
Figure 3-1 DH data configuration procedure
3.3 Configuration Step

3.3.1 Overview of Configuration Steps
The section introduces steps for configuring the following data:
z z
Proprietary Data Internal Data

z z
Interconnection Data Service Data
3.3.2 Proprietary Data

DH proprietary data, a kind of MSOFTX3000 basic data, is used to define the DH virtual Server node, working mode and heartbeat link.
I. Setting DH Work Mode

Work mode, a parameter, is used to define the work mode of a local office in a network. You can use the command SET DHWM to set Work mode to Standalone or Assistant. Following is the description of key parameters. Work mode It defines the work mode of the local MSOFTX3000 (MSC Server) in the network. The default option is Standalone. Options of the parameter are as follows:
z z
Standalone: indicates the local MSOFTX3000 does not work in DH mode. Assistant: indicates the local MSOFTX3000 works in the DH mode.
Server node index It is only valid when Work mode is set to Assistant. It specifies the virtual Server node whose work mode is to be set here. Configure the parameter by the following principles:
z
If it is set to 0, the DH work mode of the local Server node is to be set. Precondition: There is an MSOFTX3000 in the network which is the assistant Server node for the local MSOFTX3000 in networking.
If it is set to a value other than 0, the DH work mode of that Server node is to be set. And this parameter must be defined by ADD SRVNODE before it can be used here. Precondition: The local MSOFTX3000 is the assistant Server node for a certain physical MSOFTX3000 that the virtual Server node defined here corresponds to.
Switch mode It is only valid when Work mode is set to Assistant. It defines the switch mode of a certain virtual Server node in the local office. The default option is Manual. Options of the parameter are as follows:
z
Manual: When the MSC Servers work in assistant mode, the state of the appropriate virtual Server node can be switched over after the operator executes the switch command SET DHWM through the LMT or NMS.
Automatic: When working in assistant DH mode, the MSC Server switches the state of the appropriate virtual server node automatically according to the state of the heartbeat link between the assistant MSC server and itself. For example, when there is no heartbeat signal from the peer, the local MSC server sets the state of
an appropriate virtual server node to be activated automatically; when the heartbeat recovers, the local MSC server switches the state to be deactivated. Note that if Switch mode of a virtual Server node in the local office is set to Automatic, proceed as follows to configure data: 1) 2) 3) 4) Use the command SET DHWM to set Work mode of virtual Server node 0 to Assistant, Switch mode to Manual, and Force state to Activated. Use the command ADD SRVNODE to set the assistant MSOFTX3000 of a local one (for example, virtual Server node 1) to a DH MSC Server node. Use the command ADD DHHCFG to add a DH heartbeat link between a local MSOFTX3000 and its assistant MSOFTX3000. Use the command SET DHWM to set Work mode of the virtual Server node corresponding to the assistant MSOFTX3000 to Assistant, and Switch mode to Automatic. Following are configuration scripts of the previous steps:
SET DHWM: WM=ASSIST, SI=0, SM=MANUAL, FS=ACTIVE; ADD SRVNODE: SI=1, SN="LGMSOFTX3000"; ADD DHHCFG: SI=1, MN=132, IP="191.169.1.33", KEY="123456"; SET DHWM: WM=ASSIST, SI=1, SM=AUTO;
Force state It is valid when Switch mode is set to Manual. It defines the assistant state of a proper local virtual server node. The default value is Deactivated.Options of the parameter are as follows:
z
Deactivated: to force the virtual Server node to work in the DH deactivated mode manually. Then this virtual server node cannot process any service under its control, that is, in an idle state.
Activated: to force the virtual Server node to work in the DH activated mode manually. Then this virtual Server node can process all of its services.
Takeover mode It is valid when Switch mode is set to Automatic. It defines the takeover mode when a certain local virtual Server node is switched over automatically. The system supports all the modes. Options of the parameter are as follows:
z
Auto takeover: indicates that during the automatic switch, the system allows corresponding virtual Server node to switch from deactivated state to activated state. That is, the local MSOFTX3000 is able to take over services of the MSOFTX3000 that this virtual Server node corresponds to. If virtual server node 0 is not able to take over the services (Auto takeover is not selected), then after the local MSOFTX3000 is restarted, virtual server node 0 will be switched to deactivated state automatically.

z
Auto backward: indicates that during the switch, the system allows a certain virtual Server node to switch from activated state to deactivated state. That is, the local MSOFTX3000 is able to give back the services to the MSOFTX3000 that this virtual Server node corresponds to.
If the carrier wants to implement the automatic DH switch function, then you have to set Takeover mode to All for virtual Server node 0 and its corresponding node at the two MSOFTX3000s sides working in assistant mode. However, to ensure reliability of the system operation, it is suggested to set Takeover mode to Non-Auto Takeover and Non-Auto Backward for virtual Server node 0 and set Takeover mode to Auto Takeover and Non-Auto Backward for its corresponding virtual Server node. Thus it can prevent frequent switch when the bearer network is unstable. In other words, when an MSOFTX3000 is faulty, its assistant Server can take over the services automatically. After recovery, the faulty MSOFTX3000 is in the deactivated state and its assistant Server continues to process its services. After confirming the system or network is stable, the operator can execute SET DHWM to deactivate the assistant virtual Server node at the assistant MSOFTX3000 side and then to activate virtual Server node 0 at the original MSOFTX3000 side. Handshake timeout (*5s) It is valid when Work mode is set to Assistant and Server node index to a value other than 0. After the local MSOFTX3000 sends a heartbeat signal to its assistant MSOFTX3000, this parameter specifies the maximum duration for the local MSOFTX3000 to wait for the handshake signal from the peer. That is to say, if the local MSOFTX3000 does not receive a handshake signal from the assistant side within the specified duration, it considers the assistant MSOFTX3000 faulty. It depends on the switch mode of the appropriate virtual server node whether to switch or not. The unit of this parameter is five seconds. The default value is 30 x 5, that is, 150s.
II. Setting DH Virtual Server Node

In the table of virtual Server nodes, item 0 is always configured for a local MSC Server, while other items are configured for assistant or standby MSC Servers. The node ID is uniquely valid in the local MSC Server, and serves as the configuration reference of other service data. To add a virtual Server node, use the command ADD SRVNODE. Before adding a virtual Server node in the MSC Server, set Work mode of the virtual Server node 0 to Assistant with the command SET DHWM to activate the dualhoming function of the local office. Following is the description of key parameters: Server node index
It defines a DH Server node index in the configuration database of the MSOFTX3000. The local MSOFTX3000 (MSC Server) can interwork with at most five MSOFTX3000s in the 5+1 backup DH network. So, the value ranges from 1 to 5. Note that in the local configuration database, the local MSOFTX3000 Server node index is always 0. You cannot modify it. Server node name It identifies an MSC Server with a string of characters. Assistant server node It defines whether the Server node configured here can take over the services of the local MSOFTX3000. The default value is No, indicating that this MSC server is not the assistant Server node for the local MSOFTX3000. If the Server node (MSC Server) configured here is the assistant Server node for the local MSOFTX3000, set the parameter to Yes. Internal MGW media type For the internal MGWs controlled by the Server node (MSC Server) configured here, this parameter defines the bearer type of the media stream among these MGWs. The default value is IP. Options of the parameter are as follows:
z
AAL1: indicates that the media stream is ATM data packet after unstructured AAL1 adaptation, that is, the media streams among the MGWS are borne over the ATM packet network. AAL1 supports the transmission of real-time and connection-oriented media streams with constant bit rate, for example, uncompressed audio and video packets. Unstructured AAL1 only supports mapping the whole E1 link onto the ATM cell, instead of mapping one or several time slots in the E1 link onto the ATM cell. That is to say, it does not support the N x 64-kbit/s service.
AAL2: indicates that the media stream is ATM packet after AAL2 adaptation. In other words, the media streams between the MGWS are borne over the ATM packet network. AAL2 supports the transmission of real-time and connection-oriented media streams with variable bit rate, for example, compressed audio and video packets.
AAL1 structure: indicates that the media stream is ATM packet after structured AAL1 adaptation. In other words, the media streams between the MGWS are borne over the ATM packet network. AAL1 supports the transmission of real-time and connection-oriented media streams with constant bit rate, for example, uncompressed audio and video packets. Structured AAL1 supports mapping the whole E1 link onto the ATM cell and mapping one or several time slots in the E1 link onto the ATM cell. That is to say, it supports the N x 64-kbit/s service.
IP: indicates that the media stream is IP packet. In other words, the media streams between the MGWS are borne over the IP packet network.

z
TDM: indicates that the media stream is PCM code stream. In other words, the media streams between the MGWS are borne over the TDM circuit network.
Internal MGW connection type For the internal MGWs controlled by the Server node (MSC Server) configured here, this parameter defines the topology type of the media streams between these MGWs. The default value is All MGW connection. Options of the parameter are as follows:
z
Not all MGW connection: indicates that when the media streams between any two MGWs go through the bearer network, only part of them can be transmitted directly while other streams have to be transferred by other MGWs. When Internal MGW media type is set to TDM, since the TDM circuit network cannot serve as a switch itself, generally you must set this parameter to Not all MGW connection, unless the media streams are transmitted on mesh network topology. If the media streams are transmitted on mesh network topology, you must set this parameter to All MGW connection.
All MGW connection: indicates that the media streams between any two MGWs can be transmitted over the bearer network directly. When Internal MGW media type is set to AAL1, AAL2, AAL1 structure or IP, since the ATM or IP packet network can serve as a switch itself, the media streams between any two MGWs can be transmitted directly over the bearer network. So you must set Internal MGW connection type to All MGW connection.
When Internal MGW connection type is set to Not All MGW connection, you have to configure the path information between MGWs with ADD MGWPATH. Internal MGW path select mode It is valid when Internal MGW connection type is set to Not All MGW connection. For the internal MGWs controlled by the Server node configured here (MSC Server), when the media streams between two MGWs are transmitted over two or more communication paths, this parameter specifies the mode used by the system to select the paths. The default value is Automatic. Options of the parameter are as follows:
z
Automatic: The system always selects the shortest path between the source MGW and the destination MGW first. If there are several shortest paths, the system selects them in turn. If all the shortest paths are invalid, the system selects the shorter path. It is true with other conditions.
z z
Random: The system selects a path randomly. It is seldom used. Recycle: The system selects within all available paths according to a certain order, that is, in the load-sharing mode. Suppose there are N available paths, the probability of a path to be selected is 1/N.
Percent: The system selects the path according to the percent preset in the configuration database. The percent of a path to be selected is defined by ADD MGWPATH.
III. Setting Local Port of DH Heartbeat Link (Optional)

In actual networking, the signals in the DH heartbeat link are borne through the UDP protocol. By default, the UDP port number of the heartbeat link of the local MSOFTX3000 is 1000. You do not have to change the port number normally. However, if carriers have special requirements, you can change the UDP port number with SET DHLOCPORTNO. Following is the description of key parameters. WIFM module number It specifies the module number of the WIFM through whose FE port the local MSOFTX3000 sends heartbeat signals to the peer. This parameter is defined by ADD BRD before it can be used here. If there are two or more pairs of WIFMs in the whole system, you should configure two heartbeat links between the two MSOFTX3000s to guarantee the reliability of heartbeat signal transmission. Local port number As one of the parameters used for interworking with the peer MSOFTX3000, it specifies the UDP port number used when the local MSOFTX3000 sends heartbeat signals. The value ranges from 1 to 65535.
IV. Setting DH Heartbeat Link

In a network, signals of DH heartbeat link are transmitted through the UDP protocol. The heartbeat link between a local office and its assistant office is added with the command ADD DHHCFG. By default, the UDP port number used by the heartbeat link of the local MSOFTX3000 is 1000, which needs not to be modified in common situations. Those port numbers, smaller than 1000, might be reserved and it is suggested not using them. Unless there are some special requirements of telecom operators, use the command SET DHLOCPORTNO to set the local UDP port number for the dualhoming heartbeat link. In addition, to ensure the reliability of heartbeat signals for a system that configured with two pairs of WIFMs or more, configure two heartbeat links between the two MSOFTX3000s. Following is the description of key parameters. Server node index It specifies the server node that is connected to the local MSOFTX3000 by the DH heartbeat link. This parameter must be defined by ADD SRVNODE before it can be used here. WIFM module number
It specifies the module number of the WIFM through whose FE port the local MSOFTX3000 sends heartbeat signals to the peer. This parameter must be defined by ADD BRD before it can be used here. If there are two or more pairs of WIFMs in the whole system, you should configure two heartbeat links between the two MSOFTX3000s to guarantee the reliability of heartbeat signal transmission. Peer IP address As one of the parameters used for interworking with the peer MSOFTX3000, it specifies the IP address of the WIFM in the peer MSOFTX3000 that sends heartbeat signals. Peer port number As one of the parameters used for interworking with the peer MSOFTX3000, it specifies the UDP port number used when the peer MSOFTX3000 sends heartbeat signals. The value ranges from 1 to 65535. The default value is 1000. Encryption method As one of the parameters used for interworking with the peer MSOFTX3000, it specifies whether the heartbeat signals between the two MSOFTX3000s needs encrypting, and if needed, what the type of encryption is. The default type is MD5. This means the heartbeat signals needs encrypting and the MD5 encryption algorithm is employed. Key As one of the parameters used for interworking with the peer MSOFTX3000, it specifies the key required by the MD5 encryption algorithm when the heartbeat signals between the two MSOFTX3000s needs encrypting. The value should be a character string of at most 16 characters.
3.3.3 Internal Data

In a DH network, the configuration of internal data is the same as that configured for a network not adopting the dualhoming networking. The internal data is listed as follows:
I. Hardware Data
The hardware data is used to define the composition of equipment hardware, parameter of physical ports, configuration of module functions, and mode of clock synchronization. The configuration of hardware data depends on physical configuration. To avoid conflicts between virtual Server nodes, the parameter (for example, the SCTP parameter) of physical ports should be uniformly allocated.
II. Local Data

Before local data, complete configuring dualhoming proprietary data and add corresponding virtual Server nodes. Then configure corresponding local information for the virtual Server nodes. The local data is used to define the following information of a local office:
z z z z z z z z
Signaling point code Country code and area code National toll area code Multi-area statistics index DN set Call source code Local MSC number Local VLR number
Caution: During configuration, set Multi-area flag to True. Otherwise, the data of traffic statistics for different virtual nodes cannot be distinguished. All statistics will be regarded to be for virtual Server node 0.
3.3.4 Interconnection Data

During the DH configuration, the interconnection data is used to restrict commands and parameters sent to assistant network elements.
Note:
z
At present, the DH configuration is not involved in the data connecting to the SMC, SGSN and GMLC interfaces and this chapter does not introduce the data configuration for connecting these interfaces.
z z
The previous data configuration is optional and depends on the actual networking, The data of each interface is independent and there is fixed sequence for the data. It is recommended to configure the data in the sequence described in the manual. External interfaces of the MSOFTX3000 include multiple protocols of the transport layer. Before configuration, make clear the networking scheme.
I. Mc Interface Data for Connecting to MGW

The data for connecting to the MGW is an interconnection data of the MSOFTX3000. It defines the following information:
z z z
The data of H.248 links between the MSOFTX3000 and the MGW The Media connection relationship between MGWs The information of paths between MGWs
The parameter MGW index (ADD MGW) is directly associated with the index of virtual Server nodes and determines the virtual Server node to which the MGWs belong.
II. Signaling Interface Data

The configuration data of signaling interfaces refers to the data used for configuring public underlying signaling links. It includes the data of MTP, M2UA/IUA and M3UA signaling.
z
Note to MTP Configuration
The MSC Server node to which MTP DSP and subsequent data to be configured (such as MTP link set, MTP routing and MTP link) belong is determined by the MSC Server node to which a local SP belongs. If a local SP specified by the MTP DSP belongs to virtual Server node 0, the MTP DSP and subsequent data to be configured are also in the charge of virtual Server node 0. Proceed as follows to implement the M2UA-based MTP3 configuration: 1) 2) 3)
z
Configure active N7DSP, N7LKS, N7RT and N7LNK for virtual MSC Server node 0. Configure standby N7DSP, N7LKS, N7RT and N7LNK for other virtual MSC Server nodes. Follow the share-alike principle to select the WBSG module on the MSOFTX3000 and try to make all WBSGs share services of one SG. Note to M2UA/IUA Configuration
The virtual Server node to which the ESG is homed, determines the virtual Server node, to which links and link sets of M2UA or IUA are homed. The virtual Server node to which the MGW is homed, determines the virtual Server node, to which ESG is homed. Therefore, if the ESG is homed to virtual Server node 0, the links and link sets of M2UA or IUA are in the charge of virtual Server node 0. Proceed as follows to implement the M2UA/IUA configuration: 1) 2) 3) Configure active ESG, M2UA link sets and links for virtual Server node 0. Configure standby ESG and M2UA links and link sets for other virtual Server nodes. Configure one M2UA link set for the MGW (embedded ESG). The link set contains two links, one of which is connected to an active MSC Server and the other is connected to a standby MSC Server.
4)
z
Configure an M2UA link on the MGW (embedded ESG). Then the M2UA link set makes the link be managed by the virtual Server node that manages itself. Note to M3UA Configuration
The MSC Server node, to which a local SP is homed, determines the MSC Server node, to which M3LE and its subsequent data configuration (M3DE, M3LKS, M3RT and M3LNK) are homed. If local SP node 0 is specified for M3LE, the configuration of its subsequent data is in the charge of local SP node 0. Proceed as follows to implement the M3UA configuration: 1) 2) 3) Configure active M3UA local entities, destination entities, link sets, routes and links for virtual Server node 0. Configure standby M3UA local entities, destination entities, link sets, routes and links for other virtual Server nodes. Configure a link set between the MGW (embedded SG) and its corresponding SP. In the link set, configure links according to the number of the SPFs. In addition, set priorities of the links connecting to two MSOFTX3000s. Configure the link connecting to the active MSOFTX3000 with a higher priority, and the link connecting to the standby MSOFTX3000 with a lower priority. 4) Follow the share-alike principle to select the WBSG module on the MSOFTX3000 and try to make all WBSGs share services of one SG.
Note: Configure the management area on the assistant MSC Server according to the virtual Server nodes. For signaling interfaces, except the physical port and address, adopt the same configuration as that of the virtual Server nodes.
III. Trunk Office Direction Data

Configure the data of A interfaces, ISUP, TUP, R2, PRA, BICC office directions, sub-routes, routes, routing analysis, trunk groups and circuits in the same way as configure the common data.
IV. Nc Interface Data

When configuring the BICCSCTP link according to a planned BICC office direction, adopt the planned virtual Server node, to which the office direction is homed, as the virtual Server node, to which the link is homed.
3.3.5 Service Data

I. Paging Optimization in DH Network
When paging in a global network is initiated after the DH switch, to avoid overload in the access layer, it is necessary to avoid simultaneously sending paging messages to multiple virtual Servers. If the optimization function of global multi-area network paging is enabled, and data is restored after the DH switch, the paging is performed only in the local network (MSC/VLR) where a callee is located. P164 BIT4:
z
=0: Optimize the global multi-area network paging and perform the paging in a local network (MSC/VLR) only. =1: Not to optimize the global multi-area network paging and perform the paging in a multi-area network.
Default value: 1.
II. Service Data Switch

Intra-office data switch: The switch between location areas in a same virtual Server node is the intra-office switch. The data configuration is the same as that in common cases. Inter-office data switch between different virtual Server node: A location area whose local office is configured with a virtual Server node will be configured as a local VLR location area cell/service area. Therefore, it is unnecessary to configure adjacent cells for the switch between assistant offices. Cells that belong to different virtual Servers are considered as adjacent cells, and the switch performed between them is inter-office switch. The SCCP data configuration is the same as that in common cases. Inter-office data handover between different MSC Servers: The DH networking makes no difference to the configuration of SCCP data, adjacent cells, and adjacent BSC/RNCs. Then configure the data as common data.
III. Number Analysis and Routing Function

Configure the data in the same way as configure the common data.

4.1 DH Commissioning
After the data configuration, proceed as follows to verify the services:
z z z z
Verifying That Network Connections Are Normal Verifying That DH Heartbeat Link Is Normal Verifying Services Before DH Switch Verifying Services Taken Over After DH Switch
4.1.1 Verifying That Network Connections Are Normal

In the MSOFTX3000 LMT, choose Trace Management > Interface Trace Task > PING in the Maintenance tab and check whether two assistant MSOFTX3000s are normally connected. If they are connected normally, proceed the subsequent steps. If not, remove faults and then proceed the subsequent steps. For example, check whether network cables are connected normally and whether IP routing data is configured correctly.
4.1.2 Verifying That DH Heartbeat Link Is Normal

Use the command DSP DHSTA to check whether the DH heartbeat works normally. After the execution, the output displays the number and the status of DH heartbeats of virtual Server nodes (no heartbeat link connected to node 0) in a local office. Normally, only virtual Server node 0 in a local office should be active, while other virtual Server nodes are inactive, and heartbeat links work normally.
4.1.3 Verifying Services Before DH Switch

Normally, every MSC Server works in good conditions and only virtual Server node 0 is active. In the case, check the signaling link status, circuit status, MO call service, MT call service and supplementary service of the MSC Server, namely, virtual Server node 0.
4.1.4 Verifying Services Taken Over After DH Switch

Verify the DH switch of active MSC Servers: Manually set the status of an active Server to the breakdown state or make the MSC Server breakdown by simulating power failure. In this case, the corresponding virtual Server node in the standby MSC Server should be activated. When the virtual Server node is activated, verify the signaling link status, circuit status, MO call service, MT call service and supplementary service of the original active MSC Server.
Verify services of another MSC Server in the same way after it is switched over.
4.2 DH Switch
If the triggering conditions of the DH switch is satisfied, all MGWs connected to MSOFTX3000 A will register with MSOFTX3000 B. After the corresponding service data is activated, MSOFTX3000 B takes over all services. Following are two dualhoming switch modes:
z z
Auto Switch Manual Switch
4.2.1 Auto Switch

The interruption of the heartbeat link is the unique triggering condition of auto switch. Following are possible causes of interruption of heartbeat links:
z z z
The MSC Server is broken down due to power failure. Both the active and standby WIFMs are faulty. All network ports of the MSC Server are faulty.
In the N+1 backup DH network, if any of the N active MSOFTX3000s is faulty, the standby MSOFTX3000 will auto take over its services. At a time, the standby MSOFTX3000 can only take over services for one active MSOFTX3000.
II. Operation
You can specify whether switch and backward is allowed through data configuration. If the switch is allowed, the MSC Server will auto switch when the heartbeat link is interrupted. In the N+1 backup DH network, to perform the auto switch, use the command SET DHWM to set Work mode of all nodes to Assistant, Switch mode to Automatic, and Takeover mode to Auto takeover. Then if any active MSOFTX3000 is faulty, and the heartbeat link is interrupted, the standby MSOFTX3000 will auto take over all services.
III. Precaution
z
Avoid the C/D interface congestion.
After the DH switch, the data of subscribers of the active MSC Server is not restored in the standby VLR. When a subscriber initiates a location update or service request for the first time, the VLR needs to take subscriber data and authentication set from the HLR. In this case, the flow through the C/D interface rises and the link might be congested. To avoid the congestion, use the command SET MAPPARA to switch on the flow control of location update after the DH switch. For each WCCU, set Inter-VLR location
update count upon dual-home flow control to 10 in unit of count/second, and Intra-VLR location update count upon dual-home flow control to 2 in unit of count/second. If the count of location updates reaches the value that has been set, the subsequent location updates will be processed as fake access to the network, that is, the location updates are not processed by the HLR, but the handsets are informed that the location updates are accepted. In addition, if the load remains heavy after the switch, disable the authentication and encryption functions for a while. When the flow of messages reduces, enable the functions again.
z
Avoid the paging channel congestion.
After a DH switch, the location data of subscribers served by the active MSC Server is not stored in the standby VLR at the beginning. When each of the subscribers is called for the first time, the MSC will initiate the global network paging, which might increase the paging volume and cause paging channel congestion. To reduce the paging volume and avoid the congestion, set the count of global network paging to 1 (through P164 bit 2-1).In addition, you can switch on the optimization function of global network paging (through P164 Bit 4), and the paging is performed only in the minimum local network. For any modification involved in the parameter, contact local technical engineers of Huawei.
4.2.2 Manual Switch

Manually setting the DH status is the unique triggering condition of manual switch. In this case, whether to perform DH switch completely depends on manual setting. If the DH switch cannot be auto triggered, you can trigger it manually. For example, the heartbeat between an active and standby MSC Servers is existing, but all calls are blocked, or CDB is completely faulty, which also causes interruption of all services. In this case, you can manually trigger DH switch.
II. Operation
Carry out the command SET DHWM on the active MSC Server, and set the status of the active Server node 0 to Deactivated. Then, carry out the command SET DHWM on the standby MSC Server, and set the status of the proper virtual Server node to Activated. Thus, services of the active MSC Server are taken over by the corresponding virtual Server node on the standby MSC Server.
III. Precaution
The precaution of the manual switch is the same as that of the auto switch. In addition, before the DH manual switch, make sure that the standby MSC Server works normally. Otherwise, services will be interrupted after the manual switch.
4.3 DH Backward
Following are two DH backward modes:
z z
Auto Backward Manual Backward
4.3.1 Auto Backward

After switched to a standby MSC Server, the active MSC Server will auto switch back and take back all services from the standby MSC Server, if it is recovered and restarted, and its heartbeat link is recovered. Following are triggering conditions of auto backward:
z z
Recovery of the heartbeat link Takeover mode of the standby virtual Server node is set to Auto backward.
II. Operation
Before the DH switch, use the command SET DHWM to set Work mode of all virtual Server nodes to Assistant, Switch mode to Automatic, and Takeover mode to Auto backward. Then, when the active MSC Server recovers, all services can auto transfer from the standby MSC Server to the active MSC Server.
III. Precaution
In actual use, auto switch and manual backward are recommended to minimize the time of service interruption and avoid repeated switches during system abnormality.
4.3.2 Manual Backward

Manually setting the DH status is the unique triggering condition of manual backward. In this case, whether to perform dualhoming backward completely depends on manual setting.
II. Operation
Carry out the command SET DHWM on the standby MSC Server, and set the status of the standby virtual Server node to Deactivated. Then, carry out the command SET DHWM on the active MSC Server, and set the status of the active virtual Server node 0 to Deactivated. Thus, the virtual Server node 0 takes back all services from the standby MSC Server.
III. Precaution
Before the manual backward, make sure that the active MSC Server recovers. Otherwise, services will be interrupted after the manual backward.

The commissioning items listed in this chapter are to verify some functions in DH work mode before or after switch. Following sections are for your information only.
5.1 Networking Description

Figure 5-1 shows the N+1 backup DH networking (N = 2). MSC Server 3 is the standby Server for MSC Servers 1 and 2. MSC Server 1 controls MGWs 1 and 2 while MSC Server 2 controls MGWs 3 and 4.
MSC Server 1 Heartbeat link MSC Server 3 Heartbeat link MSC Server 2
MGW 1
MGW 2
MGW 3
MGW 4
Local network A
Local network C
Main control channel
Slave control channel
Figure 5-1 N+1 backup DH networking (N = 2) When MSC Server 1 or 2 becomes faulty, the services can be switched over to MSC Server 3. The following commissioning items are designed for this networking mode. No matter MSC Server 1 or MSC Server 2 is faulty, the commissioning cases are applied. Data configuration description (N+1 backup, N = 2): Configure the DH data. Set the networking mode to N+1 backup (N = 2) and MSC Server 3 to be the standby Server for MSC Servers 1 and 2. Following are just commissioning items for verification of basic functions.
5.2 Before Switch

Suppose the services of MSC Server 1 are to be switched over to MSC Server 3.
Table 5-1 Commissioning items for the network before switch Item 1 Description
z
Expected result The location information is updated successfully. The subscriber information in the VDB is correct. The location information is updated successfully. The subscriber information in the VDB is correct. The location information is updated successfully. The subscriber information in the VDB is correct. The call is established successfully. The MSC index in the MOC bills generated by MSC Server 1 is correct. The call is established successfully. The MSC index in the MOC bills generated by MSC Server 2 is correct. The call is established successfully. The bills generated by MSC Servers 1 and 2 are correct. The call is established successfully. The MSC index in the MTC bills generated by MSC Server 1 is correct. The call is established successfully. The MSC index in the MOC bills generated by MSC Server 2 is correct. The call is established successfully. The MSC index in the MTC bills generated by MSC Server 1 is correct. The call is established successfully. The MSC index in the MOC bills generated by MSC Server 2 is correct.
Location update
MS1 initiates a location update request (first time) to MSC Server 2. MS 1 requests to update the location from MSC Server 1 to MSC Server 2.
Basic call
MS 2 served by MSC Server 2 calls a PSTN subscriber.
MS A in another office (not MSC Server 1 or 2) calls MS 1 served by MSC Server 1.
MSC 2 served by MSC Server 2 calls MS A in another office (not MSC Server 1 or 2).
Item
Description
z
Expected result The call is established successfully. The MSC index in the bills generated by MSC Server 1 is correct. The call is established successfully. The bills generated by MSC Servers 1 and 2 are correct. The handover succeeds and calls can be established successfully. The bills are generated correctly by MSC Server 1. The circuits are released correctly. The handover succeeds and calls can be established successfully. The bills generated by MSC Servers 1 and 2 are correct. The circuits are released correctly. The short messages can be sent and received successfully. The MSC index in bills generated for short messages are correct. The short messages can be sent and received successfully. The MSC index in bills generated for short messages are correct.
1 Intelligent call 2
PPS subscriber MS 1 served by MSC Server 1 calls PPS subscriber MS 2 served by the same Server. PPS subscriber MS 1 served by MSC Server 1 calls PPS subscriber MS 2 served by MSC Server 2.
Handover
z
The MS served by MSC Server 1 is handed over to MSC Server 2.
1 Short message 2
MS 1 served by MSC Server 1 sends short messages to MS 2 served by the same Server. MS 1 served by MSC Server 1 sends short messages to MS 2 served by MSC Server 2. Query the states of MGWs 1 and 2 on MSC Server 1. Query the states of MGWs 3 and 4 on MSC Server 2. Query the states of MGWs 1, 2, 3 and 4 on MSC Server 3. Query the states of circuits, such as N7TKC and AIETKC, on MSC Servers 1 and 2 respectively. Query the states of circuits of virtual MSC Servers 1 and 2 respectively, such as N7TKC and AIETKC, on MSC Server 3. Query the states of links, such as MTP3, M3UA, and M2UA, on MSC Servers 1 and 2 respectively.
1 2 3
The states of MGWs 1 and 2 are normal. The states of MGWs 1 and 2 are normal. The query fails and the system prompts that the device is invalid. The states of circuits are normal.
The query fails and the system prompts that the circuits are not installed.
The states of links are normal.
Item
Description Query the states of links of virtual MSC Servers 1 and 2 respectively, such as MTP3, M3UA, and M2UA, on MSC Server 3.
Expected result The query fails and the system prompts that the links are not configured.
z
Traffic measurement
Register the traffic measurement results of MSC Servers 1 and 2, such as M3UA and M2UA link sets measurement results on themselves respectively before switch. Register the traffic measurement results of virtual MSC Servers 1 and 2 on MSC Server 3.
The traffic measurement results of MSC Servers 1 and 2 are correct. The traffic measurement results of virtual MSC Servers 1 and 2 on MSC Server 3 are all 0.
5.3 After Switch

Suppose the services of MSC Server 1 are to be switched over to MSC Server 3. Table 5-2 Commissioning items for the network after switch Item Description
z
Expected result
z
MS 1 served by MSC Server 1 before switch initiates a call for the first time after switch.
The call is rejected. The location update flow is activated. The location is updated successfully. The location is updated successfully. The subscriber information in the VDB is correct. The location is updated successfully. The subscriber information in the VDB is correct. The location is updated successfully. The subscriber information in the VDB is correct. The data restoration flow is activated during call connection. The call is established successfully. The bills are generated correctly. The traffic measurement results are correct.
2 Location update 3
MS 1 served by MSC Server 1 requests to update the location with IMSI. MS 2 requests to update the location from MSC Server 1 to MSC Server 2. MS 2 requests to update the location from MSC Server 2 to MSC Server 1.
Basic call
MS 1 served by MSC Server 1 before switch is called for the first time after switch.
z z
Item
Description
z
Expected result
z
MS 1 served by MSC Server 1 before switch calls others for the first time after switch.
The call is rejected. The location update flow is activated. The location is updated successfully. The call is established successfully. The MSC indexes in the bills are correct. The call is established successfully. The MSC indexes in the bills are correct. The call is established successfully. The call is processed as an inter-office call. The MSC indexes in the bills are correct. The call is established successfully. The call is processed as an inter-office call. The MSC indexes in the bills are correct. The call is established successfully. The MSC indexes in the bills are correct. The call is established successfully. The MSC indexes in the bills are correct. The call is established successfully. The MSC indexes in the bills are correct. The call is forwarded successfully. The call is established successfully after being forwarded. The bills generated for call forwarding, caller and callee are correct.
MS A in another office (not MSC Server 2) calls MS 1 served by MSC Server 1. MS 1 served by MSC Server 1 calls MS A in another office (not MSC Server 2). A PSTN subscriber calls MS 1 served by MSC Server 1.
8.
Forwarded call
MS 1 served by MSC Server 1 calls MS 2 served by the same Server after switch and the call is fowarded unconditionally to MS 3 served by MSC Server 1.
Item
Description
z
Expected result The call is forwarded successfully. The call is established successfully after being forwarded. The bills generated for call forwarding, caller and callee are correct. The call is forwarded successfully. The call is established successfully after being forwarded. The bills generated for call forwarding, caller and callee are correct. The call is forwarded successfully. The call is established successfully after being forwarded. The bills generated for call forwarding, caller and callee are correct. The call is forwarded successfully. The call is established successfully after being forwarded. The bills generated for call forwarding, caller and callee are correct. The call is forwarded successfully. The call is established successfully after being forwarded. The bills generated for call forwarding, caller and callee are correct. The call is forwarded successfully. The call is established successfully after being forwarded. The bills generated for call forwarding, caller and callee are correct.
MS 1 served by MSC Server 1 calls MS 2 served by the same Server after switch and the call is forwarded unconditionally to MS 3 served by MSC Server 2.
MS 1 served by MSC Server 1 calls MS 2 served by MSC Server 1 after switch and the call is forwarded unconditionally to a PSTN subscriber.
MS 1 served by MSC Server 1 calls MS 2 served by MSC Server 2 after switch and the call is forwarded to MS A in another office (not MSC Server 1) due to no reply.
Item
Description
z
Expected result The short messages can be sent and received successfully. The MSC indexes in bills generated for short messages are correct. The short messages can be sent and received successfully. The MSC indexes in bills generated for short messages are correct. The short messages can be sent and received successfully. The MSC indexes in bills generated for short messages are correct. The switch succeeds and calls can be established successfully. The bills generated by MSC Servers 1 are correct. The circuits are released correctly. The switch succeeds and calls can be established successfully. The bills generated by MSC Servers 1 are correct. The circuits are released correctly. The switch succeeds and calls can be established successfully. The bills generated by MSC Servers 1 and 2 are correct. The circuits are released correctly.
Short message
Handover
1 2
Query the states of MGWs 1 and 2 on MSC Server 1. Query the states of MGWs 1 and 2 on MSC Server 3. Query the states of circuits on MSC Server 1, such as N7TKC and AIETKC. Query the states of circuits on MSC Server 3. Query the states of links on MSC Server 1, such as MTP3 link and M3UA link. Query the states of link on MSC Server 3.
The query fails and the system prompts that the device is invalid. The states of MGWs are normal. The query fails and the system prompts that the circuits are not installed. The states of circuits are normal. The query fails and the system prompts that no link is configured. The states of links are normal.
Item
Description Register the traffic measurement results of virtual MSC Server 1, such as M3UA and M2UA link set measurement, on MSC Server 3 after switch. Set up a tracing task on MSC Server 3 to trace subscribers served by virtual MSC Server 1 after switch. Set up a tracing task on MSC Server 3 to trace links such as M3UA, M2UA and MTP3 served by virtual MSC Server 1 after switch.
Expected result
Traffic measurement
The traffic measurement results of virtual MSC Server 1 are normal. The tracing task is created successfully. The messages can be traced normally. The tracing task is created successfully. The messages can be traced normally.
1 Tracing function 2
5.4 Backward
Suppose the services of MSC Server 3 are to be switched back to MSC Server 1. Table 5-3 Commissioning items for services backward Item Description
z
Expected result The location is updated successfully. The subscriber information in the VDB is correct. The location is updated successfully. The subscriber information in the VDB is correct. The location is updated successfully. The subscriber information in the VDB is correct. The call is established successfully. The MSC indexes in the MOC bills generated by MSC Server 1 are correct. The call is established successfully. The bills generated by MSC Server 2 are correct. The call is established successfully. The bills generated by MSC Servers 1 and 2 are correct.
Location update
MS1 initiates a location update request (first time) to MSC Server 2. MS 1 requests to update the location from MSC Server 1 to MSC Server 2.
Basic call
Item
Description
z
Expected result The call is established successfully. The MSC indexes in the bills generated by MSC Server 1 are correct. The call is established successfully. The MSC indexes in the bills generated by MSC Servers 1 and 2 are correct. The switch succeeds and calls can be established successfully. The bills are generated correctly by MSC Server 1. The circuits are released correctly. The switch succeeds and calls can be established successfully. The bills generated by MSC Servers 1 and 2 are correct. The circuits are released correctly.
1 Intelligent call
PPS subscriber MS 1 served by MSC Server 1 calls PPS subscriber MS 2 served by the same Server.
PPS subscriber MS 1 served by MSC Server 1 calls PPS subscriber MS 2 served by MSC Server 2.
Handover
z
1 2
Query the states of MGWs 1 and 2 on MSC Server 1. Query the states of MGWs 1 and 2 on MSC Server 3. Query the states of active circuits, such as N7TKC and AIETKC, on MSC Servers 1 and 2 respectively.
The states of MGWs are normal. The query fails and the system prompts that the device is invalid. The states of active circuits are normal. (The active circuits here are those configured for the local Server while the standby circuits are those configured for the standby Server.) The query fails and the system prompts that the circuits are not installed. The states of active links are normal. The query fails and the system prompts that the links are not configured.
3 Management of circuits and links
Query the states of standby circuits on MSC Servers 1 and 2. Query the states of active links, such as MTP3 link and M3UA link, on MSC Servers 1 and 2 respectively. Query the states of standby links on MSC Servers 1 and 2.
5.5 Switch Commissioning

Suppose the services of MSC Server 1 are to be switched over to MSC Server 3.
Table 5-4 Commissioning items for services switch Item 1) Description Set the takeover mode of severNode1 on MSC Server 3 to auto takeover and non-auto backward. Expected result
SET DHWM: WM=ASSIST, SI=1, SM=AUTO, TM=MODE1-1&MODE2-0; 1 2) Set the takeover mode of severNode1 on MSC Server 1 to non-auto takeover and non-auto backward.
SET DHWM: WM=ASSIST, SI=0, SM=AUTO, TM=MODE1-0&MODE2-0, HT=6; 3) Auto takeover 1) Power off MSC Server 1 to make it break down. Set the takeover mode of serverNode2 on MSC Server 3 to auto takeover and non-auto backward.
SET DHWM: WM=ASSIST, SI=2, SM=AUTO, TM=MODE1-1&MODE2-0; 2 2) Set the takeover mode of serverNode2 on MSC Server 2 to non-auto takeover and non-auto backward.
SET DHWM: WM=ASSIST, SI=0, SM=AUTO, TM=MODE1-0&MODE2-0, HT=6; 3) 1) Power off MSC Server 2 to make it break down.
When MSC Server 1 recovers, deactivate serverNode1 on MSC Server 3 manually. The services are switched back successfully.
Manual backward
SET DHWM: WM=ASSIST, SI=1, SM=MANUAL, FS=DEACTIVE; 2) Activate Server node 0 on MSC Server 1:
Item 1)
Description Deactivate Server node 0 on MSC Server 1 manually:
Expected result
SET DHWM: WM=ASSIST, SI=0, SM=MANUAL, FS=DEACTIVE; 2) Activate Server node 1 on MSC Server 3 manually:
Switch the services of MSC Server 1 to MSC Server 3 through manual switch successfully.
Manual switch
SET DHWM: WM=ASSIST, SI=1, SM=MANUAL, FS=ACTIVE; 1) Deactivate Server node 0 on MSC Server 2 manually: Switch the services of MSC Server 2 to MSC Server 3 through manual switch successfully.
SET DHWM: WM=ASSIST, SI=0, SM=MANUAL, FS=DEACTIVE; 2) Activate Server node 2 on MSC Server 3 manually:
SET DHWM: WM=ASSIST, SI=2, SM=MANUAL, FS=ACTIVE; 1) Set the takeover mode of srverNode1 and serverNode2 on MSC Server 3 to auto takeover and non-auto backward. Power off MSC Server 1 to make it break down. Later power off MSC Server 2 to make it breaks down.
1 Abnormality commissioning 2) 3)
MSC Server 3 takes over the services of MSC Server 1. When MSC Server 2 becomes faulty, MSC Server 3 does not take over the services of MSC Server 2.
MSC Server 3 becomes faulty when it has already taken over the services of MSC Server 1.
MSC Server 3 does not switch the services to MSC Server 1.
HUAWEI
Part 4 Appendix
Table of Contents
Table of Contents
Appendix A Acronyms and Abbreviations .................................................................................A-1
Appendix A Acronyms and Abbreviations

B BAM BICC BSC BSS Back Administration Module Bearer Independent Call Control Base Station Controller Base Station Subsystem
C CDR Call Detail Record
F FE Fast Ethernet
H HLR Home Location Register
I iGWB IP ISUP iGateway Bill Internet Protocol ISDN User Part
L LIG Lawful Interception Gateway
M M3UA Mc MAP MGW MML MSC MSC Server MSS MTP3 User Adapter Media Control Mobile Application Part Media Gateway Man-Machine Language Mobile Switching Center Mobile Switching Center Server MSC Server
Huawei Technologies Proprietary A-1
Dual-Homing User Manual HUAWEI MSOFTX3000 Mobile SoftSwitch Center MTP MTP3b Message Transfer Part
Message transfer part (broadband)
R RNC Radio Network Controller
S SCCP SCTP SG STP Signaling Connection and Control Part Stream Control Transmission Protocol Signaling Gateway Signaling Transfer Point
T TCP Transmission Control Protocol
U UDP User Datagram Protocol
V VLR Visitor Location Register
X XPTU X Protocol Transfer Unit
Huawei Technologies Proprietary A-2
Index
Index
Numerics
1+1 assistant scheme basic flow of data configuration, 3-1 capacity planning, 2-1 commissioning, 4-1 commissioning item, 5-1 configuration step, 3-2 data planning, 2-4 dual-homing backward, 4-4 dual-homing switch, 4-2 Mc interface networking, 1-1 narrowband signaling networking, 1-4 planning method, 2-1 SIGTRAN signaling networking, 1-9 trunk networking, 1-12 virtual Server networking, 1-1 standby MSC Server, 1-1
N
N+1 backup scheme basic flow of data configuration, 3-1 capacity planning, 2-1 commissioning, 4-1 commissioning item, 5-1 configuration step, 3-2 data planning, 2-5 dual-homing backward, 4-4 dual-homing switch, 4-2 Mc interface networking, 1-1 narrowband signaling networking, 1-5 planning method, 2-1 SIGTRAN signaling networking, 1-12 trunk networking, 1-15 virtual Server networking, 1-1 networking mode, 1-3
D
derivation of the virtual Server, 1-12 dual activation, 2-4 dual homing, 1-1 dual-homing switch impact, 1-10 switch mode, 1-8 triggering condition, 1-9
S
service takeover, 1-8 switch mode, 1-3 switch notification, 1-8
T
takeover mode, 1-3
H
heartbeat, 1-8
V
virtual Server, 1-2 status of virtual Server, 1-2 type of the virtual Server, 1-2
I
implementation principle, 1-5
M
MSC Server active MSC Server, 1-1
W
work mode, 1-3
Huawei Technologies Proprietary i-1

Homing User Manual PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Homing User Manual PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Part 1 Overview

Part 2 1+1 Assistant Dual-Homing Networking

Part 3 N+1 Backup Dual-Homing Networking

HUAWEI MSOFTX3000 Mobile SoftSwitch Center Dual-Homing User Manual V100R003

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Mobile SoftSwitch Center Dual-Homing User Manual

Huawei Technologies Co., Ltd.

Huawei Technologies Proprietary

Copyright 2006 Huawei Technologies Co., Ltd.

All Rights Reserved

, HUAWEI, C&C08, EAST8000, HONET,

, ViewPoint, INtess, ETS, DMC,

Huawei Technologies Proprietary

About This Manual

Huawei Technologies Proprietary

Huawei Technologies Proprietary

II. GUI conventions

III. Keyboard operation

IV. Mouse operation

Huawei Technologies Proprietary

Dual-Homing User Manual HUAWEI MSOFTX3000 Mobile SoftSwitch Center

Part 2 1+1 Assistant Dual-Homing Networking

Dual-Homing User Manual HUAWEI MSOFTX3000 Mobile SoftSwitch Center

Part 3 N+1 Backup Dual-Homing Networking

Dual-Homing User Manual HUAWEI MSOFTX3000 Mobile SoftSwitch Center

Huawei Technologies Proprietary iii

Dual-Homing User Manual HUAWEI MSOFTX3000 Mobile SoftSwitch Center

Huawei Technologies Proprietary iv

HUAWEI MSOFTX3000 Mobile SoftSwitch Center Dual-Homing User Manual

Dual-Homing User Manual HUAWEI MSOFTX3000 Mobile SoftSwitch Center

Huawei Technologies Proprietary i

Dual-Homing User Manual HUAWEI MSOFTX3000 Mobile SoftSwitch Center

III. Active MSC Server

IV. Standby MSC Server

Huawei Technologies Proprietary 1-1

Dual-Homing User Manual HUAWEI MSOFTX3000 Mobile SoftSwitch Center

Figure 1-1 Schematic illustration of virtual Server

VI. Status of Virtual Server

VII. Types of Virtual Server

Moreover, the non-local virtual Server node is classified as follows:

Huawei Technologies Proprietary 1-2

Dual-Homing User Manual HUAWEI MSOFTX3000 Mobile SoftSwitch Center

VIII. Work Mode of MSC Server

In the assistant mode, there are two switch modes as follows:

Figure 1-2 Status conversion of virtual Server

IX. DH Networking Mode

Huawei Technologies Proprietary 1-3

Dual-Homing User Manual HUAWEI MSOFTX3000 Mobile SoftSwitch Center

1.2.2 Application of DH + Multi-Area Networking

Huawei Technologies Proprietary 1-4

Dual-Homing User Manual HUAWEI MSOFTX3000 Mobile SoftSwitch Center

Active control channel

Standby control channel

1.3 Implementation Principle of DH

MGW 3 Local network 2

MGW 4 Local network 3

Active control channel

Standby control channel

Figure 1-4 N+1 backup scheme (N=2)

Huawei Technologies Proprietary 1-5

Dual-Homing User Manual HUAWEI MSOFTX3000 Mobile SoftSwitch Center

MTP3/ M2UA MGW2

Huawei Technologies Proprietary 1-6