In 1909, Agner Erlang, an employee of the Copenhagen Telephone Company, published a paper that used probability and statistical inference to describe how many calls may be made to a switchboard to reach destinations beyond the immediate community. These mathematical descriptions of caller behaviour were accepted by the industry. In fact, during the 1940’s the Erlang was adopted as a unit of measurement to describe the amount of traffic carried on a circuit over a period of time (usually 1 hour).
Canadian telecommunications guru Ian Angus described the theoretical approach in realistic, every day terms. If you get 3,200 calls in an eight hour day, simple arithmetic suggests that works out to 400 calls per hour. However, if the calls follow a typical distribution pattern 550-600 of them will arrive during the busy hour. The result is that calls bunch up during the busy hour and lines remain underutilized at other times.
In addition, to properly staff a centre to handle the calls, time needs to be allocated for post call activities, and breaks for the operators.
The Erlang, Part Deux
This theory has been expanded over the years and a number of variations have been developed. The Erlang B is a simple function that relates Busy Hour Traffic and numbers of trunks. The Extended Erlang B includes a consideration of the impact of multiple attempts when the initial call is blocked. The Erlang C formula was developed to calculate the number of agents required for a call centre if quantity of call, call duration and average delays are known.
AT&T and Bell used a variation of the Erlang theory that used “CCS” (one hundred call seconds) as the unit of measurement. The CCS is still being used today for traffic studies on PBX facilities. To convert between CCS and Erlangs, divide the CCS number by 36. (Explanation: 36 CCS is 3600 seconds which is the number of seconds in an hour. A one hour call using one facility is 1 Erlang and similarly is 36 CCS).
How does this relate to IP Communications?
As IP communications became the defacto standard for PBX communications, conversion formulae were created to convert trunks into IP bandwidth which used the Busy Hour Traffic, coding algorithms (compression) and acceptable blockage as inputs. A basic calculation reveals that 1 Mb of bandwidth could support 35 Erlangs assuming “standard” 8kbs compression.
So what is different about Unified Communications?
The evolution of Unified Communications (UC) introduces additional complexity into the philosophy of traffic analysis and design. The basic paradigm of UC implies that a users should be able to communicate in any form on any device.
A fully deployed UC environment is far more complex than simply re-routing calls to a cell phone or providing e-mails to a contact centre agent. Not only can a UC deployment touch all seven layers of the ISO data model, but the basic paradigms of call processing are affected.
A Couple of Examples
As the first example, a Blackberry user initiates a call to a traditional telephone. The methodology for processing this call will be dramatically changed in a UC environment. When the user initiates a call, the UC application loaded on the device uses the IP network to signal the IP-PBX that the user is initiating a session.
When the communication is initiated, the IP-PBX translates the dialed numbers (rather than the cellular provider) and the call is placed using the IP-PBX facilities; servers and call processing rules. When a talk path is established to the destination number, the IP-PBX completes and monitors the connection.
The various elements involved in the Blackberry session would include a cellular talk path; IP overhead for the UC application; equivalent bandwidth within the IT infrastructure in the home office; various software applications utilized to route the call and add feature functionality; and, access to the traditional telephone (POTS) network.
In the second example, a softphone application on a laptop in a branch office establishes a multi-port conference bridge involving internal and external parties.
The UC application on the laptop simulates the functions of an IP telephone set and leverages the servers in the home office to select the attendees and establish the conference bridge.
The conference bridge establishes the connectivity using a combination of internal bandwidth, access to outside telco facilities and WAN connections.
The WAN facilities are leveraged to include internal users in branch offices to access the telco network which minimize costs.
At a macro-level, the assumptions regarding the traditional approach to predicting call flows need a significant overhaul. Consider the complexity of predicting the network design and size for an organization with over a thousand users with regular and part-time road warriors, several branch offices and a virtual contact centre.
In fact, since the communications network has become integrated with the business rules of the organization and the profiles of the users, there must be careful analysis of the organization and how they conduct business as a key component of the design. Even if the Erlang approach is considered for specific applications, such as sizing a contact centre, the introduction of multimedia functionality and skills based routing need to be included as mitigating factors as well.Clearly, the network/telecom design is an iterative process where careful prediction analysis is required by experienced professionals for the initial deployment.
However, as IT professionals become familiar and comfortable with the UC tools, network analysis, telecom traffic engineering techniques and tools, they can provide insight into the network evolution and what is required for the short and long term infrastructure.
Final Thoughts
The introduction of UC in organizations can improve the ability to conduct business and improve the overall communications experience across multiple types of devices and preference.
However, the process of traffic analysis and architectural design is not an ‘out of the box’ solution, as we learned from our own and recent client UC deployment projects. It takes experience with UC deployments and an understanding of each organizations’ business rules to properly design and implement these complex, multi-technology solutions.
Early VoIP deployments going back to 1997-2003 had issues as a result of a lack of understanding of the relationships between IT, network infrastructure and voice prioritization.
It will be critical to understand the relationships of the various media types, devices and user behaviours in order to design, deploy and manage the various parts of the ICT infrastructure required for unified communications applications.
From our experience using and deploying this emerging next generation technology applications over the last year and a half, we strongly believe that UC solutions are also the first real technology solutions that will finally deliver REAL business and personal productivity benefits from the IT investments. It’s about time eh?
As always, we welcome your comments and feedback. You can contact me at Roberta.Fox@foxgroup.ca.