Goeller on Telecom Traffic

BASIC Programs for Traffic Calculation

(Business Communications Review, May-June 1979)

(Webmaster's Note: The figures and code listings mentioned in this article are linked in separate graphic files, so that they can be printed in large enough format to be read easily.)

Technology affects us in ways we seldom even suspect. I have found, for instance, that many things I believed to be basic to electrical engineering turn out, on closer examination, to be gimmicks to facilitate computation of results with a slide rule. In the age of the hand-held programmable calculator, these cherished principles turn out to be nonsense. In a more general way, such subjects as trigonometry and logarithms, long the bane of high school mathematics, must be thought of in completely different terms when the touch of a button provides the correct number, and paper tables no longer need to be used.

In my high school days, the main thing I learned with trig and logs was how to interpolate in tables. Exercises of this sort must have taken up half the course time, and the difficulty of getting the right answer submerged both the mathematical principles involved and the grades of those who, like myself, had trouble just doing the arithmetic. Interpolation is basically evil. I felt at the time that it should be stamped out. Now I am going to strike a blow in that very direction. Join my crusade. You'll like it!

We won't bother with simple functions already handled on pocket calculators, however. We'll go to the much more interesting functions needed in telephone traffic calculations. Now that you can buy a respectable microprocessor- based computer with a video display terminal (VDT) for something less than $1,000, it is easier to calculate almost any traffic value you want faster than you can look it up. And you never need to interpolate. If the idea of programming a computer scares you, relax. The BASIC language is so simple that even I managed to learn it in something under an hour, and BASIC is fast becoming the standard small-computer language. We will not concern ourselves with BASIC itself in this article; we'll simply use BASIC to compose our programs.

The Basic Traffic Formulas

Figure 1 shows the "big three," the most commonly used traffic formulas: Erlang B, Erlang C, and Poisson. Study of the figure, even by non-mathematicians, shows a striking similarity from one formula to the next. In addition to being complicated enough to defy easy calculation, the formulas abound with terms such as A raised to the Mth power divided by N factorial. A, in all these formulas, is offered traffic in Erlangs (or hours of use per busy hour) and N is the numer of servers (usually trunks). P is used here as the probability of N trunks being busy. In Erlang B, this is the probability of blocking; in Erlang C, it is the probability of delay. In Poisson, it gets more complicated as we will see.

"Downstairs" in each equation (in the denominator, as you may recall from your school days), we find a bunch of terms to be ad- ded up. Each term is generated from the one to its left by multiplying by A and dividing by N.

(N! is read "N factorial" and means TV times N-l times N-2 and so on down to 1. For exam- ple, 6! is 6x5x4x3x2x1 = 720.) This will be useful in writing our programs. But there may be quite a few terms. The series of dots signifies all the terms left out. In the Poisson formula, the denominator ends with a series of dots. This is shorthand for an infinitely long series of terms. Fortunately, we won't have to add up an infinite number of terms. This takes quite a while, even with a computer. We will simply make use of a mathematical formula that I once saw proved in college that says the sum of an infinite series of the form shown is 2.71828 raised to the Ath power. 2.71828 or "e" is the basis of natural logarithms if anybody cares, but most BASIC programming systems get the answer with a function of the form E=EXP(A).

In any event, Erlang B and Erlang C differ only in the last term, which is also used "upstairs" (as the numerator). There is an extra multiplier in Erlang C. This is the factor that allows a call to wait in line until a trunk comes free and then use the trunk for a full holding time. In Erlang B, a call finding all trunks busy vanishes. The difference in the formulas seems quite small. The Poisson formula uses the same numerator as Erlang B; the denominator, however, does not stop at the Nth term, but goes on forever. Just to make things interesting, the Poisson formula, to be used in its traditional role, includes another summation. To find the probability of Poisson blocking, we have to find the probability that all N trunks are busy, plus the probability that the next trunk, if available, would also be busy, plus the probability that the next one, too, would be busy, etc.

This all sounds complicated, but we'll find easy ways to calculate the numbers we need. The computer is going to do all the work once we get the program written. If we know what the program has to do, the battle is half won. And once we have the program available, we never need to do any work in that particular area again. We will just tell the system the traffic offered, and it will give us the probability of blocking or delay with no interpolations or other problems.

Programming Erlang B

Erlang B is the easiest program to write, so we'll start with it. Figure 2 is a program listing, and it is seen to be quite short. Note, however, the colon ":" The colon lets us write a number of statements on one line in the particular system I use (Helios BASIC). With a small number of lines, an entire program can often be shown complete on the screen of a VDT. Without the colon, a number of very short statements would require more lines than a screen can hold at one time. If your system does not have something like the colon, give each statement a number. Line 40 would become lines 40, 42, 44, 46 and 48. Line 40 in Figure 2 initializes the system so that calculations can begin. The meaning of each term will be explained as we progress.

Line 50 tells the system to print out the headings for the columns of data that are about to spew forth. The spacing is arranged to come out right. You may have to fiddle around with it in your particular system, but getting the headings to line up with the columns isn't much trouble.

Line 60, which is composed of four statements, calculates the probability of blocking in several steps. Since the machine is going to provide information for many trunks each time we give it an offered traffic value, we start off by deciding the number of trunks, N, for this particular pass. N is initialized (in line 40) as 0, so the first time around it will become 1. In each succeeding pass, it will be increased to the next higher whole number. The next thing we do is make a term named T by multiplying the value of T we already have by A, the offered traffic, and dividing by N which we have just calculated. T, of course, is initialized as 1. We then make another term named TI, by adding T to the Tl we already have. Tl is initialized as 1, and grows rapidly. In any event, T can be seen to be the last term in the denominator of the Erlang B equation in Figure 1, and the total numerator. Tl is the sum of all the terms in the denominator including the present value of T. It is now easy to calculate P, the grade of service (G/S in the printout). We just divide T by Tl.

Note that the probability of blocking with Erlang B says exactly N trunks are busy. If fewer than N are busy, a new call will find an outgoing channel. If all N are busy and one or more new calls come in, the new calls vanish. Thus all we have to calculate is the probability that exactly N trunks are in use.

We want a few other items as well, however, and that is what line 70 does for us. We know A, the traffic offered the entire trunk group. We want to know O, the traffic offered each trunk (under the assumption the systems hunts from left to right); L, the traffic lost from each trunk and, consequently offered to the next; C, the traffic carried by each trunk; and S, the sum of the traffic carried on all the trunks examined so far. For the first trunk. O=A, since the traffic offered the group is the traffic offered to the first trunk. We won't adjust O until line 90. Be sure not to confuse O (for offered) with the number zero (0).

Once we have calculated P for N trunks, we can easily find the other things we need. Lost traffic L is equal to the offered traffic multiplied by the probability of blocking, P. The sum of the traffic carried on all N trunks can be calculated many ways; I chose to take L from A. The traffic carried on each trunk is the traffic offered that trunk, O, minus the traffic lost from that trunk, L.

Line 80 prints all this out. In my system, the answer has to be formatted to make it look attractive. N is set up as a 3 digit integer, O requires 9 spaces with 4 digits after the decimal. C is similar but needs only 6 spaces, S needs 8 and P again needs 6.

Lines 90 and 91 take us around for the next trunk and also brings the whole process to a screeching halt when P gets so small that we know we have more than enough trunks for any reasonable application. In conjunction with line 100, however, we do one more thing. When a VDT is used rather than a machine that prints results on paper, we have to have some means for displaying our information once we have it. Before I put in the business with Z, I ran the pro- gram for a large offering of traffic and found the information flashing across my screen about ten times faster than I could read it. When the thing finally came to rest, only the last ten or twelve trunks showed and all the rest of the data had been lost.

With the parameter Z, we stop the calculate-and-print routine every ten lines. If we wish to see the next ten, we type CONT and the system again springs into action. There is an instruction in Line 100 to print out the traffic offered the entire group so we don't forget where we started when we get to trunk 35 or 46, and of course we reprint the column headings for each screen full of information. Figure 3 shows a sample print- out for A = 10 Erlangs.

Programming Erlang C

Turning now to Figure 4, we are in a position to deal with Erlang C and queuing very quickly. Line 20 inputs the traffic (in Erlangs) offered the group, and Lines 30 and 31 print the column headings. P, of course, is the probability that a call will be delayed. Dl and D2 are the average delays (measured in terms of average holding times) on all calls, and only those calls which are delayed, respectively. Ql and Q2 are the average number of customers in the queue; Ql is the overall average, while Q2 is the average number in queue only when all servers are busy. P3, P4, P2, P1 and PP are the probabilities that the delay will be longer than an eighth, quarter, half, one and two holding times respectively.

Line 40 initializes as in Figure 2. Line 50, however, is something new. In Erlang B, we have "lost calls cleared," and traffic vanishes when it finds all trunks busy. In Erlang C, traffic stays in the queue and waits for a server. Thus, if six hours of traffic are offered during a busy hour, all six hours must be carried off. This says we need a minimum of six trunks, and there is no point in printing out any traffic values for a smaller number since we will get negative pro- babilities which are meaningless. Thus, we re- quire N, the number of trunks, to be greater than the number of hours of traffic offered in the busy hour. For A greater than N, we print out nothing.

As long as A is greater than N, Line 50 flips us to line 120 where we calculate terms in the denominator and increase N. When N is larger than A, we go on to Line 60 where P is calculated. T2 is both the numerator and the last term in the denominator, and P is T2 divided by the sum of T2 and T1. T1 is the sum of the other terms in the denominator and is calculated in Line 120. T, of course, is one of the terms that makes up T1. Note that T2 has to be kept separate from T1 and T since T1 must be developed without it.

Line 70 calculates Dl, D2, Q1 and Q2 but not in that order since each one can be used to simplify the calculation of another. Lines 80 through 91 calculate P8 through PP. Since PP is not a valid variable name in my version of BASIC, and I needed a heading that signified two holding times, PP is calculated as P0.

Line 100 formats and prints the desired values for a given number of trunks, and 110 stops festivities when P becomes small enough. We don't need to worry about overfilling the screen with Erlang C, since we seldom need N to be greater than A by more than 10 or 12 trunks. In systems of 100 trunks or more, there would be little point in using queuing because occupancy couldn't be improved much anyhow. Figure 5 gives a sample printout for Erlang C.

Programming Poisson

Figure 6 shows the Poisson formula's program, and in some ways it is quite different from those we've already studied. As can be seen in the sample printout (Figure 7), we get P, the probability of exactly N trunks being busy, plus P1, the conventional Poisson blocking probability of a group of N trunks. We can go on, as with Erlang B, to groups of as large a size as we like, ten trunks at a time.

After inputting the offered traffic in Erlangs in Line 40, we immediately calculate the denominator for all terms using the EXP function mentioned earlier. Line 50 then sets up the initial conditions.

Calculating the probability of blocking is a little tricky. The formula given in Figure 1 is the probability that exactly N trunks are busy, given A Erlangs of offered traffic. Under the "lost calls held" assumption of Poisson, the probability of finding, say, a ten-trunk trunk group busy is the probability that 10 or 11 or 12 or 13 or 14 and so on are busy. That is, we assume calls stay in the system for one holding time whether they are served or not; then we assume that an infinite number of parking places is available, and we calculate the probability that N or more trunks or parking places are occupied. This summation to infinity, particularly when higher numbered parking places have a very low probability of use, is a bother. Since we will be developing a probability of blocking for a range of trunks from 1 to N, there is a better way.

The probability that some number (including 0) of trunks is busy is 1. This is the sum of the probabilities of all possible numbers. 1 is a sure thing. Now, suppose we have a group consisting of exactly 1 trunk. The probability that it is busy is 1 minus the probability that no trunk is busy. If we had two trunks in the group, the probability that we hit busy is 1 minus the probability that exactly none plus exactly 1 trunk is busy. For three trunks, we take 1 minus the probability that 0, 1 and 2 are busy. We could calculate the probability that 3, 4, 5, 6, 7 and so on to infinity are busy, but it is easier to take off the other end.

In any event, line 60 calculates P, the probability that exactly N trunks are busy, and P1, the probability that a group of N is busy, assuming traffic offered the group is A Erlangs. We start out with N = 0, find the probability that exactly no traffic is in the system (1/E) and the probability that traffic offered to a no-trunk trunk group will be blocked (1, or a sure thing). We calculate all this with the help of Line 120 where we calculate T, the term we have been using in Erlang B and C, A raised to the Nth power and divided by N factorial. We then form T1 by adding T to the sum of the previously found values of T. We also use Line 120 to increase N to the next required value. Line 130 checks to make sure P1 is big enough to be of interest and then returns us to Line 60. In Line 60, P is calculated as T divided by E, which is the same formula as is shown in Figure 1. T2 is the sum of the probabilities that 0 or 1 or 2 or 3, etc., up to N-1 trunks are busy, and P1 is 1 minus T2. Note that E can be a very large number when A is large, so we always construct our T and T1 terms separately and then divide by E. If we didn't do this, we could get an "underflow" in which the computer thinks that a very small number is actually 0.

In Line 70, we exclude the printing of values of P that are too small to matter and the associated values of P1 that are too close to 1 (certainty) to be useful. This occurs when large values of A are offered; for small values of A, we will see the entire table starting with N = 0. When we are actually going to print, Line 80 tells the system what is to be recorded, while Lines 90 and 91 stop the revelation every ten lines to permit it to be read. Line 100 reminds us of the total traffic offered the group, in case we forget in large traffic offerings. Line 110 works with Line 70 to keep the program working up through the first several sets of 10 trunks when A is large and no printout is desired.

Summary

I have been using these programs for several months in various earlier forms, and they run nicely on my computer and check with tables. Further, I have had some of them running on my HP-55 programmable calculator, but since the computer moved in, there has been no comparison. The speed of calculation and the utility of a VDT display can hardly be appreciated until one tries to go back to the calculator.

One can even perform experiments in traffic theory. As shown in Figure 8, I have run Erlang C for 9. then 9.5 and then 9.9 Erlangs of traffic. It is fascinating to watch the Ds and the Qs for 10 trunks go through the ceiling. In the real world, it is obvious that traffic in Erlangs sometimes really does go beyond the number of trunks available instead of approaching it on the small side. Then we get increasing queues, dropouts, very long waits, and other problems that  simply do not show in the mathematics. Math, compared to reality, always has its limitations.  Its advantages, however, are quite useful as long as we understand what we are doing.

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

Copyright 2006 Lee Goeller. All Rights Reserved.