Goeller on Telecom Traffic

Calls, Attempts and Completions

(Business Communications Review, November 1989)

Once upon a time, as the story goes, Bell of Pennsylvania replaced a Step by Step central office with a new, shiny No. 5 Crossbar. This was a straightforward procedure, and the small town on the outskirts of Philadelphia was proud to have a telephone central office with all the latest features. This gave the town something to be proud of in addition to a very popular race track located there

Unfortunately, the straight-arrow traffic engineers from Bell did not allow for the racetrack in their calculations. Being pure as the driven snow themselves, it never occurred to them that the rest of the world might have feet of clay. Right up to the neck. In particular, it never occurred to them that human beings are not content to watch the mighty thoroughbreds thunder 'round the track. Some human beings actually wager on which horse might come home first.

The new, shiny No. 5 Crossbar did just fine until the track opened for the first day of the racing season. Then, it locked up and for all practical purposes dropped dead. It seems that those who wager on precisely which horse is the fastest do not spend a lot of time putting their money where their mouth is. It takes about 20 seconds to place a bet with their private bookmaker, and many indulge in this practice.

Now, good old SXS was a simple beastie. It had no common control, no registers, no senders, no nothing. Whenever you made a call, every gadget and gimmick which the central office needed to make the connection was there, part of each switch, and yours for the duration of the call. No. 5, on the other hand, used Markers to make connections, and Originating Registers to give you dial tone and collect your dialed digits. As soon as the OR knew what number you had dialed, it gave it to a Marker to complete the call, and the OR itself went on to take somebody else's order.

The new, shiny No. 5 Crossbar office had been designed on the basis of traffic measured in CCS which, when divided by 36, becomes Erlangs or, in simple English, the average number of calls in the system during the period of measurement. With SXS, only this average mattered, but with No. 5, the number of calls was also important, because Markers and ORs were used on a per-call basis, independent of call duration. Of course, you can get the number of calls by dividing the total erlangs by the average call holding time (if you use the right time units), but if you are unaware of the seasonal influx of those who wager on horses, you may be misled. You might assume an average call duration of three or four minutes, and thus be too low on your estimate of the actual number of calls by a factor of ten. If you have only one tenth the number of originating registers or markers you need, your switching matrix can be fully capable of handling the average number of calls in progress--it might even be engineered to be non-blocking--but you would still blow your switch right out of the water. You simply would not have enough common control equipment to handle the NUMBER of calls involved, no matter how many CCSs or Erlangs the matrix could handle.

Ultimately, Bell of Pennsylvania added a gaggle of ORs and beefed up the number of markers, and the straight arrows in traffic learned how to live with those who have feet of clay and hope of winning. Unfortunately, not everyone has learned from their example.

The Call War

There is a major war going on in PBX-land today. Northern Telecom and AT&T are rating the ability of their common control equipment in terms of busy hour calls or busy hour call COMPLETIONS, while almost everyone else is concerned with busy hour call ATTEMPTS. Both sides in this titanic struggle are trying to rate their common control equipment in terms of the NUMBER of calls it can handle (independent of how long each call lasts), but each side is missing a couple of very obvious points that the other is trying to correct.

Most of us have observed that a call ATTEMPT, even if unsuccessful, requires just about as much effort from the common control as a call COMPLETION. On the other hand, AT&T and Northern Telecom are incensed because some of their competitors, in an effort to generate impressive statistics, are measuring call attempts by pressing and releasing the switch-hook, pulling and dropping dial tone over and over again. I should point out that nobody at AT&T or Northern will tell me who is actually doing this, and in my own fairly extensive contacts with PBX manufacturers, not one will admit to this obviously silly definition of a call attempt. But I have found a few communication managers who use it, so it must have come from somewhere.

The problem with calls or call completions is that they are a function of the number of things a phone system can connect to. If all the outside trunks are busy, you have all the completions to the rest of the world you are going to get, even as the frustrated users try and retry and retry to dial 9 to get out. Further, experience shows that these retries will increase as service degrades (why do you think people like "last number redial"?), putting an even bigger load on the processor, DTMF receivers, etc., until the whole system comes crashing down like the No. 5 in Graceland.

There is, of course, NO relationship between busy hour call completions and busy hour call attempts. Call completions will go up until the number of trunks, matrix paths or whatever are all in use. But call attempts can keep right on going up. To try to calculate attempts by dividing total call holding time by average holding time per call is to forget the racetrack effect: when a lot of very short calls come in, as when you get busy or reorder tone instead of your gabby buddy at XYZ Company, you are in big trouble. It should be obvious that 100 five-minute calls represent exactly the same number of Erlangs or CCS as 1000 thirty-second calls, but only one tenth the load on the central control.

So maybe we should try to define a new Call Unit (CU) as a standard, basing it on what the customer experiences in placing a call. One basic requirement of a CU would be to have a logical easy way to relate it to easily obtained numbers, such as those on telephone bills, or the features available on modern PBXs. A valid measure of control activity, independent of hardware, could be used in RFP specifications and as a basis for comparison between PBX systems.

A CU might be defined (we'll refine it later) as the steps needed o establish and take down a simple intra-switch telephone call. They include the ability to:

• Detect seizure.

• Return dial tone.

• Collect digits.

• Test called line for busy.

• Apply ringing and audible ring.

• Detect answer.

• Make the talking connection.

• Take down the connection when the call is over.

Some Old Familiar Problems

If a CU could be related to the real world calls recorded on phone bills and traffic printouts, we would have a good specification for common control power. But a few problems have to be considered.

First, control activity is usually required on a per-digit basis. The PBX wrests the digit away from the caller and places it in a location in memory. As a result, a three-digit intra-PBX call will not require as much effort as an outside call where seven, eleven or more digits are required, and the PBX has to find an idle CO trunk, detect dial tone or the equivalent, and then outpulse the dialed number into the connecting system. Billing information must also be collected on outside calls, but is seldom available for intra-PBX calls.

Second, some routing algorithms are relatively complex and require more effort from the control than others. If you only have local CO trunks for all outgoing calls, the processor need not identify which of the several trunk groups you are permitted to use and how the number you dialed has to be modified before outpulsing to the connected switch.

Third, standard traffic analysis breaks down if calls are NOT originated at random;. what happens when traffic patterns aren’t random? If an 800 number is thrown on TV screens all over the country and callers are invited to call in before the supply of kumquat squeezers is all gone, peak call activity will approach that of post time at our race track.

More Than Calls

In addition to call handling, most modern PBXs offer thousands of features that can be activated by a switch-hook flash from a 2500 type telephone, or a feature button on an electronic phone. The conventional phone requires a matrix connection to a DTMF detector; if there aren't enough DTMF detectors, there is a delay for dial tone until one becomes available. Then the user has to dial a two or three digit code to tell the system what is wanted. It may be that another person is to be added on, an incoming call is to replace or perhaps alternate with the original call, or whatever. Each operation requires the control to manipulate the switching matrix and the appropriate ports to bring about the desired results. That is, many feature activations within an existing call require the same amount of call set-up effort as establishing an entirely new call.

Calls As Features

Features are important for selling PBXs, but the ability of work groups to manipulate sequences of telephone calls is more useful in day-to-day work. For instance, most conference calls are set up by "bridging";  is, you join me in a call to Chicago by pushing down my line button on your set. As another example, many executives expect their secretaries to set up their calls for them, and most expect secretaries to screen incoming calls. To see what is involved here, let's examine screening. When a call arrives, the secretary answers, puts the call on hold, uses the intercom to announce the call to the principal, and then has the switch connect the call to the principal, perhaps with the secretary bridged on to take notes.

In the days of 1A2 key equipment, the PBX dealt with the screening situation as just one call, which appeared on the phones of the principal and the secretary in parallel. After the call was screened, the hold operation was a function of the KTU, not the PBX, as was the intercom connection. When the principal picked up was no concern of the PBX. Today, hold is a PBX function. Intercom, both signaling and connection, is a second PBX telephone call. Connecting the principal to the calling party is yet another connection through the switching matrix.

How Modern Telephone Sets Interact

With a modern electronic telephone set, control information need not be routed via the switching matrix to a DTMF detector, and then from the detector to the common control. In most PBXs today, there is a signaling channel, like the D-channel in the future ISDN, which takes information to the control by a completely separate data path. If dial tone is returned at all, it is purely cosmetic because the customer expects to hear it. It does not come from one of a limited number of DTMF receivers but, rather, from a matrix time slot to which any number of callers can connect at the same time.

Some ISDN plans call for dial tone to be generated in the set, and activated by a D-channel signal, just as line or feature lamps or alphanumeric characters are activated on electronic PBX phones today. Clearly, this will greatly reduce the number of connections per call that have to be set up through the matrix, as well as the quantity and type of common equipment needed. If a busy or ATB condition is encountered, the appropriate tone can be gated on just as dial tone was, and no matrix manipulation of any sort will be required. After all, it is sort of silly to waste time and effort, either within the PBX or throughout the whole public network, to set up a connection to a tone that tells the caller the connection he wants cannot be delivered. To put it another way, why should a private or public network be tied up between New York and Los Angeles so that the New York caller can hear LA busy tone?

Although there are obvious advantages in not returning call progress tones from the far end of a long distance connection, it is evident that the ability to generate all possible call progress tones, including those not yet devised, within the set might well be overkill. Becuase recorded and synthesized announcements are replacing many tones, it seems likely that the serving switch, whether a PBX or CO, will always have to have the ability to return some call progress signals and, as a result, will have to use the switching matrix on a certain number of unsuccessful calls.  

Activating any feature by pushing a button on a modern telephone set is purely a symbolic function. That is, no matter what button 12 has on its label, all you tell the system is that your button 12 has been pushed. Then the control has to go to its data base to see what you have on button 12 so that it can decide what to do for you. Lighting the lamp associated with the button, or providing alphanumeric characters to an LCD display also comes from the central data base, based on how your particular telephone set is arranged.

Levels Of Control

Most modern PBXs have three levels where control signals are handled. First, there is the per-line level, where supervision and signaling information from the set is captured and stored, and where control information is stored prior to sending it back to the set. Then there is something on approximately the shelf or cabinet level that gathers up all the local incoming information from a number of lines and sends it to the central processor, as well as the inverse. Finally, at the central processor level, the information is interpreted and acted upon in terms of the system data base, an outgrowth of the original class-of-service concept.

The central data base must know, in particular, what extension number or identifying number for a trunk or service circuit is associated with each physical port on the system. At that memory location, one can add additional information, such as regularly updated busy-idle status, the information required to define all the programmable feature/line keys on the set, and the list of other features which might be accessed in ways other than through a feature key.

To make this all the more complex, extension numbers may appear on several different sets, and each set may have access to several extension numbers. How one relates set, number, and group for the best results is still a matter of debate. Then, there are hunt groups, pick-up groups and intercom groups that further relate several different telephones and the lines thereon. Interpreting such stored information in terms signaling from the customer, and manipulating audible and visible indicators at the set while reconfiguring connections through the switch are the main function of the central processor.

Clearly, the several levels of front end processors can make life a lot easier for the central processor. Thus two switches with the same central processor might have very different call handling capabilities, depending on how much they are deloaded by their front end processors. By adding front end processors in proportion to the added ports, as when there are processors per circuit card and per line group, the system can grow to a much larger size than if the central processor had to handle all the lower level details.

There are various schemes for having several controls running in parallel, sharing the load (i.e. NEAX 2400 and Tariran Coral). Finally, there are several systems that are constructed of modular building blocks, each with enough processor power to handle its own calls (Rolm-IBM-Siemens multi-module 9751, Redcom, Ericsson MD-110). Evidently, these system can provide so much processor power per module, up to their maximum size. Somehow we must be able to define the processor load in an RFP so that the response we get will be meaningful, independent of such variations in system architecture.

Background Processing, Maintenance And Routining.

In a modern switching system, call processing is only one of the functions of the common control. In general, is is always running checks on itself, the switching matrix and service circuits. It also collects and buffers traffic and CDR information. During call set up, it can activate time-outs to make sure various processes are functioning and, if the designers have been really on the ball, it can use such timeouts, test calls, and transmission measurements to detect problems in connecting systems.

Obviously, this background work takes up, on the average, a certain amount of the time available to the central control. But when call processing increases, as during a busy hour, some of the background activities can be reduced. Many diagnostic programs can be delayed with no ill effects, but some systems cancel the collection of traffic information just when you need that information most: during peaks of call processing activity. This sort of ingenious design should be rejected out of hand.

Evidently, a specification that defines the call activity the system can handle should indicate what routine functions are deferred or omitted as one approaches peak load, or how much call activity can be handled without omitting background operations. Some common controls include associated but independent processors just to handle such background functions as collecting traffic and CDR data, presenting trouble flags and printouts, and carrying out other necessary administrative functions.

Refining The CU Definition

PBX manufacturers describe their controls in terms of call attempts, calls, or call completions, depending on which vendor you talk to. Northern Telecom points to its busy hour calls, AT&T talks about busy hour call completions, and almost everyone else is concerned with busy hour call attempts. Because the manufacturers interpret the meanings of these terms according to proprietary procedures, it is very nearly impossible to know if a given system can meet your needs.

To illustrate the problem, and to suggest to the industry a means of creating a solution, I have worked out a series of Call Units for different types of call handling, as shown in Table 1. These CUs are based on what seems reasonable and are intended for illustration only. What is needed is for the entire industry to get together to establish real standards so that an RFP can elicit meaningful information about different systems with differing architectures.

My basic CU is the control activity required to set up a call from one phone to another, and then take down the connection when the call is finished. But for the basic CU, I assume modern electronic telephones with separate signaling channels and built-in tone ringing. Whatever this activity is, call it 1.0 CU. If the called party is busy, everything is the same until the busy test is made; then hang-up follows busy tone rather than conversation; call such an attempt 0.8 CU. On this scale, a “call attempt” consisting of only picking up the phone and returning it to its cradle, as AT&T attributes to others, would make a call attempt worth no more than 0.4 CU.

A successful call established between 2500 "POTS" type telephones is assumed to take 1.2 CUs, simply because it requires first a matrix connection to a DTMF receiver, then a ringing/ringback connection, and finally a talking connection. Electronic phones only require only the talking connection.

This is the first part of the job. When the call is answered by a screening secretary, an additional Secretary-Principal (S-P) connection is required to announce the call, and then the call must be connected to the Principal. Thus we have to add about 1.8 CU. Similarly, if calls are placed by a secretary, we have a P-S connection to order the call, the call itself, an S-P connection to announce the outgoing call, and then a P to trunk connection. Add two more CUs. See Table 1a.

Outgoing calls need only choose one trunk out of many rather than a particular extension, and they have to spill forward the called number to the connecting switch. ARS and Call-back Queuing impose additional call set-up requirements. Table 1b shows my guess at the required CUs.

Incoming calls are simpler with DID than via a console, because the console requires a trunk-console connection, which must then be replaced by a trunk-callED or trunk-secretary connection. Various incoming CUs are suggested in Table 1c.

To complete the picture, we would have to take each feature, such as conference, transfer, pickup, activating forwarding or coverage, along with other chores like collecting CDR information (all calls or just toll calls?), define them in terms of the basic CU, and relate them to calls in progress. But we can leave that to the pros.

An Example

As shown in Table 2, we are planning a 500 line PBX with 100 electronic stations and 400 conventional single line analog phones (bah, humbug). We assume that each phone will make one intra-PBX call during the busy hour, one outgoing call, and receive one incoming call. If these are three minute calls, and we assume each phone will, of necessity, have to terminate one intra-PBX call on the average during the busy hour, we find each phone is busy 12 minutes out of the hour. This is 7.2 CCS per phone, a bit more than is often assumed, but obviously in the right ball park.

We could check our assumptions further, of course, by comparing these calls with calls from the phone bill. However, phone bills show only the calls we pay for, which usually eliminates incoming calls and always eliminates intra-PBX calls. So what we do is take the outgoing calls only, multiply them by 6, the rule of thumb that relates busy hour calls to calls per day, and then multiply again by 22, the average number of business days per month. If, in our example, we generate a total of 500 local and long distance outgoing calls per busy hour, we can expect about 3000 calls per day and 66,000 calls per month; for many businesses, most will be local.

In actual practice we would, of course, go the other way. Take the total outgoing calls on the bill, divide by 132 to get outgoing calls per busy hour, and assume the same number of incoming and intra-PBX calls. We might have good reason to decide that electronic phones make more calls per hour than POTS phones, or vice versa.

Playing with our three 3-minute calls per line per hour (being careful not to count intra-PBX calls twice), we see that our assumptions for 500 phones lead to 75 Erlangs, or 75 calls in progress, on the average. Again, this is something that checks pretty well with modern PBX design where typically we have 128 or 256 paths through the matrix in this size range. With the matrix capability under control, we now turn to the main problem: processor load for what appears to be 1500 busy hour call completions.

From Table 1, it is evident that 1500 calls completed through the system in the busy hour is not the number we are looking for. Table 3 shows how we can use Table 1 to convert actual calls to something more like processor activity. Let us assume, to simplify the arithmetic, that all calls involving electronic sets use secretarial screening, none of the calls involving 2500 sets uses screening, and that everybody places his or her own calls. All incoming calls come via a console, the client not wanting DID for various reasons. Outgoing calls from electronic sets can overflow to toll, and thus only hit busy 5% of the time. Outgoing calls from 2500 sets do not overflow to toll, encounter busy 20% of the time, and then use call-back queuing; delayed calls are included below with unsuccessful calls (see table 3b).

Fig. 3a shows the number of successful calls (neither blocked nor delayed) for each type of phone in each of the three call categories. Below is the CU number for a call of that type, and finally, we multiply to get the total number of CUs. Add the CUs across for each of the two types of telephone, and then add these sums. Here we get 2550 CU.

In this simple example, we will ignore the contribution of additional feature operations not already implicit in the above operations, and move ahead to unsuccessful attempts. Our basic assumptions lead to each telephone being busy for 12 minutes out of the hour, or 20% of the time. This says that 20% of all intra-PBX and incoming calls will hit busy. Thus these two categories will each average 20 unsuccessful calls in addition to the calls we know about.

Turning to outgoing calls, only about 5% from the electronic phones will not make it because they can overflow to toll; these will require about the same effort as an intra-PBX call hitting busy. We must also add in the 20% of calls ultimately successful but delayed calls from the 2500 sets, completed via call-back queuing.

The total comes to 458 CU, about 18% of the work required by successful calls. The total number of CUs, 3008, is about twice what we might have expected from simply counting known call completions.

The CU number for unsuccessful or delayed calls is relatively small, as might be expected at the level for which the system is designed. However, under overload conditions, where the matrix, trunks and busy extensions limit the possible number of call completions, the number of CUs created by user frustration can escalate into something formidable.

There is one further point. Almost never would we install a PBX at the maximum size, in terms of lines and trunks, it can support. We would have to allow for growth. If we selected a PBX that could support a maximum of 1000 extensions, it would still have the same common control; if traffic could be extrapolated linearly, about 6000 CUs would be the rating the processor should have. This is the number that is roughly comparable to what vendors currently call busy-hour call attempts.

If the system were capable of growing to 10,000 lines, it would need to handle 60,000 CUs. As a practical matter, we can probably expect the average calling rate per phone to decline somewhat as the system grows in size, but we have to allow for system growth as part of processor evaluation.

Conclusions

As this demonstration suggests, present methods of defining processor load needed for the PBX in our RFP leave something to be desired. Further, calls, call attempts and call completions, as presently used, seem to be related to the world of 1A2 key systems, and may simply omit a large amount of activity the central control will actually encounter. To complicate the matter, all manufacturers produce specifications based on proprietary interpretations of undefined raw data.

Until the industry can resolve this situation, our best bet is to count the calls that we can identify via local and toll billing, triple it to allow for incoming and intra-PBX calls, and then, multiply the whole thing by about 2.5 to get something like the number of CUs needed at cutover. Scale that number by the ratio of maximum extensions to extensions at cutover, and we have a number to compare with the one from the vendor, no matter what the vendor calls it.

In our example, we might have assumed that 3000 busy hour call completions would have been more than enough to handle the 1500 calls we can account for from outside sources. But a slight overload, exacerbated by retries made easy by last number redial, can easily drive the central control out of its head. If that is the case at cutover, what can we expect three or four years down the line after various additions have been made?

The alternative is to stick to the very nearly meaningless specifications we use today, with the danger of running into a system overload when we least expect it. As ACD, voice mail, and short holding time data bursts from messaging and point of sale systems develop, processor power is the one thing we cannot afford to run out of.

[ Top ] [ Next Chapter ] [ Table of Contents ]

Copyright 2006 Lee Goeller. All Rights Reserved.