November 20, 1997

CTI converges on a single TDM bus

Stephen Kempainen, Technical Editor

Computer-telephony resource boards use the CT Bus in new designs and upgrades. The transition to PCI cards is timely for the industry to agree on one
time-division-multiplex bus. The CT Bus enables interoperable products for computer-telephony-integration systems that cost-effectively scale from small-office to large-call-center applications.

Computer-telephony integration (CTI) is a hot topic, but until now, computer-telephony products have not created a mainstream market. One impediment was the Internet's sudden explosion and the uncertainties of Internet Protocol telephony, which both grabbed research-and-development budgets and clouded the already-hazy concept of CTI. However, the CTI industry did not help the situation by fragmenting itself with multiple time-division-multiplex (TDM) buses and software standards. The lack of a single standard perpetuated the telephone industry's proprietary-development environment. Proprietary development resulted in rigid products that were difficult for businesses to cost-justify, because the products may soon be obsolete. However, the industry now endorses the new CT Bus (computer-telephony bus) as a transition to an open-systems development environment that is much like that of PCs. Both equipment manufacturers and application developers can benefit from flexible and interoperable products that are standards-based.

The Enterprise Computer Telephony Forum (ECTF) H.100 hardware-compatibility specification describes the CT Bus for transporting and switching low-latency data streams, such as voice and video data streams, in bandwidth increments of 64 kbps (N×64) (Reference 1). Because of backward compatibility with both the Multi-Vendor Integration Protocol (MVIP) bus and signal-computing bus (SCbus), which were the combatants in the bus wars, new products work in existing systems that have PCI slots (see box "An end to the bus wars"). The CT Bus simplifies application development by providing one interface for developers; therefore, end users will see many competitive and interoperable applications at reduced cost.

Getting CTI to best use computer power to enhance the phone's capabilities is no easy task (Reference 2). Telephony has used computers since voice was first digitized. However, convergence problems exist because PCs and telephony developed along separate and incompatible technology paths. Telephony has low-latency requirements and is event-driven with isochronous data streams, and PCs use asynchronous buses and interrupts that require no real-time response. Melding PCs and telephony involves solving the complicated task of exchanging signal and message data between the telephony network's switching system and computers' general-purpose functions.

Despite a market dominated by proprietary systems, competing open standards, and marketing problems, useful products, such as voice-mail systems, automatic call distributors, and PC-based private-branch exchanges (PBXs), are available. However, lack of flexibility and high cost remain problems. The industry has recognized that it would benefit from a single standard approach to merge PCs and telephony.

The burgeoning of the Internet in the mid-1990s added to CTI market confusion. Talk of inexpensive Internet telephony delayed decisions to invest in CTI systems that might soon be old technology. This procrastination was for good reason, because Internet telephony has price and performance advantages over the public switched-telephone network (PSTN), which is based on 1960s computer technology. The PSTN uses a constant 128 kbps--64 kbps in each direction--for each call connection. On the other hand, Internet telephony takes advantage of DSPs and compression algorithms that deliver the same quality calls at only 6.3 kbps (0 kbps when silent). Usually, only one person talks, saving as much as 20 times the bandwidth. In addition to bandwidth savings, the Internet also provides an open development environment for new applications. Because of the International Telecommunication Union's recent H.323 videoconferencing and audioconferencing standards for packet technology, interoperable Internet-telephony terminals are possible. Now that the direction of Internet telephony is clearer, the CTI industry can take advantage of the situation by integrating Internet telephony into computer-telephony products. However, vendors would benefit from agreeing on one architecture for this integration.

In an attempt to position the CTI market to take advantage of technology developments, the ECTF established a framework for product interoperability. The Architecture Framework document promotes high-level architecture to ensure that the ECTF working groups develop cohesive agreements (Reference 3). The framework details a client/server model by describing logical telephony and application servers that can be separate units, units integrated into one server, or units wrapped around a server. Through standardization of hardware and software interfaces, the ECTF plans to reduce product-development complexity. Products developed within this architecture will be able to scale from small-office to large-call-center applications. With this architecture, PC programmers can access the PSTN through the H.100 distributed-switch fabric on a PC and, therefore, can create any telephony application they want.

The ECTF specifies software interfaces throughout the architectural model (Figure 1). The base software standard is the S.100 media- and switching-services interface that provides the application-programming interface (API) for use by CTI-application authors. Applications using this API are the first step toward multivendor, shared-resource servers. The S.200 media-services transport-protocol interface is for communication between the client and the server. However, equipment manufacturers that supply both the client and server can use a private interprocess-communications protocol instead of the S.200. The S.300 service-provider interface permits the telephony server to interchangeably use resources from different vendors. The S.900 administrative-services interface includes functionality for managing the server's configuration, faults, performance, security, and accounting.

These software standards complement, rather than replace, the de facto call-control API standards, such as Microsoft's (Redmond, WA) TAPI (telephony API) and Novell's TSAPI (telephony-services API). Call-control standards define how a PC application sets up, monitors, and disconnects a call with the telephone network. TAPI treats the telephone as if it were another PC peripheral and enables Windows applications for such tasks as screen-based call control and the retrieval of a caller's data files at the desktop. TAPI version 2.1 adds support for applications in a client/server environment. TSAPI operates in the networking environment performing such tasks as controlling telephone switches (for example, PBXs). The newest call-control standard, JTAPI (Javatel API), specifies the call-control interface for computers running under Java.

The H.100 CT Bus delivers many benefits besides standard interconnection. The 4096 time slots on 32 bit-serial data lines provide the capacity to support complex telephony servers in the client/server architecture. Because businesses depend on their telephony servers, these servers must be reliable. To increase reliability, the CT Bus adds clock- and frame-signal redundancy for fault tolerance. Also, by providing backward compatibility with both MVIP-bus and SCbus boards, the transition to CT Bus should be nearly painless for CTI customers (Figure 2). The benefit users will notice the most is that new applications will reach the market more quickly, because there is less risk for application developers who develop products for only one interface that covers the entire market.

The time is right for CT Bus' implementation on the PCI platform. Until now, the CTI industry relied mostly on ISA and some extended-ISA (EISA) and Micro-Channel Architecture (MCA) buses to add resource boards to PCs. These buses were not a problem, because telephony-resource boards use little system-bus bandwidth. The bandwidth required to move a voice call to memory or disk over the I/O bus is only 3 kbytes/sec/call. The ISA bus could handle hundreds of these calls, making the increased PCI bandwidth unnecessary. However, with Intel (Santa Clara, CA) and Microsoft banishing ISA from new PCs, the CT Bus in the PCI form factor arrives at the perfect time to move CTI to mainstream PCs. This timing provides a good impetus for universal adoption of the CT Bus.

Also, ECTF and the PCI Industrial Computer Manufacturers Group (PICMG) are specifying the CT Bus for the CompactPCI bus. Because PCs have a bad reputation for high reliability and availability, the ECTF H.110 is specifying CT Bus in a telephony-industrylike form factor. The CompactPCI uses the VME-style Eurocard mechanical layer with rugged connectors and the PCI electrical, logical, and software layers. Several advantages of Eurocard make it better qualified for building reliable CTI systems. By using the VME-style backplane instead of over-the-top ribbon cables to connect resource boards, the H.110 CT Bus enables hot-swapping of boards. In addition, I/O connections are possible using the front panel or the backplane, which provides more options for telephony cabling. The Eurocard form factor also provides for rugged and fault-tolerant designs in cooling- and power-system units.

The H.100 and H.110 specify the same CT Bus--a TDM bus that connects the distributed-switching interface circuits on each resource card. The CT Bus relieves the host processor and system bus from isochronous telephony traffic and satisfies the low-delay and guaranteed-bandwidth requirements. The CT Bus achieves low delay and constant bandwidth by providing a series of repetitive 64-kbps time slots for moving digitized voice streams. Streams with greater bandwidth needs, such as ISDN and video, can bundle individual time slots into N×64 groups for 128 kbps, 256 kbps, and so on. Each bit-serial link carries 128 time slots in a 125-µsec frame. A digitized voice stream uses the same bytewide time slot in each of the 8000 frames/sec for a 64-kbps constant bit rate.

High-capacity switching fabric

A distributed-switching IC can switch streams to different time slots on the CT Bus or to the local card bus. Programmable switching transfers a stream from one TDM slot to another. The switching usually occurs within the same frame cycle to provide minimal latency transfers. For example, the switch wants to move a stream from slot seven to slot 27 in a different bit-serial link. Minimal-delay switching usually transfers the stream within the same frame, but if the transfer finishes too late, the switch occurs in the next frame. This minimal-delay switching can be a problem in N×64 bundles, because sequenced data could switch out of order. Hence, a switching option of the CT Bus provides constant-delay switching. The constant-delay mode always delays the time-slot switch to the next frame, so sequenced data never becomes unordered.

H.100 switches connect the CT Bus not only to a local bus for transfer to the resource board, but also to an external bus when needed. Therefore, the switch can establish local connections between resources on the same board, such as DSP engines; CT Bus connections between devices on different boards; or connections between re-source boards and an external TDM bus. To expand system capacity, an external bus can connect through an H.100 master resource board to establish connections between resource devices in separate systems.

A fully compliant H.100 switch chip is a complex switch that appears rather simple (Figure 3). The T8100 H.100 switch will be available from Lucent Microelectronics in the first quarter of 1998 for less than $30 (10,000). The CT Bus interface chip performs all switching and transfers for the telephony and the local bus. The telephony-bus interface is backward-compatible with both the MVIP bus and the SCbus. The timing and control block handles all the clock functions for compatibility and redundancy. Furthermore, the chip includes a frame group and µP interface. The T8100 is the standard-product version of the H.100/MVIP IC from Natural Microsystems.

Telephony reliability

The CT Bus switch chips include redundant clocks for reliability and fault tolerance. The CT Bus specification also requires synchronizing the redundant clocks to prevent loss of data should a failure occur. The CT Bus includes two groups of redundant clocks: the telephone-network reference clocks and an A and B set of core clocks for frame and bit transfers. These clocks use primary and secondary as well as master and slave configurations.

The clocks in all telephony TDM buses synchronize with a digital-trunk reference from the PSTN, such as a T1 connection. The CT Bus clock master card derives the A master clock from the primary trunk reference. All clock slave cards derive their timing from the A master clock. Therefore, the clock slave cards provide a fallback mode for loss of PSTN and a mode involving hardware failure or replacement of the master-clock card.

The backup network-timing reference signal, CT_NETREF, is critical to recovery from the loss of the primary PSTN reference. The NETREF signal can originate from any card that has a digital-trunk connection other than the trunk providing the primary reference. NETREF provides a backup reference to the primary-clock master PLL. If the primary digital trunk fails, the primary master clock's PLL can lock onto the NETREF signal and continue to derive the master clock from the PSTN reference (Figure 4).

The CT Bus master clock regulates data transfers between cards attached to the bus. In the event of an A master-clock failure, the standby clock master detects the failure, notifies the host, and becomes the master either automatically or by software intervention. The slave boards also detect the clock failure and switch to the backup clock automatically or through software intervention. In all cases, the backup-clock synchronization helps prevent data loss.

Easy migration

The transition from legacy TDM buses to the more reliable CT Bus was a primary goal for the H.100 standard. Backward compatibility with the SCbus and MVIP bus ensures an easy transition to next-generation products. The first 16 bit-serial links, CT_D[0:15], in the CT Bus can use a 2-, 4-, or 8-MHz clock, which enables interoperability with older bus clocks. The CT Bus interface chip provides clock generation for all the interoperability clocks. The second set of 16 physical-stream connections uses only the 8-MHz clock. These provisions for backward compatibility are for only the transition systems based on PCs that have both ISA and PCI slots.

In PCs with ISA and PCI slots, legacy cards and CT Bus cards can operate together with compatible mechanical connections that require cable adapters. The PCI cards connect to the CT Bus through an over-the-top, 68-pin ribbon cable. Even though there are more connections than there are on the SCbus or MVIP bus, the cable is thinner because it is on a 50-mil rather than a 100-mil pitch. The PCI-card connection is on the same end of the card as an SCbus connector is on an ISA card. A simple cable adapter connects the SCbus ribbon cable to the CT Bus ribbon cable (Figure 5). However, the MVIP-bus connector is on the other end of the card, so a transition pc board is necessary to connect the CT Bus cable and the MVIP-bus cable. You would need a similar transition device to connect the CT Bus between long and short PCI cards.

For the CT Bus to support backward compatibility, it must supply the clocks for data exchange with the MVIP bus and SCbus. The H.100 clock master sources clocks for SCbus, MVIP bus, and CT Bus boards connected to the same bus (Figure 6). The clocks support data-exchange rates at the backward-compatible rates. For example, the backward-compatibility specification allows an H.100 master to independently transfer data on CT Bus data-stream groups [0:3], [4:7], [8:11], and [12:15] independently at 2, 4, or 8 Mbps. The H.100 slave cards can either directly exchange data with the legacy TDM-bus cards or complete all transfers with legacy cards by switching through the master card.

Application backward compatibility between the CT Bus and the legacy buses eases the transition to CT Bus and makes it affordable for existing implementations. The MVIP device-driver software interface directly supports the H.100, because the H.100 simply defines an alternative intrachassis bus for the MVIP-bus software to operate. All current MVIP-bus products are fully compatible with the CT Bus, and developers need not change their applications.

SCbus backward compatibility is similar to that of the MVIP bus. Applications based on the Dialogic SCbus API need no code changes. As with the MVIP products, firmware and drivers need enhancements for operating with the CTBus data transfers. Extensions of the current API for both legacy buses allow applications to take advantage of the new features in the CT Bus, such as clock fallback and redundancy. Software changes would be necessary if a system developer wants to operate both MVIP-bus and SCbus cards in the same CT Bus domain.

The CT Bus specification arrives at the right time for CTI hardware developers to design resource boards. The move by industry leaders to eliminate the ISA bus from new PCs makes the CT Bus in the PCI form factor a logical choice. With the ECTF architecture, new applications for computer telephony in PCs should be less risky to develop. For large-office applications, the H.110 specification for the CT Bus in an industrial-computer form factor provides a standard direction for reliable and rugged CTI products. By providing hardware and software compatibility with the SCbus and MVIP bus, the CT Bus smoothes the transition for customers. The solid architectural foundation that the ECTF provides, along with the CT Bus providing the physical layer, should lead to mainstream products that deliver on the promise of computer-enhanced telephony.

References

1. Enterprise Computer Telephony Forum, "H.100 Revision 1.0 Hardware Compatibility Specification: CT Bus," www.ectf.org.

2. Quinnell, Richard A, "PCs and telephones start to merge," EDN, Aug 3, 1995

3. Enterprise Computer Telephony Forum, "Architecture Framework Revision 1.0," www.ectf.org.

Acknowledgments

Thanks to Mauricio Peres of Mitel Semiconductor, Brough Turner of Natural Microsystems, and John Landau of Dialogic for their comments and insight.

You can reach Technical Editor Stephen Kempainen at 1-415-643-1760, fax 1-415-643-9513, ednkempainen@worldnet.att.net.

| EDN Access | Feedback | Table of Contents |