Starting the journey to VoIP enablement
Upcoming SlideShare
Loading in...5
×
 

Starting the journey to VoIP enablement

on

  • 359 views

 

Statistics

Views

Total Views
359
Views on SlideShare
359
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Starting the journey to VoIP enablement Starting the journey to VoIP enablement Document Transcript

  • NORTEL IT IMPLEMENTATION STEPS STARTINg ThE jOuRNEy TO VOIP ENAbLEMENT Nortel Best Practice Evaluating and Planning for VoIP at Nortel Executive summary ment. Prior to a full implementation of challenge. With over 150 sites globally When Nortel IT first undertook VoIP on our network, we had to providing local and global phone integrating our voice traffic into the perform the following steps: services, pricing varied widely between data network using Voice over Internet regions and the communities of users • Determine the performance require- Protocol (VoIP), it was a journey of had different needs. ments for jitter and latency-sensitive many steps. There was a great deal of VoIP traffic We prepared for our implementation by: preparation and planning that had to • Audit, upgrade and implement take place before Nortel IT could roll • Running a series of lab and limited changes to our data infrastructure and out VoIP on our global network. production trials WAN (wide area network) bandwidth • Determining our sweet spot users, i.e., Our goal was to upgrade our existing to support VoIP traffic those employees who benefit the most voice switches to handle VoIP traffic Once we decided upon the correct by having VoIP and signaling. Throughout the imple- infrastructure and settings, we had to • Cross-training operations and engi- mentation, we needed to maintain our determine where it made business sense neering personnel from our voice and ability to support existing time division to begin deploying VoIP — and how far data silos to be able to support the multiplexing (TDM) users and equip- we needed to go. This was no small converged solution. What are the IT implementation STEPS? A how-to guide used by Nortel Information Technology in the implementation of a new technology solution or best practice. From implementation strategy to end-user support, our implementation STEPS describe the processes, procedures, tools and/or policies used by Nortel IT, including: S = Strategy, preparation and considerations T = Timetable for key activities E = Execution to implement the solution P = Prove to ensure requirements are met S = Support operations of a live service
  • This document will focus on the We decided to perform a number of lab First we performed lab trials to gather evaluation and preparation that took trials and limited production trials to the information needed to implement place before VoIP could be rolled out to prepare for the implementation. The VoIP on our network. We then our employees. We will describe how we purpose of these trials was to: performed a production trial of VoIP ran trials to determine the requirements and unified communications (UC) • Determine the network and voice of a successful VoIP implementation. applications to ensure that we could switch upgrades and the quality effectively roll out the applications to of service (QoS) settings that were Implementation STEPS our employee population globally. This required for us to reliably carry VoIP initial production trial was limited to Strategy traffic on our data network sweet spot users within different At Nortel IT, we decided to work • Create and then validate our imple- geographic sites. toward replacing our existing TDM mentation guides to be used globally voice network with a converged Our sweet spot users were determined • Define the network performance network that was VoIP-enabled. Our to be those who had a business line at and voice codec requirements for the goal was to have a single network for home, those with high PSTN long implementation both voice and data services by distance charges and high-frequency converging our existing, separate TDM Once the requirements for the VoIP travelers with calling card usage. In voice network onto our data network implementation were defined, Nortel IT these production trials, our goals were with the deployment of VoIP. had to determine the most effective way to test and refine our application to roll out VoIP to our network. We deployment plans, solicit user feedback, Voice over IP was just starting to looked at three areas during our trials: determine how this additional traffic become a viable solution when we affected the data network and stan- started to take a look at carrying voice • The impact to our network and dardize our service offerings. In turn, traffic over our IP network. We had to equipment costs by introducing VoIP Nortel would gain hard dollar savings make sure that we had a complete to our network by removing home business lines, inventory and performance profile of • Sweet spot users, i.e., the users that cutting back on long distance charges our network and how it would need to would benefit Nortel the most by and reducing spend with calling card change in order to accommodate VoIP being able to use VoIP providers. traffic. • Our IT support structure and training required to manage a VoIP-enabled Timetable network The following implementation timeline represents how Nortel IT enhanced its voice capabilities from a TDM-based VoIP evaluation and preparation timeline infrastructure over to a converged Evaluation Preparation VoIP-enabled infrastructure. Given our Timing: 6 months Timing: 6 to 12 months implementation took place in the early • Completed a full network audit of our • Developed the documentation and plans stages of VoIP, we performed many 150 voice sites and global WAN needed to implement the IP enablement of voice switches: performance tests and trials before our • Evaluated network performance requirements to ensure VoIP quality: – Engineering guidelines and processes implementation. – Bandwidth, jitter, latency, packet loss – IP enablement plan – Quality of Service (QoS) settings – End-user training documentation VoIP is more mature today. Most • Determined the uninterrupted power • Performed trials of VoIP-enabled companies will not have to perform all requirements, redundancy measures and applications: of the tests and trials we did early on, which voice codec would be used for our – Soft Clients and VoIP phones implementation – Unified communications applications but the information in this document • Located sweet spots for VoIP • Reviewed our IT organization and skill should provide some assistance for implementation sets: companies trying to figure out what – Aligned IT staff to manage and needs to be looked at and evaluated for support a converged network – Provided cross-training education for an implementation. voice and data engineers so that they could work in a converged network 2
  • Execution Lab trials ated with them than local area network Before our VoIP implementation could Once Nortel IT completed the assess- (LAN) links and must be balanced take place, Nortel IT performed a full ment of our voice and data networks, against the voice service quality on the assessment of the current voice and data we ran lab trials on a VoIP-enabled test link. This means that good management networks. This ensured that both the network. This allowed us to examine and forecasting of the bandwidth logical and physical structure of the and define our voice service quality requirements for each VoIP network network was well documented and fully requirements. These requirements were segment are imperative to a cost-effec- understood prior to any upgrades or to be applied to all IP segments that tive VoIP implementation. changes. The goal of this assessment was would carry voice traffic and affected We decided to review the circuits for to provide the information needed to the decision as to which network each of our trial sites so that we could determine what changes would be upgrades needed to take place. The key determine the bandwidth needed to required to support a VoIP implementa- voice service quality variables that we support VoIP and other data packets. tion, along with voice service quality. tested in our lab trials were bandwidth, The current peak utilization for the site latency, jitter and packet loss. Pre-assessment was compared to the number of voice From our network assessment, we Bandwidth: In our lab trials, we channels that would be needed to created Table 1 that lists the minimum discovered that you cannot improve support the users at the site. If the set of pre-assessment questions that VoIP service quality by just throwing percentage of voice channels that could should be answered or known prior to a more bandwidth onto the network be supported was less than 60 percent, VoIP implementation. But they are not segment. Traffic over an IP segment is then we would review the cost associ- exhaustive. non-linear and unpredictable, which ated with adding bandwidth to that site can overload the receiving port’s queue. and increase the bandwidth of the site if In addition, wide area network (WAN) the business case justified it. links have a higher per-bit cost associ- Pre-assessment questions that should be answered or known prior to a VoIP implementation Is a logical diagram available for the data and voice network? What types of WAN links connect this site to others in its intranet? What speed[s] are the WAN links? What Ethernet link speed is used for end node layer 2 (L2) connections? What Ethernet link speed is used for the IP gateway L2 connection? What are the current 1, 6 and 12-month utilization figures for the LAN segments where VoIP is planned for deployment? What are the 1, 6 and 12-month peak delay figures for the LAN segments where VoIP is planned for deployment? What are the current 1, 6 and 12-month utilization [TX and RX] figures for the WAN segments where VoIP is planned for deployment? What are the 1, 6 and 12-month peak delay figures for the WAN segments where VoIP is planned for deployment? Does the network hardware supporting the LAN segments where VoIP is planned for deployment support the use of layer 3 (L3) QoS (DSCP)? Does the network hardware supporting the WAN segments where VoIP is planned for deployment support the use of L3 QoS (DSCP)? Does the network hardware supporting the WAN segments where VoIP is planned for deployment support other methods of traffic prioritization [bayRS DSQMS, etc.]? From data network statistics, is it possible to determine the top five to ten bandwidth utilizing nodes [outbound and inbound]? From call detail record (CDR) data, is it possible to determine the top five destinations for voice traffic, i.e., the granularity level of code such as electronic switched network (ESN) versus public switched telephone network (PSTN). What proportion is incoming traffic versus outgoing traffic? What amount of extra traffic [in kbps] will be generated on each LAN segment where VoIP phones are planned to be installed? What MOS or R value is estimated for your network? (See description below.) Table 1. Pre-assessment for VoIP implementation 3
  • Additionally, Nortel IT decided to manage the bandwidth requirements for VoIP traffic through the implementa- tion of QoS on our data network. We configured our QoS policies to give VoIP traffic priority over other types of data so that our VoIP calls would receive the priority they needed. Latency: Nortel IT found in latency trials that a voice conversation with a network latency (uni-directional) of 100 ms or greater will be noticed by the receiver and that latencies of 250 ms or greater significantly interfere with voice conversations. To measure the effect of smooth out these variances in packet the coder/decoder and reduces the delay latency on the quality of experience arrival times. They do this by collecting associated with network buffers to a (QoE) for our users, we used the the arriving packets in a buffer to minimal amount. For both G.711 and following scale for the G.711 codec: produce a constant stream for the voice G.729 codecs, the standard is 20 ms per processor and by correcting the frame. • Excellent – 99 ms or less of uni-direc- tional latency sequencing of the packets as they arrive Packet loss: As VoIP does not retransmit for the decoder. The issue with jitter lost packets, it’s important that packet • Good – 100 to 149 ms of uni-direc- buffers, however, is that as a jitter buffer loss be kept to a reasonable level or else tional latency grows in length, so does the end-to-end the perceived call quality suffers. In our • Fair – 150 to 199 ms of uni-direc- delay, and this can cause voice quality trials, we found several sources of packet tional latency issues when voice packets are discarded loss that can seriously degrade VoIP Prior to IP-enabling our voice switches, for arriving too late. calls: buffer overflows, packets with we needed to account for the additional From our lab tests on jitter, we deter- transmission errors and network latency that VoIP processing and jitter mined that a packet jitter of 50 ms or congestion. When a voice packet is buffer delay would add from the nodes. greater across a VoIP call will cause a dropped, VoIP calls can become choppy Nortel IT found that an approximation significant amount of choppiness if the or even go silent for a couple of seconds. of 93 ms should be added to the jitter buffer is not used. By not using To prevent this, we reduced sources of uni-directional latency measurement. the jitter buffer, network latency is network congestion, removed errors that Once the network was VoIP-enabled, reduced but voice calls will be more occurred along with the packets we were able to reduce network latency sensitive to variations in network delay, transmission and adjusted link speeds to by implementing QoS and assigning IP or jitter. This is why there has to be a prevent buffer overflows. voice a higher priority than “congestion- balance in reducing network delay to We found that one of the biggest causing lower priority” data. improve voice quality and using jitter sources of errors was duplex mismatches Jitter: Jitter is the variance in network buffers to reduce the effects of network within our network — where the device latency that is encountered in the latency variations. at one end of a network link is set to end-to-end processing of voice packets. In Nortel’s network, jitter is minimal so have “full duplex” (two-way circuit), It is important from a VoIP perspective we decided to focus our standards more while the other end is set to “half to manage the jitter in the network on reducing latency in the network. We duplex” (one-way circuit). To correct because packets carrying voice informa- set our standards to reduce the jitter these errors, we set our network links to tion should arrive at the destination set buffer firmware value on IP phones to a auto negotiation wherever possible. For within their predicted transport value of 3. This number represents the the links that required a manual setting, intervals. On the receiving side of a number of frames that are held in the we set them to full duplex. voice call, jitter buffers are used to jitter buffer prior to being processed by 4
  • As we cannot completely eliminate Uninterrupted power and redundancy: end devices needed to have a backup packet loss from a network, we have In order to give our VoIP implementa- system in place to prevent communica- created the following grades of service to tion the same reliability as our TDM tion service interruptions. To provide an use with the voice codec: system, Nortel IT had to devise a plan uninterruptible power supply for the that would run all of the same services VoIP services, we chose to provide the • Excellent – Packet loss of 1% or less as TDM without interruption. In order following: • Good – Packet loss from 1.1% to 2% to provide redundancy and continuous • UPS in each closet that houses LAN • Fair – Packet loss from 2.1% to 4% service for our IP-enabled voice equipment switches, we built resiliency into our Other technical considerations network so that voice traffic can be • Power patch panels or router/switch Quality of Service (QoS): The need to rerouted quickly in the event of a power blades to distribute power to plan for QoS in our VoIP implementa- network outage. Additionally, we had to the terminals tion became paramount as we evaluated devise a way to provide uninterruptible • UPS for system platforms like our the network performance requirements power for both the IP phone sets and communication servers and gateways for a VoIP enablement. We needed QoS the LAN equipment that supported the • Power over Ethernet for the IP phones on our converged network to provide voice communications. predictable delay performance and Voice codecs: At the time of our initial packet loss metrics for our latency-sensi- Our existing TDM services were not review, the two industry mature codecs tive VoIP applications. Our plan affected by power interruptions as their were G.711 and G.729. Wideband consisted of classifying applications and systems were engineered with backup codecs had not reached wide industry then creating templates for QoS batteries and the TDM sets were maturity or adoption. Nortel IT marking, shaping, policing and sched- powered directly from the voice reviewed these three primary consider- uling. For more information about our switches. VoIP devices, however, did not ations when determining which VoIP QoS deployment, please read our QoS receive power from the same TDM codec to standardize: for VoIP Best Practice. systems, so both the LAN systems and 1 Voice quality versus bandwidth The R value is an estimate of the voice quality that a user may expect. The minimum R value 2. Susceptibility to network for a VoIP implementation at Nortel should be no less than 70. To calculate the R value for your network, you can use the following equation and tables. performance R = 94 – Lc – Ld – Lp, where Lc = CODEC impairment, Ld = Delay impairment and 3. Application compatibility Lp = Packet loss impairment. Lc Ld Lp Regarding voice quality versus band- CODEC Network Delay Packet Packet width and susceptibility to network CODEC Impairment Delay* (ms) Impairment Loss % Loss performance, G.711 provided clear (ms frames Impairment 0-48 0 advantages. While G.729 reduced g.711 0 0 0 50-99 5 bandwidth requirements through g.711a - law 8 1 4 100-149 10 2 8 compression, it introduced the possi- g.711 mu-law 0 150-199 15 4 15 bility that voice quality would be 200-249 20 250-299 25 8 25 reduced to unacceptable levels, below an * Delay is the averge one-way R-value of 80 (see Table 2). As the call network delay plus packetization and jitter buffer delay. traverses the global network and accesses The table below shows a comparison of R values to the estimated satisfaction rating of end users applications, each G.729 compression/ using VoIP networks with that rating. uncompression sequence along the call path reduces the call quality. G.729 R Value Delay MOS User Experience compression also causes quality loss due 90 4.5 Very Satisfied to incremental increases in latency and 80 4.0 Satisfied packet loss. This is because each packet 70 3.5 Some users dissatisfied 60 3.0 Many users dissatisfied represents a greater proportion of 50 2.5 Nearly all users dissatisfied information versus uncompressed R Value/MOS Estimation Table codecs. Table 2. More information provided in this Nortel Technical Paper. 5
  • Application compatibility also favored G.711. The primary compatibility issue Limited production trial promotes user transition was around dual-tone multi-frequency (DTMF) tone transport. G.729 before our users could reap the benefits of an IP-enabled voice network, we had compression techniques limit the audio to run production trials for the IP phones, soft clients and unified communications applications that we would be deploying to our users. The purpose of these trials frequencies and prevent reliable was to confirm the logistics for deployment and to ensure that they were fully in-band/in-media stream transportation prepared for our users. of DTMF tones. During our decision period, only pseudo out-of-band Nortel IT wanted to make the deployment of the IP-enabled phones and software standards based on SIP INFO messages as seamless as possible. We used the limited production trials to refine our IP had been adopted by the industry. RFC phone, soft client and unified communications client configurations to standardize 2833 had not been accepted as a and minimize end-user configuration. Additionally, we worked out a software distribution process for the soft and unified communications clients to where the universal standard. Consequently, to preconfigured version would be easily downloadable from our corporate software ensure maximum application compat- distribution site. ibility, IT favored in-band transport supported by uncompressed G.711. As the trials progressed, we also updated our project website dedicated to the IP phones, soft clients and unified communications clients. This provided our users After viewing all three consideration with up-to-date answers to frequently asked questions and troubleshooting guides points, IT determined G.711 provided for more common issues. the most robust solution at the single cost of increased bandwidth. Therefore, we standardized on G.711. This able to provide savings to the business data specialists for a new approach in standard is in continual review as new by using VoIP. These highly mobile the operations and management of industry standards and codecs, such as employees, like our sales people, integrated voice, data and video services RFC 2833 and wideband codecs, change executives and teleworkers, became — all running over an IP-enabled the results of each consideration area. known as our sweet spot users and were network. The voice teams had to Preparation chosen to initially test and provide become knowledgeable about the basic From the lab trials, Nortel IT gathered feedback on our VoIP applications and functionality of IP and routing, and the valuable information that assisted in implementation. data teams had to understand how voice preparing for the roll-out of VoIP to our networks are built and operate. Implementation plan: Our IP enable- network. Network engineering guide- ment plans for the voice switches were Nortel IT developed and implemented a lines and processes were updated during validated in the trials. Our plan was to plan that enabled us to train both our the trials to ensure that the most enable VoIP on our network through a voice and data specialists for the effective and efficient procedures were phased approach. In this phased converged network. We created training captured for future use in the roll-out. approach, we determined that the plans for voice specialists that covered VoIP sweet spots: Prior to running any largest payback — with the lowest risk data networking topics and voice-related production trials, we needed to deter- — initially would come about by training plans for the data specialists. In mine which users would be able to upgrading our current TDM voice addition to formal training, Nortel IT provide the most useful feedback and switches to support VoIP services. This also developed low-cost training business benefit for the trial. Initially, would allow us to preserve our invest- methods including: Nortel IT was most interested in ment in the existing TDM phones along • Lunch-and-learn seminars for voice or achieving benefits from the opportuni- with having the advantages of eventually data specialist groups ties that VoIP provides in worker integrating our UC soft client with the user’s existing internal phone number. • Shadowing, or cross-training, where a mobility and the associated cost savings. voice specialist would observe a data By targeting employees that required the Training the converged network specialist or vice versa use of calling cards, business lines at specialist: As the voice and data home or who often incurred costly long • Converged lab spaces where voice and networks would eventually converge, we distance phone charges, we would be data specialists could work together needed to begin preparing our voice and 6
  • • Increased information sharing and By running both lab and limited • We used probes and routers across the gatherings like combined team meet- production trials, we were able to network to obtain traffic data in an ings, network design and standards confirm our network engineering effort to review past traffic predictions sharing, and specialized communica- procedures, validate the performance and to make new traffic predictions if tions that provided useful information requirements for voice quality and a change had been noted. to both voice and data specialists. finalize our user documentation. This • VoIP information was extracted from ensured our roll-out plans would be the IP voice queues and call site’s Along with the training of the voice and efficient and effective. community of interest in order to data specialists, we evaluated the profile the voice traffic. organizational structure associated with Support the engineering and operations of our • Engineering thresholds were set based Support for the production trial of the converged network. This led to the on the ability of the node to meet the soft clients and IP phones was provided restructuring of the organization and busy period within the network. in a number of ways. The most visible reduction of staffing in roles that proved way was in the form of a web page • A continuous report of the R-value redundant. where we posted information about the and packet drops was maintained services, the functionality provided, so that QoS router queues could be Prove adjusted to increase the voice quality frequently asked questions and trouble- For the limited production trials, we throughout the network. shooting guides that would help solve used network testing tools to perform a basic issues. If a user could not solve health check on the WAN into the site their problem with the information on Conclusion prior to a trial deployment of VoIP. This the web pages, we trained our help desk In order to make the first step to a fully solution helped us to pinpoint configu- staff to resolve common issues during converged network, Nortel IT started by ration errors prior to deploying a single the trial and provided contacts for the enabling our voice switches to handle phone on the trial site. Specifically, it help desk staff to use in escalating less VoIP. We evaluated our network and provided an analysis of the circuit common problems to our network defined the performance requirements latency and jitter present on the WAN specialists. needed to integrate VoIP traffic onto link. Within the initial site deploy- ments, it also helped us to determine if In addition to the intranet site, Nortel our existing data network to provide the WAN link was able to support our IT also monitored the IP-enabled voice voice quality that was equivalent to our voice codec, which in our case was traffic to proactively reduce issues on the TDM voice network. Nortel IT ran G.711. data network. We used four basic trials with sweet spot users using IP principles to support the deployment: phones, soft clients and unified commu- nications clients in order to better prepare for the general roll-out of VoIP applications to all Nortel employees. By performing requirement evaluations and trials, Nortel IT was able to develop a cost-efficient and effective plan for implementing VoIP on our network. Written by Adam Rose with technical contribution by Nic James, Jon Sutherland, Paul Berry, Patrick Liu, Michael Carter and John Simons of Nortel IT. Go to www.nortel.com/ nortelonnortel for more Nortel IT case studies, best practices, videos, implemen- tation steps and freeware tools. 7
  • In the United States: In Europe: Nortel Nortel 35 Davis Drive Maidenhead Office Park, Westacott Way Research Triangle Park, NC 27709 uSA Maidenhead berkshire SL6 3Qh, uK Email: euroinfo@nortel.com In Canada: Nortel In Asia: 195 The West Mall Nortel Toronto, Ontario M9C 5K1 Canada united Square 101 Thomson Road In Caribbean and Latin America: Singapore 307591 Nortel Phone: (65) 6287 2877 1500 Concorde Terrace Sunrise, FL 33323 uSA Nortel is a recognized leader in delivering communications capabilities that make the promise The business case and/or financial information of Business Made Simple a reality for our customers. Our next-generation technologies, for presented in this document is based on Nortel both service provider and enterprise networks, support multimedia and business-critical appli- research and is intended for illustrative cations. Nortel’s technologies are designed to help eliminate today’s barriers to efficiency, speed purposes only. It is based on certain assump- and performance by simplifying networks and connecting people to the information they tions. These assumptions may be different from need, when they need it. Nortel does business in more than 150 countries around the world. actual operating factors and may not take into For more information, visit Nortel on the Web at www.nortel.com. For the latest Nortel news, account all factors potentially affecting results. visit www.nortel.com/news. Actual results may vary from what is presented For more information, contact your Nortel representative, or call 1-800-4 NORTEL or here. While Nortel strives to ensure the 1-800-466-7835 from anywhere in North America. accuracy of the information presented in this Nortel, the Nortel logo, Nortel Business Made Simple and the Globemark are trademarks of document, Nortel does not represent or Nortel Networks. All other trademarks are the property of their owners. warrant the accuracy or completeness of this information and cannot be liable for reliance Copyright © 2009 Nortel Networks. All rights reserved. Information in this document is on or use thereof. subject to change without notice. Nortel assumes no responsibility for any errors that may appear in this document. NN124052-020909 BUSINESS MADE SIMPLE