Goeller on Telecom Traffic

A First Course in
Telephone Traffic Engineering

While Molina was working with Binomial throwdowns and the evolution of the Poisson formula, Erlang, in Denmark, was attempting a somewhat different approach: the method of "statistical equilibrium." With calls arriving "individually and collectively at random" in a "stationary random process," knowing the arrival rate gave the probability of a call appearing in any given interval of time. If that interval were made short enough, the probability of arrival of two or more calls would be very small and we could think of a single call arriving or not. With regard to calls hanging up, the assumption of exponential holding times made hang-up random with regard to start times (as constant holding times would not). Thus the probability of a call departing the system was related to both the number of calls in the system and the service rate (1 divided by the holding time) as we saw in Chapter 1.

Well, Erlang assumed that a trunk group under study might have any number of calls in progress at any given time. If, for instance, 6 calls were in progress, he figured the probability that a new call might arrive, changing the number present to 7, or an existing call might hang up, reducing the number of calls to 5. He did this for all possible numbers of calls which might be in the system, added them up in a clever way, and produced his almost magic formula. The interested reader can refer to Appendix I for details.

To see how all this works, let's try a simulation. Call up and run SIMU-3. The first thing it asks for is the offered traffic in Erlangs (or hours of use per hour). Remember, this is also the arrival rate: if 14.63 Erlangs of traffic are offered during an hour, during one average holding time, 14.63 calls can be expected to arrive in the system. The next thing the program asks for is call holding time in decimal minutes. If we have data saying people talk for 5.35 minutes, on the average, we know that we can expect, in the long run, 14.63 calls to arrive during each 5.35 minute (5 minutes and 21 seconds) interval, or about 2.73 calls to arrive, on the average, per minute. If we divide by 60, we get the probability of a call arriving in any given second: 0.0456. We could also observe that 5.35 minutes is 321 seconds, and divide 14.63 by 321 to get the same result.

An average holding time of 321 seconds implies a service rate of 1/321, or 0.00312, and this number multiplied by the number of calls present gives the rate at which calls depart. For example, with 15 calls present, calls depart at the rate of 15*0.00312=0.0467 per second.

The program then asks us for the number of trunks in the group, and a number to kick off the random number generator. For the time being, let's have lots of trunks so we have a very low probability of hitting an ATB condition. Use 14.63 Erlangs above, and try 30 trunks. Use any number you like for the random number "seed." The machine now calculates the arrival and departure rates per second. For 14.63 Erlangs and 5.35-minute calls, the probability is one in almost 22, which is the same as .0456. The departure probability is shown to be proportional to N, the number of calls in the system, divided by 321, the holding time in seconds. The simulator is now all set up and ready to go.

Tell the program to continue. What it will do, for each of the 3600 seconds in the hour, is consult the random number generator to see if a call arrived; if so, the calls present counter is incremented by 1. Then, the random number generator decides if a call departed; if such is the case, the "calls present" counter is reduced by 1. Then the system goes on to the next second. In most seconds, no change takes place; we're expecting less than 3 calls per minute and a minute has 60 seconds.

Once a minute, the program then takes a snapshot of the number of calls present in the system, and prints out a display showing which minute we're talking about and the number of calls, plus a bar-graph visual aid. On my computer, it takes a little less than 2 minutes to run through the 3600 seconds in an hour. At the end, as shown in Printout 3-1 in Appendix IV, we see the last 15 minutes, plus a reminder of the calling rate and number of trunks we used. Then, the program summarizes the actual carried traffic, the number of calls, the number of overflows and the grade of service (calculated by dividing the number of overflows by the total number of call attempts). With no overflows, the grade of service is 0.

If we tell the program to continue, it will take up where it left off, and run a second hour. This second hour will have exactly the same parameters as the first but, because of the random number generator, it will have a different number of offered calls and carried traffic (and overflows when we have a smaller number of trunks than in the present run). Run after run will illustrate a very important point: no two busy hours are created equal. They vary, often considerably, even under identical conditions.

Now, let's run SIMU-3 again, and give it all the same parameters except the number of trunks. Let's give it an arrival rate of 14.63, a holding time of 5.35 minutes, but 20 trunks instead of 30. Now, we should get quite a few overflows. But just what is an overflow?

Well, suppose your PBX does not have enough CO trunks and, during the busy hour, you dial 9 and hit an ATB. Your call is an overflow, because it overflows the available facilities. You hang up and perhaps try again later, but for now you are cleared out of the system. This is the basic difference in Erlang B and Poisson. Poisson says you stay in the system for one holding time, which is ok if you are waiting for dial tone, but hardly reasonable if you are listening to overflow or reorder tone. Thus, the "lost calls cleared" assumption is usually the more suitable.

"Lost calls cleared" says, upon hitting busy, your call vanishes. You might hang up, or your super-smart PBX might try another trunk group. But from the standpoint of the trunk group in question, your call vanishes--is cleared out of the system. In our simulator, the calls-in-progress counter checks to see if it has more calls than trunks. If it does, it adds one to the overflow counter, subtracts one away from the calls in progress, and goes on to the next second to try again. We see at once that the maximum number of calls in the system cannot exceed the number of trunks. And several runs will show that the grade of service (overflows divided by total number of attempts) varies widely from run to run.

So far, we have been using offered traffic in our work. But when we get actual measurements, we can never be sure what the offered traffic really was. We know the carried traffic; that is what we can measure. But offered and lost traffic are always approximated. It would be helpful if we could work with carried traffic. As we have seen, we can calculate the traffic actually carried when using Poisson, but Erlang B gives us carried traffic and lost traffic directly. Thus we can use either offered or carried traffic, as suits our fancy. The only problem comes when the offered traffic is much larger than the traffic carried, typical of some kinds of network design. Then accuracy of estimates of offered traffic on the basis of carried traffic tends to leave something to be desired.

The overall Erlang B model is important and easy to understand. It assumes a certain amount of traffic is offered, a portion of that traffic is carried, and the remainder is lost. Grade of service is lost traffic divided by offered traffic. In Erlang B, the proportion of time all trunks are busy is the same as the grade of service; it is that part of the hour when a call, coming in at random, will be lost. In the mathematical calculation, the lost calls cleared assumption says all we have to calculate is the probability that exactly N trunks in a group of N are busy; if fewer are busy, the call is not blocked because at least one trunk is free to carry the call, and if more than N calls try to be present in the system at any one time, the calls in excess of the N trunks will be lost and cleared out of the system.

Contrast this with Poisson, which uses the "lost calls held" assumption. There we assume a call is held in the system for one holding time, whether it is served or not. Thus to calculate the probability that a call arriving at random will find all trunks busy involves not just the N calls being served, but also the several calls that may be waiting.

To use Erlang B, clear the computer and call up ERL-B. Tell the program to run, and it will ask you for the offered traffic in Erlangs. Give it the 14.63 Erlangs we used in SIMU-3. The computer now flings itself into action and prints out ten lines of numbers in five columns, with column headings, as shown in Printout 3-2. The first column is N TKS, the number of the particular trunk we are observing. "OFFRD HRS" is the number of Erlangs offered to each trunk in the group. The first trunk, N=1, is offered all 14.63 Erlangs. The second trunk is offered the traffic lost by the first, and the third trunk is offered the traffic overflowing the second.

"CRD PER TRK" is the the traffic each trunk actually carries. Note that no trunk can carry more than one hour of traffic per hour; 100% occupancy, one Erlang, 36 CCS, or 60 minutes is all there is. Further, the less traffic a trunk is offered, the less traffic it carries. As we go down the column, the traffic carried per trunk becomes less and less. The TOT CRD, or total traffic carried on the trunk in question and all trunks preceding it, however, accumulates. Thus the first five trunks carry 4.590 Erlangs, or hours of use; we read this in the fourth column, opposite N=5.

The fifth and last column, "GRADE OF SVC" for Grade of Service, divides the lost traffic by the offered traffic. Lost traffic, of course, is the traffic offered to the next trunk when there is no next trunk. The traffic lost by a group of 7 trunks offered 14.63 Erlangs will be 8.292 Erlangs. The grade of service will be B.567, and more than half the time a call, arriving at random, will find ATB and be lost. This is a lousy grade of service, but if we overflow to another group, it may be just what we want. We'll return to this idea in a later chapter.

Tell the program to continue, and we see the disposition of traffic on the trunks from N=11 to N=20. With 20 trunks, our grade of service is B.039; thus about 4% of the time a new call will hit ATB. One more screen takes us down to 28 trunks where the program quits; it assumes you don't want anything better that B.001 service.

Let's review what ERL-B does for us. It takes the offered traffic, in Erlangs, and calculates the offered and carried traffic per trunk, the accumulated carried traffic, and the grade of service if the group ends at a particular number of trunks. We don't need the number of calls, the average holding time, or anything else. Table II in Appendix II shows representative values.

But suppose we specify Grade of Service? What then? The GRADE OF SVC numbers in the right-hand column will almost never hit exactly the value we want. They will generally bracket the desired number. Well, we can fix that. We can call up another program, called ERL-GS, which is ERL-B turned inside out, as it were. We can now put in the desired grade of service and the program will tell us, where N is the number of trunks in a group, what the offered traffic has to be, what the total carried traffic will be, and how much traffic will be lost. This is shown in Printout 3-3, which is similar to Table I. It also takes the total carried traffic, divides it by N, and gives us the average occupancy of the trunk group. This right-most column is particularly interesting. It shows how average occupancy per trunk increases with group size; the bigger the N, the bigger the average occupancy per trunk, all for the same grade of service. Fig.3-1 shows this graphically, for the blocking values in Table I and for queuing, as will be discussed later.

Fig. 3-1. Increasing occupancy per trunk vs. group size.

ERL-GS shows us the lost traffic explicitly. But the lost traffic can be divided up into three parts, some of which may not occur in particular systems. We can think of lost traffic containing some proportion that overflows (perhaps from MCI to WATS, or WATS to toll), and some that retries. What is left just dies.

We may let all our traffic overflow to other trunk groups so that, ultimately, almost all of it is carried. Or, we can just let traffic hitting ATB die. Either approach is classic Erlang B, lost calls cleared. However, there is little probability that all callers will simply quit when they can't get through. Many will try again. Jewett's researches indicate that about 55% of the calls hitting ATB will retry. Thus we can take the lost traffic, multiply it by 55% (or some other number if we have reason to believe it works better), and find the amount of retry traffic the system is dealing with. Subtract retry traffic from offered traffic, and you have what has to be called first attempt traffic.

Your PBX, of course, cannot tell a retry from a first attempt. It just sees the offered traffic and tries to deal with it. But when service deteriorates badly, it is easy to overestimate the number of trunks we must add to correct the situation if we don't allow for retries, as we saw in the example in Chapter 1.

There is one note of caution that must be sounded here. First attempt traffic is, indeed, pretty much random. But retries are not. Retries tend to come in clusters, bunched during and just after ATB conditions. Thus retry traffic is not random, and drives the mathematicians nuts. If, however, we can convince our station users to wait for five minutes or so before retrying, their retries tend to "random out." Naturally they won't do this, but in a first course, let's keep things simple, pretend they do, and assume retries are actually random when they are not.

In ERL-GS, the program starts out with a one trunk trunk group, applies a small amount of traffic to it, and measures the grade of service. If grade of service is less than the specified value, the traffic is increased slightly and a new comparison is made. If the grade of service as measured overshoots the specified value, the program backs off and sneaks up on the specified value by increasing the offered traffic by a smaller value. When it gets close enough to the specified grade of service, it prints out and goes on to the next bigger N and repeats the process. This method of iteration is quite common in computer generation of tables.

We have talked about the difference between offered and carried traffic several times already. But, by now, it should be evident that we have to feed our formulas with offered traffic, while we can only measure carried traffic. How can we match these up? Obviously, we can specify carried traffic and let the program increase the offered traffic until the carried traffic comes out to be what we have measured or we have specified. Then we can look at the other numbers to find out what the offered traffic had to be to give us our specified carried traffic, and what our lost traffic will be under these same circumstances. All of these values are generated when we run ERL-B or any of the related programs.

The program that lets us specify carried traffic, either measured or postulated, is CARRIED. Clear the computer, load CARRIED, and run it. The first thing the program asks you for is the traffic to be carried by your trunk group. Let's keep on using our 14.63 Erlangs. The program then asks what % of the lost traffic will recall. Let's use the 55% suggested by Jewett. Overflow to toll might be 25%. Dead traffic is what remains. Finally, the program wants to know the call holding time. Let's keep on with 5.35 minutes.

We now have our basic parameters set into the machine. But it still wants more. How many trunks? Let's start with 15, the first number over the 14.63 Erlangs offered. The computer now goes into deep thought and a few seconds later produces Printout 3-4, in the same format as ERL-B. We see right away that a group of 15 trunks carrying 14.63 Erlangs is going to be in serious trouble. ATB will exist more than 72% of the time, and we will have to offer 52.88 hours of traffic to carry what we have specified.

The next screen full of information summarizes the data the program has generated. It tells us the first attempt and retry traffic, offered traffic (the sum of first attempts and retries), the carried traffic (which we specified), the traffic overflowing to toll and the traffic that simply died. It gives us hours of calling per hour (Erlangs), and it also gives us the number of calls. When we see the recalling traffic bigger than the carried traffic, we know the system is too tight. So let's ask for the next screen.

The program gives us another chance by asking for a new number of trunks. This time we try 16. We see, as soon as the program has run its course, that our grade of service is now much better (about B.38), and our offered traffic is much smaller. Continuing for the summary, and we find only 55 calls retrying as opposed to 209 first attempt calls. Let's continue again and try 17 trunks. Again there is improvement: only 26 recalls out of 211 total calls offered. Let's shoot the works and go on to 20 trunks. Now we see the grade of service is just about B.05, and is typical of what we would want for a dial-9 trunk group to the Central Office. Only 5 calls retry and 164 are carried. The 164 calls, each 5.35 minutes long, add up to our specified carried traffic of 14.63 Erlangs. Any time we want to quit, we just give the program 0 trunks and it takes the hint.

We can also use ERL-GS with carried traffic. For a specified grade of service, ERL-GS prints out both offered and carried. All one has to do is run down the "carried" column to find the number of trunks required to handle the traffic in question. Actually, hard copy printouts of runs of ERL-GS, using ERL-GSHC (where the HC suggests hard copy) for typical grades of service will handle the great majority of traffic jobs most communications managers will encounter. Table I includes printouts for B.01, B.05, B.10 and B.20, up to 50 trunks.

ERL-B is the basic program from which all the others are developed. It tells us the traffic carried on each trunk, total offered and carried, grade of service, etc. It is helpful to plot various runs of this program; graphs sometimes shows us things that tables of numbers do not.

Fig. 3-2 plots the traffic carried by each trunk in a group vs. the total number of trunks. Each curve is for a different offered traffic. Study of this diagram emphasizes a number of very important facts. First of all, we see quite clearly that no trunk can carry more than one hour of traffic per hour; 100% occupancy is all that is possible. Second, we note that, for 10 or more hours of offered traffic, the first several trunks start pushing 100% occupancy, and the more traffic we offer, the more trunks there are at "the front of the grade" that are running full. But, in all cases, there comes a time when enough traffic has been drained off by the first choice trunks so that the remaining trunks carry appreciably less traffic; carried traffic per trunk falls off very quickly. Finally, when almost all the traffic is carried away, there is none left for such trunks as remain, and the curve is again flat and close to zero. A curve of this sort is called an ogive (pronounced OH jive) by those who call it anything at all.

Fig. 3-2. Trunk by trunk distribution of traffic under Erlang B.

Observing the lower left hand side of the diagram, where small amounts of traffic are offered, we find the curves dropping quite quickly in terms of carried traffic per trunk. Consider the curve where 1 Erlang is offered. The first trunk carries 0.5 Erlang, but the second carries only 0.3. The ratio of the two is 1.67 to 1. But when we offer 10 Erlangs, the ratio of the traffic carried by the first and second trunks is only 1.02 to 1. In periods of light traffic, the first choice trunk carries less traffic than when traffic is heavy, but it carries a much larger percentage of the total traffic. Because not all hours are busy hours, we have to allow for this difference in busy-hour/side-hour traffic when we design networks. There are several different approaches, but in Chapter 6, we will see how the "Shaped Day" concept helps us predict monthly use of various facilities.

Erlang B is perhaps the most used of all the traffic formulas. With the several programs we have, we can specify offered or carried traffic, or grade of service, and let the programs relate N, the number of trunks, to the specified values. Alternatively, we can specify N, and see how much traffic a group of that size can handle at various grades of service.

The particular factor that distinguishes Erlang B from Poisson or Erlang C (which we will look at in the next chapter) is the way calls that find ATB are handled. With Erlang B, they simply vanish as far as the mathematics is concerned. Actually, they may overflow to other trunk groups or retry later; in either case, appropriate assumptions or measurements allow us to approximate system behavior. By contrast, under Poisson, calls stay in the system for one average holding time, whether they are served or not. Those that find ATB are not, however, turned away. If a trunk comes free, they use it for the remainder of their holding time. For short delays, Poisson works quite well; for longer delays, Erlang C is the one to use. With Erlang C, calls finding ATB simply go into a queue and wait in line for a trunk to come free. When a trunk is free and they are next in line, they get the trunk and use it for a full holding time.

To put it another way, there is no queue with Erlang B. The queue with Poisson is of short duration, and never more than one holding time, while the queue with Erlang C is can be quite lengthy. Each formula has its own field of application.

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

Copyright 2006 Lee Goeller. All Rights Reserved.