Virtual Switch Controller

This new infrastructure consists of the following distributed network elements: • Media gateways MGs • Packet networks • Signaling, services, and call control • Service provisioning and

Chapter 13 Virtual Switch Controller

This chapter focuses on Cisco's Virtual Switch Controller (VSC), which is a key architectural component of the virtual switch The concept of a virtual switch is based on today's voice networks moving from a time-division multiplexing (TDM) infrastructure to a new packet-based, voice service infrastructure This new infrastructure consists of the following distributed network elements:

• Media gateways (MGs)

• Packet networks

• Signaling, services, and call control

• Service provisioning and management

The collection of these elements constitutes a virtual switch where intercommunication is accomplished using open and standards-based protocols Cisco's VSC provides the virtual switch's call-control functions Drawing upon analogies of existing TDM switches, the VSC implements the functions of the software components found in a Service Switching Point (SSP) Other VSC-equivalent terms include Media Gateway Controller (MGC), call agent, soft-switch, and software-based SSP

Overview of the Virtual Switch

The virtual-switch concept evolves the current paradigm of TDM switches into a distributed architecture This concept is realized through the use of the:

• Packet-based multiservice access methods, equivalent to Public Switched Telephone Network (PSTN) line cards

• Distributed packet-bearer switching networks, analogous to TDM switch fabric

• Call-control servers such as VSC, analogous to SSP functionality

In addition to functions commonly found in a traditional SSP, however, the VSC adds additional capabilities that cater to applications such as H.323 and Session Initiation Protocol (SIP) The VSC operates in a UNIX environment with the goal of providing customers a high degree of open interfaces and programmability Cisco's realization of the virtual switch is a component of the Cisco Open Packet Telephony (OPT)

architecture

Open Packet Telephony

Cisco's Open Packet Telephony (OPT) architecture is based upon the creation of three logical planes:

connection control, call control, and services Each plane represents a different functional aspect of a voice service and interacts with the other logical planes through well-defined open interfaces The three planes are organized into a hierarchy, with connection control at the lowest level, call control above connection control, and services above call control Figure 13-1 illustrates the functional composition of the OPT architecture

Figure 13-1 Open Packet Telephony Architecture

The VSC provides the following call control-plane functions in the Cisco OPT architecture (in the Media

Gateway Control Protocol [MGCP] architecture, the VSC represents the MGC):

• The connection or bearer control plane encompasses the functionality necessary to set up, maintain, and tear down voice paths through the packet network Existing Cisco AS5300, MGX8850 and 8260,

2600, 3600, 3810, and uBR924 are known as MGs The connection control plane communicates with the call-control plane using an industry-standard control protocol such as Simple Gateway Control Protocol (SGCP) or MGCP

• The call-control plane comprises the functionality necessary to signal, process, and route voice and data calls over the packet network Functions within this layer are close to those found in the call-processing logic of an existing TDM switch Typical call control-plane functions include Signaling System 7 (SS7) protocol processing, digit analysis and manipulation, route selection, hunting, switch-based features, and interfacing with external service logic programs

The call-control plane communicates with the connection control plane using MGCP or SGCP The architectural intent of this interface is to cleanly separate the connection control from the call control in such a way that the call-control plane is independent (and unknowing) of the underlying voice packet transport This enables the same call-control plane to be used with either a Layer 3 (Internet Protocol [IP]) or Layer 2 (Asynchronous Transfer Mode/Frame Relay [ATM/FR])-oriented MG

The call-control layer also communicates with the service plane to provide flexible, enhanced services This interface is typically a standards-based Intelligent Network (IN) protocol running over SS7

transaction capabilities application part (TCAP), although many additional vendor-proprietary variants and extensions exist

• The service plane encompasses the logic necessary to provide enhanced nonswitch-resident services You can accomplish such functions with Service Control Points (SCPs) or service nodes When using SCPs, the call-control plane signals the SCP using the Advanced Intelligent Network (AIN) or IN protocol over SS7 TCAP Typical SCP applications include number translation (800#), account code authentication, credit card validation, and Virtual Private Network (VPN)

When using Service Nodes, the VSC typically routes a call to the Service Node for processing The service node then applies its own feature-specific treatment to the voice or data stream and completes call routing to the intended destination Depending upon the feature, the service node can either remain in the path of the call or give control of the call back to the VSC Typical service node

applications include voice mail, debit card, and voice-activated dialing

Packet Voice Network Overview

VSC provides call-control capability for the next-generation network It controls how narrowband TDM voice traffic is consolidated over the packet infrastructure, and ways you can apply services to those calls You can use the VSC in a variety of applications to provide call-control functions Examples of applications enabled on the packet voice network architecture include the following:

• Packet voice inter-exchange carrier (IXC) tandem applications

• Packet voice Local Exchange Carrier (LEC) Class 4 relief applications

• Endpoint client multimedia applications

• Corporate voice on-net and off-net services

• Voice over IP (VoIP) local/end office applications on cable infrastructure

Figure 13-2 depicts a generic packet voice application and illustrates various architectural components as well as how they fit and interact with each other

Figure 13-2 Packet Voice Network Architecture

Network Elements

This section reviews each network element identified in Figure 13-2 These elements include the following:

• VSC

• MG

• SCP

• Service node

• Cable head end

• Residential gateway

• H.323 endpoint/client

Virtual Switch Controller

At a high level, the virtual switch controller (VSC) provides the following core capabilities:

• Call-signal processing including Integrated Services Digital Network (ISDN) Level 3 (Q.931), SS7 Level 4 (ISDN User Part [ISUP]), H.323, and Multi-Frequency/channel-associated signaling (MF/CAS),

as well as call signaling toward devices located at residential gateways connected through cable or digital subscriber line (DSL) Customer Premise Equipment (CPE); also includes the capability to translate between different signaling types on different call legs

• Address resolution, call routing, resource management, connection control, and Call Detail Record (CDR) generation

• Service access functions for accessing services executing on external server platforms (such as SCP

or Service node)

• Management interfaces using Simple Network Management Protocol (SNMP) for faults, performance, and configuration; Web-based configuration tool and element management system

Media Gateway

Media Gateway (MG) performs the following high-level functions:

• Physical T1/E1 TDM facility termination from the PSTN or Private Branch eXchanges (PBXs)

• Communication with the VSC for call setup and teardown using SGCP or MGCP

• Echo cancellation into the circuit-switched network

• Balancing the jitter buffers

• Voice activity detection (VAD), such as silence suppression and comfort noise regeneration

• Voice compression using International Telecommunication Union (ITU) recommendations such as G.711, G.723.1, and G.729

• Tone generation, which generates dial, busy, ring-back, and congestion tones

• Dual-Tone Multi-Frequency (DTMF) transport, which enables use of touch tones for voice mail

applications with codecs that support DTMF detection/transport

• µ-law and a-law transcoding when required

• Quality of service (QoS) support

Service Control Point

The SCP provides the execution environment for service logic The SCP is responsible for processing

transaction requests and returning a response A typical transaction request in the voice world is a number translation

Examples of this service include 800 (toll-free) service and Local Number Portability (LNP) A toll-free

application running on the SCP, for example, has a sophisticated logic that enables the end user to control how incoming calls are routed You can base toll-free call routing on dialed number, time of day, day of week, geographic point of origination, and even on how busy a terminating automatic call distribution (ACD) might be

at a given moment Customers or the service provider (SP) can own the SCP

Service Node

The service node component of Cisco's voice architecture is realized by Cisco's open, programmable switch of the VCO The VCO/4k is modular and scalable It incorporates compatible generic software, universal network interfaces, and service resources and employs advanced technologies such as SS7, ISDN, hierarchical call control, and SNMP network management In addition, the VCO/4k are Central Office (CO)-compliant, and you can deploy them in fully redundant or nonredundant environments

Cable Head End

The Universal Broadband Router is an integrated cable modem termination system (CMTS) and Cisco 7200 series router utilizing radio frequency (RF) line cards The Universal Broadband Router provides a single integrated solution with CMTS functionality, the capability to terminate the Data-over-Cable Service Interface Specifications (DOCSIS) protocol, and the capability to perform all the data routing functions required

Instantiation of this component also includes a Digital Subscriber Line Multiplexer (DSLAM)

Residential Gateway

The residential gateway is a voice/data CPE device that provides from two to four ports of plain old telephone service (POTS) capability The device runs the DOCSIS protocol to provide packet data and telephony

services over the hybrid fiber-coaxial (HFC) cable to the CMTS Another example of this component also includes a DSL modem

H.323 Endpoint/Client

The H.323 client represents a broad range of voice/multimedia applications that are hosted natively on the IP network The H.323 endpoint is covered in detail in Chapter 10, "H.323."

Network Interfaces

The four main VSC network interfaces are signaling termination, inter-VSC signaling, connection control, and services control, as illustrated in Figure 13-3

Figure 13-3 Network Interfaces

Each VSC network interface is discussed in the following sections

Signaling Termination

The signaling termination capability enables the VSC to mediate between many signaling variants, such as SS7, Primary Rate Interface (PRI), CAS, and H.323, to name a few

SS7 Links

Several mechanisms are available to terminate SS7 signaling traffic on the VSC:

• Nonassociated signaling (A-links)—Terminated directly on the VSC using either a V.35 or T1/E1 physical interface Optionally, to increase reliability characteristics, you can configure a set of

Signaling Link Terminals (SLTs) to handle the lower layers of SS7 The SLTs are implemented using Cisco 2600 series routers fronting Sun servers that host the VSC application

• Fully associated signaling (F-links)—Carry bearer traffic and are terminated on the packet gateway The packet gateway is responsible for executing Message Transfer Parts (MTPs) 1 and 2,

encapsulating MTP Layer 3 (MTP L3) protocol data units and sending them to the VSC for MTP L3 and ISUP processing The transport between the packet gateway and the VSC is carried out using Reliable User Data Protocol (RUDP), a thin-reliability layer on top of User Data Protocol (UDP)

PRI Links

The PRI links carry a D channel and terminate directly on the voice gateway The voice gateway peripherals execute Level 1 (L1) and Level 2 (L2)—the lower layers of the PRI interface (Q.921) Layer 3 (L3; Q.931) is encapsulated in the RUDP packet and sent to the VSC for call processing

CAS Links

CAS links terminate directly on the voice gateway Low-level CAS protocols (for example, line and address signaling) are handled by the gateway periphery You use a CAS Application Programming Interface (API) to backhaul the call-processing events over IP to the VSC for call handling

H.323

The VSC handles the precall-level Registration, Admissions, and Status (RAS) requests as well as call-level Q.931 requests originated from the H.323 clients This signaling termination follows delivery procedures described in the H.323 standard In other words, the VSC has H.225 RAS/Q.931 capabilities, however it does not have H.323 gatekeeper functionality

Inter-VSC Signaling

The VSC-to-VSC protocol scales the network by distributing control over multiple VSC platforms A modified ISUP protocol called Enhanced ISUP (E-ISUP) exchanges call-control information between the VSCs over an

IP network using RUDP MTP information is not required and is, therefore, not transported

The E-ISUP messages also carry Session Description Protocol (SDP) elements in ISUP generic digits

information elements, which the VSC uses to specify connection attributes in SGCP and MGCP

NOTE

The industry is moving toward using SIP or a variant of SIP, known as SIP+, for an inter-MGC

communication protocol

Connection Control: SGCP/MGCP

End-to-end voice connections in the packet network are established using SGCP or MGCP, an open

mechanism to set up connections in IP networks SGCP and MGCP are UDP-based transaction protocols that permit manipulation of the connections represented by physical or logical endpoints The connections are described using attributes such as IP addresses, codecs, and so on SGCP and MGCP manage call setup requests and connections from phones connected to gateways such as cable or DSL modems SGCP/MGCP provide a mechanism to specify grammar sent by the VSC to the residential gateway instructing it how to relay voice events

The VSC also supports a Virtual Switch Interface (VSI) into the Cisco BPX wide-area switch The VSI is a Cisco-defined interface that enables an external device to control a Cisco BPX wide-area switch As the controller, the VSC implements the VSI-master functionality The VSC audits the current connections on the BPX against the current connections on the VSC The underlying interface between the VSC and the BPX is ATM adaptation Layer 5 (AAL5)

In VSI, the controller (the VSC) requests that the switch (the BPX) create, delete, and change connections The switch is required to notify the controller of changes to its synchronization state (active session-id) and/or changes to its logical interfaces (loading changes, state changes, and so on)

Services Control

Access to service can follow two paths:

• IN (AIN/INAP/convergence sublayer-1 [CS-1]) platforms such as SCPs interface initially over

standards-based AIN/INAP interfaces transported over the SS7 network, with future migration to IP-based transport

• Service node services (such as calling cards and voice mail) initially connect over TDM PRI interfaces

In the future, the service node platforms will transition to IP networks to avoid unnecessary TDM/IP inter-working

VSC Architecture and Operations

Figure 13-4 depicts the major functional blocks of Cisco's VSC platform

Figure 13-4 Functional Components of the VSC

Cisco's VSC is an open platform and is built to host third-party developed applications through a set of

powerful application/protocol building tools and associated APIs

These tools include:

• Application Toolkit—The VSC Application Toolkit enables users to customize protocols and their inter-working features The toolkit also provides powerful language tools and an API to develop state- and event-driven applications that reside on the VSC platform

• Conversion Analyzer—The Conversion Analyzer generates output reports using traces in the inter-working engine Information in the report includes message input, conversion, and output

• Simulator—The simulator enables users to create message sets and run them through a mirrored inter-working engine to determine/diagnose application or protocol errors Detailed reports include message input, conversion, and output

VSC-Supported Protocols

A great VSC feature is the fact that its architecture supports multiple access and network protocols New protocols and variations of existing protocols continue to be added to the library Table 13-1 provides a comprehensive list of protocols

Table 13-1 SC-Supported Protocols

Execution Environment

The Execution Environment (XE) provides common services to application programs running on the signaling host The major goals of the XE are the following:

• Provide application programs with a flexible, stable, and consistent infrastructure

• Enable new applications to be more easily integrated with existing applications running on the same platform

• Minimize the amount of work that application developers must do to create a new application

• Provide a simplified interface to operating system services so that third parties can develop custom applications that can run in a process on the VSC

Services provided by the XE include the following:

• Process Management—Enables processes to be managed by the XE This includes orderly startup, shutdown, and monitoring of process health Process management also is used to implement the cut-over to a new version of a process with minimal interruption of service

• Alarms—Enable processes to register, set, and clear alarms Alarm sets and clears are automatically reported to processes that request this service You can use this capability to report alarms to

attached management interfaces, enabling such processes to implement necessary recovery action

• Logs—Enable a process to log messages to shared log files, based on a facility and logging severity level

• Statistics—Enable a process to update shared counters that are used for reporting and alarms Alarms based on shared counters are automatically generated on behalf of all processes on the platform Measurement reports are automatically generated at periodic time intervals

• Command Management—Enables processes to exchange commands and responses This service also is used to provide a unified interface to the protocol conversion engine and/or to external systems that control or monitor the XE platform through a management interface (such as TransPath Man-Machine Language [MML])

• Configuration Management—Enables a process to be notified when configuration data changes It coordinates dynamic reconfiguration across all processes on the platform

• Access Control—Ensures that platform services are provided only to those processes authorized to use them

• Process Shell—Provides a framework used by processes to interface with the services provided under the XE It features a uniform event dispatching mechanism, support for interprocess communication (IPC), timers, and signals as well as a set of foundation classes for applications development

• IPC—Enables processes within the platform to exchange messages

• Signal Handling—Provides an interface for conditions signaled through the operating system

North American Numbering Plan

The VSC can handle the North American Numbering Plan (NANP) as presented to an access tandem or IXC network:

• Operator services (0-, 0+, 00) with or without 10XXX or 101XXXX routed to either a North American number (NXX-XXXX or NPA-NXX-XXXX) or international number (CC+NN)

• Normal calls with or without 10XXX or 101XXXX routed to either a North American number (NXX-XXXX or NPA-NXX-(NXX-XXXX) or international number (CC+NN)

• Support for # end of number indicator This enables callers to press # to prompt the switch to stop waiting for another digit before processing the number dialed

• Cut-through call to carriers (10XXX+# or 101XXXX+#)

• Support for 950-XXXX format numbers (both nature of addresses [NOAs])

• Conversion of NXX-XXXX numbers to NPA-NXX-XXXX numbers

• Support for IN triggers (toll free, premium service, and LNP)

Route Analysis

VSC call routing routes a call from the ingress MG to the appropriate egress MG Call routing does not refer to the routing of packets within the packet cloud; the connection control layer handles this If the originating and terminating MGs are controlled by the same VSC, the call routing takes place in one step within the VSC

If the egress gateway is controlled by a different VSC, both an originating and terminating VSC are involved in call routing The originating VSC analyzes the call request message, such as SS7 Initial Address Message (IAM), and selects a route to reach the egress gateway or terminating VSC that serves the egress gateway The route analysis selects one of the following:

• A "hop-off" or egress gateway connected to the selected trunk group

• The IP address of the terminating VSC that determines the egress gateway

• The residential gateway

A hair-pinned connection in the ingress gateway back out to the originating network

•

If two VSCs are needed, the originating VSC uses E-ISUP to communicate with the terminating VSCs to perform call setup Figure 13-5 illustrates the primary, secondary, and congestion overflow options, as determined by the route selection process

Figure 13-5 Route Selection Process

Digit Analysis

The VSC performs a digit analysis and screening function against A or B numbers (LNP and AIN/INAP

triggers) The dialed or translated number selects the route, and the terminating VSC is responsible for

selecting the egress gateway The selection is carried out first by digit analysis and selection of "preferred" hop-off gateways (such as trunk groups) Then, it is carried out by performing busy/idle handling on the terminating gateway resources, selecting an outgoing circuit on the TDM interface, and, finally, invoking

appropriate signaling procedures (ISUP IAM) toward the terminating PSTN switches Figure 13-6 illustrates the egress gateway selection process

Figure 13-6 Egress Gateway Selection

Reroute on Congestion

The VSC contains the status of trunks connected to the egress gateways (a busy/idle map) that the VSC controls If an egress gateway cannot complete a call due to an internal resource error, an explicit indication is sent back to the VSC with an MGCP/SGCP negative acknowledge The VSC can then choose another route to attempt the call If two VSCs are involved, the terminating VSC informs the originating VSC using E-ISUP (Release [REL] with congestion) and a call reroute is attempted if alternate routes were provisioned

VSC Implementation

The VSC can provide a high level of availability equal to or better than a traditional switch The system, as illustrated in Figure 13-7, is based on Sun fault-tolerant platforms consisting of an active and standby unit and a separate set of SLTs used to terminate SS7 traffic