Table of Contents

Architectural Overview

Input/Output Subsystem
Element Management Subsystem
Fault Tolerance Subsystem

Execution Environment

Call Engine
Call Instance

Directory Structure

Operations Overview

This chapter provides an overview of the architecture of the Cisco Media Gateway Controller (MGC) Software Release 7, which is used in both the Cisco Signaling Controller (SC) and the Cisco Virtual Switch Controller (VSC) products. It describes the major subsystems and processes you need to know in order to effectively operate, maintain, and troubleshoot the Cisco MGC and associated components used in the various Cisco telephony solutions that employ the Cisco MGC.

This chapter contains the following information:

• An overview of the architecture of the Cisco MGC Software Release 7

• High-level descriptions of the functionality and operation of various subsystems and processes in the Cisco MGC software

• The nature of the interfaces between internal Cisco MGC processes and the nature of Cisco MGC interfaces with external network elements

Architectural Overview

This section describes the major subsystems in the Cisco MGC software, which are illustrated in Figure 1-1 . The major subsystems are

• Input/Output Subsystem

• Element Management Subsystem

• Fault Tolerance Subsystem

• Execution Environment

• Call Engine

Input/Output Subsystem

The Input/Output (I/O) subsystem consists of the I/O channel controllers (IOCC) and the I/O channel manager (IOCM), which manages them.

• The I/O channel manager (IOCM) manages all IOCCs and keeps the hardware resource states of the hardware controlled by the IOCCs.

• The I/O channel controllers (IOCCs) provide

  • A protocol-specific, message-based interface that allows nodes and platforms external to the Cisco MGC to communicate with the Cisco MGC.

  • An interface that allows buffering of messages to the Call Engine's event dispatcher queue.

Element Management Subsystem

The Element Management Subsystem (EMS) allows external client software or terminals to gain access to the data in the Cisco MGC. The functions this subsystem supports are:

• Configuration Management—Adding, deleting, or modifying parameters and resources needed by the Cisco MGC to perform its switching function. This data is stored locally in data (.dat) files. This data is required to automate reconfiguration after a process failure.

• Alarm Management—Reporting and clearing alarms generated by Cisco MGC processes.

• Performance Measurement (PM) Management—Reporting and clearing metrics generated by Cisco MGC processes. You can also define thresholds which, if exceeded, could produce alarms.

• Accounting Management—Dumping generated call detail records (CDRs) to locally persistent files or to remote databases through a standard or customized API.

The following types of external clients can access or manipulate data on the Cisco MGC:

• Man-Machine Language (MML) terminal—Serves as a command-line interpreter where a craftsperson can manipulate data for fault detection, measurements, or configuration through a series of commands. MML is similar to TL/1 and is best suited for low-level system experts (such as operations personnel) for rapid system configuration or troubleshooting.

• SNMP-Based Terminal—Any client using SNMP, usually a craftsperson with a graphical user interface (GUI) application, can access data for fault reporting, measurements, configuration, or security. SNMP applications are best suited for end users and allow development of elaborate multiplatform client applications to satisfy diverse customer needs.

• Cisco MGC Manager (CMM)—Is an application used for provisioning the Cisco MGC.

• Cisco MGC Node Manager (CMNM)—Is an optional application used for network element (NE) management.

• Billing and Measurements Server (BAMS)—Is an optional application used for collection of CDRs and operational measurements (OMs).

Fault Tolerance Subsystem

The goal of the Fault Tolerance Subsystem is to ensure call preservation if the Cisco MGC encounters a fault condition. There are two processes that ensure this:

• Failover daemon—Monitors Cisco MGC processes using a heartbeat mechanism. If there is no response to its process polling in a fault-tolerant hardware configuration, the Cisco MGC switches control to the standby unit.

• Replicator—Allows processes to checkpoint critical call information, such as signaling and bearer states, as well as call data across the active and standby processors. Its goal is to replicate enough information for established calls to survive a failover. Checkpointing events are generated at two points in a call:

  • When the call is answered, to update the full duplex path.

  • When the call is released, after the physical resources are deallocated.

  Connectionless (non-call) signaling may be generated by a craftsperson performing maintenance through an MML or SNMP client or by circuit supervision.

  Certain signaling can also generate checkpointing events:

• Blocking or unblocking of circuits

• Circuit reset

Note   The replicator mechanism does not try to replicate program or data storage. Service features are not checkpointed across processors; there is just enough information to maintain the voice or data path between the call originator and the call terminator. If the failover happens before the simplex path is established, call processing cannot proceed on the inactive side. Non-established calls in the process of being set up are lost.

Execution Environment

The Execution Environment (XE) provides an operating system process shell used by Cisco MGC processes to access lower-level functionality. Such functionality holds together the I/O, Element Management, and Call Engine subsystems in the Cisco MGC. The XE infrastructure provides the following functions to Cisco MGC processes:

• Operating System Interface—Such as the Sun Solaris operating system.

• Process Management—Performs startup order, shutdown order, and monitoring of processes. Also performs software upgrade compatibility checking with minimal service interruption.

• Alarm Management—Allows processes to register, set, and clear alarms, which are then presented to the Element Management subsystem (EMS) for further processing.

• Log Management—Allows MGC processes to log messages to locally persistent data files. Message codes (instead of strings) minimize the overhead of interprocess transport of long buffers. Log files use a facility (process type originating the log) and a logging level (severity).

• Measurement Management—Allows processes to adjust counters or other metrics, which are subsequently presented to the EMS for Alarm and Measurement Report processing.

• Command Management—An interface that can be used by any active processes or by an EMS interface, such as MML or SNMP agents, to exchange commands or responses.

• Configuration Management—Notifies processes and gets responses when configuration data changes. Handles reconfiguration management when multiple processes are affected by changes.

• Access Control—Allows only authorized processes to access certain services or other processes.

• Interprocess Communication (IPC)—Allows processes to exchange messages.

• Event Processing Service—The XEProcShell facility allows applications to register, deregister, and exchange events (messages) through IPC. This service is critical to efficient real-time CPU usage and overall system performance.

• Timers—Allow processes to set, clear, or monitor timers. Provide timeouts to processes.

Call Engine

The Call Engine is a process designed to provide the means and resources for call processing to take place. The Call Engine involves the following components:

• Resource Manager—The Resource Manager performs the following functions:

  • Tracks all bearer resources used. Proxies and tracks the bearer resources in the trunking gateways within the Cisco MGC's service area.

  • Services all requests for allocation or deallocation of bearer resources from call instances.

  • Executes bearer allocation algorithms (circuit selection).

  • Manages echo cancellation on the call's behalf.

  • Performs continuity tests.

  • Checkpoints bearer states and modes to the Cisco MGC's inactive side (or standby system) to guarantee that the bearer channel is not lost during a failover or switchover.

• Connection Manager—The Connection Manager interfaces with the nodes and protocols external to the Cisco MGC that are necessary to establish an IP (TCP, UDP, or RUDP) or PSTN connection that is managed by the Cisco MGC. The type of node supported is

  • VoIP/VoATM trunking gateways using MGCP.

  • Time Domain Multiplex (TDM) trunking gateways using MGCP.

• Call Manager—The Call Manager contains and selects the appropriate protocol adapters. These are protocol-specific entities performing the following functions:

  • Communicates with the corresponding protocol-specific I/O channel controller (IOCC).

  • Converts incoming protocol data units (PDUs) received from the IOCC to an internal, protocol independent format.

  • Converts internal, protocol-independent PDUs to protocol-specific format.

  • Communicates current circuit states to the I/O channel manager (IOCM) using the IOCCs.

  • Creates a call instance when an incoming MTP level 3 call establishment message is received.

  • Destroys that instance and frees any associated memory when the call is terminated.

  • Supports multiple call instances. It dequeues incoming messages from the event dispatcher queue and routes them to the call instance for which they are destined.

  • Generates call detail blocks (CDBs), which are used to create call detail records (CDRs).

  • Operates as a standby entity, which is created when the Call Engine is created at system startup, and waits to create a new call, destroy an existing call, or process an event for an existing call.

  • Checkpoints call information, such as call signaling state and data, to the inactive side (or standby system) of the Cisco MGC to guarantee that the signaling link is not lost during a failover or switchover.

Call Instance

A call instance is the dynamic component of the Cisco MGC that is created at run time and is the place where call processing takes place. The call instance is commonly referred to as the Message Definition Language (MDL) component, which is the language used to implement it.

A call is instantiated when an incoming MTP Layer 3 call establishment message is received. There is always a one-to-one relationship between a call instance and a call switched by the Cisco MGC.

There are several significant subcomponents involved in a call instance:

• Originating Call Control (OCC)—Is the instance of the originating protocol's state machine. In defining a protocol, two MDL modules are created:

  • A General Declarations module, which contains protocol-specific types and definitions.

  • A Protocol Definition module, which contains the state logic for two state machines—one for call origination and one for call termination. This module produces an object file named protocolName.mdo.

• Universal Call Model (UCM)—Is a protocol-independent state machine that is used to

  • Provide protocol interworking between the originating and the terminating sides of the call.

  • A UCM MDL module is used to define the UCM behavior and logic. The UCM module is compiled into an object file, but can only be loaded by the Call Engine and cannot be used by any of the protocols.

  • Provide event-driven logic, which controls the following call-processing functions:

  • Links the OCC and TCC.

  • Updates and retrieves the call context structures.

  • Interacts with other Call Engine components, such as the Resource Manager, Connection Manager, and Call Manager.

  • Manages bearer resources, such as trunking gateways, using the Media Gateway Control Protocol (MGCP).

  • Keeps the call processing state machine.

  • The UCM also triggers events to be processed by the following MDL modules:

  • Generic Analysis Module

  • Subscriber Profile Retrieval

  • A-number and B-number Pre-analysis

  • A-number and B-number Full Analysis

  • Route Selection

  • IN Trigger Module

• Connection Plane Manager (CPM)—Is responsible for communicating with the Call Engine's Resource Manager to make the bearer connections to a remote trunking gateway using MGCP.

• CDR Manager—Generates call detail records (CDRs) and forwards them to the EMS to be locally persisted or forwarded for off-platform accounting applications. CDRs are generated when calls are answered and they can also be generated in the following situations:

  • End of call (standard)

  • Long duration calls

  • Mid-call CDRs (can generate CDBs at eight different points in a call)

• Terminating Call Control (TCC)—Is the instance of the terminating protocol's state machine.

• Call Context—The following are the Call Context characteristics:

  • The Call Context is a persistent object in a Call Instance that serves as the placeholder for bearer and signaling information. Such information is set and retrieved by the OCC, TCC, or UCM at various points in the life of the call.

  • An MDL Context Definition module is used to define the information elements, structures, and fields. This module is compiled into an object file to be used by all protocols.

  The format of these structures is protocol-independent to minimize cross-protocol conversion permutations. Contains rules for data conversion to and from each protocol.
  

  • Collects the following call information in call detail blocks (CDBs), which are assembled to build call detail records (CDRs):

  • Calling number

  • Called number

  • Answer time

  • Disconnect time

  • Originating trunkgroup and circuit

  • Terminating trunkgroup and circuit

  • Address translation and route information

  • ISUP information

  • ISDN service information

  • Database query information

  • Call completion codes

  • Other information depending on the type of call.

Directory Structure

This section shows an overview of the UNIX file directory tree for the Cisco MGC distribution, along with a brief description of the purpose for each directory. This section is to be used as a guide to finding files called out in the operational procedures.

In the installation procedures, the installer is asked for a directory under which to install the Cisco MGC software. In version 7.4 and up of the MGC software, the default directory is /opt/CiscoMGC; however, this directory name is installer-definable, so do not assume that /opt/CiscoMGC is always used. In version 7.3 of the software, for example, the default directory is /opt/TransPath. This is the directory under which all files for the Cisco MGC reside. The sole exception is some temporary files that are created at run time.

Table 1-1 utilizes the variable $BASEDIR to indicate the directory into which the Cisco MGC software was installed.

Table 1-1: Cisco MGC Directory Structure

Directory	Description
$BASEDIR/bin	Cisco MGC executable programs that cannot be customized.
$BASEDIR/local	Cisco MGC executable programs that can be modified by the customer for a site-specific reason. See the procedures for how to customize files. Generally the factory default values are sufficient.
$BASEDIR/etc	Network element configuration files. This includes all provisionable configuration files required for proper operation of the Cisco MGC.
$BASEDIR/etc/CONFIG_LIB	Cisco MGC configuration file library. This is a simple version control system for configuration file changes.
$BASEDIR/etc/cust_specific/ toolkit	Saved data from the Cisco MGC Toolkit applications is stored in this directory.
$BASEDIR/lib	Shared object files. These libraries are loaded at runtime by the executables. The three types of libraries are: (1) system/program shared objects, (2) MDL interpreted objects, and (3) MDL shared objects.
$BASEDIR/var	Subsystem communication and persistent storage area. This directory contains files and devices providing communications between the various subsystems in the Cisco MGC. It also contains files providing persistent storage of data for the Cisco MGC.
$BASEDIR/var/log	System logging area. This directory contains the platform logs. See the "Troubleshooting with System Logs" section for more information.
$BASEDIR/var/spool	Dumper Spool Area. This directory contains historic reports. See "Interpreting Report Files."
$BASEDIR/var/trace	Signal Path Trace area. This directory contains all MDL trace logs used for conversion analysis.
$BASEDIR/data	MDL source files. MDL source files are generally not provided, but if they are purchased, they will appear here.

Posted: Mon Aug 28 10:29:16 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.