Cisco Multiservice Packet Network Solution Overview
Table of ContentsSolution Components
Cisco MGX 8230, 8250, and 8850 with VISMCall Agent
Cisco AS5400 and AS5400HPX Gateways
Optical Peripheral ModuleProtocol Support
Interconnection Structure Module
Virtual Termination Call Handler
Basic Service Handler
Operation and Maintenance Server
This chapter provides a description of the key components—the media gateways and call agents—of the Cisco Multiservice Packet Network Solution. See the following sections for further information on these components:
The focus of each section is to define the particular features used within the solution. Refer to the Cisco Multiservice Packet Network Solution Documentation Guide for links to the product documentation sets for further detailed information on each component.
The MGX 8230 with VISM, AS5400, and AS5400HPX are suitable for smaller end offices, whereas the MGX 8250 and 8850 with VISM are recommended for larger applications and to allow for future capacity upgrades. Either the Cisco AS5400 or AS5400HPX media gateway is the preferred solution where universal port capability is required.
The Cisco MGX 8230, 8250, and 8850, together with the VISM, are the highly scalable carrier class platforms that deliver the voice services in combination with the Italtel Multiservice Switching System (iMSS) call agent. All components—control processor, IP modules, switching fabric, network interfaces, service interfaces, critical backplane signals, power supplies, power modules, and cooling fans—have 100 percent system redundancy, meeting the demand for high availability.
The MGX 8230 with VISM is suitable for smaller end offices, whereas the MGX 8250 and 8850 with VISM are recommended for larger applications and to allow for future capacity upgrades. The MGX 8230 has a 1.2 Gbps backplane capacity, eight slots for the VISMs, two slots for the Service Resource Modules (SRMs), and two slots for redundant Processor Switch Modules (PXM-1 cards). See Figure 2-1 for the layout of the MGX 8230.
Figure 2-1 MGX 8230 Platform—Front View
The MGX 8230 supports both SRM and SRM/E (Enhanced SRM) cards. The Cisco Multiservice Packet Network Solution recommends use of the SRM/E one-port STM-1/OC-3 back card; this provides built-in bit error rate tester (BERT) capabilities for the E1 lines, bulk distribution, and loop back and redundancy capabilities.
The MGX 8250 and 8850 have an identical chassis of two shelves of 16 cards, with 24 slots for the VISMs, four slots for the SRMs or SRM/Es, and two slots for the redundant PXM-1 cards. The MGX 8250 has a 1.2 Gbps backplane capacity whereas the MGX 8850 has a backplane capacity that can range from 1.2 Gbps to 45 Gbps. See Figure 2-2 for the layout of the MGX 8250 and 8850 platforms.
The VISM service modules can operate in a 1:N redundancy mode; that is, one module on each shelf is designated as a backup. For example, for a fully loaded 8250 or 8850 chassis with 1:N redundancy, two of the 24 VISM cards would be used as backup, and 22 cards would carry traffic. With 1:1 redundancy, each shelf can support six redundant pairs. Note that the individual redundancy groups must offer backup on the upper and lower shelves independently, and the SRM cards must be in redundant pairs.
Figure 2-2 MGX 8250 and 8850 Platforms—Front View
The VISM is front and back card set. Each VISM supports up to eight E1 lines (using RJ48 or SMB connectors) through ports located on the back card of the two-card set. Each line is configured either for binary 8-zero substitution (B8ZS) or alternate mask inversion (AMI) coding, with voice compression to G.711, G.726 (32K), and G.729ab coder-decoder (codec) standards. Line failures that are detected cause the VISM to generate E1 facility alarms, and lines can be tested using continuity tests and line loopbacks. The VISM can connect directly to the time-division multiplexing (TDM) E1 lines through ports located on the back card, or optionally via the bulk distribution capability of the SRM/E card.
The VISM communicates with the packet network for transmitting and receiving the voice payload by using the STM-1 port on the PXM-1 card. Permanent virtual circuits (PVCs) are setup between the MGX and the edge router, and all packets are sent across these PVCs regardless of their destination. The router is responsible for extracting the IP address and correctly routing the cells. For reliability, VISM supports two independent STM-1 interfaces each connected to a separate router, and each with its own PVC—one is designated the primary and one the secondary.
The Cisco Multiservice Packet Network Solution also supports the VISM-PR, a new generation VISM with an additional G.723.1 codec, and a higher density daughter card that provides increased DSP capacity for full support of eight E1s with codecs G.726 and G.729ab.
See Table 2-1 for configuration rules for the VISM, VISM-PR, and PXM cards supported in the Cisco Multiservice Packet Network Solution.
Table 2-2 lists the codecs supported by each VISM module within the Cisco Multiservice Packet Network Solution.
Platform components are dependent on the size of the application. For small applications, the MGX 8230 Edge Concentrator is recommended. See Table 2-3 for a configuration that supports up to 32 E1 lines using one SRM/E card. See Table 2-4 for a configuration that supports up to 64 E1 lines using two SRM/E cards, one on each shelf.
For medium configurations, the MGX 8250 or 8850 with VISM is recommended. See Table 2-5 for an MGX 8850 configuration that supports up to 96 E1 lines using two SRM/E cards. See Table 2-6 for a configuration that supports up to 192 E1 lines using four SRM/E cards.
Special gateway controller protocols are used between the call agent and the VISM. These protocols are transmitted as User Datagram Protocol/Internet Protocol (UDP/IP) datagrams to the edge router on the same PVC as the voice traffic.
The Media Gateway Control Protocol (MGCP) provides the call control for the setup and teardown of calls. The VISM Software Release 2.1 supports MGCP Version 0.1, and the VISM Software Release 3.0 supports MGCP Version 1.0.
The Simple Gateway Control Protocol (SGCP) and Simple Resource Control Protocol (SRCP) are used by the call agent to verify that the VISM is operational, and for auditing the status of the lines. Both the VISM classic and VISM-PR cards support SGCP Version 1.1 and SRCP Version 1.0. Figure 2-3 shows the control traffic protocols in a sample configuration with all components in the same location.
Figure 2-3 Control Traffic between the VISM and iMSS Call Agent
The voice traffic is first formatted into a Real-Time Transport Protocol (RTP) packet, then encapsulated in a UDP and then an IP packet, and then converted to AAL-5 ATM cells (that comply to RFC 1483) for transmission to the network. RTP is used to allow time-stamping of the voice samples to permit dejittering of samples transmitted to the destination TDM line. Figure 2-4 shows the voice bearer protocols in a sample configuration with VISMs connected to edge routers dedicated to voice traffic.
Figure 2-4 Voice Bearer Traffic
See Figure 2-5 for a sample physical configuration for a voice-only deployment of MGXs with VISMs as the media gateways. The call agent for this configuration is the iMSS-4040 providing TDM PRI and V5.2 connectivity, running in an enhanced configuration. The line cards require a TDM Switching matrix card on the Optical Peripheral Module (OPM) of the iMSS call agent, and an Add/Drop Multiplexer (ADM)—either third party or Italtel—to handle the E1 lines for the iMSS-4040, and to handle the PRI and V5.2 connections. In this sample configuration, the ADM is also required to handle the communication with the VISM over the E1 rather than STM-1 connection.
The redundancy in the topology is achieved using dual virtual LANs and multiple components—MGXs with VISMs, Catalyst switches, and Cisco routers—with multiple connections to the MPLS network. A recommended configuration is to use multiple Cisco 7500 series routers as edge routers to aggregate the voice traffic because they make a clear separation between traffic aggregation and the core network routers, and provide a high level of redundancy. Any data traffic should be handled by additional Cisco routers. The voice-based Cisco routers can route local traffic within the point of presence (POP) without any load on the core, handle MPLS label imposition and disposition, and determine traffic classifications. The routers run the Hot Standby Router Protocol (HSRP) so that the iMSS call agent detects a virtual router rather than active and standby routers.
Figure 2-5 MGX with VISM Physical Connections—Enhanced Call Agent Configuration
PVCs are setup between the MGX and the edge router, and all packets are sent across these PVCs regardless of their destination. For reliability, VISM supports two independent STM-1 interfaces each with its own PVC—one is designated the primary and one the secondary. Loopback cells are sent every 200 ms on each PVC as the heartbeat mechanism.
The Cisco AS5400 or AS5400HPX media gateway together with the Italtel iMSS call agent can be used to provide universal port services. This universal port functionality allows the media gateway to operate simultaneously as a network access server (NAS) and a voice gateway to deliver universal dial services—analog modem, digital modem, fax, and Voice over IP (VoIP)—on any port at any time.
The Cisco AS5400 and AS5400HPX media gateways support two 10/100 Mbps Ethernet LAN ports and have seven slots for Dial Feature Cards (DFCs). One or two DFC slots can be used for trunk feature cards, and the remaining slots can be used for Digital Signal Processor (DSP) cards. All cards are hot swappable.
Both media gateways support the 8-port E1/PRI termination trunk feature card and the 60- and 108-Universal Port Feature cards. The 8-port E1/PRI card provides physical termination for E1, PRI, or intermachine trunks (IMTs). The universal port feature cards support the modem, wireless, voice, and fax calls. Modem-management features are available for troubleshooting, including modem status, real-time call-in-progress statistics, modem activity log, hard/soft busy out, and modem firmware upgrade.
The maximum configuration is 16 E1 lines (two E1/PRI DFCs) and five 108-Universal Port DSPs in the seven slots. This configuration provides a total of 496 calls (determined by 31 calls on each E1 line). An alternative option would be to use four 108-Universal Port Feature cards and one 60-Universal Port Feature card to better match the maximum number of calls, but this is a balance between requirements for redundancy (DSP cards are pooled), inventory management issues due to a mix of cards, and cost of the cards. See Table 2-7 and Table 2-8 for sample AS5400 and AS5400HPX bundles.
The AS5400 and AS5400HPX share the same architecture and the same adaptors, and run the same Cisco IOS code. The AS5400HPX has a slightly higher performance on E1 lines due to differences in the motherboard and better memory management, and is thus able to sustain more calls.
The AS5400 and AS5400HPX require the MGCP + NAS Package that is part of Cisco IOS IP PLUS. Refer to the most current Release Notes for Cisco Multiservice Packet Network Solution for details of the required Cisco IOS release.
The Cisco Access Registrar (CAR) is an optional component that can provide the authentication, authorization, and accounting (AAA) features required for the dial services authentication. CAR is a standards-based Remote Authentication Dial-In User Service (RADIUS) server.
CAR is based on a client/server model. The media gateway (client) requests name and password information from the server; the server authenticates this information and determines which dynamic resources the user is authorized for, returning either an acceptance containing the necessary configuration information, a rejection to deny access, or a request for further information.
Any one or all of the authentication, authorization, or accounting functions can be subcontracted to another RADIUS server. In some cases, the CAR could then act as a proxy server. For example, the CAR could proxy to a Lightweight Directory Access Protocol (LDAP) server for access to directory information about users for authentication.
Based on a Sun Solaris, CAR helps deploy access services by centralizing AAA information while simplifying provisioning and management. However, it is important to correctly size the number of CARs required based on the expected load, and to distribute these around the network for redundancy.
See Table 2-9 for a list of CAR components.
Special gateway controller protocols are used between the call agent and the AS5400 or AS5400HPX. These protocols are transmitted as UDP/IP datagrams to the edge router on the same PVC as the voice traffic.
SGCP and SRCP are used by the call agent to verify that the AS5400 and AS5400HPX are operational, and for auditing the status of the lines. Both the AS5400 and AS5400HPX support SGCP Version 1.1 and SRCP Version 1.0. Figure 2-6 shows the control traffic protocols in a sample configuration with all components in the same location.
Figure 2-6 Control Traffic
The voice traffic is first formatted into an RTP packet, then encapsulated in a UDP and then an IP packet, for transmission over Fast Ethernet to the Cisco router and thus the network. RTP is used to allow time-stamping of the voice samples to permit dejittering of samples transmitted to the destination TDM line. Figure 2-7 shows the voice bearer protocols in a sample configuration with AS5400s connected to edge routers dedicated to voice traffic.
Figure 2-7 Voice Bearer Traffic
See Figure 2-8 for a sample physical configuration for a voice-only deployment of AS5400s as the media gateways. The AS5400s support the TDM links to the Public Switched Telephone Network (PSTN) and are connected to edge routers dedicated to voice traffic. The call agent for this configuration is the iMSS-4050 running in a pure configuration.
The redundancy in the topology is achieved using dual VLANs and multiple components—AS5400s, Catalyst switches, and Cisco routers—with multiple connections to the MPLS core. The AS5400 accepts a dual power supply, although it is not a fully redundant system. Because a failure of the media gateway would disable the communication, it is recommended to use a minimum of two gateways with the trunk group split between them.
Figure 2-8 AS5400 Physical Connections—Pure Call Agent Configuration
A recommended configuration is to use multiple Cisco 7500 series routers as edge routers to aggregate the voice traffic as they make a clear separation between traffic aggregation and the core network routers, and provide a high level of redundancy. Any data traffic should be handled by additional Cisco routers. The voice-based Cisco routers can route local traffic within the POP without any load on the core, handle MPLS label imposition and disposition, and determine traffic classifications. The routers run the Hot Standby Router Protocol (HSRP) so that the iMSS call agent detects a virtual router rather than active and standby routers.
As a call agent, both the iMSS-4040 and iMSS-4050 interpret the signalling messages and route the calls through the packet backbone. The iMSS is the Media Gateway Controller (MGC) and Signalling Gateway (SG), controlling the voice traffic through well-defined standard protocols. The MGC uses MGCP to control the Cisco media gateways and thus control the voice calls over the MPLS network. The SG handles the dialogue between all the various Telecom signalling protocols based on the Signalling System 7 (SS7) suite.
As a TDM switch, iMSS-4040 incorporates all the features of a Class 4 switch, such as the powerful and scalable circuit switching fabric and call-control functions. In addition, the iMSS-4040 can operate as a Class 5 switch, accepting ISDN primary rate access (PRA) coming from business customers (for example, private automatic branch exchange [PABXs]) as well as plain old telephone service (POTS) and ISDN basic rate access (BRA) subscribers via V5.1 and V5.2 interfaces.
The iMSS consists of the following main components or telephony modules: Optical Peripheral Module (OPM), Interconnection Structure Module (ISM), Basic Service Handler (BSH), Virtual Termination Call Handler (VTCH), and Operation and Maintenance Server (OMS). Each iMSS can include up to 100 of these modules.
The OPM is the key element of the iMSS call agent, providing the switch control and call handling, and the synchronization and timing for the TDM line interfaces. The OPM consists of control processors, a synchronization and timing unit (card identifier USTCON), a time slot switching matrix, four slots for multiservice cards, and five slots for interface cards. See Figure 2-9 for the layout of the OPM.
Figure 2-9 OPM Front View
Two Main Control Processors (UELABI) work in hot-standby mode to control the internal OPM elements and external communication devices and channels, although only one is in control at any one time. Each processor card has a dual 10BaseT Ethernet card (UETBAK) for intermodule communication and communication with the OMS. Similarly two Peripheral Control Processors (U32PCP) that work in hot-standby mode handle the control channels.
Each line card (USTM1N) provides one Synchronous Digital Hierarchy (SDH) STM-1 interface (155 Mbps supporting 63 trunks at 2 Mbps), with either optical or electrical interfaces. Optical STM-1 SDH interfaces (TOSTM1) have line protection using automatic path selection (APS) according to ITU-T G.783; electrical STM-1 SDH interfaces (TESTM1) have Equipment Protection Switching.
For releases 2.0 and 2.1 of the Cisco Multiservice Packet Network Solution, the line cards require an ADM (either third party or Italtel) to handle the E1 lines for both the iMSS-4040 and iMSS-4050, and to handle PRI and V5.x connections for the iMSS-4040. The ADM is also required to handle the communication with the VISM if there is no STM-1 connection on the VISM.
Table 2-10 OPM Cards
The ISM allows TDM switching to be extended over multiple OPMs. The ISM can be used only in distributed and multi-module iMSS-4040 configurations. See the "Configurations" section for sample configurations.
The VTCH software module supports the communication with the Cisco media gateways using MGCP and SRCP, as well as manage the signalling requirements with the SS7 network. The VTCH is implemented on the Centralized Processing Server (CPS). The CPS is based on the same control processor and communication components as the OPM. However, because the CPS's only requirement is to provide processing capacity, it does not require the synchronization and timing unit, time slot switching matrix, or line cards.
The BSH software module provides Intelligent Network (IN) services such as call screening, number portability features, and basic number transactions such as toll free numbers. The BSH is implemented on the CPS, and as with the VTCH module, the only requirement of the CPS is to provide processing capacity, thus not requiring the synchronization and timing unit, time slot switching matrix, or line cards.
The BSH module uses an integrated Service Control Point (SCP) database for the IN services, with the internal call handling based on the Intelligent Network Application Part Capability Set 1 (INAP-CS1). The integrated database can be within one BSH module, and thus physically located in a central POP, or distributed over multiple BSH modules, and thus multiple POPs. The Service Switching Point (SSP) functionality that queries the SCP database to provide the IN services is implemented in either an OPM or VTCH module or modules. Each OPM or VTCH module requires an associated BSH module, up to a maximum of five BSH modules correlated to the same subsystem number.
An external SCP database can used instead of the one integrated in the BSH module(s). For support through an external SCP, the iMSS call agent uses INAP-CS1 based on ETS 300 374-1, September 1994 (ITU-Q1600). In this case, communication with the external SCP databases is handled by the OPM modules.
The OMS is a centralized unit that manages the physical and logical configuration of the whole system, collecting billing data, monitoring traffic measurements and alarms, and providing the interface to the local operator and to the MultiService Element Manager (MSEM). See "Solution Management" for further information.
The OMS is a fully redundant system with master and slave units dually connected over two Ethernet links, with an additional backup serial line in case of faults on all Ethernet interfaces. The dual Ethernets allow redundant interfaces to both the other iMSS modules, as well as to operator consoles and the MSEM.
The iMSS-4040 and iMSS-4050 use the ISDN User Part - Inter Virtual Switch (ISUP-IVS) proprietary protocol for interexchange signalling. An exchange is defined to be an iMSS, single or distributed, with its own dial plan (resident on OMS). The proprietary Intra Module Control Protocol (iMCP) is used for intraexchange communication between the OPMs and between the OPMs and OMS.
The iMSS-4040 and iMSS-4050 use SS7 signalling protocols to handle the dialogue between the various Telecom components, and uses MGCP to control the Cisco media gateways and thus the voice calls over the IP network. For releases 2.0 and 2.1 of the Cisco Multiservice Packet Network Solution, it is necessary to backhaul the SS7 signal from remote POPs to the central main POP using the existing SS7 signalling network. The iMSS call agent provides full services for the SS7 network.
It is possible to have a single-site (centralized) or a multisite (distributed) iMSS call agent depending on whether the central office (CO) is located in one site or geographically distributed in several locations (POPs) linked together. The interconnection network, carrying signalling links and bearer channels among the POPs, can be either a pre-existing or a new circuit-based or packet-based installation.
See Figure 2-10 for an example of the iMSS-4050 call agent in a centralized configuration with the OPM and CPS in one location (the main POP). SS7 is being carried over the existing SS7 signalling network.
Figure 2-10 Single iMSS-4050 Call Agent—Centralized Configuration
See Figure 2-11 for an example of the iMSS-4050 call agent in a distributed configuration. This configuration has additional OPMs and CPSs in the remote locations (remote POPs), distributing the SG and MGC functions to the remote POPs. iMCP is used for intraexchange communication between the OPMs and between the OPMs and OMS.
Figure 2-11 Single iMSS-4050 Call Agent—Distributed Configuration
See Figure 2-12 for an example of the iMSS-4040 call agent in a distributed configuration. This configuration has additional OPMs and CPSs in the remote locations, using iMCP for intraexchange communication between the OPMs and between the OPMs and OMS. Additional ISMs are also required to allow the TDM switching to be extended over the multiple OPMs.
Figure 2-12 Single iMSS-4040 Call Agent—Distributed Configuration