.PAGE SIZE 55, 70 .RIGHT MARGIN 70 .LAYOUT 2, 3 .TITLE Sizing Communications Requirements .SUBTITLE B.#Z.#Lederman .CENTER Sizing Communications Requirements .BLANK 2.CENTER B.#Z.#Lederman .CENTER ITT World Communications .CENTER New York, NY 10004-2464 .NOTE Abstract Traffic analysis is a method used by the telecommunications industry to determine the number of circuits (or modems, or operators) required to meet the demand for service by 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 these requests. This paper will not attempt to give a 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 resources required to meet the demand of those wishing to be served by that resource. .END NOTE .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 running between switching centers or exchanges) are required between towns A and B to keep most customers happy (not too many fast busy signals*), .FOOTNOTE 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. .END FOOTNOTE and how many operators are required in each town to answer requests for assistance, directory information, 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 (but still be paid). 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 correct. First, it is assumed that requests for service (in the example above, people in one town calling the people in the other town) are made at random intervals 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 required 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; 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 is usually wanted in designing a system: to satisfy the normal requests 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 first appear) are much 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 (a "rotary" set of lines). The question here is: how many lines are required to meet the needs of the people trying to use the computer? .PARAGRAPH Before the number of lines can be computed, it is necessary to know how much traffic will be carried by these lines. Notice that 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 measure 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 this paper (though the entire process can be scaled to larger or smaller time intervals). During the one hour period in question 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. From this point, all measurements in this paper will be in Erlangs. .PARAGRAPH The measurement period 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. Unless phenomenal accuracy is required, measuring over a clock hour such as 2:00#PM to 3:00#PM is usually easier, and gives acceptable answers. .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 .BLANK.NO JUSTIFY.NO FILL.TEST PAGE 13 N ____^&A\&____ B = --------------------------------------- = B(N,A) __^&N\&__ i \ A /____ i! i=0 .BLANK Where:##A = traffic presented in Erlangs ########N = number of servers (trunks, etc. Must be ^&>\& 1) ########B = Blocking .BLANK.JUSTIFY.FILL 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 (all requests are served), a B of 1 means that all traffic is blocked (none goes through, all requests are refused). A value of 0.5 means that one half, or 50_%, is blocked. Don't be scared off by the formula: the traditional method of solution has been with books containing tables showing B for given N and A, but now that computers are widely available the formula may be easily solved by computer. One might ask what the procedure is if the amount of traffic expected is known and an acceptable value for B is established, the the number of servers N needs to be calculated: this is the most commonly asked question, and is what is wanted in this example. The formula above cannot be solved for N given values of B and A so one must solve iteratively: this used to mean moving around the tables in a book looking for the answer, but a computer program would simply set the value of N to 1, solve the equation, check to see if the blocking is acceptable, if not increase N by one and calculate again, etc. Fortunately, computers don't get "bored" by repetition. The actual calculation takes only a fraction of a second even on "small" computers. .PARAGRAPH To return to the example, let us suppose that 5.3 Erlangs of traffic were measured during the test period. The cost of providing various levels of service can be determined with a table: .BLANK.NO JUSTIFY.NO FILL.TEST PAGE 21 Number of Grade of trunks Blocking Service --------------------------------- 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_% .BLANK.JUSTIFY.FILL The grade of service is a term used to count the number of lost calls, generally one-in-a-whole-number (it is not expressed as one lost call in 57#2/3). This term is not widely used (at least not outside the telephone industry), and the values above (which are approximate) are given only to familiarize the reader with the terminology in use. It is more usually to choose a percentage of acceptable blocking or loss, such a 1_% of the requests being turned away or lost. From the above list, the cost of each line and modem can be added up, and balanced against the possible increase or loss in revenue for each level of service (how many lines you pay for versus how many people get through when they call). 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 measurement period. .PARAGRAPH For situations such as this, 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 should order more lines), it is sometimes necessary to measure the traffic where it is received (in this case, at 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 have gotten through the current number of lines. If the traffic presented to the group of lines is A, then the traffic lost is the traffic multiplied by the blocking, or .BLANK.INDENT Traffic Lost = L = B * A .BLANK Similarly, the traffic received is the traffic presented minus the loss, or .BLANK.INDENT Traffic Received = R = (1 - B) * A .BLANK One must work iteratively which was time consuming when only books of tables were available, but using a computer makes the task trivial. Once the traffic presented has been calculated, the actual blocking or loss is also obtained. .PARAGRAPH The situation which is normally of greatest interest is the busiest time (hour) of the day: this is to determine the number of servers needed to meet the greatest demand for service. Blocking can also be calculated for the busy hour from the point of view of determining just how bad things are going to get 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 during lunch, and peaks in the afternoon as people try to finish up for the day. To meet this load, 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 of service. .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 by 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 as 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 liens, and the actual blocking with 10 lines would be zero, not 2.45_%. (Not counting having additional lines as a safety factor in case the hardware fails or a telephone line stops working.)# 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 well known. .PARAGRAPH When the blocking is high the system is considered congested, as the requests for service cannot be satisfied. Whether this is bad or not depends on one's point of view. In the above example: if the system 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 using 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 condition 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: .BLANK.NO JUSTIFY.NO FILL.TEST PAGE 21 Number Time any of Traffic trunk trunks Blocking Received is busy ----------------------------------------------- 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_% .BLANK.JUSTIFY.FILL 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 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 (line) versus the amount of additional traffic (or the benefit of user's not seeing a busy condition) provided by additional servers (lines, trunks, etc.). Alternatively, if traffic is highly peaked (occurs mostly at a certain time of day) and you can be certain that the requesters will continue to call back until they get in, then a high level of blocking may be chosen for the busy hour to force the traffic load to distribute over a longer period of time, and result in greater utilization of fewer servers. 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 no people have to sit around waiting for a free line), then there may be no reason to provide enough lines for all branches to be able to call in at 6:00#PM and then have them sit idle for the rest of the night. One might instead choose a number of trunks which might have a high blocking at 6:00#PM (in this case, 3 or 4 lines), 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 office can report in before processing ends for the day. This would force the traffic to distribute over a longer period of time, and result in greater utilization of the circuits as they will all 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 prevent loss of service 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 it has been determined that 5_% blocking is acceptable requiring 9 trunks now, a 10_% margin might be added (0.9 trunks, rounded up) so that 10 trunks would be used. This gives some space for future increases in traffic, and gives some lead time for 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 may be a little low as the Erlang#B formula does not account for people re-trying; and when blocking is high, people may try several times to obtain service before giving up. Once the blocking goes much over 20_%, the formula is mathematically correct but may not account for real-life situations as accurately as it does for 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 (in the examples given) the values should give an accurate representation of the blocking to be expected under real conditions. For more than 12 trunks, the accuracy will depend upon the number of sources generating the traffic (requests for service). As previously stated, if the source is large, the values will be good: if a small number of requesters are generating the traffic, then the actual blocking will be less than the values predicted. Generally, an infinite source is assumed as this gives the worst blocking that could be experienced, and the worst case situation is often appropriate when planning a system. Unless the actual number of sources is only slightly larger than the number of servers, the actual difference in blocking will be very small. In the case where only the traffic received is known, and the traffic presented is inferred, a larger margin of error should be assumed unless the blocking calculated is low.