|
|
|
|
| Fault Diagnosis in Converged IP Networks
Before Going Live, Test Equipment and Methods Can Assure Voice, Data and Video Play Well Together. Adding voice to an existing IP data network without testing all potential scenarios is sure to create a network territory where users fear to tread. In telephony, the ultimate test lies with delivering delay-free, public switched telephone network (PSTN) grade service the first time and ever after. To meet this goal, service providers expecting to launch converged IP services must apply a phased approach to equipment and network testing, service validation and ongoing performance and service assurance if they are truly to achieve success with paying customers. The process must confirm not only that voice and the IP network perform well together, but also that voice, data and other applications do not threaten one another's performance along the way. Consequently, what is required is a complete set of test equipment and software tools, together with a set of rigorous testing methodologies designed specifically for the equipment, configurations and engineering designs that make up converged IP networks. Given the right tools and methodology, the process can be thorough, assure five-9's performance at the highest stress levels even before customers touch the services, and can allow the service provider to avoid mopping up a faulty service which has been deployed too early - all without adding unnecessary delays in time to market. First Things First For service providers, lab testing provides an opportunity to kick the tires and make selections among various vendors' VoIP equipment. Much of that equipment is in its infancy when compared to the nearly century-old circuit-switched telephony gear whose performance the VoIP equipment must match. Routers and other standard IP network equipment were not originally designed to deliver voice, which presents a complex set of signaling, security, regulatory and latency requirements that must be understood and tested. Factors like SS7 signaling and call set-up times are strangers to the land of IP. IP network specialists and PSTN specialists must put their heads together to make these worlds unite. Fortunately, complete testbeds are becoming available that bring IP and PSTN tests and expertise under a common roof. A single testbed for VoIP, for example, may need to test IP-to-PSTN gateway protocol performance, as well as SS7, primary rate interface (PRI) and perceptual speech quality measurements (PSQM). As service providers incorporate enhanced voice services and IP multimedia applications servers and policy servers, the processing speeds and response times of those devices also must be taken into consideration. Five 9's performance - the ability to guarantee 99.999% performance in parameters such as network availability and latency - must be tested for each of these network devices, as well as for end-to-end service performance of calls. As they compete to win business, manufacturers of softswitches, gateways and other VoIP equipment must also validate their equipment before it leaves their factory floors, thereby assuring that it will succeed in service provider tests. Further, as many equipment providers extend their product portfolios toward offering complete VoIP solutions, the need to test the entire solution before delivery grows exponentially. To be truly useful in the lab, testing tools must scale up to the capacity levels and the complexity of service mixes expected in the live network. It is a network testing axiom that some network faults will remain hidden until very high network loads are applied. Discovering such faults during test emulations will prevent them from disrupting live service at some later date. Finally, testing tools that can emulate granular variants such as router configurations will help troubleshoot both the equipment and the network even before the network goes live.
The testing tools and the expertise applied to live networks cannot come from only the IP or PSTN side of the house. Traditional methods will not suffice. Just testing IP QoS, for example, will fall short in the live network. Users may not notice half a second delay on a file transfer, but half a second on a link delivering voice will cause the user to hang up in frustration. The notion that, "If the IP network can carry quality data, then voice is just another application," is incorrect. So too is the notion that, "If the voice service runs well alone, it will maintain that performance in a changing converged IP network environment." Testing must involve methodical analyses of multiple anomalies and worst-case scenarios and their impact on all the concurrent services. Does the sudden injection of massive SAP application traffic create delays in voice payloads or call set-up signaling for an IP Centrex customer? What happens to residential email or Internet access when Mother's Day voice traffic ramps up to five times normal peak loads? And what happens to VoIP services when thousands of cable modem or DSL customers tune-in to a Victoria's Secret streaming video? Finally, retesting will continue in perpetuity. Test equipment providers should and will provide right-sized hardware and software probes that can be placed at strategic aggregation and peering points to keep confidence in service performance high over time. As noted earlier, IP networks are like living things that grow and change. With methodical lab, pre-deployment and ongoing service testing, they will do so with ever more contented customers. Tri Do is Systems Engineer for Spirent Federal Systems. (www.spirentfederal.com) |
|
|
