Using the Erlang equation

How many lines do I need?

Using the Erlang Equation

When planning a private branch exchange (PBX) like Cactus, an audiotext system like CapiCall, a fax server like CapiFax, or a dial-in modem pool for remote access to a corporate server, there is a useful formula found by the Danish A. K. Erlang to find out the required number of lines. It also allows to guess how many operators must be in a call center to handle all or at least most incoming calls.

// Javascript: Percentage of busy
// calls with a=traffic and n lines
function erl(a,n)
{ u=1;
  for(i=1;i<=n;i++) u+=pow(a,i)/fak(i);
  return((pow(a,n)/fak(n))/u+0.005)*100
}
function fak(i) // Get factorial of i
{ k=1;
  for (j=1; j<=i; j++) k*=j;
  return k
}
function pow(k,i) // Compute k power i
{ w=1;
  for (j=1; j<=i; j++) w*=k;
  return w
}

Traffic units and busy probability

First of all, "Erlang" is a traffic unit, describing the total traffic volume of one hour. For instance, if you get 30 calls in one hour and each has an average duration of 5 minutes, the traffic figure will be (30 * 5) / 60 = 2.5 Erlang. It is obvious that you will need at least three lines to handle this traffic. But even then, due to the random nature of calls, you will still have a significant rate of callers who do not get through and hear a busy signal instead.

There are three common equations used for different situations. The one on the top right is called Erlang B with B = busy rate, A = traffic volume in Erlang, and N = number of available channels. Erlang B is the most commonly used traffic model, designed to evaluate how many lines are required for a specified traffic. The model assumes that all blocked calls are immediately cleared. If you are familiar with the C or C++ programming language, it should not be a big deal to understand our Erlang-B Javascript program computing the busy probability for a given Erlang traffic figure (a) and a number of lines or ISDN B channels (n).

Pole Extended Erlang B is quite similar to Erlang B, but it assumes that some calls are immediately represented to the system if they encounter blocking (a busy signal). Erlang C assumes that all blocked calls wait in a queue infinitely until they can be handled. We do not care about these two variants here since they cover situations which are unwanted under normal circumstances.

An Erlang-B calculator

To make it simple for non-programmers, here is a Javascript-based form using the Erlang B equation. Simply enter the average call duration you expect, the number of calls in the peak hour, and the number of lines you have. Note that one ISDN T0/S0 line has two channels, so enter 2 if you have one basic-rate ISDN interface (BRI).

Average call duration (minutes):
Number of calls in peak hour:		Busy probability:
Number of lines available:

The calculated "busy" probability is quite reliable as long as it is below 20 % (and no professional would accept a significantly higher rate in planning a PBX or audiotext platform, for example). It is interesting to see that an increased number of channels drastically improves the accessibility of a system.

There are a few things that must be kept in mind when using the Erlang equation. It assumes a randomly distributed traffic from a more or less unlimited number of potential callers. (The other extreme would be, for instance, if you have two lines and only two possible callers: These two people would never hear a busy signal.) A random distribution may not be always realistic since people tend to redial immediately when they hear a busy signal -- especially when using a modem instead of a telephone. In this case, the actual busy rate will be higher than the one calculated by the Erlang equation.

If you already have a number of lines and measure the traffic volume being handled by them, then you do not really know the possible traffic because some callers will be rejected due to busy lines. In this case, the calculation should be re-iterated. For instance, if you see 100 calls in the peak hour and the calculator says that the busy probability is 10 %, then increase the number of calls by these 10 % and enter 110 to recalculate the result.