[Lee Ann]

I’m trending traffic for a wireless TDMA network. We currently use the ErlangB to calculated required devices. We regularly debate “What is the definition of blocking, anyway?”. RF has the mindset that if a caller gets a fast busy, they will automatically retry immediately – and this is not a blocked call. Should I switch to using the EXTENDED erlang B calculator & does anyone know what the impact would be in advance? Do you agree with RF that a call is not blocked if the customer immediately retry’s and gets through? We have even modified our blocking formulas to be theoretical because of this issue.

thanx,
lee ann
Network Traffic Planning Engineer

[Donald R. Darden]

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.

[Donald Darden]

I suppose I would be remiss if I did not make another point here.

When I refer to data communications, I am referring to a very limited concept, where data communications directly competes with or co-exists with voice communications. Principally, this would be with dialup service or the use of PBX circuits to alternate between voice and data service.

But most data communications today is over data networks, and the concept of measuring Grade of Service has a whole different meaning in that context. For example, with voice or dialup connections, a call is blocked if you do not get a dialtone. Network connections are generally always on – there is no similarity to waiting for a dialtone. If a network route is fully committed, most networks automatically provide alternate routing. If a node is currently busy, the data may be buffered for a time before being transferred. Voice communications require a simultaneous connection at both ends – computing devices can store data until a pathway can be established. If data is corrupted or lost, it can be transmitted again automatically. A whole transaction is rarely lost, as lost or corrupted packets can be retransmitted with no apparent degregation of performance.

What my last employer referred to as GOS for Data Communications was in fact, merely a determination of how many packets successfully completed a trip one way out of a total of such packets that were attempted. This may be valid, but it is not related to measuring data service in accord to ErlangB.

Actually, I have a much more precise method of determining Grade of Service for Data and Voice Over IP services, but I was unable to convence my last management to incorporate my concept in their discussions with the government, so to my knowledge their method is still seriously flawed. But right now I am out of the game, and who knows if I will ever have a chance to introduce this concept in context again.

[Author]

Posts