HP Opencall Ss7 Platform Operations Guide: For Release 3.2 On Hp-Ux Pa-Risc

HP OpenCall SS7 Platform
Operations Guide
For Release 3.2 on HP-UX PA-RISC
Second Edition
Manufacturing Part Number : 5990-7337

E1004
Notice
The information contained in this document is subject to change without
notice.
Hewlett-Packard makes no warranty of any kind with regard to this
material, including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose. Hewlett-Packard
shall not be liable for any errors contained herein, or for incidental or
consequential damages in connection with the furnishing, performance
or use of this material.
© 2003-2004 Copyright Hewlett-Packard Development Company, L.P.
Reproduction, adaptation or translation without prior written
permission is prohibited, except as allowed under the copyright laws.
Printing History
First Edition For Release 3.2, June 2003
Second Edition For Release 3.2 on HP-UX PA-RISC, October 2004
Trademarks
Java and all Java-based marks are trademarks or registered trademarks
of Sun Microsystems, Inc. in the United States and other countries.
This product includes software developed by the Apache Software
Foundation (http://www.apache.org/).
The following are trademarks or registered trademarks of
Hewlett-Packard:
HP-UX
MC/ServiceGuard
Hewlett-Packard Company
OpenCall Business Unit
38053 GRENOBLE Cedex 9
France
ii
Contents
1. Preparing for HP OpenCall SS7
Important Safety Precautions for Hardware Installation . . . . . . . . . . . . . . . . . . . . . . . 18
Physical Safety Precautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Anti-Static Precautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Saving Your Platform Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
User Access for Software Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Configuring Restricted SAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authorizing Access for Other Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
HP OpenCall SS7 Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Operating System Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Determinism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
LAN Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Management Applications Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Disk-buffered I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Unix Administration Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Battery Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Date, Time and Synchronizing Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Web-based Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2. Installing the HP OpenCall SS7 Platform

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
HP OpenCall SS7 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Additional Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Hardware Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Installation Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Installation Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Installation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Stage 1 - Saving the Current Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Stage 2 - Installing HP-UX and Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Stage 3 - Removing HP OpenCall SS7 Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Stage 4 - Installing the HP-UX Patches on HP Servers . . . . . . . . . . . . . . . . . . . . . . . 47
iii
Contents
Stage 5 - Setting and Checking Kernel Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Stage 6 - Setting and Checking HP-UX System Files . . . . . . . . . . . . . . . . . . . . . . . . 52
Stage 7 - Installing the HP OpenCall SS7 Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Stage 8 - Starting Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Stage 9 - Creating a New Platform Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Stage 10 - Migrating the Platform Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Stage 11 - Starting the Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Stage 12 - Validating the Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3. Configuring and Starting the Platform

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Configuration States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Configuring the Platform Using SAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Creating a New Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Modifying a Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Backing Up the Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Rolling Back Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Configuring the Platform Using Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Configuring the SSH Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Creating an SSH Key Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Changing Login Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
The Pass-Phrase ssh-agent Management Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 86
Validating the SSH Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Configuring Relocatable IP Addresses (PINS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Description of PINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
HA Functionality of PINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Requirements for PINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
PINS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Deactivating the PINS Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Monitoring and Operating PINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Starting and Stopping HP OpenCall SS7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Configuring Automatic Start-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Starting the Platform Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Starting an M3UA-Based Platform Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Stopping HP OpenCall SS7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Validating the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
iv
Contents
Checking from an HP-UX Viewpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Checking from an HP OpenCall SS7 Viewpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4. Configuring the Signaling Network

Configuring the Network (MTP and SCCP) for an MTP-Based Platform . . . . . . . . . 101
SS7 Monitor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Information for 2-Host Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Configuring MTP and SCCP Network Connectivity. . . . . . . . . . . . . . . . . . . . . . . . . 103
Guidelines for SS7 Network Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Configuring the Network (M3UA, MTP and SCCP) for an M3UA-Based Platform. . 111
Configuring MTP, M3UA and SCCP Network Connectivity . . . . . . . . . . . . . . . . . . 111
Guidelines for Network Configuration on an M3UA-Based Platform . . . . . . . . . . . 113
Guidelines for XML Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Updating the M3UA Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Migrating MTP-Based SCCP to M3UA-Based SCCP . . . . . . . . . . . . . . . . . . . . . . . . 161
Saving the Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Checkpointing from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Checkpointing an MTP-Based Configuration using SS7 Monitor . . . . . . . . . . . . . 162
Loading your Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Creating Different Network Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Validating Signaling Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Validating MTP2 and MTP3 Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Validating IP Connectivity for M3UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Connecting an Application at MTP3/M3UA Level . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Configuring ISUP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Configuring ISUP Applications Offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Configuring ISUP Applications Online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
5. Validating the Platform

Validating High Availability (HA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Checking the Stack Process States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Performing a Switchover and a Switchback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Checking that the LANs Are OK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Validating SNMP Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Checking That SNMP Traps Have Been Configured . . . . . . . . . . . . . . . . . . . . . . . . 176
Checking That SNMP Traps Are Active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
6. Managing and Monitoring the Platform
v
Contents
Managing and Monitoring an MTP-Based Platform . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Starting and Stopping the Platform Management Tools . . . . . . . . . . . . . . . . . . . . . 180
Validating the Platform Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Monitoring HP OpenCall SS7 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Changing the State of Stack Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Monitoring the SS7 Network on an MTP-Based Platform using the SS7 Monitor. 183
Managing and Monitoring an M3UA-Based Platform . . . . . . . . . . . . . . . . . . . . . . . . . 188
Managing and Monitoring Platform Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Managing the Network Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Adding a New IP System Address for M3UA Traffic . . . . . . . . . . . . . . . . . . . . . . . . 189
Monitoring the SS7 and M3UA Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Managing and Monitoring for All Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Monitoring the Platform using the Web-based Monitor . . . . . . . . . . . . . . . . . . . . . . 191
Viewing Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Working with SNMP Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Stopping a Stack on a 2-Host Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
7. Upgrading the Platform License

Adding New Feature Codewords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Migrating from a Non-Commercial to a Commercial License . . . . . . . . . . . . . . . . . . 198
Displaying Licensing Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
8. Using the SS7 Guardian Kit

High Availability for User Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
SS7Guardian Kit, HP OpenCall SS7 and User Application High Availability . . . . 202
Configuring the Platform and SS7Guardian Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
MC/ServiceGuard/SS7Guardian Kit Cluster Configuration File. . . . . . . . . . . . . . . 207
Customer Application Package Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . 211
Package Control Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Working with HP OpenCall SS7 Platforms running the SS7Guardian Kit . . . . . . . . 218
Starting the HP OpenCall SS7 Platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Managing Conflicts in Failure Detection: Principles . . . . . . . . . . . . . . . . . . . . . . . . 219
Failure Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Expected Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
9. Configuring the PIC/AG
vi
Contents
Configuration Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Global Name for Plug-In Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Naming Convention for Plug-In Server Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Overview of Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Configuration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Configuring PIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
PIC Internal Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
HA Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Pre-Defined Plug-Ins (AG_x) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Configuring Entries in /etc/services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Any Plug-In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Plug-In Using the Active/Standby Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Plug-In Implementing PCA Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Configuring the User Plug-In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Including the Plug-In Processes in the HP OpenCall Environment . . . . . . . . . . . . . . 233
The PIC Run String . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Declaring the PIC Process as HA or Not . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
10. Installing a New TSU

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Stage 1: Installing Cards in the TSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Stage 2: Installing the Telecom Signaling Unit in the Server Rack . . . . . . . . . . . . . . 240
Stage 3: Connecting the TSU to the Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Connection Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Cabling for 2-Host Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Stage 4: Checking and Configuring the Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Checking the Hardware Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Configuring the Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
11. Maintaining Signaling Hardware

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Replacing, Moving or Adding a Hardware Component in an MTP-Based Platform . 252
Replacing, Moving or Adding a Hardware Component in an M3UA-Based Platform 254
Replacing a Fan in a TSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Replacing a TSU AC Power Supply (J3401-60100) . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Replacing a TSU DC Power Supply (J3401-60200) . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Replacing the TSU Backplane and CPU Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
vii
Contents
Installing an Additional LAN Card in a TSU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Replacing a LAN Card in a TSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Installing an Additional TSC in a TSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Replacing a TSC in a TSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Removing a TSC from a TSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Replacing a TSU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Removing a TSU from a Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Installing a TSC in a Host Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Replacing a TSC in a Host Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Removing a TSC from a Host Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Replacing a Four-Port TSC Cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Common TSU/TSC Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Removing the TSU from the Server Cabinet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Removing and Replacing the TSU Cover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Removing and Replacing the Card Cage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Adding a Card to a TSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Removing a Card from a TSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Checking LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
12. Configuring TSU/TSC Hardware

Diverting Traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Restoring the Traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
TSU Configuration: Adding a New TSU to an Existing Platform. . . . . . . . . . . . . . . . 318
TSU Configuration: Replacing a TSU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
TSU Configuration: Removing a TSU from a Platform . . . . . . . . . . . . . . . . . . . . . . . . 322
TSU Configuration: Replacing the Backplane and CPU Card of a TSU . . . . . . . . . . 324
TSC Configuration: Installing an Additional TSC in a TSU . . . . . . . . . . . . . . . . . . . . 325
TSC Configuration: Replacing a TSC in a TSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
TSC Configuration: Removing a TSC from a TSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
TSC Configuration: Installing a TSC in a Host Server . . . . . . . . . . . . . . . . . . . . . . . . 332
TSC Configuration: Replacing a TSC in a Host Server . . . . . . . . . . . . . . . . . . . . . . . . 335
TSC Configuration: Removing a TSC from a Host Server. . . . . . . . . . . . . . . . . . . . . . 336
LAN Configuration: Installing an Additional LAN Card in a TSU . . . . . . . . . . . . . . 338
LAN Configuration: Replacing a LAN Card in a TSU . . . . . . . . . . . . . . . . . . . . . . . . . 339
Adding and Activating Links on the SS7 Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Configuring TSC Chained Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
viii
Contents
Configuring HP OpenCall SS7 Hardware Manually . . . . . . . . . . . . . . . . . . . . . . . . . . 344
13. Updating TSCs and SS7 Links

Adding Link(s) to a TSC Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Removing Links from a TSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Upgrading TSCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Checking the TSC is Active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Getting the Serial Number and Number of Links . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Performing the Upgrade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Labeling Your Upgrade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
14. Expanding Platform Processing Capability

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Expanding TCAP Processing Offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Expanding TCAP Processing Online. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Using SAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
From the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
A. Tools Catalog
Graphical Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Platform Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
SS7 Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
SAM: HP OpenCall Platform Configuration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Web-based Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Command Line Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
B. Telecom Signaling Cards (J3527A/J3527B and J3528A)

Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Types of Telecom Signaling Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Physical Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
V.35 Telecom Signaling Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
E1/T1 Telecom Signaling Card. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
TSC Connectors and Cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
E1 Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
T1 Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
V.35 Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Loopback Hoods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
ix
Contents
Connection Panels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
TSC Electrical and Environmental Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Chained TSCs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
C. Telecom Signaling Units (J3401A)

Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Physical Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
TSU Electrical and Environmental Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
x
Preface
This guide deals with all operational aspects of the HP OpenCall SS7
platform and signaling hardware, from how to install the software and
hardware to configuration, monitoring and maintenance.
About This Guide

This guide accompanies HP OpenCall SS7 Release 3.2.
Purpose
The guide is intended for operators concerned with the installation,
configuration, monitoring and maintenance of an HP OpenCall SS7
platform and SS7 signaling hardware. Refer to this guide for help with:
• installing the software

• configuring the platform
• configuring the SS7 network
• starting and stopping the platform
• validating the platform
• monitoring, managing and maintaining the platform
• upgrading the platform license
• installing and maintaining signaling hardware
• configuring the platform’s hardware and software
• expanding the platform capacity.
xi
Contents and Structure
The contents and structure of this guide are as follows:
Chapter Contents
Chapter 1, “Preparing for Details the hardware and software pre-requisites

HP OpenCall SS7.” that must be in place before the procedures in this
guide can be used. Also describes the operating
conditions of the platform.
Chapter 2, “Installing the Describes how to install HP OpenCall SS7 3.2 to

HP OpenCall SS7 Platform.” obtain a platform with the default settings.
Chapter 3, “Configuring and Describes how to create or modify a platform

Starting the Platform.” configuration, and how to start and stop the
platform.
Chapter 4, “Configuring the Describes how to configure the signaling network

Signaling Network.” from the platform.
Chapter 5, “Validating the Provides procedures for validating the High

Platform.” Availability of the platform and the operation of
SNMP traps.
Chapter 6, “Managing and Provides a number of procedures concerned with

Monitoring the Platform.” monitoring, managing and maintaining the
platform.
Chapter 7, “Upgrading the Describes how to upgrade your HP OpenCall SS7

Platform License.” platform license.
Chapter 8, “Using the SS7 Describes how to use the SS7 Guardian Kit with
Guardian Kit.” HP OpenCall SS7.
Chapter 9, “Configuring the Describes how to configure the PIC/AG (Plug-In

PIC/AG.” Container/Application Guardian).
Chapter 10, “Installing a New Provides procedures for installing a new Telecom
TSU.” Signaling Unit (TSU) and its associated Telecom
Signaling Cards (TSCs).
Chapter 11, “Maintaining Describes the maintenance procedures for TSUs,

Signaling Hardware.” in-system TSCs and signaling LAN cards, including
common procedures that are referenced from other
procedures in this guide.
xii
Chapter Contents
Chapter 12, “Configuring Describes how to configure TSUs, TSCs and LAN
TSU/TSC Hardware.” cards.
Chapter 13, “Updating TSCs and Details how to update the SS7 link capacity of the
SS7 Links.” platform.
Chapter 14, “Expanding Platform Describes how you can expand the processing
Processing Capability.” capability of your platform without changing the
hardware.
Appendix A, “Tools Catalog.” Contains a tools reference that lists and describes
the tools that are available with HP OpenCall SS7.
Appendix B, “Telecom Signaling Contains a detailed description of Telecom Signaling

Cards (J3527A/J3527B and Cards (TSCs).
J3528A).”
Appendix C, Telecom Signaling Contains a detailed description of the Telecom

Units (J3401A), Signaling Unit (TSU) which can be used to the
accommodate TSCs.
xiii
Associated Documentation
The following guides are on the HP OpenCall SS7 3.2 CD-ROM:
Table 1 Guides on the HP OpenCall SS7 3.2 CD-ROM
Title Contents
HP OpenCall SS7 Application Describes the HP OpenCall SS7 APIs. In

Developer’s Guide particular, it describes how to design and develop
user applications to run on ISUP.
HP OpenCall SS7 Conformance and Outlines platform conformance and compliance to

Compliance Statements telecommunications network protocols.
HP OpenCall SS7 Glossary Defines terms used in the documentation set.
HP OpenCall SS7 Migration Guide For a 2-host platform, this guide contains
procedures for migrating from previous versions of
HP OpenCall SS7, with minimum platform
downtime.
For a 1-host platform, you should use the software
installation procedure described in the
HP OpenCall SS7 Operations Guide. In this case,
traffic processing is interrupted during the
migration.
For both 1-host and 2-host platforms, this guide
also describes how to upgrade the
HP OpenCall SS7 hardware from SIUs to TSUs.
HP OpenCall SS7 Operations Guide Describes how to install and configure the
platform and SS7 network, how to start, stop and
monitor the platform, and how to use the platform
management tools. The guide also includes SS7
hardware (TSC and TSU) installation and
maintenance procedures, as well as platform
expansion procedures.
The guide contains information on the SS7
Monitor, configuration files and the SNMP traps
generated by the platform.
HP OpenCall SS7 Troubleshooting Describes how to troubleshoot an

Guide HP OpenCall SS7 platform.
xiv
Table 1 Guides on the HP OpenCall SS7 3.2 CD-ROM (Continued)
Title Contents
HP OpenCall SS7 TSU and TSC Describes the safety regulations and conformance
Starter Sheet to international standards for TSUs and TSCs.
HP OpenCall SS7 Welcome Guide Describes the main features of the platform.
The following guides are available but are not on the HP OpenCall SS7
3.2 CD-ROM:
Table 2 Other Documents
Title Contents
HP OpenCall SS7 Release Notes This document contains release-specific

information. In particular, it gives details of the
HP OpenCall SS7 packages, the servers
supported, the HP-UX versions supported and the
associated patches (if any).
HP OpenCall SS7 Software This is the booklet that accompanies the

Installation QuickStart Guide HP OpenCall SS7 3.2 CD-ROM. It describes
where to find installation information, and gives
an overview of the HP OpenCall SS7
documentation.
Features Supported in This Release

For information on the features, options, and parameters supported in
this release, see the HP OpenCall SS7 Release Notes.
xv
We Welcome Your Comments
Your feedback on these manuals is very important to us.
You can contact us by e-mail at the following address:
opencall_docs@hp.com
You can also mail your comments to:
Hewlett-Packard Company,
OpenCall Business Unit,
38053 GRENOBLE Cedex 9,
France
xvi
1 Preparing for HP OpenCall SS7
This chapter firstly describes important precautions you should take

when installing HP OpenCall SS7 hardware. It then describes the
HP OpenCall SS7 user access followed by the configuration
pre-requisites and the platform’s operating conditions.
Chapter 1 17
Preparing for HP OpenCall SS7
Important Safety Precautions for Hardware Installation
Important Safety Precautions for Hardware

Installation
It is important that you read this section before attempting any of the
hardware installation and maintenance procedures in this guide.
Physical Safety Precautions

The following instructions are important for your safety and for the
functioning of the HP OpenCall SS7 platform. Read the instructions
carefully before attempting the installation.
WARNING Ensure that the hardware you are working with (signaling
hardware or host server) is disconnected from the power supply
during installation until you are told to connect to a power
source.
To avoid personal injury and damage to the product, power to the unit
must remain switched off during installation until it is necessary to
switch the power on. This means that the unit’s power cable and network
cables must remain disconnected until you are instructed to make the
connections. Follow the instructions in the procedures carefully.
This equipment is disconnected from the power supply by removing the
power cord from the power outlet. It is therefore important to locate the
unit close to a power outlet that is easily accessible.
For your safety, never remove the cover of a TSU or server while the unit
is connected to a power source or to a telecommunication network.
Always replace the cover before switching on the power to the unit. The
terms POWER OFF and POWER ON are used to instruct you when to
switch the power off and on respectively.
WARNING When told to connect a hardware unit to a power supply, for your
safety you must always connect it to a grounded wall outlet.
18 Chapter 1
Always use the power cord supplied with the TSU or one with a properly
grounded plug (a DC powered TSU must only be used with the HP
J3401-60201 power cord). If a power cord is not supplied, select the
proper power cord according to your local national electric code. Ensure
that the cable meets your country's standards for safety. For example:
• USA - use a UL listed type SVT detachable power cord.

• Canada - use a CSA certified detachable power cord.
Anti-Static Precautions
The HP OpenCall SS7 platform contains electrical components which
can be damaged by static electricity. To avoid damage:
CAUTION Use an anti-static mat and wear a grounding wrist strap

attached to the chassis of the server cabinet when removing and
inserting components.
• The server cabinet must be independently grounded so that when

you remove the power cable any static charge passes to ground.
The mat and strap are available in the HP 9300-1155 Workstation
Kit. All components must be placed on an anti-static mat if you have
taken them out of their anti-static bag.
• Avoid carpeting and clothing that produce static charges (wool,
nylon, silk) and avoid unnecessary movements.
• Do not touch components on the cards. Handle the cards only by
their edges, face plates or extractor levers. When inserting or
removing printed cards, do not touch any other components.
Saving Your Platform Configuration
CAUTION Before carrying out any of the HP OpenCall SS7 hardware procedures
described in this guide, save your current configuration using the
ss7CheckPoint tool. For more information, see “Saving the Network
Configuration” on page 162.
Chapter 1 19
Save your new configuration using the ss7CheckPoint tool after

completing the installation. Finally, perform a Save As of the running
configuration in SAM.
20 Chapter 1
User Access for Software Configuration

To configure a platform, you must log in as a privileged user. The table
below summarizes the different possibilities:
Table 1-1 Access Permissions
User Access Level Configuration Required
root Full access to whole None.

platform, including
HP OpenCall SS7.
ocadmin Default privileged user for Configure SAM to allow user to access HP
HP OpenCall SS7. OC Platform Configuration. See
“Configuring Restricted SAM” on page 22.
other user root can grant privileged Configure SAM to allow user to access only
access to HP OpenCall SS7 HP OC Platform Configuration. See
to other members of the “Configuring Restricted SAM” on page 22.
ocadmin group
Add default environment variables to users
.profile. See “Authorizing Access for
Other Users” on page 22.
Configure user’s .rhosts file. There are
several references in the procedures to
creating or modifying the file
~ocadmin/.rhosts.
For other users, the file
~<other_user_name>/.rhosts should be
created or modified instead. Other users
must belong to the group ocadmin.
At package installation, the following are created:
• the user ocadmin

• the group ocadmin
• the directory /home/ocadmin
These must not be removed.
Chapter 1 21
The appropriate environment variables are also added to both ocadmin

and root’s .profile (and to .dtprofile, if it exists).
The HP OpenCall SS7 files and directories are handled by SAM when
configuring the platform. The root user must not create or modify any
files or directories belonging to the HP OpenCall SS7 file system layout,
except when using SAM or the supported command line tools.
NOTE To be manageable using SAM, all files in the HP OpenCall SS7

configuration directories, and the directories, must be owned by a
member of the group ocadmin.
Most platform commands can be used by the ocadmin user, however,

some require root access. Refer to Appendix A, Tools Catalog.
Configuring Restricted SAM

If you want the user ocadmin to be able to use a restricted version of
SAM, giving access only to HP OC Platform Configuration, configure this
using the Restricted SAM Builder (started using sam -r). Set the group
ocadmin’s privileges to Enable for HP OC Platform Configuration and to
Disable for all other tools.
You must also carry out the above configuration for any other users that
you want to have access to platform configuration using SAM.
Authorizing Access for Other Users

If you want users other than root and ocadmin to have access to the
platform tools or man pages, you must add the default environment
variables to each user’s .profile file:
PATH=$PATH:/opt/OC/bin
MANPATH=$MANPATH:/opt/OC/share/man
This is done automatically for the ocadmin and root users.
Any users that you want to access the platform, must be members of the
ocadmin group.
22 Chapter 1
HP OpenCall SS7 Operating Conditions

The HP OpenCall SS7 product operates under the conditions and
constraints described below.
Operating System Requirements

Please see the HP OpenCall SS7 Release Notes for detailed information
on the operating systems supported.
Make sure your system is configured for long filenames.
Make sure any UNIX patches listed in the HP OpenCall SS7 Release
Notes are installed.
Determinism
On 2-host high availability platforms, the HP-UX Operating System
must behave in a deterministic manner so that the highly sensitive
fault-detection mechanisms implemented by the Fault Tolerance
Controller are triggered only when real failures occur.
On 1-host platforms, failure detection time-outs can be set to larger
values, and the deterministic operation of the platform is not so critical.
However, for correct operation of the SS7 stack, a certain level of CPU
time must be guaranteed. To ensure this, adhere to the CPU load
constraints described below.
CPU Usage < 85%

The overall CPU usage of the hosts should remain below 85%. Above this
value, non-deterministic behavior of the Operating System may cause
unnecessary switchovers.
The number of application processes should remain as low as possible.
Resources needed to start an application may slow down the platform
and so may provoke a switchover on a 2-host platform.
Chapter 1 23
LAN Environment
OpenCall Dual The two LANs must be configured on separate IP subnets, and they must
LANs be isolated from any external network access using bridges or routers:
Figure 1-1 Isolated LANs
Router
Router
Host_1 Host_2
To prevent unnecessary switchovers, the LANs must be dimensioned so

that peak traffic (< 60% of bandwidth) does not saturate them, as this
would delay the FTC, stack heartbeats and HP OpenCall SS7 data
traffic.
NOTE The LANs must be either Ethernet (100-BaseT) or FDDI.
24 Chapter 1
Bridges or routers between hosts within the platform are not supported:
Figure 1-2 Bridges/Routers between Hosts
Router
Bridge
Host_1 Host_2
Inter Back End There are no such restrictions on the type of LAN used between Back
LANs End hosts.
Management Applications Location

All processes that are not essential to the operation of the hosts should
be located on the platform manager. These are:
• SS7 Monitor
• Platform Monitor
• SAM
Swapping
An operational host must not swap. Main memory must be dimensioned
so that all applications can run using only physical memory.
Disk-buffered I/O
Buffered file I/O cannot be used because it causes the host to stop
occasionally for an undetermined time to flush the buffers to disk.
If an application requires disk-buffered I/O, then it must be run on a
back end (BE), with HP OpenCall SS7 on a front end (FE).
Chapter 1 25
Unix Administration Constraints

The following HP-UX administration constraints apply.
Copying Very Large Files

Avoid copying very large files (larger than tens of MBs) as this slows
down the platform and may provoke a switchover.
Setting Kernel Parameters and Values

In order to run HP OpenCall SS7, you must adjust some HP-UX kernel
parameter values. For information on how to set these values, and what
the values should be, see Chapter 2, Installing the HP OpenCall SS7
Platform.
Battery Backup
Battery backup of the platform is not supported. Architectures must be
configured so that an /etc/shutdown is performed when it is powered
back on.
Date, Time and Synchronizing Clocks
NTP Synchronization
HP OpenCall SS7’s High Availability component is compatible with ntp
synchronization, without any special procedures that need to be followed.
Setting the Date and Time
Front-end Hosts HP OpenCall SS7’s High Availability component

allows you to change the date and time on front-end hosts, with the
following restrictions:
• Perform the “clock-jump” on the standby user-application, not the

active application.
• TCAP, SCCP, and MTP timers set by user-applications and API
timers that are set before the “clock jump”, are not guaranteed to
function. If your application can recognize a “clock jump”, it is
recommended (but not required) that you clear the buffers.
26 Chapter 1
Platform Manager The management processes run on the Platform

Manager, which are not highly available, do not support a “clock jump”.
Web-based Monitor
If you want to take advantage of the web-based monitor delivered with
HP OpenCall SS7, you must ensure that the correct versions of the
following software is installed:
• HP Apache-based Web Server

• Tomcat
• HP JDK
Refer to the HP OpenCall SS7 Release Notes for the correct versions to
use.
Chapter 1 27
28 Chapter 1
2 Installing the HP OpenCall SS7
Platform
The purpose of this chapter is to give you a description of the installation

and first-time configuration of HP OpenCall SS7 3.2.
Chapter 2 29
Installing the HP OpenCall SS7 Platform
Overview
Overview
This chapter describes how to install an HP OpenCall SS7 3.2 platform.
This is an off-line procedure, therefore the platform must be taken out of
service. At the end of the installation, you will have an HP OpenCall SS7
platform with default settings.
The stages in the software installation procedure cover the installation of
an HP OpenCall SS7 platform in two different situations:
• Installing onto a clean server where no version of HP OpenCall SS7

was installed before.
• Installing onto a server that has previously run the
HP OpenCall SS7 2.x or 3.1 version.
Depending on which situation you are in, you will need to skip some of
the steps. Follow the flowcharts for guidelines.
If you are carrying out the installation on a platform that has previously
been running an earlier version of HP OpenCall SS7, you must
completely remove the previous version. If you were previously running
HP OpenCall SS7 2.x or 3.1, follow the relevant steps described in this
chapter to keep a copy of your old configuration, then migrate it to the
HP OpenCall SS7 3.2 format.
For on-line migration procedures, see the HP OpenCall SS7 Migration
Guide.
The following sections in this chapter give you the prerequisites before
you can start the installation.
NOTE The installation of the operating system is not covered in detail in this
chapter. For more information, see the HP-UX Installation manuals.
30 Chapter 2
Security
Security
When performing any of the configuration or installation operations
described in this chapter, log in as root.
Once the product has been installed and configured, you can also work as
user ocadmin or any other member of the group ocadmin. If you want to
be able to use the System Administration Manager (SAM) as a member
of ocadmin, configure restricted SAM. For more information, see
“Configuring Restricted SAM” on page 22.
Chapter 2 31
Prerequisites
Prerequisites
Prerequisites prior to the installation of HP OpenCall SS7 3.2 are the
following:
Skills
To perform the installation you need good knowledge of the following
areas:
• HP-UX: During the configuration of the HP OpenCall SS7 platform

some HP-UX system files are affected and several commands are
used for configuration and customization.
• HP OpenCall SS7 administration.
Documents
During the installation of HP OpenCall SS7 you should have the
following documents:
• HP-UX Installation Manuals

• HP-UX Release Notes
• HP OpenCall SS7 3.2 Documentation Set
• HP OpenCall SS7 3.2 Release Notes
• HP OpenCall SS7 3.2 license codeword
Hardware
Hardware installation must be complete before starting any of the
software installation procedures. If your hardware has not been
pre-installed by HP, refer to “Hardware Installation” on page 36.
The minimum dedicated memory required for HP OpenCall SS7 (in
addition to the memory for HP-UX and other applications) is as follows:
• 256 MB for a single Local Point Code (LPC) MTP-based platform

• 512 MB for a single LPC M3UA-based platform
• 256 MB for each additional LPC on a MTP-based platform.
32 Chapter 2
Prerequisites
• 64 MB for each Platform Manager (PM)

The virtual memory (VM) required by LPC depends on the number of
Destination Point Codes (DPCs) configured on the network:
• 24 MB for 50 DPCs:
— 50 DPCs, 100 routes

— 50 DPCs (Remote SP), 100 Sub-System Numbers (SSNs)
— 500 Global Title (GT) entries

— 200 DPCs (Remote SP), 400 SSNs
— 2048 GT entries

— 512 DPCs (Remote SP), 1024 SSNs
— 2048 GT entries
— 1024 DPC, 4096 routes

— 1024 DPC (Remote SP), 4096 SSNs
— 4096 GT entries
The requirements for ISUP are as follows:
• 100 MB for 1024 DPCs:
— 1024 DPC, 100,000 circuits configured
Chapter 2 33
Prerequisites
Operating System
See the HP OpenCall SS7 Release Notes for information about:
• The operating systems supported

• The appropriate HP-UX extension pack(s)
• The appropriate Support Plus release
• The required HP-UX patches
• The supported servers and available hardware
HP OpenCall SS7 Software

To install the software, you need the following CD-ROM:
• HP OpenCall SS7 Software for HP OpenCall SS7 3.2
Additional Software
The additional software is available on the HP-UX CD-ROMs. See the
HP OpenCall SS7 Release Notes for the correct versions to use.
NOTE The prerequisite software must be installed before you attempt to install
the web-based monitoring component.
• If you want to take advantage of the web-based monitor delivered

with HP OpenCall SS7, you must ensure that the following software
is installed:
— HP-UX Developer's Kit for Java™ (JDK)

— HP Apache-based Web Server
— A supported web-browser
• M3UA only: In order for HP OpenCall SS7 to run correctly, you must
install:
— HP-UX Developer's Kit for Java™ (JDK)
34 Chapter 2
Prerequisites
NOTE Tomcat servlet is used for web-based monitoring.
By default, Tomcat uses Java 1.2 [JAVA_HOME=/opt/java1.2] in

/etc/rc.config.d/tomcat. Java 1.2 is the minimum recommended for
web-based monitoring on an MTP-based platform.
If you want to use web-based monitoring on an M3UA-based platform,

you must update /etc/rc.config.d/tomcat with the path to Java 1.3
[JAVA_HOME=/opt/java1.3].
Chapter 2 35
Hardware Installation
Hardware Installation
Before starting the HP OpenCall SS7 software installation described in
this chapter, your platform hardware must be already installed and
connected up. If the hardware has not been pre-installed by HP, you
must perform this installation yourself.
SS7 hardware installation (TSUs and TSCs) is described in this guide.
The procedures that you must follow depend on the type of hardware, as
follows:
• If you wish to use TSU/TSC hardware, refer to Stages 1, 2 and 3 in

Chapter 10, “Installing a New TSU,” on page 235.
• If you have a TSC-in-System platform, refer to “Installing a TSC in a
Host Server” on page 291.
In either case, do not configure the SS7 hardware or connect it to the SS7
network, as you will do this as part of the software installation procedure
in this chapter.
36 Chapter 2
Installation Recommendations
Installation Recommendations
After the installation of each product or patch, do the following:
Step 1. Check that the product or patch is correctly installed and configured.
Execute the swlist -l fileset -a state command. Its output should
show all filesets as CONFIGURED; otherwise, the product concerned has
not been installed correctly.
Step 2. Use the dmesg command to print recently generated diagnostics

messages (these are retrieved from a system buffer).
Step 3. Use the cat /var/adm/syslog/syslog.log command to display the

system log file. Check that no system problems were logged during
installation. If this log contains a file system full message (issued
during installation), it probably means that some temporary files were
not created and that the product has not been installed correctly.
Step 4. Use the bdf command to check the disk space. If this command reports a
file system full, it probably means that some files of the product have
probably not been installed correctly.
Chapter 2 37
Installation Flowchart
The flowcharts below show the stages required to install
HP OpenCall SS7 on an HP server.
Figure 2-1 outlines the stages required to install HP OpenCall SS7 on a
clean server.
38 Chapter 2
Figure 2-2 on page 40 gives the stages required to install

HP OpenCall SS7 on a server previously running an earlier version of
HP OpenCall SS7.
Figure 2-1 Installing HP OpenCall SS7 on a Clean Server
Chapter 2 39
Figure 2-2 Installing HP OpenCall SS7 on a Server Running an Earlier

Version of HP OpenCall SS7
40 Chapter 2
CAUTION See the HP OpenCall SS7 Release Notes to check that all features of
HP OpenCall SS7 2.x or 3.1 you want to use are supported by
HP OpenCall SS7 3.2.
Chapter 2 41
Installation Procedure
Follow this procedure to install the software on your platform. You will
not need to use all the stages. Use the “Installation Flowchart” on
page 38 and following pages for guidelines.
Stage 1 - Saving the Current Configuration

This stage explains how to save a copy of the current configuration to a
place where it will not be affected by the upgrade procedure. It can be a
tape or the root directory (/) if no operating system upgrade is performed.
CAUTION The configuration must not be changed after you have performed this
stage.
Actions
Step 1. Save the existing network configuration using the command

ss7CheckPoint.
Step 2. Save the running configuration using the SAM utility. Note the
configuration identifier number <n>.
Step 3. Copy the directory containing the saved configuration to a safe place
using the following command:
cp -pR ${WORKING_CONFIG_DIR}/platform_<n> <safe_place>/
NOTE The new directory must not be under any HP-AIN directory.
Step 4. Save the network configuration file using the following command:
cp -pR /etc/opt/HP-AIN/config/SS7_<standard>/Saved.
<className>.conf.ref <safe place>/
Step 5. Check that the cp commands were successful.
42 Chapter 2
Result
Configuration is now saved to a safe place.
Rollback
None.
Chapter 2 43
Stage 2 - Installing HP-UX and Applications

This stage explains how to install HP-UX on your system. This
corresponds to the standard HP-UX installation procedure.
Actions
Step 1. Power up the platform.
Step 2. Install HP-UX. For more information, see HP-UX Installation Guides.
Step 3. Configure the Logical Volumes according to the information in Table 2-1,
“Logical Volumes for an HP OpenCall SS7 Platform,” below.
Table 2-1 Logical Volumes for an HP OpenCall SS7 Platform
Logical Mount
Minimum Size (MB)
Volumes Directory
lvol1 /stand 100 MB for general use
lvol2 Primary SWAP If the amount of physical memory is less than 2 GB, set
the size of the SWAP to twice the size of the physical
memory.
If the amount of physical memory is greater than or equal
to 2 GB, set the SWAP size to be equal to that of the
physical memory.
lvol3 / 5 MB dedicated to HP OpenCall SS7, for /etc/opt/OC.
lvol4 /opt 512 MB dedicated to HP OpenCall SS7
lvol5 /usr 5 MB dedicated to HP OpenCall SS7
lvol7 /var 2.5 GB dedicated to HP OpenCall SS7
lvol8 /home 20 MB dedicated to HP OpenCall SS7
Step 4. Use the HP OpenCall SS7 Release Notes to identify the appropriate
software applications for your hardware among the following list:
• MC/ServiceGuard
• MirrorDisk/UX
• C/ANSI Developer’s bundle
44 Chapter 2
• aCC Compiler
• FDDI/9000
• HSC FDDI/9000
• 100BT/9000 EISA
• 100BT/9000 GSC Series 800
• Java SDK
Install the software applications.
Result
HP-UX and applications are installed on your system.
Rollback
None.
Chapter 2 45
Stage 3 - Removing HP OpenCall SS7 Software

This stage explains how to remove the HP OpenCall SS7 software, if
necessary.
Actions
Step 1. Remove all SS7 packages using the command swremove.
Step 2. When swremove has finished, remove the relevant HP OpenCall SS7
directories.
If your previous software installation was HP OpenCall SS7 3.1 or

earlier, delete the following HP-AIN directories using the commands:
• rm -Rf /opt/HP-AIN/
• rm -Rf /etc/opt/HP-AIN/
• rm -Rf /var/opt/HP-AIN/
• rm -Rf /var/tmp/HP-AIN/
If your previous software installation was HP OpenCall SS7 3.2, delete

the following OC directories using the commands:
• rm -Rf /opt/OC/
• rm -Rf /etc/opt/OC/
• rm -Rf /var/opt/OC/
• rm -Rf /var/tmp/OC/
Result
HP OpenCall SS7 software has now been removed.
Rollback
Reinstall and reconfigure the platform with the earlier version of
HP OpenCall SS7.
46 Chapter 2
Stage 4 - Installing the HP-UX Patches on HP Servers

This stage explains how to install the appropriate HP-UX bundles and
patches on the host.
Actions
Step 1. Power up the signaling units and the platform, if necessary.
Step 2. Select the appropriate HP-UX patches in the HP OpenCall SS7 Release
Notes.
Download the HP-UX patches you need from the following web site:
http://itrc.hp.com/
Step 3. Install the patch(es) using the swinstall utility. The host reboots after
installation.
Step 4. Check the log file /var/adm/sw/swagent.log. Any errors listed should
be consistent with your hardware and software configuration.
Result
The HP-UX patches are installed on the host.
Rollback
Uninstall the HP-UX patches using the command swremove.
Chapter 2 47
Stage 5 - Setting and Checking Kernel Parameters

This stage explains how to set and check kernel parameters.
Actions
Step 1. Note the relevant existing kernel parameters
Step 2. To run HP OpenCall SS7 3.2, you must increase the values of some
kernel parameters.
As a minimum, you must add the incremental values shown in Table 2-2
below, to your system’s current values.
NOTE Kernel parameter formulas longer than 60 characters are not supported.
If the formula exceeds 60 characters, work out the value of the result and
enter the result manually instead of using the formula.
Table 2-2 Kernel Values for HP OpenCall SS7 3.2
Parameter Value Description
nfile Add 2048 to the existing formula Max Number of open files.
ninode Add 1024 to the existing formula Max Number of open Inodes.
nproc Add 224 to the existing formula Max number of processes.
semmni Add 13 to the existing formula Number of semaphore identifiers.

Ensure that semmni is less than
or equal to semmap.
semmns Must be less than or equal to Number of semaphores in the system.

semmni x semmsl
Note that for HP-UX 11.0, semmsl has a
value of 500 and is not configurable.
semmnu Add 170 to the existing formula Number of semaphore undo structures.
48 Chapter 2
Table 2-2 Kernel Values for HP OpenCall SS7 3.2 (Continued)
Parameter Value Description
semmap If semmap is calculated via a Size of the control map.

formula that includes semmni
(for example, semmap = semmni +
2), you just set the value of
semmni as described above.
If semmap is an absolute value,
add 13 to the existing value to
get the value needed for
HP OpenCall SS7.
shmmax Add 27 MB to the existing Maximum shared-memory segment size.

formula
maxfiles If this value is less than 140, set Soft File Limit per process.
it to 140
maxdsiz For ISUP: System default or at For normal levels of ISUP

least 400 MB configurations, use your system default
value for maxdsiz. Increase the value to
at least 400 MB if you plan to run big
ISUP configurations (for example, 1024
DPC, 100K circuits).
For TCAP: System default or at For normal levels of TCAP transactions,

least 256 MB use your system default value for
maxdsiz. Increase the value to at least
256 MB if you plan to run large numbers
of TCAP transactions (up to 100 000
open transactions simultaneously).
NOTE Increasing semmnu significantly does not have much impact on memory
consumption, as the related structures are very small.
Modify the value of these parameters using SAM|Kernel

Configuration|Configurable Parameters. For more information, see HP
Managing Systems and Workgroups (Part Number: B2355-90676).
Chapter 2 49
Step 3. The purpose of this step is to ensure that the buffer cache size does not
exceed 50 MB.
Determining the buffer cache size depends on the size of the physical
memory.
• If the physical memory is less than or equal to 2500 MB, go to step 4.
• If the physical memory is greater than 2500 MB, go to step 5.
Step 4. To determine the buffer cache dynamically for a physical

memory of 2500MB or less, modify the values of dbc_min_pct in the
kernel parameters using the SAM utility. To determine the values of
dbc_min_pct and dbc_max_pct, use the following equation:
dbc_min_pct = dbc_max_pct = (50 MB / total RAM size) * 100
where:
dbc_min_pct and dbc_max_pct are percentages of the total RAM size.
Table 2-3 below gives some examples of typical kernel values. The NBUF
and BUFPAGES parameters must be set to the default value (0).
Table 2-3 Typical Kernel Values
dbc_min_pct (%) and

Minimum RAM (MB)
dbc_max_pct (%)
2500 2
1667 3
1250 4
1000 5
833 6
500 10
250 20
128 39
50 Chapter 2
Step 5. To determine the buffer cache dynamically for a physical

memory of more than 2500MB, modify the value of the BUFPAGES
kernel parameter. To determine the value of BUFPAGES, use the following
equation:
BUFPAGES = 50 MB / PAGESIZE
Find out PAGESIZE (the buffer page size) using the command
getconf PAGESIZE
Set the BUFPAGES kernel parameter for physical memory size greater
than 2500 MB using the SAM utility. The parameter BUFPAGES sets the
number of buffer pages. The default value is 0.
Example:
If the size of one buffer page is 4096 B and you set BUFPAGES to 12500,
then your buffer cache will be approximately 50 MB.
Step 6. Once you have finished setting the kernel parameter values, note the
kernel parameter changes and then process the new values. The kernel
is rebuilt and the system reboots.
Result
Appropriate kernel parameters are now set.
Rollback
Restore the original values for the kernel parameters.
Chapter 2 51
Stage 6 - Setting and Checking HP-UX System Files

This stage explains how to set and check the HP-UX system files.
During this stage, an example LAN configuration is used. The example is
illustrated in the graphic below, and shows two Front-End host called
alpha and beta, a Back-End host called delta, and a Platform Manager
called pi.
52 Chapter 2
Figure 2-3 LAN Configuration in HP-UX System Files
Management LAN
lan0 lan0
15.128.12.14 15.128.12.13
Platform Manager pi Back End delta
lan1 lan2
192.10.1.13 192.10.2.13
lan0 lan0
15.128.12.11 15.128.12.12
lan1 Switch1 lan1
192.10.1.11 192.10.1.12
Host alpha HP OpenCall Host beta
lan2 Dual LANs lan2
192.10.2.11
Switch2 192.10.2.12
lan3 lan4 lan3 lan4

193.11.20.11 193.11.21.11 193.11.20.12 193.11.21.12
M3UA Signaling LANs M3UA Signaling LANs
CAUTION Hubs do not allow you to use 100BT Full-Duplex but only 100BT
Half-Duplex. Because of the impact on the performance of the platform,
you are strongly recommended to use switches and not hubs.
Chapter 2 53
Actions
Step 1. Plan your LAN configuration taking the following points into
consideration:
• HP OpenCall SS7 dual LANs must be on separate subnets, and the

two LANs must be physically isolated.
• If you have several signaling LAN interfaces, you must configure

each signaling LAN on a different subnet.
• TSU LANs must NOT be configured with IP addresses.
Step 2. Back up any system files before you edit them. The files are the
following:
• /etc/hosts
• /etc/rc.config.d/netconf
• /etc/resolv.conf
• /etc/nsswitch.conf
Step 3. Edit the /etc/hosts file to ensure it includes the management LAN IP
addresses you are using for each host in the platform.
The hostname you enter must match the output of the HP-UX command
hostname. Fully qualified domain names are not supported for the
hostname.
54 Chapter 2
The following local loopback line must always be present.

127.0.0.1 localhost loopback
For example:
127.0.0.1 localhost loopback
15.128.12.11 alpha
15.128.12.12 beta
15.128.12.13 delta
15.128.12.14 pi
Step 4. Modify the /etc/rc.config.d/netconf file so that it contains the

correct LAN configuration for all LANs, except TSU LANs.
The examples below show you how to configure LAN information for
single and dual-LANs on host alpha.
Management LAN - # For management LAN.

Configure for All INTERFACE_NAME[0]=”lan0”
Platforms IP_ADDRESS[0]=”15.128.12.11”
SUBNET_MASK[0]=””
BROADCAST_ADDRESS[0]=””
INTERFACE_STATE[0]=””
DHCP_ENABLE[0]=0
HP OpenCall Dual # Configuration of first HP OpenCall dual LAN

LANs - Configure INTERFACE_NAME[1]=”lan1”
for 2-host IP_ADDRESS[1]=”192.10.1.11”
Platforms Only SUBNET_MASK[1]=””
DHCP_ENABLE[1]=0
# Configuration of second HP OpenCall dual LAN

INTERFACE_NAME[2]=”lan2”
IP_ADDRESS[2]=”192.10.2.11”
DHCP_ENABLE[2]=0
Chapter 2 55
Signaling LANs - # For signaling LANs used in an M3UA onfiguration.

Configure for # TSU lans are not configured in this file.
M3UA-Based INTERFACE_NAME[3]=”lan3”
Platforms Only IP_ADDRESS[3]=”193.11.20.11”
DHCP_ENABLE[3]=0
INTERFACE_NAME[4]=”lan4”
IP_ADDRESS[4]=”193.11.21.11”
DHCP_ENABLE[4]=0
Step 5. Modify the same file /etc/rc.config.d/netconf so that it includes the

IP routing for each LAN configured.
The examples below show you how to configure LAN information for a
single-LAN 1-host platform and a dual-LAN 2-host platform.
NOTE Before you proceed, check that /etc/hosts is the same on all hosts in
the platform.
Management LAN - # In this example, the management network default gateway

Configure Routing # of 15.128.11.254 has been used. Modify this to include
for All Platforms # your own management network default gateway address.
#
ROUTE_DESTINATION[0]=”default”
ROUTE_MASK[0]=””
ROUTE_GATEWAY[0]=”15.128.11.254”
ROUTE_COUNT[0]=”0”
ROUTE_ARGS[0]=””
56 Chapter 2
HP OpenCall Dual ROUTE_DESTINATION[1]=”192.10.1.11”

LAN - Configure ROUTE_MASK[1]=””
Routing for 2-host ROUTE_GATEWAY[1]=”localhost”
Platforms Only ROUTE_COUNT[1]=”0”
ROUTE_DESTINATION[2]=”192.10.2.11”
ROUTE_GATEWAY[2]=”localhost”
Signaling LAN - # If necessary, set the correct default gateway for M3UA
Configure Routing # signaling LANs.
for M3UA-Based ROUTE_DESTINATION[3]=”193.11.20.11”
Platforms Only ROUTE_MASK[3]=””
ROUTE_GATEWAY[3]=”<IP address of your signaling network
gateway>”
ROUTE_DESTINATION[4]=”193.11.21.11”
ROUTE_GATEWAY[4]=”<IP address of your signaling network
gateway>”
Step 6. If you are using DNS, ensure that the file /etc/nsswitch.conf
contains the following lines:
hosts: files [NOTFOUND=continue] dns

services: files
NOTE NIS is not supported.
Chapter 2 57
Step 7. Configure the HP OpenCall dual LANs and M3UA LANs with
parameters appropriate for how they are connected. You can configure
the LANs either by using SAM (recommended) or by editing the LAN
configuration file manually.
• In SAM, for each HP OpenCall dual LAN and M3UA LAN, go to

Networking and Communications | Network Interface Cards. Select
a LAN, then do Actions | Modify.
— For direct connections, set:
AUTO_NEG to OFF.
Speed to 100.
Duplex Mode to FULL.
— For connections via a switch, set: AUTO_NEG to ON.
• If you are unable to use SAM, in the file

/etc/rc.config.d/hpbtlanconf, manually change the parameter
HP_BTLAN_SPEED[n]:
— For direct connections, set: HP_BTLAN_SPEED[n] to 100FD.
— For connections via a switch, set: HP_BTLAN_SPEED[n] to

AUTO_ON.
You may also have to edit another file depending on your LAN card
type.
• Ensure that the equipment to which the LANs are connected (switch,
router, and so on) have auto-negotiation set to ON.
Step 8. Run the command below to take the changes into account.
/sbin/init.d/net stop; /sbin/init.d/net start
Step 9. Test all LAN connections using ping.
Result
HP-UX system files are configured.
Rollback
Replace the HP-UX system files that you have changed with those from
your back-up.
58 Chapter 2
Stage 7 - Installing the HP OpenCall SS7 Bundle

This stage explains how to install the HP OpenCall SS7 bundle on the
host.
Actions
Step 1. Start the swinstall tool on the host. Type:
/usr/sbin/swinstall&
Step 2. Select the source location (the CD-ROM) from the Specify Source
window.
Step 3. Select the appropriate bundle for the system you are installing. Table 2-4
below will help you to choose.
When you choose a bundle, all the filesets you need are selected
automatically. For more information about the default settings for each
bundle, see the HP OpenCall SS7 Release Notes.
Table 2-4 Bundles Installation
System Type Functionality Bundles
Front End Operational platform connected to the OCSS7_FE

signaling network.
Front End with Front End with no HW in a testing OCSS7_FEnoHW

No Hardware environment. Testing is enabled by the use of
(HW) a software loopback.
Back End Operational platform running user OCSS7_BE

applications in a Back End/Front End
topology.
Platform Manager Centralized platform management. OCSS7_PM
Developer Development environment for writing and OCSS7_DEV

compiling applications.
Development environment that also enables OCSS7_FE

hardware loopback tests to be run.
Development environment that also enables OCSS7_FEnoHW

software loopback tests to be run.
Chapter 2 59
Step 4. Start the installation.
Step 5. Check there are no errors in the /var/adm/sw/swagent.log file.
Result
HP OpenCall SS7 bundle is installed.
Rollback
You need to remove the HP OpenCall SS7 bundles.
Step 1. Uninstall the HP OpenCall SS7 bundle using the swremove utility.
Step 2. Remove the directories from the host using the following commands:
• rm -Rf /etc/opt/OC/
• rm -Rf /var/tmp/OC/
• rm -Rf /var/opt/OC/
• rm -Rf /opt/OC/
60 Chapter 2
Stage 8 - Starting Logging

It is important to validate the logging after the installation. This means
checking that logging is active.
Actions
Step 1. To check that logging is running, type:
/etc/nettl -status
If logging is running, the nettl output is displayed. The following is an

example of this output:
Logging Information:
Log Filename: /var/adm/nettl.LOG0x
User’s ID: 0 Buffer Size: 8192
Messages Dropped: 0 Messages Queued: 0
Subsystem Name: Log Class:
NS_LS_LOGGING ERROR DISASTER
NS_LS_NFT ERROR DISASTER
...
If logging is not running, you get a message telling you so and showing
you how to start logging. The following is an example of this message:
The tracing and logging facility has not yet been started. To
start the facility, execute the following command:
/usr/sbin/nettl -start
...............
Step 2. If necessary, start logging by typing:
startnettl
Step 3. To open a log viewing window, type:
wlog
Result
Logging is running.
Rollback
None.
Chapter 2 61
Stage 9 - Creating a New Platform Configuration

This stage explains how to configure the HP OpenCall SS7 3.2 platform.
Alternatively, if you have saved an existing HP OpenCall SS7 2.x or 3.1
configuration using “Stage 1 - Saving the Current Configuration”, follow
the instructions in “Stage 10 - Migrating the Platform Configuration” on
page 66.
NOTE Before you can start using the IP addresses in the static platform
configuration, local IP set-up must be done for the local host.
If you have not configured any local IP interface(s) for the M3UA traffic,
then before starting Stage 9, perform the procedure described in “Adding
a New IP System Address for M3UA Traffic” on page 189.
NOTE The best method for configuring the platform is using SAM. It is also
possible to use batch commands. For more information on the use of
batch commands, see “Configuring the Platform Using Scripts” on
page 81.
Actions
Step 1. Check your SS7 hardware (if any), as follows:
• For a system including TSU hardware, check that the cabling is

valid, and ensure the TSUs are powered on. For more information on
cabling recommendations, see “Cabling for 2-Host Platforms” on
page 245.
Check the LEDs on the TSU(s) and TSCs; refer to “Checking LEDs”
on page 309.
Check that the TSU(s) and TSCs are reachable by running
ss7TsuPing -v
Do this either as root or as ocadmin.
• For a TSC-in-system platform, check the LEDs on the TSCs; refer to

“Checking LEDs” on page 309.
62 Chapter 2
Check that the TSCs are reachable by running
ss7TscPing -v
Step 2. Create the ~ocadmin/.rhosts file and declare each host in the platform.
This allows a host to remote copy files to the other hosts.
Use the following syntax:
[hostname] ocadmin [#comment]
[hostname] ocadmin [#comment]
NOTE The checkpointing mechanism works only if the ~ocadmin/.rhosts file

has been created and modified as above.
Example alpha ocadmin #for SS7 host alpha
beta ocadmin #for SS7 host beta
pi ocadmin #for platform manager pi
Ensure that the ~ocadmin/.rhosts file has the following access and owner
rights:
-rw-rw---- 1 ocadmin ocadmin
Step 3. Modify the ~ocadmin/.profile file to include Java in the search path.
The exact pathname will depend on your configuration, but will be

something like:
# Set up the search paths
PATH=$PATH:/usr/sbin:/opt/java1.3/bin:.
Step 4. Start SAM.
On the host or the Platform Manager, type /usr/sbin/sam&
Chapter 2 63
NOTE On a 2-host platform, always use SAM from the same host, for example,
from the Platform Manager.
Step 5. If your platform has more than one computer, use the SAM HP OpenCall
LAN configuration tool to associate host IP address pairs. To run the
tool, select Networking and Communications|Hosts then double-click
the HP OC LAN Configuration icon.
Step 6. In SAM, double-click the HP OpenCall SS7 Platform Configuration icon.
Step 7. Create a new configuration. For more information on using SAM, see the
SAM Online Help.
Use Actions|Create in the Menu and set the values to suit your
configuration.
Enter your licence codewords, when prompted.
Enable the SNMP traps, if you want to use them.
Step 8. Configure the hardware for SS7. Select Actions|View Modify in the
Configuration Menu and click on Signaling Hardware.
If the hardware has never been configured and your system includes
TSU or TSC hardware, you must first create an initial hardware
configuration. Click on Create Initial Configuration. Then, complete the
hardware configuration steps for the TSC, and the links.
Step 9. Configure the Signaling Protocols.
If you are configuring an M3UA-based platform, configure the signaling

IP addresses using Actions|View/Modify|Signaling Protocols.
Step 10. Customize the configuration for optional features like the TCAP
Application Message Dispatcher. In SAM select Actions|View Modify in
the Configuration Menu.
Step 11. Install the configuration. Select Actions|Install in the Menu.
Step 12. If your platform has more than one host, you must propagate the
configuration to the other hosts. Select Actions|Propagate in the Menu.
Step 13. Connect the TSC cables to the SS7 network (if relevant).
64 Chapter 2
Result
The platform is configured.
Rollback
Step 1. Disconnect the TSC cables at the network end (if relevant).
Step 2. Copy back the previous configuration directory using the SAM utility
a. Type /usr/sbin/sam&
b. Double-click on the HP OpenCall SS7 Platform configuration icon.
c. Select the previous configuration.
d. Install the configuration. Select Actions|Install in the Menu.
Step 3. Restore the back-up of ~ocadmin/.rhosts.
Chapter 2 65
Stage 10 - Migrating the Platform Configuration

This stage explains how to migrate an existing HP OpenCall SS7 2.x or
3.1 platform configuration. It assumes you have saved your configuration
following the instructions in “Stage 1 - Saving the Current
Configuration”.
Actions
Step 1. Decide whether you want to run your HP OpenCall SS7 3.2
configuration in Active/Standby or Parallel Engine mode.
Step 2. Recover the configuration you saved in “Stage 3 - Removing

HP OpenCall SS7 Software” using the cfgMigrate command.
If you are migrating from HP OpenCall SS7 version 2.x, use the
command:
cfgMigrate -from <safe place> -HA_Mode <mode>
where <mode> can be one of ParallelEngine or ActiveStandy.
If an HP OpenCall SS7 3.2 license file already exists on the platform, no

warning is displayed. If no license file exists, a message will prompt you
to use SAM or the command ocLicense to enter your license
codeword(s).
If you are migrating from a commercial version of HP OpenCall SS7

version 3.1, use the command:
cfgMigrate -from <safe place> -HA_Mode <mode>
If you are migrating from a non-commercial version of HP OpenCall SS7

version 3.1, use the command:
cfgMigrate -from <safe place> -HA_Mode <mode> -nc
If an HP OpenCall SS7 3.2 license file already exists on the platform, the
previous HP OpenCall SS7 3.1 license will not be migrated. However, if
no HP OpenCall SS7 3.2 license exists, the HP OpenCall SS7 3.1 license
will be migrated.
Refer to the cfgMigrate man page for further details.
The migrated configuration becomes the running configuration by

default. For more information, see the cfgMigrate man page.
66 Chapter 2
Note that the license keyword you enter must cover all the functionality
previously available on the HP OpenCall SS7 2.x or 3.1 platform.
Result
The previous configuration is now the running configuration.
Rollback
None.
Chapter 2 67
Stage 11 - Starting the Platform

This stage explains how to start the platform.
Actions
Step 1. You can start the platform manually or automatically.
NOTE Automatic and manual start-ups are mutually exclusive. Before

proceeding, you must decide which one you want to use.
a. To start the platform manually:

Start the first Front End host by typing: ss7Start
b. To configure an automatic start-up:
• Uncomment the ss7Start command (shown below) at the end of

the /etc/inittab file. If necessary, edit the command to show
the correct location of your Java installation.
hpoc:23456:respawn:/sbin/sh -c "export
PATH=$PATH:/opt/java1.3/bin;\
/opt/OC/bin/ss7Start -foreground > \
/var/opt/OC/logs/ss7Start.log 2>&1"
• Run the command /etc/init q, so that the file is re-read and the
changes are taken into account.
68 Chapter 2
Step 2. Configure the signaling network. Choose the sub-steps below that apply
to your signaling network.
a. Configure the signaling network on an MTP-based platform using the

SS7 Monitor.
1. Start the HP OpenCall SS7 Management tools by typing

ss7MgrStart.
The SS7 Monitor will display a “No LPC Configured” message.
2. Configure the LPCs, links/linksets, DPCs, and so on using the
SS7 Monitor.
3. Ensure that all hosts are powered up.
4. Perform a checkpoint of your configuration using the SS7
Monitor.
5. If MTP is not ACTIVE, activate it using the SS7 Monitor.
Select Monitor entities.
Select MTP. You should see the MTP state: ACTIVE or
INACTIVE.
Activate MTP. The MTP state changes to ACTIVE.
The platform is now connected to the SS7 network.
b. Configure the signaling network on an M3UA-based platform.
1. Configure the signaling network using the network configuration

XML file. Refer to “Guidelines for Network Configuration on an
M3UA-Based Platform” on page 113.
2. Load the network configuration XML file using the command
loadconf.
3. Activate your local end point using the command m3uaCtrl.
4. Use the command ocNetworkStatus to check the local endpoint
instances are up.
5. Checkpoint the M3UA configuration using ss7CheckPoint.
Chapter 2 69
Step 3. If you have a 2-host platform, start the second host by typing ss7Start.
The second host starts and synchronizes with the first.
Result
HP OpenCall SS7 is running on the platform.
Rollback
Stop the platform.
70 Chapter 2
Stage 12 - Validating the Platform

This stage explains how to perform an initial platform validation.
Actions for an MTP-Based Platform
Step 1. Ensure the HP OpenCall SS7 platform is already configured with the
hardware (TSU or TSC-In-System).
Step 2. Ensure the SS7 links are already connected to the Adjacent Point Code.
Step 3. Test the LAN connections on the host(s) and the Platform Manager by
pinging each machine’s IP address.
Step 4. Check that MTP links are ACTIVE as described in “Validating MTP2
and MTP3 Connectivity” on page 166. You should see ACTIVE state for
MTP.
NOTE If not connected to the SS7 network, perform the loopback tests.
Step 5. If you have a 2-host platform, perform a graceful stop on one host from
the Platform Monitor.
Check that MTP remains active on the other host.
Step 6. Start the stack that has just been stopped.
NOTE Configuring the HP OpenCall SS7 platform is the first step towards
having an operational SS7 network. For more information on configuring
and managing the SS7 network, see Chapter 4, “Configuring the
Signaling Network.”
Chapter 2 71
Actions for an M3UA-Based Platform

Validate IP Connectivity for M3UA using the following procedure.
Step 1. Ensure that connection to the IP signaling network is valid by

performing the following checks.
a. Ping the remote server IP addresses from each end point to make
sure they are accessible.
b. Use the standard HP-UX tools ifconfig and lanscan to validate the
IP configuration.
c. Use the command netstat -rn to verify the routes configured from
both end points.
Step 2. Ensure the local end point instances are up. Do this using the command:
ocNetworkStatus -C <classname> -layer M3UA -states
Result
The platform is now operational.
The user root has access to all functionality. The user ocadmin has
access to all SS7 functionality except SAM. If you want ocadmin to be able
to use the SAM utility, see “User Access for Software Configuration” on
page 21.
Rollback
None.
72 Chapter 2
3 Configuring and Starting the
Platform
This chapter describes how to configure a platform for the first time and
how to modify an existing configuration. These are off-line procedures.
Chapter 3 73
Configuring and Starting the Platform
Overview
Overview
Configuring the HP OpenCall SS7 platform consists of the following
steps:
• Creating a new configuration.

• Modifying the new configuration to use the correct values for your
system.
• Installing the configuration: this moves the new or updated
configuration from the saved state to the running state. Note that
when the configuration is updated for a running system, the modified
configuration files will not be used until the platform has been
stopped and restarted.
• Propagating the configuration: this copies the new or modified
configuration onto all systems in the platform, ensuring consistency.
All of these tasks can be done either using SAM (the default) or by
running scripts from the command line (if a batch mode configuration is
required).
Offline modifications are done on a stack that has not been installed and
started. Such modifications are done using the Actions | View/Modify
option in SAM.
74 Chapter 3
Overview
Online modifications can be made to the running stack when it has been
started. These modifications are directly available in the SAM Actions
menu, for example TCAP Dynamic Tuning, and are immediately
implemented. The modifications remain even when the stack is stopped
and restarted.
Off-line Configuration On-line Off-line Configuration
Modify
Modify off-line
Running
Create Configuration
Install
Saved
Configuration Modify on-line
Host A
Propagate
Host B
Running
Configuration
NOTE If you have used Action | View/Modify in SAM to update a running

configuration on a platform that has already been started, you will need
to stop and restart the platform in order to take the modifications into
account.
Configuration States
A configuration can be in one of two states:
• saved: located in /var/opt/OC/working_config

• running: located in /etc/opt/OC
Chapter 3 75
Overview
The table below summarizes what happens to the configuration files in

different situations:
Table 3-1 Configuration File States
Task Action Result
Create or modify a license Modify license License is created or

upgraded.
Actions | License
Create new configuration Create configuration Configuration is in saved

state.
Actions | Create
Modify an existing saved Modify configuration Modified configuration still

configuration in saved state.
Actions | View/Modify
Install configuration Existing running

configuration (if any) moved
Actions | Install
to saved state—directory
named so as not to overwrite
any other saved
configurations.
New configuration moved to
running state.
Patch configuration Patched configuration still

in saved state.
Actions | Patch
Remove configuration Configuration is deleted.

Actions | Remove
Save As configuration The configuration is backed

up as a new saved
Actions | Save As
configuration.
76 Chapter 3
Overview
Table 3-1 Configuration File States (Continued)
Task Action Result
Modify Online Modify configuration Modified configuration is in

running (Static) running state.
Actions | View/Modify
configuration configuration
Patch configuration Patched configuration still
in saved state.
Actions | Patch
Save As configuration Running configuration

copied to saved
Actions | Save As
state—directory named so
as not to overwrite any
other saved configurations.
Note:
If you do not explicitly save
your modified configuration,
no backup copy of it exists.
Propagate configuration Running configuration

copied to all other systems
Actions | Propagate
in platform.
Check configuration Configuration is validated.

Actions | Check
Offline Modify TCAP levels After using SAM, you need

(Dynamic) to run ss7TcapTune to take
Actions | Tcap Dynamic
configuration the modification into
Tuning
account.
Modify ISUP After using SAM, you need

to run ss7IsupReload to
Actions | ISUP Dynamic
take the modification into
Config
account.
Chapter 3 77
Configuring the Platform Using SAM

This section summarizes the procedures for configuring the
HP OpenCall SS7 platform using SAM: HP OC Platform Configuration.
For detailed information on individual parameters, refer to the SAM
on-line help.
Creating a New Configuration

This procedure is intended as a general guide. For precise details on the
meaning and usage of the different parameters, see the SAM on-line
help.
Back up your existing configuration before making any changes to your
platform.
CAUTION Always create, modify, backup and propagate configurations from the
same host (Platform Manager or Front End) when using SAM.
Step 1. Start SAM by typing /usr/sbin/sam&, and choose HP OC Platform

Configuration. Remember you must be logged in as a user with
appropriate access privileges. See “User Access for Software
Configuration” on page 21. Start SAM from the Platform Manager, if
there is one.
Step 2. Choose Actions|Create to create a brand new configuration. You must

enter your license keyword.
Step 3. Fill in the appropriate configuration for your system. If you are
configuring a development platform, choose NOHW (no hardware) as
your hardware type. If you have an SDK license, the hardware button is
greyed out.
NOTE You can modify the hostname and the SNMP setting later. However, you
cannot modify the other information in this first screen later.
78 Chapter 3
Step 4. Click OK. This creates your new configuration in the saved state using
the default values for the configuration options you chose.
Step 5. Follow the steps in “Modifying a Configuration”, below, to complete your

new configuration.
Modifying a Configuration
Step 1. Highlight the configuration you want to modify, then choose
Actions|View/Modify and make the appropriate changes to the default
configuration for your system. Note the following:
• Choose Hardware|Create Initial Configuration to carry out an

autodiscovery of your hardware. However, note that this overwrites
any previous hardware configuration information for this
configuration—manual changes you have made in the ss7.hw file are
overwritten. Work through the remaining hardware screens in order.
• Carry out the remaining configuration in any order. Refer to the

on-line help for parameter details.
• When configuring ISUP, if you have only one ISUP application and
you do not intend to use Dynamic Configuration, set the Application
Identifier to 0. Otherwise, you will need to update your current
application code.
Step 2. Choose Actions|Install to move your new configuration to the running

state.
Note that when updating the configuration for a running system, the
modified configuration files that have been put in the ‘running state’ will
not be used until the platform has been stopped and restarted (see
below).
Step 3. Choose Actions|Propagate to copy the new running configuration to all

systems on the platform.
If your platform is not currently running, you can now start the platform.
If you have made modifications to a running platform, you must now stop
and restart your platform for the modifications to take effect. See
“Starting and Stopping HP OpenCall SS7” on page 93. Before doing so,
you may want to optimize the TCAP performance level. In this case, see
“Expanding TCAP Processing Offline” on page 361.
Chapter 3 79
Backing Up the Platform

Before making any changes to your configuration, make a backup:
Step 1. Start SAM by typing /usr/sbin/sam&
Step 2. Double-click the “HP OC SS7 Platform Configuration” icon.
Step 3. Select the configuration you plan to change.
Step 4. Save the configuration (select Actions | Save As)
NOTE Check that your backup has completed successfully by reading the log
file.
Rolling Back Changes

To restore your configuration from a backup:
Step 1. Start SAM by typing /usr/sbin/sam&.
Step 2. Double-click the “HP OC SS7 Platform Configuration” icon.
Step 3. Select the previous operational configuration.
Step 4. Install the configuration (select Actions|Install).
Step 5. Propagate the configuration to all the hosts in the platform. This is to
avoid configuration discrepancies between the hosts.
Step 6. Restart the application.
80 Chapter 3
Configuring the Platform Using Scripts

Configure your platform using the batch scripts only if you need to
perform your installation in batch mode; otherwise, use SAM as
described above.
• cfgCreate
• cfgss7HwCreate
• cfgInstall
• cfgPropagate
• cfgCheck
• cfgModify
For complete syntax descriptions of each command, refer to the man
pages. The files to be configured are in /etc/opt/OC
NOTE Back up your existing configuration before making any changes to your
platform.
Step 1. Configure the license by running the script ocLicense.
Step 2. Create the new configuration: run cfgCreate on the Platform Manager.
Create the configuration directly in /etc/opt/OC. To do this, leave the
[-to<destDir>] field empty.
Step 3. Configure the hardware by running the script cfgss7HwCreate.
Step 4. Make any necessary changes to the system parameters in the sys.*
files.
Step 5. If you want to scale your TCAP performance level, use the command
cfgModify -Tcap to do so.
Step 6. Run cfgInstall to move the new configuration to the running state.
(Not necessary if you created the configuration in /etc/opt/OC/)
Chapter 3 81
Step 7. Run cfgPropagate to propagate the new configuration. Always

propagate configurations from the same host (Platform Manager or
Front End).
Step 8. Run cfgCheck on the Platform Manager.
This ensures that all the necessary files are present and, on a 2-host
system, checks that the configuration on both hosts is consistent.
The platform is now ready for operation.
82 Chapter 3
Configuring the SSH Framework

This section provides information on how to replace rsh and rcp
commands with SSH (Secure Shell) commands.
When configuring a platform and propagating the configuration to the
platform hosts, HP OpenCall uses rsh and rcp commands. To enhance
traffic security, HP OpenCall uses OpenSSH, a free version of the SSH
protocol suite of network connectivity tools.
When using programs such as telnet, rlogin, and ftp, passwords are
transmitted across the Internet unencrypted. To effectively eliminate
eavesdropping, connection hijacking, and other network-level attacks,
OpenSSH encrypts all traffic, including passwords.
For further, up-to-date information on SSH, please refer to the SSH
documentation, the man pages and http://www.openssh.org.
Creating an SSH Key Pair

To build an SSH configuration for a cluster, execute the following
procedure.
NOTE You can create a key pair with or without a pass-phrase. If you are using
a pass-phrase for the key generation, refer to “The Pass-Phrase
ssh-agent Management Procedure” on page 86.
Step 1. Log on as an ocadmin user on each host of the cluster.
Step 2. Perform this step on each host in the cluster.
Create a key pair (instead of using ~/ocadmin/.rhosts and relying on

IP) as follows:
ssh-keygen -t dsa
DSA is recommended, as it is the best encryption algorithm available.
The above command will generate the key pair contained in the files:
/home/ocadmin/.ssh/id_dsa
Chapter 3 83
/home/ocadmin/.ssh/id_dsa.pub
The latter contains the public key, which has the following format:
AAAAB3NzaC1yc2EAAAABIwAAAIEA+nS/jgwbQQyCcubskWpeUt0an4TGqUc0
hNrI4Kx39k9pocadmin@opencall
NOTE This key must be contained in one line only.
Step 3. If you are using a non-null pass-phrase, add your keys to start
ssh-agent by entering:
$ eval $(ssh-agent|tee~/.ssh-agent.sh)
$ ssh-add
Step 4. For each host, including your local host, copy your public key to the host
by entering:
$ scp .ssh/id_dsa.pub ocnodex:~/.ssh/key.pub
$ ssh ocnodex "cat ~/.ssh/key.pub >> ~/.ssh/authorized_keys"
This will allow the local ocadmin account to connect to the remote hosts.
SSH will prompt you to add the remote server in your local file
(/home/ocadmin/.ssh/known_hosts) by asking the following question:
The authenticity of host ‘ocnodex (15.128.128.60)’ can’t be

established. RSA key fingerprint is
59:7a:6a:82:02:45:cd:e8:4c:b5:ae:5e:61:4e:68:00.
Are you sure you want to continue connecting (yes/no)?
Answer ‘yes’ and you will then be prompted to enter your ocadmin
account password.
Step 5. On each host of the cluster, set the correct mode for your
authorized_keys2 file by entering:
$ ssh ocnodex "chmod 600 ~/.ssh/authorized_keys"
84 Chapter 3
NOTE If your umask was already correct, you will not be prompted for the
ocadmin account password.
From now on, when you log onto a remote host, you should no longer be
prompted for a password.
All platform hosts are configured with the same authorized_keys and
known_hosts files. Only the order of the keys listed in these files should
be different.
Changing Login Methods

This section describes how to change login methods between the R-
commands and SSH commands used by the HP OpenCall SS7 software.
To change the login methods, you first need to create a file that contains
the required sequence of remote copies and remote commands on the
cluster.
NOTE If you do not create this file, the platform will use the usual remsh/rcp
tools.
• The file must be under super-user control, as only the super-user is

able to configure or unconfigure the SSH or Remote Shell (remsh)
services.
• The file location is /var/opt/OC/security/
The super-user must own this directory and all higher directories.
• The filename is ocRemoteTools.conf
• The file should belong to the root user and group, and should have
the following permissions:
-r--r-----
• The file must contain a variable to switch between SSH and the
usual remote services.
Chapter 3 85
— For an SSH configuration, the file has the following content:

ocRemoteTools=ssh
— For the usual remsh/rcp configuration, you can either:
use the command ocRemoteTools=arpa or
remove the file ocRemoteTools.conf
This gives the choice of either a remsh or ssh framework, as well
as any other remote command framework that is available.
HP OpenCall SS7 can accept any changes in this part of the
dialog between the host and the cluster, while the remote
commands keep the same method in which to identify the user
and the remote host.
• Validate your setup on all hosts by testing ocremsh/ocrcp
HP OpenCall SS7 wrappers.
For example, on the ocnodex host, enter:
$ ocremsh ocnodex id
This command will return the remote uid on the ocnodex host:
$ ocrcp ocnodex:/etc/passwd /tmp
The Pass-Phrase ssh-agent Management Procedure

The SSH framework could introduce insecure behavior if the
authentication is based only on the possession of key files. The security
changes from “a secret that a person knows” to “a file that a person has”.
It may be necessary to keep the policy as “a secret that a person knows”
in the SSH framework.
To implement this pass-phrase method, you must make changes in the
Front-End of the HP OpenCall SS7 platform.
The following list of security rules must be applied:
1. Before performing any other administrative tasks, you need to start

an ssh-agent and indicate its presence on all hosts of the
HP OpenCall SS7 cluster. This operation must be done using the
following two commands on all hosts of the HP OpenCall SS7 cluster:
$ eval $(ssh-agent | tee ~/.ssh-agent.sh)
$ ssh-add
86 Chapter 3
2. When leaving the HP OpenCall SS7 platform, you must kill the
previously running ssh-agent and remove its configuration file.
To do this, enter the following on all hosts of the cluster:
$ kill -9 $(ps -ef | grep $USER.*ssh-agent | awk ‘{ print
$2 }’)
$ rm ~/.ssh-agent.sh
3. When you log onto a host, you must check that the SSH environment
variables correctly point to the host’s ssh-agent. This check is not
necessary if the profile contains:
if [ -e ~/.ssh-agent.sh ]
then
.~/.ssh-agent.sh > /dev/null
fi
Validating the SSH Configuration

On a Front-End/Back-End platform, you need to be able to use ssh/scp
commands on the hosts without being prompted for a password. All
connections must be checked to make sure that the correct
configurations of keys are set on the cluster hosts and that, if required,
the ssh-agent has been started.
For example, if you have two Front-End hosts (A and B) and one
Back-End server (C), you must check nine connections:
• From A to A
• From A to B
• From A to C
• From B to A
• From B to B
• From B to C
• From C to A
• From C to B
• From C to C
This is the complete set of connections. If the cluster has N hosts, you
must test N*N connections.
Chapter 3 87
Configuring Relocatable IP Addresses (PINS)

This IP network high availability feature is integrated in
HP OpenCall SS7 by means of PINS (Plug-In Network Sensor).
Description of PINS
PINS manages a single “floating” IP address and re-maps the address to
one of the four LAN ports on one of the hosts in a 2-host platform. The
floating IP address is used by remote applications communicating with a
local application. This enables the IP network to view the 2-host
platform as a single IP host. PINS monitors the state of the LAN port
associated with the virtual IP address. If the LAN where the virtual IP
address is mapped fails, PINS re-assigns the IP address to another LAN
port on the same front-end host when available (local LAN switch), or on
the other host after a PINS process switchover (remote LAN switch).
PINS provides high availability for an IP address over any LAN except
M3UA and OpenCall LANs (also referred to as HA LANs). PINS uses
ARP (Address Resolution Protocol) to broadcast an update request (of the
Internet address translation tables) to the network neighborhood.
Whereas a local LAN switch is transparent to remote applications, a
remote LAN switch requires the remote application to reconnect to the
platform and to re-initiate any on-going transactions.
HA Functionality of PINS
PINS is an active/standby process managed by the Fault Tolerance
Controller (FTC). Within the HA mechanism supported by the platform,
the behavior of the PINS process includes:
• Re-assignment of the virtual IP addresses to a PINS configured LAN

port on the host where the PINS is active.
• Respawning of the PINS process by the FTC when the PINS process
has failed.
• Triggering a local or remote LAN switchover upon LAN failure.
• Broadcast of re-ARP requests to the network to overwrite existing
ARP tables on a remote machine that are still referring to the MAC
address of the previous LAN interface used by the PINS process.
88 Chapter 3
Figure 3-1 PINS on an HP OpenCall SS7 Platform

Active Platform Active
Host Manager Host
Active Standby
PINS PINS
Application Application
Private LAN
Floating IP Address
Public LAN Public LAN
INTERNET
Remote
Application
Requirements for PINS

For PINS to function properly, you must take account of the following:
• The LANs controlled by PINS should be plugged on independent

switch hubs to avoid Single Point Of Failures.
Chapter 3 89
• Two LAN interfaces must be available and configured for PINS

usage.
• Neighborhood machines must be able to receive and accept re-ARP
requests. Therefore, network elements (such as switch hubs) that
mask such requests should not be used.
PINS Configuration
You configure PINS as follows:
Step 1. On the Platform Manager, edit the file /etc/opt/OC/PINS/pins.conf

(for the running configuration) by following the template provided in this
file.
In the section [IP_1], add the following parameters:
• Nic = <lanx> [,priox]
where <lanx> is the HP-UX name (lan0, lan1, ...) of LAN access on
which a static IP address has been configured.
This is optionally followed by its priority (value 1 for the highest

priority and 2 for the lowest one).
The Nic parameter MUST be set at least one time, and may be
repeated:
Nic = lanx [,priox]

Nic = lany [,prioy]
• IpAddress = <relocatable IP> <floating Ip netmask>
A relocatable IP address associated to the LAN access, together with

its subnet mask.
• LanSwitch = <value>
where <value> can be:
— 'L' for local LAN switch. (1-host platform only).
— 'LR' for both local and remote LAN switch. (2-host platform only).
— 'R' for only remote LAN switch (2-host platform only).
90 Chapter 3
CAUTION All other parameters and sections are reserved for internal use. Do
not change or remove them.
NOTE For a 2-host platform, the PINS configuration should be installed in

the same way, and at the same time on both hosts, to ensure that the
dual NICs have the same system name. For example, if on one host
the 2 NICs are named lan12 and lan14, the 2 NICs on the second
host must be named lan12 and lan14.
Step 2. To activate the PINS process, add it in the FT platform configuration.
Use the SAM OC Processes Configuration window.
Step 3. Propagate the configuration (use SAM |OC Configurations |actions |

propagate).
Step 4. To activate the PINS process, stop/restart the Front-End platform(s).
Deactivating the PINS Process

In the SAM OC configuration in the FT process screen, remove the PINS
process from the process list and stop/restart the platform.
The PINS feature is still configured and can be re-activated by repeating
Steps 2 to 4 in the above procedure.
Monitoring and Operating PINS
Local Switch
The command:
PINS_localSwitch -h<host> IP_1 <NIC>
requests a local LAN switch to the PINS running on the specified host
(the default is the local host), on the specified LAN access to the specified
NIC. The LAN access and NIC names must be the same as in the
pins.conf file.
Chapter 3 91
Remote Switch
A remote switch can be forced from the Platform Monitor by requesting a

PINS process switch.
PINS HA Status
The floating IP address is available only for the active PINS process as
seen from the Platform Monitor. It can be seen as the alias of a PINS
LAN using the netstat -rn shell command on the host where the active
PINS is located.
The command:
PINS_getState -h<host> IP_1
displays on the standard output the configured NIC states on the
specified host (the default is the local host). The active NIC is marked
with a star ('*').
92 Chapter 3
Starting and Stopping HP OpenCall SS7

You can start the HP OpenCall SS7 software either automatically or
manually. However, do not try to start a system manually if you have
already configured an automatic start, as this results in a second
instance of the FTC trying to start.
NOTE To provide an HA service, you must use an automatic start.
NOTE If you are starting a M3UA and SCCP based stack without a network
configuration, use the procedure “Starting an M3UA-Based Platform
Manually” on page 94.
Configuring Automatic Start-up

Step 1. Uncomment the ss7Start command (shown below) at the end of the
/etc/inittab file. If necessary, edit the command to show the correct
location of your Java installation.
Step 2. As root, run the command init q so that the file is re-read and the
changes are taken into account.
Starting the Platform Manually

You can also run the ss7start command manually from the command
line. Do this either as ocadmin or as root.
Chapter 3 93
Starting an M3UA-Based Platform Manually

When starting a M3UA-based stack (M3UA only, or M3UA with
MTP-as-backup, without a network configuration, start the stack
manually using the following procedure:
Step 1. Start the stack using the command ss7Start.
Step 2. Use the command ocftstatus to determine that the process

<classname>_M3UAx_[1|2] is ACTIVE.
Step 3. Use the command loadconf to load the network configuration.
Step 4. Use the Platform Monitor or ocftstatus to determine the entire stack
has become active.
Step 5. Save the configuration using the command ss7CheckPoint.
NOTE The stack status in the Platform Monitor will be DEGRADED until the
M3UA configuration has been loaded.
NOTE Once the M3UA and SCCP configurations have been loaded and
checkpointed, you can start the M3UA-based stack using ss7Start. The
stack will then automatically load the existing configuration file
Saved.<classname>.conf.ref.xml at startup.
Stopping HP OpenCall SS7

To stop HP OpenCall SS7:
Step 1. If necessary, prevent an automatic restart. This is required for certain

maintenance tasks. See “Preventing Automatic Start-up” on page 95.
Step 2. Run the command ss7Stop -ftc. This stops the FTC and HA processes
(FTC, SS7 Stack and SS7 Waiter) started by the FTC.
94 Chapter 3
NOTE The Platform Management tools stop when you stop HP OpenCall SS7.
SAM remains running.
Preventing Automatic Start-up

To prevent an automatic ss7Start respawn in inittab:
Step 1. Uncomment the ss7Start command (shown below) at the end of the
/etc/inittab file. If necessary, edit the command to show the correct
location of your Java installation.
Step 2. As root, run the command init q to force init to re-read inittab.
Chapter 3 95
Validating the Configuration

This means checking that the platform configuration is valid.
It involves checking the configuration from an HP-UX viewpoint and
from an HP OpenCall SS7 viewpoint.
Checking from an HP-UX Viewpoint

Step 1. Check the following HP-UX configuration files:
• /etc/hosts
• ~ocadmin/.rhosts
• /etc/rc.config.d/netconf
• /etc/resolv.conf
• /etc/inittab
Step 2. Check the kernel parameters.
Checking from an HP OpenCall SS7 Viewpoint

You can do this in one of the following ways:
• Using cfgCheck.
• Using SAM.
• Viewing the log file.
Using cfgCheck
Run the batch script cfgCheck, by typing:
cfgCheck [-config <configuration-directory>]
96 Chapter 3
cfgCheck checks the configuration at two levels:
• Local System
At this level, it checks for consistency within a system.
• Global Platform
At this level, it checks for consistency between all the systems in the
platform.
To display on-line help, type:
cfgCheck -help
Using SAM
Step 1. Use SAM.
See “SAM: HP OpenCall Platform Configuration Tool” on page 372.
Step 2. Select the configuration you want to check.
Step 3. Choose Actions | Check from the pull-down menu.
See also Chapter 3, “Configuring and Starting the Platform,” on page 73.
Viewing the Log
Step 1. Use SAM.
See “SAM: HP OpenCall Platform Configuration Tool” on page 372.
Step 2. Choose Actions|View Log (from the pull-down menu)
Alternatively, you can view the /var/opt/OC/audit/audit.log file.

However, this file only contains information on configuration operations
performed using SAM. Configuration operations performed using the
command are not logged in this file.
Chapter 3 97
98 Chapter 3
4 Configuring the Signaling
Network
This chapter describes how to configure the network. The stack must be
running to carry out the configuration described in this chapter.
Chapter 4 99
Configuring the Signaling Network
Introduction There are two ways of configuring the signaling network on your
platform.
If you are running an MTP-based platform, with MTP only, configure the
signaling network using the SS7 Monitor, as described in “Configuring
the Network (MTP and SCCP) for an MTP-Based Platform” on page 101.
If you are running a M3UA-based platform, with either M3UA only, or
M3UA with MTP-as-backup, then configure the signaling network using
an XML configuration file, as described in “Configuring the Network
(M3UA, MTP and SCCP) for an M3UA-Based Platform” on page 111.
100 Chapter 4
Configuring the Network (MTP and SCCP) for an MTP-Based Platform
Configuring the Network (MTP and SCCP) for

an MTP-Based Platform
Use the information in this section if you are running an MTP-based
platform.
If you are running an M3UA-based platform, with M3UA alone, or with
MTP-as-backup, see “Configuring the Network (M3UA, MTP and SCCP)
for an M3UA-Based Platform” on page 111.
M3UA relies on the SCTP transport layer to access remote M3UA
network elements. Since SCTP is an IP based transport layer, this
implies that some IP configuration (system address creation and IP
routing tables configuration) is needed on the M3UA endpoint.
For more details, refer to the paragraph “Adding a New IP System
Address for M3UA Traffic” on page 189.
The first time you start your SS7 stack, the network configuration file is
empty. Use the SS7 Monitor to create and save your network
configuration. You can also use it to monitor the network.
The SS7 Monitor starts automatically when you start the platform
management tools using ss7MgrStart.
SS7 Monitor can run in two modes:
• Administrator—allowing both configuration and monitoring

• Operator—allowing monitoring only
The procedures described in this chapter must be carried out in
Administrator mode. For information on changing between modes, see
“Changing the SS7 Monitor Mode” on page 184.
NOTE You can quit the SS7 Monitor at any time by pressing (Q)uit.
SS7 Monitor Interface

The Administrator’s Monitor Main Menu provides these options:
1. Configure Entities
Chapter 4 101
2. Monitor Entities
3. Single Entity Statistics
Moving between Use the following keys to move between parameters:

Parameters Table 4-1
key function
+ move down one parameter
- move up one parameter
spacebar move down one window
backspace move up one window
Selecting a choice from the menu displays a window for that choice. Each
window has a corresponding help window, which gives information about
the data requested. All windows have a common format.
You can enter commands using the function keys or a mouse. Commands
and error messages are displayed on the window.
Commands To enter commands, enter the first letter, that is shown between
parentheses in the display. For example, to (c)heckpoint, enter c. To
choose a menu item, enter the number that appears next to it.
Refresh rate For some windows there is at least a 2 second delay in refreshing. The
SS7 Monitor polls the state of the signaling units every 15 seconds.
Information for 2-Host Platforms

On a 2-host platform, network configuration is not possible during
synchronization. Synchronization is the process whereby the active stack
replicates its configuration and transfers this to the standby system. The
configuration must not be changed while the platform is executing this
process. Use the command ocftstatus to determine the state of the
stack.
102 Chapter 4
Configuring MTP and SCCP Network Connectivity

Configuring the SS7 network for MTP and SCCP consists of the
following steps:
Step 1. Check that the stack is running. See “Starting and Stopping
HP OpenCall SS7” on page 93.
Step 2. Start SS7 monitor, by entering ss7MgrStart.
Step 3. From the main menu, choose Configure entities. From this window
you have the following options:
1. lpc
2. MTP
3. SCCP
Step 4. Enter the new configuration. This includes adding links/linksets,

destination point codes, and so on. Refer to the SS7 Monitor on-line help,
and to the “Guidelines for SS7 Network Configuration” for further
information.
Step 5. Save your configuration by entering c to checkpoint.
Step 6. Activate the stack. The configuration loads and MTP activates
automatically.
NOTE Backup your changes frequently, by entering c for checkpoint.
Chapter 4 103
Guidelines for SS7 Network Configuration

Configure your SS7 network entities by building a configuration from the
physical layers of the network, such as links and linksets, to the higher
protocol levels, such as SCCP and global title translations.
You must configure the LPCs first.
You can configure the following entities at a later time. This order is
recommended but not required:
• Linksets/Links
Configure your linksets and then your links—these are configured
from the MTP window. Before you can configure Links and Linksets
you must:
— install the prerequisite hardware

— configure all the links, using SAM
• MTP Parameters
• Destinations/Routes—these are configured from the MTP window
• SCCP
Refer to the SS7 Monitor on-line help for detailed information about each
parameter. However, the sections below contain guidelines for the
different entities.
Local Point Codes and Aliases

You must set the platform Local Point Code (LPC) and aliases in the SS7
Monitor before doing anything else.
NOTE To modify an LPC on an existing configuration, create a new network

configuration as described in the section “Creating Different Network
Configurations” on page 164.
For an explanation of LPC aliases, see the HP OpenCall SS7 Application

Developer’s Guide.
104 Chapter 4
Virtual Point Codes (VPCs) and Virtual Users (VUs)

Virtual Point Codes (VPCs) are non-physical point codes than enable
each SS7 stack to have up to 16 point codes. Virtual Users (VUs) are user
applications that send and receive traffic through the VPCs.
VPCs can be configured in the SS7 Monitor using the Configure entities
| LPC window, and VUs can be configured using the Configure entities |
SCCP window.
MTP
Links/Linksets The Signaling Link Code (SLC) value for ANSI, ITU-T, and the Chinese
standard must be between 0 and 15. For TTC, the SLC value must be
between 0 and 7.
With a TTC system, you need to define whether the linkset is configured
as A or B. A linkset defined as A accepts all even SLSs. A linkset defined
as B accepts all odd SLSs.
Destinations/ Before you can configure destinations and routes, at least one route must
Routes be configured for each destination.
Only one destination may be configured as a gateway (STP used to
interconnect national and international networks).
For information on cluster and full point code routing in the ANSI
standard, see “Configuring SS7 ANSI Routing” on page 109.
Example for The following example demonstrates how to configure destinations and
Configuring routes.
Destinations and
Routes
Chapter 4 105
The example configures a primary and secondary route from LPC 1 to

DPC 3. In the case of the primary route, DPC 3 is both the APC and the
DPC.
Step 1. With the Configure MTP Entities Menu displayed select

“Destinations/Routes”
Step 2. Enter: a 3
Step 3. Enter a d 2
Step 4. Enter a r p 3 3
Step 5. Enter a r s 3 2
106 Chapter 4
SCCP
Setting the Use the following table to decide if you need to set the concerned
concerned parameter to y or n.
parameter
If you... ...then enter this value
want to broadcast management y

information to a particular PC
do not want to broadcast n

management information
have a stack configuration of n

more than 50 DPCs and do not
want your system flooded with
management messages
have a stack configuration of y, but only for APCs. Otherwise

more than 50 DPCs and still you may flood your system with
need some management management messages
messages
SCCP Standard Use this parameter to tell the LPC what SCCP standard mode is in use at
used at DPC the DPC. The syntax of how to do this is in the procedures and examples
that follow.
If you have this standard at

...then enter this value
the DPC...
ITU-T 88 (Blue Book) 0 (default)
ITU-T 92 (White Book) 1
ANSI 88 0 (default)
ANSI 96 - no ISNI 10
Chapter 4 107
Configuring In the Configure Global Title Translations window, the following

Global Title abbreviations are used:
Translations Table 4-2 Global Title Translations
Abbreviation Meaning
NP Numbering Plan
TT Translation Type
NAI Nature of Address Indicator
DPC Destination Point Code
SSN Sub-System Number
Prio Priority
Under Address a backslash \ can be used as a void character. The

numbers following the backslash are then ignored. For example, 800\
can be used to represent all 800 numbers.
Priority Field You can prioritize your global title translations. This means that if one
destination is no longer preferred (for example, it becomes inaccessible)
then the destination with the next highest priority is contacted.
You can prioritize up to ten destinations for one global title translation. 0
has the highest priority and 100 has the lowest priority.
To change the default value, edit the file sys.<className>.sccp.
The loadshare2Gts parameter must be set to YES in the
sys.<className>.sccp file in order to toggle the GT loadsharing
behavior. This flag forces the setMaxPreferred value to 2.
The loadsharing is done between GTs with same TT, NP, NAI and digits
but different priorities.
Do not enter two similar GTs (with same TT, NP, NAI, digits) and same
priorities (behavior unchanged, despite the GT loadsharing feature).
If both DPCs of a GT are available, the choice of DPC is done using the
SLS as follows:
• Odd SLS messages are routed on the highest priority GT.

• Even SLS messages are routed on the lowest priority GT.
108 Chapter 4
NOTE If you want the global title translation to be done by a remote node,
configure the remote node (Remote SP) without a remoteUser (SSN). To
modify or remove an SSN, create a new network configuration as
described in the section “Creating Different Network Configurations” on
page 164.
Configuring SS7 ANSI Routing

This section describes how to configure ANSI Routing.
Cluster Routing The configuration procedure is different depending on

whether the network is already configured.
Configuring Cluster Routing in an Existing SS7 Network
Step 1. Checkpoint your configuration using the checkpointing tool.
Step 2. In the MTP screen of SAM, ensure that the FullPointCode routing box is
not checked.
Step 3. Stop and restart the stack on both hosts. The checkpointed configuration
is loaded automatically.
Some DPC creations are refused because when Full Point Code routing is
disabled, there can only be one DPC (N.C.0) in a remote cluster DPC.
This does not matter as DPC N.C.0 can stand for any DPC. You don’t
have to add anything to the configuration.
If your Full Point Code routing configuration does not have a DPC N.C.0
in the remote clusters (for example, if you have N.C.1, N.C.2 and N.C.3)
all DPCs are refused and you have to reconfigure N.C.0.
Step 4. Checkpoint your configuration again, then propagate it if necessary.
Configuring Cluster Routing with no Existing SS7 Network
not checked.
Step 2. Use the SS7 Monitor, to configure your SS7 network. In remote clusters
only the N.C.0 DPC is allowed.
Chapter 4 109
Full Point Code Routing The configuration procedure is different

depending on whether the network is already configured.
Configuring Full Point Code Routing The following procedure

explains how to enable Full Point Code routing in an existing SS7
network configured in cluster routing.
Step 1. Checkpoint your network configuration.
checked.
is automatically reloaded, but the system is now running in Full Point
Code routing mode.
Step 4. Add all the DPCs and routes that were previously implicitly handled by
DPC with member ID set to 0. For example, if in a remote cluster you
have DPC 2.5.0, 2.5.1 and 2.5.2, you must add DPC 2.5.1 and 2.5.2 (2.5.0
being already declared in the file generated by ss7CheckPoint). You
must also declare the corresponding routes.
Step 5. Checkpoint and propagate your configuration using the command

ss7CheckPoint.
Configuring Full Point Code Routing with no Existing SS7

Network
checked.
is automatically reloaded, but the system is now running in Full Point
Code routing mode.
Step 3. Use the SS7 Monitor to configure your SS7 network. Define all DPC and
routes one by one.
Step 4. Checkpoint and propagate your configuration using the command

ss7CheckPoint.
110 Chapter 4
Configuring the Network (M3UA, MTP and SCCP) for an M3UA-Based Platform
Configuring the Network (M3UA, MTP and

SCCP) for an M3UA-Based Platform
Use the information in this section if you are running an M3UA-based
platform, with M3UA alone, or with MTP-as-backup,
If you are running an MTP-based platform, see “Configuring the
Network (MTP and SCCP) for an MTP-Based Platform” on page 101.
MTP, M3UA and SCCP are configured using an XML file based on an
XML schema.
Configuring MTP, M3UA and SCCP Network

Connectivity
Configuring the network consists of the following steps:
Step 1. Create a new XML file based on the network configuration file
NetworkConfigurationTemplate.xml in the directory
/etc/opt/OC/SS7.
Refer to the section “Guidelines for Network Configuration on an

M3UA-Based Platform” on page 113.
Step 2. Check the modified configuration file using the command

loadconf -check.
Step 3. Check the state of the stack using the command ocftstatus. The state
of the stack will be Degraded, indicating that the stack is started but
that M3UA is not yet configured.
Step 4. Use the command loadconf to load your configuration files. This will
load your configuration file to both hosts on a 2-host configuration.
Step 5. Save your network configuration using the command ss7CheckPoint.

Your configuration will be saved as
/etc/opt/OC/SS7/Saved.<class_name>.conf.ref.xml, and will be
reloaded automatically when the stack is started (or restarted).
Chapter 4 111
NOTE To restart the configuration procedure, first delete the

Saved.<classname>.conf.ref.xml file from the Platform Manager and
the Front-End hosts. Then start the procedure again from step 1.
112 Chapter 4
Guidelines for Network Configuration on an

M3UA-Based Platform
Ensure that you declare the XML elements in the following order. The
order shown below must be followed for your configuration to be
successful.
Layer3
• MTP
— Network (MTP)
— LocalPointCode
— LocalAlias
— Linkset and Link
• M3UA
— Network (M3UA)
— LocalAS
— Remote elements
— RemoteSG and/or RemoteSGP, then RemoteSS7DPC.

— RemoteIPSP (this must come after RemoteSG/RemoteSGP)
• Destinations
— Network (Destinations)
— RemoteAS
— RemoteSS7DPC and SS7Route
SCCP
• Network (SCCP)
— LocalUser
— RemoteSP, RemoteUser and ConcernedLocalUser (can be
configured simultaneously or in this order)
— GlobalTitle and Translation
Chapter 4 113
Additional constraints:
• The SCCP part can only be configured after the LocalAS

corresponding to the si has been defined (SCCP_USER or ALL_USERS).
For more information on the si (Service Indicator), see the section
“LocalAS” on page 125.
• A ConcernedLocalUser can only be added to a RemoteSP if the
corresponding LocalUser has already been created.
• A Translation (DPC [SSN]) can only be configured after the
corresponding RemoteSP [RemoteUser] has already been created.
NOTE For configurations with M3UA_MTP3 transport, ensure that you

configure the parameters LPC, variant and NI for both M3UA and MTP.
You must use the same values in both places. LPC is configured in the
XML file for both M3UA and MTP. NI and variant are configured in the
XML file for M3UA and in SAM for MTP (variant can be configured at
configuration creation and NI can be configured after configuration
creation).
114 Chapter 4
Guidelines for XML Elements

Use the following guidelines when configuring the XML network
elements.
• Network elements are represented as XML elements, and elements

are identified by their attributes. Network elements can refer to
other network elements. For example,
<RemoteSG id="1">
• Attributes are mandatory, and are contained within a tag. For
example,
<LocalAS lpc="100" si="SCCP_USER" routingContext="5" />
• Parameters are between two tags. Some parameters are mandatory,
and some are optional. For example,
<dynamicRegistration>false</dynamicRegistration>
• The create action will be used by default. To use the create action,
don’t specify any action. In order to update, delete, add or remove an
element, add an action sub-element to the corresponding element.
• All parameters are used for creation, except ‘Action’. The update
action allows you to add or remove sub-objects of a given object while
the stack is running.
• When deleting an element, only specify the attributes, not the
parameters.
NOTE To see the maximum number supported for each network element, please
refer to the HP OpenCall SS7 Release Notes.
Chapter 4 115
Table 4-3 below shows the hierarchy of the XML elements in the network
configuration file. For details on each element, see the section “XML
Elements” on page 117.
Table 4-3 XML File Structure
Layer3 MTP Network LocalPointCode

(MTP)
LocalAlias
Linkset Link
M3UA Network LocalAS

(M3UA)
RemoteSG RemoteSGP
RemoteIPSP
Destinations Network RemoteAS

(Destinations)
RemoteSS7DPC SS7Route
SCCP Network LocalUser

(SCCP)
RemoteSP RemoteUser
ConcernedLocalUser
GlobalTitle Translation
For examples, please refer to:
• “Example XML Configuration File - M3UA Only” on page 153.

• “Example XML Configuration File - M3UA with MTP-as-Backup” on
page 150.
116 Chapter 4
XML Elements
This section describes the attributes and parameters for each of the
elements in the XML network configuration file.
Layer3 The layer3 element defines the local and destination configurations.
Occurs once in the network configuration file.
File structure:
<NetworkConfiguration>
<Layer3>
<MTP>
<M3UA>
<Destinations>
Example XML file structures are shown in “Example XML Configuration
File - M3UA with MTP-as-Backup” on page 150 and “Example XML
Configuration File - M3UA Only” on page 153.
MTP Occurs once in every MTP network configuration.

File structure:
<Layer3>
<MTP>
<Network>
An example XML file structure is shown in “Example XML
Configuration File - M3UA with MTP-as-Backup” on page 150.
Chapter 4 117
Network (MTP) Occurs once in every MTP network configuration.

File structure:
<Layer3>
<MTP>
<Network>
<LocalPointCode>
<LocalAlias>
<Linkset>
Table 4-4 Network (MTP) Parameters
Attribute or
Comments
Parameter
id (attribute) Network identifier

Integer
Value: 0
Mandatory
action String
Value: update

118 Chapter 4
LocalPointCode Defines the Local Point Code (LPC).

Occurs once for every LPC.
File structure:
<Layer3>
<MTP>
<Network>
<LocalPointCode>
Table 4-5 LocalPointCode Parameters
Attribute or
Comments
Parameter
lpc (attribute) String

Format: For ANSI and ANSI96, an integer
in the format x.y.z. Otherwise, an integer.
Mandatory

Chapter 4 119
LocalAlias Gives the local alias of the LPC.

Occurs once for every Local Alias.
File structure:
<Layer3>
<MTP>
<Network>
<LocalAlias>
Table 4-6 LocalAlias Parameters
Attribute or
Comments
Parameter
pc (attribute) Point Code

String
Mandatory
action String
Value: update

120 Chapter 4
Linkset Occurs once for every MTP SS7 linkset.

File structure:
<Layer3>
<MTP>
<Network>
<Linkset>
<Link>
Table 4-7 Linkset Parameters
Attribute or
Comments
Parameter
apc (attribute) Adjacent Point Code

String
Mandatory
action String
Value: update, delete
abBit Defines whether a linkset is A or B.

Value: A, B
Use only if your platform is TTC (China).
Mandatory for TCC, not to be used
otherwise.

Chapter 4 121
Link Occurs once for every MTP SS7 link.

File structure:
<Layer3>
<MTP>
<Network>
<Linkset>
<Link>
<LinkId>
Table 4-8 Link Parameters
Attribute or
Comments
Parameter
slc (attribute) Signaling Link Code

Format: 0-7 for TTC, otherwise 0-15.
Mandatory
action String
linkId or PDN Integer

Value: For a TSU, use LinkId, for an SIU,
use PDN.
Mandatory at creation

122 Chapter 4
M3UA Occurs once in every M3UA network configuration.

File structure:
<Layer3>
<M3UA>
<Network>
<RemoteSG>
<RemoteIPSP>
Chapter 4 123
Network (M3UA) Occurs once in every M3UA network configuration.

File structure:
<Layer3>
<M3UA>
<Network>
<LocalAS>
Table 4-9 Network (M3UA) Parameters
Attribute or
Comments
Parameter

Integer
Value: 0
Mandatory
action String
Value: update
ni Specifies network type.

String
Values: INTL, SPARE, NAT, RES
variant Protocol variant.

String
Values: ANSI, ANSI96, ITU, NTT, TTC,
CHINA

124 Chapter 4
LocalAS LocalAS defines the local application server and the LPC. The maximum
number of LPCs is 1.
Occurs once for each Local Application Server (Point Code + Service
Indicator).
File structure:
<Layer3>
<M3UA>
<Network>
<LocalAS>
A localAS can not be modified online after the initial creation.
Table 4-10 LocalAS Parameters
Attribute or
Comments
Parameter
lpc (attribute) Format: For ANSI and ANSI96, an integer

Mandatory
Chapter 4 125
Table 4-10 LocalAS Parameters (Continued)
Attribute or
Comments
Parameter
si (attribute) The Service Indicator (SI) identifies an

MTP user at connection time. It is used to
select the MTP user to whom an incoming
message is distributed.
String
Values:
Character Integer
<none> 0
<none> 1
USER_SPARE2 2
SCCP_USER 3
ISUP_USER 5
DATA_USER1 6
DATA_USER2 7
MTPT_USER 8
USER_SPARE9 9
USER_SPARE10 10
USER_SPARE11 12
USER_SPARE12 12
USER_SPARE13 13
USER_SPARE14 14
USER_SPARE15 15
ALL_USERS <none>
Mandatory
action String
Value: create only.
126 Chapter 4
Table 4-10 LocalAS Parameters (Continued)
Attribute or
Comments
Parameter
routingContext Can be modified while the stack is

(attribute) running.
Note: The routing context is only used for
remote IPSPs or remote SGPs that are
configured statically, when the
dynamicRegistration parameter in the
remoteIPSP or remoteSGP is set to “false”.
Integer
Mandatory

Chapter 4 127
RemoteSG Occurs once for each remote signaling gateway.

File structure:
<Layer3>
<M3UA>
<RemoteSG>
<RemoteSGP>
Table 4-11 RemoteSG Parameters
Attribute or
Comments
Parameter
id (attribute) Integer
Value: 1 to 128
Mandatory
action String

128 Chapter 4
RemoteSGP Occurs once for each remote signaling gateway process in a signaling
gateway.
File structure:
<Layer3>
<M3UA>
<RemoteSG>
<RemoteSGP>
Table 4-12 RemoteSGP Parameters
Attribute or
Comments
Parameter
id (attribute) SGP identifiers and IPSP identifiers

cannot be identical within a configuration.
Integer
Value: 1 to 128
Mandatory
action String
Value: delete
associationAddressType String
Value: IPv4
associationAddress The remote primary address of the

association, used in association requests.
String
Value: IP address
associationPort The remote port of the association. The

default is the reserved M3UA port: 2905.
Integer
Optional
Chapter 4 129
Table 4-12 RemoteSGP Parameters (Continued)
Attribute or
Comments
Parameter
dynamicRegistration If set to TRUE, the remote SGP is known

to send/receive Dynamic Routing Key
Management (DRKM) messages.
Boolean
Values: true, false
defaultNetwork Refers to the id attribute for “Network

(M3UA)” on page 124.
Integer
Value: 0
networkAppearance Network appearance is used in the

network appearance field of the M3UA
message sent to the peer.
Integer
Optional

130 Chapter 4
RemoteIPSP Occurs one for each remote IP Server Process.

File structure:
<Layer3>
<M3UA>
<RemoteIPSP>
Table 4-13 RemoteIPSP Parameters
Attribute or
Comments
Parameter
id (attribute) SGP identifiers and IPSP identifiers

cannot be identical within a configuration.
Integer
Value: 1 to 128
Mandatory
action String
Value: delete
associationAddressType String
Value: IPv4
associationAddress The remote primary address of the

association, used in association requests.
String
Value: IP address
associationPort The remote port of the association. The

default is the reserved M3UA port: 2905.
Integer
Optional
Chapter 4 131
Table 4-13 RemoteIPSP Parameters (Continued)
Attribute or
Comments
Parameter
dynamicRegistration If set to TRUE, the remote SGP is known

to send/receive Dynamic Routing Key
Management (DRKM) messages.
Boolean
Values: true, false
defaultNetwork Refers to the id attribute for “Network

(M3UA)” on page 124.
Integer
Value: 0
networkAppearance Network appearance is used in the

network appearance field of the M3UA
message sent to the peer.
Integer
Optional

132 Chapter 4
Destinations Defines all the destinations that can be reached.

Occurs once in every network configuration.
File structure:
<Layer3>
<Destinations>
<Network>
Network Occurs once in every network configuration.

(Destinations)
File structure:
<Layer3>
<Destinations>
<Network>
<RemoteAS>
<RemoteSS7DPC>
Table 4-14 Network (Destinations) Parameters
Attribute or
Comments
Parameter

Integer
Mandatory.
Chapter 4 133
RemoteAS Occurs once for each Remote Application Server.

File structure:
<Layer3>
<M3UA>
<Destinations>
<Network>
<RemoteAS>
Table 4-15 RemoteAS Parameters
Attribute or
Comments
Parameter
dpc (attribute) Format: For ANSI and ANSI96, an integer

Mandatory
134 Chapter 4
Table 4-15 RemoteAS Parameters (Continued)
Attribute or
Comments
Parameter
si (attribute) The Service Indicator (SI) identifies an

MTP user at connection time. It is used to
select the MTP user to whom an incoming
message is distributed.
String
Values:
Character Integer
<none> 0
<none> 1
USER_SPARE2 2
SCCP_USER 3
ISUP_USER 5
DATA_USER1 6
DATA_USER2 7
MTPT_USER 8
USER_SPARE9 9
USER_SPARE10 10
USER_SPARE11 12
USER_SPARE12 12
USER_SPARE13 13
USER_SPARE14 14
USER_SPARE15 15
ALL_USERS <none>
Mandatory
action String
Chapter 4 135
Table 4-15 RemoteAS Parameters (Continued)
Attribute or
Comments
Parameter
routingContext Integer
IPSP id Refers to the ID of the IPSP element.

Integer
action: add (An IPSP id action can only be
used within an update of the RemoteAS.)

136 Chapter 4
RemoteSS7DPC Occurs once for each remote SS7 Destination Point Code in the SS7
network.
File structure:
<Layer3>
<Destinations>
<Network>
<RemoteSS7DPC>
<SS7Route>
Table 4-16 RemoteSS7DPC Parameters
Attribute or
Comments
Parameter

Mandatory
action String
ss7Stp Only use this if the DPC is addressed via

an MTP network and an SS7 gateway.
You can use the update action to update
this element online.
Boolean
ss7Gateway Use only if the DPC is addressed via an

M3UA network.
You can use the update action to update
Boolean
Chapter 4 137
Table 4-16 RemoteSS7DPC Parameters (Continued)
Attribute or
Comments
Parameter
SG id Refers to the ID of the SG element.

Integer
action: add (An SG id action can only be
used within an update of the
RemoteSS7dpc.)

SS7Route Occurs once for each SS7 route.

File structure:
<Layer3>
<Destinations>
<Network>
<RemoteSS7DPC>
<SS7Route>
Table 4-17 SS7Route Parameters
Attribute or
Comments
Parameter
apc (attribute) Format: For ANSI and ANSI96, an integer

Mandatory
action String
138 Chapter 4
Table 4-17 SS7Route Parameters (Continued)
Attribute or
Comments
Parameter
priority You can use the update action to update

String
Value: primary, secondary

Chapter 4 139
SCCP This element defines the SCCP network configuration.

Occurs once in every SCCP network configuration.
File structure:
<SCCP>
<Network>
140 Chapter 4
Network (SCCP) Occurs once in every SCCP network configuration.

File structure:
<SCCP>
<Network>
<LocalUser>
<RemoteSP>
<GlobalTitle>
Table 4-18 Network (SCCP) Parameters
Attribute or
Comments
Parameter

Integer
Value: 0
Mandatory at update.

Chapter 4 141
LocalUser Occurs once for each local user (SSN).

File structure:
<SCCP>
<Network>
<LocalUser>
Table 4-19 LocalUser Parameters
Attribute or
Comments
Parameter
ssn (attribute) Integer

Value: 2-255
Mandatory
action String
Value: delete

142 Chapter 4
RemoteSP Occurs once for each remote SP.

File structure:
<SCCP>
<Network>
<RemoteSP>
<RemoteUser>
<ConcernedLocalUser>
Table 4-20 RemoteSP Parameters
Attribute or
Comments
Parameter

Mandatory
action String
Values: update, delete
concerned Boolean
Values: true, false
mode You can use the update action to update

the mode online.
String
Values: regular, ITU-white, ANSI96-noisni
Optional

Chapter 4 143
RemoteUser Occurs once for each remote user (ssn) on a remote server process.
File structure:
<SCCP>
<Network>
<RemoteSP>
<RemoteUser>
Table 4-21 RemoteUser Parameters
Attribute or
Comments
Parameter
ssn (attribute) Sub System Number

Integer
Value: 2-255
Mandatory
action String
Value: delete

144 Chapter 4
ConcernedLo- The ConcernedLocalUser X defined within a RemoteSP Y indicates that

calUser X will be informed of the availability state of Y.
Occurs once for each concerned local user within a remote SP.
File structure:
<SCCP>
<Network>
<RemoteSP>
<ConcernedLocalUser>
Table 4-22 ConcernedLocalUser Parameters
Attribute or
Comments
Parameter
lpc (attribute) Format: For ANSI and ANSI96, an integer

Mandatory
ssn (attribute) Integer

Value: 2-255
Mandatory
action String
Values: add, remove
Chapter 4 145
GlobalTitle Occurs once for each global title configured.

At least one of the global title attributes must not be null.
File structure:
<SCCP>
<Network>
<GlobalTitle>
<Translation>
Table 4-23 GlobalTitle Parameters
Attribute or Parameter Comments
numberingPlan (attribute) String or integer

Values:
Character Integer
<none> 0
ISDN 1
<none> 2
UserData 3
Telex 4
MaritimeMobile 5
LandMobile 6
ISDNMobile 7
<none> 8 - 15
Mandatory
translationType Integer
(attribute)
Value: 0-255
Mandatory
146 Chapter 4
Table 4-23 GlobalTitle Parameters (Continued)
Attribute or Parameter Comments
natureOfAddressIndicator String or integer

(attribute)
Values:
Character Integer
<none> 0 (wildcard)
Subscriber 1
ReservedNationalUse 2
National 3
International 4
Mandatory
Chapter 4 147
Translation Occurs once for each translation configured within a global title.
File structure:
<SCCP>
<Network>
<GlobalTitle>
<Translation>
Table 4-24 Translation Parameters
Attribute or
Comments
Parameter
addressInfo (attribute) String

Mandatory
dpc (attribute) The corresponding RemoteSP must be

configured.
Mandatory
ssn (attribute) The corresponding RemoteUser must be

configured.
Integer
Value: 1-255
Optional
action String
Value: delete
priority Integer
Value: 1-99
Optional
148 Chapter 4
M3UA with MTP-as-Backup Configuration Example

The following figure and example file show a Local Point Code configured
for M3UA with MTP-as-backup.
Figure 4-1 Example Network with M3UA with MTP-as-Backup
Local User HP OpenCall

SSN: 10 PC=50
Local AS Local AS
Routing Key: Routing Key:
PC=50 PC=50
SI=3(SCCP_USER) SI=5(ISUP_USER)
M3UA Endpoint MTP
SS7 link
SGP 1
@IP=10.10.10.100
SS7 link
SG 1
SS7 link
DPC DPC
(For SCCP: RemoteSP) (For SCCP: RemoteSP)
PC=100 PC=200
MTP Remote User

SSN: 10
M3UA
Network indicator: International

M3UA variant: ITU
Chapter 4 149
Example 4-1 Example XML Configuration File - M3UA with MTP-as-Backup

<?xml version="1.0" encoding="UTF-8"?>
<NetworkConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="NetworkConfiguration.xsd">
<Layer3>
<MTP>
<Network id="0">
<LocalPointCode lpc="50"></LocalPointCode>
<Linkset apc="200">
<Link slc="0">
<linkId>0</linkId>
</Link>
<Link slc="1">
<linkId>1</linkId>
</Link>
<Link slc="2">
<linkId>2</linkId>
</Link>
</Linkset>
</Network>
</MTP>
<M3UA>
<Network id="0">
<ni>INTL</ni>
<variant>ITU</variant>
<LocalAS lpc="50" si="3" routingContext="1"/>
<LocalAS lpc="50" si="5" routingContext="2"/>
</Network>
<RemoteSG id="1">
<RemoteSGP id="1">
<associationAddressType>IPv4</associationAddressType>
<associationAddress>10.10.10.100</associationAddress>
<associationPort>2905</associationPort>
<defaultNetwork>0</defaultNetwork>
<networkAppearance>2</networkAppearance>
</RemoteSGP>
</RemoteSG>
</M3UA>
<Destinations>
<Network id="0">
<RemoteSS7DPC dpc="100">
<SG id="1"/>
</RemoteSS7DPC>
150 Chapter 4
<ss7Stp>false</ss7Stp>
<ss7Gateway>false</ss7Gateway>
<SG id="1"/>
<SS7Route apc="200">
<priority>primary</priority>
</SS7Route>
</RemoteSS7DPC>
</Network>
</Destinations>
</Layer3>
<SCCP>
<Network id="0">
<LocalUser ssn="10"/>
<RemoteSP dpc="200">
<concerned>true</concerned>
<mode>regular</mode>
<RemoteUser ssn="10"/>
</RemoteSP>
</Network>
</SCCP>
</NetworkConfiguration>
Chapter 4 151
M3UA-Only Configuration Example

The following figure and example file show a local M3UA endpoint
configured with a signaling gateway and a DPC, and also with a remote
AS.
Figure 4-2 Example Network with M3UA Only
Local User HP OpenCall

SSN: 30 PC=100
Local AS
Routing Key:
PC=100
SI=SCCP_USER
M3UA Endpoint
SGP 1 SGP 2
IP@10.10.10.1 IP@10.10.10.2
SG 1
IPSP 10 IPSP 12
IP@10.10.11.1 IP@10.10.11.3
DPC
(For SCCP: RemoteSP)
PC=200
Remote AS
Routing Key:
PC=210
Network indicator: National SI=SCCP_USER
M3UA variant: ITU
Remote User
SSN: 50
152 Chapter 4
Example 4-2 Example XML Configuration File - M3UA Only

<?xml version="1.0" encoding="UTF-8"?>
<Layer3>
<M3UA>
<Network id="0">
<ni>NAT</ni>
<variant>ITU</variant>
<LocalAS lpc="100" routingContext="5" si="SCCP_USER"></LocalAS>
</Network>
<RemoteSG id="1">
<RemoteSGP id="1">
</RemoteSGP>
<RemoteSGP id="2">
</RemoteSGP>
</RemoteSG>
<RemoteIPSP id="10">
</RemoteIPSP>
</RemoteIPSP>
Chapter 4 153
</M3UA>
<Destinations>
<Network id="0">
<RemoteAS dpc="210" si="SCCP_USER">
<routingContext>6</routingContext>
<IPSP id="10"></IPSP>
<IPSP id="12"></IPSP>
</RemoteAS>
<SG id="1"></SG>
</RemoteSS7DPC>
</Network>
</Destinations>
</Layer3>
<SCCP>
<Network id="0">
<LocalUser ssn="30"></LocalUser>
<concerned>true</concerned>
<mode>regular</mode>
<RemoteUser ssn="50"></RemoteUser>
<ConcernedLocalUser lpc="100" ssn="30"></ConcernedLocalUser>
</RemoteSP>
<GlobalTitle natureOfAddressIndicator="National" numberingPlan="ISDN"
translationType="1">
<Translation addressInfo="0800" dpc="210" ssn="50">
<priority>1</priority>
</Translation>
</GlobalTitle>
</Network>
</SCCP>
154 Chapter 4
Updating the M3UA Network Configuration

This section describes how to update your configuration online and
offline.
Updating the Network Configuration Online

Use the following procedure to update the M3UA network configuration
while the stack is running.
You can add new elements, or modify or delete existing ones, by creating
a new file which updates the existing running configuration file with the
changes.
Step 1. Check the stack is running, and use ocNetworkStatus -states to

check the initial configuration is loaded.
Step 2. Save a copy of the running XML configuration file using ss7CheckPoint.
Step 3. Create a new XML file using the same format you used to create the
running XML configuration file. See the “Example XML Update File” on
page 160.
Include only the new elements or those you want to change or delete. The
'action' parameter allows you to specify the operation to perform.
Before you can delete a RemoteSG you must delete all the RemoteSGPs
running on it. Likewise, before you can delete a RemoteSP you must
delete all the RemoteUsers running on it.
You must put the corresponding commands in the correct order in the
XML file, as shown in the example below:
<action>update</action>
<RemoteUser ssn="10">
<action>delete</action>
</RemoteUser>
</RemoteSP>
<action>delete</action>
</RemoteSP>
Step 4. Check the modified configuration file using the command

loadconf -check.
Chapter 4 155
Step 5. Use the command loadconf to load your updated configuration files.
This will modify your XML configuration file, and load the modified
configuration file to both hosts on a 2-host configuration.
You can load the configuration from the Platform Manager or a

Front-End host (the procedure is the same). However, the XML
configuration file must be present on the host on which you execute the
loadconf command.
Step 6. Save your network configuration using the command ss7CheckPoint.

Your updated configuration will be saved as
/etc/opt/OC/SS7/Saved.<class_name>.conf.ref.xml, and will be
reloaded automatically whenever the stack is restarted.
During the checkpoint, the previous configuration file is automatically

saved as: /etc/opt/OC/SS7/Saved.<class_name>.conf.ref.xml.prev
Online Rollback
To rollback configuration updates online, while the stack is running:
Step 1. Create a new updated XML file that reverses the changes.
Step 2. Load the new XML file, as described in “Updating the M3UA Network
Configuration” on page 155.
156 Chapter 4
Updating the Network Configuration Offline

Use this procedure to modify the network configuration offline after
initial creation.
CAUTION To modify your configuration without coherence problems between the

hosts, ensure you follow this procedure in the correct order.
Step 1. Stop the stack on all Front-End hosts of the platform.
Step 2. On one of the hosts, copy the file Saved.<class_name>.conf.ref.xml to

a safe place.
Step 3. Perform the following actions on the same host:
a. Manually edit the file Saved.<class_name>.conf.ref.xml.
Changes in the Saved.<class_name>.conf.ref.xml file must be

done on all Front-End hosts. This file must be exactly the same on
each host.
An easy way to achieve this, is to modify the file on a single host, and
in the case of a 2-host platform, use the cfgPropagate command to
propagate the file to the other Front-End hosts.
b. Check the modified configuration file using the command
loadconf -check.
c. Restart the stack. This will load the modified configuration
automatically.
d. Checkpoint the configuration using ss7CheckPoint. This will
propagate the configuration to all hosts in the platform.
During the checkpoint, the previous configuration file is
automatically saved as:
/etc/opt/OC/SS7/Saved.<class_name>.conf.ref.xml.prev.
Step 4. If you have a 2-host platform, restart the stack on the other host.
Chapter 4 157
Offline Rollback
To rollback configuration updates offline, use the following procedure.
Step 1. Stop the stack.
Step 2. Replace the running XML configuration file on all hosts in the platform,
with the one you previously saved in a safe place in the procedure
“Updating the Network Configuration Offline”.
Alternatively, you can replace the running configuration file with the file
/etc/opt/OC/SS7/Saved.<class_name>.conf.ref.xml.prev saved
during the checkpoint.
Step 3. Restart the stack.
158 Chapter 4
M3UA Configuration Update Example

The following figure and example file show the update of an M3UA and
SCCP configuration. A new IPSP 11 is created, and added to the list of
IPSPs serving the remote AS with routing key (220, all_users).
Figure 4-3 Updating the M3UA and SCCP Configuration
Local User
SSN: 30 HP OpenCall
PC=100
Local AS
Routing Key:
PC=100
SI=SCCP_USER
M3UA Endpoint
SGP 1 SGP 2 IPSP 11 IPSP 10 IPSP 12

IP@10.10.10.1 IP@10.10.10.2 IP@10.10.11.2 IP@10.10.11.1 IP@10.10.11.3
SG 1 New IPSP
Remote AS
Routing Key:
Dynamic PC=210
DPC Registration SI=SCCP_USER
PC=200
Remote User
SSN: 50
Network indicator: National

M3UA variant: ITU
Chapter 4 159
Example 4-3 Example XML Update File

<?xml version="1.0" encoding="UTF-8" ?>
<Layer3>
<M3UA>
</RemoteIPSP>
</M3UA>
<Destinations>
<Network id="0">
<RemoteAS dpc="210" si="SCCP_USER">
<action>update</action>
<IPSP id="11">
<action>add</action>
</IPSP>
</RemoteAS>
</Network>
</Destinations>
</Layer3>
160 Chapter 4
Migrating MTP-Based SCCP to M3UA-Based SCCP

If you've just migrated from an MTP-based configuration to an
M3UA-based one, and you want your previous MTP-based SCCP
network configuration to be loaded in the new stack, use this procedure
to migrate SCCP.
Step 1. Ensure that the new M3UA-based stack is up and running, with the
M3UA network configuration already loaded. Check this using the
command ocNetworkStatus.
Step 2. Load the previous SCCP network configuration file using the following
command:
loadconf -C <classname> -f <legacy network configuration

file> -sccpUpgrade
Step 3. Check that the SCCP configuration is correctly loaded using the
command ocNetworkStatus.
Step 4. Checkpoint the configuration into the XML network configuration file
using the command ss7CheckPoint.
Result
The SCCP part of the legacy network configuration file is loaded in the
M3UA-based stack, and included in the XML network configuration file.
Chapter 4 161
Saving the Network Configuration
Saving the Network Configuration

Save your network configuration frequently as you work, and every time
you finish the stack configuration. This is referred to as checkpointing.
On a 2-host platform the configuration is saved to both SS7 hosts. When
HP OpenCall SS7 starts, it automatically loads the most recently
checkpointed configuration and activates MTP or M3UA.
Checkpointing from the Command Line

Use the command ss7CheckPoint to checkpoint MTP or M3UA network
configurations.
Checkpointing an MTP-Based Configuration using

SS7 Monitor
You can checkpoint at anytime by typing C if this option is shown in your
window.
162 Chapter 4
Loading your Network Configuration
Loading your Network Configuration

Loading the By default, when HP OpenCall SS7 starts, it loads the reference
Default configuration file created by checkpointing. See “Saving the Network
Configuration Configuration” on page 162.
Loading a To load a configuration file other than the reference configuration file,
Non-Default use the loadconf command, using the -f option to specify the file to
Configuration load.
NOTE All configuration files must be owned by a member of the group ocadmin.
Chapter 4 163
Creating Different Network Configurations

Use this procedure to create and use several identical platform
configurations with different network configurations. This will allow you
to switch easily between the different configurations (mainly for test and
development purposes).
Follow the steps below to configure and save the configurations. Steps 3
to 7 must all be done on the same host.
Step 1. On one host, save your current configuration using the ss7CheckPoint
command.
Step 2. Stop the stack on both hosts
Step 3. On one host, save the installed configuration using SAM.
Step 4. Remove the reference files stored in the directory /etc/opt/OC/SS7.
For MTP-based platforms, use the command:

rm Saved.<className>.conf.ref
For M3UA-based platforms, use the command:

rm Saved.<className>.conf.ref.xml
Step 5. Restart the stack on one host.
Step 6. Configure your new network.
On an MTP-based platform, use the SS7 Monitor.
On an M3UA-based platform, edit the XML network configuration file

directly.
Step 7. Checkpoint the new configuration.
Step 8. Using SAM, save the newly checkpointed configuration.
Step 9. Start the other stack. The new configuration is now running.
At any later stage, you can use the Install function of SAM to switch
between the available configurations.
164 Chapter 4
NOTE In order to be configurable using SAM, all files in the HP OpenCall SS7
configuration directories must be owned by a member of the group
ocadmin.
Chapter 4 165
Validating Signaling Connectivity

For an MTP-based platform, this means checking that alignment is
possible at MTP2 and MTP3 levels and that it is possible to connect at
MTP3 level.
For an M3UA-based platform, this means checking IP connectivity with
the signaling network.
Validating MTP2 and MTP3 Connectivity
Prerequisite
Step 1. Connect the TSC cables to the SS7 network.
Aligning at MTP2 Level
Step 1. To align up to MTP2 level, you can use the hardware diagnostic tool.
This tool is described in the HP OpenCall SS7 Troubleshooting Guide.
Aligning at MTP3 Levels
Step 1. Start the SS7 stack(s) using the ss7Start command.
Step 2. Start SS7 Monitor using the ss7MgrStart command.
Step 3. Configure the destinations, linksets, and links.
Step 4. To align at MTP3 level, activate MTP using the SS7 Monitor.
1. In SS7 Monitor (which you started in Step 2), select “Monitor

entities”, select MTP, and if the MTP state is INACTIVE, select
“Activate MTP”.
2. After a while, the MTP state should change to ACTIVE.
Step 5. In the monitor entities/lk/lkset menu, check that all links become
active.
In case of problem, refer to the section on traffic problems in the

HP OpenCall SS7 Troubleshooting Guide.
166 Chapter 4
Validating IP Connectivity for M3UA

Step 1. Ensure that connection to the IP signaling network is valid by
performing the following checks.
a. Ping the remote server IP addresses from each end point to make
sure they are accessible.
b. Use the standard HP-UX tools ifconfig and lanscan to validate the
IP configuration.
c. Use the command netstat -rn to verify the routes configured from
both end points.
Step 2. Ensure the local end point instances are up. Do this using the command:
ocNetworkStatus -C <className> -layer M3UA -states
Connecting an Application at MTP3/M3UA Level

You can check that it is possible to connect at MTP3 level in either of the
following ways:
• Generate traffic using trafgen. Use the /opt/OC/bin/trafgen

command.
• Generate traffic using the MTP tutorials.
MtpClient and MtpServer are the names of the MTP tutorials. They
are located in the /opt/OC/tutorials/SS7 directory.
If MTP traffic is generated, then the connection was successful.
Chapter 4 167
Configuring ISUP
Configuring ISUP
This section provides offline and online procedures for configuring ISUP
applications.
Configuring ISUP Applications Offline

To configure an ISUP application offline, use SAM and follow the path
HP OpenCall SS7 Platform configuration | Configuration <x>|ISUP
configuration, where <x> is an available configuration.
Configuring ISUP Applications Online

This section describes how to update an existing ISUP configuration,
using SAM, without stopping the application.
NOTE All of the configuration described in this procedure must be carried out
in a single SAM session. Changes are not saved until you click OK in the
ISUP Application Configuration Window. When you quit the dynamic
configuration window, the configuration is automatically propagated to
all the hosts of the platform.
Refer to the SAM on-line help and to the

IsupDynamicConfiguration(3) man page for detailed descriptions of
the parameters mentioned below.
Step 1. In the Platform Configuration window, highlight the running

configuration, then select Actions|ISUP Dynamic Config. In dynamic
mode, you can do the following:
• Add or remove DPCs. You cannot change the configuration of an

existing DPC—to obtain the same end result, remove DPC you want
to change, then add a new one with the same name and modified
parameter values.
• Add, remove or modify circuit parameters.
Fields containing information you cannot change are read-only, and

buttons are grayed out.
168 Chapter 4
Configuring ISUP
Step 2. Identify the application you want to update (for example, using the ps
command) and the host on which it is running. Note that you can have
several instances of the same application running on the same platform,
but that only one of these instances is the primary application. If
possible, identify the primary application and carry out steps 4 and 5
below on the host running the primary.
NOTE If you are not able to identify the primary, choose any application
instance and proceed as below.
Step 3. Start nettl (using startnettl as root) on the host running the
application, and open a log window (using wlog).
Step 4. On the host running the application, start the ss7IsupReload script, as
appropriate, giving the application identifier as an argument:
For ISUP
prompt$ ss7IsupReload -appID <appID>
Answer any questions put by the script. When the log file indicates that
both the reload and the dump are complete, the script prompts you to
confirm the changes. When you enter y to do so, the ISUP configuration
file is up to date and the changes come into use. If you choose not to
confirm your changes, restart the application to restore the old values.
NOTE In an HA configuration, a reload can only be carried out on the primary

application. If you start the ss7IsupReload script on a host running a
secondary application, the reload fails and an error message gives the
reason. In this case, repeat steps 4 and 5 on another host running the
application, until the primary has been successfully updated.
In a HA configuration, the ISUP application ceases to be highly available

when the reload is carried out on the primary application, as the values
of CICs may no longer be identical in all application instances. This
remains the case until the secondary application has been restarted.
Step 5. Stop and restart any secondary applications.
Chapter 4 169
Configuring ISUP
170 Chapter 4
5 Validating the Platform
This chapter describes the platform validation that is not covered in the
other chapters of the guide. In particular, it covers validating the High
Availability (HA) of the platform and checking that SNMP traps have
been configured.
Chapter 5 171
Validating the Platform
Validating High Availability (HA)

The HA mode on MTP-based stacks can be Active/Active, or
Active/Hot-Standby (for version 2.x compatibility). For M3UA-based
stacks, the HA mode is always Active/Active (Parallel Engine).
Validating HA means ensuring the platform is OK from an HA
viewpoint. This involves:
• Checking the state of the stack processes.

• Checking the state of the LANs.
• Performing a switchover followed by a switchback
(Active/Hot-Standby mode only).
Checking the Stack Process States

You do this as follows.
Step 1. Start the SS7 stack(s), using the ss7Start command, on one host at a
time.
Step 2. Look at the process states using the command ocftstatus.
The possible process states are:
• ACTIVE
• BOOTING
• DOWN
• SYNCHRONIZING
• UNKNOWN
• HOT-STANDBY
In Parallel Engine mode, the stacks should be ACTIVE on both hosts.
In Active/Hot-Standby mode, once SS7 has fully started on both hosts,

the stacks should be ACTIVE on one host (host1) and HOT-STANDBY on the
other (host2).
172 Chapter 5
2-Host Platform On a 2-host platform, the Platform Monitor display has two columns and
switch buttons. You can force a switchover of HA processes, by clicking on
one of the switch buttons (switch group or switch all). During a
switchover, the performance of an operational platform is affected.
Performing a Switchover and a Switchback
Performing a On a two-host platform, you perform a switchover as follows.

Switchover
Step 1. Check that the SS7 stacks are running on both hosts (if necessary, use
the ss7Start command on one host at a time).
Step 2. If the Platform Monitor is not running, use the ss7MgrStart command
to start it).
Step 3. From host1, switch the stacks manually by clicking on the switch all
button (in the Platform Monitor screen).
Step 4. On the Platform Monitor, check that all the services have switched over
to host2.
Step 5. On the SS7 Monitor, check that all the links remain active.
Step 6. On the Platform Monitor, check that the stack reaches the HOT-STANDBY
state on host1.
Performing a You perform a switchback as follows.

Switchback
Step 7. From host2, switch the stacks manually by clicking on the switch all
button (in the Platform Monitor screen).
Step 8. On the Platform Monitor, check that all the services have switched over
to host1.
Step 9. On the SS7 Monitor, check that all the links remain active.
Step 10. On the Platform Monitor, check that the stack reaches the HOT-STANDBY
state on host2.
Chapter 5 173
Checking that the LANs Are OK

You do this as shown below.
Figure 5-1 Dual LANs
Step 1. Retrieve information about the LAN interfaces, host names, and IP
addresses of the Dual LANs. You can do this by executing the netstat
-i and netstat -in commands.
174 Chapter 5
Step 2. Check LAN1.
• Physically disconnect LAN1 from Host A.
• Check that no switchover or split brain symptom occurs and that

there is no impact on the SS7 stack. For more information on the
split brain symptom, see the HP OpenCall SS7 Troubleshooting
Guide.
• Perform a ping on LAN2.
• Reconnect LAN1 to Host A.
• Wait for the establishment of traffic, then perform a ping on LAN1.
Step 3. Check LAN2 (as is described in step 2 for LAN1).
Chapter 5 175
Validating SNMP Operation

Validating SNMP operation means checking that SNMP Traps have
been configured and that they have been activated.
Checking That SNMP Traps Have Been Configured

To check that SNMP Traps have been configured for HP OpenCall SS7,
you must:
Step 1. Check that the HP master agent has been configured to send SNMP
Traps.
The configuration file is /etc/SnmpAgent.d/snmpd.conf.
See the section “Configuring SNMP Traps” on page 192.
Step 2. Check that the SNMP agent process (which is a sub-agent of the HP
master agent) has been enabled.
This is done using SAM, see “SAM: HP OpenCall Platform Configuration

Tool” on page 372.
See also Chapter 3, Configuring and Starting the Platform.
176 Chapter 5
Checking That SNMP Traps Are Active

To check that SNMP Traps are active with HP OpenCall SS7, you must:
Step 1. Check that SNMP Traps are enabled:
1. In SAM, select the “View/Modify” menu.
If necessary, start SAM. See “SAM: HP OpenCall Platform

Configuration Tool” on page 372.
2. Click on the “Fault Tolerance Processes” button, and check that

ss7SNMPAgent is present in the list.
3. If ss7SNMPAgent is not present, activate “Process Name” and choose

ss7SNMPAgent.
Step 2. Check that the HP master agent is running (snmpdm).
You can do this as follows:

ps -ef | grep snmpd
Step 3. Check that nettl is running. See “Stage 8 - Starting Logging” on

page 61.
Chapter 5 177
178 Chapter 5
6 Managing and Monitoring the
Platform
This chapter contains a number of procedures and information that are

useful for monitoring, managing and maintaining the platform.
Chapter 6 179
Managing and Monitoring the Platform
Managing and Monitoring an MTP-Based Platform
Managing and Monitoring an MTP-Based

Platform
This section gives information for managing and monitoring an
MTP-based platform. For information on managing and monitoring an
M3UA-based platform, (M3UA only or M3UA with MTP-as-backup), see
“Managing and Monitoring an M3UA-Based Platform” on page 188.
Starting and Stopping the Platform Management

Tools
NOTE HP OpenCall SS7 must be running before you can start the platform
management tools.
Starting Platform Management

To start the platform management tools enter the ss7MgrStart
command. This starts two tools:
• Platform Monitor—this is the user interface for the Fault Tolerance

Controller
• SS7 Monitor—this lets you monitor and configure the SS7 network
SS7 Monitor can run in two modes:
• Administrator—allowing both configuration and monitoring

• Operator—allowing monitoring only
Refer to “Changing the SS7 Monitor Mode” on page 184 for instructions
on changing between these modes.
See the SS7 Monitor on-line help for information on the parameters
displayed.
See “Configuring the Network (MTP and SCCP) for an MTP-Based
Platform” on page 101 for guidelines on configuring the SS7 network.
180 Chapter 6
Starting the Platform Monitor Alone

To start the Platform Monitor without starting the SS7 Monitor, use the
command:
/opt/OC/bin/FT_Monitor
Run this command as ocadmin or as root.
NOTE The Platform Monitor runs as a separate process from the FTC itself.
Stopping the FTC does not close down the Platform Monitor, and closing
the Platform Monitor does not stop the FTC.
Refer to the Platform Monitor’s on-line help for a description of the

different possible process states.
Stopping the Platform Management Tools

Use the ss7MgrStop command to stop the platform management tools
and kill any running processes. Enter it with one of the following options:
• -all—Stops all management processes.

• -select—Prompts you to specify the process(es) to kill.
Validating the Platform Manager

This means checking that the Platform Manager is functioning correctly.
Step 1. On each of the Front-End hosts, start the SS7 stack(s):
ss7Start
Step 2. On the Platform Manager, start the SS7 Monitor:
ss7MgrStart
This starts both the Platform Monitor (to access the Fault Tolerance
Controller) and the SS7 Monitor (to configure/monitor SS7). If the SS7
stack is not running, the SS7 Monitor does not start.
Once the stacks have been started on the Front-Ends, you can stop and
start the stacks as required using the Platform Monitor on the Platform
Manager host.
Chapter 6 181
Step 3. On the Platform Monitor, check that the states of the Front-Ends are
reported. If so, the Platform Manager is correctly configured. Otherwise,
see the HP OpenCall SS7 Troubleshooting Guide.
Monitoring HP OpenCall SS7 Processes

To monitor the state of stack processes, use the Platform Monitor. This
starts automatically when you give the ss7MgrStart command.
Processes can be in one of the following states:
Table 6-1 Stack Process States
State Meaning
Active Process is handling platform functions
Degraded Process is on-line, but not performing at optimum level -

maintenance may be required to upgrade service
HotStby Process is acting as hot standby, ready to take over

control of a service
Switching Process is becoming active
Synchro Process is synchronizing with the active process. If a

switchover happens during synchronization, no service
is provided to existing clients
Stopping Process is going down
ColdStby Process is available to become active, but is not

synchronized with the current active process
Booting Process is rebooting
Down Process is down
Unknown No information is available on process state
The display is updated automatically, or you can force an update by

clicking the Refresh button.
182 Chapter 6
Changing the State of Stack Processes

To force a change on a stack processes, use the Platform Monitor. This
starts automatically when you give the ss7MgrStart command, or you
can start it explicitly. See “Starting the Platform Monitor Alone” on
page 181. Click the appropriate button for the change you want to make.
In 2-host mode, you must also choose the host you want your actions to
apply to. Possible changes are shown below (a different subset is shown
for active/active and active/standby modes):
Table 6-2 Forcing Stack Process Changes
Button Effect
Emergency Stop All Kills all running processes
Graceful Stop All Shuts down all running processes layer by

layer, minimizing disruption.
Switch Group Switches the selected pair of processes,

together with any other processes in the same
group
Switch All All paired processes are switched
Emergency Stop Kills the selected process
Graceful Stop Shuts down the selected process layer by layer,

minimizing disruption.
Restart Restarts the selected process
Monitoring the SS7 Network on an MTP-Based

Platform using the SS7 Monitor
To monitor the SS7 network, use the SS7 Monitor. You can do this in
either Operator or Administrator mode.
The Monitor Entities and Single Entity Statistics menu items let you
monitor and get statistics on the SS7 network and about hardware
status. These menus can be accessed in Operator (non-privileged) mode,
as well as in Administrator mode. Refer the SS7 Monitor on-line help
and to Appendix A, Tools Catalog, for details on the information
provided.
Chapter 6 183
See “SS7 Monitor Interface” on page 101 for information on syntax and
navigation.
Changing the SS7 Monitor Mode

To switch between the available modes, edit the file
/etc/opt/OC/management/mgtProcessList.conf to comment out the
lines that you do not require:
# To start Administrator SS7 Monitor(s)
$BINPATH/ss7AdmMon -C $CLASSNAME_1 -typeName $TYPENAME_1
# To start Operator SS7 Monitor(s)
#$BINPATH/ss7OpeMon -C $CLASSNAME_1 -typeName $TYPENAME_1
Available Network Entities

Using the Operator’s interface, you can monitor the following:
• Hardware State
• MTP
• SCCP
• TCAP
Monitoring MTP
If you choose MTP from the main menu, you can choose to monitor one of
the following:
• MTP
• Destinations / Routes
• Links / Linksets
Monitoring Overall MTP Layer Traffic From the Monitor MTP

window you can activate, deactivate, and monitor the overall traffic of
the MTP layer of the SS7 stack.
Monitoring Destinations/Routes From the Monitoring

Destinations/Routes window you can activate, deactivate, and monitor
the status of destinations, or individual routes to one destination. The
window shows the states as defined in the ITU-T/ANSI
recommendations.
184 Chapter 6
NOTE As soon as one route leading to a destination is congested, the

destination is declared congested even if there are other uncongested
routes leading to that destination.
Search Use the (S)earch function (type S) to find a particular destination point
code.
Test Use the (T)est function (type T) to test the route in the TTC standard.
The local host sends a SRT and expects the return of an SRA. The return
notification will display, for example:
*** Routing test successful on route DPC, RPC ***
or
***Error : Routing test failed on route DPC, RPC ***
This testing function is not available for the ITU-T nor ANSI standards.
If you try to test these standards, you will see an error message.
You cannot access the route while it is being tested.
Monitoring Links/Linksets From the Monitoring Links/Linksets

window you can activate, deactivate, inhibit, uninhibit and monitor the
status of links to adjacent DPCs.
You can also monitor overall traffic on the linksets.
Abbreviations used in this window are as follows:
• in the column AIOC, A = Active, I = Inhibit, O = Out of Service, C =

Congested, ---- = inactive
• Rx %Use = percentage link utilization rate for reception
• Tx %Use = percentage link utilization rate for transmission
Link Inhibit The link inhibit command works for ANSI and ITU-T stacks, but is not in
the TTC standard. If you use TTC, you will see an error
(ILLEGAL_OA_OPERATION) if you try to inhibit a link.
Chapter 6 185
Linkset/Link Activation Behavior
When the Stack The activation behavior of Link/Linkset is automatic if the links have
Starts been configured, that is your links become ACTIVE. If a Signaling Unit
has a status of ONLINE, the link(s) pass from INACTIVE, to
OUT_OF_SERVICE to ACTIVE.
If the Signaling Unit has a status other than ONLINE or STANDBY, the
Signaling Unit is reloaded until it has an ONLINE or STANDBY state,
and then the links will pass through the states as described above.
When the Stacks If the Signaling Unit must pass from STANDBY to ACTIVE in the case
Switchover of a HP OC SS7 host switchover, the links are not impacted and remain
ACTIVE.
NOTE When a destination is out-of-service, because of a network problem

(remote destination not responding to alignment procedure, for example)
you cannot inhibit all the links of a linkset. You must first deactivate the
failed destination.
Starting Up After a If a switchover occurs when the MTP is not active, it means that
Switchover synchronization failed. In this case, stop the synchronization before you
(Active/Standby re-start. You should:
Mode Only)
1. Stop the synchronization.
2. Activate MTP.
3. Re-start synchronization.
Single Entity Statistics

The following options are available:
• MTP
• Linkset
• Link
• SCCP
• TCAP
The statistical data for the selected entity is updated every few seconds.
186 Chapter 6
MTP From this window you can see the MTP statistics for the local
point code.
Linkset Enter the identifier of the linkset that you want to monitor.
Link Select a link that you want to monitor.
SCCP Enter S, then enter the entity (select from 1 to 5) and parameters
that you want to monitor:
Example:
(2) Local User [ 2 <ssn> ]: in this case, enter 2 then the ssn.
TCAP From this window you can see the TCAP statistics for the local
point code.
Chapter 6 187
Managing and Monitoring an M3UA-Based Platform
Managing and Monitoring an M3UA-Based

Platform
This section gives information on managing and monitoring an
M3UA-based platform, (M3UA only or M3UA with MTP-as-backup). For
information for managing and monitoring an MTP-based platform, see
“Managing and Monitoring an MTP-Based Platform” on page 180.
For more information on the command listed below, see the relevant man
pages.
Managing and Monitoring Platform Processes

To see the state of the platform processes, use the command ocftstatus.
To change the state of the platform processes, use the command
ocftcontrol.
NOTE The SS7 Monitor is not supported for M3UA with MTP-as-backup.
Managing the Network Configuration

For detailed information on how to configure the network, see
“Configuring the Network (M3UA, MTP and SCCP) for an M3UA-Based
Platform” on page 111.
To manage the network configuration, use the command loadconf.
To activate or deactivate the local endpoint instances, whatever the
running protocols, (either M3UA only or M3UA with MTP-as-backup)
use the command ocNetworkControl.
To activate or deactivate individual elements in the local MTP end point
instance, use the command mtpCtrl.
To activate or deactivate individual elements in the local M3UA endpoint
instances (local ASPs and IPSPs), use the command m3uaCtrl. The
command m3uaCtrl also allows you to enable and disable the access or
connection to a given remote SGP or IPSP.
188 Chapter 6
Adding a New IP System Address for M3UA Traffic

Use this procedure to add a new IP address for M3UA traffic.
You will need to stop and restart the stack as part of this procedure.
Step 1. Save the existing file /etc/rc.config.d/netconf to a safe place.
Step 2. Configure the new IP address using SAM.
Step 3. Save the running platform configuration using SAM.
Step 4. Add the IP address to the local M3UA endpoint instance using SAM.
Step 5. Stop the stack using the command ss7Stop -all
CAUTION It is imperative that you have run the command ss7Stop -all before
you run the command sctp stop, since running sctp stop closes all
existing associations set up to and from the host.
Step 6. When configuring a new IP address with SAM, the IP routing tables are
automatically updated with a route that uses the new interface to reach
the sub-network directly connected to it.
If the interface is intended to be used with networks behind network

routers, it is also necessary to configure the routes towards these remote
networks.
This is especially true if the remote SCTP endpoints, with which you
want to set-up SCTP associations, are multihomed. In such a case, it is
necessary to define a route towards each of the IP addresses (or at least
to the sub-network) that are used by the remote SCTP endpoint.
Step 7. Run the commands:

/sbin/init.d/sctp stop; /sbin/init.d/sctp start;
Step 8. Re-start the stack using the command ss7Start.
Step 9. Perform the previous actions on your second host, if required.
Checks
Validate M3UA connectivity using the procedure in “Validating IP
Connectivity for M3UA” on page 167.
Chapter 6 189
Check the state of the processes using the command ocftstatus.
Monitoring the SS7 and M3UA Network

If your platform is M3UA only, or M3UA with MTP-as-backup, use the
command ocNetworkStatus to monitor the MTP and M3UA network.
The command ocNetworkStatus allows you to monitor network entity
states and statistics.
Refer to the man pages for more information.
190 Chapter 6
Managing and Monitoring for All Platforms
Monitoring the Platform using the Web-based Monitor

You can monitor the state of platform processes using the web-based
monitor. To do so:
Step 1. Ensure that the web-based monitor and its pre-requisite software (HP
Apache-based Web Server, and Java™ SDK) are correctly installed and
configured. Refer to the HP OpenCall SS7 Release Notes for versions and
package names.
NOTE The Tomcat servlet is used for web-based monitoring.
By default, Tomcat uses Java 1.2 [JAVA_HOME=/opt/java1.2] in

/etc/rc.config.d/tomcat. Java 1.2 is the minimum recommended for
web-based monitoring on an MTP-based platform.
If you want to use web-based monitoring on an M3UA-based platform,

you must update /etc/rc.config.d/tomcat with the path to Java 1.3
[JAVA_HOME=/opt/java1.3].
Step 2. If your operating system is HP-UX 11i, you can omit this step since the
HP Apache-based Web Server and the Tomcat servlet are started by
default at boot-up (although you should ensure that they are running).
Otherwise, as root, start the HP Apache-based Web Server and the

Tomcat servlet using the following commands, in the order shown:
You must execute the scripts on all Front Ends in the platform.
/sbin/init.d/apache start
/sbin/init.d/tomcat start
Step 3. Connect to the application by entering the following URL in any

supported web browser:
http://<servername>/examples/hp/opencall/monitoring/home/home.jsp
Chapter 6 191
NOTE It must be possible to access the server from the workstation the
web-browser is running on.
To stop the web-based monitoring feature, stop the HP Apache-based

Web Server and the Tomcat servlet by running the following commands
as root:
/sbin/init.d/apache stop
/sbin/init.d/tomcat stop
Viewing Logs
When working with HP OpenCall SS7, it is often useful to display the
system’s logs. This lets you see immediately that all is well, or take
appropriate action if there is a problem.
To view logs alone make sure nettl is running, then enter the wlog
command.
To include Cause and Action in the display, if these are available, use the
wlog -extended command.
Working with SNMP Traps

HP OpenCall SS7 provides an SNMP traps mechanism that can be used
in conjunction with an SNMP manager such as HP OpenView. The
HP OpenCall SS7 SNMP agent, ss7SNMPAgent, maps Cause and Action
logs to SNMP traps. The ss7SNMPAgent is a sub-agent of the HP master
agent. The destination to which traps are sent is
/etc/SnmpAgent.d/snmpd.conf.
Configuring SNMP Traps

To set up SNMP traps, do the following:
Step 1. When creating your initial configuration, ensure the SNMP agent
process is enabled. See “Creating a New Configuration” on page 78.
Step 2. If the master agent is running, stop it.
192 Chapter 6
Step 3. Edit the trap-dest field of the /etc/SnmpAgent.d/snmpd.conf file to

point to the destination for SNMP traps. Copy this file to all hosts in your
platform.
Step 4. Restart the master agent using the snmpd command.
Step 5. In order to work with HP OpenView:
a. Copy the following file onto your management station:

/etc/opt/OC/management/OpencallSS7_trapd.conf
b. On the management station, run the following command:
$OV_BIN/xnmevents -merge OpencallSS7_trapd.conf
Displaying a List of Available Traps

To list the available traps, enter the following command:
ss7SNMPAgent -displayTrapDoc.
Logs can be one of the following types: Informative, Warning, Minor
and Major.
Displaying OIDs of the Trapped Events

The OID of the traps will be given below as:
1.3.6.1.4.1.11.2.29.2.0.<TrapID>
where <Trap ID> is given by running the command ss7SNMPAgent
-displayTrapDoc and the 1.3.6.1.4.1.11.2.29.2.0 sequence is
located in the /etc/opt/management/OpenCallSS7_trapd.conf file.
Stopping a Stack on a 2-Host Platform

If you need to stop one of the hosts on your platform (for maintenance or
any other reason) use the procedure below to find the host that is
running the standby SCCP process. If you stop this host, you will
minimize the impact on signaling traffic.
Step 1. Use the Platform Monitor or the command ocftstatus to check the
stack is running correctly on both hosts.
Step 2. Use the command ocftstatus to determine which host the standby
SCCP process is running on.
Step 3. Use the Platform Monitor to stop the stack on this host (a graceful
shutdown).
Chapter 6 193
Step 4. Wait for the Platform Monitor to show that the stack is DOWN on the
host.
194 Chapter 6
7 Upgrading the Platform License
This chapter describes how to upgrade your platform license, and display
license information.
Chapter 7 195
Upgrading the Platform License
The features you can access when using HP OpenCall SS7 depend on
your license. It is possible to update your license to access more
functionality.
This chapter provides procedures on how to upgrade a license on an
HP OpenCall SS7 3.2 platform. Below this procedure is a description of
how to display the platform’s current license information.
196 Chapter 7
Adding New Feature Codewords
Adding New Feature Codewords

This procedure allows you to increase platform capacity or add features
by adding a new codeword to your platform license.
Step 1. In SAM, open the HP OpenCall SS7 Configuration tool and select
Actions|License.
Step 2. Enter your additional codeword and press ‘OK’.
Step 3. In the main SS7 Platform Configuration menu, use Actions|Propagate

to propagate the new license to all the systems in your platform.
A platform restart will retain the new configuration.
Step 4. If you are upgrading your license online, with a running stack:
Load the new license using the command:
ocLicense -reload
This option is used to increase your M3UA traffic capacity online, or to

increase the number of SS7 links.
Chapter 7 197
Migrating from a Non-Commercial to a Commercial License
Migrating from a Non-Commercial to a

Commercial License
Step 1. Note your existing license codewords for future reference. You will need
them if you wish to perform a rollback.
Step 2. In SAM, open the HP OpenCall SS7 Configuration tool and select
Actions|License.
Step 3. Press Change to change your initial codeword.
Step 4. Enter your additional codeword(s).
Step 5. In the main SS7 Platform Configuration menu, use Actions|Propagate

to propagate the new license to all the systems in your platform.
198 Chapter 7
Displaying Licensing Information

To display licensing information, you can choose from the following:
• In SAM, open the HP OpenCall SS7 Configuration tool, and select

Actions|License.
• Enter the following command: ocLicense -display
Chapter 7 199
200 Chapter 7
8 Using the SS7 Guardian Kit
This chapter describes how to use the SS7 Guardian Kit with
HP OpenCall SS7. This feature is only available if MC/ServiceGuard is
installed. The SS7 Guardian Kit is not intended for use on a platform
operating in the Parallel Engine mode.
Chapter 8 201
Using the SS7 Guardian Kit
High Availability for User Applications
NOTE When carrying out any of the installation activities described in this
chapter, you must log in as root. When carrying out the configuration
activities, log in either as the user ocadmin or as root.
SS7Guardian Kit, HP OpenCall SS7 and User

Application High Availability
The HP OpenCall SS7 platform provides a high availability environment
for its own processes (the SS7 stack and SS7Waiter), but does not provide
high availability for the user applications themselves. High availability
for user applications can be provided on HP OpenCall SS7 platforms by
using the HP standard product MC/ServiceGuard.
MC/ServiceGuard MC/ServiceGuard is a specialized utility for protecting mission critical

applications from hardware and software failures. With
MC/ServiceGuard, multiple computers are organized into a cluster that
is capable of delivering highly available application services, grouped as
MC/ServiceGuard packages.
MC/ServiceGuard monitors the components in each computer, and
quickly responds to failures in a way that minimizes application
downtime. MC/ServiceGuard is able to detect and respond to failures in:
• the System Processing Unit

• the System Memory
• the System and application processes
• the LAN media and adaptors
For more information on MC/ServiceGuard, see the HP
MC/ServiceGuard documentation.
202 Chapter 8
MC/ServiceGuard Both MC/ServiceGuard and HP OpenCall SS7 are able to detect the
and failure of an application and to activate this application on a new host.
HP OpenCall SS7 However, they react differently once the failure is detected:
• MC/ServiceGuard restarts the application in the same or another

host in the cluster,
• HP OpenCall SS7 requests the affected running process to go from
the standby state to the active state
To control how MC/ServiceGuard and HP OpenCall SS7 cooperate, HP
provides the “SS7Guardian Kit”, which comprises two utilities:
• SS7GuardianAngel and
• SS7GuardianSwitch
Use of The use and configuration of the SS7Guardian Kit is optional, depending
SS7Guardian Kit on how you want the HP OpenCall SS7 platform to behave in the event
of a failure.
The SS7Guardian Kit can only be used in non-mixed configurations; that
is, where the application and the active stack are on the same host.
Architectures not The SS7Guardian Kit is not required for the following architectures:
requiring the
SS7Guardian Kit • Front-end/ Back-end (FE/BE) configurations where
MC/ServiceGuard manages the back-end applications only:
MC/ServiceGuard manages the BE applications as an
MC/ServiceGuard cluster, while HP OpenCall SS7 runs on a 1-host
or 2-host FE platform. They operate independently from each other.
• A 1-host HP OpenCall SS7 platform under MC/ServiceGuard
management:
MC/ServiceGuard manages the BE applications, and manages
HP OpenCall SS7 on a 1-host platform as one of its cluster
applications.
• A 2-host HP OpenCall SS7 platform, where the applications and
stack are not required to run on the same machine - so that the
application does not need to be linked or to switch over if the SS7
Stack switches over.
In all cases, HP OpenCall SS7 and MC/ServiceGuard are configured
independently as described in their respective documentation.
Chapter 8 203
Architectures The SS7Guardian Kit is required for architectures where

requiring the MC/ServiceGuard runs on the same 2-host platform as
SS7Guardian Kit HP OpenCall SS7, with user applications running on the hosts as an
integrated MC/ServiceGuard/SS7Guardian Kit cluster.
In such an integrated cluster configuration, HP OpenCall SS7 and
MC/ServiceGuard must cooperate in case there are race conditions and
conflicts in failure detection and recovery. The possible conflicts, and the
solutions provided with the SS7Guardian Kit are described in the
following section “Managing Conflicts in Failure Detection: Principles”
on page 219.
HP OpenCall SS7/ On an HP OpenCall SS7 platform, application services can be grouped

ServiceGuard together as packages.
Configurations
HP-UX and LANs The HP-UX three LAN solution is shown in Figure 8-1,
“MC/ServiceGuard - SS7Guardian Configuration for HP-UX - three LAN
solution.”
The HP-UX two LAN solution is shown in Figure 8-2, “MC/ServiceGuard
- SS7Guardian Configuration for HP-UX - two LAN solution.”
NOTE The RS-232 MC/ServiceGuard link is also highly recommended. This is

used as a heartbeat mechanism if there are problems with the LANs.
Refer to your MC/ServiceGuard documentation to configure this. This
link is shown in the Figure 8-2, MC/ServiceGuard - SS7Guardian
Configuration for HP-UX - two LAN solution.
204 Chapter 8
Figure 8-1 MC/ServiceGuard - SS7Guardian Configuration for HP-UX -

three LAN solution
SS7-1 LAN 2
Subnet 0
MC/ServiceGuard Standby LAN

Subnet 1
Bridge
SS7-2 LAN 0
MC/ServiceGuard
Subnet 1’ Mandatory Cluster Lock
Platform Manager
Shared Disks
H H
H H
Independent Independent
Power Supply Power Supply
Signaling
Units
SS7 Links SS7 Links
MC/ServiceGuard - SS7Guardian Cluster
Chapter 8 205
Figure 8-2 MC/ServiceGuard - SS7Guardian Configuration for HP-UX - two

LAN solution
Subnet 0 LAN 1
SS7 + MC/Service Guard
Serial RS-232
SS7-MC/ServiceGuard LAN 0
Subnet 1’
Mandatory Cluster Lock
Platform Manager
Shared Disks
H H
H H
Independent Independent
Power Supply Power Supply
Signaling
Units
SS7 Links SS7 Links
MC/ServiceGuard - SS7Guardian Cluster
206 Chapter 8
Configuring the Platform and SS7Guardian Kit
Configuring the Platform and SS7Guardian

Kit
Configure the SS7Guardian Kit files in the table below before running
the platform. Examples files for non-mixed mode are shown in the
following pages; fields to be configured are shown in bold.
NOTE You may need to configure the MC/ServiceGuard configuration files for
your platform. Refer to the MC/ServiceGuard documentation for
information.
MC/ServiceGuard/SS7Guardian Kit Cluster

Configuration File
Generating the file Use the command cmquerycl to generate this file. See the man page
cmquerycl(1M) for a description. Giving your system values as
arguments to the command will configure the file.
Configuring the See the MC/ServiceGuard manual to configure this file. The
file customizable values are shown in bold in the example below. It is shown
configured for HP-UX 3 LAN platforms.
To have a HP-UX 2 LAN platform, you must comment the lines for 3
LANs and uncomment the lines for 2 LANs.
# **********************************************************************
# ********* HIGH AVAILABILITY CLUSTER CONFIGURATION FILE ***************
# ***** For complete details about cluster parameters and how to ****
# ***** set them, consult the cmquerycl(1m) manpage or your manual. ****
# **********************************************************************
# Enter a name for this

cluster. This name will be used to identify the
Chapter 8 207
# cluster when viewing or manipulating it.
CLUSTER_NAME <clusterName>
#
Cluster Lock Device Parameters. This is the
volume group that
# holds the cluster lock which is used to break a cluster formation
# tie. This volume group should not be used by any other cluster
# as cluster lock device.
FIRST_CLUSTER_LOCK_VG /dev/vgpkg1
# Definition of nodes in the cluster.
# Repeat node definitions as necessary for additional nodes.
NODE_NAME <nodeName_1>
NETWORK_INTERFACE lan0
HEARTBEAT_IP <hearbeat_IP_1>
STATIONARY_IP <stationary_IP_1> # HP-UX (3 LANs)
# for HP-UX (2 LANs) comment out the above line and uncomment the
# following line:
# HEARTBEAT_IP <heartbeat_IP_1b> # HP-UX (2 LANs)
FIRST_CLUSTER_LOCK_PV /dev/dsk/c2t1d0
#
Primary Network Interfaces on Bridged Net 1: lan0.
# Warning: There are no standby network interfaces on bridged net 1.
# Primary Network Interfaces on Bridged Net 2: lan1.
208 Chapter 8
HEARTBEAT_IP <hearbeat_IP_2>
STATIONARY_IP <secondary_IP_2> # HP-UX (3 LANs)
# for HP-UX (2 LANs) comment out the above line and uncomment the following line:
# HEARTBEAT_IP <heartbeat_IP_2b> # HP-UX (2 LANs)
FIRST_CLUSTER_LOCK_PV /dev/dsk/c2t1d0
# There are no primary network interfaces on bridged net 3.
# Possible standby Network Interfaces on Bridged Net 3: lan1.
# Cluster Timing Parmeters (microseconds).
HEARTBEAT_INTERVAL 1000000
NODE_TIMEOUT 2000000
# Configuration/Reconfiguration Timing Parameters (microseconds).
AUTO_START_TIMEOUT 600000000
NETWORK_POLLING_INTERVAL 2000000
# List of cluster aware Volume Groups. These volume groups
# will be used by clustered applications via the vgchange -a e command.
# For example: # VOLUME_GROUP /dev/vgdatabase.
Chapter 8 209
# VOLUME_GROUP /dev/vg02.
VOLUME_GROUP /dev/vgpkg1
210 Chapter 8
Customer Application Package Configuration File

In order for a customer application to run on the active stack host, both
the stack and the application must belong to the same application
package. To support this, a service is implemented which watches the
state of the SS7 Stack on which the application resides. Specify the
package control script name that will control the services executed
(Run/Stop), and the service ss7GuardianAngel that will control the
services executed (Run/Stop).
Generating the file Use the command cmmakepkg -p to generate this file. See the man page
cmmakepkg(1M) for a description.
Configuring the The customizable values are shown in bold in the example below.
file
# **********************************************************************
# ********* SERVICEGUARD PACKAGE CONFIGURATION FILE (template) *********
# **********************************************************************
# ******* Note: This file MUST be edited before it can be used. ********
# * For complete details about package parameters and how to set them, *
# *** consult the ServiceGuard manpages or your ServiceGuard manual. ***
# **********************************************************************
# Enter a name for this package. This name will be used to identify the
# package when viewing or manipulating it. It must be different from
# the other configured package names.
PACKAGE_NAME <pkg1.oc>
# Enter the names of the nodes configured for this package. Repeat
# this line as necessary for additional adoptive nodes.
# Order IS relevant. Put the second Adoptive Node AFTER the first
# one.
# Example : NODE_NAME original_node
# NODE_NAME adoptive_node
# Enter the complete path for the run and halt scripts. In most cases
# the run script and halt script specified here will be the same script,
# the package control script generated by the cmmakepkg command. This
# control script handles the run(ning) and halt(ing) of the package.
# If the script has not completed by the specified timeout value,
# ServiceGuard will terminate the script. The default for each script
Chapter 8 211
# timeout is NO_TIMEOUT. Adjust the timeouts as necessary to permit

# full execution of each script.
# Note: The HALT_SCRIPT_TIMEOUT should be greater than the sum of
# all SERVICE_HALT_TIMEOUT specified for all services.
RUN_SCRIPT /etc/cmcluster/pkg1/ss7pkg.cntl
RUN_SCRIPT_TIMEOUTNO_TIMEOUT
HALT_SCRIPT /etc/cmcluster/pkg1/ss7pkg.cntl
HALT_SCRIPT_TIMEOUTNO_TIMEOUT
# Enter the name of the service, the SERVICE_FAIL_FAST_ENABLED value

# and the SERVICE_HALT_TIMEOUT value for this package. Repeat these
# three lines as necessary for additional service names. All service
# names MUST correspond to the service names used by cmrunserv and
# cmhaltserv commands inside the run and halt scripts.
# The default for SERVICE_FAIL_FAST_ENABLED is NO. If set to YES,
# in the event of a service failure, ServiceGuard will halt the node
# on which the service is running. Adjust as necessary.
# The default for SERVICE_HALT_TIMEOUT is 300 seconds (5 minutes).
# In the event of a service halt, ServiceGuard will first send out
# a SIGTERM signal to terminate the service. If the process is not
# terminated, ServiceGuard will wait for the specified timeout before
# sending out the SIGKILL signal to force the process termination.
# Adjust the timeout as necessary to allow enough time for any
# cleanup process associated with the service to complete.
SERVICE_NAME <serviceName_1(eg.ss7GuardianAngel)>
SERVICE_FAIL_FAST_ENABLED <NO>
SERVICE_HALT_TIMEOUT <30>
SERVICE_NAME <customerApplicName>
SERVICE_FAIL_FAST_ENABLED <NO>
SERVICE_HALT_TIMEOUT <30>
# Enter the network subnet name that is to be monitored for this package.
# Repeat this line as necessary for additional subnet names.
#SUBNET <subnetName_1(eg. 0.0.0.0)>
# The default for PKG_SWITCHING_ENABLED is YES. In the event of a

# failure, this permits ServiceGuard to transfer the package to an
# adoptive node. Adjust as necessary.
212 Chapter 8
PKG_SWITCHING_ENABLED <YES>
# The default for NET_SWITCHING_ENABLED is YES. In the event of a

# failure, this permits ServiceGuard to switch LANs locally (transfer
# to a standby LAN card). Adjust as necessary.
NET_SWITCHING_ENABLED <YES/NO>
# The default for NODE_FAIL_FAST_ENABLED is NO. If set to YES,

# in the event of a failure, ServiceGuard will halt the node on
# which the package is running. Adjust as necessary.
NODE_FAIL_FAST_ENABLED <NO>
Chapter 8 213
Package Control Script

Run this script as a service to the user application. The environment
variables which are uncommented should not be changed; uncomment
those with comments if you need to set them. Specify the UNIX path of
the executable for each service.
Generating the file Use the command cmmakepkg -s to generate this file. See the man page
cmmakepkg(1M) for a description.
Configuring the The customizable values are shown in bold in the example below.
file
# **********************************************************************
# * *
# * ServiceGuard PACKAGE CONTROL SCRIPT (template) *
# * *
# * Note: This file MUST be edited before it can be used. *
# * *
# **********************************************************************
# UNCOMMENT the variables as you set them.

# Set PATH to reference the appropriate directories.
PATH=/sbin:/usr/bin:/usr/sbin:/etc:/bin:/opt/OC/bin
# Volume groups, Logical volumes, and File systems.

# NOTE: VG, LV, and FS are members of an array and must be set in groups of
# three. These variables are only for logical volumes that you wish to mount.
# All the file systems must be of the same type.
# Example: VG[0]=vg01, LV[0]=/dev/vg01/lvol1, FS[0]=/pkg1
# Example: VG[2]=pkg2, LV[2]=/dev/pkg2/lvol1, FS[2]=/pkg2
#VG[0]=
#LV[0]=
#FS[0]=
# ACTIVATION mode: The default is to activate volume groups in exclusive mode.

# This assumes the volume groups have been initialized with `vgchange -c y'
# at the time of creation.
# For the ability to recover from both Node and disk fault, if your disk are
# mirrored on separate physical paths, uncomment the first line and comment out
# the default.
# If you wish to use
non-exclusive activation mode, then uncomment the second
# line and comment out the default.
#VGCHANGE="vgchange -a e -q n"
#VGCHANGE="vgchange -a y"
214 Chapter 8
VGCHANGE="vgchange -a e" # Default
# IP/Subnet address pairs for each IP address you want to add to a subnet
# interface card. Must be set in pairs, even for IP addresses on the same
# subnet.
# Hint: Run "netstat -i" to see the available subnets in the Network field.
# Example: IP[0]=182.10.25.12
# Example: SUBNET[0]=182.10.25.0 # (netmask=255.255.255.0)
#IP[0]=
#SUBNET[0]=
# Service names and commands.
# Note: No environmental variables will be passed to the command, this
# includes the PATH variable. Absolute path names are required for the
# service command definition. Default shell is sh.
#
# Service[0] must always be pkgOCSS7.ss7 and SERVICE_CMD[0] must not be
# changed
#
SERVICE_NAME[0]=SS7GuardianAngel
SERVICE_CMD[0]=”/etc/cmcluster/pkg5/startSS7GuardianAngel”
SERVICE_NAME[1]=pkgOCSS7.customerApplic
SERVICE_CMD[1]="/opt/customerApplicDir/customerApplicExecutable"
# DTC manager information for each DTC.

# Example: DTC[0]=dtc_20
#DTC_NAME[0]=
# LINK LEVEL address switching for devices that do not communicate at the IP
# address level.
# REQUIRES a interface card that does not have an IP address associated with it.
# ONLY for MAC address switching between Nodes.
# The Network Management ID (NM_ID) is the number return by lanscan in the
# NameUnit field.
# Example: ORIG_MAC_ADDRESS[0]=0800099634B3
# Example: MAC_ADDRESS[0]=080009963ABC
# Example: NM_ID[0]=1
#ORIG_MAC_ADDRESS[0]=
#MAC_ADDRESS[0]=
#NM_ID[0]=
# START OF CUSTOMER DEFINED FUNCTIONS
# This function is a place holder for customer define functions.

# You should define all actions you want to happen here, before the service is
# started. You can create as many functions as you need.
Chapter 8 215
function customer_defined_run_cmds
{
# ADD customer defined run commands.
: # do nothing instruction, because a function must contain some command.
}
# This function is a place holder for customer define functions.
# You should define all actions you want to happen here, before the service is
# halted.
function customer_defined_halt_cmds
{
# ADD customer defined halt commands.
: # do nothing instruction, because a function must contain some command.
}
# END OF CUSTOMER DEFINED FUNCTIONS
# the rest of the script must be taken from standard template.
216 Chapter 8
SS7 Tools The command:

SERVICE_CMD[0]=/”etc/cmcluster/pkg5/startSS7GuardianAngel”
needs the following script (or a similar one):
#Script Name : startSS7GuardianAngel
echo starting SS7GuardianAngel

/opt/OC/bin/SS7GuardianAngel -c SS7_Stack
echo SS7GuardianAngel terminated
Chapter 8 217
Working with HP OpenCall SS7 Platforms running the SS7Guardian Kit
Working with HP OpenCall SS7 Platforms

running the SS7Guardian Kit
How to start The kit is started automatically each time MC/ServiceGuard is started,
SS7Guardian Kit using the standard MC/ServiceGuard startup commands.
Prerequisites • MC/ServiceGuard cluster and package definition and

HP OpenCall SS7 configurations are correct. Check both
configurations before running the cluster. For more information on
MC/ServiceGuard, see the HP MC/ServiceGuard documentation.
Starting the HP OpenCall SS7 Platform
CTRL-C Command The SS7GuardianAngel and SS7GuardianSwitch scripts are designed to

run permanently as daemons. They do not respond to the CTRL-C
command, which is used to re-load the file debug.conf. Use of
debug.conf is reserved for HP personnel only.
218 Chapter 8
Managing Conflicts in Failure Detection: Principles

This section describes how the SS7Guardian Kit resolves the behavior
conflicts between MC/ServiceGuard and HP OpenCall SS7 in the
following failure situations:
• User Application Failures

• SS7 Stack Failures
LAN Failures In both MC/ServiceGuard and HP OpenCall SS7 architectures,

components are duplicated to avoid single points of failure.
However, there is still the possibility of a network failure, such as both
LANs failing. This affects:
• traffic between the two HP OpenCall SS7 hosts

• traffic between HP OpenCall SS7 and the user application
NOTE Dual LAN failure is a situation which is not supported by

HP OpenCall SS7. The platform tries to keep the service up and running,
but this situation may lead to a complete service loss in certain cases.
Chapter 8 219
SS7 Stack Failure These are failures where HP OpenCall SS7 and the user applications
reside on the same (FE) host.
These are failures due to process termination or process hang.
The following table shows how MC/ServiceGuard, HP OpenCall SS7 and
the SS7Guardian Kit react.
Table 8-1 SS7 Stack Failure Handling
Reaction of Reaction of Resolution by SS7Guardian

MC/ServiceGuard HP OpenCall SS7 Kit
There is no reaction from When the SS7 Stack goes The utility “SS7GuardianAngel”
MC/ServiceGuard because the DOWN (either due to a problem in the SS7Guardian Kit triggers
active and hotstandby stacks or due to operator intervention), the MC/ServiceGuard failure
are managed by HP OpenCall SS7 activates the mechanism, which switches
HP OpenCall SS7. standby SS7 Stack on the other over the user applications when
host. the SS7 Stack fails.
However, the user application SS7GuardianAngel runs as a
may continue to run on the service to the user application
original host, if designed to do package and examines the
so. The operator may prefer to status of the local SS7 Stack. It
have all linked applications exits on the host where the SS7
running on the same active Stack dies (goes to the DOWN
host. state).
When it dies,
SS7GuardianAngel provokes a
switchover of those user
applications configured to be
part of the same
MC/ServiceGuard package as
itself. This ensures that the
user application follows the SS7
Stack when it switches over.
See the man page SS7GuardianAngel.
220 Chapter 8
User Application These are failures where HP OpenCall SS7 and the user applications
Failure reside on the same (FE) host.
These are failures due to process termination.
The following table shows how MC/ServiceGuard, HP OpenCall SS7 and
the SS7Guardian Kit react.
Table 8-2 User Application Failure Handling
Reaction of Reaction of Resolution by SS7Guardian

MC/ServiceGuard HP OpenCall SS7 Kit
When the User Application The SS7 Stack continues to run The utility
stops (either due to a problem on the original host. The “SS7GuardianSwitch” in the
or due to operator intervention) operator may prefer to have all SS7Guardian Kit triggers a
on one host, MC/ServiceGuard linked applications running on switchover of the SS7 Stack in
transfers the application to a the same host. the event of user application
secondary host if the exit value failure.
is known. The control of the
SS7GuardianSwitch must be
transfer can be done by testing
run once when the user
the exit value of the application
application fails.
— that is, the UNIX process—
on the MC/ServiceGuard script. For example, the user
application can be started using
a shell script which will chain
two executables: the application
executable and the
SS7GuardianSwitch.
See the man page SS7GuardianSwitch.
Chapter 8 221
Failure Detection
The following tables describe how MC/ServiceGuard and
HP OpenCall SS7 react to failure detection.
Host Failure
Table 8-3 Host Failure: hardware, system panic or system hang
MC/ServiceGuard HP OpenCall SS7
Detection Action Detection Action
Heartbeat: • LAN transfers Heartbeat: • Activate Host

to other LAN Standby
• Minimum frequency = card • Default frequency = application
1 sec 0.5 sec
• Rebuild cluster
• Minimum timeout = 2 (get cluster • Default timeout = 2
x frequency lock) sec
• Transfer
package
Network Failure
Table 8-4 Network Failure: cable disconnection, LAN card failure,

termination loss
Heartbeat: • Rebuild cluster Heartbeat: LAN switch

(get cluster
• Default frequency = 1 lock) • Default frequency =
sec 0.5 sec
• Transfer
• Default timeout = 2 package • Default timeout = 2
sec sec
LAN polling:
• Link-level messages to
all other interfaces in
the cluster (primary
and secondary)
222 Chapter 8
Process Failure
Table 8-5 Process Failure: termination, process hangs
Standard UNIX If the exit value is Process heart beat: • Activate

parent/child relationship. known, the corresponding
The cmcld daemon is package will be • Default frequency = Host Standby
aware of the death of all transferred to a 1sec application
its child processes secondary node group, and
• Default timeout = 10
sec restart locally
If the exit value is
on Standby
unknown, transfer
host.
is disabled or times
out
Other Failure
Table 8-6 Other Failure: disk
Failure can be detected by If the service is via the SS7 Stack • Activate
package service failure, if flagged to fail-fast, Standby
it has been defined the application is application.
be transferred and
the primary node
halted
Chapter 8 223
Expected Behavior
The following tables give the platform state before and after the detected
failure.
Host Failure
Table 8-7 Platform State before and after Active Failure
Process Before Failure After Failure
Host 1 Host 2 Host 1 Host 2
MC/ServiceGuar Running Running Running

d
FTC Running Running Running
SS7 Stack Active Host Standby Active
Customer Running Running (started

Application by
MC/ServiceGuar
d)
Table 8-8 Platform State before and after Standby Failure
MC/ServiceGuar Running Running Running

d
FTC Running Running Running
SS7 Stack Active Host Standby Active
Customer Running Running

Application
SS7 Stack Failure Either:
• SS7 Stack problem, or
224 Chapter 8
• SS7 Stack stopped by operator intervention.

Table 8-9 Platform State before and after SS7 Stack Failure
MC/ServiceGuard Running Running Running Running
FTC Running Running Running Running
SS7 Stack Active Host Standby Down Active
Customer Running Down: Running:

Application
stopped by started by
MC/ServiceGuar MC/ServiceGuar
d if configured d if configured
for non-mixed for non-mixed
mode mode
Chapter 8 225
226 Chapter 8
9 Configuring the PIC/AG
This appendix describes how to configure the HP OpenCall PIC/AG

(Plug-In Container/Application Guardian).
Chapter 9 227
Configuring the PIC/AG
Configuration Basics
Configuration Basics
Global Name for Plug-In Process

The same name should be used for the plug-in process in different
configuration steps. This is called the plug-in global name and it must
be unique on the platform.
Naming Convention for Plug-In Server Names

Plug-In servers can be addressed directly using the following format:
<port>@<IP_address>
More generally, the format is as follows:
<first part>@<second part>
The “@” character is the separator between the two parts and is
mandatory. Consequently, it should not appear in either part.
The first part resolves to a port, and it must be unique in /etc/services
(both its name and its number). See also “Configuring Entries in
/etc/services” on page 231.
The second part must always resolve to the IP address of the local host,
since the plug-in runs on the FE (Front-End) server of the HP OpenCall
platform. The PIC configuration allows you to specify the second part of
the name (that is, the IP address part).
228 Chapter 9
Overview of Configuration
Overview of Configuration
Prerequisites
Before configuring PIC/AG, HP OpenCall SS7 must have been installed.
PIC/AG is installed during the installation of HP OpenCall SS7. See
Chapter 2 “Installing the HP OpenCall SS7 Software”.
Configuration Steps
Configuring the HP OpenCall PIC/AG contains the following steps:
Step 1. Configure PIC for a particular user plug-in (shared library).
Step 2. Configure the entries in /etc/services file, if needed.
Step 3. Configure the user plug-in (shared library), if needed.
Step 4. Include the plug-in processes in the HP OpenCall environment.
Detailed information is given in the following sections.
Chapter 9 229
Configuring PIC
Configuring PIC
This must be done using SAM or the cfgPic command. For more details,
see the SAM online help or the cfgPic man page.
PIC Internal Parameters

Each PIC instance needed by a user plug-in must be configured. These
parameters are stored in a configuration file. This file contains internal
setup and configuration information.
There is one such file for each PIC. Therefore, you must choose a
different name for each PIC. The PIC configuration file is defined as:
<plug-in global name>.conf
where <plug-in global name> is as described in “Global Name for Plug-In
Process” on page 228.
There is an example configuration file in the Plug-In configuration
directory.
HA Parameters
These parameters define ports (peer-to-peer and FTC) and heartbeats
(frequency, time-out period, etc.).
On a 2-host platform, the HeartBeatWithPeer parameter must be set to
“YES” for each PIC process so that the corresponding standby process is
started correctly.
Pre-Defined Plug-Ins (AG_x)

In HP OpenCall SS7, 4 plug-in processes are pre-defined.
Their plug-in global names are: AG_1, AG_2, AG_3, and AG_4.
A configuration is proposed to the user. To use these pre-defined plug-ins,
you must supply values for all the mandatory parameter (for example,
the user plug-in shared library path).
You can view these configurations using SAM or the cfgPic -view
<AG_x> command. You can create more plug-ins (in addition to the
pre-defined ones).
230 Chapter 9
Configuring Entries in /etc/services
Configuring Entries in /etc/services

The <port numbers> used in the user plug-in (shared library) name must
be registered in the /etc/services file.
The TCP ports for the pre-defined plug-ins, described in “Pre-Defined
Plug-Ins (AG_x)” on page 230, are already present in the /etc/services
file.
The following entries are automatically added in the /etc/services file:
ha_ag_1 6639/tcp # HP Opencall Plugin
ha_hb_ag_1 6784/tcp # HP Opencall Plugin
If other plugins are added, more tcp ports must be defined by the user.
For example:
Any Plug-In
For all plug-ins:
ha_plugin_1 12345/tcp # HP Opencall Plugin - FTC HA management port
Plug-In Using the Active/Standby Model

If the plug-in uses the Active/Standby Model and needs peer heartbeats:
ha_hb_ag_1 12346/tcp # HP Opencall Plugin - peer Plugin Heartbeats port
Plug-In Implementing PCA Server

If the plug-in implements a PCA server:
pca_server_plugin_1 12347/tcp # HP Opencall Plugin PCA server port
Chapter 9 231
Configuring the User Plug-In
Configuring the User Plug-In

This includes configuring any facilities needed by the user plug-in
(shared library) and creating the user plug-in’s own configuration file (if
it uses one).
This operation completely depends on the nature of the user’s
application.
It is not described in this guide.
232 Chapter 9
Including the Plug-In Processes in the HP OpenCall Environment
Including the Plug-In Processes in the HP

OpenCall Environment
This is done using SAM. For more details, see the SAM online help.
The PIC Run String

During configuration, you specify the PIC run string.
The PIC executable run string contains the following arguments:
/opt/OC/bin/PluginContainer[<trace>] -c <file> [-E] [-N]
where:
trace Specifies the name of the section in debug.conf to be
used by this PIC. The default name is PlugIn.
-c <file> Specifies the user plug-in configuration file. The file
name may include the path to access the configuration
file. This argument is mandatory.
-E If set, exit on initialization error. By default, do not
exit.
-N If set, the PIC Process is not HA. By default, the
process is HA.
Chapter 9 233
Including the Plug-In Processes in the HP OpenCall Environment
Declaring the PIC Process as HA or Not

Each user plug-in (shared library) must be added for startup and
configured as a respawnable (RS) or an active/standby (HA) process.
Note that:
• A PIC process declared as HA (that is, HA or HN) must be launched

without the argument -N in the run string.
• A PIC process declared as not HA (that is, RS or RO) must be
launched with the argument -N in the run string:
/etc/opt/OC/bin/PluginContainer ........ -N
• If a PIC process needs a lot of processing time, you should allocate it
to a dedicated processor using the PreferredProcessor attribute.
• You give the configuration file name (and path) as a mandatory
argument (using the “-c” option) on the PIC executable run string:
/etc/opt/OC/bin/PluginContainer ... -c <conf-file> .....
• To enable PIC tracing, you must include the <plug-in global name>
in the run string as follows:
/etc/opt/OC/bin/PluginContainer <plug-in global name> ...
NOTE The process class name should be the <plug-in global name> (see “Global
Name for Plug-In Process” on page 228), that is, the same as used in
configuring the PIC. This should also be the name under which the user
plug-in process will appear in the Platform Monitor window or the
ocftstatus command.
234 Chapter 9
10 Installing a New TSU
This chapter describes how to install a new Telecom Signaling Unit

(TSU) and its associated Telecom Signaling Cards (TSCs).
Chapter 10 235
Installing a New TSU
Overview
Overview
The installation procedures in this chapter are concerned with adding a
new Telecom Signaling Unit (TSU) to a new or existing (running)
platform. You can add a new TSU to a running platform without
disturbing the traffic.
If you wish to perform maintenance on an existing Telecom Signaling
Unit, refer to Chapter 11, “Maintaining Signaling Hardware.”
WARNING Before attempting the installation, refer to the HP OpenCall SS7

TSU and TSC Starter Sheet. This provides important
information, including regulatory information and conformance
statements.
Also read the safety notices in “Important Safety Precautions for
Hardware Installation” on page 18. Failure to do so may result in
damage to your hardware or to yourself.
The TSU/TSC installation procedure is described in Table 10-1,

“Overview of TSU Installation Procedure,” on page 237, where each
stage shown is detailed in a dedicated section.
236 Chapter 10
Overview
NOTE If you are installing a TSU in a new platform, perform Stages 1, 2 and 3
only. Do not configure the hardware, as you will do this as part of the
HP OpenCall SS7 software installation.
Table 10-1 Overview of TSU Installation Procedure
Stage Description Section Reference
1 Install your Telecom Signaling “Stage 1: Installing Cards in the TSU” on

Cards and LAN card into the TSU. page 238
2 Install the Telecom Signaling Unit “Stage 2: Installing the Telecom Signaling
into a server cabinet. Unit in the Server Rack” on page 240
3 Connect the TSU to the host(s). “Stage 3: Connecting the TSU to the
Platform” on page 243
4 Check and configure the hardware. “Stage 4: Checking and Configuring the
Hardware” on page 248
Chapter 10 237
Stage 1: Installing Cards in the TSU
NOTE This section describes how to intall cards into a new TSU.
If you wish to add an additional TSC to an existing TSU, or replace a
TSC or LAN card in an existing TSU, refer to Chapter 11, “Maintaining
Signaling Hardware.”.
When adding a new Telecom Signaling Unit to your platform, you must
first install the Telecom Signaling Cards and additional LAN card (if
required) into your unit. Note that the PCI slots available for the
different types of cards are as follows:
Table 10-2 PCI Slots in a TSU
Card Type PCI Slots
V.35 TSC 1 to 5
E1/T1 TSC 1, 3 and 5
LAN Card L1
NOTE Do not mix different Telecom Signaling Card types in a single TSU. To
use more than one TSC type with your platform, you must install each
TSC type in a separate TSU.
NOTE Slot L0 in the TSU is occupied by the system CPU card, which also
provides a LAN connection to the host. This card is supplied with the
TSU and cannot be removed. You only need to install an additional LAN
card (in slot L1) if the TSU is to be connected to the hosts in a 2-host
platform.
238 Chapter 10
If you need to add an additional LAN card to your host server(s) in order
to connect to the new TSU, refer to “Replacing, Moving or Adding a
Hardware Component in an MTP-Based Platform” on page 252.
WARNING Ensure that the TSU is powered OFF before installing cards.
Install the cards as described in the procedure below:
Step 1. Before handling the cards, take anti-static precautions by wearing a

grounding wrist strap.
Step 2. Remove the cover of the Telecom Signaling Unit, as described in

“Removing the TSU Cover” on page 300.
Step 3. Remove the card cage from the TSU, as described in “Removing the Card
Cage” on page 302.
Step 4. If you need to install an additional LAN card, insert the card into slot L1
in the TSU, as described in “Adding a Card to a TSU” on page 303.
If you wish to install a TSC in slot 5 (which is adjacent to slot L1), do this
(as described in Step 4) before securing the card brackets again.
Do NOT connect the LAN cards to the hosts yet.
Step 5. To install a TSC into the TSU, insert the TSC into an appropriate slot in
the TSU, as described in “Adding a Card to a TSU” on page 303.
Do NOT connect the network cables yet.
Step 6. Re-insert the card cage into the TSU, as described in “Replacing the Card
Step 7. Replace the cover of the TSU, as described in “Replacing the TSU Cover”
on page 301.
Chapter 10 239
Stage 2: Installing the Telecom Signaling Unit in the Server Rack
Stage 2: Installing the Telecom Signaling Unit

in the Server Rack
This section describes how to install your Telecom Signaling Unit (with
cards installed) into a server cabinet.
In order to work through the procedures of this installation, you will
need to refer to the diagram in Figure 10-1 below.
Figure 10-1 Sliding Rails, Brackets and Handles
240 Chapter 10
NOTE The installation described in this section also refers to an optional

connection panel. This is a metal panel that can be attached inside the
server cabinet to provide a convenient connection interface to the TSCs
within the TSU. Refer to “Connection Panels” on page 409.
To install your TSU in a server cabinet, follow the steps below:
Step 1. Install the ear brackets and handles on the front of the TSU.
Step 2. Install the cable guide for the TSU at the back of the unit.
Step 3. Install the sliding rails. The rails that you need depend on the type of
server rack in which the TSU is to be installed. For a Rosebowl I rack,
you need the rails with HP Part Number J3401-80202. For a Rosebowl II
or Seismic rack, you need the rails with HP Part Number J3401-80203.
a. Attach the captive nuts to the holes on each side of the server cabinet
at the height that you wish to install the TSU.
b. Screw the rail guides to the captive nuts in the cabinet, so that the
hole is at the rear of the cabinet (or at the front of the cabinet if you
have a CO cabinet). Install the rail guides with the lip side pointing
inwards. Note that for the rails with HP Part Number J3401-80203,
you must put the wedge and washer between the rails and the server
cabinet (not shown in Figure 10-1).
c. Attach the rails to each side of the TSU, with the lip facing away from
the box and with the stop at the rear of the box. To do this, align the
four holes on the rail with the four holes along the side of the TSU
and secure the rails to the box using the small screws provided.
Step 4. Slide the rails on the TSU into the rail guides in the cabinet and push
the TSU into the cabinet until the TSU is in place.
Step 5. Install the TSU’s optional connection panel in the cabinet:
a. Check that you have the correct connection panel:
• BNC grounded connection panels have round connector holes

with a flat top.
• BNC ungrounded connection panels have larger round connector
holes with a flat top.
Chapter 10 241
• RJ-45 connection panels have square connector holes.

• V.35 connection panels have rectangular connector holes.
b. Secure the connection panel to the cabinet at the same level as the
TSU.
242 Chapter 10
Stage 3: Connecting the TSU to the Platform

This section describes the connections that must be made to the TSU
(installed in a cabinet server) in order to check the installation.
NOTE This does NOT involve connecting the TSCs to the signaling network
(which must be left as the last task before the TSU is put into service).
NOTE For full details of the TSC connectors and cables required, refer to “TSC
Connectors and Cables” on page 390.
The subsections below describe the connection procedure and provide

cabling recommendations for connecting more than one TSU to the hosts
of a 2-host platform.
Connection Procedures
In order to work through the connection procedures in this section, you
may need to refer to the diagram in Figure 10-2 below. This shows the
connectors on the rear panel of the TSU. These include the TSC
connectors (for connection to the signaling network), the LAN card
connectors (for host connections), as well as the power supply connectors.
Figure 10-2 TSU Rear Panel Connectors (AC Powered TSU)
Chapter 10 243
NOTE It is not possible to have a dual LAN connection between a TSU and a
single server.
All the steps described below apply to both 1-host and 2-host platforms,
unless marked as “2-host only”.
Connect to the To connect the TSU to the platform host(s):

Host(s)
Step 1. Using the 1.5 m LAN cable (HP Part Number: 5063-1358), connect TSU
slot L0 to the platform host contained in the same server cabinet as the
TSU.
Step 2. 2-host only: Using the 6.5 m LAN cable (HP Part Number: 5063-1359),
connect TSU slot L1 to the other platform host. Refer to “Cabling for
2-Host Platforms” on page 245 for advice on making host connections in
a 2-host platform.
Step 3. Label the cables, stating what they are (LAN) and where they connect to
(L0, L1).
Connect the TSC The TSC cables connect the TSCs to the signaling network. At this stage,
Cables you can connect the TSC cables at the platform end but must NOT
connect them at the network end. To do this:
Step 1. Connect the cables to the TSU. If you are using the optional connection
panel, connect the network end of the cables to the rear of the connection
panel.
Step 2. Label the cables, stating what they are (E1, T1, V.35) and where they
connect to (TSC1, TSC2 and so on).
CAUTION Do NOT connect the TSC cables at the network end yet.
Connect to the Now power on the TSU by connecting it to a suitable power outlet. The
Power Supply unit can be powered from an AC or DC supply. Refer to “TSU Electrical
and Environmental Specifications” on page 419 for details of the
required power supply.
244 Chapter 10
Cabling for 2-Host Platforms

The cabling instructions below allow you to determine your TSU Id
settings.
Follow these instructions to ensure the TSU Ids are set in the order that
the LANs are picked by SAM during the Create Initial Configuration
action.
• The HSC/PCI LAN cards must use the same slots in the two systems;
and have the same hardware path.
• The HSC/PCI LAN ports connected to the same TSU must have the
same hardware path on the two hosts.
• On each system, half of the TSUs must be connected to the LAN port
provided by the core I/O LAN card of the TSU. The other half must be
provided by the LAN port on the add-on LAN card.
• You should also make a note of the hardware LAN path and MAC
address associated with each TSU, and note this on the backplane in
the space provided.
The diagram in Figure 10-3 shows an example for two TSUs on a 2-host
platform.
Chapter 10 245
Cabling Example
This example shows a 2-host platform with Two TSUs.
TSU 0 is in Rack 1 and TSU 1 is in Rack 2.
Figure 10-3 Cabling Example for Two TSUs
RACK 1 RACK 2
1 1
Same hardware paths*
2 2
Cable A
Cable A Cable B Cable C
1 10/8/1/0 1
Same hardware paths Cable C
2 2
Cable D 10/8/2/0*
LAN Id 0 LAN Id 0 LAN Id 1 LAN Id 1

*Each port in the system
has the same hardware
TSU 0 path in the other system. TSU 1
100BaseT
100BaseT
LAN card LAN card
1
Core I/O LAN card
Host LAN card Core I/O LAN card
2
Running ss7TsuPing gives:

LAN [?:?] : 10/8/1/0
LAN [?:?] : 10/8/2/0
246 Chapter 10
Table 10-3 below details the cabling connections in the Figure 10-3.
Table 10-3 Cabling Connections for Two TSUs
Cable Description
A Connects the core I/O LAN port of the TSU in Rack 1 to

port 10/8/1/0 of the system in Rack 1
B Connects the 100BaseT LAN port of the TSU in Rack 1 to

C Connects the core I/O LAN port of the TSU in Rack 2 to

D Connects the 100BaseT LAN port of the TSU in Rack 2 to

Chapter 10 247
Stage 4: Checking and Configuring the Hardware
Stage 4: Checking and Configuring the

Hardware
NOTE You must only work through this stage when installing a new TSU in an
existing platform (not when installing a TSU in a new platform).
NOTE At this stage, your TSU should be connected to the platform host(s) and
be powered on. The TSC cables should NOT yet be connected to the
signaling network.
Checking the Hardware Installation

Follow the procedure below to check that the hardware you have
installed is operating correctly.
Step 1. Power on the TSU.
Step 2. Check the LEDs on the TSU and the TSCs. See “Checking LEDs” on
page 309 for information on the LEDs and their meaning.
Step 3. Check that the TSU and TSCs are reachable by running
ss7TsuPing -v
Configuring the Hardware

Once you have checked your hardware installation, you must define the
configuration for your TSU. This includes details of the TSU, TSCs, ports
and links. The configuration must then be installed on the host
machine(s). This is described in the section “TSU Configuration: Adding
a New TSU to an Existing Platform” on page 318.
248 Chapter 10
11 Maintaining Signaling
Hardware
This chapter details the maintenance procedures that you may need to
perform on your TSU or your TSC-in-system server.
Chapter 11 249
Maintaining Signaling Hardware
Overview
Overview
The maintenance procedures provided in this chapter are listed in the
table below along with references to the relevant sections.
Description Section Reference
How to add, replace or remove a hardware “Replacing, Moving or Adding a Hardware

component of a host server (such as a CPU, Component in an MTP-Based Platform” on
LAN card etc.) in an MTP-based platform. page 252
How to add, replace or remove a hardware “Replacing, Moving or Adding a Hardware

component of a host server (such as a CPU, Component in an M3UA-Based Platform”
signaling LAN card etc.) in an M3UA-based on page 254
platform.
How to replace a faulty fan in a TSU. “Replacing a Fan in a TSU” on page 256
How to replace an AC power supply in a “Replacing a TSU AC Power Supply

TSU (J3401-60100)” on page 259
How to replace a DC power supply in a TSU “Replacing a TSU DC Power Supply

(J3401-60200)” on page 262
How to replace a faulty TSU card cage that “Replacing the TSU Backplane and CPU
contains the PCI backplane and CPU card. Card” on page 265
How to replace an add-on LAN card (for a “Replacing a LAN Card in a TSU” on
2-host platform) in a TSU. page 271
How to add a new Telecom Signaling Card “Installing an Additional TSC in a TSU” on
to a TSU. page 275
How to replace a Telecom Signaling Card in “Replacing a TSC in a TSU” on page 277
a TSU.
How to remove a Telecom Signaling Card “Removing a TSC from a TSU” on page 281
from a TSU (without replacing it).
How to replace a Telecom Signaling Unit. “Replacing a TSU” on page 285
How to remove a Telecom Signaling Unit “Removing a TSU from a Platform” on

from a platform. page 289
250 Chapter 11
Overview
Description Section Reference
How to add a new Telecom Signaling Card “Installing a TSC in a Host Server” on
to a host server. page 291
How to replace a Telecom Signaling Card in “Replacing a TSC in a Host Server” on

a host server. page 293
How to remove a Telecom Signaling Card “Removing a TSC from a Host Server” on
from a host server (without replacing it). page 296
How to replace a 4-port TSC cable that “Replacing a Four-Port TSC Cable” on
connects a Telecom Signaling Card to the page 299
SS7 network.
NOTE Some of the above procedures refer to other procedures. For easy access,
these sub-procedures have been collected together in the last section of
this chapter, “Common TSU/TSC Procedures” on page 300.
WARNING It is important that you read the safety and anti-static notices
provided in “Important Safety Precautions for Hardware
Installation” on page 18 before attempting to follow any of the
maintenance procedures described in this chapter. Failure to do
so may result in damage to your hardware or to yourself.
Also ensure that you save your platform configuration, as
described in “Saving Your Platform Configuration” on page 19.
Chapter 11 251
Replacing, Moving or Adding a Hardware Component in an MTP-Based Platform
Replacing, Moving or Adding a Hardware

Component in an MTP-Based Platform
This procedure describes how to proceed if you want to replace a
hardware component of a host (card, disk array, PDU, CPU, and so on). It
can be used for any actions requiring the shutdown of a host. It explains
how to safely perform a switchover on a 2-host platform.
NOTE This procedure does not apply to replacing, adding or removing TSCs in a
host server. For these procedures, refer to the relevant sections in this
chapter.
NOTE Although this procedure does not disturb the traffic on a 2-host platform,
it stops all the traffic of a 1-host platform.
In this procedure, host A is stopped, and host B is the remaining host if

the platform is 2-host. Except for step 3, which must be done as root, all
the following steps can be done as root or ocadmin.
Step 1. Carry out the following checks for 2-host platforms.
a. Check the state of the hardware on host B. Run ss7TsuPing -v and

check the state of the LANs of host B, and the state of the TSUs (if
wrongly configured, the stack will not switch).
b. Check the stacks on host B are active or hot-standby.
c. Using the Platform Monitor, make sure active stacks are running on
host B, or switch the stacks active on host A to host B. To launch the
Platform Monitor, run the command ss7MgrStart on the Platform
Manager or on host B.
d. Still in the Platform Monitor, check that the global state of host A is
standby.
Step 2. Stop HP OpenCall on host A: ss7Stop -all.
Step 3. As root, shutdown host A.
252 Chapter 11
Replacing, Moving or Adding a Hardware Component in an MTP-Based Platform
Step 4. Replace, remove or add the hardware component:
a. Power off host A.

b. Replace, remove or add the hardware element. See the server
documentation.
c. Power on host A.
d. Check the installation of the hardware element. See the server
documentation
Step 5. Start HP OpenCall SS7 on host A by running the command ss7Start.
Note that the Destination Point Code platform must also be running.
Step 6. Check the state of the hardware by running ss7TsuPing -v on a

front-end host. In particular, check the state of the LANs for TSC-in-TSU
platforms, and the state of the TSCs for TSC-in-system platforms.
Checks For a 2-host platform, check the synchronization of the stack using the
Platform Monitor on any host.
For a 1-host platform, check the state of the links using SS7 Monitor on
the Platform Manager or on the host. In the SS7 Monitor screen, select
Monitor Entities|Monit MTP|Monit lk/lkset. Check that the links
are active
Results All hardware elements are active, and the stack(s) are up. On 2-host
platform, the active host is host B
Rollback Repeat the procedure, reversing your actions in Step 4.
Chapter 11 253
Replacing, Moving or Adding a Hardware Component in an M3UA-Based Platform
Replacing, Moving or Adding a Hardware

Component in an M3UA-Based Platform
This procedure describes how to proceed if you want to replace a
hardware component of a host (card, disk array, PDU, CPU, and so on). It
can be used for any actions requiring the shutdown of a host. It explains
how to safely perform a switchover on a 2-host platform.
NOTE Although this procedure does not disturb the traffic on a 2-host platform,
it stops all the traffic of a 1-host platform.
In this procedure, host A is stopped, and host B is the remaining host if

the platform is 2-host. Except for step 3, which must be done as root, all
the following steps can be done as root or ocadmin.
Step 1. Carry out the following checks for 2-host platforms.
a. Check the stacks on host B are active and processing traffic.

b. Check in the logs that there are no failures on the Host B OpenCall
LANs (if wrongly configured, the stack will not switch).
Step 2. Stop HP OpenCall on host A: ss7Stop -all.
Step 3. As root, shutdown host A.
Step 4. Replace, remove or add the hardware component:
a. Power off host A.

b. Replace, remove or add the hardware element. See the server
documentation.
c. Power on host A.
d. Check the installation of the hardware element. See the server
documentation
Step 5. Start HP OpenCall SS7 on host A by running the command ss7Start.
Checks Ensure that connection to the IP signaling network is valid by following

the procedure in “Validating IP Connectivity for M3UA” on page 167.
254 Chapter 11
Replacing, Moving or Adding a Hardware Component in an M3UA-Based Platform
Results All hardware elements are active, and the stack(s) are up. On 2-host
platform, the active host is host B
Rollback Repeat the procedure, reversing your actions in Step 4.
Chapter 11 255
Replacing a Fan in a TSU
CAUTION A faulty fan should be replaced as soon as possible. The TSU can operate
without one fan, but to maximize the life of the TSU you must replace
the faulty fan without delay.
NOTE You can replace a fan without powering off the TSU or removing the TSU
from the server cabinet.
256 Chapter 11
Before you can replace a fan, you need to remove the frontplate of the
TSU. Figure 11-1 and Figure 11-2 below show the front view of the TSU
with and without the frontplate, respectively.
Figure 11-1 TSU with Frontplate
Figure 11-2 TSU with Frontplate Removed to Show Fans
To replace a fan, follow the procedure below:
Step 1. Remove the frontplate of the TSU, as follows:
a. Unscrew and remove the two screws on either side of the frontplate.
You will need a Philips screwdriver.
b. Pull the frontplate away from the chassis.
Step 2. Disconnect the fan’s connector. If you are replacing a fan for the power
supply section (fan 1 or 2), you must disconnect the connectors for both
fans 1 and 2.
Chapter 11 257
Step 3. Unscrew and remove the four screws that hold the fan in place. You will
need a Philips screwdriver.
Step 4. Remove the fan.
Step 5. Insert the replacement fan.
NOTE Make sure that you use a replacement fan of the correct size (60mm or
80mm), and that you install it the right way up and the right way around
(with the arrow at the front).
Step 6. Replace and tighten the four screws.
Step 7. Reconnect the fan’s connector (if you have replaced fan 1 or 2, remember
to reconnect the connectors for both fans 1 and 2).
Step 8. Replace and secure the frontplate.
Step 9. Make sure that the Fan Fault warning LED goes off.
258 Chapter 11
Replacing a TSU AC Power Supply (J3401-60100)
Replacing a TSU AC Power Supply

(J3401-60100)
A procedure is presented below for replacing an AC power supply in a
TSU. It is possible to replace a TSU power supply on a running platform
without disturbing the traffic.
CAUTION This procedure should be performed by HP support personnel. If you

wish to perform the procedure yourself, first contact your HP
representative.
CAUTION The following procedure involves disconnecting the TSU from the SS7
network. The HP OpenCall SS7 platform will therefore lose network
links. However, depending on the platform, it may be possible for the
traffic that uses these links to be redirected via other links. Do this in
consultation with the personnel responsible for operating the platform.
WARNING Be sure to power off the TSU when instructed to do so.
Step 1. If the platform has more than one TSU, divert the traffic from the TSU
that you are going to work on. To do this, refer to “Diverting Traffic” on
page 316.
If you have a 1-host platform with only one TSU, stop HP OpenCall SS7
by logging in as root on the host and running ss7Stop -all. As a
result, all traffic will be stopped.
Step 2. Take anti-static precautions by wearing the grounding wrist strap.
Step 3. Power off the TSU.
Step 4. Disconnect all cables from the rear panel of the TSU and from the SS7
network.
Chapter 11 259
Step 5. Remove the TSU from the server cabinet, as described in “Removing the
TSU from the Server Cabinet” on page 300.
Step 6. Remove the cover of the TSU, as described in “Removing the TSU Cover”
on page 300.
Step 7. Remove the cover of the power supply unit.
Step 8. Disconnect the power connector (the large white connector) from the
power supply unit.
Step 9. Disconnect the J10 connector which is behind the front panel of the TSU.
Step 10. Disconnect and remove the on/off power input module from the rear
panel. To do this, you will have to remove the wires that connect the
module to the power supply unit.
Step 11. Unscrew the two screws on the rear power supply bracket with a Philips
screwdriver.
Step 12. Remove the power supply unit; slide the power supply bracket forward
towards the frontplate to disconnect the keyhole standoffs, then lift it off.
Step 13. Insert the new power supply unit; line up the keyhole standoffs on the
bottom of the new power supply bracket with those on the cage and slide
the power supply into place.
Step 14. Secure the two screws on the rear power supply bracket with a Philips
screwdriver.
Step 15. Connect and install the new on/off power input module on the rear panel.
To do this, you will have to connect the module to the power supply unit
(to help you, both the wires and the screw terminals are labelled).
Step 16. Reconnect the J10 connector.
Step 17. Reconnect the (white) power connector to the power supply unit.
Step 18. Replace the cover of the power supply unit.
on page 301.
Step 20. Insert the TSU back into the server cabinet, as described in “Stage 2:
Installing the Telecom Signaling Unit in the Server Rack” on page 240.
Step 21. Reconnect all cables to the rear panel of the TSU, but do NOT reconnect
any TSC cables at the network end yet.
260 Chapter 11
Step 22. Power on the TSU and check the LEDs on the TSU and the TSCs. See
“Checking LEDs” on page 309 for information on the LEDs and their
meaning.
Step 23. Reconnect the TSC cables at the network end.
Step 24. If you have diverted the traffic from this TSU, you can now restore the
traffic to the TSU. To do this, refer to “Restoring the Traffic” on page 317.
If you have stopped HP OpenCall SS7, you can now restart it. To do this,
log in as root on the host and run ss7Start.
Rollback Perform the above procedure again to reinstall the old power supply.
Chapter 11 261
Replacing a TSU DC Power Supply (J3401-60200)
Replacing a TSU DC Power Supply

(J3401-60200)
A procedure is presented below for replacing a DC power supply in a
TSU. It is possible to replace a TSU power supply on a running platform

representative.
page 316.
network.
262 Chapter 11
on page 300.
Step 7. Remove the cover of the power supply unit.
Step 8. Disconnect the power connector (the large white connector) from the
power supply unit.
Step 9. Disconnect the power supply connector that is attached to the fan board
J8 connector.
Step 10. Disconnect and remove the on/off power input module from the rear
panel. To do this, you will have to remove the wires that connect the
module to the power supply unit.
Step 11. Unscrew the two screws on the rear power supply bracket with a Philips
screwdriver.
Step 12. Remove the power supply unit; slide the power supply bracket forward
towards the frontplate to disconnect the keyhole standoffs, then lift it off.
Step 13. Insert the new power supply unit; line up the keyhole standoffs on the
bottom of the new power supply bracket with those on the cage and slide
the power supply into place.
Step 14. Secure the two screws on the rear power supply bracket with a Philips
screwdriver.
Step 15. Connect and install the new on/off power connector on the rear panel. To
do this, you will have to connect the module to the power supply unit (to
help you, both the wires and the screw terminals are labelled).
Step 16. Reconnect the power supply connector J8 that is attached to the fan
board.
Step 17. Reconnect the (white) power connector to the power supply unit.
Step 18. Replace the cover of the power supply unit.
on page 301.
Chapter 11 263
Step 21. Reconnect all cables to the rear panel of the TSU, but do NOT reconnect
Step 22. Power on the TSU and check the LEDs on the TSU and the TSCs. See
“Checking LEDs” on page 309 for information on the LEDs and their
meaning.
Rollback Perform the above procedure again to reinstall the old power supply.
264 Chapter 11
Replacing the TSU Backplane and CPU Card

The TSU’s backplane and CPU card form part of the card cage. Replacing
the backplane and CPU card therefore involves replacing the card cage
kit. It is possible to replace a TSU card cage on a running platform

representative.
The steps of this procedure apply to both 1-host and 2-host platforms,
unless otherwise stated. You must be logged in as root or ocadmin on the
active host.
that you are going to work on. To do this, refer to the “Diverting Traffic”
on page 316.
Chapter 11 265
network.
on page 300.
Step 8. Transfer the TSCs and add-on LAN card (if present) from the existing
card cage to the replacement card cage. Refer to “Removing a Card from
a TSU” on page 306 and “Adding a Card to a TSU” on page 303 for help
with this procedure.
a. Transfer the add-on LAN card (if present) in slot L1 to slot L1 in the
replacement card cage.
b. Transfer the TSCs to their equivalent slots in the replacement card
cage.
Step 9. Insert the new card cage into the TSU, as described in “Replacing the
Card Cage” on page 303.
on page 301.
Step 12. Reconnect all cables to the rear panel of the TSU, but do NOT connect
Step 13. Power on the TSU and wait until the TSU has booted (approximately 2
minutes).
Step 14. Use the command ss7TsuPing -v -u <TSU_ID> to check that you can
reach the TSU that you are working on.
Step 15. Run the hardware replacement command ss7HwReplace. If the tool
returns an error, refer to the HP OpenCall SS7 Troubleshooting Guide.
When asked if you wish to load the updated configuration, answer yes.
266 Chapter 11
Do not accept changes now - move to another window to continue or quit

the tool - if you accept the changes, no rollback will be available.
Step 18. Configure the hardware. To do this, refer to “TSU Configuration:

Replacing the Backplane and CPU Card of a TSU” on page 324.
Rollback You should only perform this rollback when instructed to do so in the
procedure “TSU Configuration: Replacing the Backplane and CPU Card
of a TSU” on page 324.
page 316.
network.
on page 300.
Step 8. Transfer the TSCs and add-on LAN card (if present) back to the former
card cage. Refer to “Removing a Card from a TSU” on page 306 and
“Adding a Card to a TSU” on page 303 for help with this procedure.
Chapter 11 267
a. Transfer the add-on LAN card (if present) in slot L1 to slot L1 in the
former card cage.
b. Transfer the TSCs to their equivalent slots in the former card cage.
Step 9. Insert the card cage into the TSU, as described in “Replacing the Card
on page 301.
minutes).
Step 14. Rollback the configuration changes by carrying out either of the
following:
• run the command ss7HwRollback
• reject the updated configuration in the ss7HwReplace window.
268 Chapter 11
Installing an Additional LAN Card in a TSU

This section describes how to install an additional LAN card (HP Part
Number: D5013-60002) in a TSU, where this card is to be used to connect
the TSU to the second host of a 2-host platform.
NOTE The additional LAN card is installed in slot L1 in the TSU. Slot L0 is
occupied by the system CPU card, which also provides a host LAN
connection. This card is supplied with the TSU and cannot be removed.
links. Before starting, you must ensure that the traffic that uses these
links is redirected via other links. Do this in consultation with the
personnel responsible for operating the platform.
WARNING Power off the TSU before carrying out this procedure.
Step 2. Ensure that the TSU is powered off.
Step 3. Remove all cables from the rear panel of the TSU.
Step 4. Slide the TSU out on its rails until it blocks.
on page 300.
Step 7. Install the new LAN card in slot L1. Refer to “Adding a Card to a TSU”
on page 303 for help with this procedure.
Chapter 11 269
Note that if there is a TSC installed in slot 5, you will need to remove it
before you can gain access to slot L1. Do not forget to replace it!
on page 301.
Step 10. Slide the TSU on its rails back into the cabinet.
Step 11. Connect the TSU LAN cables to the host computers. Refer to “Cabling for
2-Host Platforms” on page 245 for guidance.
Step 12. Reconnect the power cable of the TSU but do NOT connect the TSC
cables (that connect to the signaling network) yet.
minutes).
Step 14. Check that the hardware has been installed correctly (refer to “Checking
the Hardware Installation” on page 248).
Step 15. Reconnect the TSC cables to the rear panel of the TSU in order to
reconnect to the signaling network.
Step 16. Configure the hardware. To do this, refer to “LAN Configuration:

Installing an Additional LAN Card in a TSU” on page 338.
270 Chapter 11
Replacing a LAN Card in a TSU

This section describes how to replace an add-on LAN card (HP Part
Number: D5013-60002), located in slot L1 in the TSU, which is used in a
2-host platform. It is possible to add a LAN card in a TSU on a running
platform without disturbing the traffic.
NOTE Slot L0 in the TSU is occupied by the system CPU card, which also
provides a host LAN connection. This card is supplied with the TSU and
cannot be removed. If there is a problem with this card, call your HP
representative.
You must be logged in as root or ocadmin on the active host.
page 316.
Chapter 11 271
on page 300.
Step 8. Remove the old LAN card from slot L1 and install the new card in its
place. Refer to “Removing a Card from a TSU” on page 306 and “Adding a
Card to a TSU” on page 303 for help with this procedure.
on page 301.
minutes).
Step 14. Use the command ss7TsuPing -v to see the new MAC address of the
replacement LAN card.
When asked if you wish to load the updated configuration, answer

affirmatively.

272 Chapter 11
Step 17. Configure the hardware. To do this, refer to “LAN Configuration:

Replacing a LAN Card in a TSU” on page 339.
procedure “LAN Configuration: Replacing a LAN Card in a TSU” on
page 339.
page 316.
on page 300.
Step 8. Remove the replacement LAN card from slot L1 and re-install the former
card in its place. Refer to “Removing a Card from a TSU” on page 306
and “Adding a Card to a TSU” on page 303 for help with this procedure.
on page 301.
Chapter 11 273
Step 12. Reconnect the power and LAN cables in the rear panel of the TSU but do
NOT connect the TSC cables (that connect to the signaling network) yet.
minutes).
following:
Step 15. Reconnect the TSC cables to the rear panel of the TSU in order to
reconnect to the signaling network.
If you have stopped HP OpenCall SS7 on the hosts, you can now restart
it. To do this, log in as root or ocadmin on the host and run ss7Start.
274 Chapter 11
Installing an Additional TSC in a TSU

This section describes how to add an additional Telecom Signaling Card
into a TSU. The new TSC must of the same type as the other TSCs in the
TSU. It is possible to add a TSC to a TSU on a running platform without
disturbing the traffic.
You must be logged onto the active host as root or ocadmin.
page 316.
Step 4. Remove all cables from the rear panel of the TSU and disconnect the
TSC cables at the network end.
on page 300.
Chapter 11 275
Step 8. Insert the new TSC into a vacant slot. Refer to “Adding a Card to a TSU”
on page 303 for help with this.
Note that you may need to remove other TSCs in order to gain access to
the relevant slot. If this is the case, do not forget to replace them!
on page 301.
any TSC cables at the network end yet. If you are using the optional
connection panel, you will need to make the TSC connections via this
panel.
Label the new TSC cables, stating what they are (E1, T1, V.35) and
where they connect to (e.g. TSC5).
minutes).
Step 14. Check the LEDs on the TSU and the TSCs. See “Checking LEDs” on
page 309 for information on the LEDs and their meaning.
Step 15. Configure the hardware. To do this, refer to “TSC Configuration:

Installing an Additional TSC in a TSU” on page 325. As part of this
procedure, you will connect the TSC cables to the network and restore
the diverted traffic (if necessary).
276 Chapter 11
Replacing a TSC in a TSU

This section describes how to replace a Telecom Signaling Card in a TSU.
The replacement TSC must be of the same type as the other TSCs in the
TSU. It is possible to replace a TSC in a TSU on a running platform
page 316.
on page 300.
Chapter 11 277
Step 8. Remove the old TSC and install the new card in its place. Refer to
“Removing a Card from a TSU” on page 306 and “Adding a Card to a
TSU” on page 303 for help with this.
on page 301.
minutes).
reach the replacement TSC.
When asked if you wish to load the updated configuration, answer

affirmatively.
Do not accept changes now - quit the tool or move to another window to
continue - if you accept the changes, no rollback will be available.
Step 16. Reconnect the TSC cables to the signaling network.
Step 17. If you have diverted the traffic from the TSU, you can now restore the

Replacing a TSC in a TSU” on page 329.
278 Chapter 11
procedure “TSC Configuration: Replacing a TSC in a TSU” on page 329.
that you are going to work on. To do this, refer to “Restoring the Traffic”
on page 317.
on page 300.
Step 8. Remove the replacement TSC and install the old card back in its place.
Refer to “Removing a Card from a TSU” on page 306 and “Adding a Card
to a TSU” on page 303 for help with this.
on page 301.
Step 12. Reconnect the power and LAN cables to the rear panel of the TSU but do
NOT reconnect the TSC cables to the TSCs yet.
minutes).
Chapter 11 279
reach the TSC that you have re-installed.
Step 15. Reconnect the TSC cables.
following:
traffic to the TSU. Refer to “Restoring the Traffic” on page 317.
If you have stopped HP OpenCall SS7 on the hosts, you can now restart
it. To do this, log in as root or ocadmin on the host and run ss7Start.
280 Chapter 11
Removing a TSC from a TSU

This section describes how to remove a Telecom Signaling Card from a
TSU (without replacing the card). It is possible to remove a TSC from a
TSU on a running platform without disturbing the traffic.
page 316.
Step 2. Remove the link(s) associated with the TSC from the stack, as follows:
a. In SAM, follow the path Platform Configuration|

Actions|View/Modify|Hardware|View Configuration
and find the links to be removed.
b. In the SS7 Monitor screen, follow the path
Configure Entities|Config MTP|Config lk/lkset
then find the SLC corresponding to the link identifiers and remove
the link(s).
Press “C” to checkpoint the modifications.
Make a note of the link identifiers, the SLCs and the DPCs of the
links you have removed.
Chapter 11 281
on page 300.
Step 9. Remove the relevant TSC from the TSU. Refer to “Removing a Card from
a TSU” on page 306 for help with this.
on page 301.
Step 13. Reconnect the power and LAN cables in the rear panel of the TSU.
minutes).
Step 15. Reconnect the remaining TSC cables to the rear panel of the TSU, but do
NOT connect them at the network end yet.
Step 16. Use the command ss7TsuPing -v to check that the TSC is no longer
present.

Removing a TSC from a TSU” on page 330. During this procedure, you
will reconnect the TSC cables to the network and restore the diverted
traffic (if necessary).
282 Chapter 11
procedure “TSC Configuration: Removing a TSC from a TSU” on
page 330.
on page 300.
Step 6. Re-insert the removed TSC into the TSU. Refer to “Adding a Card to a
on page 301.
Step 10. Reconnect the power and LAN cables in the rear panel of the TSU.
Step 11. Reconnect the TSC cables to the rear panel of the TSU, but do NOT
connect them at the network end yet.
minutes).
Step 13. Use the command ss7TsuPing -v to check that you can reach the TSC
that you have re-installed.
Step 14. Rollback the platform configuration changes by running the command
ss7HwRollback.
Step 16. If you have stopped HP OpenCall SS7, you can now restart it. To do this,
Chapter 11 283
Step 17. Add the removed link(s) back to the stack. In the SS7 Monitor screen,
select Configure Entities|Config MTP|Config lk/lkset and add the
link(s).
Otherwise, reactivate the link(s). In the SS7 Monitor screen, select

Monitor Entities|Monit MTP|Monit lk/lkset, then activate the
link(s).
284 Chapter 11
Replacing a TSU
Replacing a TSU
This section describes how to replace a faulty TSU. It is possible to
replace a faulty TSU on a running platform without disturbing the
traffic.
CAUTION The following procedure involves disconnecting the existing TSU from
the SS7 network. The HP OpenCall SS7 platform will therefore lose
network links. However, depending on the platform, it may be possible
for the traffic that uses these links to be redirected via other links. Do
this in consultation with the personnel responsible for operating the
platform.
that you are going to replace. To do this, refer to “Diverting Traffic” on
page 316.
Step 3. Power off the faulty TSU.
Step 4. Disconnect all cables from the rear panel of the faulty TSU.
Step 6. Remove the covers of both TSUs, as described in “Removing the TSU
Cover” on page 300.
Chapter 11 285
Replacing a TSU
Step 7. Remove the card cages from both TSUs, as described in “Removing the
Step 8. Remove the TSCs and any add-on LAN card from the faulty TSU and
transfer them to the equivalent slots in the replacement TSU. Refer to
Step 9. Re-insert the card cage into the new TSU, as described in “Replacing the
Step 10. Replace the cover of the new TSU, as described in “Replacing the TSU
Step 11. Slide the rails on the new TSU into the rail guides in the server cabinet
and push the TSU into the cabinet until it is in place.
minutes).
Step 14. Use the command ss7TsuPing -v to check that you can reach the
replacement TSU and that it has a new MAC address.

Step 16. Use the command ss7TsuStatus -L -u <TSU_ID> to verify that the
replacement TSU is active and that the links are floating.

Replacing a TSU” on page 321.
286 Chapter 11
Replacing a TSU
procedure “TSU Configuration: Replacing a TSU” on page 321.
that you are going to replace. To do this, refer to “Diverting Traffic” on
page 316.
Step 3. Power off the new TSU.
Step 4. Disconnect all cables from the rear panel of the new TSU.
Step 6. Remove the covers of both TSUs, as described in “Removing the TSU
Step 7. Remove the card cages from both TSUs, as described in “Removing the
Step 8. Remove the TSCs and any add-on LAN card from the new TSU and
transfer them to the equivalent slots in the former TSU. Refer to
Step 9. Re-insert the card cage into the former TSU, as described in “Replacing
the Card Cage” on page 303.
Step 10. Replace the cover of the former TSU, as described in “Replacing the TSU
Step 11. Slide the rails on the former TSU into the rail guides in the server
cabinet and push the TSU into the cabinet until it is in place.
minutes).
Chapter 11 287
Replacing a TSU
following:
288 Chapter 11
Removing a TSU from a Platform

This section describes how to remove a TSU from a running platform
(without replacing the TSU). It is possible to remove a TSU from a
running platform without disturbing the traffic.
All software steps in this procedure must be performed on the same host,
on the running configuration (select Platform Configuration in SAM).
that you are going to remove. To do this, refer to “Diverting Traffic” on
page 316.
Step 2. Remove the link(s) associated with the TSU from the stack. In the SS7
Monitor screen, select
and remove the link(s) you have diverted the traffic from.
Write down the linkIds, SLCs and destination point codes of the links
you have removed.
Chapter 11 289
Step 3. Power off the TSU and remove all cables from the rear panel of the TSU.
Also disconnect the TSC cables at the network end.
Step 4. Remove the TSU from the server cabinet. To do this, refer to “Removing
the TSU from the Server Cabinet” on page 300.

Removing a TSU from a Platform” on page 322.
procedure “TSU Configuration: Removing a TSU from a Platform” on
page 322.
Step 1. Insert the TSU back into the server cabinet.
Step 2. Reconnect all cables to the rear panel of the TSU:
a. Connect the TSU to a platform host using a LAN cable via Slot L0
and if the platform is 2-host, connect the TSU to the other host using
a LAN cable via Slot L1. For information on LAN cabling, refer to
“Cabling for 2-Host Platforms” on page 245.
b. Connect the TSC cables to the TSU but do NOT connect them at the
network end yet.
Step 3. Power on the TSU.
Step 4. Use the command ss7TsuPing -v to check that the TSU is no longer
present.

ss7HwRollback.
link(s).
Step 8. Activate the added link(s). In the SS7 Monitor screen, select
link(s).
290 Chapter 11
Installing a TSC in a Host Server

This section describes how to add a Telecom Signaling Card into a
TSC-in-system server. The new TSC must be of the same type as any
other TSCs in the server.
CAUTION When following this procedure, it is important to refer to your server

documentation when carrying out tasks that are specific to the host
server.
CAUTION During this procedure, it is necessary to shut down the platform (if the
platform is running). You will therefore disturb the traffic handled by the
platform.
WARNING Be sure to power off the host server when instructed to do so.
Step 1. If your platform is running, stop HP OpenCall SS7. To do this, log onto
the host as root, run the command ss7Stop -all and shut down the
platform.
Step 3. Power off the host server (if it is powered on).
Step 4. Remove the cover of the host server.
Step 5. Install the new TSC in the host server. Refer to your server
documentation for help with this.
Step 6. Replace the cover of the host server.
Step 7. Power on the host server and wait until it has booted.
Chapter 11 291
Step 8. If the HP OpenCall SS7 software has been installed, use the command
ss7TscPing -v to check that you can reach the new TSC. If the software
has not been installed, omit this step.
Step 9. Connect the TSC cables to the TSC, but do NOT connect them at the
network end yet.
Step 10. Label the new TSC cables, stating what they are (E1, T1, V.35) and
where they connect to (e.g. TSC1, TSC2).
Step 11. If you are installing a TSC in an existing system, now configure the
hardware. To do this, refer to “TSC Configuration: Installing a TSC in a
Host Server” on page 332. During this procedure you will connect the
TSC cables to the network.
If you are installing a TSC in a new platform, do not configure the

hardware yet, as you will do this as part of the HP OpenCall SS7
software installation procedure.
292 Chapter 11
Replacing a TSC in a Host Server

This section describes how to replace a Telecom Signaling Card in a
TSC-in-system server. The replacement TSC must be of the same type as
any other TSCs in the server.

server.
CAUTION During this procedure, it is necessary to shut down the platform. You will
therefore disturb the traffic handled by the platform.
Step 1. Stop HP OpenCall SS7. To do this, log onto the host as root, run the
command ss7Stop -all and shut down the platform.
Step 3. Power off the host server.
Step 4. Remove the network cables from the TSC that is to be replaced and
disconnect the TSC cables at the network end.
Step 6. Remove the old TSC and install the new card in its place. Refer to your
server documentation for help with this.
Step 9. Use the command ss7TscPing -v to check that you can reach the
replacement TSC.
Chapter 11 293
Step 10. Reconnect the TSC cables to the TSC but do NOT connect them at the
network end yet.
Do not accept changes now - quit the tool or move to another window to
continue - if you accept the changes, no rollback will be available.

Replacing a TSC in a Host Server” on page 335. During this procedure,
you will reconnect the TSC cables to the network.
procedure “TSC Configuration: Replacing a TSC in a Host Server” on
page 335.
Step 1. Stop HP OpenCall SS7 by running the command ss7Stop -all and shut
down the platform.
Step 4. Remove the network cables from the TSC and disconnect the TSC cables
at the network end.
Step 6. Remove the replacement TSC and re-install the old card in its place.
Refer to your server documentation for help with this.
Step 9. Use the command ss7TscPing -v to check that you can reach the TSC
Step 10. Reconnect the TSC cables.
following:
294 Chapter 11
Step 12. Restart HP OpenCall SS7 by running the command ss7Start.
Chapter 11 295
Removing a TSC from a Host Server

This section describes how to remove a Telecom Signaling Card from a
TSC-in-system server (without replacing the card).

server.
CAUTION During this procedure, it is necessary to shut down the platform. You will
therefore interrupt the traffic handled by the platform.
Step 1. If there is traffic on the TSC that is to be removed, divert the traffic from
this TSC. To do this, refer to “Diverting Traffic” on page 316.
If there is no traffic on the TSC that is to be removed, simply deactivate

the links associated with this TSC. To do this, run SS7 Monitor, select
Monitor Entities|Monit MTP|Monit lk/lkset and follow the
instructions to deactivate the links.
Step 2. Remove the link(s) associated with the TSC from the stack, as follows:
In the SS7 Monitor screen, follow the path
and remove the links associated with the TSU to be removed.
Make a note of the link identifiers and the SLCs of the links you have
removed.
296 Chapter 11
down the platform.
Step 6. Remove the TSC cables from all TSCs and disconnect the cables at the
network end.
Step 8. Remove the TSC from the host server. Refer to your server
Step 11. Reconnect the TSC cables to the remaining TSCs, but do NOT connect
them at the network end yet.
Step 12. Use the command ss7TscPing -v to check that the TSC is no longer
present.

Removing a TSC from a Host Server” on page 336. During this procedure
you will reconnect the TSC cables to the network.
procedure “TSC Configuration: Removing a TSC from a Host Server” on
page 336.
down the platform.
Step 5. Re-insert the removed TSC into the host server. Refer to your server
Chapter 11 297
Step 7. Reconnect the TSC cables to the TSC, but do NOT connect at the
network end yet.
Step 9. Use the command ss7TscPing -v to check that you can reach the TSC
ss7HwRollback.
Step 12. Restart HP OpenCall SS7 on the host. To do this, log in as root or
ocadmin on the relevant host and run ss7Start.
link(s).
Step 14. Reactivate the links associated with the TSC using the SS7 Monitor. To
do this, select Monitor Entities|Monit MTP|Monit lk/lkset and
follow the instructions to activate the links. If all links of a linkset have
been deactivated, you must activate the linkset.
If you diverted traffic from the TSC, the links will then handle the traffic
as before.
298 Chapter 11
Replacing a Four-Port TSC Cable
Replacing a Four-Port TSC Cable

This section describes how to replace a 4-port TSC cable that connects a
Telecom Signaling Card to the SS7 network.
NOTE The replacement cable must be identical in type to the cable being
removed.
CAUTION During this procedure, the traffic handled by the TSC will be disturbed.
You can, however, avoid disruption of traffic by diverting this traffic to
another TSC.
Step 1. Divert the traffic from the TSC that you are going to work on. To do this,
refer to “Diverting Traffic” on page 316.
Step 2. Remove the old 4-port TSC cable.
Step 3. Connect the new 4-port TSC cable to the TSC and to the network.
Step 4. You can now restore the traffic to the TSC. To do this, refer to “Restoring
the Traffic” on page 317.
Rollback Follow the above procedure.
Chapter 11 299
Common TSU/TSC Procedures

This section contains the TSU/TSC procedures that are referenced from
other procedures in the manual (from Chapter 10, Installing a New TSU,
and Chapter 11, “Maintaining Signaling Hardware.”)
The procedures provided in this section are listed below.
• “Removing the TSU from the Server Cabinet” on page 300

• “Removing and Replacing the TSU Cover” on page 300
• “Removing and Replacing the Card Cage” on page 302
• “Adding a Card to a TSU” on page 303
• “Removing a Card from a TSU” on page 306
• “Checking LEDs” on page 309
Removing the TSU from the Server Cabinet

For some of the procedures described in this guide, you have to remove
the TSU from the server cabinet. To do this, follow the procedure below:
Step 1. Ensure that the TSU is powered off.
Step 2. Ensure that all cables have been removed from the rear panel of the
TSU.
Step 3. Slide the TSU on its rails until it blocks.
Step 4. Push the two springs on the side of the rails (that hold the TSU in) and
slide the TSU off the rail guide.
Removing and Replacing the TSU Cover

the TSU cover.
This section describes how to remove and then replace the cover.
Removing the TSU Cover

When working through this procedure, refer to Figure 11-3 below.
300 Chapter 11
Step 1. Unscrew the four captive screws on the sides of the cover with a Philips
screwdriver.
Step 2. Slide the cover back one centimeter to loosen it from the groove, then lift
it off.
Figure 11-3 Removing the TSU Cover
Replacing the TSU Cover
Step 1. Place the cover on the top of the unit, one centimeter behind the
frontplate, then slide it forward so that the grooves at the rear of the unit
are attached.
Step 2. Tighten the four captive screws on the cover of the unit.
Chapter 11 301
Removing and Replacing the Card Cage

the card cage from inside the TSU.
This section describes how to remove and then replace the card cage.
Removing the Card Cage

When working through this procedure, refer to Figure 11-4 below.
Step 1. Disconnect the power supply connector (the large white connector) from
the power supply unit.
Step 2. Disconnect the fan board connector J9 (the large black connector on the
ribbon cable at the front of the card cage).
Step 3. Unscrew the four captive screws at the back of the card cage (and
accessible from the TSU rear panel), then slide the cage towards the
frontplate of the unit and lift the cage out.
Figure 11-4 Removing the Card Cage
302 Chapter 11
Replacing the Card Cage
Step 1. Insert the card cage back into the TSU and tighten the four captive
screws at the back to the chassis.
Step 2. Reconnect the (white) power supply connector to the power supply unit.
Step 3. Reconnect the fan board connector J9.
Adding a Card to a TSU

Note that the PCI slots available in a TSU for the different types of cards
are as follows:
Card Type PCI Slots
V.35 TSC 1 to 5
LAN Card L1
NOTE If you wish to add a card to your TSU, you should begin the installation
by referring to the section in this guide for adding the relevant card type.
• If you are installing TSCs and/or a LAN card in a new TSU, refer to
“Stage 1: Installing Cards in the TSU” on page 238.
• If you are adding or replacing a TSC in an existing TSU, refer to
“Replacing a TSC in a TSU” on page 277 or “Installing an Additional
TSC in a TSU” on page 275.
• If you are adding or replacing a LAN card in an existing TSU, refer to
“Installing an Additional LAN Card in a TSU” on page 269 or
“Replacing a LAN Card in a TSU” on page 271.
CAUTION Ensure that you are taking anti-static precautions by wearing the
grounding wrist strap before handling the cards.
Chapter 11 303
The following procedure forms a common part of other procedures in this

guide concerned with inserting different card types into a TSU.
Step 1. Remove the card holder brackets as follows (also refer to Figure 11-5
below):
a. Remove the appropriate card holder bracket screw(s).

b. Slide the bracket sideways towards the front of the chassis to detach
the keyhole standoff on the bottom of the card cage.
Figure 11-5 Removing the Card Holder Brackets
Step 2. Insert the card as follows (also refer to Figure 11-6 below)
a. Remove the slot protector from the relevant slot on the card cage
backplane.
b. Slide the card into the slot. Press firmly on both ends of the card at
the same time to make sure it is firmly seated in the connector.
304 Chapter 11
c. Screw the card bracket to the cage.
Figure 11-6 Inserting the Card
Step 3. Replace the card holder bracket(s):
a. Slide the bracket into the keyhole standoff in the chassis.

b. Secure the bracket to the card cage by replacing and tightening the
screw on the top of the bracket.
Chapter 11 305
Removing a Card from a TSU

Note that the different types of cards that the PCI slots in a TSU can
accommodate are as follows:
Card
PCI Slots
Type
V.35 TSC 1 to 5
LAN Card L1
NOTE If you wish to remove a card from your TSU, you should begin by
referring to the section in this guide for removing the relevant card type.
• If you are removing a TSC, refer to “Replacing a TSC in a TSU” on

page 277 or “Installing an Additional TSC in a TSU” on page 275.
• If you are removing a LAN card, refer to “Installing an Additional
LAN Card in a TSU” on page 269 or “Replacing a LAN Card in a
TSU” on page 271.
CAUTION Ensure that you are taking anti-static precautions by wearing the
grounding wrist strap before handling the cards.
306 Chapter 11
The following procedure forms a common part of other procedures in this

guide concerned with removing different card types from a TSU.
Step 1. Remove the card holder brackets as follows (also refer to Figure 11-5
below):
a. Remove the appropriate card holder bracket screw(s).

b. Slide the bracket sideways towards the front of the chassis to detach
the keyhole standoff on the bottom of the card cage.
Figure 11-7 Removing the Card Holder Brackets
Step 2. Remove the card as follows (also refer to Figure 11-6 below)
a. Unscrew the card bracket from the cage.

b. Slide the card out of the slot. Pull firmly on both ends of the card at
the same time.
Chapter 11 307
c. Place a slot protector in the relevant slot on the card cage backplane.
Figure 11-8 Removing the Card
Step 3. If you are going to leave the vacated slot empty, replace the card holder
bracket(s):
a. Slide the bracket into the keyhole standoff in the chassis.

b. Secure the bracket to the card cage by replacing and tightening the
screw on the top of the bracket.
308 Chapter 11
Checking LEDs
To check that installed hardware is functioning correctly, refer to the
LEDs. These are as follows:
• TSU LEDs
These appear on the front panel of the unit and are repeated on the
rear panel. They indicate the status of the TSU and are fully
described below.
• TSC LEDs
These appear on the end-plate of each TSC and can be viewed on the
rear panel of the TSU. They indicate the status of the TSC and are
fully described below.
• LAN Card LEDs
These appear on the end-plate of each LAN card and can be viewed
on the rear panel of the TSU. They indicate the status of the LAN
card and are fully described below.
Once you have powered on the TSU, use the above LEDs to determine
whether each of the individual components (TSU, TSCs and LAN cards)
is operating correctly. The LEDs are interpreted as described below.
TSU LEDs The TSU features the following four LEDs which appear on both the
front and back of the unit:
• Power
• Status
• Fault
• Fan Fail
Chapter 11 309
Table 11-1 below indicates the meanings of these LEDs in their different
states.
Table 11-1 TSU LEDs - Interpretation
ACTIVE
TSU without
TSU
HP OpenCall SS ACTIVE Fan
LED without
7 TSU failed
configurati
firmware
on
Power On On On On
Status Off On On Off
Fault Flashing On Off On
Fan Fail Off Off Off Flashing
Therefore at this stage, if your TSU is operating correctly, the four LEDs
should show the following states:
• Power - ON
• Status - ON
• Fault - ON
• Fan Fail - OFF
NOTE If the TSU is powered on, but not configured, the Fault LED should be
ON.
If the Status and Fault LEDs do not appear in the above ON-ON
combination, their exact behavior can be used to determine the current
operational state of the TSU. Table 11-2 below details how to interpret
this behavior.
310 Chapter 11
Table 11-2 TSU Status and Fault LEDs - Interpretation
LED
TSU State Meaning
Fault Status
Off + Off Not responding Performing the

power-on self-test, or
rebooting
Off + Flashing Not responding Starting the TSU

slowly firmware
Off + Flashing Not responding Firmware started, TSU

rapidly is configuring TSCs
Off + On Active TSU is operational
On + Off Not responding Power-on self-test has

failed
Flashing slowly or + Off Not responding No firmware on TSU

rapidly
Flashing slowly + Flashing Not responding Fatal software error

slowly
Flashing slowly + On Degraded At least one element of

the TSU has a problem;
e.g. a TSC is
out-of-service
Chapter 11 311
TSC LEDs Each of the TSCs features a number of LEDs on its end-plate: V.35 TSCs
each have two LEDs and E1/T1 TSCs each have six LEDs. These are as
follows:
• L1 LED (all TSC types): Indicates the status of the PCI base card.
• L2 LED (all TSC types): Indicates the status of the TSC itself.
• P0-P3 LEDs (E1/T1 TSC only): Indicate port status.
The positions of these LEDs are indicated in Figure B-1 on page 386
(V.35 TSC) and Figure B-2 on page 388 (E1/T1 TSC).
states.
Table 11-3 TSC LEDs - Interpretation
Meaning for
LED Status Meaning for V.35
E1/T1
L1 On Reset TSC Reset TSC
L2 On TSC active Reset TSC
Amber TSC failed N/A
P0/P1/P2/P3 On Cable connected N/A

and at least one
link is configured
For an unconfigured TSC, only the L2 LED should be ON.
LAN Card LEDs Each LAN card has three LEDs:
• LNK: Indicates the state of the connection to the host.

• ACT: Indicates whether data is being sent/received.
• 100: Indicates the speed of the connection.
312 Chapter 11
states.
Table 11-4 LAN Card LEDs
LED Status Meaning
On The card and the host LAN card are

receiving power. The cable connection
between adapter and host is OK.
LNK
Off The cable connection between the card
and the host is faulty, or the driver
configuration is faulty.
On or The card is sending or receiving network

flashing data. The frequency of the flashing
ACT depends on the amount of traffic.
Off The card is not sending or receiving data.
On The card is operating at 100 Mbit/s.

100
Off The card is operating at 10 Mbit/s.
It is therefore important to check that the LNK LED is ON and that the
ACT LED flashes occasionally. If this is not the case, consult the
troubleshooting lists below.
The LNK LED does not light:
• Check all connections at the card and the host LAN card.
• Try another port on the host LAN card.
• Make sure the host LAN card has its configuration set to
autoregulate the speed.
• Make sure that you have the correct cabling, as supplied with the
TSU, between the card and the host.
The ACT LED does not light:
• The card may not be transmitting or receiving. Refer to your LAN

card documentation for help.
In addition, the 100 LED will be ON if the card is functioning properly.
Chapter 11 313
314 Chapter 11
12 Configuring TSU/TSC Hardware
This chapter contains the procedures for the software configuration of

TSUs, TSCs and LAN cards. To carry out the necessary hardware
operations, start with the relevant procedure in Chapter 10, “Installing a
New TSU,” or Chapter 11, “Maintaining Signaling Hardware.”
Chapter 12 315
Configuring TSU/TSC Hardware
Diverting Traffic
Diverting Traffic
Many of the procedures described in Chapter 11, Maintaining Signaling
Hardware, require you to divert the traffic before starting. This
procedure describes how to do so.
Use these procedures when the traffic is low as performance is affected,
although the connection is maintained. Otherwise, you will concentrate
too much traffic on the remaining links and they will become congested.
For example, if you plan to deactivate half of your links, they should be
loaded at less than 40%. You should also take care not to deactivate too
many links at a time as the diverted traffic may overload the remaining
links, even if they were initially loaded at less than 40%.
CAUTION If you stop a hardware element that handles all your SS7 links on the
platform, you will lose your traffic.
Actions All the steps can be done as root or ocadmin. They must be done on the
active host.
Step 1. Find the MTPL2 link identifiers (linkId) for the elements you need to
stop.
In SAM, use
Actions|View/Modify|Hardware|View Configuration.
Step 2. Find the corresponding SLCs and linksets. To do this, in the SS7
Monitor, select Monitor Entities|Monit MTP|Monit lk/lkset. For
each linkId, there is a corresponding SLC and DPC.
If you do not need to deactivate all the links of a linkset (or to a DPC), the
connection with this destination point code is not lost. The traffic is
shared among the remaining links of the linkset. Otherwise, you lose the
traffic unless there is a secondary route to this DPC (see Monitor
Entities|Monit MTP|Monit dst/rout).
Step 3. Deactivate the links. Run SS7 Monitor, and select Monitor
Entities|Monit MTP|Monit lk/lkset and follow the instructions to
deactivate the links.
316 Chapter 12
Diverting Traffic
NOTE When deactivating the links, you lose any messages that were being
exchanged at the exact moment of the deactivation
Checks
Step 1. Check that there is no congestion on the other links.
Step 2. Check that no DPCs are out of service. If you deactivate all the links to a
DPC, it will go of service and all traffic to it will be lost.
Result All the links corresponding to the hardware elements you need to stop
are now deactivated. The traffic that used to be supported by them is
shared among the remaining links
Restoring the Traffic

To restore the traffic on the deactivated links, reactivate them using the
SS7 Monitor. They will handle the traffic as before.
To do this, select Monitor Entities|Monit MTP|Monit lk/lkset and
follow the instructions to activate the links.
If all links of a linkset have been deactivated, you must activate the
linkset.
Chapter 12 317
TSU Configuration: Adding a New TSU to an Existing Platform
TSU Configuration: Adding a New TSU to an

Existing Platform
This section contains the software configuration steps that you must
perform when adding a new TSU to an existing (running) system. To
perform this installation, you must start with the procedure in
Chapter 10, “Installing a New TSU,” on page 235.
The procedure below assumes that the TSU and associated TSCs have
been installed, and that the TSU has been connected to the platform and
is powered on. Note that the TSCs must NOT be connected to the
network at this stage.
NOTE The steps below should be carried out on both 1-host and 2-host
platforms.
All steps of this procedure must be carried out on the active host, on the
running configuration. You must log in as root or ocadmin.
Step 1. Update the configuration using SAM. Follow the path

Platform Configuration|Actions|View/Modify|Hardware|Update
Existing Configuration.
Refer to the SAM on-line help. Do not leave the hardware screen.
Step 2. Configure the TSCs using SAM. Follow the path

Platform Configuration|Actions|View/Modify|Hardware|TSC
Configuration.
All parameters of the new TSCs are automatically detected or set by

default, except the owner parameter when there is more than one stack.
Configure this parameter now.
Step 3. If the TSCs are E1/T1, configure the ports using SAM. Follow the path
Configuration|Port Configuration.
318 Chapter 12
Step 4. Configure the links using SAM. Follow the path

Platform Configuration|Actions|View/Modify|Hardware|Link
Configuration.
All links of the new TSCs are configured with default values except the
timeslots (for conventional SS7 links), which you have to configure now.
Refer to the SAM on-line help.
Write down the new link identifiers for the link configurations in the
stack.
You can now leave the hardware screen.
Step 5. Load the changes by running the command ss7HwLoad.
Do not accept changes now - quit the tool or move to another window - if
you accept the changes now, no rollback will be available.
Step 6. Add the link(s) to the stack. In the SS7 Monitor screen, select
Configure Entities|Config MTP|Config lk/lkset and add the new
link(s).
Step 7. Connect the TSC cables from the rear panel of the TSU (or the optional
connection panel) to the signaling network.
Step 8. Activate the link(s). In the SS7 Monitor screen, select

link(s).
All elements at the network end should be configured and activated, so

that the links can be aligned.
Step 9. Check the state of the links using the SS7 Monitor. To do this, follow the
path Monitor Entities|Monit MTP|Monit lk/lkset.
The links should be active.
Step 10. If you are satisfied with the new configuration, make it the running
configuration by carrying out either one of the following:
• run the command ss7HwAccept
• accept the updated configuration in the ss7HwLoad window.
If you are not satisfied with the new configuration, perform the rollback
steps now. Refer to the “Rollback” section below.
Chapter 12 319
Step 11. If you have a 2-host platform, propagate the updated configuration. To do
this, carry out one of the following:
• answer affirmatively in the ss7HwAccept or ss7HwLoad window
• in SAM, follow the path

Platform Configuration|Actions|Propagate
Rollback Only perform this rollback when instructed to do so in Step 10 above.
Step 1. Deactivate the added link(s) on the stack. In the SS7 Monitor screen,
select Monitor Entities|Monit MTP|Monit lk/lkset and deactivate
the link(s).
Step 2. Remove the added link(s) from the stack. In the SS7 Monitor screen,
select Configure Entities|Config MTP|Config lk/lkset and remove
the link(s).
Step 3. Rollback the configuration changes by carrying out either one of the
following:
• reject the updated configuration in the ss7HwLoad window.
320 Chapter 12
TSU Configuration: Replacing a TSU
TSU Configuration: Replacing a TSU

perform when replacing a TSU in an existing (running) system. To
perform this installation, you must start with the procedure
“Replacing a TSU” on page 285.
The procedure below assumes that the TSU and associated TSCs have
been installed, and that the TSU has been connected to the platform and
is powered on. Note that the TSCs must NOT be connected to the
network at this stage.
platforms.
All steps of this procedure must be carried out on the active host, on the
running configuration. You must log in as root or ocadmin.
Step 2. If you are satisfied with this new configuration, make it the running
• accept the updated configuration in the ss7HwReplace window.
steps now. Refer to the “Rollback” in the section “Replacing a TSU” on
page 285.

this, carry out either one of the following:
• answer affirmatively in the ss7HwReplace or ss7HwAccept window

Platform Configuration|Actions|Propagate.
Chapter 12 321
TSU Configuration: Removing a TSU from a Platform
TSU Configuration: Removing a TSU from a

Platform
perform when removing a TSU from a platform (without replacing the
TSU). To remove a TSU, you must start with the procedure
“Removing a TSU from a Platform” on page 289.
The procedure below assumes that the links associated with the TSU
have been removed from the stack, and that the TSU has been powered
off and disconnected from the platform.
platforms. You must be logged in as root or ocadmin on the active host.

Step 2. Check the updated configuration. In SAM, follow the path

Platform Configuration|Actions|View/Modify|Hardware|View
Configuration.
If you are not satisfied with the configuration, go back to the steps
concerned with removing links and updating the configuration until you
are satisfied with the configuration.
Step 3. Load the configuration changes by running the command ss7HwLoad. Do

not accept the changes now - quit the tool or move to another window to
continue - if you accept the changes now, no rollback will be available.
Step 4. Check that the TSU has been removed from the configuration. Do this by
running the command ss7TsuStatus from a host.
Step 5. If you are satisfied with the new configuration, make it the new running
322 Chapter 12
TSU Configuration: Removing a TSU from a Platform
If you are not satisfied with the configuration, perform the rollback steps
now. Refer to the “Rollback” in the section “Removing a TSU from a
Platform” on page 289.

• answer affirmatively in the ss7HwLoad or ss7HwAccept window
• In SAM, follow the path Platform Configuration | Actions |

Propagate.
Chapter 12 323
TSU Configuration: Replacing the Backplane and CPU Card of a TSU
TSU Configuration: Replacing the Backplane

and CPU Card of a TSU
perform when replacing the card cage kit of a TSU, where this kit
includes the backplane and CPU card of the TSU. To replace the
backplane and CPU card, you must start with the procedure
“Replacing the TSU Backplane and CPU Card” on page 265.
The procedure below assumes that the card cage kit has been replaced
and that the TSU has been powered on. Note that the TSCs must NOT
be connected to the network at this stage.
NOTE The steps of this procedure apply to both 1-host and 2-host platforms,
unless otherwise stated. You must be logged in as root or ocadmin on the
active host.
Step 2. If you are satisfied with this new configuration, make it the running
steps now. Refer to the “Rollback” in the section “Replacing the TSU
Backplane and CPU Card” on page 265.


324 Chapter 12
TSC Configuration: Installing an Additional TSC in a TSU
TSC Configuration: Installing an Additional

TSC in a TSU
perform when installing an additional TSC in a TSU. To perform this
installation, you must start with the procedure “Installing an
Additional TSC in a TSU” on page 275.
The procedure below assumes that the TSU has been powered on again
after installation of the TSC. Note that the TSC must NOT be connected
to the network at this stage.
platforms.
The following procedure must be performed on the active host, on the

running configuration (select Platform Configuration in SAM). You
must be logged in as root or ocadmin.

Step 2. Configure the new TSC using SAM. Follow the path
Configuration.
All parameters of the new TSC are automatically detected or set by

Step 3. If the TSC is E1/T1, configure the ports using SAM. Follow the path
Chapter 12 325

Configuration.
All links of the new TSC are configured with default values except the
timeslots, which you have to configure now. Refer to the SAM on-line
help.
stack.
Step 6. Connect the TSC cables at the network end.
link(s).

link(s).
326 Chapter 12
steps now. Refer to the “Rollback” below.

the link(s).
the link(s).
following:
page 316.
Chapter 12 327
Step 9. Remove the cover of the TSU, as described in “Removing and Replacing
the TSU Cover” on page 300.
Step 10. Remove the card cage from the TSU, as described in “Removing and
Replacing the Card Cage” on page 302.
Step 11. Remove the new TSC. Refer to “Removing a Card from a TSU” on
page 306 for help with this.
Step 12. Re-insert the card cage into the TSU, as described in “Removing and
Replacing the Card Cage” on page 302.
Step 13. Replace the cover of the TSU, as described in “Removing and Replacing
the TSU Cover” on page 300.
Step 15. Reconnect the power and LAN cables in the rear panel of the TSU but do
NOT reconnect the TSC cables yet.
minutes).
Step 17. Use the command ss7TsuPing -v -u to check that you can reach the
new TSC.
Step 18. Reconnect the TSC cables to the rear panel of the TSU and at the
network end.
328 Chapter 12
TSC Configuration: Replacing a TSC in a TSU
TSC Configuration: Replacing a TSC in a TSU

perform when replacing a TSC in a TSU. To perform this installation,
start with the procedure “Replacing a TSC in a TSU” on
page 277.
after installation of the TSC. Note that the TSC must NOT be connected
to the network at this stage.
platforms. You must be logged in as root or ocadmin on the active host.
steps now. Refer to the “Rollback” in the section “Replacing a TSC in a
TSU” on page 277.


Chapter 12 329
TSC Configuration: Removing a TSC from a TSU
TSC Configuration: Removing a TSC from a

TSU
perform when removing a TSC from a TSU (without replacing the TSC).
To remove a TSC, you must start with the procedure “Removing
a TSC from a TSU” on page 281.
The procedure below assumes that the links associated with the TSC
have been removed from the stack, that the TSC has been removed from
the TSU and that the TSU is powered on again.


Configuration.

Step 4. Check that the TSC has been removed from the configuration. Do this by
running the command ss7TsuStatus -C from the active host.
now. Refer to the “Rollback” in the section “Removing a TSC from a TSU”
on page 281.
330 Chapter 12
TSC Configuration: Removing a TSC from a TSU

• answer affirmatively in the ss7HwLoad or ss7HwAccept window

Step 7. Reconnect the TSC cables to the network.
Chapter 12 331
TSC Configuration: Installing a TSC in a Host Server
TSC Configuration: Installing a TSC in a Host

Server
perform when installing a TSC in a TSC-in-system server. To perform
this installation, you must start with the procedure “Installing a
TSC in a Host Server” on page 291.
The procedure below assumes that the host server has been powered on
again after installation of the TSC. Note that the TSC must NOT be
connected to the network at this stage.

Step 2. Configure the new TSC using SAM. Follow the path
Configuration.
All parameters of the new TSC are automatically detected or set by

Step 3. If the TSC is E1/T1, configure the ports using SAM. Follow the path

Configuration.
332 Chapter 12
All links of the new TSC are configured with default values except the
timeslots, which you have to configure now. Refer to the SAM on-line
help.
stack.
Step 6. Using the command ss7TscStatus on a front-end host, check that all
TSCs are active.
Step 8. Connect the TSC cables at the network end.
link(s).
link(s).
Chapter 12 333
Rollback Only perform this rollback when you are instructed to do so in Step 7
above.
following:
down the platform.
Step 5. Remove the network cables from the TSC and disconnect them at the
network end.
Step 7. Remove the new TSC from the host. Refer to your server documentation
for help with this.
334 Chapter 12
TSC Configuration: Replacing a TSC in a Host Server
TSC Configuration: Replacing a TSC in a Host

Server
perform when replacing a TSC in a TSC-in-system server. To perform
this installation, start with the procedure “Replacing a TSC in a
The procedure below assumes that the host server has been powered on
again after installation of the TSC. Note that the TSC must NOT be
connected to the network at this stage.
Step 1. Check that all TSCs are active. Do this on the active host using the
command ss7TscStatus -L.
steps now. Refer to the “Rollback” in the section “Replacing a TSC in a
Step 3. Reconnect the TSC cables to the signaling network.
Chapter 12 335
TSC Configuration: Removing a TSC from a Host Server
TSC Configuration: Removing a TSC from a

Host Server
perform when removing a TSC from a TSC-in-system server (without
replacing the TSC). To remove a TSC, you must start with the
procedure “Removing a TSC from a Host Server” on page 296.
The procedure below assumes that the links associated with the TSC
have been removed from the stack, that the TSC has been removed from
the host server and that the TSU is powered on again.


Configuration.

Step 4. Check that the TSC has been removed from the configuration. Do this by
running the command ss7TscStatus -L on the active host.
336 Chapter 12
TSC Configuration: Removing a TSC from a Host Server
now. Refer to the “Rollback” in the section “Removing a TSC from a Host
Server” on page 296.
Step 6. Reconnect all TSC cables to the network.
Step 7. Restore the traffic, as described in “Restoring the Traffic” on page 317.
Chapter 12 337
LAN Configuration: Installing an Additional LAN Card in a TSU
LAN Configuration: Installing an Additional

LAN Card in a TSU
This section contains the software configuration procedure that you must
perform when adding a LAN card in slot L1 of a TSU. To perform this
installation, start with the procedure “Installing an Additional
LAN Card in a TSU” on page 269.
after installation of the LAN card and that the TSU LANs have been
connected to the platform hosts.

See the SAM on-line help.
Step 2. Install the configuration on the host. Do this by running the command
ss7HwLoad followed by the command ss7HwAccept.
Step 3. Propagate the configuration to the other hosts in the platform by either
answering “yes” in the ss7HwAccept window or by propagating in SAM.
338 Chapter 12
LAN Configuration: Replacing a LAN Card in a TSU
LAN Configuration: Replacing a LAN Card in

a TSU
This section contains the software configuration procedure that you must
perform when replacing a LAN card in slot L1 of a TSU. To perform
this installation, you must start with the procedure “Installing
an Additional LAN Card in a TSU” on page 269.
after installation of the LAN card and that the TSU LANs have been
connected to the platform hosts.
The steps of this procedure must be performed on the active host, on the
steps now. Refer to the “Rollback” in the section “Replacing a LAN Card
in a TSU” on page 271.


Chapter 12 339
Adding and Activating Links on the SS7 Stack
Adding and Activating Links on the SS7 Stack

This section describes how to add and activate links on the SS7 stack
when a new TSC is introduced into the HP OpenCall SS7 system.
The procedure below assumes that the TSC has been installed,
configured, validated and connected to the SS7 network, and that the
appropriate links have been created using SAM.
Step 1. Add the link(s) to the stack.
From the SS7 Monitor screen, select Configure Entities|Configure

MTP|Configure Link/Linksets and add the new link(s).
Step 2. Activate the link(s).
In the SS7 Monitor screen, select Monitor Entities|Monitor

MTP|Link|Linksets, then type A.
340 Chapter 12
Configuring TSC Chained Links

This section describes how to configure the SS7 links for E1/T1 TSCs
that have been connected together in a daisy chain arrangement. You can
chain together two TSCs only. Refer to “Chained TSCs” on page 412 for
more information on TSC chained links.
The procedure below assumes that the TSCs have already been
physically connected together as required. An example arrangement is
shown in the figure below.
Figure 12-1 Example of Chained TSCs
Step 1. Create a configuration using SAM. To do this, follow the path

Platform Configuration|Actions|View/Modify|Hardware|Create
Initial Configuration.
Chapter 12 341
Step 2. In the TSC Configuration screen, select the card type (E1 or T1) of your
TSCs.
Step 3. Select the clock source for each of the TSCs. This can be set to be internal
or external:
• If both TSCs are to take their clocks from the SS7 network, set the
clock source to external for both TSCs.
• If one of the two TSCs is to act as the clock source, set the clock
source to internal for this TSC and to external for the other TSC.
Step 4. For the TSC that is connected directly to the network, configure the two
ports used so that they are internally connected on the TSC. Each port
must be connected to the other port by setting the Port Source parameter
in the Port Configuration screen.
For example, for the system shown in the above diagram, this
configuration for
TSC A would be as follows:
• For Port 0, set Port Source to be 2 (so that the output for Port 0 is
taken from Port 2 via an internal connection on the TSC).
• For Port 2, set Port Source to be 0 (so that the output for Port 2 is
taken from Port 0 via an internal connection on the TSC).
Step 5. In the Link Configuration screen, create the links for the two TSCs. For
each link, you must specify a name, a TSC, a port and a timeslot.
For example, for the system shown in the above diagram, you would
create the following links:
• a link LINK_A01 for Port 0 on TSC A, which maps to timeslot 1.
• a link LINK_B15 for Port 1 on TSC B, which maps to timeslot 5.
link(s).

link(s).
342 Chapter 12
Chapter 12 343
Configuring HP OpenCall SS7 Hardware Manually
Configuring HP OpenCall SS7 Hardware

Manually
This section describes how to configure TSUs and TSCs manually.
Configuration involves the following steps:
• Defining the configuration information.

• Checking the configuration.
• Loading the configuration to the host.
The information on how to carry out these steps manually is provided for
use in batch configurations. In general, you should use SAM.
Step 1. Define the Configuration
Before any communication can occur between the host and the network,
the system must be configured: the SS7 network must know which units,
cards, ports and links it is communicating with. In order to work this out:
a. Draw a map of your system configuration, showing the above

components.
b. Find out detailed configuration information for each component using
the commands ss7TsuPing and ss7TscPing.
c. Use the command cfgss7HwCreate to specify the correct LAN, TSU
and TSC information.
Step 2. Check and load the configuration.
The command ss7HwInit checks that the configuration is valid, and if it

is, loads it.
When you run the command, if the configuration is valid, the following
prompt appears,
Configuration successfully loaded in shared memory
and the system transfers the configuration data from the shared memory
block to the appropriate hardware and software components, ensuring
that the host and the TSU have the same configuration.
344 Chapter 12
If the configuration is invalid, an error message appears describing what

the problem is.
Step 3. Check the links.
Once you have downloaded the configuration to the TSU, run one, or
both, of the following commands to check the status of the TSU and
TSCs.
• ss7TsuStatus -u <tsuId> -C -L
This checks the status of the TSU itself, the TSC(s) it contains and
the links belonging to it.
• ss7TscStatus -c <tscId> -L
This checks TSC status.
Chapter 12 345
346 Chapter 12
13 Updating TSCs and SS7 Links
This chapter contains a number of procedures related to updating the

platform hardware (such as adding and removing links).
Chapter 13 347
Updating TSCs and SS7 Links
Adding Link(s) to a TSC Port

Each TSC has four ports. Each of these ports connects to one or more
links. The table below shows the link limitations for each TSC type.
Table 13-1 Link Limitations
TSC type Maximum Maximum TSCs

number of number of links available
links per TSC per port with links...
V.35 4 1 2 or 4
E1 16 16 2, 4, 8 or 16
T1 16 16 2, 4, 8 or 16
NOTE The maximum number of links that you can use on your system depends
on the platform license you have purchased.
If your license does not support the new total number of links that you
want to use on a TSC, you will need to upgrade the platform license
before adding links to your system (refer to Chapter 7, “Upgrading the
Platform License,” on page 195). You can view the platform license
information using SAM - follow the path Platform
Configuration|Actions|View/Modify|Platform License|OK.
Each TSC has a maximum number of links that it can maintain - this
number is determined when the TSC is ordered. If your required number
of links exceeds this maximum, it may be possible to upgrade the link
capability of the TSC (see Table 13-1). To do this, refer to “Upgrading
TSCs” on page 354. You can view your TSC’s link capability using SAM -
follow the path Platform
Configuration|Actions|View/Modify|Hardware|View
Configuration.
If it is not possible to enhance the link capability of your TSC, you will
need to add another TSC before you can add links.
348 Chapter 13
There is also a maximum number of links for each port (see Table 13-1).
If the existing ports already have the maximum number of links
assigned, you will need to configure another port before you can add
links. This is described in the following procedure.
NOTE You do not need to power off the system in order to add links. You can
also perform this upgrade without disturbing traffic, except if you need
to modify a port configuration, in which case you will have to divert
traffic from the TSC concerned.
All software steps in the following procedure must be performed on the

active host on the running configuration (select Platform
Configuration in SAM). You must be logged in as root or ocadmin.
To add link(s) to a port on an existing TSC:
Step 1. If you need to connect another port to the SS7 network in order to add
links, carry out the following (omit this step if you are adding links to an
already connected port):
a. Connect the TSC cable port connector to the network cable.

b. Label the cable, stating what it is (E1, T1, V.35) and where it is
connected to (TSC1, TSC2, and so on).
c. If the TSC is E1/T1, customize the port configuration according to
your network. In SAM, follow the path Platform
Configuration|Actions|View/Modify|Hardware|TSC
Step 2. Add the new link(s) using SAM. To do this, follow the path
Platform Configuration|Actions|View/Modify|Hardware|Links
Configuration. Refer to the SAM on-line help.
Make a note of the new link identifiers for the stack configuration.
Step 3. Load the changes:
a. If you have modified the port configuration in Step 1d, divert the
traffic from the TSC, as described in “Diverting Traffic” on page 316.
b. Run the command ss7HwLoad.
Chapter 13 349
Do not accept changes now - quit the tool or move to another window -
if you accept the changes now, no rollback will be available.
c. If you have diverted the traffic from the TSC, restore it now, as
described in “Restoring the Traffic” on page 317.
link(s).
Step 5. Activate the link(s). In the Stack Monitor screen, select

Monitor Entities|Monit MTP|Monit lk/lkset and type A.
All elements at the network end should be configured and activated, so

that the links can be aligned.
Step 7. If you are happy with the new configuration, make it the running
If you are not happy with the new configuration, perform the rollback


350 Chapter 13
Rollback
the link(s).
the link(s).
Step 3. Rollback the changes:
a. If you have modified the port configuration in Step 1d of the main

procedure, divert the traffic from the TSC, as described in “Diverting
Traffic” on page 316.
b. Rollback the configuration changes by carrying out either one of the
following:

c. If you have diverted the traffic from the TSC, restore it now, as
described in “Restoring the Traffic” on page 317.
Step 4. If you connected an additional port to the network in Step 1 of the main
procedure, disconnect the cable at the network end.
Chapter 13 351
Removing Links from a TSC

This section describes how to remove links associated with a Telecom
Signaling Card.
NOTE You do not need to power off the system in order to remove links. You can
also perform this update without disturbing traffic (apart from the traffic
on the removed links).
All software steps in the following procedure must be performed on the

active host, on the running configuration (select Platform
Configuration in SAM). You must be logged in as root or ocadmin.
Step 1. Deactivate the link(s) that you wish to remove. In the SS7 Monitor
screen, select Monitor Entities|Monitor MTP|Monit lk/lkset and
deactivate the link(s).
Step 2. Remove the link(s) from the stack. In the SS7 Monitor screen, select
Configure Entities|Config MTP|Config lk/lkset and remove the
link(s).
Step 3. Remove the links in SAM. To do this, follow the path

Configuration.
Step 5. Check that the links have been removed from the configuration. Use the
command ss7TsuStatus -L for a TSC-in-TSU platform or
ss7TscStatus -L for a TSC-in-system platform.
Step 6. If you are happy with the new configuration, make it the running
352 Chapter 13
If you are not happy with the new configuration, perform the rollback


Step 8. If you have removed the last link of a port, remove the network cables
connected to this port. Note that you can view the ports in SAM by
following the path Platform
Configuration|Actions|View/Modify|Hardware|View
Configuration.
following:
Step 2. Add the removed link(s) to the stack. In the SS7 Monitor screen, select
link(s).
Step 3. Activate the link(s). In the Stack Monitor screen, select

Monitor Entities|Monit MTP|Monit lk/lkset and type A.
Chapter 13 353
Upgrading TSCs
Upgrading TSCs
Every TSC is limited in terms of the number of links to the SS7 network
that it can maintain. This limit is chosen when ordering the TSC.
However, it is possible to upgrade the card to permit a larger number of
links. This can be done without changing the TSC or removing it from
the platform.
This section describes how to upgrade a TSC by increasing the number of
SS7 links that it can handle.
Checking the TSC is Active

Before upgrading your TSC, send your hardware supplier details about
your card. To get these details, the TSC must be active. The
ss7TscStatus command gives information about a specific TSC if you
use the -c option. The example below investigates TSC 10.
$ ss7TscStatus -c 10
giving the following output:
TSC 10, Name: TSC_10, Status: ACTIVE
Slot Number: 2, Type: E1_UNBALANCED, Class Name: Stack_1
If the status of the card is not active then you must activate it.
Getting the Serial Number and Number of Links

Once you have established that you are working with an active TSC, use
the ss7HwInfo command to find out the information your hardware
supplier needs (also see “Displaying Licensing Information” on
page 199):
• The number of links the card can currently handle

• The serial number of the card
• The total number of links licensed for your platform
354 Chapter 13
Upgrading TSCs
Performing the Upgrade

This upgrade is performed using the command ss7TscUpgrade which
must be run on a front-end machine that has a configured connection to
the TSC that is being upgraded. The TSC must be powered on and
accessible to the system. The current operation of the TSC is not affected
by the upgrade. The user must be logged onto the active host as ocadmin
or as root.
If no errors are reported then the new configuration of the TSC can be
accessed via the ss7HwInfo command. Once the upgrade has been
performed, new links can be added to the TSC using SAM.
NOTE If you are prompted for a platform license, configure and propagate this
using SAM.
ss7TscUpgrade runs with the following parameters:

Table 13-2 ss7TscUpgrade Parameters
Parameter Name Function
-c tscId The tscId of the TSC card being

upgraded
-p licenseCodewo The codeword supplied by HP

rd
The command is executed as follows:

ss7TscUpgrade -c <TSC_ID> -p <codeword>
where <TSC_ID> is the number that identifies the TSC and <codeword>
is the license codeword provided by HP.
Troubleshooting
The following table lists the error messages that can be obtained when
using the ss7TscUpgrade command, with their corresponding meanings.
Error messages are generated if any of the parameters are missing or out
of range.
Chapter 13 355
Upgrading TSCs
Table 13-3 ss7TscUpgrade Error Messages
Error Message Meaning
Corrupted codeword The codeword cannot be

decoded correctly. Check that
it has been typed in correctly.
TSC <%d> not configured No TSC with this

identification is configured in
SAM or the configuration has
not been deployed on the
system.
TSC <%d> inaccessible Communication with the

specified TSC is not possible.
TSC <%d> has serial number that The serial number in the
does not match in the codeword licensed codeword does not
match that of the specified
TSC card.
TSC has incorrect number of The number of links in the

links TSC card does not match the
number in the codeword.
356 Chapter 13
Upgrading TSCs
Labeling Your Upgrade

The upgrade kit includes a set of labels. Each label corresponds to a
combination of card type and link capability. When you have completed
your upgrade, attach the appropriate label (corresponding to your card
type and new link capability) to the front of the TSC.
Table 13-4 Upgrade Kit Label Set for J3527A
TSC Type No. of Links P/N Label
E1/T1 2 J3527-60002
E1/T1 4 J3527-60004
E1/T1 8 J3527-60008
E1/T1 16 J3527-60016
Table 13-5 Upgrade Kit Label Set for J3527B
E1/T1 1 J3527-60301
E1/T1 2 J3527-60302
E1/T1 4 J3527-60304
E1/T1 8 J3527-60308
E1/T1 16 J3527-60316
Table 13-6 Upgrade Kit Label Set for J3528A
V35 2 J3528-60002
V35 4 J3528-60004
Chapter 13 357
Upgrading TSCs
358 Chapter 13
14 Expanding Platform Processing
Capability
This chapter describes how to expand your platform’s processing

capability without any change of hardware.
Chapter 14 359
Expanding Platform Processing Capability
Overview
Overview
HP OpenCall SS7 allows you to change the processing capabilities of
your platform by expanding (or contracting) the platform’s TCAP
processing capacity.
NOTE These changes are made within the software, without any change of
hardware. However, you should first check whether your planned TCAP
expansion requires you to add a CPU to your platform.
TCAP expansion can be performed offline or online, also referred to as

static expansion and dynamic expansion, respectively.
• Static (Offline) Expansion

Static expansion is performed on a platform with an idle Local Point
Code (SS7 stack). It is configured using SAM.
The procedure for static expansion is provided in “Expanding TCAP
Processing Offline” on page 361.
• Dynamic (Online) Expansion

Dynamic expansion is performed on a running HP OpenCall SS7
platform (with a running Local Point Code). It can be configured
using SAM or from the command line.
The procedures for dynamic expansion are provided in “Expanding
TCAP Processing Online” on page 364.
In SAM, static and dynamic expansion use the same dialog box, but
require different menu paths to reach the dialog box.
360 Chapter 14
Expanding TCAP Processing Offline

This section describes how to expand the TCAP processing capacity on
an offline HP OpenCall SS7 platform, in order to optimize performance.
TCAP expansion on a platform with an idle Local Point Code (SS7 stack)
is referred to as static expansion. The procedure in this section allows
you to expand (or contract) the TCAP processing capacity for more than
one LPC at the same time, if required.
Before following the procedure in this section, you must assess the
feasibility of your planned expansion. You need to determine whether it
is possible to expand the TCAP processing capacity from the currently
configured level to the desired level. However, you do not need to be
concerned with the details of the process redistribution, as the tools
automatically determine this for you. If you first need to add a CPU to
your platform, refer to your server documentation for information on how
to do this.
CAUTION This procedure for static TCAP expansion assumes that the target LPCs
(SS7 stacks) are NOT running (on either host, in the case of a 2-host
platform). If this is not the case, use the dynamic TCAP expansion
procedure provided in “Expanding TCAP Processing Online” on
page 364.
Step 1. Start up SAM.
Step 2. Save a back-up of the current configuration using the Actions|Save As

option in SAM.
Step 3. Highlight the configuration you want to expand.
Step 4. Follow the menu path Actions|View/Modify and then click on the SS7
Performance button.
Chapter 14 361
The following dialog box appears.
Figure 14-1 Configuring TCAP Capacity Level
Step 5. Select the LPC (SS7 stack) for which you wish to change the TCAP
processing capacity. These are listed under Class Name.
Step 6. Select the direction and the number of levels by which you wish to
change the TCAP processing capacity. This is achieved by clicking on the
appropriate button the required number of times:
• Up, if you wish to expand the TCAP processing capacity
• Down, if you wish to contract the TCAP processing capacity.
Each click changes by one level. The cumulative change requested can be
checked by comparing the Initial and New levels that are displayed for
the LPC (Class Name).
If it is not possible to change the performance level of the TCAP

processing because the maximum or minimum level has been reached,
the corresponding button (Up or Down) is grayed out.
362 Chapter 14
Step 7. Repeat Steps 5 and 6 for the other LPCs, if required.
Step 8. Click on OK.
The configuration files are updated according to your changes.
Step 9. Propagate your changes.
NOTE Once you have completed the above procedure, you can start the LPCs
(SS7 stacks).
Chapter 14 363
Expanding TCAP Processing Online

This section describes how to expand the TCAP processing capacity on a
running HP OpenCall SS7 platform, in order to optimize performance.
TCAP expansion on a platform with a running SS7 stack is referred to as
dynamic expansion.
The procedures described in this chapter allow you to expand (or
contract) the TCAP processing capacity for a running Local Point Code
(SS7 stack). This involves first modifying the system configuration and
then applying these modifications to the running system.
This can be carried out either:
• using SAM, as described in “Using SAM” on page 365.

• using commands, as described in “From the Command Line” on
page 367.
NOTE Before following the procedures in this chapter, you must assess the
feasibility of your planned expansion. You will need to determine
whether it is possible to expand the TCAP processing capacity from the
current level to the desired level. However, you do not need to be
concerned with the details of the process redistribution, as the tools will
automatically determine this for you. If you first need to add a CPU to
your platform, refer to your server documentation for information on how
to do this.
By following the procedures below, it is only possible to expand the TCAP
processing capacity corresponding to one LPC at any one time. If you
wish to change the performance level for more than one LPC, you must
follow the complete procedure for each LPC separately and apply the
change to the running system before proceeding to the next change.
364 Chapter 14
Using SAM
CAUTION This procedure for dynamic TCAP expansion assumes that the target
LPC (SS7 stack) is running (on both hosts, in the case of a 2-host
platform). If this is not the case, use the static TCAP expansion
procedure provided in “Expanding TCAP Processing Offline” on
page 361.
Step 1. Start up SAM.
Step 2. Save a back-up of the current configuration using the Actions|Save As

option in SAM.
Step 3. Highlight the RUNNING configuration.
Step 4. Follow the menu path Actions | TCAP Dynamic Tuning.
The following dialog box will be displayed.
Figure 14-2 Configuring TCAP Capacity Level
Step 5. Select the LPC (SS7 stack) for which you wish to change the TCAP
processing capacity. These are listed under Class Name.
Step 6. Select the direction and the number of levels by which you wish to
change the TCAP processing capacity. This is achieved by clicking on the
appropriate button the required number of times:
• Up, if you wish to expand the TCAP processing capacity
Chapter 14 365
• Down, if you wish to contract the TCAP processing capacity.
Each depression of a button corresponds to a change by one level. The

cumulative change requested can be checked by comparing the Initial
and New levels that are displayed for the LPC (Class Name).
Note that if it is not possible to change the performance level of the

TCAP processing because the maximum or minimum level has been
reached, the corresponding button (Up or Down) will be unavailable.
Step 7. Click on OK.
This will prepare the configuration changes but will not apply the
changes to the running system.
Step 8. To apply the configuration modifications to the running system, run the
command ss7TcapTune. This will also modify the system configuration
files.
For details of ss7TcapTune, refer to the relevant man page.
366 Chapter 14
From the Command Line
CAUTION This procedure for dynamic TCAP expansion assumes that the target
LPC (SS7 stack) is running (on both hosts, in the case of a 2-host
platform). If this is not the case, use the static TCAP expansion
procedure provided in “Expanding TCAP Processing Offline” on
page 361.
You can also expand (or contract) the TCAP processing capacity for a
particular LPC from the command line.
You must first use cfgModify -Tcap to prepare the required
configuration modifications. This must be followed by the command
ss7TcapTune, which applies the changes to the running system.
For details of cfgModify and ss7TcapTune, refer to the relevant man
pages.
Chapter 14 367
368 Chapter 14
A Tools Catalog
This appendix contains a catalog of the different tools available for use
with HP OpenCall SS7.
Appendix A 369
Tools Catalog
Graphical Tools
Graphical Tools
The graphical tools described in this section can be used to configure and
monitor HP OpenCall SS7.
Platform Monitor
The interface to the Fault Tolerance Controller. It can be used to monitor
or change process states. It is not itself fault tolerant.
Figure A-1 Platform Monitor Screen
Start and Stop Start and stop the Platform Monitor using the ss7MgrStart and
Commands ss7MgrStop commands.
370 Appendix A
Tools Catalog
Graphical Tools
SS7 Monitor
The SS7 Monitor is used to configure and monitor the SS7 network.
Figure A-2 SS7 Monitor Screen
Start and Stop Start and stop the SS7 Monitor using the ss7MgrStart and ss7MgrStop
Commands commands.
Appendix A 371
Tools Catalog
Graphical Tools
SAM: HP OpenCall Platform Configuration Tool

SAM is the general HP-UX configuration tool. The HP OC Platform
Configuration Tool is integrated into SAM and provides a secure way to
configure the platform. By default you run SAM as root. However, you
can configure a restricted version of SAM to run the HP OC Platform
Configuration Tool as the user ocadmin. Use the sam -r command to do
this.
When you start SAM, a screen providing access to the different areas of
HP-UX Administration appears.
Figure A-3 SAM Initial Screen
HP OC SS7
Platform
Configuratio
n Icon
372 Appendix A
Tools Catalog
Graphical Tools
Double-click the SAM: HP OC Platform Configuration icon to access SS7

configuration.
Figure A-4 HP OC SS7 Platform Configuration Initial Screen
Start and Stop Start SAM by entering the sam command. Close down SAM by choosing
Commands Exit from the File menu.
Web-based Monitor
Use this tool to monitor the state of platform processes. Note that data is
not encrypted during transfer.
Appendix A 373
Tools Catalog
Command Line Tools
Command Line Tools

In addition to the graphical tools listed above, a number of command line
tools are provided with HP OpenCall SS7. Some are complementary to
the graphical tools, providing additional functions. Others provide an
alternative way to carry out the same tasks. In general, if both a
graphical and a command line tool exists, use the graphical tools, as they
provide more rigorous consistency checking and security. Use the
command line version only if the graphical tools are unavailable, or if
you need to work in batch mode.
You can use almost all of the commands as a member of the group
ocadmin. Exceptions are noted in the Comment column.
374 Appendix A
Tools Catalog
Command Line Tools
For detailed information on all of the commands listed in this section,

refer to the man pages.
Table A-1 Platform Configuration Commands
Command Function Comment
cfgCheck Checks configuration Use SAM if available

is coherent.
cfgCreate Creates a new Use SAM if available

configuration.
cfgInstall Installs a new Use SAM if available

configuration.
cfgMigrate Migrates an existing No graphical

HP OpenCall SS7 equivalent
configuration to a
new
HP OpenCall SS7
configuration.
cfgModify Modifies the existing Use SAM if available

configuration.
cfgPatch Patches an existing Use SAM if available

configuration.
cfgPropagate Propagates a Use SAM if available

configuration to all
hosts in a platform.
cfgSs7HwCreate Carries out hardware Use SAM if available

autodiscovery and
fills in hardware
configuration
information as
appropriate.
Appendix A 375
Tools Catalog
Command Line Tools
Table A-2 Platform Start and Stop Commands
ocftcontrol Changes the state of

the platform
processes.
ss7Start Starts the SS7 This must be run on

Platform. the Front End.
ss7Stop Stops the SS7 This must be run on

Platform. the Front End.
Table A-3 Platform Management Commands
ocftstatus Displays information

on processes
managed by FTCs
and sub-FTCs
running on a cluster.
ss7MgrStart Starts the Platform

Monitor and the SS7
Monitor.
ss7MgrStop Stops the Platform

Monitor and the SS7
Monitor.
ss7RMonStart Starts the SS7

Monitor alone.
FT_Monitor Starts the Platform

Monitor alone.
Table A-4 Stack Related Commands
loadconf Loads a configuration

from an existing file.
376 Appendix A
Tools Catalog
Command Line Tools
Table A-4 Stack Related Commands (Continued)
mtpCtrl Activates and Only used on

deactivates platforms with
individual elements M3UA.
in the local MTP
endpoint instances.
m3uaCtrl Activates and

deactivates
individual elements
in the local M3UA
endpoint instances.
ocNetworkControl Activates and

deactivate the local
endpoint instances,
whatever the
running protocols,
ocNetworkStatus Displays network

entity states and
statistics for
M3UA-based
networks.
ss7CheckPoint Saves the stack Can also be done

configuration to a from within the SS7
file. Monitor
ss7GuardianAngel Detects any failure of Designed to run

the SS7 stack and permanently as a
triggers a switchover daemon
if needed.
ss7GuardianSwitch Triggers the Designed to run

switchover of a fault permanently as a
tolerant process. daemon
ss7TcapTune Dynamically updates

the TCAP level.
Appendix A 377
Tools Catalog
Command Line Tools
Table A-5 ISUP Commands
isupgenANSI Sets up and releases

ISUP calls for test
isupgenITU
purposes.
ss7IsupReload Dynamically reloads

the ISUP
configuration.
Table A-6 Hardware Related Commands
ss7DiagStart Tests and

troubleshoots the
SS7 links.
ss7HwAccept Replaces the current

hardware
configuration with an
loaded configuration.
ss7HwInfo Displays information

on SS7 hardware.
ss7HwInit Initializes SS7 Use SAM if available

hardware.
ss7HwLoad Loads a new

hardware
configuration.
ss7HwReplace Automatically
updates the
hardware
configuration after a
hardware
replacement.
378 Appendix A
Tools Catalog
Command Line Tools
Table A-6 Hardware Related Commands (Continued)
ss7HwRollback Deletes the updated

hardware
configuration file and
reloads the previous
one.
ss7TscPing Pings TSC.
ss7TscStatus Displays TSC status.
ss7TscUpgrade Upgrades the

number of links on a
TSC.
ss7TsuPing Obtains the LAN

paths and MAC
addresses the TSU
connections to a
given host.
ss7TsuStatus Displays TSU status.
Table A-7 Log Related Commands
auditCatalog Displays a message

from a message
catalog in a readable
format.
The cause of the log
message is given if
available and any
relevant action to
take to correct the
problem.
cleanttl Stops logging and You must be root to
cleans out existing use this command
log files.
Appendix A 379
Tools Catalog
Command Line Tools
Table A-7 Log Related Commands (Continued)
nlog Displays logs without

opening a new
window.
nmsg Displays traces

without opening a
new window.
ss7SNMPAgent Maps logs to SNMP Enter the

traps. -displayTrapDoc
option to list all
available traps
ss7HwTrace Manages logs and

traces for TSCs and
TSUs.
startnettl Starts logging. You must be root to

use this command.
stopnettl Stops logging. You must be root to

use this command.
wlog Opens a log window.
wmsg Opens a trace

window.
NOTE Traces are not a feature of the HP OpenCall SS7 product. As such, they
are not supported, maintained or documented, and there is no
commitment regarding their stability. Traces are tools used to debug the
HP OpenCall SS7 product itself rather than customer applications.
Traces can change over time and they may even disappear.
380 Appendix A
Tools Catalog
Command Line Tools
CAUTION You should use traces only if requested to do so by HP support personnel.
The tracing utility (nmsg) must be strictly restricted to the

troubleshooting of abnormal situations under the guidance of HP
support.
Table A-8 Traffic Generation Commands
isupgenANSI Generates ISUP

traffic for test
isupgenITU
purposes.
tcxgen Generates TCAP

traffic for test
purposes.
trafgen Generates MTP

traffic for test
purposes.
Table A-9 Other Commands
collectInfo Collects information Intended primarily

on system, for use by HP support
versioning, personnel.
configuration and
debugging the
platform.
ocLicense Displays and updates

licensing
information.
Appendix A 381
Tools Catalog
Command Line Tools
382 Appendix A
B Telecom Signaling Cards
(J3527A/J3527B and J3528A)
This appendix describes the Telecom Signaling Cards (TSCs) that can be
used to connect an HP OpenCall SS7 platform to the SS7 network.
Appendix B 383
Telecom Signaling Cards (J3527A/J3527B and J3528A)
Function
Function
The Telecom Signaling Card (TSC) provides the means of connecting an
HP OpenCall SS7 platform to the signaling network. These cards can be
accommodated in either:
• a Telecom Signaling Unit (TSU) which connects to the host and to

the signalling network
• a host server with a PCI bus that can take TSCs directly. This is
referred to as TSC-in-system.
A Telecom Signaling Card has four physical ports available for
connection to the network. Each of these ports is assigned to one or more
links. The number of possible links depends on the type of TSC used.
384 Appendix B
Types of Telecom Signaling Card
Types of Telecom Signaling Card

There are two types of TSC:
• V.35 Cards
These are TSCs that communicate using the V.35/V.36 standard
(DTE or DCE). The choice of cable determines whether the card uses
the DTE or DCE interface type.
These cards have 4 DTE ports or 4 DCE ports, and 4 SS7 links.
DTE/DCE can operate at 48.5 (TTC standard only), 56 or 64 kbits/s.
• E1/T1 Cards
These are TSCs that communicate using the E1 or T1 standard
(standard G.703). The choice of cable determines whether the card
uses the E1 or T1 interface type.
These cards have 4 E1 ports or 4 T1 ports, and can support up to 16
SS7 links.
NOTE Do not mix card types in a single Telecom Signaling Unit or host server.
If you wish to use V.35, E1 and T1 TSCs with your platform, you must
install each card type in a separate TSU.
Appendix B 385
Physical Description
Ready-to-install V.35 and E1/T1 TSCs comprise a 32-bit V.35 or E1/T1
universal telecom signaling PMC card mounted on a full-length PCI
adapter card. The PMC card implements the physical line interface to
the SS7 network.
The physical details of each type of TSC are described below.
V.35 Telecom Signaling Card

The figure below shows the V.35 Telecom Signaling Card mounted on the
adapter card.
Figure B-1 V.35 Telecom Signaling Card
386 Appendix B
LEDs Refer to “Checking LEDs” on page 309 for a description of the LEDs.
Ports and Links The V.35 TSC has four ports. You can assign a single SS7 link to each of
these ports. The card is available with 2 or 4 links.
Part Numbers The part number of a V.35 TSC depends on the number of links that it
supports, as follows:
HP Part Number of
Number Links
J3528-60002 2
J3528-60004 4
Upgrading the A V.35 TSC is supplied with a defined number of links, as detailed above.
Number of Links This number can be upgraded (up to a maximum of 4) without removing
the card from the platform. Refer to the “Adding and Activating Links on
the SS7 Stack” on page 340 for information on upgrading the TSC link
capability.
Appendix B 387
E1/T1 Telecom Signaling Card

The figure below shows the E1/T1 Telecom Signaling Card mounted on
the adapter card.
Figure B-2 E1/T1 Telecom Signaling Card
LEDs Refer to “Checking LEDs” on page 309 for a description of the LEDs.
Ports and Links The E1/T1 TSC has 4 ports and is available with 2, 4, 8 or 16 links. You
can assign up to 16 links to any one port. Each link can be assigned to
any valid timeslot, on any port.
388 Appendix B
Part Numbers The part number of an E1/T1 TSC depends on the number of links that it
supports, as follows:
Table B-1 E1/T1 HP Part Numbers
HP Part Number Number of Links
J3527A J3527B
J3527-60301 1 HSL-CCC
J3527-60002 J3527-60302 2
J3527-60004 J3527-60304 4
J3527-60008 J3527-60308 8
J3527-60016 J3527-60316 16
Upgrading the An E1/T1 TSC is supplied with a defined number of SS7 links that it can
Number of Links support, as detailed in the above table. The number of links supported
can be increased to a maximum of 16. This upgrade can be performed
without removing the card from the platform.
Refer to “Adding and Activating Links on the SS7 Stack” on page 340 for
information on upgrading the TSC link capability.
Appendix B 389
TSC Connectors and Cables

This section describes the connectors and cables required to connect a
Telecom Signaling Card to the signaling network. A TSC is connected to
the signaling network from a connector on the end-plate of its PCI
adapter card.
The connectors and cables required depend on the type of TSC (and, in
the case of an E1/T1 card, the telecommunications protocol to be used).
Four sets of connectors are described here:
Section
Connection Description
Reference
E1 To connect an E1/T1 TSC to the “E1 Connections”

network using the E1 protocol. on page 391
T1 To connect an E1/T1 TSC to the “T1 Connections”

network using the T1 protocol. on page 396
V.35 To connect a V.35 TSC to the “V.35 Connections”

network. on page 397
Loopback To connect up a TSC for “Loopback Hoods”

loopback testing. on page 402
In addition, the optional connection panels that can be used to organize

TSC cabling are described in “Connection Panels” on page 409.
390 Appendix B
E1 Connections
This section describes the connections required to connect an E1/T1 TSC
to the signaling network, when the E1 protocol is to be used.
The E1 cable assembly connects to the E1/T1 TSC by means of a 36-pin
male connector, shown in Figure B-3.
Figure B-3 TSC 36 Pin Connector (E1/T1)
Appendix B 391
The cable assembly provides four ports to the network. These ports may
interface to the network using either four RJ-45 connectors or eight BNC
connectors (grounded or ungrounded). The RJ-45 and BNC connector
types are illustrated in the figures below.
Figure B-4 RJ-45 Connector (E1/T1)
Figure B-5 BNC Connector
392 Appendix B
E1 Connector The pinouts for the three types of E1 cable assembly are provided in the
Pinouts tables below. Each table lists the pins of the relevant port connector(s)
and for each port gives the corresponding pins on the 36-pin TSC
connector.
Table B-2 E1 RJ-45 Connector Pinouts
I/O
RJ-45 Signal (Input/
TSC Connector Pin
Pin Name Output
)
Port Port Port Port

0 1 2 3
01 35 31 25 21 RX1-x I
02 36 32 26 22 RX2-x I
03, 06 16 12 9 4 FGND- -
x
04 33 29 23 19 TX1-x O
05 34 30 24 20 TX2-x O
Table B-3 E1 BNC Connector Pinouts - Grounded
I/O
BNC
Signal (Input/
Conduct TSC Connector Pin
Name Output
or
)
Port Port Port Port

0 1 2 3
RX Inner 35 31 25 21 RX1-x I
TX Inner 33 29 23 19 TX1-x O
TX and Housing, FGND -

RX Outer TX2-x
20, 22, 24, 26, 30, 32, 34, 36
RX2-x
Appendix B 393
Table B-4 E1 BNC Connector Pinouts - Ungrounded
I/O
BNC
Signal (Input/
Connect TSC Connector Pin
Name Output
or
)
Port Port Port Port

0 1 2 3
RX Inner 35 31 25 21 RX1-x I
RX Outer 36 32 26 22 RX2-x I
TX Inner 33 29 23 19 TX1-x O
TX Outer 34 30 24 20 TX2-x O
- 16 12 8 4 FGND -
E1 Cable When constructing an E1 cable assembly, you should follow the

Specification guidelines below:
• 24 AWG copper conductor, twisted pair telephone cable.

• Impedance
— E1 balanced 120 ohms

— E1 unbalanced 75 ohms
• DC resistance (single conductor) of 23.7 ohms/1000 meters.
• Shunt capacity of 16 pF/foot.
• Shield terminated with a “frame ground” pin.
394 Appendix B
The table below lists the corresponding cable assemblies and their HP
part numbers.
Table B-5 E1 Cable Assemblies
Cable
Network
Cable Assembly Assembly HP
Connectors
Part Number
BNC Unbalanced, 8 BNC (2 per 5063-1330

Grounded port)
BNC Unbalanced, 8 BNC (2 per 5063-1331

Ungrounded port)
RJ-45 Balanced 4 RJ-45 (1 per 5063-1338

port)
Appendix B 395
T1 Connections
This section describes the connections required to connect an E1/T1 TSC
to the signaling network, when the T1 protocol is to be used.
The T1 cable assembly connects to the E1/T1 TSC by means of a 36-pin
male connector, shown in Figure B-3 on page 391.
The cable assembly then provides four ports that interface to the
network using four RJ-45 connectors. The RJ-45 connector type is
illustrated in Figure B-4 on page 392.
T1 Connector The pinouts for the T1 cable assembly are provided in the table below.
Pinouts The table lists the pins of the port connector and for each port gives the
corresponding pins on the 36-pin TSC connector.
Table B-6 T1 RJ-45 Connector Pinouts
I/O
RJ-45 Signal (Input/
TSC Connector Pin
Pin Name Output
)
Port Port Port Port

0 1 2 3
1 35 31 25 21 RX1-x I
2 36 32 26 22 RX2-x I
3, 6 16 12 9 04 FGND- -
x
4 33 29 23 19 TX1-x O
5 34 30 24 20 TX2-x O
T1 Cable T1 cables have an impedance of 100 ohms.

Specification
396 Appendix B
The table below gives the corresponding cable assembly and its HP part
number.
Table B-7 T1 Cable Assembly
Cable
Cable Network
Assembly HP
Assembly Connectors
Part Number
RJ-45 4 RJ-45 (1 per 5063-1339

port)
V.35 Connections
This section describes the connections required to connect a V.35 TSC to
the signaling network.
The V.35 cable assembly connects to the V.35 TSC by means of a 120-pin
male D-shell connector, shown in Figure B-6 below.
Figure B-6 TSC Connector (V.35)
There are two types of V.35 cable assembly that can be used. One
provides a DTE protocol connection and the other provides a DCE
protocol connection.
Appendix B 397
A V.35 cable assembly provides four ports to the network. These ports
interface to the network using four 34-pin female DCE connectors or four
34-pin male DTE connectors. These are illustrated below in Figure B-7
and Figure B-8 respectively.
Figure B-7 V.35 DTE Connector
Figure B-8 V.35 DCE Connector
398 Appendix B
V.35 Connector The pinouts for the V.35 DTE and DCE cable assemblies are provided
Pinouts below in Table B-8 and Table B-9 respectively. Each table lists the pins of
the relevant port connector and for each port gives the corresponding
pins on the 120-pin TSC connector.
Table B-8 V.35 DTE Connector Pinouts
I/O
Signal (Input/
DTE Pin TSC Connector Pin
Name Output
)
Port Port Port Port

0 1 2 3
A - - - - Shield -
B 110 50 10 70 GND -
C 114 54 6 66 RTSx O
D 120 60 15 75 CTSx I
E 98 38 22 82 DSRx O
F 94 34 26 85 CDx I
H 112 52 8 68 DTRx O
P 118 58 2 62 TXDxA O
R 96 36 24 84 RXDxA I
S 119 59 3 63 TXDxB O
T 97 37 25 85 RXDxB I
U 116 56 4 64 TCLKOxA O
V 108 48 12 72 RXCLKxA I
W 117 57 05 65 TCLKOxB O
X 109 49 13 73 RXCLKxB I
Y 102 42 18 78 TCLKIxA I
AA 103 43 19 79 TCLKIxB I
Appendix B 399
Table B-9 V.35 DCE Connector Pinouts
I/O
Signal (Input/
DCE Pin TSC Connector Pin
Name Output
)
Port 0 Port 1 Port 2 Port 3
C 120 60 15 75 CTSx I
D 114 54 6 66 RTSx O
E
114 54 6 66 RTSx O
F
94 34 26 85 CDx I
H
98 38 22 82 DSRx O
P 96 36 24 84 RXDxA I
R 118 58 2 62 TXDxA O
S 97 37 25 85 RXDxB I
T 119 59 3 63 TXDxB O
U 108 48 12 72 RXCLKxA I
V (and Y) 116 56 4 64 TCLKOxA O
W 109 49 13 73 RXCLKxB I
X (and 117 57 05 65 TCLKOxB O

AA)
Y (and V) 116 56 4 64 TCLKOxA O
AA (and 117 57 05 65 TCLKOxB O

X)
400 Appendix B
The table below lists the corresponding cable assemblies and their HP
part numbers.
Table B-10 V.35 Cable Assemblies
Cable
Cable Network
Assembly HP
Assembly Connectors
Part Number
DTE 4 DTE (1 per 5063-1362

port)
DCE 4 DCE (1 per 5063-1332

port)
Appendix B 401
Loopback Hoods
Loopback hoods are used in the hardware validation procedure to
connect the output of a TSC network port to the input of the same TSC
network port. This allows a TSC to be operated and tested without direct
connection to the network. There are two general types of loopback hood:
• Cable Loopback Hoods: These connect to the end of the TSC

cables (to the network end) and can therefore be used to test the
operation of the TSC in conjunction with the TSC network cables.
These hoods are available in three types, for the different types of
cable, and are supplied with the cables:
Table B-11 Card Loopback Hood HP Part Numbers
Loopback Hood HP Part

Type Number
E1/T1 RJ-45 5063-1340
V.35 DTE 5063-1334
V.35 DCE 5063-1335
Note that Cable Loopback Hoods are not supplied for E1/T1 BNC
cables, since loopback is easily accomplished with these cables.
402 Appendix B
• Card Loopback Hoods: These connect directly to the TSC (to the
TSC end-plate connector on the rear panel of the TSU) and can
therefore be used to test the operation of the TSC in isolation from
the TSC network cables. These hoods are available in two types, for
the different types of card, and are supplied with the cards:
Table B-12 Cable Loopback Hood HP Part Numbers
Loopback Hood HP Part

Type Number
E1/T1 5063-1346
V.35 5063-1336
Appendix B 403
Loopback Pinouts The pinouts for the above loopback hoods are given in the tables that
follow. Each table details the pair of pins of the relevant connector that
must be connected together.
Table B-13 V.35 DTE Cable Loopback Pinout
From To
Signal Pin Signal Pin
TXDxA P
RXDxA R
TCLKIxA Y
TXDxB B
RXDxB T
TCLKIxB AA
TCLKOxA U RCLKIxA V
TCLKxB W RCLKIxB X
RTSx C CTSx D
CDx F
DSRx E
DTRx H
Table B-14 V.35 DCE Cable Loopback Pinout
From To
RXDxA R TXDxA P
RXDxB T TXDxB S
RCLKxA V TTExA U
RCLKxB X TTExB W
RTSx D CTSx C
DSRx E DTRx H
404 Appendix B
Table B-15 V.35 TSC Card Loopback Pinout
From To
DSR0A 98
DTR0A 112
CD0A 94
DSR0B 99
CD0B 95
DTR0B 113
GND 110
ID0_P1 92
RXD0A 96
TXD0A 118
TXCLK10A 102
RXD0B 97
TXD0B 119
TXCLK10B 103
RXD012V 104
TXD012V 105
TXCLK1012V 91
RTS0A 114 CTS0A 101
TXCLK0A 116 RXCLK0A 108
TXCLK0B 117 RXCLK0B 109
TXCLK0012V 111 RXCLK012V 106
DSR1A 38
DTR1A 52
CD1A 34
DSR1B 39
DTR1B 53 CD1B 35
GND 50
RXD1A 36
TXD1A 58
TXCLK11A 42
Appendix B 405
Table B-15 V.35 TSC Card Loopback Pinout (Continued)
From To
RXD1B 37
TXD1B 59
TXCLK11B 43
RXD112V 44
TXD112V 45
TXCLK1112V 31
RTS1A 54 CTS1A 40
RTS1B 55 CTS1B 41
DSR2A 22
DTR2A 8
CD2A 26
DSR2B 23
DTR2B 9 CD2B 27
GND 10
RXD2A 24
TXD2A 2
TXCLK12A 18
RXD1B 25
TXD2B 3
TXCLK12B 19
RXD212V 16
TXD212V 17
TXCLK1212V 30
RTS2A 6 CTS2A 20
RTS2B 7 CTS2B 21
406 Appendix B
Table B-15 V.35 TSC Card Loopback Pinout (Continued)
From To
DSR3A 82
DTR3A 68
CD3A 86
DSR3B 83
DTR3B 69 CD3B 87
GND 70
RXD3A 84
TXD3A 62
TXCLK13A 79
RXD3B 85
TXD3B 77
TXCLK13B 79
RXD312V 76
TXD312V 77
TXCLK1312V 90
RTS3A 66 CTS3A 80
RTS3B 67 CTS3B 81
Appendix B 407
Table B-16 E1/T1 RJ-45 Cable Loopback Pinout
From To Notes
TX1x 4 RX1x 1
TX2x 2 RX2x 5
Cable ID - Cable ID - 8 No cable ID resistor

7
poll sense required
Table B-17 E1/T1 TSC Card Loopback Pinout
From To
ID0 9 GND0 18
ID1 10 GND1 14
ID2 27 GND2 6
ID3 28 GND3 2
TX1_0 33 RX1_0 35
TX2_0 34 RX2_0 36
TX1_1 29 RX1_1 31
TX2_1 30 RX2_1 32
TX1_2 23 RX1_2 25
TX2_2 24 RX2_2 26
TX1_3 19 RX1_3 21
TX2_3 20 RX2_3 22
408 Appendix B
Connection Panels
To aid installation and maintenance, all cabling between a TSC and the
signaling network can be routed via an optional connection panel in the
server cabinet in which the TSCs are located (the TSCs are housed either
directly in the server or in one or more Telecom Signaling Units located
in the server cabinet).
The connection panel contains a number of sockets of a certain type, each
corresponding to one TSC port. The TSC cables connect to the sockets of
the panel from where they are connected to the network.
Connection panels are available from HP for the different types of cable
assembly. These are listed in the table below which details the number of
TSC ports supported, along with the HP product number and part
number.
Table B-18 Connection Panels
Connection Connection
Connector Number
Panel HP Panel HP Part
Type of Ports
Product Number Number
RJ-45 Grounded 12 J3844A J3844-80100
BNC Grounded 12 J3845A J3845-80100
BNC 12 J5980A J5980-80100

Ungrounded
V.35 8 J3848A J3848-80100
Appendix B 409
A BNC connection panel is illustrated in Figure B-9. The RJ-45

connection panel is similar but with one hole per port.
Figure B-9 BNC Connection Panel
410 Appendix B
TSC Electrical and Environmental Specifications
TSC Electrical and Environmental

Specifications
This section provides electrical and environmental information for TSCs.
This includes power supply requirements as well as operational and
non-operational environmental requirements.
Power Supply The power consumption of a TSC is 13.5 W.
Environmental The table below provides the operational and non-operational

Requirements environmental requirements for a TSC. If you require any additional
environmental information, contact Hewlett-Packard.
Table B-19 TSC Environmental Requirements
Operational Non-Operational
Parameter
Range Range
Temperature 0°C to 55°C Storage: 0°C to 60°C

Shipping: -40°C to
70°C
Humidity 5% to 95% Storage: 5% to 80%

(Non-Condensing)
Shipping: 5% to 100%
Appendix B 411
Chained TSCs
Chained TSCs
It is possible to connect two E1/T1 TSCs in a daisy chain arrangement in
which only one of the TSCs is directly connected to the SS7 network. This
allows the platform to increase the number of timeslots that it can use in
a single frame on the network. The chained TSCs architecture is
illustrated in Figure B-10, “Example of Chained TSCs.”
For example, an E1 TSC has a link capacity of 16 links, which allows it to
use up to 16 of the 31 timeslots in an E1 frame. A single physical
connection to the SS7 network provides access to the timeslots of a single
frame. By connecting this TSC to another E1 TSC, such that they share
the same physical network connection, they can potentially use all 31
timeslots of the E1 frame.
Figure B-10 Example of Chained TSCs
The two TSCs can be located in the same host server, the same TSU or
different TSUs.
412 Appendix B
C Telecom Signaling Units
(J3401A)
This appendix describes the Telecom Signaling Unit (TSU) which can be
used to the accommodate the Telecom Signaling Cards (TSCs).
Appendix C 413
Telecom Signaling Units (J3401A)
Function
Function
The Telecom Signaling Unit (TSU) provides accommodation for the
following PCI cards:
• Telecom Signaling Cards (TSCs)

The TSCs provide the physical connectivity to the signaling network.
• CPU Card
The CPU card is supplied pre-installed in the TSU and provides a
LAN connection to the host computer.
• LAN Card
A LAN card can be installed to provide the connectivity to a second
host computer, for example, in a 2-host system.
A TSU can be employed as part of:
• a 1-host platform based around a host server which does not have an
internal PCI bus (and therefore cannot accommodate Telecom
Signaling Cards directly)
• a 1-host platform requiring more SS7 links than can be provided by a
TSC-in-system server
• a 2-host platform (for High Availability).
Up to eight TSUs can be connected to an SS7 platform.
414 Appendix C
The Telecom Signaling Unit is an external chassis that can accommodate
PCI cards. The cards are mounted in a removable card cage which
incorporates the PCI backplane and a CPU card. The backplane has
seven slots:
• Five slots are reserved for Telecom Signaling Cards.

The number of TSCs that can be accommodated depends on the type
of cards, as follows:
— up to five V.35 cards (in slots 1, 2, 3, 4 and 5), or

— up to three E1/T1 cards (in slots 1, 3 and 5).
• The other two slots are reserved for:
— the TSU’s fixed CPU card (slot L0) which also provides a LAN
connection to the host computer.
— a LAN card (slot L1) which can be installed to provide a
connection to a second host.
A TSU is connected to a host computer via a dedicated point-to-point
100 BASE-T LAN interface to a 100 BASE-T card on the host:
• For K-class servers, this host card is an HSC dual-port card allowing
up to two TSUs per HSC slot.
• For A-, L- and N-class servers, this host card is a single or quad-port
PCI card, allowing up to four TSUs per PCI slot.
NOTE Do not mix Telecom Signaling Card (TSC) types in a single TSU. If you
want to use more than one TSC type with your platform, install each
TSC type in a separate TSU.
NOTE It is not possible to have a dual LAN connection between a TSU and a
single server.
Appendix C 415
Power Supplies A TSU can be run from an AC or DC power supply. Details of these power
supplies are provided in “TSU Electrical and Environmental
Specifications” on page 419.
The power supply unit of a DC powered TSU is attached to two power
rails for High Availability (so that if one rail fails, power is still
available).
Part Numbers The part number of a TSU depends on the power supply, as follows:
HP Part
Power Supply
Number
J3401-60003 AC powered
J3401-60004 DC powered
TSU Cabinet The dimensions of the TSU cabinet are given in the table below.
Table C-1 TSU Dimensions
Height Width Depth
86.89 mm (3.421”) 431.80 mm (17”) 464.21 mm (18.28”)
416 Appendix C
The following figures show the front view of the TSU, the unit with the
frontplate removed, and the back view of the TSU. The status LEDs on
the front and back are described in “Checking the Hardware
Installation” on page 248.
Figure C-1 Telecom Signaling Unit - Front View
Figure C-2 Telecom Signaling Unit - Front View with Frontplate Removed
Appendix C 417
Figure C-3 Telecom Signaling Unit (AC Powered) - Back View
418 Appendix C
TSU Electrical and Environmental Specifications
TSU Electrical and Environmental

Specifications
This section provides electrical and environmental information for TSUs.
This includes power supply requirements as well as operational and
non-operational environmental requirements.
AC Power Supply The power supply requirements for a TSU operating from an AC supply
are presented in the table below.
Table C-2 AC Power Supply Specifications for a TSU
Input Current 100-127 V AC input: 3 A

200-240 V AC input: 1.3 A
Input Voltage Primary 100-127/200-240 V AC

AC:
50-60 Hz
(auto-ranging)
Outputs +5V @ 24 A (min)

+12V @ 1.75 A (min)
Compliance with UL1950

Standards
CSA22.2 #950
VDE0805
EN60950
IEC950
EN55022A
FCC Class A
Appendix C 419
DC Power Supply A DC powered TSU can operate in the voltage range -48 V to -60 V. The
power supply requirements for a TSU operating from a DC supply are
presented in the table below.
Table C-3 DC Power Supply Specifications for a TSU
Input Current for -40 V DC input: 8 A

for -76 V DC input: 3.5 A
Input Voltage TNV-2 DC: -40 to -72 V DC with dual

input
Outputs +5 V @ 24 A (min)
+12 V @ 1.75 A (min)
Compliance with UL1950

Standards
CSA22.2 #950
VDE0805
EN60950
IEC950
EN55022A
FCC Class A
FTZ1046/84
Figure C-4 below shows the DC power supply connector and the
connector pinout. This is the connector at the TSU end of the power
supply cable.
420 Appendix C
WARNING The power supply cable has been evaluated for use as an internal
wire only and must be installed in a cabinet for the system to
retain its safety regulatory markings.
Figure C-4 DC Power Supply Connector
Table C-4 DC Power Supply Connector Pinout
Signal Pin
DC Return 7
DC 1
DC Return 8
DC 4
Not Used 2,3,5,6.
Appendix C 421
Environmental The table below provides the operational and non-operational

Requirements environmental requirements for a TSU. If you require any additional
environmental information, contact Hewlett-Packard.
Table C-5 TSU Environmental Requirements
Non-Operational
Parameter Operational Range
Range
Temperature 0°C to 50°C -40°C to 70°C
Humidity
5% to 95% relative humidity
(Non-Condensing)
422 Appendix C
Index
A buffered file I/O, limitations of use, 25
activating
local endpoint (M3UA), 377 C
SNMP Traps, 177 cables, 390
active failure, 224 E1, 394, 395
ACTIVE state T1, 397
process, 172 V.35, 401
adding card
hardware component (M3UA-based cage, 265, 302, 415
platform), 254 cfgCheck, 81, 82, 375
new feature codewords, 197 using, 96
address cfgCreate, 81, 375
adding new (for M3UA), 189 cfgInstall, 81, 375
IP, 215 cfgMigrate, 375
relocatable IP address, 88 cfgModify, 81, 367, 375
switching, 215 cfgPatch, 375
addresses cfgPropagate, 81, 375
IP, 64 cfgSs7HwCreate, 375
administrator cfgss7HwCreate, 81
Stack Monitor interface, 101 checking
LANs, 174
aligning
MTP2, 166 the configuration, 345
MTP3, 166 the configuration with ss7HwLoadConfig,
ANSI 344
full point code routing, 109 checkpointing
anti-static a new stack configuration, 101, 162
kit, 19 manually, 162
precautions, 19 MTP-based configuration, 162
apache server, 27 child process, death of, 223
application cleanttl, 379
buffered I/O, 25 cleanup process, 212
downtime, 202 clock-jump, 26
failure, 219 cluster, 222
MC/ServiceGuard, 202
memory usage, 25
name, 207
number of processes, 23 cluster lock
Application Guardian (PIC/AG), 227 device parameters, 208
application services as packages, 204 cmcld daemon, 223
AS
local AS parameters, 157 cmmakepkg command, 211, 214
cmquerycl command, 207
remote AS parameters, 134, 137 codewords (license)
auditCatalog, 379 adding, 197
automatic start, 218 collectInfo command
commands
B collectInfo, 381
Back End command
prerequisites, 25 ftp, 65
battery backup, 26 commands
BOOTING state isupgenXXX, 378, 381
process, 172 m3uaCtrl, 377
bridge, isolating the LANs, 24 ocLicense, 381
423
Index
ocNetworkControl, 377 V.35, 397
ocNetworkStatus, 377 connectivity
tcxgen, 381 validating M3UA, 167
trafgen, 381 validating MTP2, 166
wlog, 380 validating MTP3, 166
wmsg, 380 validating SS7, 166
commands, startup, 218 connector, 390
commercial license BNC, 392
migrating to, 198 loopback hoods, 402
concerned local user RJ-45, 392
parameters for M3UA, 145 TSC (E1/T1), 391
conditions TSC (V.35), 397
operating, 23 TSU rear panel, 243
configuration, 248 V.35 (DCE), 398
checking before startup, 218 V.35 (DTE), 398
checkpointing MTP-based configuration, copying large files, 26
162 CPU
M3UA example, 152 load constraints, 23
safeguarding, 19 usage, 23
SNMP Traps, 176 CPU card, 238, 265, 414, 415
updating M3UA network configuration, 155 customer defined functions, 215
validation, 96
XML file example, 150, 153, 160 D
configuration file DCE, 385, 397
template, 211 deactivating
configured nodes (hosts), 211 local endpoint (M3UA), 377
configuring PINS, 91
checking the configuration, 345 death of child process, 223
file location, 81 default shell, 215
files for stack, 81 destination
M3UA, 64 configuring as gateway, 105
MTP3, 69 out-of-service, 186
network for M3UA, 111 deterministic behavior of operating system,
network for SCCP, 111 23
PINS, 90 dimensioning main memory, 25
relocatable IP address, 88 DOWN state
configuring PIC/AG, 227 process, 172
conflict DTE, 385, 397
in failure detection, 204 duplex platforms
congested route, destination, 185 cabling recommendations, 245
connection
M3UA level, 167 E
MTP3 level, 167 E1 cards, 385, 388
connection panels, 241, 409 cable assembly, 395
connections, 243 connections, 391
E1, 391 ports, 388
LAN, 244, 245, 415 editing
T1, 396 XML configuration file, 164
TSC to network, 244 electrical specifications, 411, 419
TSU to host, 244, 245 environment variables, 215
424
Index
environmental specifications, 411, 419 HA status
etc/opt/HP-AIN/config/, 81 PINS, 92
etc/opt/OC, 81 hardware
Event Display adding component (M3UA-based platform),
location, 25 254
examples adding component (MTP-based platform),
M3UA configuration, 152 252
XML configuration file, 150, 153, 160 moving component (M3UA-based
exclusive mode, 214 platform), 254
moving component (MTP-based platform),
F 252
failed destination, 186 replacing component (M3UA-based
fail-fast, 223 platform), 254
failure replacing component (MTP-based
application, 219 platform), 252
HP OC SS7 and MC/ServiceGuard conflict, heartbeat, 222
204 High Availability, 26
of active and standby, 224 SS7 processes, 202
of stack, 224 user applications, 202
platform state before and after, 224 hosts
response of HP OC SS7, 203 front-end, 26
response of MC/ServiceGuard, 203 HOT-STANDBY state
single point of, 219 process, 172
stack, 219 HP-UX
failure detection installation, 96
reaction of HP OC SS7 and hubs
MC/ServiceGuard, 222 recommendation, 53
failure response
MC/ServiceGuard, 202 I
fans, 256, 310, 417 inhibit links, 186
file installation
copying, 26 cards into a new TSU, 238
limitations on size for copying, 26 checking, 309
MC/ServiceGuard configuration file, 207 connecting up TSU/TSCs, 243
structure of XML file, 115 LAN card into TSU, 239, 269
file SS7Guardian kit configuration file, 207 TSC into host server, 291
FT_Monitor, 376 TSC into TSU, 239, 275, 281, 296
FTC, 224, 225
stopping using ss7Stop, 94 TSU into server cabinet, 240
validation, 37
function, customer-defined, 215
IP address
adding new for M3UA, 189
G
configuring for M3UA, 64
gateway, configuring, 105 in ServiceGuard script, 215
relocatable, 88
H isupgenXXX command, 378, 381
HA
validating, 172 L
HA processes LAN
stopping using ss7Stop, 94 card (in TSU), 414
425
Index
checking, 174 M
connections, 244, 245, 415 M3UA
dimensioning, 24 activating local endpoint, 377
installing card in TSU, 239 adding new IP address, 189
installing LAN card, 269 concerned local user parameters, 145
LEDs, 312 configuration example, 152
media and adaptor failure, 202 configuring IP addresses, 64
polling, 222 configuring network, 111
replacing LAN card, 271, 338 connecting, 167
supported types, 24 deactivating local endpoint, 377
lanscan, 215 local AS parameters, 157
LEDs, 309 migrating from MTP3, 161
LAN card, 312 monitoring network, 190
TSC, 312 network parameters, 133
TSU, 309 remote AS parameters, 134, 137
license remote SG parameters, 128
migrating to commercial, 198 updating network configuration, 155
procedure, 197, 198
validating connectivity, 167
link
adding to a TSC or TSU, 348 validating platform, 72
M3UA-based platform
configuring, 106
adding hardware component, 254
E1/T1, 388 moving hardware component, 254
inhibit, 186
replacing hardware component, 254
licenses, 348
m3uaCtrl command, 377
number per port, 348 MAC address, 215
number per TSC, 348 maintenance procedures, 249
upgrading, 387, 389 installing a LAN card, 269
utilization rate, 185 installing a new TSC in a host server, 291
V.35, 387 installing a new TSC in a TSU, 275, 281, 296
Link-level message, 222 replacing a LAN card, 271
linkset replacing a TSC in a TSU, 277, 293
configuring, 106 replacing a TSU, 285
Linkset/Link Activation Behavior, 185 replacing a TSU fan, 256
load constraints on CPU, 23 replacing TSU AC power supply, 259
loadconf, 376
local AS replacing TSU backplane and CPU card,
parameters for M3UA, 157 265
local endpoint (M3UA) replacing TSU DC power supply, 262
activating/deactivating, 377 man page
local switch SS7GuardianAngel, 220
PINS, 91 SS7GuardianSwitch, 221
locally switch LAN, 213 man page, adding PATH to enable access, 22
lock, cluster, 222 MC/ServiceGuard
log configuration file, 207
viewing, 97 function, 202
logical volumes, 214 memory
loopback hoods, 402 dimension of main, 25
LPC main and real, 25
changing, 104 migration
M3UA to MTP3, 161
426
Index
MTP3-based SCCP to M3UA, 161 ocNetworkControl command, 377
monitoring ocNetworkStatus command, 377
M3UA-based network, 190 operating
PINS, 91 PINS, 91
moving operating system, deterministic behavior of,
hardware component (M3UA-based 23
platform), 254 operator intervention, 225
MTP, 26 out-of-service, 186
checkpointing configuration, 162
MTP2 P
aligning, 166 package, 222
validating connectivity, 166 MC/ServiceGuard, 202
MTP3 name, 211
aligning, 166 path
configuring, 69 modification to enable other users, 22
connecting, 167 path names
migrating SCCP to M3UA-based, 161 absolute, 215
migrating to M3UA, 161 performance
validating connectivity, 166 use switches instead of hubs, 53
validating platform, 71 PIC/AG, 227
MTP-based platform pinouts
adding hardware components, 252 E1 BNC connector (grounded), 393
moving hardware components, 252 E1 BNC connector (ungrounded), 394
replacing hardware components, 252 E1 RJ-45 connector, 393
E1/T1 RJ-45 cable loopback, 408
N E1/T1 TSC card loopback, 408
T1 RJ-45 connector, 396
network V.35 DCE cable loopback, 404
configuring for M3UA, 111
V.35 DCE connector, 400
configuring for SCCP, 111 V.35 DTE cable loopback, 404
connecting national and international, 105
V.35 DTE connector, 399
destination out-of-service, 186
V.35 TSC card loopback, 405
monitoring M3UA-based network, 190 PINS
parameters for M3UA, 133 configuration, 90
running different configurations, 164 deactivating, 91
subnet name, 212 description, 88
network configuration functionality, 88
saving, 109 HA status, 92
new feature
local switch, 91
adding codewords to license, 197
nlog, 380 monitoring, 91
non-commercial license operating, 91
migrating from, 198 remote switch, 92
non-exclusive activation mode, 214 requirements, 89
platform
O recommended processes on PMW, 25
platform management workstation, 27
ocadmin, 202 Platform Manager
ocftcontrol, 376 validating, 181
ocftstatus, 376 Platform Monitor
ocLicense command, 381 screen, 180
427
Index
platform performance restricted SAM, 22
use switches instead of hubs, 53 root login, 202
platform state route
before and after failure, 224 congestion, 185
plug-in, 227 router
Plug-In Container/Application Guardian, 227 isolating the LANs, 24
port run and halt script pathname, 211
E1/T1, 388
V.35, 387 S
power SAM
battery backup, 26 restricted, 22
process to run when repowering, 26 using, 97
power supply SCCP, 26
replacing (TSU AC), 259 configuring network, 111
replacing (TSU DC), 262 migrating from MTP3-based, 161
TSC, 411 SCSI failure, 223
TSU (AC), 419 secure access, 202
TSU (DC), 420 security, 202
TSU DC connector, 421 service
precautions failure, 212, 223
anti-static, 19 name, 212, 215
safeguarding configuration, 19 SG
safety, 18 remote SG parameters, 128
Primary Network Interface, 208 shell, default, 215
Print Logger SIGKILL signal, 212
location, 25 SIGTERM signal, 212
process single point of failure, 219
hang, 220 SLC
heart beat, 223 number, 105
location of non-essential, 25 slow platform processes, causes, 23
number of application, 23 SNMP Traps
states, 172 activating, 177
termination, forcing of, 212 configuring, 176
validating, 176
R SS7
stack failure, 219
race conditions, 204 validating connectivity, 166
relocatable SS7 Monitor
IP address (configuring), 88 configure global title translation, 107
remote AS configure links, 106
parameters for M3UA, 134, 137 configure Local Point Code, 103
remote SG linkset, 106
parameters for M3UA, 128 monitor SCCP, 186
remote switch
ss7MgrStart, 180
PINS, 92
replacing ss7CheckPoint, 377
ss7DiagStart, 378
hardware component (M3UA-based SS7Guardian kit
platform), 254 configuration file, 207
resolution ss7GuardianAngel, 377
of stack failure, 220 ss7GuardianSwitch, 377
of user application failure, 221 ss7HwAccept, 378
428
Index
ss7HwInfo, 378 switch
ss7HwInit, 378 local (PINS), 91
ss7HwLoad, 378 remote (PINS), 92
ss7HwLoadConfig switchback
to check the configuration, 344 performing, 173
ss7HwReplace, 378 switches
ss7HwRollback, 379 recommendation, 53
ss7HwTrace, 380 switchover
ss7IsupReload, 378 due to number of application processes, 23
ss7MgrStart, 376 performing, 173
ss7MgrStop, 376 spurious, due to CPU load, 23
command options, 181
synchronizing clocks, 26
ss7RmonStart, 376 SYNCHRONIZING state
ss7SNMPAgent, 380
ss7Start, 376 process, 172
command options, 95 system
ss7Stop, 376 memory failure, 202
command options, 94 processing unit failure, 202
ss7TcapTune, 367, 377 system and application process failure, 202
ss7TscPing, 379
ss7TscStatus, 379 T
ss7TscUpgrade, 379 T1 cards, 385, 388
ss7TsuPing, 379 cable assembly, 397
ss7TsuStatus, 379 connections, 396
stack ports, 388
process states, 172 TCAP, 26
stack configuration TCAP process expansion
loading by script, 163 dynamic (using commands), 367
stack failure, 220, 224 dynamic (using SAM), 365
resolution by SS7GuardianAngel, 220 static, 361
standby failure, 224
tcxgen command, 381
start Telecom Signaling Card (TSC), 383
the Platform Manager using ss7MgrStart,
adding in a TSU, 275, 281, 291, 296
180
adding link(s), 348
Starting, 94
adding to a TSU, 325, 329, 332
startnettl, 380
startup commands, 218 cable assemblies, 395, 397, 401
states chained links, 341, 412
ACTIVE (process), 172 connectors, 390
BOOTING (process), 172 E1/T1, 385, 388
DOWN (process), 172 environmental requirements, 411
HOT-STANDBY (process), 172 function, 384
stack processes, 172 installing in TSU, 239
SYNCHRONIZING (process), 172 labeling your upgrade, 354
UNKNOWN (process), 172 LEDs, 312
statistics number of links, 354
data for entity, 186 on-site upgrade, 354
status power supply, 411
HA (PINS), 92 replacing in a TSU, 277, 293
STP, configuring gateway, 105 serial number, 354
subnet, 212, 215 upgrade, 354
swapping limitations, 25 upgrade troubleshooting, 354
429
Index
V.35, 385, 386 cfgCheck, 96
Telecom Signaling Unit (TSU), 413 SAM, 97
adding to the platform, 318, 322, 330, 336
backplane, 265 V
cabinet, 416
V.35 cards, 385, 386
card cage, 265, 302, 415 cable assembly, 401
checking the configuration, 345 connections, 397
CPU card, 265, 414, 415 links, 387
E1 configuration example, 345 ports, 387
environmental requirements, 422 validating
fans, 256, 310, 417 configuration, 96
function, 414 HA, 172
installation, 240 HP-UX installation, 96
installing cards, 238 installation, 37, 96
LAN card, 269, 271 M3UA connectivity, 167
LEDs, 309 M3UA platform, 72
loading the configuration, 345 MTP2 connectivity, 166
maintenance procedures, 249 MTP3 connectivity, 166
PCI slots, 238, 415 MTP3 platform, 71
power cord, 19, 421 Platform Manager, 181
power supplies, 416 SNMP Traps, 176
rear panel connectors, 243 SS7 connectivity, 166
removing and replacing card cage, 302 variables, 214
removing and replacing cover, 300 viewing
removing from server cabinet, 300 log, 97
replacing, 285 volume group, 208, 214
Time, 26
timeout value, 211 W
timeout\
failure detection on platform types, 23 web-based monitor, 191
wlog command, 380
timers, 26 wmsg command, 380
trafgen command, 381
Traps
activating SNMP Traps, 177 X
configuring SNMP Traps, 176 XML
validating SNMP Traps, 176 configuration example, 150, 153, 160
TSC-in-system, 384 editing XML configuration file, 164
elements, 115
U file structure, 115
uncongested route, 185
UNKNOWN state
process, 172
updating
M3UA network configuration, 155
user
concerned local user parameters, 145
user application failure
resolution by SS7GuardianSwitch, 221
user, adding PATH to .profile, 22
using
430

HP Opencall Ss7 Platform Operations Guide: For Release 3.2 On Hp-Ux Pa-Risc

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HP Opencall Ss7 Platform Operations Guide: For Release 3.2 On Hp-Ux Pa-Risc

Uploaded by

Copyright:

Available Formats

HP OpenCall SS7 Platform

Manufacturing Part Number : 5990-7337

2. Installing the HP OpenCall SS7 Platform

3. Configuring and Starting the Platform

4. Configuring the Signaling Network

5. Validating the Platform

6. Managing and Monitoring the Platform

7. Upgrading the Platform License

8. Using the SS7 Guardian Kit

9. Configuring the PIC/AG

10. Installing a New TSU

11. Maintaining Signaling Hardware

12. Configuring TSU/TSC Hardware

13. Updating TSCs and SS7 Links

14. Expanding Platform Processing Capability

B. Telecom Signaling Cards (J3527A/J3527B and J3528A)

C. Telecom Signaling Units (J3401A)

About This Guide

• installing the software

Chapter 1, “Preparing for Details the hardware and software pre-requisites

Chapter 2, “Installing the Describes how to install HP OpenCall SS7 3.2 to

Chapter 3, “Configuring and Describes how to create or modify a platform

Chapter 4, “Configuring the Describes how to configure the signaling network

Chapter 5, “Validating the Provides procedures for validating the High

Chapter 6, “Managing and Provides a number of procedures concerned with

Chapter 7, “Upgrading the Describes how to upgrade your HP OpenCall SS7

Chapter 9, “Configuring the Describes how to configure the PIC/AG (Plug-In

Chapter 11, “Maintaining Describes the maintenance procedures for TSUs,

Appendix B, “Telecom Signaling Contains a detailed description of Telecom Signaling

Appendix C, Telecom Signaling Contains a detailed description of the Telecom

HP OpenCall SS7 Application Describes the HP OpenCall SS7 APIs. In

HP OpenCall SS7 Conformance and Outlines platform conformance and compliance to

HP OpenCall SS7 Glossary Defines terms used in the documentation set.

HP OpenCall SS7 Troubleshooting Describes how to troubleshoot an

HP OpenCall SS7 Release Notes This document contains release-specific

HP OpenCall SS7 Software This is the booklet that accompanies the

Features Supported in This Release

This chapter firstly describes important precautions you should take

Important Safety Precautions for Hardware

Physical Safety Precautions

• USA - use a UL listed type SVT detachable power cord.

CAUTION Use an anti-static mat and wear a grounding wrist strap

• The server cabinet must be independently grounded so that when

Saving Your Platform Configuration

Save your new configuration using the ss7CheckPoint tool after

User Access for Software Configuration

User Access Level Configuration Required

root Full access to whole None.

At package installation, the following are created:

• the user ocadmin

The appropriate environment variables are also added to both ocadmin

NOTE To be manageable using SAM, all files in the HP OpenCall SS7

Most platform commands can be used by the ocadmin user, however,

Configuring Restricted SAM

Authorizing Access for Other Users

HP OpenCall SS7 Operating Conditions

Operating System Requirements

CPU Usage < 85%

Figure 1-1 Isolated LANs

To prevent unnecessary switchovers, the LANs must be dimensioned so

NOTE The LANs must be either Ethernet (100-BaseT) or FDDI.

Figure 1-2 Bridges/Routers between Hosts

Management Applications Location