.PAPER SIZE 60,70 .CENTER Sizing Communications Requirements .TITLE Sizing Communications Requirements .SUBTITLE B. Z. Lederman ITT World Communications .BLANK 2 .CENTER B.#Z.#Lederman .CENTER ITT#World Communications .CENTER New York, N.Y. 10004 .BLANK 2 .NOTE Abstract Traffic analysis is a method used by the telecommunications industry to determine the number of circuits or operators required to meet the demand for service of their customers. Although it is not widely known outside the industry, it can be applied to a wide variety of applications where some number of requests for service must compete for a limited resource servicing the requests. This paper will not attempt to give a complete history of traffic analysis, but will try to show the fundamentals involved, demonstrate the types of problems which traffic analysis can solve, and show where such analysis may be of use in determining the quantity of resource required to meet the demand of those wishing to be served by that resource. .END NOTE .BLANK 3 .PARAGRAPH Briefly, traffic analysis started when telephone companies were faced with a situation such as in Figure 1. The problems faced are: how many trunks (telephone lines or circuits) are required between towns A and B to keep most customers happy (not too many fast busy signals*), .FOOTNOTE 4 .BLANK * The telephone company considers it's job done when one telephone is connected to another: if the desired telephone is in use, or no-one answers, it is not their concern. ! and how many operators are required in each town to answer requests for assistance, telephone numbers, etc.? Too few lines, and customers will complain about busy signals, too many and the telephone company wastes money and resources by supplying unused lines: too few operators, and customers will complain about waiting too long for assistance, too many and operators will sit idle. This represents two types of systems: the first is a "blocking", or "loss", system, where requests are abandoned if not immediately satisfied; the second is a "waiting", or "queuing", system, where requests wait until served (or a given amount of time has elapsed). These two types of situations occur for many applications outside of the telephone industry, and it is the purpose of this paper to demonstrate how the methods of traffic analysis may be used for these applications. .PARAGRAPH The methods of answering these questions were largely developed by A.#K.#Erlang, and are based on a number of assumptions which must be true for the answers to be true. First, it is assumed that requests for service (in this case, persons in one town calling a person in the other town) are made at random in time: experience has shown that this is an accurate description of the actions of large numbers of persons acting separately (the exact distribution is a form of Poisson, or exponential distribution). Next, it is assumed that the answer desired is that which will satisfy the majority of requests over a given period of time. Traffic analysis deals with statistical processes: it describes what one can normally expect to see in the long run, and not necessarily what will happen at any one particular instant in time, and measurements are usually taken over a period of time (for example, how busy a system is during a one hour period) rather than for instants in time. This is, in fact, what one usually wants in designing a system; to satisfy the normal request for day-to-day service, rather than an abnormally high request rate which may occur once in 3 years. The Erlang conditions produce a subset of more general queuing theory, and result in equations which (complicated as they may appear) are easier to use than more general queuing theory formulas. .PARAGRAPH The loss system is easier to explain, so an example of this type of application will be given first, as shown in Figure 2. The problem involves a computer with a number of telephone lines attached to modems: persons wishing to use the computer must call in, and the telephone company will connect them to one of the lines, unless all are busy. The question is, how many lines (plus the attached modem and line on the computer) are required? .PARAGRAPH Before the number of lines can be computed, it is necessary to know how much traffic will be carried by these lines. Notice I did not say how many people want to use the system: by assuming the traffic is generated by an infinite source, the traffic can be measured in a way which is independent of the number of requests. The measurement which is needed is the total amount of time the lines in this group are busy over a given time period. The period of time most often used is one hour, and this will be used for the example, though the entire process can be scaled to larger or smaller time intervals if desired. During the one hour period in question (which need not coincide exactly to a clock hour, i.e. the period could start at 14:37:52 rather than at exactly 2:00 PM), the total amount of time each line in the group is busy will be measured, and the sum total is the amount of trunk occupancy, or traffic, received. For example, if there was only one call, and it lasted two minutes, then the amount of traffic in that hour was 120 call connect seconds (CS). If there were two calls, one for 3 minutes and one for 5 minutes, the total traffic was 480 CS or 4.8 cent call seconds (CCS) or 4.8 hundred call seconds (HCS). If a call was in progress when the measurement period began, or is in progress when the measurement period ends, only the portion of the call within the period of interest is included: for example, a call begins during the measurement period, and lasts for 8 minutes, but it started 2#1/2 minutes before the end of the measurement period; therefore only 2#1/2 minutes are added to the total traffic: see Figure 3 for some examples. When the period is over, all of the traffic is added up. It can be expressed in call-connect seconds, or cent call seconds (which is more common within the telephone industry), but it is most often expressed in Erlangs (named for A.#K.#Erlang). One Erlang is equal to one call connect-hour, or 1 traffic unit (TU), or 36 HCS, or 36 CCS, or 3600 connect seconds (CS), measured over a one hour period of time. In this paper, all traffic is measured in Erlangs. .PARAGRAPH Once the amount of traffic is known, and the number of lines which are to carry this traffic is known, the Erlang#B formula is used to calculate the amount of blocking, or loss, incurred. The formula is: .TEST PAGE 10.BLANK .NO JUSTIFY.NO FILL N __^&A\&__ N! B = ------------------- = B(N,A) __^&N\&__ i _\ __^&A\&__ ^&/\&____ i! i=0 Where A = Traffic Presented in Erlangs N = Number of Servers (trunks) (Must be ^&>\& 1) B = Blocking .JUSTIFY.FILL .BLANK The blocking B (also written as B(N,A) to indicate the blocking for given values of N and A) can be a value between 0 and 1: zero blocking means all traffic goes through, a B of 1 means that all traffic is blocked (none goes through). A value of 0.5 means one half, or 50_%, is blocked (50_% goes through). Don't be scared off by the formula: the traditional method of solution has been with books of tables containing values of B for given N and A, but now that computers are generally available (I assume that most persons reading this paper have access to one), the formula may be easily solved by computer. One might ask what the procedure is if one knows the amount of traffic expected, and has determined an acceptable value for B, as in the present example. The formula above cannot be used to solve for N, given values of B and A, so one must solve iteratively, by either moving around the table in the book, or, on a computer, entering the amount of traffic, setting the value of N to 1, and solve for B; if B is less than or equal to the desired B, then the answer has been obtained: if not, increase the value of N by one, and try again. Fortunately, computers don't get "bored" by repetition. .PARAGRAPH To return to the example, let us suppose that 5.3 Erlangs of traffic were measured during the test period. One may wish to determine the cost of providing various levels of service, thus: .TEST PAGE 22.BLANK.NO JUSTIFY.NO FILL Number of Grade of trunks####Blocking####Service -------------------------------- .BLANK # 1#######84.13_% # 2#######69.03_% # 3#######54.95_% # 4#######42.13_% # 5#######30.87_% # 6#######21.43_%#####1 in 5 ------------------------------- # 7#######13.96_% # 8####### 8.46_% # 9####### 4.75_%#####1 in 20 #10####### 2.45_% #11####### 1.17_%#####1 in 100 #12####### .51_% ------------------------------- #13####### .21_% #14####### .08_%#####1 in 1000 #15####### .03_% .JUSTIFY.FILL.BLANK The grade of service is a term used to count the number of lost calls, generally one-in-a-whole number (one does not see it expressed as one lost call in 57#2/3). This term is not widely used, and the values above (which are approximates) are given only to familiarize the reader with the terminology in use. From the above list, one can then add up the cost of each line and modem, and balance it against the possible increase or loss in revenue for each level of service. This is where traffic analysis ends: it only provides the numbers upon which a decision can be made as to what constitutes an acceptable loss during the busy period. .PARAGRAPH For situations such as these, it is normal to measure the traffic to a group of servers. In the above case, it would have been necessary to measure the traffic which the telephone company is presenting to the group of telephone lines. While the company might be willing to do this (especially if it wishes to demonstrate that the customer requires more lines), it is sometimes necessary to measure the traffic from the point where it is received (in this case, the computer). This can be done iteratively by measuring the traffic received, and calculating the amount of traffic which must have been presented in order for the amount of traffic received to get through. If the traffic presented to the group of lines is A, then the traffic lost is the traffic times the blocking, or .BLANK.INDENT 5 Traffic lost = L = B * A .BLANK Similarly, the traffic received is the traffic presented minus the loss, or .BLANK.INDENT 5 Traffic received = R = ( 1 - B ) * A .BLANK One must work iteratively, which is time consuming when only books of tables are available, but the use of the computer makes this much easier. Once the traffic presented has been calculated, the actual blocking is also obtained. .PARAGRAPH It has been said that one usually calculates blocking for the busiest hour of the day: this is to determine the number of servers required for the heaviest load. One could also calculate the blocking for the busy hour from the point of view of determining just how bad things are going to be at their worst. If a day's traffic is measured for each hour and plotted, one might see something like Figure 4. This is a typical business day, where traffic picks up in the morning as the work day begins, drops somewhat at lunch, and peaks in the afternoon. One can simply take the peak at 5:00 PM (1700 hours) as the worst case, or calculate the blocking hour-by-hour to determine how often the system is blocking above the desired level. .PARAGRAPH It should also be noted that the formula given assumes an infinite number of sources generating the traffic: this is why only the volume of traffic is required, and not the number of users. If the traffic is generated be a fixed number of sources, the actual blocking will be slightly less than that given by the formula. This is only important if the number of sources is only slightly larger than the number of servers, and, in any case, the blocking calculated assuming an infinite source can be taken as a worst case, thus supplying a slight additional safety factor. Of course, if one knows that the traffic will be generated by a fixed small number of sources, that places the upper limit on the number of servers required. In the above example, if it were known that the 5.3 Erlangs of traffic were being generated by 10 customers (there being only 10 customers allowed to call this facility), then there is no reason to provide more than 10 telephone lines, and the actual blocking with 10 lines should be zero, not 2.45_%. Most applications are not this simple, however, and traffic analysis allows one to obtain reasonable answers to problems where the number of requests for service may not be as well known. .PARAGRAPH When blocking is high, the system is considered to be congested as the requests for service cannot be satisfied. Whether this is bad or not depends upon one's point of view. In the above example, if one is supplying a time-sharing service, and is competing with others supplying this service, then the number of lines should be selected to provide low blocking, otherwise potential customers will be frustrated at not being able to get into the system, and may cease to use the service. From the point of view of the person supplying the lines and modems, low blocking implies that some of the lines will often be idle; a situation of high blocking would insure that the lines would be busy most of the time. Consider the data from the previous example in this manner: .TEST PAGE 22.BLANK.NO JUSTIFY.NO FILL Number Time any of Traffic trunk trunks Blocking Received is busy ------------------------------------------ .BLANK 1######84.13_%#########0.84########84.1_% 2######69.03_%#########1.64########82.1_% 3######54.95_%#########2.39########79.6_% 4######42.13_%#########3.07########76.7_% 5######30.87_%#########3.66########73.3_% 6######21.43_%#########4.16########69.3_% ------------------------------------------ 7######13.96_%#########4.56########65.1_% 8###### 8.46_%#########4.85########60.6_% 9###### 4.75_%#########5.05########56.1_% 10###### 2.45_%#########5.17########51.7_% 11###### 1.17_%#########5.24########47.6_% 12###### .51_%#########5.27########43.9_% ------------------------------------------ 13###### .21_%#########5.29########40.7_% 14###### .08_%#########5.29########37.8_% 15###### .03_%#########5.29########35.3_% .JUSTIFY.FILL.BLANK It can be seen that as blocking goes up, the percentage of time that the trunks in use will be busy goes up; as blocking goes down, the traffic received approaches the traffic presented, and the percentage of time that each trunk is busy decreases. Note also that the amount of time all trunks are busy is exactly equal to the blocking. This must be taken into account when deciding what level of service to provide, by accounting for the cost of the server vs. the amount of additional traffic (or the benefit of user's not seeing a busy condition) provided by additional servers. Alternatively, if traffic is highly peaked and one can be certain that the requesters will continue to call until served, then a high level of blocking may be chosen for the busy hour to force the traffic load to distribute over time, and result in greater utilization of fewer circuits. If we take the example presented but now say that the callers are branch offices reporting their daily transactions to a main office at the end of the day, and the calls are placed by computer so there are no operators to become annoyed, then there is no reason to provide enough circuits for all branches to be able to call in at 6:00#PM and then have them idle for the rest of the night. One would instead choose a number of trunks which might have a high blocking at 6:00#PM (in this case, 3 or 4 trunks), and then measure the traffic to see that blocking falls off to a low value by 11:00#PM, so that there is a good probability that all offices can report in before processing ends for the day. This would force the traffic to distribute over a longer period of time, and one would obtain a greater utilization of the circuits, as they will be busy a greater percentage of the time. .PARAGRAPH If, for a given use, you do choose a low value of blocking for the busy hour, then you must also be prepared to demonstrate why the additional circuits are required to provide the desired level of service should someone unfamiliar with traffic analysis look at the circuits during the day and find some of them idle. The greatest difficulty in introducing traffic analysis to people is convincing them that the statistical approach is correct, and that the extra circuits are required to reduce blocking, even if at times they appear unused. .PARAGRAPH Another approach is to calculate the number of trunks needed now for a given amount of blocking, and then add a percentage to account for future growth: thus if one determined that 5_% blocking is acceptable, requiring 9 trunks now, one might add a 10_% margin (.9 additional trunks, rounded up) or 10 trunks, so that future growth would not raise the blocking too much. This gives one some lead time in ordering extra circuits when traffic does increase. .PARAGRAPH The accuracy of these results should be examined. In the above examples, the tables were divided into 3 sections. For 1 to 6 trunks, the blocking predicted is probably too low, as the Erlang B formula does not account for re-tries, and when blocking is great, the requesters will probably try several times to receive service. Once the blocking goes much over 20_%, the formula is mathematically correct, but may not account for the real-life situation as accurately as it does conditions of moderate or low blocking. This is generally not a problem, however, because once the blocking goes over 20_% it is generally sufficient to know that the system is congested, and an error of a few percent is not of vital importance. For 7 through 12 trunks (for the example given), the values should give an accurate representation of the blocking to be expected in a real system. For more than 12 trunks, the accuracy will depend upon the number of sources generating the traffic. If the source is large (an infinite source was assumed), the values will be good. If a small number of requesters are generating the traffic, then the actual blocking will be less than that predicted. Generally, the infinite source is assumed, as this gives the worst blocking which will be experienced, and the worst case condition is often appropriate in planning a system. Unless the actual number of sources is only slightly larger than the number of servers, the difference in blocking will be small. In the case where only traffic received is known, and the traffic presented is inferred, a larger margin of error should be assumed unless the blocking is low. .PARAGRAPH A waiting, or queuing, system is one where the requesters wait until served. The case covered by the Erlang formulas is a multi-server, single First In First Out queue (see Figure 5). Examples of this are a bank where customers enter at the end of a single waiting line and the person at the head of the line goes to the next available teller, a printer queue where files are entered at the back of the queue and the file at the front is printed on the next available device (even if there is only one printer serving the queue, the formulas work), a telephone operator queue where persons calling in are placed at the end of a waiting list and the free operator takes the next entry off of the front of the list, a restaurant (without reservations) where customers entering are placed on a list, and the first party is given the next available table, a disk queue where requests go on a queue and the first request gets the next available controller, etc. This works only if no-one is allowed to "jump" the queue, if requests have different priorities (the queue is not strictly FIFO), then different (and more complicated) queuing formulas must be used. .PARAGRAPH In the place of the simple question "how many requests are turned away for lack of servers" asked in a blocking system, a queuing system involves more complicated questions such as "how many requests are made to wait", "what is the length of time the average request waits", and "what is the maximum time a request waits?". The solution to the first is fairly simple, and is represented by the symbol P>0, or the probability of waiting more than zero amount of time. Obtaining more information than this is another matter. There are two times of interest; Tw, which is the average waiting time of all requests (delayed and non-delayed), and Tw', which is the average waiting time of only those calls which are required to wait (those that are not served immediately). It is wise to remind the reader at this point that in this paper, average and mean both refer to the simple arithmetic mean (add up all values and divide by the number of values). In addition, one will want to calculate the probability of waiting no more than a given amount of time, expressed as P>T; the probability that a request waits more than time T. It is not possible to calculate the maximum waiting time (or rather, it is not necessary; the maximum is infinity), but as the time increases, the probability that a call will have to wait that amount of time decreases. In most cases, it is sufficient to calculate the average, and the time by which a given percentage of all requests will be serviced; i.e. one can specify that 99_% of all requests will be serviced by time T. This percentage will naturally vary with the application, and is one of the quality factors which must be decided arbitrarily by the person evaluating the application. If one is designing a query-answer system for a travel agency, one might wish to set a maximum wait for 90_% of the requests, whereas a similar system installed in a hospital operating room might require 99.9_% of the inquiries be answered by a given time to satisfy the users of the system. .PARAGRAPH In the simple blocking system, it was possible to obtain an accurate answer knowing only the total amount of traffic, rather than the length of each request and the number of requests. In waiting systems, only P>0 can be determined this way. To determine the other values more information is required, such as the mean holding time of a request and the number of requests, or the individual holding times for each request, which eventually amount to the same thing. Obviously, the time has come to explain more terminology. The holding time of a transaction (a call in the telephone industry) is the total length of time a particular request lasts from first initiation to final completion. For a telephone call, this is the time from the moment you lift the telephone receiver to request service to the time you replace it (and actually a little more, as the used circuits have to be cleared out when you have finished). It doesn't matter if your call went thorough or not; all time is the holding time. This is different from the effective time (or elapsed time, or connect time, or bill-able time, which are all different names for the same quantity), which is the time starting when the person you called picks up their telephone, to the time one of you hangs up, which is the time for which you are billed. The difference at the beginning of the call is the set-up time; the time required to establish the connection. For a call which does not go through, the set up time is identical with the holding time. For a call which is successful, the set-up time plus the effective time should equal the holding time. For a situation where requests are waiting for service, the waiting time would be part of the set-up time, while the service itself would be the effective time. To use an example which will be familiar to most readers, and to show that the techniques are applicable to more than just communications and computers, consider a bank where customers wait on a single line, and the person at the front of the line goes to the next available teller. The wait on the line would be the set-up time or time on queue, and the time spent with the teller would be the effective time. The probability of a person walking into the bank and finding a teller immediately available (i.e. no line of people waiting) is one minus the probability of waiting or 1-(P>0). The average wait on line is Tw', the average delay of requests which are delayed. The average holding time is the average of the time each person spends in the bank including the time spent at the teller, and the time spent waiting on line, if any. The value which is usually of interest is the probability of the customer waiting on line more than a given amount of time (or P>T, for some acceptable value of T). .PARAGRAPH Some astute readers may have spotted what appears to be a contradiction between the definition of holding time and the definition of blocking systems, where a request for service must be satisfied immediately, else it is lost. In real life, requests are not instantly gratified. If one dials a telephone number, one usually waits at least a few seconds for the call to go through. In practice, if this time is counted as part of the holding time (as is in fact proper, as the server is busy while the request is processed), then the formulas yield the correct answers. .PARAGRAPH The probability of delay may be calculated directly from the data, or the simple blocking formula, Erlang B, may be used as an intermediate calculation. The probability of any delay, P>0, is also known as C or C(N,A), and may be calculated from B(N,A) by one of the following: .TEST PAGE 8.BLANK.NO JUSTIFY.NO FILL 1 B(N,A) C(N,A) = ----------------- = --------------------- N - A A 1 + ------------ 1 - - * (1 - B(N,A)) A * B(N-1,A) N B = B(N,A) = the Erlang B blocking formula given before. A = the amount of traffic presented, in Erlangs. N = the number of servers. .BLANK.JUSTIFY.FILL Note that in the first formula, the value of B is for N#-#1, ^&one less\& server than the number of servers in question. One may also calculate directly from the data by: .TEST PAGE 14.BLANK.NO JUSTIFY.NO FILL N A ------------------ (N - 1)! * (N - A) C(N,A) = ----------------------------- = P>0 N-1 --- i N _\ A A / --- + ------------------ --- i! (N - 1)! * (N - A) i=0 .JUSTIFY.FILL .TEST PAGE 14 .NO JUSTIFY.NO FILL or N N A --- * --- N-A N! C(N,A) = ----------------------- = P>0 N-1 i N ---- A N A _\ --- + --- * --- ^&/\&______ i! N-A N! i=0 .BLANK.JUSTIFY.FILL All of the above should work out to the same value, but it is important to note that the formulas are valid only for N greater than A. If A is greater than or equal to N, then C(N,A) is assumed to be 1, and the delay approaches infinity, as there will not be enough servers to ever get all of the requests off of the queue. The only way to obtain time-delay values for an existing case where A#>#N is to extend the time period under observation to include a period of time where traffic drops off and the servers catch up with the queue. If this is done, the average traffic presented will be less than the number of servers, and the time delays can be calculated. .PARAGRAPH An example of the output of these formulas can be shown using the same value of traffic (5.3 Erlangs) as in the first example: .BREAK .TEST PAGE 13.BLANK.NO JUSTIFY.NO FILL N B C ----------------- 6 .214 .70 7 .14 .40 8 .085 .216 9 .048 .110 10 .025 .052 11 .012 .023 12 .0051 .0091 13 .0021 .0035 14 .0008 .0013 15 .0003 .0004 .JUSTIFY.FILL .PARAGRAPH The next step is to obtain the probability of waiting more than some given amount of time T. This requires knowing a new item of data, U, the reciprocal of the average holding time per call. For example, if one adds up all of the holding times for the period in question (from which one usually obtains the amount of traffic presented), and divides by the number of requests, the mean holding time is obtained, and the reciprocal of this is U. If there were 318 minutes of holding time observed during an hour, which is 5.3 Erlangs, and this amount of time was the result of 127 requests for service, the mean holding time is 2.5 minutes (318/127), and U is 0.40 (1/2.5). When U and C(N,A) are known, the probability of waiting for any given T may be obtained from: .TEST PAGE 5.BLANK.NO JUSTIFY.NO FILL -(N - A)UT P>T = C(N,A) e .BLANK.JUSTIFY.FILL It is important to remember that U and T must have the same dimensions; if U is expressed in minutes, T must also be in minutes. A is always in Erlangs. .PARAGRAPH One may also calculate Tw, the mean time of delay for all calls, and Tw', the mean time of delay for delayed calls. .TEST PAGE 6.BLANK.NO JUSTIFY.NO FILL C(N,A) 1 Tw = --------- Tw' = --------- U*(N - A) U*(N - A) .BLANK.JUSTIFY.FILL The only difference is that one takes into account the portion of calls delayed, which is C(N,A). Tw is therefore also referred to as the expected delay, E(W), as it is the average delay for all calls. .PARAGRAPH As an example of how the delays may be calculated, take the data from the previous example (5.3 Erlangs, U=0.40), and assume that there are 7 servers. This makes C(N,A)#=#0.40, Tw is 0.59 minutes, and Tw' is 1.47 minutes. Using the formula for P>T and various values of T, the following is obtained: .TEST PAGE 14.BLANK.NO JUSTIFY.NO FILL T P>T T P>T ------------------------------ .1 .378 3.5 .055 .25 .347 4.0 .041 .5 .301 4.5 .031 .75 .261 5.0 .023 1.0 .227 6.0 .014 1.5 .171 7.0 .0075 2.0 .129 8.0 .0043 2.5 .097 9.0 .0024 3.0 .073 10.0 .0014 .BLANK.JUSTIFY.FILL As one might expect, as time increases, the probability of waiting that much time decreases, and the probability of being served by that amount of time increases. One can say, for example, that the probability of waiting more than 2.5 minutes is .097 which means that just under 10_% of the requests wait more than 2.5 minutes. The expected waiting time is weighted for the distribution of waiting requests and requests which do not wait (in this example P>0 is 0.4, so fewer than half of all requests should have any wait). If these waiting times are too long, then one would chose a larger number of servers (in this case, 8 or more), and calculate the P>0 and P>T times again, to determine if the waiting times are now acceptable. Alternatively, one might construct a table as before, showing delay probabilities for a given amount of traffic (in this case, 5.3 Erlangs with U#=#0.40) and different numbers of servers N. All times are in minutes. .TEST PAGE 10.BLANK.NO JUSTIFY.NO FILL N P>0 P>.1 P>.5 P>2.5 Tw' Tw --------------------------------------- .BLANK 6 .70 .68 .62 .39 3.57 2.5 7 .40 .38 .30 .097 1.47 0.59 8 .216 .20 .14 .023 .93 .20 9 .110 .097 .059 .005 .68 .075 10 .052 .044 .024 .001 .53 .028 11 .023 .019 .009 .0002 .44 .010 .BLANK.JUSTIFY.FILL It is now simple to balance the cost of the number of servers against the expected delay, or the probability of a wait exceeding a desired limit. In this example, if one wanted 99_% of all calls to be served within 30 seconds (0.5 minutes), then P>.5 must be less than 0.01, which requires 11 servers. If one wanted the expected (average) delay to be 15 seconds or less, 8 servers are required (0.2 minutes is 12 seconds). .PARAGRAPH One must also remember to put the results back into the context of the problem. If this were a print queue problem, then the values obtained are the delays before the request is served. In this case, this is the delay until the job starts to print. If the time until the job is finished and ready to be torn off the printer is the desired time, then the average holding time (the average length of a print job) would have to be added to the average delay to obtain the average wait for job completion. It is a good practice whenever solving a traffic analysis problem to refer back to the original conditions periodically to ensure that the answers make sense when applied. .PARAGRAPH Hopefully, the reader will now have some idea of the types of problems which traffic analysis can address. If a situation where a number of requests compete for a limited resource can be described in a manner consistent with the Erlang models presented, then it is reasonably easy to calculate values for the number of requests which will be turned away, or the length of time requests will wait. With these values, one may then make reasonable decisions about the allocation of these resources, or the need to increase the number of servers, and by what amount, to reach the desired level of service. .BLANK .CENTER;Bibliography .BLANK Staff, "Engineering and Operations in the Bell System", Bell Telephone Laboratories, Inc. Part 5 .BLANK Kleinrock, Leonard, "Queueing Systems: Volume 1 Theory", John Wiley and Sons. Covers all types of Queues, very advanced mathematically. .BLANK Kleinrock, Leonard, "Queueing Systems: Volume 2 Computer Applications", John Wiley and Sons. Contains ARPANET examples. .BLANK Gorney, Leonard, "Queueing Theory: A Problem Solving Approach", Petrocelli Books. Has programs in TRS-80 Level II Basic. .BLANK Zussman, Ronald, "Computer Queuing Analysis on a Handheld Calculator", Computer Design, November 1977 pp. 85-94 .BLANK -, "Teletraffic Engineering Manual, Tables and Diagrams for Switching Systems", Standard Elektrik Lorenz AG, Stuttgart .BLANK -, "Telephone Traffic Theory - Tables and Charts", Siemens Aktiengesellshaft, Munich ISBN 3-8009-1163-9 .BLANK The two works above are books of tables, with explanations of the formulas and their uses. They are published in English. .TEST PAGE 10.PARAGRAPH The following FORTRAN Function solves the Erlang B Blocking formula without requiring any factorials or large powers by re-arrainging the formula into a single series. .BLANK.NO JUSTIFY.NO FILL FUNCTION ERLB(N,A) C C To solve the Erlang B formula without C factorials or large powers. ERLB C returns a value between 0 and 1. C C Permission to use this algorithm is granted C provided the author is credited. C C B. Z. Lederman C ITT World Communications, N.Y. C C TEMP1 gradually decreases in value: if it C becomes so small as to no longer be C significant, quit early. C TEMP1 = 1. TEMP2 = 1. C DO 220 I = N, 1, -1 TEMP3 = FLOAT(I) TEMP1 = TEMP1 * (TEMP3 / A) IF (TEMP1 .LE. 0.00001) GO TO 225 220 TEMP2 = TEMP2 + TEMP1 225 ERLB = 1. / TEMP2 RETURN END