Goeller on Telecom
Traffic
(Lee Goeller writes:
I combined material from my
several articles into a book which BCR published in 1983: "A First
Course in Telephone Traffic Engineering." So far as I know, it is
the first book to include a floppy disk with all my traffic
programs, somewhat expanded for general use, included. I wrote the
book to work with the programs, and the programs to work with the
book. The text of the book is included here, without the disk and
some of the material generated by programs in BASIC rather than a
word processor. )
A First Course in
Telephone Traffic Engineering
Table of Contents
(Webmaster's Note: Clicking on "Figure" links will open the
Figure in a separate window.)
Chapter 1:
Traffic Handling Systems,
Basic assumptions
How To Use This Course
This course is based on the assumption that you want to learn how
to use telephone traffic theory to design communication networks of
the sort used by businesses, institutions, governments, and even
telephone companies. As a result, it does not follow the typical
pattern which requires the memorization of formulas well known for
70 or more years and which, without a computer, are almost
completely unusable. (Appendix I contains some of the simpler
formula derivations, along with references for further reading).
Rather, it substitutes a floppy disk on which these formulas are
programmed to be ready for immediate use. As you read through the
text, call up the programs where indicated, run them, and see what
happens. Appendix IV contains suitable instructions.
If you do not have access to a computer, or are reading on an
airplane or in the comfort of your living room chair, sample runs
for specific programs, similar to those you would see on the screen,
are also listed in Appendix IV. Further, sample traffic tables are
given in Appendix II for quick reference. However, it is strongly
recommended that you get in the habit of calling up and running
specific programs as you need them.
For those interested in the programs themselves, Appendix III
contains an article I wrote several years ago to illustrate my
approach to the problem. Even the simplest of the traffic formulas
are seen there to be quite complex; I feel they have to be
considered a sort of flowing process rather than a single
calculation. Viewed in that light, the program listings are
deceptively brief, considering what they do. It is interesting to
note that even Bell Labs, as of 1953, did not have tables of the
Erlang C distribution; now anybody with a toy computer can generate
them at will, and, indeed, many people all across the country are
using the programs from my article today.
The programs on the disk that comes with this course are almost
all somewhat more involved, and reflect additional needs and
requirements that I have found necessary in my own consulting
practice. Further, they deal better with some of the strange
behavior of computers which do not like very large or very small
numbers or have other eccentricities. Computers are strange
machines, but I often wonder how anybody worked in traffic before
they became generally available. Without a computer to provide
numbers, even a perfect understanding of theory and the derivation
of the formulas is almost useless. With a computer, even those of us
who are not PhDs in mathematics can design quite respectable
networks and save our employers and clients large sums of money.
But what is a good network? Anyone who cannot stand ambiguity
should not study telephone traffic. Traffic is a statistical subject
by its very nature, and "right" answers are not always meaningful,
particularly if we express them to an accuracy of six decimal
places. Exactly how many circuits we need, exactly how many calls we
can serve, are not meaningful terms. When we try to predict the
future on the basis of measurements made in the past, there is
always a margin for error. To get any sort of answers at all, we
have to make assumptions; our answers, then, can be no better than
the way the assumptions work out in any specific real situation.
They may, in fact, be a lot worse. But to start off, we must
understand the assumptions on which our concepts are based. The rest
of this chapter introduces the more important of these assumptions,
leaving the following chapters to deal with specific formulas and
design principles.
Grade Of Service
The concepts of "Sales" and "Service" are so closely interlinked
that we seldom bother to notice that they are quite separate and
distinct ways of operating a business. If we think about the matter
at all, we almost always think of a business as selling a product
which, in our optimism at the moment of purchase, will never break
down and need to be serviced. But many businesses are based on
selling a service, not a product and, as a result, have to be
thought about in a way that tends to be alien to our normal way of
considering economic concepts.
The classic example of a service-vending business, as opposed to
one that sells a product, is the telephone industry. Until recently,
telephone companies sold telephone calls, not telephone equipment,
and provided equipment to facilitate calling on a service rather
than sales basis; that is, you rented the ability to make phone
calls, not a telephone set, PBX, or some other piece of equipment.
The telephone company installed the equipment, maintained it, paid
taxes and insurance on it and, in many cases, even provided the
power to make it operate.
In the public telephone network, the telephone company still
provides switches with the ability to connect one customer line to
another, or a line to a trunk to another switch; trunks (individual
voice circuits shared by customers) are provided between switches to
assure the caller of a chance to reach any other telephone in the
country. The rules and mechanisms by which the switches select the
trunks required to establish any given connection are all part of
the package the customer normally never even has to think about.
But the telephone company has to give considerable thought to the
matter: how many trunks should be installed between Switch A and
Switch B? How many connections at any one time should a switch be
capable of supporting? How many signaling detectors are required to
return dial tone and accept instructions from people initiating (or
modifying) calls?
Clearly, it is always possible to put in lots of capacity to be
sure that any call that comes along can be served. But, with too
many facilities, many lying idle all the time, a system would cost
too much and might not be affordable to its customers. Too few
facilities, on the other hand, might be much less expensive, but
would block revenue-producing calls and reduce telephone company
income. Thus a relatively delicate balance is required: too many
facilities reduce customers by increasing cost while too few
facilities reduce calling by preventing call completion.
To put this in another form, consider the difference between an
automobile dealer and a rent-a-car company. The dealer wants to sell
as many cars as he can, so the number of cars he has available is
limited only by his floor space and the money required to support
his inventory. The rent-a-car company, however, does not sell cars.
It rents them. It must have enough cars on hand to meet the variable
day-by-day need, but not so many that a large proportion sit idly on
the lot, tying up capital and producing no revenue.
There is one additional point to consider in this analogy: if
people only rent cars when they need them, a rent-a-car company
needs far fewer cars to serve the same number of customers than does
a car dealer. For the dealer, one car serves one customer; for the
renter, one car serves many. Thus service organizations tend to make
more efficient use of some kinds of assets than do companies which
sell the same assets as product.
Another point of some interest is the fact that service companies
have a very strong motivation to make their serving systems work
because they only earn money when delivering the vended service.
Companies that sell product, however, are often relatively glad to
see a product break down so that they can sell their customer a new
item or fix his old one at a surprisingly high cost. Indeed,
automobile repair parts cost so much more than the same parts when
put into new vehicles that a whole new branch of crime has developed
in response to the need: the chop shop. Who says free enterprise is
dead?
In any event, we see that too few facilities turn away customers,
while too many can increase costs to such a point that customers are
again turned away. Thus we have to have some way of defining
"enough." The concept of Grade of Service is therefore basic to the
thinking of any person or company hoping to render a service for
profit.
Grade of Service relates the number of customers to the number of
servers. When we are talking about telephone trunks and people
making calls, the callers are the customers in question, and the
trunks are the servers. We can, equally well, think of servers as
being check-out clerks in a supermarket, toll booth personnel on a
highway or bridge, or cars in a rent-a-car lot. The Grade of Service
tells how well we serve our customers.
The terms used to describe grade of service need to be examined.
We usually look at the customers who do not get immediate service;
those who are blocked or are delayed in a queue. With luck, this is
a small number, and we can say that 5 calls in a hundred are blocked
and have to retry, or 20 calls in a hundred are delayed in a queue.
You will frequently hear grade of service described with a letter, a
"dot," and some numbers, as P.05 (read "P dot oh five"). The "P"
means that the Poisson probability distribution and its underlying
assumptions, to be examined in Chapter 2, are employed and the dot
05 means 5 calls in 100 find all trunks busy (ATB). Today, it is
more common to use the Erlang B distribution, and let "B.05" define
our grade of service. Obviously, this means we are going to use the
Erlang B distribution and its underlying physical assumptions which
give a slightly different meaning to 5 calls in 100 finding ATB. See
Chapter 3.
When we get into the subject of queuing calls, or making them
wait until a WATS line, for instance, is free to serve them, grade
of service must be defined differently. Although we could use the
definition that is analogous to the probability of blocking--the
probability that all trunks are busy is the probability that a call,
originating at random, will go into the queue to wait for a facility
to come free--this definition is less useful than defining how long
a call has to wait in queue before it is served.
Two standard definitions are used: the average delay on all
calls, called D1, including those calls that are not delayed at all
(they luck out and arrive when there is no queue and at least one
trunk is free), and the delay on only those calls that are delayed,
called D2. Obviously, D2 is longer than D1 because it includes no
calls with zero waiting time in queue. Another definition that can
be used is the number of callers waiting in queue. Analogous to D1
and D2, we have a Q1 and a Q2, where Q1 is the average number of
callers waiting, while Q2 is the average number waiting during ATB.
But we'll return to this in Chapter 4.
The thing to remember now is that we either define Grade of
Service as the proportion of customers that find all servers busy,
or else we define it in terms of the average wait for service when a
queue can occur. Typically, our dial-9 trunk group out of a PBX to a
Central Office should have a grade of service in the B.05 range.
B.01 is better than we need, and B.10 may make for problems. When we
use expensive facilities such as Foreign Exchange (FX) or WATS
lines, we approach things a little differently. We may permit a
higher probability of blocking or use a queue.
When we queue calls, we find that D1 less than 30 seconds or
greater than about 10 minutes does little to increase the number of
calls we can handle on a given group of trunks. With short duration
queues, there is a low probability of a circuit coming free during
the waiting interval, while with long duration queues, we already
have the circuits running full, and we can't pack them fuller, no
matter how long we wait.
Randomness
Traffic theory has its roots in probability, and like most
probabilistic things, it requires "randomness." In particular, we
assume that calls "originate individually and collectively at
random" in a "stationary random process." The phrases in quote
marks, trotted out at cocktail parties, can have a devastating
effect after three martinis, but all they imply is a spontaneity of
call origination where callers are not influenced by each other or
any common experience.
"Individually and collectively at random" can best be understood
by observing what it is not. For instance, if a flying saucer lands
on the company parking lot and, as a result, everybody picks up a
phone to call security, we do not have calls originating at random.
Similarly, the drop in phone rates at 11 PM leads to non-random
traffic patterns. Even waiting until midnight for these non-random
calls to be cleared implies a non-random origination of our own
call.
This arrival of calls at random is one of the most important
assumptions in traffic theory, but there is more to it. We still
have to deal with the "stationary random process" business. It turns
out that our traffic formulas do not hold if traffic is building up
as it does between 8 and about 9:30 in the morning in a business, or
is falling off as it does at lunch-time or after 4 PM. To be a
stationary random process, our call arrivals must fluctuate around a
constant average value. That is, there will sometimes be more and
sometimes fewer calls in the system, but the average is constant
over the study period and not building up or dying out.
For telephone traffic to be able to take advantage of the
mathematics of probability and statistics, we assume that calls are
placed at random--that is, every second during a study period is
just as likely as every other second to see one or more calls
originate. The probability that one or more calls end in a given
second is proportional to the number of calls in progress and the
average duration of a call, and is thus also pretty much random.
Statistical fluctuations around a constant average describe the
behavior of theoretical telephone traffic.
Holding Time
Additional assumptions concern "holding time." Holding time is
not, as some people believe, the time they are left on hold when
they call a busy company. Rather, it is the total time a server is
occupied with a given call. Paid holding time or conversation time
is something else again. It is the time your pay for when you make a
call, excluding dialing, set-up and ringing, sometimes known as
operating time. Note that we can occupy a coast-to-coast telephone
company (but not a specialized carrier) circuit for an hour and, if
nobody answers the call, we don't pay for it. Thus the conversation
or paid holding time is zero, although the telephone company's
traffic people will find their traffic recording equipment showing
an hour of use.
In any event, holding time is the time we occupy a trunk or some
other facility on a given call. And there has been a great deal of
study of how holding times behave, statistically. With ordinary
voice calls, we can measure the total use and the "peg count" or
number of calls made, divide, and get an average holding time. But
some calls are longer than others. Typically, we find a relatively
large number of short calls and a smaller number of longer calls;
the longer the call, the smaller the probability that it will be
present.
The mathematicians calls such a distribution "exponential" or,
properly, "negative exponential." A negative exponential
distribution of holding times says that there will be an ever
decreasing probability that a given call will last as long as or
longer than an ever increasing duration. Measurements actually made
on telephone calls over the years show that regular calls are,
indeed, distributed this way.
We can thus calculate the probability of a call lasting some
number of average holding times or longer by using standard tables,
or the exponential key on a hand held calculator. But it is more fun
to use a computer. Fire up your computer, put the disk in the slot,
and run EXPO. EXPO will immediately give you a table of
probabilities that a call will last longer than several selected
multiples of one average holding time. See Printout 1-1 in Appendix
IV.
We note immediately that any given call, if it exists at all,
will have a probability of 1.0 (100%) of being 0 holding times or
longer in duration, which seems sort of obvious. But is it as
obvious that a call has a 61% probability of lasting longer than
half a holding time, a probability of 0.37 of lasting longer than
one holding time, but only a probability of about 5% (.05) of being
longer than three holding times?
The program will now ask you how many holding times you would
like to investigate. Give it any number you like, up to 14, integer
or fraction. It will immediately respond with the probability that a
call will last that long or longer.
The ability to measure things in terms of holding times is very
important in studying traffic. However, we ultimately want to know
the probability that a call will last longer than 15 minutes, or
something definite like that. EXPO can help us. It should be sitting
there now, asking you how many holding times you want. Give it a
number bigger than 600, and it will break out of the loop to ask you
for call holding time in minutes. Not minutes and seconds, but
decimal minutes, such as 5.6 instead of 5 minutes and 36 seconds.
Give it a "real" average holding time, and you can now get the
probability that a call will last as long or longer than any number
of minutes you punch in. Give it different numbers of minutes, one
at a time, and see how it responds. Follow instructions on the
screen to terminate the run when you are finished.
The exponential nature of holding times has a number of
interesting consequences, two of which we will examine now, without
proof. First of all, let us suppose that we find a call in progress.
What is the probability that it will continue for one holding time?
It turns out that, no matter how long the call has been up, the
probability that it will continue for a given number of holding
times is the same as if the call had just started. To put it another
way, the continued duration of any call is independent of its past
duration. Odd but true.
As a direct result of the above, but again we will not make any
attempt to prove it (an exercise for the student?), the average
delay the first call in a queue will encounter when it arrives and
finds ATB is the average holding time on that trunk group divided by
the number of trunks. For instance, suppose we have 5 trunks to
Chicago handling 10-minute calls. When all trunks are found to be
busy, the average wait for one (any one) to come free is 5/10, or
half a minute. If we have 7-minute calls on a trunk group of 2, the
average wait for one to come free is 3.5 minutes. If we hold calls
in a 30 second queue before we let them overflow to some other trunk
group, the odds are pretty good that the 5 trunk group will, in a
specific instance, have a trunk come free before the queue times
out, but the odds are much less for the two-trunk group.
Exponential holding times have been studied extensively, and the
exponential model appears to be quite good for voice calls. However,
there are many types of calls or operations that are of relatively
fixed duration. The time required to dial a telephone number, for
instance, makes the holding time of a Touch-Tone detector very
nearly constant. There are a great many other traffic engineered
operations that have a nearly fixed duration: the time it takes a
directory assistance operator to help a customer, for instance, or
the time it takes a toll-booth attendant on a bridge or highway to
take a quarter. Thus the other holding time distribution that has
been given attention by the mathematicians is the fixed holding
time. The difference between fixed and exponential holding times
comes out mostly in the study of queuing; it turns out that, if
calls have a fixed length rather than one that is exponentially
distributed, the delay in a queue is, in general, somewhat less. In
data communication, packet switching, with packets of fixed length,
takes advantage of this.
The thing to remember here is that, for voice calls, we will
usually assume exponential holding times, while for many types of
data engineering as well as the engineering of some kinds of voice
switching equipment, constant holding times are more appropriate.
Traffic Units
Most of the troubles encountered by beginning students of traffic
come from the fact that the ancient Babylonians had 30 fingers on
each hand. At least it appears that they counted by 60s, what with
360 degrees in a circle, 360 days in a year, 60 seconds in a minute,
and 60 minutes in an hour. Counting by 60s instead of 10s is a real
bother.
When we measure traffic, we use some form of timer, and we
measure the total time a server or group of servers is occupied
during a study period. Thus we measure our traffic in seconds,
minutes, hours, or some combination thereof. The problems come when
we try to convert from 2.75 hours to minutes, or from 3.68 minutes
to seconds. Now, 2.75 hours is 2 hours and 45 minutes, so the total
number of minutes comes out to be 165. The number of seconds in 3.68
minutes is left as an exercise for the student.
In the early days, the main aspect of traffic dealt with staffing
switchboards. Thus time-and-motion studies were conducted by
efficiency experts clutching stop watches and measuring all the
different operations performed by a telephone operator. Most such
actions, such as plugging a cord into a jack, or looking up a name
in a directory, were completed very quickly, so measurements in
terms of seconds were quite satisfactory. When call durations were
measured, however, seconds were too short. Thus the intrepid traffic
engineers decided to simplify their lives by changing the size of
the minute. They created a minute that is 100 second long, and
called it a CCS for Hundred Call Seconds (well, C stands for 100 in
Roman numerals). This way they could deal with switchboards and
trunks in the same units, just by moving a decimal point around.
Nice, simple and clean. The telephone industry in North America uses
the CCS to this day.
When customers buy telephone calls, however, they do not
understand the CCS unit. Thus the telephone company and most of the
specialized common carriers print out telephone bills in terms of
whole minutes. To keep things simple (and to make more money), each
call is usually rounded up to the next whole minute so that
fractional minutes need not be considered. Thus, if you go one
second into the next minute, you pay for the whole thing (the
exceptions are quite rare, and will be flagged when they occur). Be
this as it may, minutes are used to measure traffic when we are
concerned with paying for it.
There is only one unit left. Hours. And that is the most
important one of all. Hours of use per month is much more tractable
than minutes or CCS, and WATS and the specialized services are
billed by the hour instead of by the minute. But there are other
reasons why hours are the best units to use. We will investigate
them right after we look at the concept of the "busy hour."
The Busy Hour
It was stated above that, for our traffic assumptions to work,
our traffic must be in statistical equilibrium; that is, it
fluctuates, but around a constant average value. The average itself
does not change during the study period. This suggests there are
limits on how long a study period can be.
If it is too long, we know there will be variations that are not
statistical but causal: we know that nobody is at work before 8 AM,
that traffic builds up during the business day but falls off at
lunch time, and then builds up for the afternoon until the five
o'clock whistle kills it, as suggested by Fig. 1-1. Thus a day is
too long a study period.
Fig. 1-1. Typical business day telephone traffic.
On the other hand, a one-minute interval, for ordinary telephone
voice traffic, is much too short. On a minute by minute basis, the
number of calls on a given group of trunks can be seen to fluctuate
all over the place, and any one minute is hardly representative of
anything.
So what do we do? We choose a study period that's not too long
and not too short, but just right. An hour turns out to be just
about what we want. It is long enough to give stable averages, and
short enough to miss the major daily causal fluctuations.
Specifically, it is longer than the average holding time per call by
about a factor of 10, but it is shorter than the main work intervals
in the morning and afternoon. Thus an hour is just about what we
want.
But which hour? Where should an hour start? For convenience, we
make measurements that often start at the hour. This permits sorting
collected data on just the hour. However, in the best of all
possible worlds, we would like to have two collection schemes in
progress, one starting and ending on the hour, and the second
starting and ending on the half-hour. These overlapping hourly
intervals would help us find more accurately the actual busiest
period during the day, but as yet most PBXs and stand-alone data
collection systems do not have such flexibility.
Why not measure in terms of half hours? Well, a shorter period
doesn't give as big a sample, and in any statistical operation, the
larger the sample, the more confidence we can have in the averages
and other values we measure and the extreme values we choose to
estimate. Second, we want the study period to be as much longer than
the average call holding time as possible to minimize the impact of
the small number of very long calls that may occur. Finally, "hours
of use per hour" is a very nice unit. It does not need any sort of
multiplying factors such as the 36 per hour with CCS or 60 per hour
with minutes, and it translates directly into many other useful
concepts. An hour of use per hour has a name: it is called an
Erlang, after the Danish mathematician and telephone engineer, A. K.
Erlang, who, back just after the turn of the century, developed many
of our standard traffic formulas.
One other point. We look for the busy hour because, if we can
handle our traffic then with a satisfactory grade of service, the
"side hour" traffic can take care of itself. One of the most common
approximations in business communication is the rule that the busy
hour is one sixth of a day's traffic, or 6 busy hours equal one day,
as suggested by Fig. 1-2. Expressed as a percentage, this comes out
to 16% or 17%, depending on how you like to round numbers off.
One-sixth is actually 0.1666666666... as far as you want to go. But
note that this rule of thumb is just that, an educated guess. It is
usually better to use actual measurements rather than estimates, if
you have them available. But when you have only daily traffic,
dividing by 6 is a better approximation than most.
Fig. 1-2. Suggesting six busy hours = one day.
At this point, a word of warning is in order. Much traffic data
is collected and sorted in ways that do not reveal the true busy
hour. For instance, call detail recording systems, recording
bill-back information, are sometimes sorted monthly to obtain data
for traffic engineering. All calls originating between 7 and 8, 8
and 9, 9 and 10, etc., are totaled in similar registers, without
regard to the days on which they occurred. If these totals are
divided by the number of business days per month, a daily pattern is
obtained; however, in such a pattern, the "busy" hour is obviously
an average busy hour, and may fall far short of the true busy hour.
Where causal factors make, say, the first week in the month much
heavier in telephone use than the remaining three, this can lead to
disaster.
There is another approximation relating to busy hour traffic that
is often employed: 22 business days equal one month. When dealing
with a general month in network design, this is a good
approximation, leading to the "magic number," 132. Obviously,
22*6=132, and suggests that the busy hour can be approximated from
monthly traffic by dividing monthly hours of use by the magic
number. However, for any particular month, particularly when used as
a source of data, care must be taken. The exact period involved must
be known (carriers seldom bill by the calendar month), and the
actual number of days worked during that period must be counted.
Fig. 1-3 plots over the period of a year the actual traffic from
months of varying lengths (dotted curve), and what that traffic
would have been if all months had been 22 days long (solid curve).
The difference is seen to be quite striking. To get the smoothed
(solid) curve, one divides by the actual number of days worked to
get the average traffic per day, and then multiplies by 22.
Fig.
1-3. Actual monthly traffic vs. traffic from 22-day months.
There are some interesting variations between busy hour and side
hour traffic, which we will return to in greater detail later. For
now, we simply want to note that first choice trunks get a larger
proportion of the available traffic in the side hours than in the
busy hours. This can be understood intuitively by noting that a lone
overtime worker, when making telephone calls, will always get the
WATS line and will never overflow to toll. During the day, however,
when much more traffic is present, the WATS line or any other
facility cannot handle more than one call at a time, and more than
one hour of use per hour (one Erlang). This translates to 60 minutes
or 36 CCS per hour. That is tops. So a bigger proportion of the
offered traffic will go on to the next choice circuits.
The Erlang
So now we can return to the Erlang as a traffic unit. What does
it mean and how can we use it? Well, for starters, let's assume we
have exactly one trunk and every hour we measure the traffic it
carries. Suppose we find it busy for 45 minutes. This would be 2700
seconds or 27 CCS, but it is also three quarters of an hour, or 0.75
Erlang. Which number, 45, 27 or 0.75 is the most useful? I vote for
0.75, because this number tells us the occupancy of the trunk during
the hour in question. We know it is running at 75% occupancy, and
thus is unused for 25% of the hour.
Now, suppose we have a group of 5 trunks, and our measurements
say we are carrying 3 Erlangs of traffic. The average occupancy per
trunk is 3 divided by 5, 0.6 or 60%. Now 3 Erlangs is 180 minutes or
108 CCS. But knowing we have 108 CCS on 5 trunks, we cannot find
percent occupancy as easily; we first have to divide by 36. This
illustrates our first major advantage of Erlangs over CCS or minutes
of use per hour. It lets us estimate occupancy of our facilities
easily, simplifying management by telling us how effectively we are
using our resources.
But we get even more. If we are carrying 3 Erlangs on a group of
trunks, we know that, on the average, 3 calls will be in the system.
This is what the Erlang means...the average number of calls in
progress at any one time. If we measure 14.73 erlangs on a big trunk
group, we know that sometimes we had more and sometimes we had fewer
calls in progress, but over the hour, the average number of calls in
progress is 14.73. So the average occupancy during the hour and the
average number of calls in progress is seen to be the same thing, as
long as we measure in hours of use per hour, or Erlangs.
Consider an example. The Dimension 400 PBX has a switching matrix
(the equipment that connects extensions to each other and to trunks)
that can handle 1700 CCS in a busy hour. What does this mean? We can
find out if we divide 1700 CCS by 36 to get 47.22 Erlangs, or about
47 calls present, on the average. Bell uses the Poisson tables (to
be discussed in Chapter 2), and if we look up 47 Erlangs, we find
that 64 servers will provide a grade of service of about P.01.
Looking further at the Dimension, we discover that it has 64 time
slots and can, as a result, handle 64 simultaneous calls, maximum.
It seems to me that 47 calls on the average relates more reasonably
to 64 time slots than does 1700 CCS.
In most traffic formulas and tables, traffic is represented by
the letter A, either upper or lower case. Why A? Why not E for
Erlang? Well, the name Erlang was attached to the traffic unit quite
late in the game, and A has another meaning. It represents the
Arrival rate, or the rate at which our calls, individually and
collectively at random, appear at the trunk group to demand service.
So what does 14.73 mean as an arrival rate?
We cannot tell without one more piece of information. We need to
know the average length of a call, so that we can tell how many
calls per hour 14.73 Erlangs implies. Assume we have 5-minute
holding times, on the average. We then convert 14.73 Erlangs to
minutes by multiplying by 60, and divide by 5 to find the number of
calls involved. When we do the arithmetic, we get 176.76 calls. This
is the average number of calls arriving per hour. To find the number
of calls per minute, we now divide by 60, getting 2.95. This is the
average arrival rate: 2.95 calls per minute arrive at our trunk
group expecting service.
We could have gotten this number a lot easier by not first
multiplying and then dividing by 60. That is, we could have divided
14.73 Erlangs by 5 minutes per call to get 2.95 calls per minute.
This suggests that 14.73 is the average arrival rate during one
holding time. Further, no matter what units the holding time is
measured in, we can find the arrival rate during one of those units
by simply dividing occupancy in Erlangs by the number of units per
call.
Example: If the average holding time per call is 243 seconds and
we still have our 14.73 Erlangs of use, the arrival rate is
14.73/243=0.0606 calls per second. In other words, the probability
of a call arriving in any given second is 0.0606. We will make
considerable use of this sort of thing later.
If calls arrive at the rate of 0.0606 per second, the reciprocal
of the arrival rate is the average time between call arrivals; here,
1/0.606=16.5 seconds. Mean time between call arrivals is more used
in data than voice engineering, but the relationship is useful to
remember. One more thing: we have been calculating arrival rate on
the basis of the traffic carried by our trunk group. Carried traffic
is the only thing we can measure, but it differs from offered
traffic in that sometimes all trunks will be busy and not all the
offered traffic will get through. Thus some traffic will be lost. So
what we have been figuring is the arrival rate of successful calls;
what we really want is the arrival rate of all calls, including
those that are lost. Further, the A that occurs in traffic formulas
is for offered traffic, not carried traffic. There is a difference,
and we will come back to it several times before we're done. Note
that, if we have a good grade of service, the difference in offered
and carried traffic is quite small (like 5% for a grade of service
of B.05).
Just as arrival rate and mean time between call arrivals are
reciprocals, so holding time and service rate are reciprocals. If we
have five-minute calls, each server is serving them at the rate of
12 per hour, five minutes being one twelfth of an hour. The rate at
which we service calls is the rate at which they depart the system.
Thus at any instant, the departure rate is the number of calls in
progress multiplied by he service rate, or, what is the same thing,
the number of calls in progress divided by the average holding time
per call.
Summary
Let's remember what "traffic engineering" is supposed to help us
do: it is supposed to help us predict the future. We are using
measurements made in the past and inserting them into mathematical
models to predict future behavior of the system in question.
For example, suppose we have a "combination" trunk group of 17
trunks to take dial-9 traffic from our PBX to the central office,
and to bring incoming calls to our console attendant from the CO.
Everybody is complaining that they can't get out, and outside
callers say they can't get in. We make a measurement. We find the
traffic carried during the busy hour is about 14 Erlangs, or hours
of use during that particular hour. The Erlang B mathematical model,
to be discussed in Chapter 3 and summarized in Table I of Appendix
II, indicates that 14 Erlangs on 17 trunks is pushing a B.20 grade
of service; almost one call in 5 is hitting ATB or an All Trunks
Busy condition. This is not good. But what do we do about it? We
decide that a grade of service in the B.05 range will be about
right. How many trunks must we add?
Well, Table I, at Grade of Service = B.20, tells us that if we
are carrying 14 Erlangs on 17 trunks, the offered traffic had to be
about 18 Erlangs. Now, it is obvious that some of this traffic is
going to be retries, because so many people are not able to get out
on the first attempt. However, for the moment, we will pretend that
there are no retries. We will just assume that 18 Erlangs of traffic
is offered, and see how many trunks are required for a B.05 grade of
service. The B.05 section of Table I tells us that 23 trunks will be
needed. So we add six, and everybody is happy.
Now we can refine matters a bit. Table I tells us that when we
offered 18 hours to our original 17 trunks, the LOST traffic was
about 3.6 hours. Considerable study has been given to retries,
notably by James Jewett and others; Jewett's research indicates that
about 55% of the lost traffic retries. If we take 55% of 3.6 hours,
we get almost 2 hours of retry traffic. We pull this out of the 18
hours, and get what Jewett calls "First Attempt Traffic." That is,
the offered traffic is actually about 16 hours if we pull out the
retries. If we offer 16 Erlangs to 21 trunks, Table I predicts a
grade of service fairly close to B.05. So we order 4 trunks rather
than 6, save some money, and hope that things will improve when the
changes are effected.
Let's recap what we have done. We have measured the carried
traffic over what we hope is a busy hour; the carried traffic during
the hour (divided by 1 hour) is the average traffic per hour. The
study of statistics tells us that averages such as the mean value
are very stable and are good estimates of what is going on. They are
also easy to collect, and are thus relatively inexpensive. So we
measure averages, and use them to estimate maximum values. Here we
use the average number of calls in the system to estimate how many
trunks are required so that only about 5% of the time will calls
arriving at random find all trunks busy.
There are other measurements that we can make, and some of them
are less expensive than average values. One of the most common is
either a measure of ATB, or a count of the number of calls that
overflow our trunk group. If we knew the duration of the ATB
condition (measured in hours), we would have a direct measure of
grade of service using Erlang B as our mathematical model. Or, if we
knew the total number of offered calls, and divided it into the
number of overflow calls, once again we'd have a measure of grade of
service. But even if we did this, the results would not be too
satisfactory. Why? Because we are dealing with extreme values which,
under the same random conditions, will vary considerably from one
hour to the next. Thus they are not as stable as the mean value, and
they will not give us as reliable estimates of what we need to know.
To say it one more time, we measure mean or average values, and
use them to predict the probability of occurrence of extreme values;
then we size our systems accordingly. Grade of Service relates
Offered or Carried traffic to Number of servers required. That's all
there is to it...but, as we will see in subsequent chapters, it is
quite enough.
[
Top ] [ Next Chapter ] [
Table of Contents ] |
