The classical concept of ErlangB
was that a blocked call is a
blocked call, regardless. ErlangB does not concern itself with which calls get blocked, but with the fact that not all offered calls can be completed when the capacity of the trunk is exceeded. The ErlangB then determines approximately the percentage of calls that could not be completed based on the number of circuits that remain busy within the trunk group over a period of time. A P03 would mean that a percentage (3%), or a theoretical 3 out of a hundred calls would be blocked and not able to complete on a single attempt.
Since ErlangB takes into consideration the duration of calls, the longer the calls stay up on the average, the more capacity required in the trunk group, and hence the more calls would likely be blocked – exactly what you would expect in a real world situation.
Note that ErlangB does not include the ability to consider alternate routing impacts – if the telecom switch supports assigning additional routes to backup the primary trunk group, then the switch is capable of carrying the excess calls via alternate paths, but the calculations would only reflect the likelihood that those excess calls were blocked. That is because initially, alternate routing was not a feature found in the telecom switches of the day.
Consequently, ErlangB in its original form has less to do with current network behavour than it did in the pass, but it seems to be firmly entrenched in the present, regardless.
Another problem with ErlangB and the network structure it most closely reflects is that designing a static network based on Busy Hour Busy Day (2 pm on Mother’s Day) hardly holds true for an environment where data communications is increasingly replacing voice communications as the medium of information exchange. The mass of data communications usually originates in the late evening or night, and with information flowing around the world, it can be terminating during any segment of the day at the terminating end. Further, while some information feeds are continuous or at least cyclic, a huge segment of bulk transfers is sporatic and unpredictable. So picking a busy hour/busy day for a customer might require collecting and screening actual usage data for an extended period of time.
Not all data flows are syncronous, as the bulk of the data may flow in just one direction most of the time, but there may be spurts where some data flows in volume in the opposite direction. I used a peak-to-peak (p-p) variation on determining Busy Hour/Busy Day where I considered the maximum flow in either direction over a period of time, then summed the largest incoming with the largest outgoing to arrive at a worse case senario.
Another consideration is that customers are always modifying their processes, adding or changing their applications, and hense the data flows not only follow short and long cycles, but show behavour change over an extended period of time. Customers may start with high usage, then change operations and have the data flow taper off to virtually nothing. Or they may be slow to bring new applications into service, until suddenly they are over capacity and angry because of high blockage.
But most damaging to the service provider is that customer usage tends to be erratic and unpredictable. If you size to the maximum, you may avoid customer complaint, but you are likely to find that you cannot price actual usage to compensate for fixed access charges. It may make more sence to sell the service at a fixed price based on the capacity provided, but at a discount (which would still be higher than actual usage warrants).
By the way, I am a Systems Engineer, who also acted as a Systems Analyst, formerly with a major carrier. You have the distillation of about four years of experience in this area covered here.