cc/td/doc/product/access/sc/rel7/soln/ss7pri
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Cisco SS7 PRI Gateway Solution Operations Overview

Cisco SS7 PRI Gateway Solution Operations Overview

This chapter provides a brief overview of unattended operations and manual control options available in your Cisco SS7 PRI Gateway Solution.

Unattended Operation

The following operations are described in this section:

Understanding System Redundancy

The Cisco SS7 PRI Gateway Solution uses two VSC hosts with software-based checkpointing and heartbeat to facilitate redundancy. The call-processing application is active on only one VSC host platform at a time and switches to the standby platform under failure conditions. For more information see the "Understanding Automatic Failover" section, on page 3-2, for more information.

The Session Manager software on the Cisco SLT manages the communication sessions with the VSC hosts. When Cisco SLTs are used with a redundant pair of VSC hosts, the Session Manager maintains separate communication sessions with each VSC host in the pair. The session between the Cisco SLT and the active VSC host transports the SS7 traffic, while the session between the Cisco SLT and the standby VSC host provides backup. Upon VSC host switchover or failover, the Session Manager on the Cisco SLT must be instructed by the newly active (formerly standby) VSC host to switch traffic to itself. Upon failover, all answered calls in progress are preserved.


Note Full system redundancy is available on continuous-service configurations and is limited in high-availability configurations.

Understanding Automatic Failover

The Cisco SS7 PRI Gateway Solution offers the continuous-service configuration to protect your system against failures and downtime.

The failover system consists of two VSC hosts connected using IP, as shown in Figure 3-1. One VSC host functions as the active host, while the other VSC host functions as the standby host. The failover system provides a seamless transition to the standby host in case of system failures.

The active host maintains communications between the active and standby hosts. The standby host constantly checks the active host for new and changed configurations and updates itself on a regular basis. When the standby host becomes the active, its configuration mirrors that of the former active host without losing the link with the access gateway, thus preserving calls.


Figure 3-1: Failover Processes on the Signaling Controller Hosts

System Messages

The Cisco MGC software generates system messages that provide you with call processing, management, configuration, and alarm status.

Status messages include these types:

After you enter an MML command, one of the following messages is generated: MML status, MML error code, auto-generated or autonomous, and alarm.
The portable execution environment (PXE) logging system outputs messages to log files determined during the client initialization period. The PXE log server software takes messages initiated by various applications (other software processes) within the VSC software, formats the messages, and outputs them to the appropriate files. The PXE log server also adds a timestamp, an application identifier (also known as a service ID or service name, a process identifier (that is, the UNIX process), and a log level.

For detailed information about system messages, refer to the following documents:

Call Detail Records (CDR)

Call detail records (CDRs) are stored on the VSC for billing purposes and are available for external processing.

CDRs are comprised of call data elements (CDEs). The CDE is the data element (field) that includes a basic information field within a billing record. Examples of CDEs are the calling number, the called number, and so on. The call data block (CDB) consists of several CDEs, related to a certain point in call (PIC).

For detailed information about CDEs and CDBs and an overview of the Cisco MGC billing system, see these documents:

Disk Mirroring

Disk mirroring is an optional feature that duplicates the information contained in a file system by using two disk partitions located on separate physical disks. In the event of a physical disk failure, the file system continues to operate using the unaffected disk.

Disk mirroring increases the availability of the Cisco SS7 PRI Gateway Solution by keeping the system operating when a physical disk fails---a mirrored disk can be removed and replaced while the system remains active. With redundant VSC hosts using disk mirroring, a single disk failure does not cause failover as described in the "Understanding System Redundancy" section.

The Volume Manager software running on your Cisco VSC3000 provides this feature in a transparent manner so that the application software does not know that there are mutiple disk partitions making up the file system.

For detailed information about how to install disk mirroring through Volume Manager, refer to the Cisco Media Gateway Controller Software Release 7 Installation and Configuration Guide.


Note Disk mirroring is optional on the Sun Netra t 11xx and Sun Netra t 14xx server platforms.

Manual Control Options

The Cisco Virtual Signaling Controller includes three tools that you can use to provision the software: the Cisco Voice Service Provisioning Tool graphical user interface (GUI) application, the interim provisioning tool, and the Man-Machine Language (MML) command line interface (CLI) application.

CMM makes provisioning easier for less experienced administrators by listing all the components that need to be configured and providing windows that display all configuration parameters for each component. Instructions for provisioning with CMM can be found in the
Cisco Media Gateway Controller Software Release 7 Provisioning Guide.

Provisioning Choices

Although MML provisioning requires more keystrokes, quick provisioning updates can sometimes be made faster with MML commands. When you enter MML commands into a batch file, you can copy and paste configuration commands to speed command entry, and you can copy and modify MML scripts to configure additional Cisco MGC switches. For information on provisioning with MML, refer to the Cisco SS7 PRI Gateway Solution Provisioning Guide.

You can use the interim provisioning tool and MML to provision the Cisco MGC. However, you can use only one of these tools at a time for actual configuring. Table 3-1 lists some of the Voice Service Provisioning Tool and MML features and provides guidelines for selecting between the two tools.


Table 3-1:
Specifications/Features Voice Service Provisioning Tool Man-Machine Language (MML)

System Basics

X-windows GUI1 front end.


Note Any client software supporting X-windows, such as Reflection for remote management, can be used.

CLI2 that interacts directly with Cisco MGC.

System Hardware/Software Requirements

Sun Sparc station running Solaris 2.6 or greater


Note Running the Voice Service Provisioning Tool on the same host as the Cisco MGC can adversely impact performance. Cisco recommends using a separate server.

Runs on the Cisco MGC host.

Batch File Support

No

Yes

Level of Network/Telephony Experience Required

Some experience required; easy to use.

Requires a high level of experience with MML and the Cisco MGC software.

Best Used For

  • Setting up a single configuration or few configurations on individual machines.

  • Modifying an existing configuration.

  • Creating batch files to provision many Cisco MGCs or retrieve measurements.

  • Modifying configurations (experienced users).

1GUI = graphical user interface.
2CLI = command line interface.
Voice Service Provisioning Tool and MML Features

hometocprevnextglossaryfeedbacksearchhelp
Posted: Thu Jun 15 09:57:16 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.