The benefits of convergence ï¿½ including reduction of telecom costs, the advantages of managing of one network instead of two, and greatly simplified provisioning of services to remote locations ï¿½ are so compelling that most companies canï¿½t afford not to deploy VoIP. At the same time, however, itï¿½s essential to ensure that implementation of a converged environment doesnï¿½t jeopardize either voice services or other business critical IT applications.
Thatï¿½s why companies pursuing the benefits of VoIP must take steps to ensure that their converged networks deliver target performance levels and continuous availability of both voice and data services. Several factors make it particularly challenging to ensure end-to-end service levels in converged environments.
ï¿½ The complexity of converged network infrastructure;
ï¿½ The significant differences in the way the diverse applications running in the converged environment, including legacy software, Web services, and VoIP, tolerate network impairments;
ï¿½ Limitations in the IT organizationï¿½s ability to measure, analyze, and/or predict the end userï¿½s quality of experience with each of these applications; and
ï¿½ Limited resources with which to plan, build, and manage the environment.
One of the best ways to overcome these challenges is to leverage virtual network test bed technology. With a virtual network test bed, IT organizations can carefully assess their environmentï¿½s VoIP readiness before blindly embarking on a network upgrade mission. They can also experiment with a variety of remedies for any problems they discover. Equally importantly, such a test bed is invaluable for continuously and proactively safeguarding VoIP and data application performance over time as utilization grows, as new applications are introduced into the production environment, and as the business morphs and expands.
The Virtual Network
Virtual network test beds enable application developers, QA specialists, network managers, and other IT staff to observe and analyze the behavior of network applications in a controlled lab environment that accurately emulates conditions on the current and/or planned production network. Ideally, this emulation should reflect all relevant attributes of the network, including all network links and their impairments (physical distance and associated latency, bandwidth, jitter, packet loss, CIR, QoS/MPLS classification schemes); the number and distribution of end users at each remote location; and application traffic loads.
In addition to allowing technicians to analyze the behavior of critical applications under existing and projected network conditions, a virtual test bed also enables ï¿½ears onï¿½ assessment of VoIP call quality. In other words, actual phone equipment can be connected to the emulated environment so that technicians and/or end users can experience first-hand what calls will sound like between any two points on the network at any time of day. This kind of real-world acceptance testing greatly reduces the possibility that end users will balk at call quality after huge investments have been made in a VoIP rollout.
Seven best practices for convergence success
The following seven best practices specifically highlight how IT organizations are using virtual network technology to ensure both the success of their initial VoIP implementations and their long-term ability to sustain high service levels, despite the risks associated with data/voice/multimedia convergence.
1. Capture conditions on the network to define best case, average case, and worst case scenarios
Conditions in a test lab can only reflect conditions in the real-world environment if they are based on accurate, empirical input. Thatï¿½s why itï¿½s best to ï¿½recordï¿½ conditions on the production network over an extended period of time and then ï¿½play backï¿½ those conditions in the lab to define best, average, and worst case scenarios. These recorded scenarios will reflect the full range of real-world conditions on the specific network across which the companyï¿½s applications and services will ultimately have to perform.
2. Use the virtual network to trial VoIP in the lab under those real-world scenarios
Once an accurate set of scenarios have been defined, they can be re-created in the test environment, so that the behavior of VoIP and other applications can be assessed under those all possible environmental conditions. A phone can be associated with each location, so that the quality of calls between any two points can be evaluated under the same conditions as exist on the production network. A call generator can also be added to the virtual network to generate synthetic VoIP traffic and perform regression testing. At the same time, technicians can use PCs to assess to-the-desktop performance of data applications running in the same environment.
3. Analyze call quality with technical metrics
Once VoIP traffic is running in an appropriately defined virtual environment, the team can apply metrics, such as MOS, to determine where voice quality is acceptable and where it is not. Typically, there will be a close correlation between network conditions ï¿½ such as delay, jitter, and packet loss ï¿½ and call quality. In fact, given the highly dynamic nature of todayï¿½s networks, voice quality may vary substantially during the course of a call.
4. Validate call quality by listening to ï¿½liveï¿½ calls
Technical metrics alone can be misleading, since it is the perception of call quality by actual end users that serves as the ultimate test of VoIP success. So, the virtual environment should be used to enable the team to validate first-hand the audio quality on calls between any two points on the network under all projected network conditions. Using a call generator in conjunction with the virtual network, a tester can become the ï¿½nthï¿½ caller at any location. This information is typically documented on voice mail systems and is included in the call itself to ensure accurate documentation. For example, the tester might say, ï¿½Hello. This is a message from the 101st caller from California to Texas under the average case network scenario.ï¿½
5. Repeat as necessary to assess and validate remedies
Discovering a problem with call quality is one thing; fixing it is another. Often, the obvious answer to a problem ï¿½ such as adding more bandwidth or resetting DiffServ variables ï¿½ doesnï¿½t actually produce the desired effect. With a virtual environment, however, these various fixes can be tried and tested without disrupting the production network. Better yet, this ï¿½try before you buyï¿½ approach enables the company to avoid making technology investments that may not, in fact, be necessary. Testing in the virtual environment should, therefore, be an iterative process, so that all quality issues can be fully addressed and the rollout of VoIP in the production environment can be performed with a very high degree of certainty.
6. Bring in end-users for pre-deployment acceptance testing
Voice quality is, ultimately, a highly subjective attribute. Thatï¿½s why many VoIP implementation teams have found that it is worthwhile to bring in end users for acceptance testing prior to production rollout. This greatly reduces the chance of the dreaded ï¿½VoIP mutinyï¿½ syndrome, where end users balk at call quality, despite the best efforts of IT and despite the fact that call quality meets common industry standards. Pre-deployment acceptance testing is particularly important when the financial investments made in VoIP-enabling the network are significant.
7. Continue applying these best practices over time as part of an established change management process
To maintain VoIP quality over time, IT organizations must incorporate these best practices into their change management processes. This is essential for ensuring that changes in the enterprise environment ï¿½ the addition of new locations, the introduction of a new application onto the network, a planned relocation of staff ï¿½ will not adversely impact end-to-end VoIP service levels. Such changes can easily affect VoIP performance in totally unexpected ways, so the only safeguard against the interruption of critical voice capabilities is to test call quality under the new projected conditions in the lab using a virtual network.
Cost-justifying the virtual network
Of course, IT organizations face a wide range of investment decisions as they seek to evolve their enterprise computing environments to meet the needs of the business. So, IT organizations that want to acquire virtual network test bed technology in order to support their VoIP implementations need a strong basis for cost-justifying that acquisition.
In general, improvements in VoIP implementation alone can provide ample justification. By accurately assessing the networkï¿½s VoIP readiness, a virtual network test bed enables IT organizations to predictively discover and proactively remedy any potential problems. A virtual test bed also saves money by validating proposed remedies, thereby avoiding unnecessary purchases of bandwidth or equipment. In addition, project teams can use the virtual network test bed to accurately compare competing vendorsï¿½ solution and make the smartest buy.
However, such a test bed typically offers many high-ROI uses above and beyond VoIP. These uses include more network-aware software development, more intelligent network capacity planning, improved troubleshooting, and smarter execution of server moves and data center consolidations.
A virtual network testing environment is thus a wise investment both for ensuring the success of convergence initiatives and for the improved performance of IT on the whole. By integrating network emulation into its total technology portfolio, IT can reduce risks, avoid wasteful spending, and bring a new level of predictability to service levels across an ever changing enterprise that depends every day on both voice and data applications. IT
Amichai Lesser is the director of product marketing at Shunra, a pioneer in predicting the behavior of services across todayï¿½s complex networks. For more information, please visit the company online at www.shunra.com.
If you are interested in purchasing reprints of this article (in either print or PDF format), please visit Reprint Management Services online at www.reprintbuyer.com or contact a representative via e-mail at firstname.lastname@example.org or by phone at 800-290-5460.