PVQM Proactive Voice Quality Monitoring

Transcription

1 White Paper PVQM Proactive Voice Quality Monitoring A guide to next-generation voice service quality by Steven Taylor

2 Introduction In the near future, enterprises of all sizes will be expanding IP telephony deployments. The rate of evolution, and whether this evolution begins in the WAN or the LAN, varies from enterprise to enterprise. Likewise, the acceptance of the technology and the degree to which applications are integrated varies. But the net result is the same: what we traditionally think of as separate voice and data networks will converge and run over an IP infrastructure. Even though voice is sometimes characterized as just another application, the fundamental aspects of voice conversations place requirements on the network that are quite different from data applications. These requirements boil down to providing toll quality voice, which is measured in terms of clarity and low delay. Unlike data applications, in which automatic retransmissions of erred data is a given, with voice, you don t get a second chance to get it right. The truth about VoIP quality Several years ago, early adopters were willing to settle for sub-par voice quality in order to gain the significant economic benefits provided by IP telephony. As the technology has matured, traditional leaders in voice networking, such as Nortel Networks, have brought toll-quality voice to IP telephony. As a result, the table stakes have changed and users assume that voice quality over an IP network will be as good as traditional voice. Another assumption is that IP telephony works well on network transport infrastructures designed for low latency and high reliability. However, IP telephony deployed over a poorly designed network results in poor voice quality. Making IP telephony work goes beyond tuning the data network infrastructure. For instance, the appropriate voice coder/decoder 2 (codec) must be chosen for converting analog voice to digital voice. While the days of assuming that IP telephony is synonymous with poor quality are gone, it remains incumbent on the providers of this technology to prove that the voice quality is good. This is in stark contrast to traditional voice networks where basic quality is assumed and there is no requirement for proactive voice quality monitoring. Proactive Voice Quality Monitoring Real proof of quality is quantitative and to address this need, new capabilities called Proactive Voice Quality Monitoring (PVQM) tools are being developed. These tools allow accurate measurement of voice quality at the IP client, providing continuous passive monitoring to ensure satisfied users of IP telephony solutions. PVQM goes far beyond the capabilities of traditional voice networks, providing a call-by-call analysis that alerts network management personnel to potential trouble spots before users are even aware that a problem exists. And because PVQM monitors call quality from the IP client itself, it provides true end-to-end quality assessment. PVQM also has an active monitoring component to enable predictive analysis of potential degradation in voice quality. Potential problems can be addressed before users experience any actual call quality problems. When you link voice quality management with infrastructure management, you further simplify the troubleshooting and diagnostic tasks associated with maintaining toll-quality voice services. Led by companies like Nortel Networks, these PVQM capabilities provide the tools to take voice quality management beyond traditional telephony to a level that will become the norm for next-generation voice networks. PVQM Proactive Voice Quality Monitoring enables the delivery of toll quality voice services over an IP infrastructure. With the ability to proactively monitor call quality and quickly diagnose voice and infrastructure problems, enterprises and service providers can deliver the same highquality voice services of traditional telephony. The business implications for PVQM are tremendous. On one level, this capability removes a major barrier to IP telephony implementations by answering the question of whether IP telephony sounds good. More importantly, PVQM actually provides the enabling technology and metrics to include voice quality as a key parameter in a service level agreement (SLA), whether the corporate telecommunications department offers an SLA to internal users, or a service provider offers an SLA to external customers. Defining voice quality For traditional telephony networks, defining voice quality is not a major issue. Excellent voice quality is assumed, and voice quality monitoring is performed on an exception basis; for example, if a user complains of poor quality. Troubleshooting in this instance could include the use of test tones and signal-to-noise ratios, and could result in the dispatch of a repair person for on-site maintenance if the problem exists in the telephone set or its associated cabling.

3 Figure 1. Selected key characteristics of various codecs. IP telephony presents a new set of challenges. In contrast with traditional voice calls, IP telephony voice quality problems are likely to be more transient and difficult to pinpoint simply because the calls are transported on a shared packet network. Insufficient resources in a traditional voice system may result in call blocking an all circuits busy condition. Insufficient resources for IP telephony usually results in impaired voice quality since the resources are assigned on demand rather than on a call-by-call basis. So, while one is less likely to have blocked calls in an IP telephony environment, call quality degradation is more likely to occur. Defining voice quality is a daunting challenge. Everyone has his or her own opinion of what does and doesn t sound good. Consequently, there is a need for some objective metrics for this most subjective of topics. One of the most popular metrics for defining voice quality is a subjective rating known as a Mean Opinion Score (MOS). Defined on a scale of one to five, with five being the highest, any MOS Figure 2. MOS and R-Values and voice quality ITU-T Codec Coding Bit rate Sample size Encoding Mean Opinion standard scheme used (Bits) delay time Score G.711 PCM 64 kbps 8 <1 msec 4.4 G.726 ADPCM 32 kbps 4 1 msec 4.2 G.729 CS-CELP 8 kbps msec 4.2 G MPMLQ 6.3 kbps msec 3.98 G ACELP 5.3 kbps msec 3.5 Source: IP Telephony Demystified by Ken Camp. Published 2003 by McGraw-Hill of 4.0 or higher is generally considered to be toll-quality voice. In this respect, MOS is an excellent method for measuring the quality of various voice encoding methods, and there is general, though not exact, agreement on the quality of various algorithms. Several of the most popular coding algorithms, or codecs, are shown in Figure 1. While MOS values are an excellent first approximation for voice quality, they are also somewhat limiting. MOS values reflect exactly the quality of the voice when it is transformed from analog to digital voice no more and no less. One can readily discuss the relative merits of pure 64 kbps PCM with an MOS of 4.4 as compared with 32 kbps ADPCM or 8 kbps CS-CELP, both of which have MOS values of 4.2. However, MOS R-Value User MO Very satisfied Satisfied TOLL QUALITY Some users dissatisfied Many users dissatisfied Nearly all users dissatisfied Not recommended values don t represent the impact of network impairments. Various forms of delay and packet loss (which could be viewed as an extreme form of delay) have a profound impact on the voice quality. Consequently, there s a need for a more extensive evaluation procedure that accounts for these network impairments called the R-value. The R-value is an objective measurement of call quality that takes into account the impact of impairments on call quality, including codec, latency, jitter, etc. To help bridge the qualitative and quantitative measurements, R-values can be mapped to MOS scores (Figure 2). Voice quality monitoring reference architecture Because there are so many factors that can affect voice quality, it is imperative to develop a reference architecture that includes all factors affecting voice quality in order to define which factors are reasonable to measure and which lie outside the scope of a monitoring architecture. Voice quality and the IP telephony client The job of the IP telephony client is to convert the sound waves produced by the human voice into a digital format that is appropriate for transport over a network and to convert similar received signals back into sound waves. Defining what the telephony instrument is for IP telephony 3

4 can be a bit of a challenge: it can be an IP phone that has the look and feel of a traditional phone; it can be a soft phone that is implemented via software on a PC or PDA; it may even be a standard digital phone or even an analog phone connected to an IP-enabled PBX or to an IP telephony-enabled router. Obviously the design and construction of the IP telephony client has an impact on the perceived sound quality and high-quality components and good design should factor into the choice of the IP telephony client. But beyond the manufactured quality of the IP telephony client, the type of telephony instrument will also determine if it possible to passively monitor IP telephony performance end-to-end. When a traditional telephone is used, the quality monitoring stops in the IP-enabled PBX or IP telephony-enabled router, since traditional phones are not equipped for voice quality monitoring (Figure 3). This makes sense because up to point of entry into the IP network, dedicated bandwidth is assigned to the conversation for that phone so there is no need for voice quality monitoring between the IP-enabled PBX and the telephone. Similarly, connections to the legacy public switched telephone network may only be monitored to the point that they enter the IP-enabled PBX or IP telephony-enabled router. A further consideration is the extent to which the voice quality may be monitored. The old adage of garbage in garbage out still applies. Voice quality monitoring can only look at whether the input sound is being reproduced faithfully. If a call is made from a noisy office environment as opposed to a carefully controlled testing room, the perceived quality will be different. However, both will be measured based only on the sound that is submitted to the phone. Another important factor in voice quality is the choice of voice encoding algorithm, or codec, for a given call. Different codecs use different amounts of bandwidth (Figure 1). In general, the more bandwidth used, the better the sound quality. Because each codec responds differently to various impairments in the network such as packet loss, jitter, and latency, an accurate evaluation of voice quality must include and go beyond codec choice. Figure 3. Reference architecture for voice quality monitoring IP Phone Software Phones IP PBX IP-enabled PBX or VoIP Router PSTN LAN Switches/Routers IP Transport Network WAN Switches/ Routers Traditional Phone Can be monitored Can t be monitored 4

5 Figure 4. Per-packet delays for various packet sizes and transmission speeds IP telephony clients support a variety of codecs, and, in general, an appropriate codec will be negotiated at the beginning of each call. When there is ample bandwidth such as a call within a campus where the high-bandwidth LAN is used, a higher bit-rate codec is chosen. However, if the call is between two international points where the bandwidth is limited and expensive, a lower bit rate codec is chosen. Thus, it is imperative that voice quality monitoring be performed on a call-by-call basis, and the codec that is used for each call must be an integral part of the quality evaluation process. Delay (msec) 10,000 1, Freeze-out Myth and Reality 64 kbps ,000 10, ,000 Speed (kbps) Source: Distributed Networking Associates, Inc. T1 10 Mbps Ethernet T3 500 Bytes 4,000 Bytes 100 Mbps Ethernet 32 Bytes Finally, another characteristic that impacts perceived voice quality is echo. Echo cancellation deals with most of the disruptions in voice communication, but high network latency will exacerbate a pre-existing echo problem. The PVQM solution doesn t directly monitor the impact of echo on voice quality. Voice quality and the transport network Once the external factors have been addressed, the data transport network and its effect on voice quality need to be considered. Even an excellent phone with a high-quality codec doesn t guarantee good or even acceptable voice quality. The MOS values in Figure 1 assume that there isn t any network degradation and doesn t take into consideration the network conditions affecting voice quality: network delay, packet loss, and jitter the latter two of which can be considered alternate manifestations of delay. The role of absolute delay in voice quality Absolute delay is the first network impairment that causes a perceived loss of voice quality. Similar to the delay experienced talking over satellites, too much fixed delay in the packet network for IP telephony can adversely impact normal conversation. This is in stark contrast to data applications where receiving information a bit late is better than not receiving it. For IP telephony, never is preferable to late once a certain threshold is reached. As a rule of thumb, a one-way delay of less than 150 milliseconds is acceptable and under certain conditions, one-way delay can be as high as 250 milliseconds. A wide range of factors contribute to fixed delay. The first is the encoding delay from the chosen codec algorithm. Different codecs have different inherent delays due to the sample size. However, since a single voice packet may (or may not) contain multiple samples, the number of samples per packet must also be considered. A second source of fixed delay comes from the switching time for each individual packet, sometimes called the packet time. The packet time is calculated by dividing the packet size by the transmission speed. Every time a packet crosses an interface in a switch, one packet time is incurred. Of course, some of these effects are mitigated if the packet is segmented, such as when IP telephony is transported in a cell-based ATM or MPLS network. As shown in Figure 4, this is a major problem only if the maximum packet size is very large and/or the network transmission speeds are quite low. As LAN and WAN services move to higher speeds, this becomes less of an impediment. Also, as LAN transmission speeds tend to be at least a couple of orders of magnitude faster than WAN transmission speeds, this delay tends to be much less of an issue in the LAN. Fixed delay can also come from a number of other sources. There is some delay, albeit negligible in most cases, simply from the propagation time in the network. Since most network transmissions occur at a fairly large fraction of the speed of light, this is usually minimal unless the transmission path involves satellites. Other factors that could add delay include the time for optional encryption, intrusion detection filtering, and similar processes. The role of packet loss in voice quality In many ways, packet loss can be viewed as an extreme case of delay: the packets are so severely delayed that they never arrive. There are a number of reasons that packets could be lost in transit: 5

6 If a network failure occurs, packets may be lost during the time that traffic is rerouted onto alternate facilities Some Layer 2 protocols Frame Relay, ATM, and MPLS, in particular detect erred packet and discard them Packets are sometimes considered lost if there is excessive jitter and the packet arrives too late The bad news is that you will occasionally lose packets; the good news is that the various codecs can recover from random packet loss. In the case of traditional 64-kbps PCM, the waveform for the voice signal is essentially mapped with discrete samples every 125 msec. Losing a few of these samples results in minimal disruption. More advanced algorithms carry more information per sample. Referring again to Figure 1, each sample using G contains about 30 msec worth of information, so a significant amount of information is lost whenever a packet is lost. However, these more advanced codecs are also designed to incur random packet loss without severe degradation. In fact, in most cases the voice codecs can deal with packet loss much more readily than data applications can deal with this same amount of loss. Nevertheless, if there is significant loss of consecutive packets, voice quality degrades. The impact of packet loss is highly dependent on the distribution of the loss. Losing a few packets randomly over a long time causes less impairment than losing the same number of consecutive packets. The role of packet jitter on voice quality The third type of network impairment is packet jitter. Packet jitter refers to variable delay on a packet-to-packet basis as it traverses the network. For most data applications, this has a minor impact. Data protocols are designed to collect 6 information and to transmit and receive this information whenever it is available. As long as each packet arrives intact, the timing between packets is of relatively minor importance. This is referred to as asynchronous transmission: there is no fixed relationship between the timing at the sending and the receiving end. Voice is quite different. It is a synchronous service: an exact relationship must be maintained between the source and the recipient of the information. A couple of hundred extra milliseconds can t be added in the middle of a word simply because the information didn t make it there on time. Moreover, if you get two packets belonging to the same conversation in rapid succession because the first was delayed and the second wasn t delayed, they can t be played out simultaneously. The first must finish before the second is begun. Smooth playback of voice packets is achieved by the use of jitter buffers. A jitter buffer is specialized memory that holds a given number of packets so that all packets can be played back smoothly. Think of the jitter buffer as a funnel going into a bottle. The flow into the bottle is limited by the size of the small end of the funnel. As the liquid is poured, the funnel is almost full, and then pouring stops until the funnel is almost empty. As long as there is some liquid in the funnel, there is a smooth flow out of the funnel into the bottle. Jitter buffers work the same way. There is a known output rate for packets from the network to the IP telephony application. Initially, a few packets are buffered and the funnel is allowed to fill a little, intentionally introducing some delay. As later packets arrive (a little slower or a little faster than the average transit time), the funnel gets a little more or less full, but the output stays steady. Continuing with the funnel analogy, there are underflow and overflow conditions. An underflow condition is when there are not enough packets to buffer and overflow conditions are when there are too many packets to buffer. Jitter buffers can also experience underflow and overflow. If severe events happen within the network, then packet flows can be totally interrupted, resulting in an underflow condition in the buffer when there simply aren t any packets available for output. On the other hand, if the buffer isn t large enough, it s possible that the buffer could overflow. Initially setting the appropriate size for the jitter buffer of your network is a nontrivial task. If the buffer is very large, few packets will be lost, but it can introduce significant delay. On the other hand, if the jitter buffer is too small, then delay is minimized, but there are more likely to be buffer underflows. For instance, if there are significant queuing delays due to multiple traffic types or simply due to severely underprovisioning network resources, more jitter is introduced as the voice traffic waits its turn in the network. One technique that some network managers use to solve the jitter problem is to throw more bandwidth at it. In some cases increasing LAN bandwidth is a viable option. However, in some cases adding bandwidth isn t an option. For instance, adding bandwidth is problematic when the bandwidth is limited by expense over the WAN, lack of highspeed bandwidth for remote users, or the first generation of wireless LAN products. Another simpler technique of minimizing jitter is simply using differential queuing that gives voice packets higher priority than other packets.

7 Figure 5. Passive voice quality monitoring with passive and active monitoring software IP Phone Software Phones IP PBX LAN Switches/ Routers IP-enabled PBX or VoIP Router IP Transport Network WAN Switches/Routers Voice Quality Monitoring System Jitter is the major issue of network impairment affecting packetized voice quality. If all packets for a conversation arrive in a timely fashion with minimal delay and packet loss, then the voice quality will be good. However, once you exceed certain thresholds, the voice quality starts to degrade. Analyzing jitter at appropriate points within the network can also be used to monitor voice quality. Monitoring voice quality proactively By integrating appropriate hardware and software at various points in the network, it is possible to monitor the voice quality for IP telephony calls. One company, Nortel Networks, is taking a leadership position in this type of monitoring. As shown in Figure 5, each IP telephony client, soft phone on a PDA, or PC can be monitored for voice quality and the conversations can be assessed in an ongoing fashion by doing a detailed analysis of the jitter buffers and matching the codec and other relevant parameters. It is also possible to make a similar assessment of voice quality in IP-enabled PBXs and in IP telephony-enabled routers at the point that IP telephony is converted back to a traditional format. In these situations, impairments that are due to IP quality as opposed to other factors like a bad handset can be detected. Most significantly, this type of analysis is totally passive and non-disruptive. Monitoring the IP telephony clients on the userside of the jitter buffer doesn t interfere with the call in progress, just as watching the level of the liquid in the funnel example doesn t interfere with the flow of the liquid. Moreover, any underflow or overflow conditions can be detected. The information concerning the jitter buffer condition can be correlated with other real-time information that is available concerning the call in progress. For instance, depending on whether the call in progress is connected to another party locally or to someone in an international location, a different codec may be in use. (Typically higher bit rate codecs are used for local calls for better quality where the bandwidth consumed is a minor issue.) Consequently, a numeric representation of the quality can be assigned to the current call. There are various times throughout the call that recording these call quality metrics is useful. For example, recording metrics a few seconds after the call is established is useful in case the call is dropped. This information could possibly be correlated with call detail records to enable the network administrator to get a good idea of whether the number of calls of very short duration (less than 10 seconds) are due to poor call quality versus dialing a wrong number. Similarly, end-of-call metrics are very important for determining the percentage of calls that are disconnected due to poor quality. An important distinction of a PVQM system is the ability to monitor and report on call quality in process, not just after 7

8 the end of a call. This enables more timely and accurate resolution of potential call quality problems, especially on more lengthy calls. This includes the ability to set call quality thresholds so that an exception is reported if the quality drops below a preset value. For instance, if the nominal value for international calls is a given number, the network administrator may want to know if the quality drops below this number. Of course, having information is interesting, but it s not particularly useful unless there is something you can actually do with the information. This is where the real power of PVQM starts to become apparent. For example, assume that the network management system receives an alert (exception report) indicating that there is a call in progress that is dropping below the desired quality threshold. At this point a trace-route can be initiated to find out how the call is actually routed. (This is critical since calls may take different routes at different times.) A first level of information is simply to identify which devices IP PBXs, LAN switch/routers, and WAN switch/routers are involved in the call. If the same device shows up in multiple exception reports, this provides a strong indication of the location of the potential problem. Some companies, such as Nortel Networks, are going beyond a simple trace route to integrate voice quality monitoring statistics with their element management systems. This allows network managers to link voice quality degradation with specific infrastructure impediments. With a little more intelligence in the network, this can be taken even further. Assume that the switch/routers have been identified, and also that the switch/routers can be queried by the management system. Jitter buffer problems in the end devices occur because there is a buffer problem somewhere in the transport network. If the internal network components are appropriately equipped, the management system can query the switches and routers concerning their buffer status and pinpoint the problem. The end result is that voice quality is monitored continuously. When a problem occurs, the first level of diagnostics is initiated without any manual intervention on the part of the network administrator. Finally, a good passive voice quality monitoring system is augmented by an active voice quality monitoring system that sends synthetic voice traffic streams across a network infrastructure. For example, imagine you have a distributed contact center in three locations. At each location, synthetic voice transactions run between all of the other locations and measure the impact that the network has on the quality of that synthetic transaction. As these transactions, potential network problems can be spotted before it impacts the actual voice quality of real users. Moreover, the statistics that you collect will enable you to plan appropriately for new network infrastructure upgrades or codec tuning. PVQM example of diagnostics and troubleshooting Let s look at a couple of real-world examples when there is a complaint from a user about poor voice quality. With traditional telephony, this is a timeconsuming and personnel-consuming task, requiring disruptive testing. Transient problems of this type are difficult to track, and assuming that the end equipment checks out, the testing tools are limited to doing loopbacks and tone testing. If the problem is due to either a bad trunk group or a bad line within a trunk group, it is difficult, but not impossible, to pinpoint the problem. When there is indeed a problem, it tends to be related to a given network element because, as discussed above, network traffic congestion results in all circuits busy as opposed to degraded call quality. The result: you eventually find the problem, but the testing has been disruptive and personnelintensive for both the telecom staff and the user. Now let s contrast this with PVQM in which the proactive processes will already have noticed that there is a problem so the user can be notified that their problem is known and that corrective action is already in process. Assuming that the user reports the problem before corrective action has been initiated, the network administrator can query the PVQM application for call quality on recent calls. If the PVQM has not detected a problem, then the problem must lie outside the IP telephony network, thus avoiding the new kid on the block syndrome where the most recently implemented system is the most likely suspect for problems whether it is where the problem really lies or not. Hours, if not days, of finger pointing can thus be avoided. Additionally, the network administrator may wish to set a more stringent threshold for calls from the extension in question, thereby creating traps for calls that might otherwise be considered borderline. This level of diagnostics also allows a layer of objectivity to be superimposed upon a very subjective complaint. For instance, if one user complains about the quality and five other users have identical equip- 8

9 ment and aren t complaining, and all the calls have similar quality measurements, then the problem may lie with the user s perception rather than the equipment. The bottom line is that the troubleshooting capabilities actually significantly exceed those available for traditional telephony. Rather than simply meeting an objection to deployment, a powerful tool is added that makes troubleshooting faster and simpler in an IP telephony environment. PVQM example of Service Level Agreements for voice quality PVQM can be used to offer and monitor compliance with SLAs based on call quality. Rather than simply answering a common objection to IP telephony implementations, PVQM can be used to expand services quickly. In the preceding sections, the process for passively monitoring call quality and reporting this quality to a centralized database upon completion of the call was discussed. Thus, it is at least theoretically possible that each call detail record can have a voice quality value associated with that particular call. There are multiple ways that the SLA could be constructed. An average quality value for local calls and another value for calls across the WAN could be offered. Or the SLA could be constructed to ensure that a certain percentage of calls or of call minutes meet a given value. This opens the way for enhanced service for both enterprises and for service providers. For the enterprise, various departments can be given an SLA for their use of the internal voice services. This should be useful in meeting objections from any factions within the enterprise who simply don t believe that IP telephony is a good idea. For service providers, this opens the door for an enhanced service offering. By offering an SLA for the voice service based on an objectively measured numeric value, the quality is guaranteed. Further, the user is able to verify that the SLA is being met because the compliance tools are integral to the technology itself, unlike other SLAs that often require active testing for ensuring compliance. Summary IP telephony is quickly growing in popularity because of the tactical and strategic advantages it brings to enterprise networks. From the tactical perspective, operations costs are contained and toll bypass can provide significant cost savings. More importantly, from the strategic perspective, IP telephony is an enabling technology that facilitates better customer relations and more productive employees via applications like collaborative computing, next-generation contact centers, and integrated messaging. Nevertheless, in some circles the willingness to move to this technology is stifled by concerns about voice quality. While the community of people who believe that IP telephony quality is good continues to grow, the show-me concerns must still be met. And this is exactly what PVQM does. What s more, PVQM goes beyond addressing this objection. It doesn t just level the playing field; it changes the rules of the game by demonstrating that IP telephony call quality is both quantifiable and actionable. By passively monitoring call quality, potential trouble spots are identified and can be corrected before users notice a problem. This takes voice service delivery to the next level. IP telephony is not only demonstrated to be as good as traditional voice; rather, the capability for guaranteeing quality is taken to the next level. PVQM not only removes a barrier for IP telephony deployment, it clears the way for enterprises to move full speed ahead with converged networks for the 21 st century. Steven Taylor, consultant and broadband packet evangelist, is President of Distributed Networking Associates and Publisher of Webtorials.Com. An independent consultant, planner, author, and teacher since 1984, Mr. Taylor is frequently quoted in the trade press and is one of the industry s most published authors and lecturers on high bandwidth networking techniques. He has served as a Contributing Editor for Data Communications magazine, publishes articles in both Business Communications Review and Network World, and co-authors two newsletters Convergence and Wide Area Networking distributed by Network World Fusion. Augmenting his skill as a teacher and consultant, Mr. Taylor s background in actually planning, implementing, and running an extensive network for the University of North Carolina brings a unique, real-world perspective to his work. 9

10 In the United States: Nortel Networks 35 Davis Drive Research Triangle Park, NC USA In Canada: Nortel Networks 8200 Dixie Road, Suite 100 Brampton, Ontario L6T 5P6 Canada In Caribbean and Latin America: Nortel Networks 1500 Concorde Terrace Sunrise, FL USA In Europe: Nortel Networks Maidenhead Office Park Westacott Way Maidenhead Berkshire SL6 3QH UK In Asia: Nortel Networks Asia 6/F Cityplaza 4, Taikooshing, 12 Taikoo Wan Road, Hong Kong Nortel Networks is an industry leader and innovator focused on transforming how the world communicates and exchanges information. The company is supplying its service provider and enterprise customers with communications technology and infrastructure to enable value-added IP data, voice and multimedia services spanning Wireline, Wireless Networks, Enterprise Networks, and Optical Networks. As a global company, Nortel Networks does business in more than 150 countries. More information about Nortel Networks can be found on the Web at: For more information, contact your Nortel Networks representative, or call NORTEL or from anywhere in North America. *Nortel Networks, the Nortel Networks logo, and the globemark design are trademarks of Nortel Networks. All other trademarks are the property of their owners Copyright 2003 Nortel Networks. All rights reserved. Information in this document is subject to change without notice. Nortel Networks assumes no responsibility for any errors that may appear in this document. NN