[ Home ] [ Table of Contents ] [ About Lee Goeller ] [ Search ]

The PBX: What It Is, How It Works

Lee Goeller's "The PBX: What It Is, How It Works" was Chapter One of The BCR Manual of PBXs, a ring-bound information service published by Business Communications Review from 1980 to 1990.

To speed downloading, we have posted the chapter in five parts, and configured diagrams to open as separate windows.

The PBX: What It Is, How It Works

Part Four: System Control

Modern PBXs use one or more processors for control. The stored program approach is now standard, but this hardly tells the whole story. We are confronted with an explosion of control techniques based on the plummeting cost of microprocessor and memory chips and other electronic devices. At this moment (early in April, 1985) 64K RAM chips are going for $1.00 each, and 10 Mbyte hard disk memory systems are selling to OEM manufacturers for something like $600. Low cost options open to designers today weren't available at any price just a few years ago.

In any computer-controlled industrial system, a program, or list of instructions stored in memory, is used by a processor receiving signals from and sending signals to various pieces of peripheral equipment. In a PBX, a "scanner" checks the status of lines, trunks and other circuitry, and sends its reports to memory. The processor looks at present and past status of any given port in its memory map, identifies changes (did terminal 463, formerly on-hook, go off-hook to signal a call origination?), and follows its stored instructions by generating a response (find an idle signaling receiver, attach it to terminal 463 via the switching matrix, and instruct it to return dial tone) by issuing appropriate command signals to the matrix and signaling receiver as required.

In modern systems, each piece of peripheral equipment may be controlled by its own processor; for instance, it is possible for the line and trunk scanner to have its own "last look" memory and only deliver changes in status and terminal identities to the main processor. This task is harder than it looks because noise on the line may affect the port sensor; typically, several looks are required, several milliseconds apart, before an electronic scanner will "believe" that a change has taken place. Similarly, switch-hook flashes and, if still used, dial pulses, can be detected, timed and collected, and complete digits sent to the control. Where digital signaling is used to and from electronic telephone sets, much faster and more elaborate communication between peripherals and sets is required, but the higher level communication between peripheral and central processor may be relatively slow because of all the "front end" work the processor has done to reduce the need for transmitting and receiving such information.

The control responds to externally generated signals and to internal signals that result from processing information in accordance with data stored in memory. That is, it checks class marks and other instructions and sets up paths through the switching matrix between lines and/or trunks, records information in memory for billing and traffic purposes, makes tests on itself regularly and, in general, carries out the functions of an operator at a manual switchboard as well as those of a maintenance craftsperson continuously checking the health and sanity of the system.

The control's associated memory must contain a great deal of information, organized on a per-system, per-port, and per-call basis. First of all, it must hold the system program, the routing tables for Automatic Route Selection, perhaps the billing algorithm for costing long distance calls, etc. Then, it must contain a data-base dedicated to individual ports, containing each port's class of service (which may be divided up to deal with originating features such as speed calling and terminating features such as call forwarding). Here, also, is stored the translation between extension number and switch position and, in modern systems, the name of the person to whom the phone is assigned for use by the directory.

The per-call memory must have space for the originating port, the dialed number and the answer and hang-up time. It may also record the facility chosen for a long distance call, time spent in queue waiting for that facility, the path through the matrix, etc. It may be convenient to copy into the call record the calling extension number, the originating class of service and class of restriction (often separate), which are needed by ARS, and other information. When the call is completed, the appropriate parts can be written to the billing record, while other parts can be used to release the trunk and matrix path for use by other callers.

To complete a call, the system already knows the called extension or trunk group desired from information supplied by the call originator. It must then translate the extension number or trunk group identity to a specific matrix port (the reverse of the translation made to serve the originating party) and then check terminating class of service and restriction: Is this line or trunk in a hunt group? Is call forwarding in effect? Is pick-up from some other phone a possibility? A busy test is made, usually on the status indicator stored in memory and updated regularly, rather than on the port itself. A line may be "busier" than busy, particularly if camp-on or call-waiting is available. On a call to an extension, ringing must be applied, answer supervision detected, and the connection placed in the talking state. The control does this by manipulating the switching matrix and, as required, line, trunk and service circuits. Note that at each stage of the game, it checks information stored in its memory.

This is the whole secret of modern systems. Everything is stored in a list of some sort in memory. In the old days, DTMF vs. dial pulse signaling was handled by having two different line groups: DTMF extensions would be placed on one and rotary-dial lines on the other. Ringing type was selected by the location of the line on the switch, and hunting was activated by strapping certain terminals together at the terminating side of the line circuit. Restricted stations would sometimes have a similar strapping at the originating side of the line circuit: one kind of strapping would permit certain first digits to be dialed (2 and 3 for internal calls, for instance, but not 8 for tie trunks or 9 for CO trunks). All this is nearly gone. Hardware limitations are mostly removed, and everything is handled by symbols stored in memory lists or tables.

Automatic Route Selection (ARS), for instance, is just a group of lists, to be selected on the basis of the called number and the caller's class of service or restriction. The list chosen for a given call specifies the first, second, third and perhaps additional choices of trunk group on which the call in question can be placed, usually in the order of ascending cost. The list may also contain instructions to queue after looking at certain lower cost trunk groups (usually WATS or FX) and finding them busy. If a trunk in one of these groups comes free during the queue interval, it will be used to complete the call; if one does not come free, the caller may be informed (by a tone) that the call will go toll unless he hangs up, and a regular dial 9 trunk is then used.

A further refinement is based on the built-in system clock-calendar; this permits changing selection of ARS lists as a function of time of day and day of week. The main use here was prior to June 1981, when it was necessary to busy out Measured WATS after 5 PM on the East Coast (when toll became cheaper). The present tapered rate WATS tariffs make this unnecessary, but there are other instances where changing routing as a function of time or day can be used to good effect. Time of day and day of week routing should be built into the program structure of any modern PBX. Obviously, the computer can follow instructions that are quite complex.

Processors are usually not duplicated for reliability in small systems; they almost always are in large systems. The break point appears to be about 400 lines. Duplication for reliability was first done in the hot standby mode; that is, one processor had control while the other monitored its actions and stayed poised, ready to take over. This increased system complexity in that both sets of memories had to be kept up to date, and the computers had to be able to decide which one was in charge. In earlier stored program control systems, the cost of the second processor was sometimes justified by letting it run standard business programs (payroll, inventory, etc.), or related communication functions such as Rolm's early electronic mail system. In recent years, however, the prices of computers and memory have dropped so low that this form of cost justification is hardly needed and "applications processors" have been added, linked via a system bus, to handle a variety of functions more or less related to communications: CDR, directory, energy management, emulation of different data systems, etc. Voice and message storage systems are also added in the same way.

As the price of computers continues to fall, other approaches to reliability have been tried in newer designs. One approach is to have a different processor for each set of functions (as in the late Rockwell-Wescom 580): one for handling lines, another for trunks, one for the matrix, one for the data base, etc. Another is to have each module in a large system semi-autonomous, with its own computer and memory, so that any one failure will only affect a portion of the system. Another approach, often referred to as "n+1," lets several processors share the central control load (very much the way markers did in electromechanical crossbar systems), with one more supplied than traffic demands. Then, failure of any one processor does not affect the operation of the system, and if more fail, "graceful degredation" takes place.  The NEAX 22 carried this to an extreme with up to 32 processors; the NEAX 2400, using much faster processors, gets the sane results with only four.

No amount of processor duplication will save the system in the event of power failure. In such an instance, a back-up battery is required to keep the system running. The alternative is to let the system die, usually throwing over a number of CO trunks to selected extensions for emergency service. If only RAM is used for system memory, loss of power wipes it clean and the system must be reloaded from tape or disk (the latter is much faster) when power is restored. Calls in progress are usually lost, and station programmed features may or may not be saved on tape or disk for reload, depending on system design. Small batteries designed to keep the RAM active when outside power fails are common these days; other alternatives use ROM for the basic program, some form of programmable ROM (PROM, EAROM, EEPROM, etc.) for the system data base (station information and translations, ARS tables, etc.), and RAM only for calls in progress and other temporary memory that changes rapidly.

One of the main advantages of stored program control in switching systems (or other industrial equipment) is the ease with which new features can be installed, service can be upgraded, and changes can be made in the course of regular activity. Note, however, that not all stored program control systems permit easy changes. Read-only memories (ROMs) are not always changeable in the field—sometimes they may have to be unplugged and replaced, while in other instances, their machine language instructions must be altered in a special programming device. ROM memory is quite reliable: it can't be changed by unauthorized personnel very easily, and being non-volatile it is ready to go as soon as power comes back after failure. But in most instances, the flexibility of making changes from a maintenance terminal, the console or a special telephone set is of much greater importance. Thus RAM battery and PROM are finding wide use.

Software design to support the alteration of system parameters by customer personnel is one of the most important innovations taking place in PBX design today. Although some manufacturers and vendors are trying desperately to hold on to their $75 an hour terminal manipulations whenever the customer needs a move, change or routing update, most are finding better response by providing "do it yourself" capability for the customers who want it. It is interesting to note that AT&T is one of the leaders in offering such an approach. Intecom, Ztel, CXC and others are following with considerable enthusiasm, but a few die-hards are resisting the trend. How long they can keep their sacred mysteries out of the customers' profane hands is one of the more interesting questions the marketplace can answer for us.

[ Top ] [ Next ] [ Table of Contents ]

Copyright 2006 Lee Goeller. All Rights Reserved.