Contents

Erlang - a unit of traffic Erlang traffic models Further reading A.K. Erlang - a tribute Conclusion

Erlang - a unit of traffic

An Erlang is a unit of telecommunications traffic measurement. Strictly speaking, an Erlang represents the continuous use of one voice path. In practice, it is used to describe the total traffic volume of one hour. For example, if a group of user made 30 calls in one hour, and each call had an average call duration of 5 minutes, then the number of Erlangs this represents is worked out as follows: Minutes of traffic in the hour Minutes of traffic in the hour Minutes of traffic in the hour Hours of traffic in the hour Hours of traffic in the hour Traffic figure = number of calls x duration

= 30 x 5 = 150 = 150 / 60 = 2.5 = 2.5 Erlangs

Erlang traffic measurements are made in order to help telecommunications network designers understand traffic patterns within their voice networks. This is essential if they are to successfully design their network topology and establish the necessary trunk group sizes. Erlang traffic measurements or estimates can be used to work out how many lines are required between a telephone system and a central office (PSTN exchange lines), or between multiple network locations.

Erlang traffic models

Several traffic models exist which share their name with the Erlang unit of traffic. They are formulae which can be used to estimate the number of lines required in a network, or to a central office (PSTN exchange lines). A formula also exists to model queuing situations, and lends itself well to estimating the agent staffing requirements of call centers. The main Erlang traffic model are listed below, with links to the free online calculators on this Web site:

Erlang B This is the most commonly used traffic model, and is used to work out how many lines are required if the traffic figure (in Erlangs) during the busiest hour is known. The model assumes that all blocked calls are immediately cleared. Extended Erlang B This model is similar to Erlang B, but takes into account that a percentage of calls are immediately represented to the system if they encounter blocking (a busy signal). The retry percentage can be specified. Erlang C This model assumes that all blocked calls stay in the system until they can be handled. This model can be applied to the design of call center staffing arrangements where, if calls cannot be immediately answered, they enter a queue.

Further reading
To investigate the traffic unit Erlang, and the Erlang traffic models, we suggest the following sources of information on this Web site:

1. Free online Erlang traffic Calculators

These online calculators allow you to perform Erlang traffic calculations now. The Call Minutes Calculator does not even require an understanding of the Erlang traffic unit, and allows entries in minutes rather than Erlangs. Detailed information is available in the Help area (press the Help button). Dimensioning Trunk Groups This white paper discusses a method of optimising the number of lines in a trunk group based on the traffic carried by that trunk group. This is known as dimensioning a trunk group, and uses the Erlang B traffic model.

2.

3. Call Centre Design

This white paper describes the steps involved in assessing the staffing requirements of a call centre and estimating the number of trunks (central office lines) required to serve a call centre for incoming calls. The suggested method uses both Erlang B and Erlang C.

A.K. Erlang - a tribute

Agner Krarup Erlang was born in 1878 in Lnborg, Denmark. He was a pioneer in the study of telecommunications traffic and, through his studies, proposed a formula to calculate the fraction of callers served by a village exchange who would have to wait when attempting to place a call to someone outside the village. In 1909, he published his first work: The Theory of Probabilities and Telephone Conversations. He gained worldwide recognition for his work, and his formula was accepted for use by the General Post Office in the UK. Erlang never married. He worked for the Copenhagen Telephone Company for twenty years, until his death in 1929. During the 1940s, the Erlang became the accepted unit of telecommunication traffic measurement, and his formula is still used today in the design of modern telecommunications networks.

Contents

Purpose Software tools required Designing networks Dimensioning trunks using Erlang B Reasons for caution Conclusion

Purpose
This white paper discusses a method of optimising the number of lines in a trunk group based on the traffic carried by that trunk group. This is known as dimensioning a trunk group and can be used to work out how many lines are required into a call centre facility.

Software tools required

In order to help you with your calculations, we have provided free online traffic calculators at this Web site which you can use now. A Windows version is available for immediate download at 89 US Dollars and offers increased speed, capacity and convenience.

Designing networks
A network cannot be properly designed without understanding the traffic patterns which that network will carry. In order to carry out a complete network design, a matrix of traffic figures between every combination of site on that network should be gathered. For each site, a traffic figure should be obtained for calls to every other site, and this information can be used to calculate between which sites network links should be installed. It is also common for traffic figures for calls carried over particular trunk groups to be retrieved from loggers. With existing networks, these figures are often used to calculate the optimum number of trunks for a group. Our opinion is that this practice is not a sound basis for network design for the following reasons: Call loggers can give a distorted view of the traffic on a link as they measure carried traffic rather than offered traffic. Changes to link capacities based on these figures can often be under-estimated because traffic models base their results on offered traffic. In other words, increasing the number of lines generates more traffic which needs more lines! Link traffic does not include those calls from callers who do not use the direct links because the grade of service is bad. Tweaking links as necessary avoids the central issue of network design which is to produce the most economical network layout. To design a network,

consideration should be given to locations between which links should be introduced or removed rather than changing the size of existing links.

Dimensioning trunks using Erlang B

Of course, this is a rather idealistic view. In the real world, links cannot be introduced and removed regularly and the voice network layout may depend upon other factors such as data traffic carried over a network with voice and data integration. So, a way of estimating the number of lines required for a known value of offered traffic is required. This is available in the form of the Erlang B traffic mode which requires the following inputs: Busy Hour Traffic Blocking

Busy Hour Traffic (B.H.T.) This figure represents the quantity of traffic expressed in a unit called Erlangs. For the purposes of these calculations, 1 Erlang can be considered equivalent to 1 hour of calls. You will need to provide an estimate for this figure, which represents the number of hours of traffic which is offered to a trunk group in its busiest hour. For example, if you know from your call logger that 350 calls are made on a trunk group, and the average call duration is 180 seconds, then the busy hour traffic will be: BHT = Average call duration (s) * Calls per hour / 3600 BHT = 180 * 350 / 3600 BHT = 17.5 Erlangs Blocking The blocking figure describes the calls which cannot be completed because insufficient lines have been provided. A figure of 0.01 means that 1% of calls would be blocked; this is a normal figure to use in traffic engineering. For some applications, 0.03 (3%) blocking is used. Example calculation Having established these two parameters, an estimate of the number of lines required can be made using the Erlang B Traffic Model. You can use our online calculator to work through this example now. BHT = 17.986 Erlangs Blocking = 0.01

Pressing the Calc button reveals that 27 lines will be required during the hour in question. Performing this calculation using our Windows product, Westbay Traffic Calculators is similar, but please refer to the user guide or help system for detailed instructions.

Reasons for caution

The Erlang B models makes certain assumptions about the nature of the call arrivals. Amongst them is the assumption that call arrivals are random (Poisson arrivals). Although this is quite reasonable in most applications, it can cause inaccurate results when there is a sudden peak of calls. This type of peak can be produced by a radio or television advertisement being shown and here drastic call peaks are expected, overengineering of trunks and call center agents should always be carried out - always be on the safe side! Our suggestion has been to obtain traffic figures from call loggers. Care must be taken when using this method. Extracting a figure for the traffic carried on a trunk group will often be sufficient, but it should be borne in mind that this figure would represent the traffic carried over a trunk group and not the traffic offered to a trunk group (that is, it would not include the traffic currently being blocked) - be careful! Lastly, it is important to note that the busy hour traffic figure should represent the busiest traffic load a trunk group will ever be offered. The trunk group being designed must be large enough to cater not just for today's peak, but for every peak. Therefore, extreme caution should be exercised when calculating BHT.

Contents

Purpose Layered model IP (Internet protocol) UDP (User Datagram Protocol) RTP (Real-time Transport Protocol) The complete header RTP Payload Conclusion

Purpose
This white paper describes the protocols involved in the transmission of voice samples through an IP based network. This document aims to give the reader the basic grounding that is required to further investigate the bandwidth requirements of voice over IP. This paper does not discuss header compression schemes, and does not discuss layer 2 protocols. Furthermore, this paper only considers IPv4 and not IPv6.

Layered model
In common with many communications systems, the protocols involved in Voice over IP (VoIP) follow a layered hierarchy which can be compared with the theoretical model developed by the International Standards Organisation (OSI seven layer model). Breaking a system into defined layers can make that system more manageable and flexible. Each layer has its job, and does not need a detailed understanding of the layers around it.

For example, IP datagrams can be transported across a variety of link layer systems including serial lines (using PPP), Ethernet and Token Ring. The link layer protocol is for the most part irrelevant to IP (unless that protocol limits the size of its datagrams), and need not be the same for the first link of a Voice over IP call and the final link of a VoIP call. As always there are exceptions (such as IP over ATM), but the simple discreet layered model will be considered in this document. The effect of each layer's contribution the the communication process is an additional header preceding the information being transmitted. The complete packet which a layer creates (header and data) becomes the data passed to the next level for processing. That layer will then add a header portion, and so on... Each layer, started at the Network (or Internet) Layer are considered in the sections which follow.

IP (Internet Protocol)
The Internet Protocol is the lowest level protocol considered in this document. It is responsible for the delivery of packets (or datagrams) between host computers. IP is a connectionless protocol, that is, it does not establish a virtual connection through a network prior to commencing transmission; this is the job for higher level protocols. IP makes no guarantees concerning reliability, flow control, error detection or error correction. The result is that datagrams could arrive at the destination computer out of sequence, with errors or not even arrive at all. Nevertheless, IP succeeds in making the network transparent to the upper layers involved in voice transmission through an IP based network. Any Voice over IP transmission must use IP (by definition). IP is not well suited to voice transmission. Real time applications such as voice and video require guaranteed connection with consistent delay characteristics. Higher layer protocols address these issues (to a certain extent). The diagram below shows the header that proceeds the data payload to be transmitted. In its most basic form, the header comprises 20 octets. There are optional fields which can be appended to the basic header, but these offer additional capabilities which are not necessary for VoIP transmission as described in this document.
0 1 2 3 4 5 6 7 8 9 101112131415161718192021222324252627282930 31 Octet 1,5,9... 1-4 5-8 9 - 12 13 16 17 20 Octet 2,6,10... Octet 3,7,11... Octet 4,8,12...

Versio n

Type of service Identification Time to live Protocol IHL

Total length Flags Fragment offset Header checksum

Source address Destination address

The fields shown are briefly described below: Version IHL

The version of IP being used. For this format header, the version would be 4. The length of the IP header in units of four octets (32 bits). For the basic header shown in this diagram, the value would be 5 (each line in the diagram represents four octets). Specifies the quality of service requested by the host computer sending the datagram. This is not always effectively supported by routers or Internet Service Providers. The length of the datagram, measured in octets, including the header and payload. As well as handling the addressing of datagrams between two computers (or hosts), IP needs to handle the splitting of data payloads into smaller packages. This process, known as fragmentation, is required because, although a single IP datagram can handle a theoretical maximum length of 65,515 octets, lower link layer protocols such as Ethernet cannot always handle these large packet sizes. This field is a unique reference number assigned by the sending host to aid in the reassembly of a fragmented datagram. These flags indicate whether the datagram may be fragmented, and, if it has been fragmented, whether further fragments follow this one. This field indicates where in the datagram this fragment belongs. It is measured in units of 8 octets (64 bits). This field indicates the maximum time the datagram is permitted to remain in the internet system. This parameter ensures that a datagram which cannot reach its destination host is given a finite lifetime. This indicates the higher level protocol in use for this datagram. Numbers have been assigned for use with this field to represent such transport layer protocols as TCP and UDP. This is a checksum covering the header only. The IP address of the host which generated this datagram. IPv4 addresses are 32 bits in length and, when written or spoken, a dotted decimal notation is used (e.g.: 192.168.0.1). The IP address of the destination host.

Type of service Total length

Identification

Flags

Fragment offset Time to live Protocol

Header checksum Source address

Destination address

UDP (User Datagram Protocol)

Generally, there are two protocols available at the transport layer when transmitting information through an IP network. These are TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). Both protocols enable the transmission of information between the correct processes (or applications) on host computers. These processes are associated with unique port numbers (for example, the HTTP application is usually associated with port 80). TCP is a connection oriented protocol; that is, it establishes a communications path prior to transmitting data. It handles sequencing and error detection, ensuring that a reliable stream of data is received by the destination application. Voice is a real-time application, and mechanisms must be in place with ensure that information is received in the correct sequence, reliably and with predictable delay characteristics. Although TCP would address these requirements to a certain extent, there are some functions which are reserved for the layer above TCP. Therefore, for the transport layer, TCP is not used, and the alternative protocol, UDP, is commonly used.

In common with IP, UDP is a connectionless protocol. UDP routes data to it's correct destination port, but does not attempt to perform any sequencing, or to ensure data reliability.
0 1 2 3 4 5 6 7 8 9 101112131415161718192021222324252627282930 31 Octet 1,5 1-4 5-8 Octet 2,6 Octet 3,7 Octet 4,8

Source port Length

Destination port Checksum

The fields shown are briefly described below: Source port

Identifies the higher layer process which originated the data. Identifies with higher layer process to which this data is being transmitted. The length in octets of the UDP data and payload (minimum 8). Optional field supporting error detection.

Destination port Length

Checksum

RTP (Real-time Transport Protocol)

Real time applications require mechanisms to be in place to ensure that a stream of data can be reconstructed accurately. Datagrams must be reconstructed in the correct order, and a means of detecting network delays must be in place. Jitter is the variation in delay times experienced by the individual packets making up the data stream. In order to reduce the effects of jitter, data must be buffered at the receiving end of the link so that it can be played out at a constant rate. To support this requirement, two protocols have been developed. These are RTP (Real-time Transport Protocol) and RTCP (RTP Control Protocol). RTCP provides feedback on the quality of the transmission link. RTP transports the digitised samples of real time information. RTP and RTCP do not reduce the overall delay of the real time information. Nor do they make any guarantees concerning quality of service. The RTP header, which precedes the data payload, is shown in the diagram below:
0 1 2 3 4 5 6 7 8 9 101112131415161718192021222324252627282930 31 Octet 1,5,9 1-4 5-8 912 Octet 2,6,10 Octet 3,7,11 Octet 4,8,12

V= PX 2

CC

PT Timestamp

Sequence number

Synchronisation source (SSRC) number

Version

Identifies the version of RTP (currently 2). A flag which indicates whether the packet has been appended with padding octets after the payload data.

Padding

X (Header extension)

Indicates whether an optional fixed length extension has been added to the RTP header.

CC (CSRC count)

Although not shown on this header diagram, the 12 octet header can optionally be expanded to include a list of up to contributing sources. Contributing sources are added by mixers, and are only relevant for conferencing application where elements of the data payload have originated from different computers. For point to point communications, CSRCs are not required. Alllows significant events such as frame boundaries to be marked in the packet stream. This field identifies the format of the RTP payload and determines its interpretation by the application A unique reference number which increments by one for each RTP packet sent. It allows the receiver to reconstruct the sender's packet sequence. The time that this packet was transmitted. This field allows the received to buffer and playout the data in a continuous stream. A randomly chosen number which identifies the source of the data stream.

M (Marker)

PT (Payload type)

Sequence number Timestamp

Synchronisation source (SSRC) number

The complete header

The headers of the three payload carrying protocols discussed are sent sequentially before the digitised voice or video samples, which are actually the payload the RTP header. The result is a 40 octet overhead for every packet of data:
0 1 2 3 4 5 6 7 8 9 101112131415161718192021222324252627282930 31 Octet 1,5,9... 1-4 5-8 9 - 12 13 16 17 20 21 24 25 -28 29 32 33 36 37 40 Octet 2,6,10... Octet 3,7,11... Octet 4,8,12...

Version

IHL Type of service Total length Identification Flags Fragment offset Time to live Protocol Header checksum Source address Destination address Source port Length Destination port Checksum PT Timestamp Synchronisation source (SSRC) number Sequence number

V= PX 2

CC

The headers are followed by a payload of digitised voice or video samples

RTP payload
The IP, UDP and RTP headers are followed by the data payload of the RTP header. This comprises digitised samples of voice and video. The length of these samples can vary, but for voice, samples representing 20ms are considered the maximum duration for the payload.

The selection of this payload duration is a compromise between bandwidth requirements and quality. Smaller payloads demand higher bandwidth per channel band, because the header length remains at forty octets. However, if payloads are increased, the overall delay of the system will increase, and the system will be more susceptible to the loss of individual packets by the network. This subject is discussed in more detail in the white paper Bandwidth requirements for Voice over IP transmission.

Conclusion
This document has detailed a common set of protocols used for the transmission of voice over IP through a local or wide area network. It should be borne in mind that there are other methods of transmitting voice through an IP based network. Some of these are vendor specific, and some are still under development by the Internet Engineering Task Force. Specifically, header compression and multiplexing techniques can go some way towards reducing the bandwidth requirement across a WAN.

Contents

Purpose Header overhead Packet frequency Simple bandwidth calculation Effects of coding algorithms Conclusion

Purpose
There are many factors involved when calculating the bandwidth required through a network. This white paper aims to explain these factors, and to offer a simple means of making such calculations. It starts with a basic 'rule of thumb', and then expands this to take specific voice coding algorithms into account. There are many ways to reduce the bandwidth requirements, and these can be particularly important in the wide area network. These include silence suppression, RTP header compression and RTP multiplexing. These methods are not considered in this document. You can try out the calculations described in this white paper by visiting our free Lines to IP Bandwidth Calculator. It can be used online, now.

Header overhead

In our white paper Voice over IP Protocols for Voice Transmission, we concluded that the standard method of transporting voice samples through an IP based network required the addition of three headers; one for each layer. These headers are IP, UDP and RTP. An IPv4 header is 20 octets; a UDP header is 8 octets and an RTP header is 12 octets. The total length of this header information is 40 octets (bytes), or 320 bits, and these headers are sent each time a packet containing voice samples is transmitted. The additional bandwidth occupied by this header information is determined by the number if packets which are sent each second.

Packet frequency
For the purposes of this document, we define packet frequency as the number of packets containing voice samples which are sent per second. The packet frequency is the inverse of the duration in seconds represented by the voice samples. For example, if the voice samples in one packet represent a duration of 50 milliseconds, then 20 of these samples would be required each second. The packet frequency would therefore be 20. The selection of this payload duration is a compromise between bandwidth requirements and quality. Smaller payloads demand higher bandwidth per channel band, because the header length remains at forty octets. However, if payloads are increased, the overall delay of the system will increase, and the system will be more susceptible to the loss of individual packets by the network. We know of no recommendations concerning packet duration. In RFC1889, the Internet Engineering Task Force include an example where the duration is 20ms, but they do not suggest this as a recommended value. There is no absolute answer to this question, but for the remainder of this document, we will assume that voice samples representing 20ms are sent in each packet.

Simple bandwidth calculation

If one packet carries the voice samples representing 20 milliseconds, the 50 such samples are required to be transmitted in every second. Each sample carries a IP/UDP/RTP header overhead of 320 bits. Therefore, in each second, 16,000 header bits are sent. Therefore, as a general rule of thumb, it can be assumed that header information will add 16kbps to the bandwidth requirement for voice over IP. For example, if an 8kbps algorithm such as G.729 is used, the total bandwidth required to transmit each voice channel would be 24kbps.

Effects of coding algorithms

The designer of any network convergence solution that includes voice will need to decide upon which coding algorithm to use. CODECs perform the conversion from an analogue voice waveform to a digital stream of information. They sample the analogue signal at regular intervals (125 microseconds is a typical value), and convert the measured analogue value into a numeric representation (known as quantising). The resultant output comprises discreet blocks of information sent at

regular intervals. The method suggested in the previous section offers a simplistic view of the bandwidth calculation process. It is valid for most coding algorithms, however, it assumes that voice samples can be transmitted within a 20ms datagram. For coding algorithms which use much smaller sampling periods, multiple samples can be sent within each packet, and the samples can be buffered for up to 20ms. However, some algorithms do not produce samples which can be fitted exactly into 20ms datagrams, and for those algorithms, the 16kbps rule of thumb becomes invalid. The following tables shows the relevant characteristics of the most common coding algorithms. Coding algorithm G.711 G.723.1 G.726 G.728 G.729(A) PCM ACELP ADPCM LD-CELP CS-ACELP Bandwidth 64kbps 5.6kbps 6.4kbps 32kbps 16kbps 8kbps Sample 0.125ms 30ms 0.125ms 0.625ms 10ms IP bandwidth 80kbps 16.27kbps 17.07kbps 48kbps 32kbps 24kbps

The algorithms listed which do not fit into the 16kbps rule of thumb are the two G.723.1 systems (highlighted on the table). As their sample duration is 30ms rather than 20ms, only 33 frames are sent each second. This reduces the header overhead to 10.66kbps. Detailed consideration of each coding method is beyond the scope of this document, but it should be understood that the various coding methods vary in the levels of complexity, delay characteristics and quality. The CODECs which are expected to become prevalent within the Voice over IP arena are G.729A and G.723.1.

Conclusion
This document has offered a quick method of calculating the bandwidth requirement for individual calls being transmitted through an IP network. As a rule of thumb, it is suggested that 16kbps be added to the compressed voice bandwidth to calculate the total bandwidth required. This assumes a packet duration of 20 milliseconds. G.723.1 requires special treatment, because its packet duration is 30ms. For a typical 8kbps compression scheme, the overhead is 16kbps (or 200%). Methods exists, or are being developed, which reduce this overhead. These include silence suppression, RTP header compression and RTP multiplexing. These will be the subject of further documents published at this Web site.

Contents

Purpose Software tools required Description of the design process How many agents do I need? How many trunks do I need? Reasons for caution Conclusion

Purpose
This white paper describes the steps involved in assessing the staffing requirements of a call centre and the estimating the number of trunks (central office lines) required to serve a call centre for incoming calls.

Software tools required

In order to help you with your calculations, we have provided free online traffic calculators at this Web site which you can use now. A Windows version is available for immediate download at 89 US Dollars and offers increased speed, capacity and convenience. Ansapoint is a call centre analyser which automates the design process discussed in this paper. It is available for immediate download for just 169 US Dollars.

Description of the design process

There are two distinct areas of design required in such an application. The questions which must be answered are: 1. How many call centre agents do I need? 2. How many trunks do I need? As call holding times depend upon average queuing times (which depend upon the number of agents deployed), the two questions must be addressed in the order shown.

How many agents to I need?

Calculating the number of agents required is a continuous process which will require regular reassessment as the circumstances of a call center change. Assessments may be made for each working hour of a day, and should take such factors as marketing campaigns and daily call peaks into account. We suggest performing a calculation for each working hour. In order to estimate the number of agents required in a particular hour, the following information relating to that hour is required as a minimum: 1. Number of calls received

2. Average duration of these calls 3. Average delay that you accept that incoming callers may experience. Items 1 and 2 describe the incoming traffic levels and must be established from call statistics or from estimates based on your understand of your business. Item 3 is your performance criterion. Another performance criterion which can be used defines call handling in terms of the percentage of calls answered within a target queuing time (e.g. 85% of calls answered within 20 seconds of ringing). This can be more meaningful and is supported by our Windows 95 / NT product, Westbay Traffic Calculators, but is not yet supported by our online calculators. Wrap up time (or wrap time) is the time an agent remains unavailable to answer a call after a call has been completed. It is usually the time taken to carry out administrative tasks relating to a call such as entering an order on a terminal. For the purposes of Erlang C, wrap up time should be included in average call duration. Having established these three minimum parameters for an hour, an estimate of the number of agents required can be made using the Erlang C Traffic Model. You can use our online calculator to work through this example now. Calls received in the hour 350 Average call duration 180 seconds (160 seconds duration + 20 seconds wrap up time). Average delay to all calls 25 seconds

Pressing the Calc button reveals that 21 agents will be required during the hour in question. Performing this calculation using our Windows product, Westbay Traffic Calculators is similar, but please refer to the user guide or help system for detailed instructions.

How many trunks do I need

Whereas the number of agents required can (and should) be dynamic, changing from hour to hour, the number of lines required to connect a call center with a central office exchange is fixed (at least in traditional circuit switched technology) and must cater for the maximum anticipated traffic levels which will be encountered. Engineering the number of lines required is known as dimensioning a trunk group. The Erlang B traffic model can be used to estimate the number of lines required. This traffic model requires the following inputs: Busy Hour Traffic Blocking

Busy Hour Traffic This figure represents the quantity of traffic expressed in a unit called Erlangs. For the purposes of these calculations, 1 Erlang can be considered equivalent to 1 hour of calls. The busiest hour must always be used for busy hour traffic calculations. But, wrap up time is not included. In working out the number of lines required, the busy hour traffic must be based on the duration of the calls and the queuing times as these

account for trunk occupancy; wrap up time does not occupy a trunk. Assuming our earlier call centre example represents the busiest hour, the busy hour traffic is calculated as follows: BHT = [ Average call duration (s) + Average delay (s) ] * Calls per hour / 3600 The resulting figure shows the total trunk occupancy in hours, including the average delay period during which calls are being queued in an ACD and occupying trunks. So, the busy hour traffic figure would be: BHT = [ 160 + 25 ] * 350 / 3600 BHT = 17.986 Erlangs It is important to note that the busy hour traffic figure should represent the busiest traffic load a call centre will ever be offered. The trunk group being designed must be large enough to cater not just for today's peak, but for every peak. Therefore, extreme caution should be exercised when calculating BHT. Blocking The blocking figure describes the calls which cannot be completed because insufficient lines have been provided. A figure of 0.01 means that 1% of calls would be blocked; this is a normal figure to use in traffic engineering. For some applications, 0.03 (3%) blocking is used. Having established these two parameters, an estimate of the number of lines required can be made using the Erlang B Traffic Model. You can use our online calculator to work through this example now. BHT = 17.986 Erlangs Blocking = 0.01

Pressing the Calc button reveals that 28 lines will be required during the hour in question. Performing this calculation using our Windows 95, Westbay Traffic Calculators is similar, but please refer to the user guide or help system for detailed instructions.

Reasons for caution

The Erlang B and C traffic models make certain assumptions about the nature of the call arrivals. Amongst them is the assumption that call arrivals are random (Poisson arrivals). Although this is quite reasonable in most applications, it can cause inaccurate results when there is a sudden peak of calls. This type of peak can be produced by a radio or television advertisement being shown (which can often be the reason for a call centre's existence in the first place!) Where drastic call peaks are expected, over-engineering of trunks and call center agents should always be carried out - always be on the safe side!

The Erlang C traffic model does not take abandoned calls into account, but if your call center is engineered correctly, this should not be a factor. It may cause a problem when attempting to use Erlang C to analyse an existing call centre with poor performance.

SECTION

Why design a voice network? Companies with no networks Direct Inward Dialling (DID / DDI) Private Circuits PSTN Overflow Tandem Switching Types of Private Wires Voice over data Virtual Private Network (VPN) Numbering Plans Conclusion

Why design a voice network?

Designers of private voice networks have two goals. Firstly, they want to save money. Secondly, they want to ensure that the users of their telephone systems, and perhaps more importantly, the people who call their company, get through on the first call. The telecommunications industry around the World is undergoing enormous changes. Countries are opening their markets to competition, which is allowing new companies to offer alternative services to their customer. With so many telephone companies (also called PTTs, PTOs, telcos and carriers) offering a wide variety of voice telecommunications services, there is certainly scope for many companies to make significant savings on their telephone bills. However, it is important to understand how much money each type of service can save your company.

Companies with no network

Many companies have offices in more than one town. Staff in each of these offices will almost certainly need to talk to each other by telephone. If these companies do not have private voice networks in place, then these calls will be routed over the PSTN. PSTN stands for Public Switched Telephone Network. It is the basic dialled service offered by almost all telephone companies.

Direct Inward Dialling (DID/DDI)

Calls into a building routed over PSTN are often answered by switchboard operators who then connect them to the required extension. An alternative to this exists which allows incoming calls to be routed directly to extensions. This service is called DID (or

DDI in the UK) and enables telephone users to publish their individual direct numbers rather than their company's main number. The advantages of DDI are that dialling between offices within a company is quicker and callers from outside the company who know the extension number of the person they want to speak to can call that person directly. This also means that companies can save money because they require fewer switchboard operators although a switchboard service is usually retained to some degree to cater for general incoming queries where callers do not know who they need to speak to. Although PSTN and DDI are very flexible and simple services, more economic solutions exist for companies which make high volumes of calls between their buildings.

Private leased circuits

Private leased circuits (also known as leased lines, private wires, private circuits and tielines) are direct connections between PBXs in two buildings. The two ends of these circuits can be in the same town or can be in different towns, or countries. Callers in one office can call users in another office by dialling a prefix code to access leased circuits and then dialling the users extension numbers. PTTs (telephone companies) charge a fixed rental for each private circuit. However, the calls made on these circuits are free. There is obviously a break-even point in the number of calls made between two offices at which point a private circuit connection between those sites becomes economically attractive. Another factor in the justification of private wires is the number of connections required. Unless PSTN overflow is used, sufficient circuits must be leased to carry all telephone calls between sites without being blocked. (Blocking is the failure of a call to connect because there are not enough lines). Callers who are blocked hear a permanently busy tone, even if the person they are calling is available.

PSTN overflow
A solution exists which avoids blocking if insufficient private leased circuits have been connected between two sites. Many telephone switchboards (PBXs) can be programmed to provide a more intelligent routing of calls between buildings. PABXs which have been configured for PSTN overflow will attempt to place calls between buildings over a private circuit if one is available. If all private wires are busy, calls will be routed over PSTN, the normal public telephone service. This option only works properly if the destination site has DDI, as previously described, to ensure that PSTN calls can be directly routed to the required extensions. PSTN overflow avoids callers hearing a busy tone (blocking), but if a network is designed professionally, it can also provide economic benefits. The more calls a private wire is carrying, the more money is being saved. However, if a private wire connection is required between two sites, sufficient lines must be provided to carry all traffic including the occasional peaks in traffic. The result is that some lines are almost constantly in use and so are paying for themselves but a few lines are only used occasionally and become an expensive overhead. If enough private wires are provided to carry the bulk of the calls, PSTN overflow can

be used to route the occasional peak traffic over the public network. The rental saved in removing the peak traffic private circuit easily outweighs the cost of putting calls on the PSTN which charges per minute, but working out the optimum number of private wires between two sites using PSTN overflow is a complicated task.

Tandem switching
Things become more complicated if a company has more than two buildings. Imagine a company with offices in New York, Chicago and Los Angeles. This company wishes to install private wires to route its internal telephone traffic (telephone calls). One option would be to install three routes (groups of lines) linking all sites in a triangle. That is: From Chicago New York Los Angeles To New York Los Angeles Chicago

Another option which would almost certainly be cheaper would be to provide the following two routes: From Chicago Chicago To New York Los Angeles

The PBX in New York would be programmed to route all private network calls to the tandem PBX at Chicago. When the call arrived at Chicago, the Chicago PBX decides whether the call needs to be onwardly routed to Los Angeles or can be terminated on a local Chicago extension. The advantage of this set up is clear: fewer private wires will be required between the East and West sides of the U.S.A and, as private wire rental is usually charged on a per distance basis, a cost saving would be realised.

Types of private circuits

Different types of private wires are offered by PTTs. Analogue private wires are basic individual connections between two sites. Digital private wires use a more modern transmission technology which group lines together in multiples of 30 (24 in the USA) and provide a single connection to the PABXs at each end. For situations where a high number of private circuits is required, it can often be cheaper to lease these circuits using a single digital link capable of carrying 30 individual lines because digital private circuits are always cheaper than 30 individual analogue private circuits. The decision to install a digital private circuit is usually based on a costing exercise although it should also be noted that digital circuits use a more modern technology which is more reliable and usually produces better quality connections.

Network convergence
For companies which operate a wide area data network, opportunities exist to share networking resources. Voice channels have traditionally been derived from TDM (Time Division Multiplexer) network equipment. However, recent improvements in technology are allowing voice communications to be established through ATM, IP and Frame Relay. Nevertheless, most voice over data solutions still involve the derivation of discreet voice channels from a data network which are connected to PBXs using traditional interfaces. Some networking equipment is now becoming capable of voice switching rather than just the creation of fixed voice channels. Instead of just passing a call set up through the network transparently, a network node can analyse the addressing information of the calls (either a private numbering plan or an international E164 number) and can route the call accordingly. Effectively, this solution moves the tandem switching function from a PBX to the wide area network, resulting in a reduced number of voice connections, and reduced hardware and transmission costs.

Virtual private networks (VPN)

Many telcos are now offering a modern alternative to private circuits which in many cases has great advantages over private circuits. Virtual Private Networking offers companies the advantages of private networking (with private wires) without the additional overhead of managing such networks. Links are provided between telco's and customer's PABXs in much the same way as a network of private wires except that the VPN network becomes the tandem site. PABXs are programmed to pass all calls to other buildings in their company onto these VPN lines. The VPN provider then sends these calls to the correct destination based on the number which the callers have dialled. The numbering plan for the company can be programmed into the VPN network by the VPN provider so giving the impression to users that a private network is in place. The charges made for a VPN service differ between the service providers but generally include elements of private wire costs and PSTN costs. A charge may be made for provision of the service; a charge may be levied per site and a fixed charge per line can be made. In addition to these fixed costs, which are usually lower than private wire costs, charges are made for calls made based on duration. This per minute charging is similar to PSTN but not as expensive. Another important cost advantage of VPN is that service providers are often eager to take calls to off-net locations, that is, locations which are not connected to the VPN and offer advantageous call rates for all calls made on the VPN lines. In this way, VPN can be considered an alternative to PSTN. It should be noted that modern wide area data networks can provide connections which are similar in nature to VPN in that they can switch calls. This moves the tandem switching functions away from PABXs and reduce the associated hardware costs.

Numbering plans

Numbering or dialling plans have been mentioned in previous paragraphs. A numbering plan is a structured system of extension numbers which extend across some or all sites within a company. It is the means by which one user dials another. It can consist merely of a four or five digit extension number, each site being allocated a unique range of number or it can include a site location code which is usually three digits. Here are two examples of numbering plans: Numbering plan with site codes Chicago Los Angeles New York 770 1000 to 770 1999 771 1000 to 771 1999 772 1000 to 772 1999

Numbering plan without site codes Chicago Los Angeles New York 1000 - 1999 2000 - 2999 3000 - 3999

Numbering plans can be programmed into PABXs which use private wires or can be given to a VPN service provider to programme into their network so they know where to route calls. With modern PABXs, numbering plans can even be used when the only service between company sites is PSTN (the public network) hiding the fact that there is no network in place. The advantages of numbering plans should not therefore be used to justify the move to any particular networking strategy.