Rapid System Engineering Assessment of Voice-over-IP Deployment

Rapid System Engineering Assessment of Voice-over-IP Deployment Decisions

Technology Review Journal • Spring/Summer 2005 57

Rapid System Engineering Assessment ofVoice-over-IP Deployment Decisions

John Y. Ma, Hoi Y. Chong, and Mark E. SchultheisNorthrop Grumman Information Technology

Deploying a voice-over-Internet Protocol (VoIP) system for a corporation is acritical business decision. One of the most important challenges is to developthe specifications of the VoIP traffic, performance, security, and network infra-structure requirements, while taking implementation, operation, and mainte-nance costs into account. Typically, the decision requires an in-depth analysisof requirements, the corresponding system characteristics, and a detailedevaluation of return on investment (ROI). Such analyses are costly and oftenlead to a delay in considering VoIP as a viable approach.

This article presents a system engineering approach to VoIP analyses thatallows an organization’s management to use nominal data, modified as neededto reflect organization-unique requirements, to assess the potential of VoIP andreach a quick decision on deployment. Our approach focuses on areas thatcurrently lack a standard, simple methodology. It first evaluates the benefitsand uses of the given application of VoIP. Then it assesses the costs involvedand the potential ROI. If VoIP appears attractive, procedures are provided toenable system managers to quickly generate an initial set of requirements.Those requirements can then be refined in an iterative design process and theevolving performance and benefits of VoIP can be continually checked againstthe costs. Our experience in applying this approach internally for NorthropGrumman and externally for clients has demonstrated that the staff effort for theinitial assessment of VoIP potential can be as small as one-fifth that for aconventional, detailed deployment analysis.

Introduction

Voice over Internet Protocol (VoIP) describes the transport of voice traffic over IP-basednetworks. Long past the “hyped” phase, VoIP technology is now being deployed overconverged enterprise networks (CENs), which simultaneously carry voice, data, video,and emerging multimedia traffic. Conventional analyses are time-consuming and costly.No standard approach allows quick, easy, consistent definition of requirements and thecorresponding costs and benefits of VoIP in CENs.

Considering VoIP’s potential value to an organization, the lack of a method of quickassessment presents a critical problem, because a detailed analysis may be difficult tojustify. For a 1000-person organization, such an analysis could take over six staff-monthsof effort—just large enough to delay that analysis during times of tight budgets. What isneeded is the ability to make a first judgment, based on a smaller effort of five staff-weeksor less. If the initial assessment is positive, then investing in the more detailed assessmentmay be warranted. A system engineering approach can help by focusing the assessmenton key factors in the decision, such as the volume of voice traffic, requisite voice quality,service availability (uptime), and security.

http://www.ms.northropgrumman.com/PDFs/TRJ2005/05SS_TOC.pdf


Technology Review Journal • Spring/Summer 200558

For an effective but quick assessment, the system engineering methodology presentedhere is comprehensive, using nominal data in areas not sensitive to the data values andmodifying the nominal data in areas where unique organization requirements are sensitiveto design parameters. The nominal data, along with the guidelines for selectively tailoringthe analysis to the unique characteristics of the organization, fill a gap where a simple,standard methodology is needed. Our approach provides guidance on developing aninitial set of VoIP requirements and assigning nominal costs for those requirements. Thenominal costs are based on industry experience, and can include organization-specificexperience data and vendor data supplied to the organization. The methodology alsoshows how to modify the nominal cost to account for nontypical requirements.

Getting started is straightforward, requiring only the site locations and number ofemployees at each site. From that, the telecommunications manager can generate a set ofnetwork design requirements for traffic capacity, voice quality, availability, and security.Nominal costs can be assigned to those requirements and atypical requirement costsintroduced. If the initial set of requirements and their associated costs indicate a benefitfor implementing VoIP on a CEN, then the organization is justified in spending resourceson more detailed requirements or even proceeding to deployment. It is an iterativeprocess, in which the indicated decision at each cycle is rechecked in the next cycle asadditional cost information is generated.

Currently, VoIP is governed by two competing sets of protocol standards. The systemengineering methodology described in this article is transparent to both protocols:• H.323, from the International Telecommunication Union, Telecommunication

Standardization Sector (ITU-T), is the older standard, derived from the videoconferencing standards over IP packet network.

• The Session Initiation Protocol is a standard proposed by the Internet EngineeringTask Force.

Our method was developed in a Northrop Grumman Information Technology sectorInternal Research and Development (IR&D) project and applied to the sector’s owntelecommunication systems and those of its clients. The method broke deadlocks overthe commitment of funds for more detailed analyses and facilitated earlier decisions ondeployment of VoIP.

Decision Process for Deployment of VoIP

Figure 1 shows the steps in the initial analysis and decision processes that guide thedeployment of a converged voice and data network. The key for success is to haveguidelines and data sources that can be used to generate reliable estimates of cost andperformance. That information is provided for VoIP design areas where new concepts andtechnologies have emerged over the past few years and where, to date, reliable proce-dures for quick, low-effort assessments of VoIP net benefits have not yet been defined.

Our overall approach comprises the following steps, detailed in the subsequent sectionsof this article:• Analysis begins with the definition of the potential uses of integrated data and voice

networks. Based on that definition, the basic benefits—both business performanceand cost savings—can be identified by type. We discuss the range of benefits thatshould be considered in an initial analysis to properly evaluate the full range of CENcapabilities.



• The next step is to estimate the savings with the CEN implemented. Then the returnon investment (ROI) can be assessed. We describe an approach for quick ROI calcu-lation, including sample data that can guide the analyst in projecting cost savings.With the benefits identified by type and quantified where possible, managementshould review the results and determine whether the argument is strong enoughto warrant more detailed definition of requirements for either a full implementationor a pilot installation.

• Still in the first cut, the analysis would then estimate the projected traffic; the requiredbandwidth, circuit size; the quality and customer satisfaction of the voice service; theavailability of circuits and associated built-in redundancy; and the security require-ments. No accepted standard exists for easily computing the requirements for any ofthose areas, so we provide quick assessment methodologies.

• After the first iteration, management can direct a full analysis of detailed require-ments for a complete CEN system or a pilot, or request refinements on specific areas.The complete cycle of activities to design and implement a VoIP system involvessubsequent preparation of requests for information (RFIs) from vendors, preparationand issuance of requests for proposal (RFPs) from vendors, proposal evaluation,deployment planning, and implementation.

Figure 1. Decision process for deployment of converged voice and data network

Define PotentialUses of Integrated

Data and VoiceNetworks

Identify ConvergedNetwork Benefits

Define Costs of andSavings Due toComponents

••

Implementation costs

Operation andmaintenance savings

ROI Analysis

ManagementReview of

Benefits and ROIResults

Recommendation forNext Level of Detail

Recommendation forPilot Program or

Full ImplementationDefine Requirements:

Traffic/bandwidth/circuit size

Quality

Availability/redundancy

Security

••••

Start



Potential Benefits of VoIP Converged Enterprise Network

The benefits of a CEN are not limited to reduced telephone costs or toll-bypass savings.Indeed, despite considerable toll-bypass savings for a few companies with an unusuallyhigh number of international calls, we believe that such savings will be insignificant formost organizations. The list of benefits is extensive:• Replace costly private branch exchanges (PBXs) that may serve only a few users in

a branch office.• Replace outdated PBXs with a much lower-cost and reduced-maintenance VoIP

system.• Combine the data communications and telecommunications staffs for operational

support and maintenance of a single, less costly CEN.• Facilitate more productive employee activities via applications such as collaborative

computing and integrated messaging.• Support multimedia applications, opening the possibility of cost-effective video

conferencing, video streaming, and other multimedia applications.• Support new business offerings.

Our article concentrates on the application of VoIP to civilian enterprises. For the military,VoIP is viewed as an enabling technology with a potential application in command andcontrol, providing improved integration of operational units. Those operational capabili-ties require special evaluation, taking into account the effect on military effectiveness, aswell as reduced cost.

The key decision variable for civilian enterprise is ROI, if VoIP meets all business require-ments. The following sections address the estimation of ROI and the questions that mustbe resolved in identifying the correct costs and benefits for a given situation.

Estimating Return on Investment

Our approach to estimating ROI has three characteristics:• Clear definition of the VoIP requirements that must be met if the CEN is to be effective

in supporting the business and achieving the benefits discussed above.• Establishing a clear link between the VoIP requirements and the cost and savings

values that go into the ROI.• A repository of information from which the cost and savings data appropriate for the

organization’s operations can be derived.

Successful applications of the methodology have shown that a nominal case can beconstructed, based on the general characteristics of VoIP implementations and informationavailable from the literature and vendor data. The nominal-case cost and savings valuescan then be quickly modified to reflect specific requirements. That is an effective approachfor quick generation of results, because the nominal case is relatively insensitive to anumber of factors:• Size is not a major factor in determining per-station costs for most organizations.

Economies of scale that might be expected as size increases are often offset by thecomplexity of the required CEN. The more detailed analysis that might follow theinitial assessment can check the validity of the assumption, but that is needed onlyif the initial review identifies unusual characteristics in the VoIP solution.



• It is appropriate to assume that at least the same level of voice quality, availability,and security of telephone service is achieved with VoIP as with the PBX system.As discussed later, the enhancements in equipment and circuit characteristicsrequired to meet business needs are easily identified. It is then a relatively quickprocess to modify the costs, using information from the repository. In two cases—traffic estimation and voice quality—we recommend the use of models. Revision ofthe nominal case for network availability and security can be done with standardengineering approaches, but we discuss the major issues (pages 73–75).

A great deal of information is available from the literature and vendors to support a rapidassessment; we present a representative sample in the references at the end of this articleand in the two sidebars (pages 64 and 69). Care must be taken, however, to assess theapplicability of such information to the specific organization’s requirements. For example,Fowler [1] presents information, summarized in Table 1, on a range of applications,considering the type of business and its sensitivity to service VoIP-related failures. Hisestimates of the monthly VoIP cost per telephone station include up to $1500 loss ofbusiness due to VoIP service interruption. Some businesses may need to consider accep-tance of some interruption, but most should design to the same service availability levelthat they have with their current PBX system, or better. The latter could be necessary ifnew types of service are required.

Systematic collection of supporting information in a repository is essential if the method-ology presented here is to be fully useful in decisions on deploying VoIP. As experience isacquired over time for different decisions, the analysts gain better understanding of thedata values that best represent their own organization. The information repository shouldcontain at a minimum the following information:• Published articles that address the costs and benefits of VoIP for the range of

applications addressed by the organization. The articles should include informationappropriate for internal use, as well as clients.

• Vendor information, much of which may be proprietary to exchanges between theorganization and its vendors. The repository should include information defining thevendors’ assumptions on service requirements.

Table 1. Representative monthly costs per telephone station

General estimates, cost per station

Case A. Small-to-medium (100 employees)non-risk-averse company with an obsoletevoice system

Case B. Large company (service industry) witha relatively new voice system, where a loss ofvoice service has serious costs and problems

Case C. Medium-sized organization with manyknowledge workers who are not technology-oriented

$700 to $2300

$800 perstation +

operational staff

$1150 perstation +

operational staff

$800 perstation +

operational staff

Case VoIPConventional

PBX

$600 to $1000

$750 per station

$700 per station

$700 per station

Source:The Telecommunications Reviewhttp:/www.mitretek.org/publications/2003_telecomm_review/03_fowler_2003.pdf.

T.B. Fowler, “So You Want to Deploy VoIP? A Decision Maker’s Guide,” Mitretek Systems,, Vol. 14, September 2003, pp. 19–31,



The VoIP repository discussed at the end of this article provides a core set of informa-tion to support an integration service company’s internal decision making, as well as itsrecommendations to government clients.

To support a first-cut analysis, we derived, from our repository of 2003 cost estimations, anominal VoIP per-station deployment cost of $1050. For practical applications, that valuecan be rounded off to $1000. The component estimates are listed in Table 2. We alsoestimated operations and maintenance savings as about $500 per station per year. Thosesavings are based on a judgment that combining the telecommunication and informationtechnology (IT) networks can reduce support requirements by two to three staff for a1000-person organization. The information is consistent with published data [1,2].

With such savings, costs can be recovered in two years when an existing PBX system isreplaced by VoIP. For a new building, however, a decision to deploy VoIP is more attrac-tive, since no PBX system would have been previously acquired. Based on our repositoryinformation, we estimate one-time additional savings of at least $600 per station for a newbuilding, because the cost of a PBX can be avoided altogether.

To reduce risk, a corporation can deploy a VoIP system in each building individually, as aVoIP island, with significant immediate operational cost savings but a slight performancepenalty, as shown by the methodology described in the next section. The operational costsavings are due to the expected IT department productivity improvement resulting fromthe voice/data network integration at each building.

In this deployment alternative, employees would complete outside calls via gatewaysconnected to the public switched telephone network (PSTN). The VoIP systems fromvarious buildings linked via VoIP wide-area-network (WAN) connections can be inte-grated later to realize the full benefits of a VoIP system, including the benefits of usingconverged applications. The full benefits of VoIP would be realized when interbuildingvoice communication is changed to VoIP.

The next step in the assessment of ROI is to tailor the nominal case to the specificrequirements of the business, as follows:• Estimate the bandwidth required to fully support business needs. The next section

discusses an approach for estimating traffic, using nominal values from the literatureto reflect the type of business (e.g., a call center versus an engineering firm).

• Calculate the trade-off between implementation cost and quality of service, addressedin the section “User Satisfaction and Perceived Quality” (pages 67–68, 73). Weassumed the same quality for VoIP and PBX services in the nominal case, but thecosts can be adjusted in accordance with the considerations given in the discussion.

Table 2. VoIP deployment cost components

VoIP handset

VoIP common equipment

Infrastructure upgrade

Initial training

Total deployment

$500 each

$300 per user

$150 per user

$100 per user

Component Cost

$1050



• Network availability must be equivalent to PBX system availability. The essentialelements of a reliable VoIP system are discussed in the section “Network AvailabilityIssues” (page 73).

• Identify the security requirements—which are discussed in the section “VoIP SecurityConsiderations” (pages 74–75)—in terms of the business decisions necessary toprotect company information. It is assumed that the analysis of security costs shouldbe based on each organization’s experience.

Estimating Traffic Volume and Bandwidth Requirements

A key requirement for any CEN network design and sizing is the estimation of trafficvolume for voice, data, and video. The estimation must be made for the WAN connectingeach company location (interlocation traffic), as well as the local-area networks (LANs) ineach location (intralocation traffic). The WAN traffic must also be distinguished betweenaccess and backbone links, as shown in Figure 2:• Each access link carries all interlocation traffic into and out of the location.• Each backbone link carries only the traffic between locations that must pass through

that link.

We assume that the data and video traffic for each company can be derived from the datarepository of its existing data network, using its existing standard methods, and thus donot warrant discussion here. However, voice traffic—the main focus of this section—is aparticular challenge, since it can be so variable, depending on coder-decoder (codec) andencryption options discussed in a sidebar, “Voice Traffic Model” (pages 64–66). Voicetraffic is typically measured in erlangs, the time-averaged value of the number of two-way conversations over a given period. For estimating bandwidth, however, we use the

Figure 2. Access and backbone nodes and links

Access node

Access link

Backbone node

Backbone link

BackboneNetwork Location 4

with N4 Users

Location 5with N5 Users

Location 2with N2 Users

Location 1with N1 Users Location 3

with N3 Users

(Continued on page 66)



Voice Traffic Model

Key Network Characteristics for VoIP

Access VoIP WAN traffic in bits per second at each location can be modeled as theproduct of three components:• The traffic requirement for each conversation• The projected percentage of time telephones are used by each user for interlocation

calls• The number of users at each location

In our derivations below, we combine the first two components that give the traffic in bitsper second per user. We then show how the VoIP CEN traffic requirements can be derived,based on traffic per user, multiplied by the number of users. To illustrate, we have usedrepresentative numbers and parameters to derive voice user traffic, listed in Table S1. Eachnetwork manager should adjust those numbers specifically for his or her network.

For VoIP, the busy-hour (BH) voice traffic per user can vary significantly, depending onthe type of voice coder-decoder (codec) used and the selection of other options, such asthe Compressed Real-Time Protocol (cRTP) and encryption. The packet or frame size andpacket frequency will directly influence the traffic requirements.

As an example, Table S1 lists traffic estimates for probable options per VoIP conversationover a WAN. The equivalent kilobits-per-second traffic is based on a 20-ms frame, withone frame per WAN IP packet, resulting in 50 packets per second to support the transmis-sion from each user codec. As shown in the bottom row of Table S1, the total VoIP over-head can be high. For the G.729 speech codec case, the size of the packet with overheadcan become 300% of the original packet for the case without encryption and 700% for thecase with encryption, using the IP Security (IPsec) tunnel mode. The G.711 speech codec

Table S1. VoIP traffic for two codecs over a WAN

Payload bytes per 20-ms frame

IP overhead bytesa

RTP and UDP overhead bytesb c

GRE tunnel bytesd overhead

IPsec bytes (in tunnel mode)overhead

20

20

20

NA

NA

160

20

20

NA

NA

20

20

20

24

56

160

20

20

24

56

Without Encryption With Encryption

G.729 G.729G.711 G.711

a

b

c

d

e

Internet Protocol

Real-time protocol

User Datagram Protocol

Wide-area network

Generic routing encapsulation

Packet Component

Total layer-3 bytes per packet

WAN -equivalent kilobits per seconde

Percentage of original codec signal

60

24

300

200

80

125

140

56

700

280

112

175



is for the standard 64 kbps voice traffic, whereas the G.729 codec is for the 8 kbps low-bit-rate version of compressed traffic. Table S1 shows the resulting WAN-equivalent valuesfor G.729 and G.711, for the cases with and without encryption.

Various methods can assist in reducing VoIP traffic, such as using a more bandwidth-efficient encryption, larger frame size, and compression and silent suppression schemes.It is more bandwidth-efficient to use encrypting audio streams via Secure Real-timeTransport Protocol (SRTP) rather than IPsec tunnel. VoIP traffic encryption is undergoingrapid change. Although the WAN-equivalent traffic can be improved by choosing longerframes—e.g., 40 ms, instead of the 20 ms used in our example—a longer frame would incura performance penalty due to increased end-to-end delay, as discussed below (pages 67–68). Clearly, this is an area for trade-offs.

In addition, cRTP would increase efficiency by reducing the overall packet size, as shownin our example in Table S1. However, cRTP needs a large router processing capacity.Another way to reduce traffic is to use voice activity detection (VAD) and silent suppres-sion. With VAD, voice traffic is not sent when the user is in a listening mode. That featurecan reduce traffic by 40% to 50%, but it makes VoIP performance sensitive to the packetloss rate, as discussed below. This article does not address encryption and compressionschemes, but those choices are trade-off issues to be considered in security assessments.Standard security assessments will provide sufficient information to adjust the trafficrequirements.

The traffic and capacity requirements have the following relationships: If the VoIP trafficlevel is known, the capacity requirement can be estimated with the existing Erlang Bcapacity sizing formula used in the public switched telephone network’s (PSTN’s) oldtime-division-multiplexing voice transmission. Assuming a 1000-telephone location with a3% telephone use at the busy hour for outside calls, an average of 30 erlangs of BH trafficwill have to be supported. Based on a simple table lookup in the Erlang B table [S1], wefind that this will require 42 trunks for 1% blocking. For a mixture of different types of VoIPlocal-area-network (LAN) traffic and VoIP WAN codecs with different settings, the totalVoIP WAN capacity requirement can be sized as the sum of the capacity requirement inkilobits per second for each type of codec and setting.

VoIP Traffic Estimates

Having selected the type of codec and determined the user population at each location,the next step is to derive the VoIP traffic in kilobits per second per user. Using Table S1 asa guide, we can make the following observations with respect to traffic and capacityrequirements per VoIP user:• 0.03 WAN erlang per voice user is equivalent to average traffic per VoIP user of

0.72 kbps (24 kbps for G.729 packet with no encryption times a 3% level of use).• 0.1 WAN erlang per user is equivalent to 11 kbps (112 kbps G.711 packet with

encryption times a 10% usage level).

Based on extensive analysis, we believe those two cases are extreme values. We foundthat the average voice traffic level per VoIP user is about 2 to 3 kbps during the busy hour.Similarly, intralocation VoIP traffic will be about 11 kbps, plus a small LAN overhead perperson, assuming that G.711 will be used for them. Thus, the total LAN traffic for bothintra- and interbuilding traffic will be less than 15 kbps per user. For a 100-user location,



if we assume that telephone use is 3% for outgoing calls, the total VoIP LAN trafficwill be equivalent to 1.5 Mbps. That value is one or two order of magnitudes less than theLAN connectivity capacity, which typically ranges from 10 Mbps for simple Ethernet to1000 Mbps for gigabit Ethernet. Since VoIP user traffic will be quite smooth compared withdata traffic, which is typically “bursty,” the effect of VoIP capacity requirements on LANinfrastructure will be small. However, VoIP does have a significant effect on LAN infra-structure, owing to the higher availability requirements of VoIP traffic, as discussed below(page 73).

The estimate discussed above will not be applicable to cases such as call centers with uselevels between 50% and 90%, which will have much higher kilobits-per-second transmis-sions, but the same methodology applies for linear scaling of traffic estimates, based onthe product of multiplication of the traffic factors. The determination of circuit size,however, depends on table lookup and is a nonlinear process. The total capacity is stilllimited by the case where all users are on the telephone 100% of the time. The voice trafficestimate can be different if we consider the effects due to VAD, with a potential of a 50%reduction, as well as the effects due to encryption, with possible variations of severalhundred percent (see Table S1).

Reference

S1. J. Davidson, T. Fox, et al., Deploying Cisco Voice over IP Solutions, Cisco Press,Indianapolis, Ind., 2002.

average busy-hour (BH) value, defined as the average peak hour use for three months.That value is available from operational experience and can be adjusted for planned newservices.

Also needed is the from/to WAN traffic matrix, which represents the traffic between loca-tions and is typically used for the backbone WAN design. The backbone node can beeither a corporate building or a carrier site. The WAN backbone can be a private networkor a virtual private network operated by a carrier. A from/to traffic matrix for backbonecircuits can be developed if we know what percentage of access traffic at each locationis expected to flow from and to every other location. Our first-cut approach takes thenominal percentage of interlocation traffic and defines the location-to-location compo-nents based on operational experience and knowledge of planned changes in businessoperations.

Typically, a location’s voice WAN access traffic requirement at busy hours ranges from0.03 to 0.1 erlang per user, which means that, at any given time, about 3% to 10% of alltelephones are being used to communicate with other locations. For heavy-use operationssuch as call centers, the level of telephone use may reach 50% or even as high as 90%.In such cases, a quick check of operational experience should provide a realistic nominaltraffic level for beginning the traffic analysis.

In all cases, three additional factors must be considered in determining the values ofaccess traffic for use in the cost of bandwidth requirement for the ROI analysis:• The traffic requirement for each conversation• The projected percentage of time telephones are used by each user for

interlocation calls• The number of users at each location



Together, those three factors help to determine the traffic volume and the level of use. Theactual bandwidth required to support the level of use can be significantly affected by thetype of voice codec selected, as well as optional selections such as the Compressed Real-Time Protocol (cRTP) and encryption. The “Voice Traffic Model” sidebar presents thedetails of the analysis and discusses the three factors noted above.

Once the access traffic has been estimated, the from/to matrix can be constructed. Back-bone traffic can be allocated to specific circuits quickly, based on operational experience.If the backbone traffic exceeds 10% of the intraorganizational traffic, then individual point-to-point allocations must be determined, taking into account both current operations andplans for new operations.

A key fact in CEN planning is that, today, the average WAN voice traffic level per user is2 to 3 kbps per user, as discussed in the sidebar, and is typically lower than the averageWAN data traffic per user. Based on our network operation experience and other industryreports, we found that in 2003 the average WAN BH data traffic of a typical office locationof a few hundred users is between 5 kbps per user for low-use cases and 10 kbps per userfor medium-use cases [3,4]. High-data-use cases typically have a much higher trafficrequirement per person. The greater use corresponds to the adopters and users of multi-media and converged applications. Moreover, the annual data traffic growth rate formultimedia and converged operations is expected to be 25% to 43%. The 25% and 43%annual growth corresponds to doubling every three and two years, respectively.

The typical annual growth rate of voice traffic is much less than that of data traffic. Thus,the major network traffic in a CEN will be data. Based on the comparisons of current andprojected voice and data traffic in the above paragraph and the “Voice Traffic Model”sidebar, we conclude that, with respect to capacity requirements, VoIP traffic can beaccommodated by the existing data LAN and WAN capacity, perhaps with a scalableupgrade. Typically, the upgrade will be less than a 50% increase in the overall capacity,not a very difficult technical requirement.

User Satisfaction and Perceived Quality

Without user satisfaction, the CEN cannot do its job. In this section, therefore, we discussthe relevant factors and how they influence the user-perceived quality. The industrystandard E-Model will help in understanding user-perceived degradation that in turndepends on various data communication performance degradations.

A major source of problems is analog facilities, which will exist for a long time. Therefore,for the foreseeable future, a VoIP conversation will still have to go through some analogfacilities, which can cause echo or reflection. The echo associated with a certain amountof delay, due to the distance between the point where the echo occurs and the talker, isbothersome to the talker. For a given level of echo, such user-perceived degradation willincrease as the delay increases. Typically, echoes are generated at hybrids in carriers’ endoffices—i.e., interface points at a carrier end office where two-wire loops to the customersmeet with four-wire trunks to the telephone network. Analog-to-digital conversion pointsin a customer location can also cause echo.

The other VoIP-related degradation is caused by packet loss in the LAN and WANnetwork due to congestion, bunching, or “burstiness” of data traffic. The lost packets cancause gaps and distortions in the voice signal. VoIP deployments use packet loss conceal-ment to minimize that problem.



Telephone companies measure user satisfaction with the mean opinion score (MoS) [5–8],developed in the very early days of telephony and used ever since. The MoS of a telecom-munication system is measured using a live tester, which provides a score of 1 to 5, with 5being the best possible rating. MoS measures user perception and accounts for the voicequality distortion due to the signal processing equipment, line noise, and echo/delay. Per-ception due to call setup and teardown performance is not included. Any MoS of 4.0 orhigher is generally considered to be toll-quality voice. For VoIP CEN, the MoS should beat least 3.6 for hard-to-reach remote locations, where bandwidth is very expensive.

In planning VoIP CEN networks, it is desirable to be able to estimate the voice qualityexperienced by a potential user before the network is deployed. Such an estimate permitsthe designer to make design trade-offs between the factors that affect user perception,network capacity, and performance in terms of echo, delay, noise, and intelligibility.

The quality of a VoIP implementation depends largely on the network infrastructure usedto transmit the voice packets. A CEN usually comprises codecs, switches, routers, LANs,and a WAN. Any component can introduce voice quality impairments due to speechcodec quantization and compression, network delay, and packet loss. The “E-Model”sidebar (pages 69–73) describes an approach to assess user-perceived quality before livetests can be run, allowing consideration of the quality factors and the costs needed toachieve desired quality levels in the ROI analysis.

If the CEN mouth-to-ear delay includes intranet WAN connectivity between locations, theend-to-end delay must be controlled. Our simulation and test studies have shown that, tocontrol the VoIP end-to-end delay and delay jitter, VoIP packets must be given priorityover data packets. Because voice traffic is smooth and data traffic is bursty, voice trafficwill have relatively little effect on data, if it has been properly accounted for in capacitydesign. The reverse is not true. In a CEN, therefore, voice traffic must be given precedenceover data traffic. The ITU recommended that the network end-to-end delay be less than150-ms and that echo cancellers be used if the end-to-end delay exceeds 25 ms. Thus,echo cancelers should always be used for VoIP calls.

It is interesting to compare our findings to those of Markopoulou et al. [9] dealing withtest measurements for VoIP over the Internet. Prioritization for voice traffic is not yetpossible over the Internet. Moreover, the Internet cannot be easily controlled with respectto congestion. Thus, packet delay, delay jitter, and packet loss are difficult to control andcan be problematic. We concluded that the Internet would be unreliable for VoIP, eventhough it is typically underutilized and would not impede data with delay or delay jitter.Markopoulou et al. have found that many of the Internet links in their test performedpoorly for VoIP.

In addition, a CEN should be designed to support the required load of VoIP and datatraffic. If the VoIP traffic exceeds the designed loading threshold, the excess traffic wouldhave to be prevented from entering the network, using call admission control, so as toavoid degrading the existing VoIP sessions’ voice quality and exhausting the networkresources. Such a situation would be rare, but call blocking should be in place to handleextreme cases.

(Continued on page 73)



E-Model: A Computational Model for Use inTransmission Planning

In the past, user-perceived quality of a voice service was based on the answers andratings provided by test users after using the service. In 2000, the International Telecom-munication Union (ITU) published the E-Model [S1,S2], which could be used to computeand predict mean opinion scores (MoSs) of a voice transmission system. The E-Modelcan be used before a service is developed and deployed, and without human testers.Several vendors have adopted E-Models in their VoIP performance measurement systems[S3,S4]. The E-Model is based on a 100-point R-value (overall transmission quality rating),and it provides a table to map back to a 5-point MoS. It can be used to estimate or predictuser-perceived quality rating, based on technically measurable parameters and networkperformance degradations such as loudness, noise, imperfection from digitization andquantization, end-to-end delay, echo, and packet errors.

Table S1 provides an interpretation of the scores used in the E-Model with respect touser perceptions. An R-value of 100 translates to an MoS of 4.5 and a toll-quality requiredR-value score of 70. It is equivalent to an MoS score of 3.6. A transmission with an MoSbelow 3.6 may be completely intelligible, but the scoring is based on user-perceived over-all experience, which includes degradation due to noise, distortion, and mouth-to-eardelay. Packet delay, delay variation, and packet loss are more prevalent in IP-basednetworks, and they could lead to additional mouth-to-ear delay, as well as distortions.Here we identify the factors that are important to user-perceived voice quality, how toquantify their effects, and, most important, how to mitigate them.

In the E-Model, the R-value score of a voice connection is based on 100, minus theaccumulated degradations due to various factors. That E-Model relationship can berepresented as

(S1)

An Io of 5.5 to 6.0 points represents the basic signal-to-noise ratio degradation. I

s mea-

sures degradation of the simultaneous impairment factors due to loudness, talkersidetone, and quantization. In the literature, R

o is used where R

o = 100 – I

o. We use the

extended form to help clarify the 100-point R score. Is degradation is introduced by the

lower coder-decoder (codec) quality and number of codecs in the path. Id measures

degradation of delay impairment due to a one-way mouth-to-ear delay with a certain levelof echo, corresponding to VoIP CEN end-to-end voice packet delay. I

e is the equipment

Table S1. R-value and mean-opinion-score value mapping

R = 100 – Io – I

s – I

d – I

e + A(x) .

Source:International Telecommunication Union, Telecommunication Standardization SectorDecember 7, 2000.

ITU-T Recommendation G.108,,

Application of the E-Model: A Planning Guide,

90–100

80–90

70–80

60–70

50–60

4.34–4.5

4.03–4.34

3.6–4.03

3.1–3.6

2.58–3.1

Best

High

Medium

Low

Poor

Very satisfied

Satisfied

Some users dissatisfied

Many users dissatisfied

Nearly all users dissatisfied

R-Value Mean Opinion Score Quality User Rating



impairment factor and represents the degradation of analog voice from information lossdue to low-bit-rate encoding and packet loss. A(x) is the advantage factor due to theuser’s willingness to accept a certain degree of quality degradation for a given situation(x) for convenience, such as that provided by a wireless telephone. It is interesting to notethat, based on ITU-T G.108 [S2], provisional values for A(x) can range from 0 for theconventional public switched telephone network (PSTN) wired case to 10 for cellularwithin a vehicle and 20 for multihop satellite services. We believe that the VoIP values forA(x) should be the same, depending on the service provided, although our remainingdiscussion will be limited to the land-based conventional case.

The first three terms (100, Io, and I

s) from Equation (S1) are independent of the type of

time-division-multiplexed voice used—VoIP or PSTN. Following Markopoulou et al. [S5]from Stanford, the resulting R-values for 100 – I

o – I

s are 94.3 for G.711 and 84.3 for G.729.

Those values are for the case in a test laboratory where Ie is zero, I

d is small, and there is

no echo. Such low Is degradation is based on the assumption that few codec types are

involved. Significant codec-based degradation can result if the VoIP signal transmitsthrough a large number of codec types from one end of the circuit to the other. But that isa special case, which not be addressed here.

In practice, however, as discussed earlier, there will always be echo, and the echo/delay-related degradations must be accounted for. Table S2 presents examples of the effects on aVoIP MoS of various I

d and I

e values for the two codec subcases discussed above for

G.711 and G.729. Values for various other codecs, not discussed here, fall between thosefor G.711 and G.729. The two selected codecs thus provide a bound for the performance ofthe others.

Table S2 shows how to use the E-Model to calculate the R-value for five use-cases, basedon WAN characteristics and the two codec subcases, G.711 and G.729. The G.711 codecperformed quite well for most cases, but the G.729 performed marginally for many. Thus,care must be taken with the use of G.729. For each case in Table S2, the factors thatcontribute to degradation are identified, and the total degradation and resulting MoS arethen derived. The basic R-values for 100 – I

o – I

s for the G.711 and G.729 cases are used as

a starting point. They are degraded by packet loss Ie and delay I

d. For our discussion, we

consider only casual conversation. The overall effect of delay and packet loss on tenseconversation, such as reading numbers, can be worse but is not discussed. The effect ofsuch degradation—such as the effect on emergency medical technicians’ transmissionson critical patients—should be considered in the context of the business operation, todetermine whether effective operation requires higher quality.

The degradation value for Ie is based on the assumption of a four-point degradation for

each 1% increase in packet loss rate [S5]. The assumption is good between 0% and 3%packet loss rates. That rule assumes the deployment with packet loss concealment (PLC),which is already incorporated by vendors into the G.729 codec. But PLC may not havebeen incorporated into the G.711 by some vendors. The extrapolation will diverge whenpacket loss rises above 3% into two sets of values—with and without PLC. Moreover, theabove rule applies only to cases with no voice activity detection (VAD) and silentsuppression. VAD appears to increase the degradation [S5]. We have relied on the work ofMarkopoulou et al. [S5] because it has analyzed and reconciled values from many sources.VAD can help to reduce VoIP traffic, but its use may degrade performance. Therefore, thesystem designer will have to conduct a trade-off analysis to select the best balance for thebusiness.



Table S2. Use-cases and calculations for user-perceived VoIP mean-opinion-scorevalues: An E-Model example

Use-Case for User-Perceived VoIP MoS Value

Codec

G.711,Baseline

G.729,Low Bit Rate

Case 1. Ideal intrabuilding network, LAN only

Basic R-value for 100Degradation value for (with no packet loss, achieved bygiving priority to VoIP as necessary)Degradation value for with mouth-to-ear one-way delay of50 ms (with 20-ms frame delay at each end and 20-msprocessing time). Echo loss = 51 dB. That is indeed a veryconservative assumption.

– lo – Isle

ld

Net R-valueEquivalent mean opinion score for LAN-only case

••

•

95.4 85.40 0

–5 –5

90.4 80.44.3 4.0

Case 2. Within a metropolitan area, small region, no packet loss

Basic R-value for 100Degradation value for (with no packet loss, achieved bygiving priority to VoIP as necessary)Degradation value for with mouth-to-ear one-way delay of60 ms (add 10-ms interlocation packet propagation time tocase 1). Echo loss = 51 dB.

– lo – Isle

ld

Net R-value

••

•

95.4 85.40 0

–6 –6

89.4 79.44.3 4.0

Case 3. Within a metropolitan area, small region, 1% packet loss

Basic R-value for 100Degradation value forDegradation value for with mouth-to-ear one-way delay of60 ms (add 10-ms interlocation packet propagation time tocase 1). Echo loss = 51 dB.

– lo – Isleld

Net R-value

•••

95.4 85.4–4 –4–6 –6

85.4 75.44.2 3.8

Case 4. Within continental United States with no packet loss

Basic R-value for 100Degradation value for (with no packet loss, achieved bygiving priority to VoIP as necessary)Degradation value for with mouth-to-ear one-way delay of100 ms (add 50-ms interlocation packet propagation time tocase 1). Echo loss = 51 dB.

– lo – Isle

ld

Net R-valueEquivalent mean opinion score for continental United States with no packet loss

••

•

95.4 85.40 0

–10 –10

85.4 75.44.2 3.8

Case 5. Within continental United States with 1% packet loss

Basic R-value for 100Degradation value forDegradation value for with mouth-to-ear one-way delay of100 ms (add 50-ms interlocation packet propagation time tocase 1). Echo loss = 51 dB.

– lo – Isleld

Net R-valueEquivalent for continental United States with 1% packet lossmean opinion score

•••

95.4 85.4–4 –4

–10 –10

81.4 71.44.1 3.7

Equivalent mean opinion score for metropolitan-area case with no packet loss

Equivalent mean opinion score for metropolitan-area case with 1% packet loss



The degradation value for Id is based on the assumption of a 10-point degradation on the

R score for each 100-ms increase in mouth-to-ear delay [S5]. That degradation value isbased on the assumption that the echo level corresponds to an echo loss of 51 dB, whichin turn corresponds to the performance realized with a simple but efficient echo cancellerat each end. That rule is good for a mouth-to-ear one-way delay from 0 to 200 ms and willbe a useful approximation up to 300 ms.

Other values for Io, I

s, I

d, and I

e related to codec-based degradations can be found in

References S2 and S6. We believe that, as VoIP matures and more measurements becomeavailable, the values from different sources will converge. For our examples in Table S2,we have assumed a packet delay of 0 ms for the local-area-network (LAN)-only case; themetropolitan-area case, 10 ms; and the continental United States case, 50 ms. Thosevalues account for the speed of propagation over fiber or copper, circuitous cable andwire routes, delay due to equipment, and some additional buffering for delay jitter.

In an IP network, a packet traveling across a network can experience jitter betweenpackets. Such jitter can cause a difference in delay across the network between packets.Unlike the data traffic stream, the voice stream must be continuous. Buffer and artificialdelay must therefore be introduced to compensate for jitter—adding to the end-to-enddelay. Telecommunication designers should note that, to derive the mouth-to-ear delay,it is important to add 50 ms for a 20-ms framing assumption onto the propagation delaydescribed above from case 1, LAN-only, which accounts for the framing and processingof VoIP packets. Table S2 presents examples showing how that was done.

The results for the five cases considered in Table S2 show that MoS values for the use ofG.711 should exceed 4.0 for all cases in the continental United States, including the LAN-only and the metropolitan-area cases. However, G.729 values will start at 4.0 for the bestcase (LAN-only), using a 20-ms frame and assuming a 50-ms mouth-to-ear one-way delay.The 50-ms delay comprises 20 ms from framing at the originating end; 10 ms for voice, aswell as LAN processing and propagation over the equipment; and 20 ms at the receivingend for dejitter playout buffering.

When two VoIP telephone users in a LAN talk to one another, there may be no echoreflection points. But we make a conservative assumption with respect to echo, in casesome of the equipment is still analog. The added packet propagation delays for themetropolitan-area and continental United States cases are assumed to be 10 and 50 ms,respectively, above the 50 ms used for the LAN-only case. For packet loss, we haveassumed two cases of 0% and 1% packet loss rate.

References

S1. ITU-T Recommendation G.107, The E-Model: A Computational Model for Use inTransmission Planning, International Telecommunication Union, TelecommunicationStandardization Sector, May 2003.

S2. ITU-T Recommendation G.108, Application of the E-Model: A Planning Guide,International Telecommunication Union, Telecommunication Standardization Sector,December 7, 2000.

S3. J. Anderson, Methods for Measuring Perceptual Speech Quality, Agilent Technolo-gies, Network Systems Test Division, white paper, October 22, 2001, http://literature.agilent.com/litweb/pdf/5988-2352EN.pdf. Accessed May 6, 2005.



S4. J.Q. Walker and J. Hicks, Evaluating Data Networks for VoIP, NetIQ Corporation,white paper, 2001, http://www.atsweb.it/Images/Documenti/NTQ_WP_Evaluating%20Data%20Networks%20for%20VoIP.pdf. AccessedMay 6, 2005.

S5. A.P. Markopoulou, F.A. Tobagi, and M.J. Karam, “Assessment of VoIP Quality overInternet Backbones,” Proc. IEEE INFOCOM 2002, 21st Annual Joint Conf. IEEEComputer and Communications Societies, New York, June 23–27, 2002, http://mmnetworks.stanford.edu/papers/markopoulou_infocom02.pdf. AccessedMay 6, 2005.

S6. D. De Vleeschauwer, J. Janssen, G.H. Petit, and F. Poppe, “Quality Bounds forPacketized Voice Transport,” Alcatel Telecommunications Review, First Quarter 2000,pp. 19–24.

Call blocking is also used in PSTN network to control traffic. The level of blocking isspecified by its grade of service. Certain VoIP calls will be either blocked or rerouted to aPSTN gateway. As discussed previously, priority may have to be established for VoIPtraffic traversing a WAN, in order to hold the end-to-end delay, as well as its effect onuser perception, to an acceptable level.

Finally, telecommunications managers and analysts should calibrate and validate E-Modelresults by doing a field test to see how well performance under actual conditions agreeswith E-Model prediction. At some point in the iterative process, a small field test of two tothree users should be run to validate our E-Model results.

We conclude that G.711 will perform quite well for most cases in the continental UnitedStates. We also conclude that the G.729 low-bit-rate codec can perform well in the LAN-only case, when a low bit rate is not important. But G.729 may perform poorly for callsacross the continental United States, so it should be evaluated carefully. We have pointedout that a low user MoS score does not necessarily mean unintelligible conversation, soG.729 may still be useful for low-bandwidth locations, with the understanding that theuser-perceived MoS score may be low.

Network Availability Issues

VoIP CENs must be carefully designed to meet the required uptime for voice. Availabilityrequirements are more stringent for voice than for data, so CENs must be more robust thantoday’s stand-alone data networks. Today, voice users are accustomed to having five 9’s(99.999%) availability for a voice backbone on the carrier’s side. The availability to thevoice end-user is lower, because of the reduced availability of the local access lines andon-premises equipment. During normal working hours, a typical voice-access circuit at asmall site generally has an availability of 99.8% to 99.9%, or 4 to 2 hours downtime peryear. In large or high-availability locations, redundant access circuits, equipment, andpower options are implemented to provide higher availability.

For VoIP users in a CEN to enjoy similar network availability, the backbone WAN, powersupplies, circuits, and all essential common equipment must have sufficient redundancy toavoid a single point of failure. Before implementing a VoIP CEN, designers should evaluatethe LANs and WAN with respect to standard end-to-end network availability, to deter-mine the type of redundancy needed to meet the required performance.



VoIP Security Considerations

VoIP security is another important requirement in a CEN. Since VoIP runs over the IP datanetwork, all data network security specifications should apply equally to VoIP. Likewise,CEN security requirements must meet the security requirements for data, as well as voice.Existing data networks have been designed to meet data security, whereas voice in theform of VoIP may be governed by a quite different set of requirements and threats. Forexample:• The voice conversation packets can be captured, decoded, and replayed.• A denial-of-service attack on a call controller, media gateway, or LAN switch can

disrupt the VoIP service.• An unauthorized computer, posing as an IP telephone, can be inserted on the voice

LAN and gain access via a brute-force password assault on the call controller orauthentication server.

Therefore, the general VoIP security requirements are equipment access control, authenti-cation, authorization, and confidentiality. Security does not come free when implementingVoIP security, it depends on the security level that you can accept and afford in yournetwork environments [10], within both the LAN/campus network infrastructure and theWAN infrastructure.

To serve as a guideline, we describe three levels of VoIP security: basic, enhanced, andadvanced.

Basic Security Level. Basic security assumes that the VoIP environment can be trustedwith a combination of preexisting data network security and selected additional measures:• Assumed preexisting security:

– All access is presumed valid because of existing authentication measures (may/may not be via clear text).

– Physical security measures, such as locked wiring closets, are assumed to bein place.

• Additional measures:– Separation of data segments and IP telephone segments by using virtual LANs

(VLANs).– Voice firewall for PSTN interface.

Enhanced Security Level. Enhanced security is typically required for a CEN that uses aWAN to interconnect multiple sites. For this level, at least four specific security measuresare added to the basic security implementation:

• Voice traffic between sites must be secured with encryption to provide confidentiality.That protection can be implemented as encrypted tunnels through the WAN.

• Firewalls must exist between voice and data VLANs to minimize exposure to virus anddenial-of-service attacks.

• Various servers—at least all voice-related servers (such as the call controller, gate-way, Trivial File Transfer Protocol, authentication, voice mail, and Dynamic HostConfiguration Protocol servers)—must have hardened operating systems and includeintrusion prevention software.

• Clients and servers (such as IP telephones, soft telephones, and call controllers) mustbe properly and mutually authenticated.



Advanced Security Level. VoIP security requirements have little to do with the size of theenterprise network or the number of users. Instead, they are based on the degree to whichsecurity breaches would affect the voice communication. For the advanced security level,all data network security features should be implemented, including network/host intru-sion detection systems, firewalls, and equipment access controls. No trust is assumed onthe internal and external network infrastructure, and additional security measures areincluded:• All IP telephony payload traffic should be encrypted in both the WAN and the LAN.• All VoIP signaling traffic should be encrypted in both the WAN and LAN.• Authentication between the IP telephone, soft telephone (i.e., users), and servers

should not be via clear text.

Authentication between the users and servers can be via either digital certificates orshared keys or passwords. The scalability of the key distribution and management shouldbe evaluated before deploying it in a CEN. Digital certificates are more scalable thanshared keys. Encryption also requires more computer processing power (in the VoIPequipment) to process the encryption, decryption, and authentication. Encrypted voicepackets will have a larger packet size, so communication equipment and network band-width must be adjusted accordingly to compensate for the additional latency and process-ing delay. The Secure Real-time Transport Protocol (SRTP) and newer versions of VoIPprotocols [11] that address those security issues have either just been released or are stillin their draft versions. Achieving a higher level of VoIP security is possible, but theadditional cost should be considered, following standard security practices.

We conclude that, with proper evaluation and design, acceptable VoIP security can beprovided. VoIP security requirements are determined by how significantly security threatswould affect voice communication and business requirements. Equipment access control,authentication (user, server, and IP telephone), authorization, voice session integrity, andconfidentiality should be evaluated for implementation, depending on the applicationenvironment and budget.

Vendor Input

At each stage of the analysis, vendor input can be a useful source of data. By usingpreviously collected vendor data, and requesting bids from vendors against the require-ments defined here, a realistic appraisal can be made of the expected performance and costof VoIP.

Vendor quotes can be requested at any stage within the ROI assessment process, oncean initial set of requirements is defined. When quotes are obtained, they must first beanalyzed for how well they meet requirements. Some of the nominal performance valuesprovided in this article can be used to check the validity of the quotes. If quotes appearunrealistic, the vendors can be redirected based on a solid understanding of the require-ments. On the other hand, vendor quotes may reveal how industry can offer new capabilities.

Sample VoIP Repository Information

Each organization should construct its own repository of VoIP data to support decisionson deploying or expanding the service. The repository compiled during recent studies forNorthrop Grumman Information Technology and its clients include the following:



• Operational experience and databases (including the topology, design, performance,and cost of each piece of circuit and equipment) of several very large data networks– Data, experience, and use of various carrier WAN transmission services,

including dedicated and nondedicated circuits and services ranging from theDS0 standard digital transmission rate (64 kbps) to 622 Mbps (OC12) speedsand beyond

– Data, experience, and use of various LAN/WAN routing, switching, andsupporting equipment

• IR&D reports and presentations• IR&D-related equipment configuration templates for various location type and design

options• Relevant literatures on voice and data use and forecast

– Relevant published articles and unpublished industry reports on voice trafficand use

– Relevant published articles and unpublished industry reports on data use bytype of location

• Voice and data traffic database– Voice utilization records, call records, and bills for various projects and from our

own experience base– Data traffic measurements from a very large number of Northrop Grumman and

customer sites/circuits• Extensive WAN RFPs and proposals and experience bases• Equipment lists, specifications, and prices from multiple vendors; laboratory

test and actual use data; and experience with equipment that is outside ouroperational experience base

• Transmission circuit inventory by service type and related prices for transmissionservices that are outside our operational experience base

If an organization has not developed a repository of such information, a quick-cutanalysis is still possible, using information from commercial sources such as Gartner andForrester, along with vendor-supplied information. Acquiring that information andfollowing the process put forward here will still afford a significant saving over standardapproaches.

An effective repository can be built by simply starting to collect available industryinformation and vendor inputs to bid requests. Care must be taken to keep the informationcurrent, organized, and available.

Conclusions and Recommendations

This article identifies system engineering considerations and information necessary forVoIP and CEN predeployment decisions: potential benefits, ROI, bandwidth, voice quality,user satisfaction, availability, and security. A quick-look system engineering method ofanalysis provides the basis for determining whether a CEN should be built, as well as howto specify the CEN requirements and evaluate the network design in later steps. Therecommended approach is based on years of network design and performance datacollection.

The guidelines presented here reflect our experience in supporting deployment decisionswith a quick but focused analysis, until expenditure of more resources is justified.



The repository of data and the analytical approach together have enabled NorthropGrumman Information Technology and its clients to determine the value of VoIP anddecide to proceed with deployment in a staged assessment. Large commitments ofresources were withheld until analysis indicated that the investment would provide adesired ROI. By keying in on critical design considerations, the resources were focused,allowing checks on the validity of key performance and cost concerns, and reducing therisk of wasting resources in an attempt to justify an inadvisable deployment.

This article presents the key engineering choices, along with performance and cost trade-offs for VoIP deployment. The nominal performance capabilities and costs provide a basisfor early determination of the potential of a positive ROI for VoIP deployment. Keyinsights are as follows:• Operational savings from productivity improvement of IT staff will typically be the

main contributor to ROI, much higher than toll bypass savings for domestic calls.• Typically, VoIP traffic will be much lower than data traffic. Nominal traffic levels can be

used in many cases, but organizations such as call centers must determine their ownlevels. In all cases, the nominal traffic estimates must be evaluated to assess theeffects of needed choices on codecs, cRTP, and encryption. The additional analysisrequired is described in the traffic model presented here.

• User satisfaction and perceived quality, ordinarily determined in live tests, can beaddressed analytically using the E-Model.

• Availability requirements are different for data and voice networks. If a data networkis used as the basis for a CEN, it may need to be enhanced in terms of availability, aswell as security.

• Voice and data have different security requirements. A properly designed CEN shouldbe able to meet voice security requirements.

The system engineering insights and guidelines presented here may be used by chiefinformation officers, telecommunications managers, network analysts, and networkdesigners to produce an initial set of design requirements, as well as performance andcost estimates to estimate the ROI for a VoIP deployment. The initial estimate can then berefined through iterative design and evaluation based on specific business consider-ations. The recommended approach fills a gap in areas of VoIP decision making, whichcurrently lacks any standard, simple, but effective methodology for low-cost assessments.

References

1. T.B. Fowler, “So You Want to Deploy VoIP? A Decision Maker’s Guide,” MitretekSystems, The Telecommunications Review, Vol. 14, September 2003, pp. 19–31,http://www.mitretek.org/publications/2003_telecomm_review/03_fowler_2003.pdf.

2. J. Kreiling, “Building an IT Business Case That Will Sell: What Business DecisionMakers Look for When Evaluating New IT Investments,” Cisco Systems, Packetmagazine, Vol. 15, No.1, First Quarter 2003, Special Report, pp. 41–45.

3. E. Dunne, Broadband Services Overview, Vertical Systems Group, Westwood, Mass.,http://www.cis.state.mi.us/mpsc/comm/broadband/broadband/studybroadband.pdf.Accessed May 6, 2005.

4. Nortel Networks, “Optical Broadband Services Delivered through Service Innova-tion,” March 21, 2003, www.nortelnetworks.com/solutions/osc/collateral/nn-



103920-032103.pdf or http://64.233.161.104/search?q=cache:CiK0beqFEIQJ:www.nortelnetworks.com/solutions/osc/collateral/nn-103920-032103.pdf+103920-032103.pdf&hl=en. Accessed May 20, 2005.

5. ITU-T Recommendation G.107, The E-Model: A Computational Model for Use inTransmission Planning, International Telecommunication Union, TelecommunicationStandardization Sector, May 2003.

6. ITU-T Recommendation G.108, Application of the E-Model: A Planning Guide,International Telecommunication Union, Telecommunication Standardization Sector,December 7, 2000.

7. Bell Telephone Laboratories staff, Transmission Systems for Communications, 5th ed.,Bell Telephone Laboratories, 1982.

8. J.J. Gruber and G. Williams, Transmission Performance of Evolving Telecommunica-tions Networks, Artech House Publishers, London, 1992.

9. A.P. Markopoulou, F.A. Tobagi, and M.J. Karam, “Assessment of VoIP Quality overInternet Backbones,” Proc. IEEE INFOCOM 2002, 21st Annual Joint Conf. IEEEComputer and Communications Societies, New York, June 23–27, 2002, http://mmnetworks.stanford.edu/papers/markopoulou_infocom02.pdf. AccessedMay 6, 2005.

10. Nortel Networks, Secure Telephony Solution, position paper, 2003, http://www.nortelnetworks.com/solutions/security/collateral/nn104820-071403.pdf.Accessed May 6, 2005.

11. ITU-T Recommendation H.323, Packet-based Multimedia Communications Systems,International Telecommunication Union, Telecommunication Standardization Sector,July 2003, www.h323forum.org/standards and http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-H.323. AccessedMay 14, 2005.

Author Profiles

John Y. Ma (previously also known as Y. Manichaikul) hasserved as an electrical engineer and manager for NorthropGrumman Information Technology’s Federal EnterpriseSolutions business unit, focusing on high-level systemengineering, economics studies, planning, traffic, performance,and network modeling for telecommunication networks andsystems. He has performed system design and engineeringfor large national and international WANs comprising up toseveral thousands of routing nodes, as well as a 10-GHz-bandwireless point-to-multipoint microwave communication systemfor metropolitan-area networks. Dr. Ma holds B.S., M.S., andPh.D. degrees in electrical engineering from the Massachu-setts Institute of Technology.

[email protected]

��



Hoi Y. Chong is a Technical Fellow and network systemengineer in Northrop Grumman Information Technology’sFederal Enterprise Solutions business unit. Currently hesupports the Treasury Communications System program andnew proposal effort. He has worked on Northrop GrummanInformation Technology’s network design projects, such asthe National Weather Service’s Advanced Weather InteractiveProcessing System’s (AWIPS’s) WAN, as well as a network forthe U.S. Patent and Trademark Office. He holds a BS fromCheng Kung University, Taiwan; an MS from New MexicoState University; and a PhD from Oregon State University. Alldegrees are in electrical engineering.

[email protected]

Mark E. Schultheis has worked as a system engineer andmanager for Northrop Grumman Mission Systems andNorthrop Grumman Information Technology on a broad rangeof assignments, including digital microprocessor design, dataencryption techniques, large-scale IT system development andtelecommunication network design. Most recently, he was theprincipal investigator and manager for IR&D projects relatedto broadband communications and CEN technologies such asVoIP and multiprotocol label switching. He has also been thechief technologist and architect for a number of large develop-ment programs, such as the United Kingdom’s NationalAutomated Fingerprint Identification Systems, U.S. TreasuryCommunications System, and the Department of HomelandSecurity’s Homeland Secure Data Network. He holds a BS inelectrical engineering from Pennsylvania State University.

[email protected]

Documents

Rapid System Engineering Assessment of Voice-over-IP Deployment