Cisco PGW 2200 Softswitch Platform Overview
Revised: December 3, 2009, OL-0800-12
This chapter provides an overview of the components of the Cisco PGW 2200 Softswitch platform, and of the software architecture of the Cisco PGW 2200 Softswitch software Release 9.
This information is described in the following sections:
•Cisco PGW 2200 Softswitch Platform
•Cisco PGW 2200 Softswitch Software Architecture
•Cisco PGW 2200 Softswitch Software Directory Structure
Cisco PGW 2200 Softswitch Platform
The following subsections briefly describe the components of the Cisco PGW 2200 Softswitch platform:
•Cisco PGW 2200 Softswitch
•Cisco SS7 Interfaces
There are several optional elements of the Cisco PGW 2200 Softswitch platform, which are listed in the "Agent Management Subsystem" section. For more information on these optional elements, see the documentation for that element.
Cisco PGW 2200 Softswitch
The Cisco PGW 2200 Softswitch is a Sun UNIX box running Cisco PGW 2200 Softswitch software Release 9. The Cisco PGW 2200 Softswitch performs real-time call-processing and SS7 layer functions; manages trunk resources, alarms, and call routing; and administers billing information.
Cisco PGW 2200 Softswitch functionality includes:
•Originating call detail records (CDRs)
•Providing alarm initiation information
•Producing operational peg counts
•Receiving and processing craft user interface (CUI) data
•Providing Message Transfer Part (MTP) Level 3 (MTP3) functions
•Providing advanced intelligent network (AIN) capabilities
Sun UNIX Hosts
Sun UNIX hosts serve as the platforms for the Cisco PGW 2200 Softswitch software Release 9. Information on which Sun UNIX hosts can be used for each Cisco PGW 2200 Softswitch releases is found in the section, "Cisco Media Gateway Controller Overview", of the Cisco PGW 2200 Softswitch Hardware Installation Guide - Releases 7 & 9.
Using two Sun UNIX hosts in a continuous service configuration provides system redundancy and reliability. The call-processing application is active on one Cisco PGW 2200 Softswitch and automatically switches to the standby Cisco PGW 2200 Softswitch only under failure conditions.
Cisco SS7 Interfaces
The Cisco PGW 2200 Softswitch platform interfaces to the SS7 network using either Cisco IP Transfer Point LinkExtenders (ITP-Ls) or Cisco IP Transfer Points (ITPs).
The Cisco ITP-Ls terminate Message Transfer Part (MTP) levels 1 and 2 of the SS7 protocol. The remaining SS7 layers are backhauled across an IP network to the Cisco PGW 2200 Softswitch, using the Reliable User Datagram Protocol (RUDP) over an Ethernet interface (10BASE-T for Cisco 2611 routers, 100BASE-T for Cisco 2651, 5350, and 5400 routers).
The number of signaling network connections on each Cisco ITP-L varies with the router used in the chassis. The Cisco 2611 router supports up to two signaling network connections per Cisco ITP-L chassis. The Cisco 2651, 5350, and 5400 routers support up to four signaling network connections per Cisco ITP-L chassis. Multiple Cisco ITP-Ls (up to 16 per Cisco PGW 2200 Softswitch platform) can be used to support additional signaling channels. The Cisco ITP-L, regardless of the router used, can be configured with redundant connections to the control signaling network, to eliminate the Cisco ITP-L as a possible single point of failure in the Cisco PGW 2200 Softswitch platform. The Cisco ITP-Ls support V.35, T1, and E1 interfaces to the SS7 network.
The Cisco ITPs terminate all levels of MTP and the Service Connection Control Part (SCCP) layer of the SS7 protocol. The remaining SS7 layers are backhauled across an IP network to the Cisco PGW 2200 Softswitch, using the SIGTRAN standards, MTP Level 3 User Adaptation/SCCP User Adaptation (M3UA/SUA) using Stream Controlled Transmission Protocol (SCTP), over an Ethernet interface.
The number of signaling network connections on each Cisco ITP varies with the router used. A list of the routers that support the Cisco ITP functionality and the number of signaling network connections they support can be found the Release Notes for the Cisco ITP software.
Cisco switches are used to create the Ethernet backbone for the Cisco PGW 2200 Softswitch platform. Local area network (LAN) and wide area network (WAN) implementations are supported. The switches that are supported for your implementation are detailed in the Release Notes for the Cisco PGW 2200 Softswitch software.
WAN implementations have the following limitations:
Table 1-1 Limitations on WAN switches within a Cisco PGW 2200 Softswitch Platform
Software release version
Cisco PGW 2200 Softswitch software 9.3(2) or later (with associated operating system and hardware requirements).
Total end-to-end delay, one way (length of time it takes to send a message from a source to a destination, such as from a Cisco PGW 2200 Softswitch to an ITP-L)
Must be less than 150 milliseconds.
Packet loss (defined as missing packets with a message)
Must not exceed 1 percent (preferably, less than 0.5 percent).
Note For packet loss rates below 0.5 percent, increase the RUDP receive window size (*. rudpWindowSz) to 64 for increased performance.
If dual-VLAN SIP automatic switchover support is enabled...
Both Cisco PGW 2200 Softswitches should be part of the same IP subnet.
Each Ethernet NIC for each Cisco PGW 2200 Softswitch is connected by a 100BASE-T interface to the switches. The switches connect to the SS7 interfaces using 10BASE-T or 100BASE-T interfaces. Figure 1-1 displays the Ethernet connections between the elements of the Cisco PGW 2200 Softswitch platform.
Figure 1-1 Cisco PGW 2200 Softswitch Platform Connectivity
Cisco PGW 2200 Softswitch Software Architecture
This section describes the major subsystems in the Cisco PGW 2200 Softswitch software, which are illustrated in Figure 1-2. The major subsystems are
•Agent Management Subsystem
•Fault Tolerance Subsystem
•Execution Environment Process Shell
•Call Engine Process
Figure 1-2 Cisco PGW 2200 Softswitch Software System Diagram
Note The H.248 IOCC in the I/O subsystem is added on Cisco PGW 2200 Softswitch software Release 9.7(3) Patch 8 in the Figure 1-2.
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 IOCM manages all IOCCs.
•The IOCCs provide
–A protocol-specific, message-based interface that allows nodes and platforms external to the Cisco PGW 2200 Softswitch to communicate with the Cisco PGW 2200 Softswitch.
–An interface that allows buffering of messages to the call engine's event dispatcher queue.
•The Cisco PGW 2200 Softswitch software I/O subsystem includes the following IOCCs:
–Basic Rate Interface (BRI)—Added in Release 9.5, this IOCC enables the backhaul of layer 3 QSIG and Q.931 messages in a TCP session. This IOCC is used between a Cisco PGW 2200 Softswitch and voice gateways that support BRI signaling backhaul.
–Digital Private Network Signaling System (DPNSS)—Added in Release 9.4, this IOCC enables the transparent transport of DPNSS data over IP. This IOCC is used between media gateways that support DPNSS.
–Extended ISDN User Part (E-ISUP)—Cisco-proprietary protocol that enables the transport of endpoint- and media gateway-specific information between two (or more) Cisco PGW 2200 Softswitches. This protocol uses an enhanced ISUP base to support all ANSI and ITU ISUP messaging and elements. It also has additional fields to support transport of service information (such as local number portability (LNP), 800 numbers, and so on).
–ISDN Level 3—Provides backhauling of ISDN (standard variants) to a Cisco PGW 2200 Softswitch from a media gateway.
–ISDN Q.921 User Adaptation Layer (IUA)—Added in Release 9.4, this IOCC enables backhauling of ISDN Q.921 user messages over IP using Stream Controlled Transmission Protocol (SCTP). This IOCC is used between a Cisco PGW 2200 Softswitch and media gateways.
–Media Gateway Control Protocol (MGCP)—Enables communication with media gateways and trunking gateways, making possible the setting up of bearer channel connections used in Cisco PGW 2200 Softswitch configured for call control environments.
–Message Transfer Part Level 3 (MTP3) User Adaptation (M3UA)—Added in Release 9.4, this IOCC enables the transport of any SS7 MTP Level 3 User signaling (for example, ISUP and TUP messages) over IP using SCTP. This IOCC is used between a Cisco PGW 2200 Softswitch and a Cisco IP Transfer Point (ITP).
–Q.931+—A stateless IOCC, for a Cisco-proprietary protocol, which is a special version of ISDN that enables forward hauling of Q931+ signaling to a media gateway used with a Cisco PGW 2200 Softswitch configured for signaling environments.
–Session Initiation Protocol (SIP)—Enables the Cisco PGW 2200 Softswitch to receive and send SIP messages over the User Datagram Protocol (UDP).
–Signaling Control Connection Part (SCCP) User Adaptation (SUA)—Added in Release 9.4, this IOCC enables the transport of any SCCP user signaling (for example, TCAP messages) over IP using SCTP. This IOCC is used between a Cisco PGW 2200 Softswitch and a Cisco ITP.
–Signaling System 7 (SS7)—Contains MTP3, which is used for backhauling SS7 signaling to the Cisco PGW 2200 Softswitch from a Cisco IP Transfer Point LinkExtender (ITP-L).
Agent Management Subsystem
The agent management subsystem (AMS) allows external client software or terminals to gain access to the data in the Cisco PGW 2200 Softswitch. The functions this subsystem supports are:
•Configuration management—Adding, deleting, or modifying parameters and resources needed by the Cisco PGW 2200 Softswitch 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 PGW 2200 Softswitch processes.
•Performance measurement management—Reporting and clearing metrics generated by Cisco PGW 2200 Softswitch processes. You can also define thresholds which, if exceeded, could produce alarms.
•Accounting management—Dumping generated 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 PGW 2200 Softswitch:
•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—Allows any customer using SNMP to access network data for the purpose of managing system performance, measurements, and security. The Cisco PGW 2200 Softswitch uses a master agent, EMANATE from SNMP Research, and the following related subagents to enable SNMP access to the system:
–Operations—A custom subagent that provides access to fault data
–Measurement—A custom subagent that provides access to measurement data
–Critical application monitor—A standard CIAgent subagent that is used to monitor the process manager (procM) process
–Host resources MIB—A standard CIAgent subagent that is used to access data, such as the number of processors, and memory usage in the Cisco PGW 2200 Softswitch
–MIB-II—A standard CIAgent subagent that partially supports the MIB-II standard (RFC-1213)
–File system monitor—A standard CIAgent subagent that monitors thresholds for five file systems
•TIBCO management system—Introduced in Release 9.5(2), the Cisco PGW 2200 Softswitch TIBCO interface enables you to use a TIBCO management system to add, modify, delete, and retrieve provisioning data on the Cisco Cisco PGW 2200 Softswitch. The Cisco PGW 2200 Softswitch supports TIBCO Version 6 daemons and libraries. When this interface is enabled, the Cisco PGW 2200 Softswitch can communicate with one of two TIBCO daemons on your management system:
–Rendezvous Daemon (RVD)—Used when the management system is in the same network as the Cisco PGW 2200 Softswitches. RVD is started automatically on the management system by the TIBCO adapter on the Cisco PGW 2200 Softswitch, unless either the RVD or Routing Daemon (RVRD) is already running.
–Routing Daemon (RVRD)—Used when the management system and the Cisco PGW 2200 Softswitches are not on the same network. You must configure the RVRD routing table and start RVRD manually before activating the interface on the Cisco PGW 2200 Softswitch. See the TIBCO user documentation for information on configuring the RVRD routing table.
Note The TIBCO interface is typically activated during initial install or upgrade. For more information on activating the TIBCO interface, see the Cisco PGW 2200 Softswitch Software Release 9 Installation and Configuration Guide.
•Cisco MGC Node Manager (MNM)—An optional application used for network element management.
•Cisco Voice Services Provisioning Tool (VSPT)—An optional application used for provisioning the Cisco PGW 2200 Softswitch.
•Billing and Measurements Server (BAMS)—An optional application used for collection of CDRs and operational measurements.
•H.323 Signaling Interface (HSI)—An optional application used to provide an interface to H.323 networks.
Fault Tolerance Subsystem
The goal of the fault tolerance subsystem is to ensure call preservation if the Cisco PGW 2200 Softswitch encounters a fault condition. There are two processes that ensure this:
•Failover daemon—Monitors Cisco PGW 2200 Softswitch processes using a heartbeat mechanism. If there is no response to its process polling in a fault-tolerant hardware configuration, the Cisco PGW 2200 Softswitches 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
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 switchover happens before the voice path is established during the call processing, the call cannot be checkpointed to the standby Cisco PGW 2200 Softswitch. Non-established calls in the process of being set up are lost in the Cisco PGW 2200 Softswitch which becomes active after the switchover.
Execution Environment Process Shell
The execution environment provides an operating system process shell used by Cisco PGW 2200 Softswitch processes to access lower-level functionality. Such functionality holds together the I/O, element management, and call engine subsystems on the Cisco PGW 2200 Softswitch. The execution environment infrastructure provides the following functions to Cisco PGW 2200 Softswitch 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 AMS for further processing.
•Log management—Allows Cisco PGW 2200 Softswitch 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 AMS 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 Process
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—Performs the following functions:
–Tracks all bearer resources used. Proxies and tracks the bearer resources in the trunking gateways within the Cisco PGW 2200 Softswitch 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 standby Cisco PGW 2200 Softswitch to guarantee that the bearer channel is not lost during a manual or automatic switchover.
•Connection manager—Interfaces with the nodes and protocols external to the Cisco PGW 2200 Softswitch that are necessary to establish an IP (TCP, UDP, or RUDP) or PSTN connection that is managed by the Cisco PGW 2200 Softswitch. The type of node supported is
–VoIP/VoATM trunking gateways using MGCP.
–Time Domain Multiplex (TDM) trunking gateways using MGCP.
•Call manager—Contains and selects the appropriate protocol adapters. These are protocol-specific entities performing the following functions:
–Communicates with the corresponding protocol-specific 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 IOCM using the IOCCs.
–Creates a call instance when an incoming call 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 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 standby Cisco PGW 2200 Softswitch to guarantee that the signaling link is not lost during a manual or automatic switchover.
Call Instance Component
A call instance is the dynamic component of the Cisco PGW 2200 Softswitch 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 call message is received. There is always a one-to-one relationship between a call instance and a call switched by the Cisco PGW 2200 Softswitch.
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: linking the OCC and the terminating call control (TCC), updating and retrieving the call context structures, interacting with other call engine components, such as the resource manager, connection manager, and call manager, managing bearer resources, such as trunking gateways, using the MGCP, and keeping 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, and the IN trigger module.
•Connection plane manager (CPM)—Communicates with the call engine's resource manager to make the bearer connections to a remote trunking gateway using MGCP.
•CDR Manager—Generates 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—Is the instance of the terminating protocol's state machine.
•Call context—The following are the call context characteristics:
–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 CDBs, which are assembled to build CDRs: calling number, called number, answer time, disconnect time, originating trunk group and circuit identification code (CIC), terminating trunk group and CIC, address translation and route information, ISUP information, ISDN service information, database query information, call completion codes, and other information depending on the type of call.
Cisco PGW 2200 Softswitch Software Directory Structure
This section shows an overview of the UNIX file directory tree for the Cisco PGW 2200 Softswitch 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 PGW 2200 Softswitch software. The default directory is /opt/CiscoMGC; however, this directory name is installer-definable, so do not assume that /opt/CiscoMGC is always used. This is the directory under which all files for the Cisco PGW 2200 Softswitch reside. The sole exception is some temporary files that are created at run time.
Table 1-2 utilizes the variable $BASEDIR to indicate the directory into which the Cisco PGW 2200 Softswitch software was installed.
Table 1-2 Cisco PGW 2200 Softswitch Software Directory Structure
Cisco PGW 2200 Softswitch executable programs that cannot be customized.
MDL source files. MDL source files are generally not provided, but if they are purchased, they will appear here.
Active Cisco PGW 2200 Softswitch dial plan area. This directory contains all theactive dial plans on the Cisco PGW 2200 Softswitch.
Network element configuration files. This includes all provisionable configuration files required for proper operation of the Cisco PGW 2200 Softswitch.
Cisco PGW 2200 Softswitch configuration file library. This is a simple version control system for configuration file changes.
Saved data from the Cisco PGW 2200 Softswitch toolkit applications is stored in this directory.
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.
Cisco PGW 2200 Softswitch license file area. This directory contains the license files that the Cisco PGW 2200 Softswitch needs.
Cisco PGW 2200 Softswitch 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.
Intermediate patch file area. This directory contains the intermediate files during the patch installation.
SNMP agents and configuration area. This directory contains SNMP configuration files and SNMP agents which communicate with SNMP clients on other managing software.
Subsystem communication and persistent storage area. This directory contains files and devices providing communications between the various subsystems in the Cisco PGW 2200 Softswitch. It also contains files providing persistent storage of data for the Cisco PGW 2200 Softswitch.
System logging area. This directory contains the platform logs, MML command logs, and disk monitor logs. See the "Understanding Logging Files" section on page A-1 for more information.
Dumper Spool Area. This directory contains historic reports. See the "Understanding Logging Files" section on page A-1.
Signal Path Trace area. This directory contains all MDL trace logs used for conversion analysis.