Evolution of the Digital PBX, 1975–2000

There are two distinct generations of PBX systems based on the fundamental transmission and switching platform used to support signaling, control, and communications to and from the station user desktop and the common equipment. The first generation was known collectively as analog PBXs and included systems with a variety of internal switching network designs, such as step-by-step and crossbar, for port-to-port connections. The second generation, known as digital PBXs, converted analog voice signals into digital bit format using a codec in the desktop telephone terminal or at the port interface circuit card. Time division multiplexed (TDM) transmission buses were used as the core switching network for internal connections between peripheral port interfaces. Second-generation PBX systems used circuit-switched connections based on Pulse Code Modulation (PCM) techniques to establish communications channels between stations and/or trunk ports. The emerging generation of PBXs is based on IP signaling and communications protocols and interface standards commonly used for LAN and Wide Area Network (WAN) data communications but adapted for voice communications applications.

The digital circuit-switched PBX systems being marketed and installed today evolved directly from the first PBXs to use a digital transmission format across the internal switching network introduced in the mid-1970s by several manufacturers within a very short period. Before 1975, the earlier generation of premises communications systems was based entirely on an analog transmission and switching platform for communications between station users and/or trunk circuits. Using a digital transmission format was the first step toward the evolution of the PBX system from a voice-only communications system to the mixed-media communications system currently being marketed and sold. Other significant PBX system design changes that have occurred during the past quarter century include computer-stored program control, evolution of a modular, distributed system design for processing, switching, and port interface operations, and digital transmission between the station user desktop and the common equipment. The same basic design elements of a PBX system remain the same—call processing, switching, port interfacing, and transmission—but the technology and architecture of the system have certainly changed (Figure 1).


Figure 1: PBX evolution timeline: major design developments.

PBX system features and functions have also evolved since the first digital, SPC systems were introduced. The early digital PBX systems had fewer than 100 total features in support of station user, attendant, and system call processing requirements. Slowly, with each new software feature release, PBX system software options expanded to include support for multiple system networks, ACD-based call center applications, and integrated voice/data communications. Enhanced system options, such as video communications, computer telephony, mobile communications, and messaging, were continually added to total PBX system offering. Some of the features and functions were based solely on software programming, but many required hardware elements, such as adjunct servers or special signaling interface cards, to implement and operate. Most current communications users are not aware of the significant evolution in system performance capabilities because few station users take advantage of the wide range of features and functions available on their PBX systems.

Herewith is a review and discussion of the major digital PBX system design, feature, and functional changes and enhancements leading to the development of the next generation of IP telephony enterprise communications systems.

The Fundamental Enterprise Communications Systems

Current voice communications systems comprise five fundamental product categories:

Key Telephone System (KTS)

Private Branch Exchange (PBX)

Automatic Call Distributor (ACD)

Voice Messaging System (VMS)

Interactive Voice Response (IVR)

The first three categories support call processing and switching functions to enable telephone calls between two or more station users. The latter two product categories are designed to work in conjunction with one of the three core communications switching systems to provide optional services beyond a basic station-to-station call. It’s possible to integrate voice messaging or IVR capabilities into a KTS, PBX, or ACD product design, but most companies don’t. Instead, customers have traditionally chosen to install external, stand-alone systems for messaging and voice response applications. (Many small KTS products have an integrated voice messaging function, but the messaging features are typically not as robust as stand-alone offerings.)

KTS
A KTS is a customer-premises communications system designed to support basic voice applications and relatively small station user requirements. KTS got its name from its historical use with proprietary telephones, known as key telephones, which interface with a central control cabinet known as a Key Service Unit (KSU). The KSU is equipped with the system’s call processing control, port interface cards, and a variety of system/service circuit cards, such as Dual Tone Multi Frequency (DTMF) receivers and Input/Output (I/O) interfaces. The KSU performs central office line connection, intercom functions, paging, and station connections. Its common control elements include a call processor and system memory databases, and its most important function is the provisioning of dial tone. Other basic call processing functions are call answering, dialing, and transaction features such as hold, transfer, call forward, and conference.

Oddly, not all KTS products require a KSU. Instead, the intelligence needed to perform call processing and switching can be built into the circuitry of each key telephone instrument. Such systems are easy to install and maintain, but usually have limited feature and function capabilities, and are acceptable only for customers with modest port-size requirements. The KSU-less system is usually installed to work behind Centrex services offered by local telephone operating companies, which provide the more advanced features and functions through their central office communications switching system.

Common to KTS telephone instruments are designated, programmable key buttons for making and receiving off-premises calls over telephone company line circuits (trunks). The term KTS takes its name from the telephone instrument keys (analogous to typewriter keys) integrated into the product design. The line keys for each telephone instrument have direct access to off-premises telephones. Because trunks are distributed over and shared across groups of select telephones, each station user’s desktop instrument must be provisioned with multiple-line access keys. This is the distinguishing characteristic of a KTS: station user selection and access to designated telephone company lines. A pure KTS product supports only multi-line key telephone instruments and is incapable of supporting industry standard 2500-type single-line analog telephones unless a designated line circuit is dedicated to a single analog telephone instrument. Needless to say, it’s unusual for a customer to configure a KTS in this manner. Small system customers who want station users with 2500-type telephones to have shared access to a pool of trunks do have an alternative: a KTS/Hybrid product (see below), designed to support a mix of proprietary multiple-line button phones and nonproprietary single-line analog phones.

PBX
PBXs aren’t just big KTSs with more features and functions. The two share architecture elements, but PBX systems are designed for more robust functionality, greater growth capacities for ports, traffic, and call processing, and more levels of redundancy. PBX basic architecture includes the common control carrier/cabinet, port carriers/cabinets, and port circuit cards. Peripheral equipment support includes proprietary telephones, both single and multiple line, and industry standard single-line analog telephones.

First, let’s look at the major design and operational difference between a KTS and PBX. PBX stations can place calls over telephone company trunks only with the shared pool access method. The sole exceptions are telephones equipped with an optional private line for inbound and outbound calls. [Note: for reasons too complex to explain, the term line, when used in relation to a PBX system, usually refers to all customer premises equipment peripheral endpoints and is not a reference to a trunk circuit, as it would be with a KTS. The terms station and line are both used for PBX endpoints (telephones, modems, fax terminals) that are not off-premises trunk circuits.]

Hybrid System
Hybrid communications systems also share operating functions common to standard KTS and PBX systems. Original Hybrid systems were designed to more closely resemble KTS rather than PBX systems, although differences between the product categories are diminishing. Like KTS, Hybrid systems are based on a control cabinet similar to a KSU and can support a variety of port circuit boards for interfacing to station and trunk circuit equipment. All Hybrids support multiple-line proprietary key telephones and industry-standard single-line analog telephones. In a Hybrid system, phone access to line circuits is identical to that of a pure KTS, but single-line analog phones access a defined pool (group) of telephone company line circuits. This latter design capability is what distinguishes a pure KTS from a Hybrid system. The Hybrid’s port-oriented architecture design permits custom configurations to suit specific business applications. The architecture and technology design foundations of current Hybrid systems are more similar to PBXs than to KTSs. In fact, features and functions are sometimes difficult to distinguish from more expensive PBX systems.

Unfortunately confusion reigns when it comes to product category typing a communications system as KTS, Hybrid, or PBX. Some manufacturers call their Hybrid offering a KTS/Hybrid and others may refer to it as a Hybrid/PBX. The naming issue gets interesting in the United States because the Federal Communications Commission classifies customer premises communications systems as either KTS or Hybrid based on how single-line telephones access the central office. If the phone can access only one line as programmed by the system administrator, the system is a KTS; if it can access a pooled group of lines, the system is considered a Hybrid. Some manufacturers may even register a single system as both because the call processing software allows configuration flexibility for either pooled- or single-line access from a single-line telephone. Note that designating the product as a KTS, Hybrid, or PBX system may have financial consequences based on telephone company jurisdiction because trunk tariffs for linking a customer premises communications system to the central office can differ between KTS and PBX. (This was more common 15 years ago than it is today.) Ultimately it is the local telephone company that defines the type of system the customer is seeking to connect to the central office.

ACD Systems
The central component of a customer call center is an ACD. ACD systems were originally developed to handle large volumes of incoming calls and automatically route them to designated answering positions. ACD systems are designed and customer programmed to satisfy higher quality of service standards than PBX systems for the following call processing functions:

Screening

Routing

Queuing

Answering

Most PBX systems can be programmed to function as ACD systems, but few ACDs can be programmed to function as PBXs and continue to support most of the latter product’s standard or optional features and functions. Nevertheless, an ACD system shares many of the architecture and feature capabilities of a PBX system. You can think of it as a PBX designed for a very specific application—to distribute incoming calls equitably to a group or groups of answering stations. We usually call ACD answering stations agents, and this is the fundamental difference between PBX and ACD system service: calls handled by a PBX are routed to a specific station user, whereas ACD calls are routed to a group of stations, although call analysis programs can be used to route the call to a specific agent in a group.

ACDs exhibit several architecture design and feature standards that are often not adhered to for PBXs. A true ACD system is based on a nonblocking switch network design, has sufficient call processing power to handle a large volume of complex call types, and has software program- ming features that can screen, route, and distribute calls to agent positions fast and efficiently. Other distinguishing standard ACD system attributes are the ability to support specialized stations, known as supervisor positions, and an integrated MIS reporting system used to monitor, track, and analyze call center operations. All of these features are standard in stand-alone ACD systems, but PBX systems may fail to meet the same standards. Indeed most PBXs must be traffic engineered to support non-blocking switch network access and post-equipped with optional software and external applications servers to all but the most basic ACD feature and MIS capabilities.

Early ACD systems were stand-alone products designed exclusively for a call center environment with large call volumes, such as an airline reservation center. During the early 1980s several PBX systems were designed with optional software that could support basic ACD functions but could not match their performance level. By the 1990s a growing number of PBX systems enhanced with optional ACD software and external MIS reporting systems started to look functionally competitive with stand-alone ACDs. Similar PBX systems with optional ACD packages now control more than 80 percent of the market for call center communications systems. Although stand-alone ACDs hold their own at the high end of the market for large, complex feature and function requirements, PBX and ACD systems totally dominate the call center market segment for systems with fewer than 100 agents. Many KTS/Hybrid systems can also be configured with optional ACD capabilities and are gradually penetrating the very small call center market segment for systems with fewer than 20 agents. Why has the average size of an ACD call center system continually declined over the past 20 years? Customers are realizing that programmable call routing, distribution, and reporting features are beneficial for a variety of nontraditional ACD applications, such as internal help desks and groups of attendant positions. Today’s average ACD installation has only about 60 agent positions, and that number is declining.

Voice Messaging System
Most enterprise environments use a VMS as the primary call coverage point for unanswered calls, but you’d be selling the VMS short to think of it only in terms of message record and store. A good VMS mailbox can:

Be programmed for different greetings

Offer incoming callers a menu of options for leaving a message or transferring to another station

Act as an automated attendant position to answer and route calls

Serve as an automated information system or an outbound call messaging system

VMSs can be interfaced to almost all current generation KTS/Hybrid, PBX, and ACD systems by using a signaling link between the VMS, the switching system, and its voice communications channels. The signaling link is usually referred to as the voice mail system interface or, in standards parlance, the Station Message Detail Interface (SMDI). Among other functions, the link activates the message-waiting indication at a user station. Its voice communications channels will be based on 2500-type analog station interfaces, a standard interface supported by all systems.

Here’s what happens when a caller leaves a message. VMS coders/decoders (codecs) take the transmitted voice communications signals from the switching system, digitize them, and compress them for storage purposes. The same codecs will convert the digitally compressed messages back to analog format for station user playback. The voice quality of VMS playback largely depends on compression algorithms that may degrade the original message to optimize storage capabilities by using a low sampling rate or bit scheme. Filters and automatic gain control improve sound quality, but if stored messages are forwarded to another station or broadcast to hundreds of stations, further digital compression occurs as messages pass through interim mailboxes. Moreover, when VMS is used behind IP telephony, playback quality weakens if stored message transmission is packetized using IP codecs. This is a technical issue being addressed by designers and developers of the new IP-PBX systems.

Because the market trend is toward Local Area Network (LAN)–connected application servers, the traditional method for setting up signaling between the switch and the external VMS is slowly changing. The new, improved method is to insert an Ethernet TCP/IP link between the switching system and the LAN-connected VMS. At the same time, the newer VMS server design is also driving the market for Unified Messaging systems (UMSs). Many people think that first-generation UMS failed to take hold because they were based largely on traditional VM systems design and user operation. In contrast, second-generation systems are based largely on e-mail server design and user operation and are gaining greater market acceptance. Several new client/server PBX system designs include the VMS or UMS function as an integrated feature capability.

Interactive Voice Response System
An IVR system is a communications system product that typically functions as an intermediary between a PBX system and external computer databases. An IVR can also function as a stand-alone enterprise communications system, without a PBX system, because it can support standard PSTN trunk interfaces. Analog and digital trunk interfaces are supported by most IVR systems to connect to the customer premises PBX system or directly to the PSTN. IVR systems are used for several customer applications, including automated voice response and feedback, automated directory, call routing.

The primary system link for an IVR system is not the switching system, but an external computer system. The IVR mediates between voice callers and computer databases with customer-written scripts and menus prompting callers to respond to prompts with dialpad entries on their phones. The IVR system interprets the DTMF signals from the dialpad and is programmed to respond with another voice prompt, a recorded announcement, or a “spoken” answer to the caller’s inquiry. IVR speech is based on a text-to-speech programming algorithm, for which appropriate “answers” can be stored in the IVR database (which usually has limited memory storage capacity) or (more commonly) an external computer database.

Some IVR systems with ASR capabilities don’t require DTMF input to respond to caller voice commands and questions. Voice-based interaction with the IVR can significantly speed up the IVR transaction process by bypassing many call prompt levels of the programming tree. There are also many instances when callers find it easier and faster to speak digits or words instead of using the dialpad to enter digits in response to a call prompt command. ASR systems have been famously slow to penetrate the market because of reliability and cost barriers, but recent advances in programming and the declining cost of digital signal processors have made ASR more prevalent. We anticipate that the next major technology advance for automated response systems is speaker verification, an important capability to simplify the system interaction process and raise security levels.

Convergence of KTS/Hybrid and PBX Systems
KTS and PBX architectures began their gradual convergence of design and function with the introduction of the first KTS/Hybrid systems. The early 1980s saw major differences in call processing, switching, and port cabinet-design pure KTSs and PBXs. KTSs used analog switching and transmission standards and were based on a common control system design, with limited traffic, processing, and port capacities. Features were necessarily limited, and options such as multiple system networking and ACD were unheard of. Migration between KTS models—even on the same manufacturer’s product platform—usually required KSU fork-lifts. However, most PBX systems of the day employed digital switching and transmission standards, with digital desktop telephone and trunk interface support. PBXs were designed to handle greater traffic, processing, and port expansion requirements and offered numerous advanced features not available on any KTS.

Hybrid systems began to blur these category differences as PBX design technology and feature capabilities were applied to a KTS-like platform, nudging Hybrid switching network design away from the traditional dedicated line access and intercom path. The result more closely resembled the digital Time Division Multiplexing (TDM) bus design used by PBX systems. Hybrid systems could support customer port capacities far in excess of KTSs, some basic networking options, and call center applications.

By the mid-1990s many customers couldn’t tell the difference between a Hybrid system and a full-function PBX system because the design platform and feature sets were so similar as to be indistinguishable for all but the most unique customer requirements. High-end Hybrid systems could support customer port requirements up to several user stations. They accommodated networking options such as digital T1-carrier trunk interfaces and ISDN PRI services, ACD options including MIS reporting packages similar to the early PBX/ACD systems, and some integrated voice messaging and wireless communications options. Hybrid system digital telephones were more advanced, often offering customers a greater selection of multiple-line key and display models. It was not unusual for Hybrid telephones to offer the large display fields and soft-key feature buttons that are only now becoming a PBX standard.

Today’s Hybrids are often larger in capacity than many entry-level PBX systems and can support most, if not all, of the same features and functions for the majority of customer requirements. They can be intelligently networked, and they can satisfy complex call center requirements. Some manufacturers offer the same telephone models for both their Hybrid and PBX models, allowing customers a migration path between the two platforms, and most manufacturers have announced that their recently shipped IP telephones will work behind either systems.

As Hybrid systems expanded, PBX systems grew smaller. Until recently PBX systems were not priced to be competitive against Hybrid systems at the same station sizes. (The target market for competitively priced PBX systems usually began at 40 stations.) This PBX price problem was created by the higher cost of its more robust common control cabinet or carrier. During the past few years the PBX manufacturers have responded by redesigning their common control systems and downsizing the control cabinet/carrier hardware equipment. Although today’s PBX systems remain higher priced than a KTS/Hybrid configured for the same number of stations and trunks, the price differential has been continually shrinking. There is currently a 10 to 15 percent price difference between the two system platforms compared with 25 to 50 percent a decade ago. Today there are entry PBX models designed around a single printed circuit board for call processing, memory, and switch network functions. These new models are price competitive but port limited, usually designed for customers with 20 to 40 station size requirements at initial installation, but equipped with the call processing capability to support all of the features and functions of PBX models many times their port capacity.

PBX systems based on client/server designs are targeted primarily at the small/medium enterprise (SME) market, defined as ranging from about 20 stations to about 120 station, and overlaps with the Hybrid system market. A typical Hybrid system installation is about 25 stations. Shipments of PBX systems based on client/server designs are currently averaging about the same station size as Hybrid systems, and few have been installed at customer locations with port requirements above 100 stations. As you might expect, most of the systems being replaced by the client/server PBX systems are Hybrid systems, against which the newer PBXs can offer more bundled applications and support (either current or planned) for IP endpoints. The current generation of installed-base Hybrid systems may someday support IP endpoints but only after costly system upgrades. For the vast majority of users, it will be less expensive to install a new system than to upgrade the old. The first generation of IP telephony systems designed for the very small KTS/Hybrid customer is just beginning to make its way into the market.

Under the circumstances, we can predict that the traditional Hybrid system eventually will be replaced by the new communications system, client/server design, competitive product offerings, or upgrades to the system manufacturer’s new design platform. But this picture is also affected by customer size. Almost all market demand forecasts predict that the new PBX designs will be far more successful in smaller rather than larger line size markets, because the latter customer segment is less likely to replace a reliable and upgradeable installed system for a system that has not yet proved as reliable. The cost factors for large system replacement go far beyond the system purchase and installation price. Too much is at stake for large line size customers to risk the lesser reliability level of an OEM server running an operating system, such as Windows NT, not originally developed for real-time industrial applications. Only a few of the new client/server systems are built on more reliable and flexible operating systems, such VX Works, and custom-designed common control elements. Branch offices may sacrifice reliability for a less expensive system, but a large line size corporate or regional headquarters customer would not.