Networking | Features/Function Enhancements

PBX networking has evolved dramatically during the past 25 years. The earliest PBX networking arrangements consisted of two switch nodes linked by a dedicated, private line facility (E&M tie trunk) to save on long distance toll charges. The primary benefit was cost savings. When customers began to use multiple long distance carriers in the late 1970s it became necessary for PBX systems to analyze each placed long distance call to determine which carrier service should handle the call.

The preferred carrier service was usually the lowest priced for the call. A new PBX feature was developed and known by several names, including least cost routing (LCR), ARS, and most economical route selection (MERS). Implementing the feature required the system administrator to enter the call destination route and routing pattern data into a database that would price each call based on tariff pricing data. The tariff data was obtained through a service bureau and needed to be updated regularly.

The benefit to the customer was to reduce long distance toll expenses. Expensive calling routes were restricted to callers only with permitted network classes of service levels; callers with the lowest service level rating could place calls only when the lowest cost route was available.

Also in the late 1970s, AT&T announced its Electronic Tandem Network (ETN) offering, and PBX networks acquired a greater degree of complexity and functionality. ETN was a private tandem network consisting of a meshed network of private line facilities linking tandem switch PBX nodes, main PBX nodes, and satellite systems. In-band signaling techniques supported a network dialing plan and automatic alternate routing between nodes within the network. In addition to cost-savings benefits using fixed tariff private line carrier facilities, customers enjoyed greater control over network operation and use. All of this was initially done with the use of narrowband analog trunking facilities.

The next step up the evolutionary PBX networking ladder was establishing an intelligent network signaling to support transparent feature/function operations between discrete locations served by independent PBX systems. AT&T’s Distributed Communications System (DCS) offering was introduced in 1982 for its Dimension PBX. The first intelligent signaling link required an expensive private data circuit; analog private lines were used to carry voice traffic. The DCS intelligent networking solution allowed customers to use simplified dialing plans (i.e., four- or five-digits) for calls across PBX systems; supported transport of caller name/number display information between telephone desktops working behind different switching nodes; and provided a basic level of transparency within the network for many of the most commonly used station features, such as call transfer, call forwarding, and multiparty conferencing. Shared applications were also supported across a network of PBX systems, such as centralized voice messaging.

The arrival of digital T1-carrier trunk services in the mid-1980s changed the rules for PBX networking because in-band signaling was replaced by out-of-band signaling, and new networking solutions became possible. The same digital trunk circuit used for voice traffic could also be used to support the intelligent signaling link between PBXs. Digital voice carrier services using T1-carrier circuits made out-of-band signaling a more economic and feasible solution for implementing an intelligent network of PBXs. Use of an out-of-band signaling channel allowed PBX systems to communicate with one another at a much higher level than before. The resulting intelligent network configuration could offer customers traditional network transmission costs savings and provide significant productivity gains and additional cost savings through the use of shared application features/functions.

Each PBX manufacturer’s intelligent networking solution was proprietary and caused problems for customers with a mix of PBX systems in their networks. An initiative was begun in the late 1980s in Europe by the leading PBX suppliers to create a standardized network signaling protocol to intelligently link dissimilar PBXs. The signaling standard is commonly known as Qsig, and was originally developed under the auspices of the ISDN Private Network Systems (IPNS) Forum. PBX systems that support Qsig can interwork intelligently with each other; support basic call set-up and tear-down across the network between dissimilar PBX system platforms; conform to a common dialing plan for limited digit dialing across PBXs; transmit and accept telephone display information, such as calling name and number, and call redirection data between desktops; and sup- port feature-transparent operations for a defined set of features, such as call forwarding, call transfer, conferencing, and network attendant service. Although most leading PBX suppliers support Qsig as part of their networking solutions, the degree of transparency between systems remains limited. Manufacturers must do continual testing of their systems to correct Qsig message and signaling problems.

PBX networking advancements in the late 1980s included support of ISDN PRI services. ISDN PRI service circuits became the preferred trunking solution for implementing an intelligent feature-transparent network because the D channel was a natural communications channel for handling signaling and control data across distributed PBXs. New PBX networking features based on ISDN PRI services included support of incoming ANI, and call-by-call service selection (CBCSS). CBCSS allows a PBX system administrator to define the communications service supported by individual ISDN PRI bearer communications channels. A single T1-carrier trunk circuit, supported by ISDN PRI service, could be used for a variety of services between the PBX system and the network exchange carrier’s central office switching system. For example, several bearer channels could be designated incoming DID trunks, others could be designated two-way CO trunks, and others could be designated clear channel data circuits. Using programming tools, the administrator could reconfigure the mix of trunk services on demand or by a schedule, or could even program the channels to reconfigure themselves based on real-time traffic conditions.

Network carrier services in the 1990s designed to support data communications were also supported by PBX systems. Nortel Networks redesigned its Magellan Passport Asynchronous Transfer Mode (ATM) switching system as a Meridian 1 gateway module to support a mix of voice, data, and video communications over broadband trunk carrier circuits. Lucent Technologies, NEC, and Siemens also introduced ATM network interface options for their respective PBX systems. One of the most important PBX networking advancements in the late 1990s was the introduction of external IP telephony gateways, closely followed by integrated IP trunk gateway port circuit cards. Lucent Technologies was the first to market an integrated IP trunk option and was closely followed by other market leaders, including Nortel Networks and Alcatel.

Video Communications | Features/Function Enhancements

The older generation of PBX station users may remember their first introduction to the videophone at the 1964 New York World’s Fair. Several generations of PBXs have come and gone since 1964, but PBX-based desktop video communications is still a work in progress for most customers. The first major attempts at desktop video communications behind a PBX system occurred during the early 1990s when ISDN BRI options became available. Using both BRI bearer communications channels per video call (128-Kbps transmission rate) provided a fair quality of service, but a killer application for the video option never materialized, and desktop video behind the PBX is rarely implemented today. Desktop video communications today is based primarily on LAN or supported by dedicated trunk circuit facilities.

Lucent Technologies attempted to revive interest in PBX-based video communications in the mid-1990s when it introduced two Definity PBX options designed to support voice calling features on video calls. The MultiMedia Communications Exchange (MMCX) was a server-based system designed to support H.323 mixed-media calling (voice, data, and video). The MMCX provided some basic calling features, including dial plan, conferencing, and call forwarding, to LAN-connected workstations used for video communications applications. The MMCX could also support traffic between PBX ports and LAN peripherals, and a Q signaling (Qsig) link would provide a higher level of PBX system features to the LAN workstations. Another PBX option was called MultiMedia Call Handler (MMCH), which was designed to apply a limited number of voice calling features to ISDN BRI video workstations conforming to H.320 standards. Neither the MMCX nor MMCH offerings gained market acceptance, although the MMCX product was later modified by Lucent and reintroduced as its first Internet telephony gateway product. The IP gateway was further redesigned as an internal IP trunk interface card for the Definity PBX. The concept of the MMCX, a call processing server for LAN workstations, could be considered an early version of today’s emerging IP-PBX systems. Although no IP telephones existed when the MMCX was announced, LAN-based voice communications using a video workstation equipped with a microphone and speaker were supported.

Data Communications | Features/Function Enhancements

Digital PBXs were supposed to be the enterprise data communications network backbone, but some things were not meant to be. The first PBX data communications options were introduced in the early 1980s. In 1980 Intecom was the first to offer a high-speed data module capable of transmission rates of up to 57.6 Kbps. This was at the time when most modems were operating below 9.6 Kbps, and 10-Mbps Ethernet was not yet introduced. After the Intecom announcement, most of the older PBX suppliers announced data module options for their systems with maximum transmission rates ranging from 9.6 to 64 Kbps (Figure 1).


Figure 1: Call center configuration.

Data communications options were available for integrated voice/data or stand-alone data ports. The integrated voice/data port option required a data module that attached to a digital telephone and provided a RS-232C or RS-449 interface for an adjunct data terminal. Asynchronous and synchronous interfaces were usually available from each PBX suppler. Stand-alone data modules were also available and may have required a port circuit card dedicated to data-only communications. The early data modules were priced at about $300 to $500 and required the more expensive digital telephones to work. Most PBX systems at the time were not designed to handle long call holding times and required extensive traffic engineering to support significant customer data requirements. When digital trunks were first available in the mid1980s, the tariffs were very high, and the PBX digital trunk interface cards were expensive compared with analog trunk interfaces. The cost of LAN equipment, at first significantly more expensive than PBX data option pricing, declined rapidly during the 1980s, making it a far more attractive data networking solution than a PBX. PBX data modules, once considered a high-speed option, were viewed as slow when compared with LAN transmission rates. Dreams of the PBX becoming the data networking solution died by the late 1980s when LAN technology matured and network routers first entered the market. Shipment levels of PBX data stations (integrated and stand-alone) never exceeded 3 percent of total annual shipments.

PBXs attempted to make a comeback in the early 1990s by offering a wideband data communications option using an ISDN primary rate interface (PRI) circuit card. By bonding multiple B channels together, a PBX could support transmission rates up to 1.5 Mbps to the desktop and across its digital trunk network. The cost to support the option, however, was seen as excessive because a single wideband port required a dedicated ISDN PRI port circuit card that could cost several thousand dollars. Fujitsu was the first to offer wideband data communications on its F9600 PBX, but customer demand was weak. Other PBX suppliers soon followed the Fujitsu announcement with their own ISDN PRI–based data communications option, but total sales of the option to date have failed to reach 1 percent saturation.

Another PBX system attempt to make a dent in the data communications market came in the mid-1990s when Intecom introduced an Ethernet hub and workstation interface option fully integrated into its port cabinet design. Broadband fiber optic loops between the distributed port cabinets handled intrasystem data traffic and could support Ethernet 10BaseT transmission standards. The broadband data communications option was priced higher than existing LAN interface and switching equipment and failed to find a market.

More than 20 years after the first attempts to position the PBX system as a data communications networking solution, sales of PBX data modules are negligible. The only appreciable data traffic transmitted across a PBX system today is analog-based data communications generated by modems. PBXs are used primarily as a back-up system when LANs are down for service or repair. Ironically, the often unreliable nature of enterprise LANs has made the PBX an invaluable spare data network solution, forcing many voice communications managers to install a significant number of analog ports in support of data modems for use in emergencies. PBX data solutions may not be high speed, but they are reliable.

Basic Voice Call Station/System Features | Feature/Function Enhancements

Do station users really need six variations of call forwarding? Do managers still “buzz” their secretaries? Although PBXs have many call forwarding options and still retain the manual signaling (buzz) feature, the most significant station/system feature enhancements during the past two decades have been to improve incoming call coverage, support the needs of the new mobile workforce, and simplify the administration and maintenance operations of the system manager.

An important PBX feature developed in the days before voice messaging systems invaded the workplace was programmed call coverage. Programmed call coverage was a form of enhanced call forwarding, with some important distinctions. First introduced in 1983 by AT&T on the System 85 PBX, call coverage did not receive the market attention it deserved during the 1980s and 1990s, but renewed interest in personalized call screening and routing to improve communications service levels has revitalized the feature. Call coverage capabilities on current-generation PBX systems allow station users to define where incoming calls are directed when they are unable to answer the call and program the coverage path based on who is calling (CLID, Automatic Number Identification [ANI], internal calling number, call prompt), where the call originated (internal or external to the system), how it arrived into the system (trunk group ID), or when a call is placed (time of day, day of week). Building on the concept of call forwarding, personal call coverage programming redirects calls to a defined path of answering stations and will default to the called party’s voice mailbox only as a last resort. Calls will not be redirected to the forwarding position or voice mailbox of a station user defined in the call coverage path; the originally called party’s coverage path overrides intermediary station user call forwarding commands.

Call coverage tables and station user programming was not possible before the development of digital PBXs. The new CTI-based PBX system designs allows station users to program caller-specific call coverage paths based on identified callers. The personal call coverage function in these new-generation systems is supported at the station user desktop (a PC client softphone), not at the common control call processing system. The objective of personalized call coverage features is to reduce dependency on voice mail systems because a human answering station rather than a noninteractive machine might be preferred by the caller. Voice mailboxes should be the last option in a call coverage environment, not the first or only option.

The new mobile workforce includes station users who are rarely in the office and workers who do not have permanent desk assignments because they are constantly moving or their job function is not desk based. To support these mobile workers, it is necessary to dissociate a station user’s telephone directory number from a physical telephone instrument. Hoteling, a feature designed to support workers who work at different desks throughout the enterprise, allows station users to log into the system from a telephone and reassign their directory number to their chosen telephone. In addition to their telephone number, the individual’s station user profile (service levels, call restriction levels, group assignments) is also assigned to the physical telephone location. Account codes and call records are maintained for the station users for each telephone they use. When done using the telephone, after 1 hour, or 1 week, or 1 month, the station user logs out, freeing the telephone for the next mobile worker. Hoteling is becoming very popular in sales offices. The feature can significantly reduce system costs by optimizing common equipment hardware, telephone instrument, and cabling requirements and, more importantly, minimizing real estate requirements (fewer dedicated desks/telephones, less office space).

Today’s mobile workers who are rarely at a fixed telephone location also benefit from recent feature enhancements. The find-me feature allows station users to program their telephone to direct calls to other telephone numbers outside of the PBX system. More than one external number can be programmed. For example, on a no-answer call at the station user desktop, the call can be forwarded to another telephone number after a selected number of rings; if there is no answer at the external number, another telephone number is dialed, and the call is redirected. External telephone numbers likely to be programmed include cellular telephones, home, conference facility, remote office branch, or even a hotel. A relatively recent teleworker option available on some PBXs allows station users to bridge their line appearance to a telephone external to the system. The concept of the PBX as a mobility server can significantly improve call coverage, reduce lost or abandoned calls, and increase the number of successful call attempts between caller and called parties.

Another category of mobile workers consists of station users who require a telephone away from the formal office environment. Known as teleworkers, these station users require their high-performance telephones to function away from the workplace and receive incoming calls redirected to their remote desktop. The original teleworker option was an off-premises extension (OPX) station using highly tariffed telephone trunk circuits to link remote analog station equipment to the main PBX system. Expensive and low-performance analog OPX stations have evolved into affordable and high-performance digital desktops. The same digital telephone supported behind the PBX at the office can be supported remotely with several options, including distance extender modules and analog trunk carrier facilities, ISDN BRI services and equipment, and the recently available IP workstation (hard telephone or PC client softphone).

The most important system feature enhancements during the past decades have been systems administration and maintenance tools. The early PBX management terminals required high-level programming skills and weeks of training. A typical station move, add, or change operation could require at least 15 minutes of keyboard entries. After booting up the systems management terminal the administrator was met by a blank monitor screen waiting for a programming command. There were no menus, on-screen help command, or point, click, and drag. Computer technology evolved during the 1980s and so did PBX management tools. By 1990 a systems management terminal had a basic graphical user interface (GUI), usually a menu selection list and formatted screens. By 2000 PBX management tools were accessed through a web browser via the Internet, and a sophisticated GUI simplified the administration process. Few keyboard entries are now required, and access to a common metadirectory server simplifies the initial station user directory entry.

Modular System Design

Until the early 1980s all PBX systems were based on a centralized processing, centralized switching, and centralized cabinet equipment design. Intecom, the developer of the first digital PBX telephone, also broke system design tradition when its IBX system featured distributed port cabinets linked to the main processing/switching complex via fiber optic cabling. Each of the IBX’s distributed interface modules (IMs) could be located 10,000 feet from the main equipment room to support campus configuration requirements. Each Intecom IM cabinet had its own local processing unit operating under the control of the centrally located Master Control Unit (MCU).

The distributed cabinet design was dictated by distance limitations imposed by digital signal links to the digital desktop. Intecom was forced to bring the port cabinet closer to the station user. Analog telephones could support cabling loop lengths of 1 or 2 miles, but the Intecom ITE digital telephones were limited to 1,000 feet between wall jack and port circuit card.

The next logical step in a modular system design was to remote port cabinet miles away from the PBX common control complex using telephone company trunk carrier circuits. Northern Telecom was the first to accomplish this when it designed a remote peripheral cabinet for its SL-1 PBX in 1982. Using analog trunk circuits, the remote cabinet depended on the main PBX location for all call processing and switching functions, but at least a customer could support two or more distributed locations with a single PBX system. If the trunk circuit link to the remote location failed, however, the remote location was left without communications service. A spare processing option at the remote location would solve the link failure problem, so Intecom announced such an option about one year after Northern Telecom introduced the first remote cabinet option.

By the mid-1980s several PBXs offered remote cabinet options, but only Intecom has a remote survivable processor option. Other manufacturers offered an alternative solution to the remote cabinet option and in some ways a better PBX system design. A PBX system first announced in the early 1980s, and still working today after many upgrades and enhancements, was the Ericsson MD-110 PBX. Based on its own central office switching system, Ericsson’s MD-110 was a fully distributed communications system from a call processing, switching, and cabinet architecture perspective. Each MD-110 Line Interface Module (LIM) contained a common control complex that operated independently yet in coordination with every other LIM cabinet in the system. The LIMs could be geographically dispersed on a campus location or across a telephone network (analog or digital trunks, copper or fiber optic cabling, microwave or satellite transmission). Each LIM had its own switching system backplane and communicated with other LIMs via a centralized group switch complex. PCM links between the LIMs and group switch could be duplicated, as could the group switch (Figure 1).


Figure 1: MD110 IP evolution.
In the mid-1980s Rolm introduced a PBX design similar to the Ericsson offering. The Rolm CBX II 9000 did not have a centralized group switch but it did have functionally independent control cabinet clusters. The Northern Telecom SL-100, a modified version of the manufacturer’s DMS-100 central office switching system, became a popular PBX system for very large (thousands to tens of thousands of user stations) distributed communications configurations requiring an extremely high level of reliability and redundancy. The SL-100 Remote Switch Center (RSC) option could be located hundreds of miles from the main PBX location, support thousands of stations users, and function as a standalone system, if necessary, with minimal loss of features if the control link to the main common control complex failed. The growing availability of PBXs capable of supporting multiple common control complexes and port cabinets geographically dispersed across great distances marked a distinct change from the old, monolithic design platform of PBXs before 1980.

For customers with single-location requirements and not interested in remote port cabinet options, the most important PBX cabinet innovation of the early 1980s was the introduction of the stackable cabinet design. PBX control and port cabinets were traditionally based on large, multiple carrier steel frames. Customers would be forced to buy and install an expensive large cabinet capable of supporting several equipment shelves, even if they required expansion for a few stations. The incremental cost to add a few stations was very expensive. When the NEC NEAX2400 was introduced in 1983, it was the first PBX based on a stackable cabinet design, with dedicated single-shelf cabinets for call processing functions and stackable port cabinet shelves. Up to four Port Interface Module (PIM) single-shelf cabinets could be stacked on top of each other, sharing a common switching and processing backplane. Each PIM had a dedicated Port Processor Interface and a dedicated Time Slot Interexchange (TSI). The NEAX2400 offered customers a cost-effective solution for modest growth requirements as compared with PBX systems based solely on large expansion port cabinets costing tens of thousands of dollars even if only a few expansion ports were required.

By the early 1990s almost all PBX systems targeted to customers with small and/or intermediate port requirements were based on modular, stackable port cabinet designs. Many PBX manufacturers offered a remote port cabinet option to customers desiring a single communication system for multiple-location configuration requirements. Distributed processing and switching designs were becoming commonplace. The emergence of CTI in the 1990s allowed manufacturers to offload advanced software options, particularly for call center management, onto adjunct servers dedicated for a specific application. Optional software application programs run on proprietary or customer-provided server equipment reduced the call processing load on the main control complex and offered a more flexible migration and upgrade path to enhance older PBX system platforms that still performed the basic communications functions with little problem. The early CTI hardware solutions required proprietary hardware links between PBX and server, but evolving PBX architecture design led to standardized TCP/IP links over Ethernet LANs.

The development of call processor control signaling over LAN infrastructures simplified the installation of third-party hardware and software solutions behind the core PBX system and kickstarted development activity for IP telephony and the emerging client/server IP-PBX system design. Using the LAN infrastructure (Ethernet switches, multiservice routers) for voice transport and switching between LAN-connected PC client softphones and LAN-connected servers for call processing is the ultimate modular system design because the processing and switching functions are totally distributed across the entire network.

Digital Desktop

In the late 1970s and early 1980s most PBX manufacturers developed an electronic telephone for use behind their systems. The electronic telephone’s primary benefit was support of multiple-line appearances. Instead of using KTS equipment behind a PBX to support station user requirements for multiple line appearances, an alternative option was available. The majority of station users at the time used single-line appearance analog telephones, with no feature/function buttons, no speakerphones, and no displays. Only a few lucky station users qualified for multiple-line appearance telephone instruments. Today, of course, the typical PBX telephone instrument looks slightly less complicated than the cockpit of a Boeing 777, with more buttons, bells, and whistles than one knows what to do with.

Like the basic 2500-type analog telephone, voice transmission from the electronic telephone to the port circuit card over the inside wiring was analog, but the built-in intelligence of the telephone instrument provided an array of programmable feature/line buttons and a limited function display. A signaling link between the telephone and the PBX provided the intelligence to identify which line appearance button was being used to place the call or which feature button was depressed for activation. Control signaling between the electronic telephone and the port circuit card was embedded within the instrument’s 4-KHz voice transmission channel. The low-frequency signaling stream constrained feature/function development, but was a first step in the evolution of intelligent digital desktops behind the PBX.

The evolutionary step made by electronic telephones was a break from the traditional DTMF signaling techniques for communicating with the PBX common control equipment, as was done with traditional analog telephones. Each PBX manufacturer used a proprietary signaling scheme and dedicated station line circuit cards to support electronic telephones. An industry standard for electronic telephones was not developed for a variety of reasons, although it may have led to more sophisticated desktop terminals. Maintaining a proprietary signaling link meant that electronic telephones could be sold at a high price, with a significant profit margin, if customers required multiple-line appearances. Third-party telephones could not be manufactured unless the signaling scheme specifications were published (which they weren’t).

When Intecom introduced the first digital PBX telephone, the product marketing materials emphasized its potential for integrated voice/data communications with an optional data module. Two communications channels were available to the desktop station user, one for voice and the other for data. Little mention was made of the dedicated signaling channel used to link the telephone with the PBX common control equipment. The digital signaling channel was the major breakthrough that would be the distinguishing factor between analog transmission telephones (industry standard, 2500-type, electronic) and digital transmission telephones. The out-of-band signaling channel, operating at transmission rates between 16 and 64 Kbps (based on the individual manufacturer’s design specifications), could be used for a variety of new, advanced desktop capabilities.

The primary function of the signaling channel was to alert the PBX common control equipment when the telephone handset was taken off the hook to prepare a voice call. The signaling channel was designed to transmit keypad dialing signals and feature/function activation and implementation signals. Display information, such as calling name and number, was carried over the signaling channel, including call redirection information for forwarded calls. Station users could self-program their telephone instruments with software programs residing in the main PBX control complex but accessible via the signaling channel.

The second communications channel originally developed for desktop data communications applications was rarely used because LANs became the dominant enterprise data communications network. Eventually telephone designers were able to program the PBX to support a second voice channel to the individual station user desktop in support of an adjunct voice terminal. The intelligent signaling channel can distinguish between voice calls placed to different directory numbers and support simultaneous calls to and from discrete desktop devices. Using a special analog line adapter module, a digital telephone can be used to support an adjunct analog telephone, modem, facsimile terminal, or audioconferencing station. The adapter module converts signals from the adjunct analog communications device signals into the proprietary PBX digital format. Other uses of the second communications channel include support of a second digital telephone (using a digital line adapter module) off a single PBX communications port interface and bonding of the two channels for high-speed transmission in support of data or video applications using an ISDN Basic Rate Interface (BRI) type of adapter module.

The most impressive use of the signaling channel is the support of sophisticated display information fields and associated context-sensitive softkey feature/function access. The current generation of digital telephones have large multiple-line display fields that are used to view directories and call logs, access on-line help programs, read text messages, and perform station and/or system management operations.

One of the criticisms of traditional PBXs has been the use of a proprietary control signaling to support digital desktop equipment. The recent development of LAN telephony systems using IP signaling standards someday will eliminate the proprietary signaling link between the call processing system and the telephone, but standards are still in development. Cisco’s IP telephone currently does not work on a 3Com IP telephony system, and Avaya’s and Nortel’s IP telephones interwork do not work on each manufacturer’s respective IP-PBX offering. When a high-performance industry standard IP telephone is available to work behind a multitude of IP-PBX systems, it will be possible only because of a standardized signaling link between the call processing server and the desktop, a design specification first developed 20 years ago in the first-generation digital PBXs.

Messaging | Features/Function Enhancements

VMSs were introduced to the market in the early 1980s, and originally worked as stand-alone systems behind PBX systems. Although the first VMSs were designed and marketed by third-party suppliers, several of the leading PBX manufacturers eventually entered the market with products of their own design. Rolm and AT&T were among the first PBX manufacturers to enter the voice messaging market with products designed to work behind their own communications systems, although they could also be engineered as stand-alone systems to work behind other suppliers’ PBX systems.

Northern Telecom, one of the leading PBX suppliers, came late to the VMS market during the late 1980s, but when it introduced Meridian Mail it became the first messaging system to be fully integrated within the PBX system design. Meridian Mail used the Meridian 1 processing and switching network backplane for supporting PBX station user messaging applications. The Meridian Mail Module was installed as another cabinet stack in the Meridian 1 and tightly integrated within the overall PBX system design. Instead of using analog station interfaces and a dedicated data signaling link between the PBX system and adjunct voice messaging cabinet, Meridian Mail ports appeared to the Meridian 1 switching network as just another station port, and signaling between the Meridian Mail Module and the Meridian 1 common control complex was transmitted over the internal system processor bus. AT&T followed Northern Telecom’s example and later redesigned its Audix VMS as a multiple card slot equipment module to be installed within its Definity PBX system. The Definity Audix option offered most of the features and functions available on the larger, stand-alone Audix (later Intuity Audix) system at a reduced price.

During the early 1990s VMSs were redesigned to support integrated messaging applications with e-mail servers. The concept of a UMS designed to support voice and e-mail messaging, with both message mediums sharing a common directory and storage system, was also introduced in the early 1990s. Although demand for the enhanced messaging system designs has been limited to date, there are many productivity and cost benefits attributable to using one mailbox for all types of messages and having a single interface to the mailbox from either a telephone or PC client.

Recognizing the competitive advantage of bundling messaging applications within the PBX system, several recent start-up companies with PBX client/server designs, such as Altigen and NBX (since acquired by 3Com), integrated a UMS application running off the main system server that also provided basic PBX communications features and functions. Recently, Avaya integrated the capabilities of a full-function Intuity Audix system into the main call processing board of its small Definity One PBX system and included the Intuity Integrated Messaging appli- cation on the same board. The Altigen, 3Com, and Avaya PBX systems with the bundled messaging capabilities are designed for small/intermediate customer line size requirements, and the message storage capacities and access ports are limited. PBX systems designed for large and very large customer port requirements would not be able to integrate the messaging application into the main common control complex without affecting the basic communications responsibilities of the system. Dedicated messaging application servers will likely be the optimal solution for higher-end PBX customers, even when IP-PBX client/server system designs become standard by the end of this decade.


Figure 1: Avaya speech access with unified messenger architecture.

Computer Stored Program Control

Until PBX systems incorporated computer technology into its call processing system design, features and functions were extremely limited. Station user features were restricted to those operations that could be handled by mechanical means. The general availability of computer SPC meant that features could be based on software programming tools, and feature development was limited only by a programmer’s imagination. Many PBX functions that are currently viewed as basic telephony capabilities, such as call forwarding and station activated conferencing, were first implemented through computer SPC. Network routing tables and CDR would not be available without computer programming capabilities.

The first SPC PBX system was introduced by Northern Telecom in the early 1970s. Known by a variety of names, including the Pulse and the SG-1, the Northern Telecom system was the first PBX to use a computer software program to perform basic call processing functions, such as provisioning of dial tone, and implement simple station user features, such as hold and transfer. In the United States, Northern Telecom distributed the system through the Pacific Telephone and Telegraph local telephony company, but sales of the new PBX design were limited. It was not until AT&T introduced the Dimension PBX system in 1974 that an SPC communications system was distributed on a large scale through each of the Bell System’s local operating companies. Dimension became one of the best-selling PBXs of all time, although AT&T’s market share declined throughout the life cycle of the product. After the Dimension PBX announcement, there was a flood of SPC communications systems from AT&T’s competitors. Between 1974 and 1980 SPC PBXs went from a 1 to a 95 percent market saturation level for new system installations.

The first computer-based PBXs were based on a centralized processing design. A single computer-based call processing element was used for all system call processing and switching operations. PBX manufacturers of the early digital SPC systems designed and manufactured their own processing hardware and were the designers and developers of the operating system used as a platform for software feature applications. The first-generation digital PBXs were based on call processing designs that closely resembled the minicomputers of the 1970s. Many computer manufacturers became interested in the PBX industry as a new potential market for their products, and a few actually attempted to design a telephony system. Rolm was a manufacturer of military specification computers who successfully entered the PBX market, but most failed. IBM designed, manufactured, and marketed PBXs for the European market but was unable to compete in North America. Digital Equipment Corporation (DEC) was rumored to be developing a PBX based on its VAX minicomputer design, but no product was ever officially announced.

Computer technology in the 1970s was relatively expensive as compared with current prices, and the high cost to design and manufacture a digital PBX was reflected in the enduser price at the time. Common control equipment hardware was priced several times the current cost to customers, even though the features in the 1970s were minimal compared with those of today, and the call processing power of the system was a fraction of today’s capacity limits. PBX call processing design evolved significantly during the 1980s when third-party microprocessors were generally available, and prices began their exponential decline. Dispersed and/or distributed call processing designs became the standard architecture platform for PBX systems. The single, centralized, common control element gave way to dedicated processing elements for diagnostics and maintenance operations, localized call processing and switching functions, and systems administration. Basic function electronic telephones with internal processor chips evolved into intelligent digital telephones. Adjunct applications processors provided enhanced functionality behind the core PBX system.

During the 1980s PBXs could be classified into one of three call processing system designs: centralized, distributed, and dispersed. System processor elements expanded from the common control complex to expansion port cabinets and even to individual port circuit cards. The focus of PBX system design was shifting from hardware to software. From the 1970s through the mid-1980s more research and development dollars were spent on hardware upgrades and enhancements, with a focus on digital switching and SPC functions. By the late 1980s most research dollars were being spent on software programming. The emergence in the 1990s of third-party CTI software applications programs running on adjunct servers linked to the PBX officially signaled the beginning of the end of proprietary common control and call processing designs. At the beginning of the twenty-first century, almost 90 percent of PBX research and development dollars were devoted to software applications programming. Little money is spent on core call processing hardware because third-party microprocessors, digital signal processors, and servers, instead of the original self-designed and manufactured computer system, are used.

Today’s PBX call processing design is as likely to be based on a customer-provided Windows NT server from Compaq, IBM, or Dell rather than a proprietary common control cabinet from the PBX supplier. Customers may experience lower system reliability levels using third-party servers not designed by their manufacturer for the heavy-duty real-time call processing demands of telephony communications, but the lower price alleviates the risk factor to some extent.

Digital Switching/Transmission

PBXs based on digital switching and transmission technology debuted in the mid-1970s. Between 1974 and 1976 several communications system manufacturers claimed to be the first to announce a digital PBX system, including Northern Telecom (currently known as Nortel Networks), Rolm (acquired by IBM and then sold to Siemens), and Digital Telephone Systems (later acquired by Harris Corporation and known as Harris Digital until withdrawing from the market in 2000). The stated driving factor for developing a digital PBX system was to support desktop data communications without a modem, although data communications options would not be widely available until the early 1980s. Other benefits of digital switching/transmission included improved system quality and reliability levels and lower potential manufacturing costs.

There were no established standards for designing a digital PBX system in the 1970s, and the resulting systems reflected each manufacturer’s individual design biases. The preferred method of digital transmission used by almost all PBX designers was TDM. TDM is simply described as the sharing of a common transmission bus by many peripheral endpoints. Transmission of digital signals by each endpoint is based on assigned time slots by the PBX common control system. Although TDM was used for transmission of digital signals across the internal PBX switching network, it was possible to use different encoding schemes to convert the original analog signals into a digital format. Although most of the early digital PBXs used an 8-bit word PCM formatting scheme, including Northern Telecom’s SL-1 PBX, the first-generation Rolm CBX used a 16-bit word. The typical sampling rate used to convert analog signals to digital format was 8 KHz (a sampling rate double the maximum frequency of a human voice communications signal), but the Rolm CBX used a 12-KHz sampling scheme.

Encoding schemes other than PCM could also be used. In the early 1980s the first-generation Lexar LBX system used a Delta Modulation (DM) sampling/encoding scheme. Some manufacturers evaluated using Adaptive Differential Pulse Code Modulation (ADPCM), based on a 4-bit word encoding format, but no product was ever announced. Although no written industry standard existed, by the early 1980s it became obvious that the 8 KHz sampling using 8-bit word encoding was the preferred digital PBX switching platform. It took Rolm 8 years after its original CBX system made its debute to change its digital switching platform to conform to the 8-KHz, 8-bit word format; Lexar also converted to 8-bit PCM in the late 1980s. By 1990 100 percent of all new PBXs sold in North America were based on digital switching platforms using 8-KHz, 8-bit word TDM/PCM.

The first digital PBX systems digitized the analog voice signal at the port circuit card. Analog voice transmission signals were digitized for transmission across the internal switching network, mostly through the use of a TDM transmission scheme. After being transmitted across the internal switch network, the digitized transmission signal was reconverted back to analog format at the destination port circuit card. Analog station port cards were used to transmit communications to desktop devices, such as telephones or modems, and analog trunk circuit port cards were used to connect to telephone company trunk carrier circuits.

When Intecom introduced the first digital telephone in 1980 for its IBX communications system, the digitization process was performed with a codec in the telephone. Voice signals were digitized and transmitted over the local loop wiring from the telephone to the port circuit card. The first digital telephones used a multiple-channel communications link between the codec and the port circuit card. One channel was used for digitized voice signals and another channel was used for control and signaling functions. A third channel was also available for data communications devices attached to the digital telephone via a data module. Stand-alone data modules for data-only desktops were also available (Figure 1).


Figure 1: Digital PBX data communications.
Desktop-to-desktop digital communications was a major breakthrough for PBX systems. In addition to using the telephony communications network for voice communications, customers could use the PBX system as a local area data communications network. Very expensive modems would no longer be required to convert digital data communications to analog format, and transmission rates up to 64 Kbps could be achieved. Accessing a centralized computer mainframe system would be simplified—no more modems or coaxial cable cluster controllers. LAN technology in 1980 was in its infancy and very expensive. The early Ethernet Network Interface Cards (NICs) were more than double the cost of a digital PBX datastation. A PBX system could support an entire network of data workstations across the entire enterprise when an Ethernet LAN was limited to 50 workstations with major distance limitations. Great things were predicted for the integrated voice/data PBX system because transmission and switching could be all digital. We now know that LAN technology improved; NIC prices rapidly declined; bridges, hubs, Fast Ethernet, and routers were developed; and PBXs as data networking systems never caught on. The irony of the situation is that the digital PBX transmission and switching infrastructure is evolving toward an Ethernet LAN/IP WAN design.

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.

Enterprise Communications Systems Today | PBX Systems for IP Telephony

Today’s enterprise communications market is in a considerable flux caused by major ongoing changes in the technology of core products and the network infrastructure. Notably, voice communications systems are migrating from a time- to a packet-based switching and transmission design. The last major market and product shift occurred in the mid-1970s when the first computer stored program control (SPC) and digital switching communications systems were announced and shipped to replace older generation electromechanical systems. Although every generation believes that product 2upgrades and enhancements occurring in their prime are the most significant ever, telecommunications managers who remember the limited feature and function capabilities available on communications systems 30 years ago may be less impressed with the current market upheaval than industry newcomers who have learned to expect a new generation of products every 18 months from the data networking world.

Today’s typical enterprise voice communications network includes many, if not all, of the following ingredients:

1. A core communications switching system (Private Branch Exchange [PBX] system, Key Telephone System [KTS], or KTS/Hybrid system) that provides dial tone, call setup and teardown functions, and more call processing features than any one customer is likely to use

2. A management system to support fault and configuration operations

3. A call accounting system that analyzes and processes call detail records to generate billing and traffic reports

4. A voice messaging system that offers a wide array of services far beyond a basic answering system

Other widely used products that support basic voice applications in the enterprise include automated attendants, paging systems, and voice announcers. It is naturally assumed, but sometimes overlooked, that each network system user has some type of desktop or mobile telephone to access the core communications switching system. Other stand-alone desktop equipment scattered around the enterprise is likely to include facsimile (fax) machines and modems for dial-up data network access.

Customers with call center system requirements will install, at a minimum:

1. An Automatic Call Distributor (ACD)

2. A Management Information System (MIS)

As the call center requirements become more sophisticated, subsystems and options will be added to the basic ACD. These might include an Interactive Voice Response (IVR) system, an Automatic Speech Recognition (ASR) system, or a Computer Telephony Integration (CTI) application server. Users now routinely expect that all of these call center system elements will gradually merge with the Web server and e-mail server to form a mixed media e-contact center.

Twenty years ago almost none of these products existed beyond the core communications switching system. Small-line-size customers during the early 1980s with basic voice communications requirements would have a KTS or perhaps one of the recently introduced KTS/Hybrid systems. Intermediate and large-line-size customers with more advanced requirements preferred a PBX system, although what counted as advanced capabilities at the time would include features and functions considered basic today, such as Direct Inward Dialing (DID), Call Detail Recording (CDR), and Automatic Route Selection (ARS). These features were once available on only large, sophisticated, and relatively expensive PBX systems, but they can now be found on KTS products targeted at very small customer locations. The trickle-down theory of KTS/PBX feature and function options says that optionally priced advanced features and functions designed primarily for customers of large PBX systems eventually become standard offerings on entry-level KTSs.

The number of available features on PBX systems has increased exponentially since the first SPC models were introduced in the 1970s. A leading-edge PBX system marketed in 1980 had a software package with about 100 features for station, attendant, and system operations. By 1990 the number of features had more than doubled. Today a typical PBX system boasts more than 500 features, including optional hospitality, networking, and ACD options, and today’s typical KTS/Hybrid system offers more performance options than any PBX system in 1980. Despite the significant increase in features designed for desktop access and implementation, the majority of PBX station users (i.e., people with phones on their desks) use fewer than ten features on an everyday basis. Ironically, today’s typical station user may use fewer features than he would have used 20 years ago because many once-popular features, such as call pick-up and automatic callback, are rarely implemented. One reason for the decline in use of once common desktop features is the prevalence of voice messaging systems that preclude the use of many manually operated features for call coverage situations.

As a result, today’s PBX developers continue to write new feature software programs for the non-typical station user. Studies show that most station users implement about six features on an everyday basis, and features in general use are limited to hold, transfer, conference, and a few others. However, system designers cannot assume that the set of features in general use will be the same for every station user. Many features are used by a small number of system subscribers, but they are no less important than those used by the majority. For example, a feature such as Flexible Night Service may be used only by the system’s sole attendant console operator, and the Recent Change History feature may be of value only to the system administrator, but these features are as vital to the few individuals who implement them as Call Forwarding is to a typical desktop telephone station user. Many of the hundreds of PBX features introduced during the past 20 years were developed at the explicit request of customers. When a customer or a small group of customers demanded a new feature, a PBX manufacturer first determined that anticipated demand justified its development. Once offered by a major manufacturer, the new feature soon became available on systems from most competitors.

It’s important to note that some perfectly viable features are unique to special categories of customers or station users and may be used by as few as one system subscriber per enterprise. A feature’s value is not determined solely by how many individual station users implement the feature, but also by potential cost savings and productivity improvement at a station, system, or network level.

Of course, most customers do not have stringent demands on PBX system design architecture attributes; they’re looking for basic growth and redundancy requirements. A station user who doesn’t have telecommunications system acquisition or management responsibilities cares nothing about the technical underpinnings of the telephone system he’s using. He picks up the telephone handset, listens for dial tone, punches a number or activates a feature, and is satisfied by the experience almost every time. As long as that’s true, the station user won’t be asking whether the system has analog or digital transmission, circuit-switched or packet-switched connections, a proprietary software operating system, or a standard off-the-shelf Windows solution. People who should care about PBX system technology and reliability standards, applications support, and future product direction are the telecommunications manager, voice/data networks director, or CIO.

PBX Circuit Switching Design

PBX circuit switched network designs differ between each manufacturer’s product portfolio and even among models within a portfolio. Although there are differences in the individual PBX system switch network designs, the main functional elements are the same. All port circuit interface cards transmit and receive communications signals via a directly connected TDM bus, but the time and talk slot capacities are likely to differ between systems. A very small or small PBX system switching network design may consist of a single TDM bus backplane connected to every port interface circuit card, but a larger PBX system with more than one TDM bus must be designed to provide connections between the TDM bus segments. The TDM bus connections may be direct connections or center stage switch connections. The center stage switching system complex may be based on a space switch matrix design using circuit switched connections or a broadband TDM bus interconnecting lower bandwidth TDM buses. Two of the leading suppliers of PBX systems, Avaya and Alcatel, also offer customers of their very large PBX system models a center stage ATM switching option that can also support switched LAN data communications applications.

Center Stage Switch Complex
The primary function of the center stage switching complex is to provide connections between the local TDM buses, which support port carrier interface transmission requirements across the internal switching network. Complex center stage switching systems may be used in PBX systems designed for 100 user stations, although the smaller systems typically have a single TDM bus design or multiple TDM buses with direct link connections between each bus. A center stage switching complex may consist of a single large switching network or interconnected switching networks.

A very small PBX system usually does not require a center stage switching complex because the entire switching network might consist of a single TDM bus. Individual TDM bus switch network designs require a TDM bus with sufficient bandwidth (talk slots) to support the typical communications needs of a fully configured system at maximum port capacity. Most small PBX systems based on a single TDM bus design can provide nonblocking access to the switch network at maximum port capacity levels. If the TDM bus has fewer talk slots than station and trunk ports, the switch network can still support the communications traffic requirements, if properly engineered.

There are a few small and intermediate PBX systems that have multiple TDM buses but no center stage switching complex. For example, an Avaya Definity G3si can support up to 2,400 stations and 400 trunks using three-port equipment cabinets, each with a dedicated TDM bus, but does not use a center stage switching complex to connect the TDM buses. PBX system designs like the Definity G3si use direct cabling connections between each TDM bus for intercabinet connections between ports. This type of design can support a limited number of TDM buses without a center stage switching complex, but more TDM buses require more direct connections between each bus. When the system design includes more than three TDM buses, the switch network connection requirements may become unwieldly and often very costly. During the 1980s the Rolm CBX II 9000 supported up to 15 port equipment nodes that required dedicated fiber optic cabling connections to link each cabinet’s TDM bus switching network because it lacked a center stage switching complex. A fully configured system required 105 direct link connections (fiber cabling, fiber interface cards), resulting in a very costly alternative to a center stage switching complex. Every new nodal addition to the system required new fiber optic connections to every existing cabinet node. The advantage of a center stage switching com- plex in an intermediate/large PBX system design is to simplify switch network connections between endpoints.

There are several center stage switch designs typically used in digital circuit switched PBXs:

Broadband (very large bandwidth) TDM bus

Single-stage switch matrix

Multistage switch matrix

Broadband TDM Bus
Most local TDM buses have limited bandwidths capable of supporting between 32 and 512 time slots. A TDM bus functioning as a center stage switching complex capable of supporting switch connections between many local buses must have a transmission bandwidth equal to or greater than the total bandwidth of the local TDM buses it supports for nonblocking access. For example, a single TDM bus with a bandwidth of 128 Mbps (2,048 time slots) can support switch connections for sixteen 8-Mbps TDM buses or four 32-Mbps TDM buses.

The center stage TDM bus must also support a sufficient number of physical link connections to support all local TDM buses. If the bandwidth of the center stage TDM bus is not sufficient to support switched connections for every local TDM bus time slot, there is a probability of blocking between the local TDM bus and the center stage TDM bus. The number of local TDM bus connections is always limited to ensure nonblocking access to the center stage TDM bus.

Local TDM buses typically interface to the center stage TDM bus through a switch network element known as a Time Slot Interchanger (TSI). The TSI is a switching device embedded on the physical interface circuit card that supports the physical local/center stage bus connection. The primary function of a TSI is to provide time slot connections between two TDM buses with different bandwidths. The simplest definition of a TSI is a portal between the local TDM bus and the center stage bus.

If a single broadband TDM bus cannot support nonblocking connections for all of the installed and configured local TDM buses, it may be necessary to install additional center stage TDM buses. A center stage switching complex based on multiple high bandwidth TDM buses requires connections between each center stage bus, in addition to switched connections to the local buses. Switched connections between any two local TDM buses in the PBX system may require transmission across two center stage buses, which are linked together, because each center stage TDM bus has dedicated connections to a select number of local TDM buses. The bandwidth connections between the high-speed center stage TDM buses must be sufficient to support the port-to-port traffic needs of the local TDM buses. For this reason, system designers use very high-speed optical fiber connections to ensure the switched network traffic requirements.

Single-Stage Circuit Switch Matrix
The most popular center stage switching design is a single-stage circuit switch matrix. A single-stage circuit switch matrix is based on a physical crosspoint switched network matrix design, which supports connections between the originating and destination local TDM buses. A single-stage circuit switch matrix may consist of one or more discrete switch network matrix chips. Most small/intermediate PBX systems use this type of design because of the limited number of local TDM buses needed to support port circuit interface requirements.

The core element of a crosspoint switching matrix is a microelectronic switch matrix chip set. The switch matrix chip sets currently used in PBXs typically support between 512 and 2,048 nonblocking I/O channels. A 1K switch matrix supports 1,024 channels; a 2K switch matrix supports 2,048 channels. Each channel supports a single TDM bus time slot. Larger switch network matrices can be designed with multiple switch matrix chips networked together in an array.

Based on the size of the switch network matrix and the channel capacity of a single chip set, a center stage switching complex may require one or more printed circuit boards with embedded switch matrix chip sets. The number of chips increases exponentially as the channel (time slot) requirements double. For example, if a single 1K switch chip can support 1,024 I/O communications, four interconnected 1K switch chips are required to support 2,048 I/O channels. Doubling the number of channels to 4,096 will require 16 interconnected 1K switch chip sets. Large single-stage switching networks use a square switching matrix array, for example, a 2 × 2 array (four discrete switch matrix chip sets) or a 4 × 4 array (16 discrete switch matrix chip sets).

A 1K switch matrix can support any number of TDM buses with a total channel (time slot) capacity of 1,024, for example, eight 128 time slot TDM buses or four 256 time slot TDM buses. The total bandwidth (time slots) of the networked TDM buses cannot be greater than the switch network capacity of the center stage switch matrix. The physical connection interfaces for the TDM buses are usually embedded on the switching network board, but this is not always the case. The intermediate/large Nortel Networks Meridian 1 models require an intermediary circuit board, known as a Superloop Card, to provide the switch connection between the local TDM buses (Superloops) and the center stage 1K group switch matrix.

Multistage Circuit Switch Matrix
A single-stage circuit switch matrix design is not feasible for the center stage switching system complex of a large or very large PBX system because such a system would have a system traffic requirement for as many as 20,000 time slots. A very large array of switch matrix chip sets would lead to design complications and require several switch network array printed circuit boards. The better switch matrix design solution for a large or very large PBX system is a multistage design. The most common multistage switch network design type is a three-stage network design known as a Time-Space-Time (T-S-T) switch network. A T-S-T switch network connects three layers of switches in a matrix array that is not square (Figure 1).


Figure 1: TDM bus connections: center stage space switch matrix.

In a T-S-T switching network design, each switch network layer consists of the same number of switch matrix chips. The first switch network layer connects the originating local TDM buses to the second switch network layer; the third switch network layer connects to the second switch network layer and the destination local TDM buses. In this design, the second network switch layer is used to connect the first and third layers only, with no direct connection to the local TDM buses. The term Time-Space-Time was derived from the fact that the first and third switch network layers connect to TDM buses, and the second switch network layer functions solely as a crosspoint space connection switch for the two outer layers.

In a T-S-T switch network configuration, each TDM bus channel entering the first switch network layer has access to each outbound switch connection to the second switch network layer. In turn, each outbound switch connection in the second switch network layer has access to each switch connection in the third switch network layer. Each switch matrix in the first and second layers is connected according to the same pattern.

The T-S-T switch network is contained on a combination of printed circuit boards. Multiple first and third layer switch matrix chip sets may be packaged on a single board, although the usual design is a single switch matrix per board to simplify connections between the local TDM buses and the second switch network layer. Multiple second layer switch matrices are usually packaged on a single board. The total number of boards required for the center stage switching complex will depend on the number of I/O TDM channels configured in the installed system. An 8K switch network will require fewer boards than a 16K switch network.

ATM Center Stage
During the early 1990s, it was believed that traditional circuit switched voice networks would someday be replaced by ATM switch networks. Several PBX manufacturers worked to develop a PBX switch network based on ATM switching and transmission standards. An ATM switching network can provide the same high quality of service as traditional circuit switched networks can for real-time voice communications; it also offers the additional advantage of very high switching and transmission rates. Lucent Technology’s enterprise communications system division (now Avaya) and Alcatel developed, announced, marketed, and shipped ATM center stage switching options for its largest PBX models. Implementing the ATM center stage switching option requires a stand-alone ATM switching system equipped with customized interface cards to connect to the PBX processing and switch network subsystems. A gateway interface card is used to link the local TDM buses to the ATM switching complex for intercabinet communications. The gateway interface card converts communications signals from time-based PCM format to ATM packet format.

Shipments of the option have been negligible since its introduction for two important reasons: few customers have installed ATM-based LANs, opting instead to upgrade their IP-based Ethernet LAN infrastructure, and the cost to install the PBX option is greater than the cost of a traditional TDM/PCM center stage switching complex. In addition to the cost of the ATM switching system, there is the cost of high-priced interface cards used to convert TDM/PCM communications signals to ATM format for connecting the local TDM buses to the center stage switch complex. Nortel Networks tested an ATM-based version of its Meridian 1, but canceled development in the late 1990s after determining that the cost to upgrade a customer’s installed system was too high.

The Avaya Definity ECS and Alcatel OmniPCX 4400 ATM-based offerings are still being marketed, but too few customers have shown enough interest to make it a viable center stage switching option for the future. Growing market demand for IP-based PBX systems appears to have stunted development of the ATM center stage switching option.