Goeller on Telecom Traffic

A First Course in
Telephone Traffic Engineering

If we have just one business location, we only need a single-node network. The alternative is a multi-node or point-to-point network, where several PBXs or other switches are tied together with tie-trunks. We will look at tie-trunk networks later.

The first thing we have to do when we consider network design is to obtain some facts. We need to know how much traffic we have to carry, and where it goes. Obtaining this information is fairly straight-forward, but it takes time and effort. If we have no WATS lines, FX lines, Specialized or Resale Carriers, or whatever, and start from scratch, we have two advantages.

First, almost anything we do is going to save money and make us look good. And second, with all the long distance traffic presently going toll, we can use the bills from the telephone company as the source of our design information. The best way to proceed is to make arrangements with the telco to get the bills for the next several months in machine-readable form (preferably on computer tape) and have them sorted by destination. There are many consulting and software firms that specialize in this sort of work, and you can get good data almost immediately, and at a relatively low cost.

Note that the telephone company makes your copy of the tape at the same time it prints your paper bill, so you have to ask for data in advance. You cannot ask them for a tape of last December's bill, for instance, but you can get one for month after next. This service is not free; the telco will charge you for the information (and expect you to return the tape), and the company that does the processing will also charge you, but the results you get will be well worth the modest cost. You can, of course, key-punch the entire paper bill, write your own programs, and have your corporate EDP center do the processing. But, even though most of the programs are relatively simple sorts, companies that have been in the field for 10 or 15 years have developed some very sophisticated programs and charged them off over several hundred clients. There is no point in trying to re-invent the wheel.

A good computer run will sort calls by called number, with one line for each number called, and the numbers in order from Area Code 201 to 919. Typically, number of calls, number of minutes and total cost are provided. The next step in the sort is to accumulate by Central Office code; next, by area code. Because many states have several area codes, a sort by states is also helpful; the most important state, however, is the one in which your office is located. IntRA-state rates are often much higher than intER-state rates and, in general, most companies do more intra-state calling than inter-state. Finally, a sort is made by WATS Service Area (Service Areas used to be called Bands).

There is one more sort that is quite useful: sort by called city. There are many central offices in New York, Chicago, Los Angeles, and even smaller cities such as Columbus, Ohio or Richmond, Virginia. Further, there is no particular numerical sequence of central office number codes that allows you to know where a particular CO is. If you have the bill, the computer doing the sort can look just as easily at a city name as at a number, and can summarize calls by destination city. If you have a built-in toll recording system, city names are not usually included in the record. However, it is possible to obtain tapes that relate office codes within area codes to city names, sometimes using the "V & H" coordinates used to calculate intercity distances. City name is added during the processing, and sorting thereon can then be carried out.

Because computers like doing dull work, you will usually find printouts including average cost per call, average duration per call, etc., in each report. This information can be very helpful in many ways. Another thing a computer can do is find the most called telephone numbers, central offices, cities, area codes, and WATS service areas. If we know the number of calls, minutes and dollars, we can start our network design right away.

Note that our telephone bill is for a whole month, and our programs so far are for the busy hour. Well, some of the better reports are sorted by hour of the day and day of the month, and provide suitable subtotals in each category. This kind of data can help us find our busy hours directly. And we can always use our magic number, 132, to divide monthly traffic to find an approximation to busy hour traffic. However, direct measurements are usually preferable even to good rule-of-thumb estimates.

Let us suppose that we have an old fashioned, dumb PBX that cannot route calls to cities served by specialized carriers. We find, upon looking at our data, that the toll traffic we are pumping into WATS service areas 3, 4 and 5 amounts to about 400 hours per month for about $12,000. We should be able to save some money by using WATS lines.

Well, since we don't have automatic route selection, we are going to have to give our users information on how to dial. To get them to cooperate, we will (a) have to make the dialing instructions very simple, and (b) put in some sort of restrictor (probably a unit external to the PBX in this instance) to physically prevent them from doing things wrong. Then we decide to have only one group of Service Area 5 WATS lines, and let it handle all traffic going beyond about 430 miles. We draw a circle with a 430-mile radius around our location, note the area codes outside and inside the circle, and set our restrictor accordingly. The Dial 9 group will get all the traffic inside the circle, and the Dial 8 group will get all the traffic outside the circle (except for calls to 800 numbers, numbers with 555 for an office code, etc.).

How did we arrive at the 430-mile figure? Take a look at Fig. 6-1, which is set up for New York City. Right off, we see that DDD has a rate step at 430 miles. Then, we see that Service Areas 1 and 2 are pretty much inside the circle, while Service Areas 3, 4 and 5 are outside. Actually, we'd probably include Ohio and North Carolina in the WATS area. Checking toll costs, we note that, for any reasonable mix of traffic, 5 minute calls between 421 and 3000 miles average to about 50 cents a minute, ranging from 47 cents to 54 cents. If we were working out of Los Angeles, the cost might be a little higher because of the small amount of traffic directed to the Rocky Mountain area.

Fig. 6-1. Setting up a Service Area 5 WATS group for New York

The next question is this: how many trunks to we need? If we divide 400 hours per month by 132, we find our average busy hour traffic will be about 3.03 Erlangs. This is carried traffic, of course. If we glance at Table I in Appendix B, we see that 5 trunks can deal with this traffic quite well, with Grade of Service somewhere between B.1 and B.2. We can verify his by running CARRIED. Assume 55% of our blocked calls retry and 0% overflow to toll, holding time is 5 minutes and we have 5 trunks (Printout 6-1). We see first how busy hour traffic is distributed over the trunks in the group, and on the next screen, we get our busy hour summary. Our grade of service, including retries, is B.166, almost 4 calls retry, and about 3 die. We can refine the design later.

If we could queue, the average delay on all calls would be somewhere in the 30 second range. If we called up ERL-C2, we would get, for 3.03 Erlangs of 5-minute calls offered to 5 trunks, a D1 of 37.1 seconds, and a D2 of 152.28 seconds. Those who have to wait at all are going to average a little over two and a half minutes in queue. Delays are, of course, somewhat longer with only 4 trunks. Printout 6-2 has a lot of information.

At least, we're in the right ball-park. So let's estimate our savings with this configuration. If we carry 400 hours a month on 5 trunks, the average traffic per trunk per month comes out to 80 hours. Cost per minute, either from a Swooping Gull diagram or a run of TAPRD is 33.31 cents a minute. We are saving 50-33.31= 16.69 cents a minute, and for 400 hours this comes to $4005.60. Thus, our toll costs beyond about 430 miles drop from $12,000 to $8,000. This is a saving of 33%. WOW!

Now let's see what happens with one less and one more trunk in our group. Continue with CARRIED, and it asks for a new number of trunks in the group. With 4 trunks, grade of service becomes B.41, with 13.72 calls per busy hour retrying, on the average, and 11.22 quitting. This is a good deal worse than before. But now, let's run with 6 trunks. Grade of service becomes B.07, with 1.42 busy hour recalls and 1.16 quits. This may be better than we need; it all depends on cost.

TAPRD can give us cost when we have 400 hours on 4, 5 and 6 trunks. This implies an average use of 100, 80 and 66.7 hours per trunk, with costs of 31.68, 33.31 and 34.01 cents per minute using daytime rates on Rate Step 18. For an increase in cost of 2.67%, we can improve our grade of service from B.17 to B.07; for a saving of 4.89%, we can go from B.17 to B.41. Is it worth $106 (2.67% of our $4000 Saving) to have a better grade of service? Is saving $196 strong enough motivation to let things go to hell in a hand-basket? These are interesting value-judgments to make. There is no "right" answer. This is why we say, "If you can't stand ambiguity, don't work in traffic."

Let's try one more thing. Let's assume we have to carry a 10% overload and see what happens. Let's run through the sequence again with 3.333 hours of carried traffic per busy hour. Now, for 4, 5 and 6 trunks, CARRIED gives us a G/S of B.54, B.23, and B.09. I would be very tempted to opt for 6 trunks.

We have seen what CARRIED can do for a single group; now, let's return to ERL-C2 and the 4 trunk solution with queuing. We might use a manual queue, even on an old cord board. Running the program with 3.03 Erlangs of 5 minute calls in a busy hour shows that with 4 trunks, a call arriving at random will have a 0.522 probability of going into queue, and a probability of 0.2 of having to wait in queue for 5 minutes or longer. The average delay of those calls that are delayed will be 309 seconds, a little over 5 minutes, but average delay on all calls, including those handled immediately, will be about 2 minutes and 40 seconds. For queuing, this isn't bad service.

If we try an overload of 10%, using 3.333 Erlangs per busy hour, the probability of hitting a queue goes up to almost 66%, and the probability of a delay longer than 5 minutes goes to 34%. D1 and D2 become almost 5 and about 7.5 minutes, respectively. Not too bad. But the only question here is if we can afford the people or equipment to handle the queuing. As we have seen, if we can carry 400 hours on 4 trunks, we can only save a little less than $200 over letting the station users dial at random into 5 trunks. How much queuing can we buy for $200 a month?

In the example we have just worked through, we estimated the busy hour and worked in the hourly context. Further, we left out a refinement that sometimes turns out to be important: overhead, or the non-productive (non-paid) occupancy of facilities while dialing and ringing are taking place, and while aborted calls are occupying facilities on partial dials, ring no answers, or access to busy tone.

Typically, overhead increases the paid use of a facility by about 10%. When we have accurate measurements of paid usage, as with WATS, we must increase our paid traffic by multiplying by 1.10 before we calculate traffic distribution over facilities and grade of service. Then we must divide by 1.10 to return to the paid occupancy that will match our bill. When we get our information from a toll bill, however, we can ignore overhead. As has been mentioned, toll (and many of the specialized carriers) round up to the next whole minute, suggesting that, on the average, the paid duration of a call is half a minute shorter than it appears. Half a minute is 10% of a 5 minute call, so taking paid call holding times from a toll bill actually gives us directly a good approximation to the total holding time, including overhead.

It is not difficult to modify CARRIED to work on a monthly basis and insert overhead time as required. The resulting program, B1-MONTH, does just that, and shows us the monthly offered, carried and total traffic for each trunk in the group; as usual, the first trunk in the group is offered all the traffic, and each succeeding trunk is offered the traffic overflowing from the one before.

Let's try a run, with 400 hours, 10% overhead, 22 business days per month, 6 busy hours equal to a day, and 55% of our overflows retrying while 25% go toll. Calls have a length of 5 minutes, and we have 5 trunks in the group. Looking at the screen or Printout 6-3, we see 517 hours had to be offered so that we could carry a total of 400 hours; grade of service with 5 trunks is seen to be B.23. The first trunk in the group apparently carries a 97.40 hours, while the fifth carries 58.55. The next screen-full of data shows first attempt, recalling and offered traffic, by the hour and for the month, as well as carried traffic, the amount overflowing to toll, and the traffic that quits.

Now, B1-MONTH is a relatively simple program. It assumes all hours are busy hours; it divides by 22*6 (or whatever other numbers you like), corrects for overhead and finds how the busy hour traffic distributes over the trunks. While doing this, it assumes hunting for an idle circuit is always in the same sequential order (rotary, as we used to say in the days of Step-by-Step switching). Then it multiplies the busy-hour traffic per trunk by 132 and corrects for overhead to get back to monthly traffic levels. But B1-MONTH assumes all hours are created equal.

When we actually set up systems of this sort, we run into problems. We find that the estimates of traffic on the first choice trunks are too low, and those on later trunks are too high. This comes about, of course, because of the way side-hour traffic prefers the first choice trunks, a topic we have already considered.

When less traffic is offered per hour, a larger proportion of that traffic will go on the first choice trunks. Thus one approach to cost prediction is to use 8 "average" hours rather than 6 "busy" hours to equal a day. Thus we put in 8 hours per day when asked, rather than 6. Try it now on B1-MONTH, using 5 trunks and all other items the same. We find that the first trunk is supposed to carry 117.25 hours a month rather than 97.40, and the fifth carries 38.91 as opposed to 58.55. Grade of service is now B.09, which we know to be unrealistic for the busy hour, but the distribution of traffic over the five trunks for the whole month will come much closer to actual measurement.

We need an accurate distribution of traffic when we have different priced circuits in the same route. In the old days, we used to pack Full Business Day WATS full, and overflow to Measured Time WATS. Today, we try to pack FX lines full, overflow to specialized carriers, and then overflow to WATS and perhaps DDD. Because we are billed by the month, based on the (average) occupancy of each group, we must have an accurate estimate of traffic so that we can make a good estimate of cost.

We have to know where one trunk group should stop and the next should begin. Do we have one, two or three FX lines before we overflow to MCI? And how many MCI access lines do we need? Ideally, the least used trunk in the first group, as an individual, should cost slightly less per minute than the most used trunk in the second group. Even if our routing equipment actually loads each trunk group uniformly (most of them do), we often have to know how traffic would have been distributed under a sequential hunting arrangement so that we can size our groups. Only with the usage per trunk for the month can we find the cost per minute, and decide where each early choice group ends with an overflow to a later choice.

But grade of service is important, too. It is foolish if not downright dishonest to try to design a network without estimating both cost and grade of service at the same time. Busy vs. average hours per day leave much to be desired.

There are other approaches to the problem. The one I decided to use is a "shaped day," and you can call it up from the disk as "B2-MONTH". B2-MONTH asks the same questions as before, but it uses the information we give it in a different way. It divides the 9-hour window (between 8 and 5, when rates are high) into three parts: where traffic is at 100% of the busy hour rate, where it is at 67%, and where it is at 33%. Then it accumulates the traffic per trunk in each period to get a day's traffic which it then modifies to get the monthly traffic. Thus we get a good estimate of busy hour grade of service and monthly traffic distribution, all at the same time.

One might immediately wonder how many hours are at each traffic level. With a 9-hour window and 1/6 of a day's traffic estimating the busy hour, we assume 3 busy hours, 3 at 2/3 of a busy hour, and 3 at 1/3 of a busy hour. Thus our 9-hour window is filled with the same daily traffic, but distributed more realistically. But suppose we decided that our busy hour was only 11% of the daytime traffic. This implies 9 busy hours per day, or that all hours are busy hours. We then have no side hour traffic. If we assume a busy hour is 1/7 of a day (14.3%), 5 busy hours are implied, with 2 hours at 2/3 and 2 more at 1/3 of the busy hour traffic level. The program can work in the range from 5 to 9 busy hours being equal to a day, (busy hour ranging from 20% to 11.1% of a day's traffic) and adjust accordingly.

To see how it all comes out, run B2-MONTH with the 400 hours we used for B1-MONTH, 10% overhead, 22 days per month, 6 hours per day, etc. Our first screen-full of data tells us that the busy hour grade of service is B.17; we also see how busy hour traffic distributes over the trunks. When the traffic is at 2/3 of the busy hour, grade of service is B.07 as the next screen shows. Finally, at lunch time, 8:15 AM, etc., the next screen shows B.0074. Further, if we have been looking closely, we see that the ratio of traffic on the first trunk to that on the second gets higher as the traffic falls off. Check against Printout 6-4 in Appendix IV.

Continuing to the next screen, we see the first choice trunk handling 123.64 hours, while the fifth trunk gets only 38.44 hours. We can compare this with 117.25 hours and 38.91 that we got from an 8 "average hour" day using B1-MONTH. We also note that we offered less traffic to carry our 400 hours. This, of course, comes from the lack of overflows during side hours when less traffic is offered.

After conducting numerous experiments with different numbers of busy hours, it became apparent to me that the traffic distribution did not change much. Upon reflection, the result is perfectly logical. With a 20% busy hour, we have to have more side hours to fill the day (we cannot have 5 busy hours alone), and the side hour traffic favors the first choice trunks. On the other hand, with an 11.1% busy hour (the whole business day uniform), the lack of side hour traffic is compensated by lower traffic during the busy hours; again, this lower traffic favors first choice trunks. As a result, all other programs on the disk divide the daily window into three equal parts. This matches our basic assumption that one sixth of a day is equal to a busy hour and gives us a slightly conservative grade of service. This tends to compensate to some extent for use of "average" busy hours based on total monthly traffic during a given hour divided by the number of business days per month, and other approaches frequently found in data collection schemes.

Once we obtain the monthly traffic per circuit, we can use TAPRD to find the cost per minute for each WATS line or access line to MCI or SPCC as an individual, as well as the average cost per minute for the group as a whole. Comparing such costs helps us decide when to decide when one group is becoming less economical than the alternatives. Taking the numbers from our run of 400 hours on a group of Rate Step 18 WATS lines, we can produce the following table:

The average cost per minute for the group of 5 is 33.31 cents, and even at 36.97 cents a minute, it is easy to see that a Service Area 5 WATS line is less expensive than toll at the 430-mile level. Whether or not something else may be even less expensive is something that must be determined as network design progresses.

When working with monthly traffic, it is not always obvious how many trunks will be required. Suppose, for instance, we have 1430 hours to deal with; how many trunks do we need? A program that can be helpful in getting into the right ball-park is C-MONTH, a shaped day program where traffic is queued for access so that offered equals carried traffic on the group in question. Run C-MONTH for 1430 hours. C-MONTH will ask for overhead factor (10% in Printout 6-5), business days per month (22), time window (9) and holding time (5). It then prints out parameters for the busy hour, starting at 12 trunks. We see that 12 trunks will not really be enough (D1 of 3475 seconds, almost a hour), but 16 or 17 might not be too bad; probability of hitting ATB is C.146 or C.084. With side hour traffic, on the next two screens, we see that we have no problems.

We have now run the same problem several times, and gotten a number of different "answers." Once again, it is important to remember that we are predicting the future on the basis of the past, and we will get as many different answers as we have sets of assumptions. And, with luck, we will come fairly close to reality if we do things right. If we learn nothing else, however, we must learn to check our results after the network is up and running. If it behaves as we predicted, fine. If it doesn't, we have to check to see if the actual traffic differed, if our assumptions were not appropriate, or of some combination of the two interacted.

One of the things we want to look out for is number of business days in a month: as we saw in connection with Fig. 1-3, this number is found, for any specific month, by starting at the billing date and counting forward to the day before the billing date in the next month, omitting days not worked. We may find as few as 19 and as many as 24 business days; this, alone, can make a difference. Some companies work two shifts; some have busy seasons that peak sharply above the average; some have days in the week or weeks in the month when traffic is very heavy for reasons that are not statistical. Good source data can help locate such trouble spots.

What do you do about them? Well, you have to plan to handle overloads, preferably by letting some calls go toll, or by having other routes available. Dial-up access to specialized carriers is a good back-up for their network services (direct access), and the current pricing of WATS circuits permits a few extra to be used at small reduction in savings. But ANY design must be aware of potential trouble spots, and have a plan for dealing with them without reducing appreciably the savings possible when traffic is more nearly average.

We can never really be sure of the traffic offered, but carried traffic can be measured with some accuracy. If we work with carried traffic, our programs can use standard traffic assumptions to estimate system behavior. We can use CARRIED to design on a busy hour basis, using carried traffic as the input, but, because our data usually comes on a monthly basis, we can use B1-MONTH or B2-MONTH to do the whole problem for us. To approximate the right number of trunks to use, C-MONTH can be run first. Then B2-MONTH, using a shaped day, can see how user traffic will be distributed over the group, allowing for the fact that not all hours are busy hours...that side hour traffic tends to load the first choice trunks more heavily. Cost per minute per trunk or for the group as a whole can easily be found by running TAPRD with data from B2-MONTH.

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

Copyright 2006 Lee Goeller. All Rights Reserved.