Optimizing VME for Telephony Applications

Over the past decade, the worlds of computing and telephony have been drawn together in a mixture that has been ripe with possibilities and hounded by issues of incompatibility, but through it all, computer telephony convergence has been inexorably driven forward by the ever-expanding needs of corporate and individual users. Developers have responded by creating new applications that range from simple PC-based address books, dialers and call control to more sophisticated PBX-linked multi-user applications such as call centers, auto attendant data access systems, voice processing/messaging, and fax server systems.

The first instances of computer-telephone integration began during the late 1980s, with the usage of CTI control links to tie single telephone systems to single computers to serve single applications. In essence, the computer would simply control the telephone connection for use as the applications' communication link. As the PC has evolved into a standard platform, companies established standardized applications programming interfaces (such as Microsoft's TAPI and AT&T's TSAPI) that enabled the development of applications such as desktop faxing, and PC-based call centers and answering machines. However, corporate environments with many interrelated users and application requirements, need much greater integration, flexibility and performance than can be obtained through separate desktop PC systems.

Computer Telephony is now on the threshold of new changes which will go beyond mere integration of legacy systems and instead will provide new architectures designed to allow full convergence of computing and telephony functions. In much the same way that client/server computing has changed database access and other "back office" type functions, Computer Telephony Convergence will make a wide range of telephony functions available to all users. However, the successful delivery of such high-performance integrated systems requires a solid, standards-based foundation upon which to build.

What VMEbus Brings to the Table

Driven by the same sorts of user oriented requirements that spurred the computing world's open systems revolution, the computer-telephony world is seeing a similar demand for open, standards-based, modular systems. At the same time, the high-level of reliability that we have all come to expect from our telephone systems has set an expectation for robustness which cannot be denied. In order to be successful as a new-generation telephony platform, an architecture must meet the following requirements: be based upon a widely-accepted standard; provide a high-speed messaging bus for supporting call traffic; allow for modular configurability and extensibility; provide high reliability, robustness and diagnostics capabilities.

Also, as more feature-rich telephony systems are deployed in mission critical situations, the need for "maintainability-in-place" has made the capability for hot-swap modular replacement a key consideration. The strategy of "one for N sparing" (built-in redundancy using full systems), which has become common practice in the PC-based telephony world, is simply not cost effective for maintaining high-performance multi-user systems. In addition to allowing for maintenance during operation, hot-swap capability also makes it possible to evolutionary upgrade to new telephony features without incurring system downtime.

The VMEbus is a prime candidate for implementing telephony systems because it is both rigorously defined and widely supported. VMEbus system building blocks are already available to support a wide variety of system configurations and feature sets. In addition to choices of chassis, backplanes and CPUs, today's system designer also has available a rapidly expanding selection VMEbus boards targeted at specific telephony applications. First introduced by Motorola in 1981, VMEbus became an adopted standard, IEEE-1014, in 1987. VITA subsequently assumed control of the standard and has enhanced its additional features that enabled 64-bit block transfers and improved performance, configuration management, and mechanical robustness. In May 1995, the resulting VME64 bus was recognized by the American National Standards Institute as ANSI/VITA 1-1994. This expansion of VME bus flexibility and performance, along with its historic industry-wide acceptance, has set the stage for making VME the implementation platform of choice for the telephony systems of tomorrow. The most popular format for VMEbus boards is called 6U by 160 mm or roughly 6" by 9" in area. Some of the major advantages of VMEbus systems include: the ability to use multiple-master CPU configurations to boost performance and processing bandwidth; high system bus bandwidth; mechanically rugged circuit board and chassis formats (based on the IEC 297 Eurocard standard) that use reliable pin-and-socket connectors; backplane I/O configuration flexibility (using available P2 connector pins) and high maintainability by providing for all inter-board communication via the backplane.

There are new features in the VMEbus standard such as VITA1.1 VME 64 Extensions, which include: greater configurability and maintainability by electronically jumpering out boards without disruption of existing interrupt or bus master daisy chains; the resultant capability to make "hot swap" changes of boards while the system is running; the ability to build self configuring systems via geographic addressing and configuration ROM; standard board extractor handles with position sensing allows service people to withdraw boards without causing system upset and without prior notification of the system and keying support that prevents inserting boards into the wrong slots.

Telephony-oriented Enhancements to VMEbus

In order to achieve optimal performance from new-generation telephony applications, a number of industry leaders have worked with Dialogic to develop enhancements and special implementations for VMEbus based telephony systems. Some of the specific areas in which they have made improvements are: adoption of the Signal Computing System Architecture (SCSA) for VMEbus systems; practical implementation of the new VMEbus "hot swap" extensions; development of mechanisms for "On-line Reconfiguration"; a set of Enhanced Diagnostics to support on-line system maintenance and expansion.

The SCSA Architecture

A key to the performance of any computer-based telephony system is integrated access to a high capacity "bearer traffic" bus for switching and distributing media streams, such as voice conversations. In order to avoid performance delays, the bus must have direct access to all system modules and network interfaces. Under the aegis of VITA, Dialogic moderated the industry's development of the Signal Computing System Architecture (SCSA) which provides a comprehensive framework for marrying individual modules together on an industry standard high speed bearer bus and managing them as an integrated telephony system. In addition, SCSA provides a framework to develop software standards that allow third party developers to become components of the system, thereby making them readily usable with all SCSA compliant hardware and software components. At the heart of SCSA is a high capacity TDM (Time Division Multiplexed) highway called SCbus which provides up to 2,048 universal timeslots of bandwidth for interconnecting the various processing technologies used in call processing and media server systems. In a VMEbus system, the SCbus is implemented using the available P2 connector. The VMEbus system bus, implemented as usual on the P1 connectors, continues to handle all system commands and status information while the SCbus on the P2 connectors is dedicated to high-speed bearer signal traffic between the telephony boards, such as voice, fax and DSP processors used for speech recognition synthesis.

The SCbus can be physically implemented on the VMEbus system's P2 connectors in a number of ways, depending upon overall system requirements. When retrofitting existing VMEbus systems to support SCSA telephony functions or delivering systems that will not always be used for telephony, it is often most cost effective to implement the SCbus using ribbon cable or sub-backplane cards. These can easily be connected to the wire-wrap P2 connector pins which protrude from the rear of a most standard VMEbus backplanes. Since SCbus is a logical construct which does not dictate a specific physical implementation, it can even be implemented via front-side inter-card connectors, for those existing systems which don't support P2 connections via the backplane. On the other hand, for new systems which are dedicated solely to telephony functions, it can be more effective to include the SCbus in the PC layout of the backplane itself, thereby reducing the overall number of components in the system and increasing system robustness. Embedding SCSA's industry-standard SCbus in the backplane or implementing it via the rear-side P2 connectors eliminates any requirement for front-side cabling between system modules and allows for unencumbered insertion and removal of all boards. Having free access to all boards, with all I/O, power and signal traffic handled via the backplane, makes possible the implementation of live insertion, hot-swap capability.

Real World Implementation of Hot Swap Capability

The VMEbus standard was not originally designed as a live insertion bus, therefore development of extensions for live insertion had to deal with a number of tough issues. Primarily, how do you add and remove modules from a logical bus, like the VMEbus backplane, without injecting glitches into the bus and upsetting operations? Based upon some pioneering work done by IBM with "pre-biasing" the pins, a method was developed that avoiding signal disruption. In essence, pre-biasing applies a voltage to the pins prior to their insertion into the backplane so that the newly inserted board's signal line capacitance is charged to an electrical state more closely matching that of the backplane. Since the board already has a middle ground voltage (not 0.0 and not 5.0 volts), there is not a major transfer of charge between the board and the backplane.

Of course, real world implementation of pre-biasing requires that somehow the board being inserted must acquire a source of voltage prior to full insertion with the backplane. This required development of a special new VMEbus connector which has a "pre-leading contact" to pull voltage from the backplane's 5 volt power pins and use it to pre-bias the other pins on the board before they make contact with the backplane's signal pins. In order to allow for either top-first or bottom-first canting of the board during insertion, these pre-leading contacts had to be implemented on both the P1 and P2 connectors. Additionally, implementation of live insertion required development of a new logic family called Enhanced Transistor Logic (ETL) which includes special pre-biasing circuitry. Use of ETL in the connector area of a board prevents the pre-biasing voltage from being bled off into the board's internal circuitry prior to completion of the insertion process. These devices also provide "incident wave switching" of backplane signals which maximizes bus transfer speeds.

The other area that needed to be addressed to implement live insertion was management of the VME system's existing daisy-chain mechanisms. The first is the Bus Request and Grant daisy chain which is the way that the priority is set for use of the bus by multiple masters. In standard VMEbus, this issue is resolved by physically arranging the masters in the order of their priority for bus access. Ownership of the bus is then simply "passed down the queue" in standard operations. However, live insertion complicates the situation by making it possible to remove a board from any point in the physical queue, which in normal operation would isolate all the boards to the right of the missing board. The VITA Standards Organization (VSO) resolved this problem by proposing a standard mechanism for switch assemblies on the rear-side of the connectors which can "jumper-out" a board and continue the daisy chain signals across a slot in which a board is to be powered down and/or removed.

Taken together, the improvements allowing live insertion enable telephony based systems to be maintained, repaired and updated during ongoing operation. This capability is of prime importance in new generation telephony systems where users will come to rely on enhanced computer-based functions with the same high level of expectations that they currently have for their phone systems.

On-Line Reconfiguration

Due to capital cost considerations, newly deployed corporate telephony systems typically are not "fully provisioned" at their maximum configurations. This means that most systems are setup with an expectation that they will be incrementally upgraded as new users are added, new features become available and/or service levels need to be maintained against rising usage. In order to accommodate this expectation, Dialogic has developed software which works with the VME64 extensions and allows full reconfiguration of drivers to add to, remove from and reconfigure the system capacity while the system is running.

This on-line software package includes an administration module which monitors the overall system's service and response levels to automatically identify upgrade and reconfiguration requirements. The rest of the software package makes use of a "callable loader" and "configurable driver" utilities which together allow the user to interactively test, load and configure the system modules on an as-needed rather than on a one-time basis.

Enhanced Diagnostics

With sophisticated telephony systems, which may include both multiple CPUs and multiple applications modules working in concert, it becomes increasingly important to have adequate diagnostic capabilities. These fault resilient systems can provide high levels of performance but, at the same time, they can mask latent problems with specific boards that may be functioning at less than optimum levels. To enable its system's partners to create multi-CPU, multi-module, VMEbus-based telephony systems which can be maintained at the highest possible performance levels, Dialogic has also developed a tri-level package of enhanced diagnostics software:

• Pre-boot Diagnostics: allows the system to run a diagnostic to confirm the type of board being added, to read the board's configuration ROM and to load appropriate test software.
• On-line Diagnostics: continually monitors the board (even when it is not under a load from users), confirms availability of all channels and flags any potential problems. This eliminates the risk of the system's transferring a call into a "dead channel".
• Interactive Diagnostics: allows the system administrator to interactively test a suspect board without having to power down or remove it. Also allows graceful isolation of a suspect board by incrementally re-allocating call traffic. Minimizes "swapping out" of boards as a diagnostic technique.

Real World Telephony Implementations

The use of high-performance platforms, such as VME, and architectural enhancements such as SCSA, live insertion, on-line reconfiguration and system level diagnostics, are enabling Dialogic customers to create new and powerful telephony applications. A few primary examples are as follows:

• Messaging applications generally consist of providing non-real-time point-to-point communications enhancements that improve user efficiency by reducing the constraints of time and distance. In addition to voice-mail systems, other messaging applications include things such as remotely controlled fax storing and forwarding and email-to-fax or email-to-voice data conversions.
• FAX on Demand is an interactive database applications which allows the user to make queries and selections via touch tone telephony signals and to direct the server to fax requested information to a specific phone number.
• Interactive Voice Response (IVR) enables a caller to obtain information from a database via a synthesized voice response to the caller's touch tone commands.
• Call Treatment applications conduct inbound/outbound call routing functions (such as international callback, debit card calls, and locator services) without requiring operator assistance.
• Automatic Call Distributor applications automatically route and/or distribute calls among multiple service agents based upon a variety of criteria (such as caller profiles, agent workloads, the call originating location, etc.).
• Name or Voice Dialing which uses voice recognition to allow the user to place calls and/or select functions.
• Advanced Intelligent Networks (AIN) adjuncts pull together many of these functions into an intelligent, client/server type of architecture which automatically queries databases and makes routing and/or call handling decisions based upon information acquired from the calling signal and the associated database. AIN makes use of the out-of-band signaling information (such as the SS7 protocol) contained in today's public switched calls and also relies upon a network of Intelligent Peripherals that act as servers to provide specific telephony functions. AIN in particular, would be far less practical without advanced, open systems, hardware and software platforms such as VMEbus and SCSA.

Industry Partnerships That Yield System Level Solutions

In order to ensure that the above board level telephony functions can be combined into effective system level telephony platforms, Dialogic has worked closely with the VITA Standards Organization and with many leading vendors of VMEbus products. Some of the key partnerships that are producing VMEbus-oriented solutions vital to building telephony systems, include those with Schroff Inc., FORCE COMPUTER Inc., Motorola and CETIA Inc. Specific efforts include:

• Schroff Inc. (Straubenhardt, Germany) has worked with Dialogic to create an "overlay" which implements the SCSA SCbus on standard VMEbus backplanes. This allows users to upgrade existing systems to be SCSA capable without requiring any change out of the system's basic components. Schroff has also embedded all of the VME 64 extensions (live insertion, etc.) in a VMEbus backplane which also supports SCSA bus. This allows builders of new systems to take advantage of both VME 64 extensions and SCSA. According to Laurie Burger, Schroff Product Manager for VME Systems, "The integration of VME 64 extensions and SCbus into a single backplane will form the heart of what will be tomorrow's high performance telephony systems."
• FORCE COMPUTER Inc. has developed system-level VME-based products which use the SCSA architecture to combine FORCE-manufactured SPARC CPUs, running the Solaris operating system, with Dialogic board level telephony platforms. These systems are targeted for use in Advanced Intelligent Networks, as Central Office equipment and/or for dedicated applications such as voice processing/voice messaging, fax servers, call distribution, interactive voice response, etc. According to Mathias Renner, Telecom Market Segment Manager for FORCE COMPUTER Inc., "In principle, the synergy of FORCE and Dialogic is excellent. Our expertise has been in VME since 1981 with product focus on CPUs, single board computers and system integration while Dialogic's flexible board-level products provide high performance telephony platforms that can support a wide array of third party SCSA software solutions."
• Motorola Computer Group (MCG) has worked with Dialogic throughout the development of the SCSA VMEbus product line of telephony products. MCG's XR Series of VMEbus based systems are targeted at telephony applications for use in telecom exchange offices and Advanced Intelligent Networks. According to Noel Lesniak, Market Development Manager for Telecommunications and Intelligent Networks, "One of the biggest growth areas for future telephony needs will be in the Central Office equipment arena as customers look to Central Offices for a wider range of AIN-based services. These Central Office systems typically also require higher levels of robustness and reliability. Dialogic's VMEbus products are key to providing the voice processing component of our system offerings in this area."
• CETIA, a US subsidiary of Frances' Thomson CSF, has partnered with Dialogic to offer CETIA's PowerPC based VMEbus CPU boards in SCSA telephony oriented platforms running AIX. According to Paul Martino, Sales Manager of CETIA, "SCSA will help standardize telephony products so you can mix and match rather than always having to build on a customized basis."

The Final Analysis - How Does It Play For the Phone Companies?

Maybe the benefits of VMEbus can be summed up best from the perspective of a major manufacturer of Central Office Equipment for use by telephone operating companies. For these insights, we can turn to Cognitronics Corporation, a major manufacturer of network announcement platforms for over 30 years. According to Michael Keefe, VP of Engineering for Cognitronics, "You may never have heard of Cognitronics, but you've heard our voice because it's in the network throughout North America. As a maker of CO equipment, we see VME as perfectly suited for switch manufacturers who are looking for reliability and also looking for NEBS type compliance where you attach all cabling to the back and plug boards from the front. With VME you don't have to struggle with a mass of cables, plus you get high MTBF, low maintenance costs, and high flexibility." "Also, the market is moving to Advanced Intelligent Networks, where services can be mixed and matched to optimize system responsiveness and configurability. As a result, high performance Intelligent Peripheral platforms for AIN are becoming the hot item in the market. With the combination of VME-based systems, standardized APIs like SCSA, and plug in processors like Dialogic's voice boards, we've got lots of opportunity to keep raising the levels of both performance and features. Telephony today is kind of like the computer industry when open systems first came along - a standardized level playing field for vendors and lots of options developing for the end customers."

Non-copyrighted article. Reprinted with permission.

This page last updated: August 16, 1999

Return to the main VMEbus FAQ Page