Jump to content, skipping navigation

Triple Play DSLAM Testing White Paper

    * Required Field

    Cancel

    Sales Information Call North America: (800) 927 2660 International: +33(0) 1 61 37 2250 Spirent DLS/AE Products Tel: (613) 592 2661 Fax: (613) 592 0522 ae.spirentcom.com AccelerateAssure WH ITE PA PE R IntroductionDSL service providers are pushing toward the holy grail  of Triple-Play services, whereby telecom carriers deliver voice, data, and video services through one pipe. The drive behind this movement is to increase profitability and retain customers. Customers that buy multiple services from a single provider have more longevity than single-service subscribers. The more services that a customer has, the more difficult it is for them to switch to a competitor. Thus, triple play is extremely attractive to carriers. How does the drive towards triple play affect DSLAM equipment manufacturers? Next generation DSLAMs must be able to support higher bandwidths and a guaranteed Quality of Service, while at the same time be relatively easy to deploy and manage. By adding layer 3 functionality to DSLAMs, Triple-Play services can be supported while effectively managing bandwidth. This allows service providers to minimize time to market for new services based on market demand. Providing Triple-Play services does not come without its challenges. DSLAM vendors must be able to guarantee that their equipment can provide the QoS that is necessary to ensure a quality user experience, which minimizes customer turnover. This brings special test challenges to the DSLAM manufacturers and DSL service providers. This application note explores the new technical and testing requirements for next generation DSLAMs that support Triple- Play. Testing Current DSLAMs Traditional DSLAMs are basic layer 2 devices, whose main function is to aggregate traffic from many DSL connections into one large connection. The DSLAM multiplexes the DSL lines into a high-bandwidth (typically) ATM connection such as an OC-3/STM-1. The high-bandwidth trunk connects the DSLAM to a BRAS (Broadband Remote Access Server), which authenticates the users and connects them to the Internet. This network is shown in figure 1 below. Figure 1: Traditional DSL Network Performance and functional testing for this type of DSLAM is generally limited to determining if the DSLAM will support a fixed traffic rate of a few different packet sizes. Test set-ups typically consist of multiple CPE modems, with each modem attached to a traffic generator/analyzer connecting to the DSLAM. Another high-bandwidth connection from the traffic generator/analyzer connects to the DSLAM in place of the BRAS. This test network is shown in figure 2 below. Figure 2: Typical DSLAM Test Setup This simple test has sufficed, as the main application for this type of DSLAM is limited to data or Internet service. Internet service is deployed as best -effort  meaning th at there is no QoS applied. This service also uses the TCP protocol which retransmits data should packet loss or packet errors occur. Stated another way, while errors may occur, the end-user is unaware that they have taken place due to the checks and balances put in place. Modem DSLAM ADSL2+ OC-3 STM-1 PPPoEoA Gig E BRAS INTERNET DATA Modem DSLAM ADSL2+ OC-3 STM-1 Traffic Generator/ Analyzer Traffic Generator/ Analyzer POTSor Triple-Play DSLAM TestingADSL2+ Now for ADSL2+ Over POTS or ISDN ISDN POor Sales Information Call North America: (800) 927 2660 International: +33(0) 1 61 37 2250 Spirent DLS/AE Products Tel: (613) 592 2661 Fax: (613) 592 0522 ae.spirentcom.com Spirent s Triple-Play DSLAM Testing White Paper 2 Testing Triple-Play DSLAMs The network required to support voice, video and data (Figure 3) is far more complicated than that which supports only data. To support Triple-Play the DSLAM must take on greater functionality. In addition to its job of aggregating users, it now needs to be aw are  of the traffic flowing though it. This is required in order to effectively manage bandwidth on the network. For example, when supporting TVoDSL the DSLAM plays an intermediary role, bringing in only the channels that have been requested by its users. Triple-Play services also require that QoS support be implemented to ensure that traffic is reliably transferred to the user and is correctly prioritized based on predefined rules. Figure 3: Triple Play Network With the DSLAM now supporting higher layer functionality and requirements for QoS, there are many issues which must be considered when testing Triple-Play functionality and performance. CPE Modems Great for consumers, but not very useful as test devices The CPE modem is a cost-optimized consumer device. As such it was never designed to be a piece of test equipment. Modems have a limited buffer, which can lead to dropped packets. Testing using this setup will not be able to determine if dropped packets are due to the CPE, or the DSLAM. The CPE will also add additional latency and latency variation into test results, making it impossible to isolate DSLAM performance. While this was acceptable when Internet data transfer was the only application, it is unacceptable for Triple-Play. With ADSL2 and ADSL2+ many messages and alarms are sent between the modem and DSLAM allowing the systems to make decisions about everything from power states to error conditions. While this functionality is implemented in modems, they are designed to be simple for end users to set up and therefore are extremely limited in terms of configurability. Testers can t force modems to produce DSL messages and alarms and therefore the DSLAM's response to these messages can t be evaluated. Another drawback to this test technology is the lack of basic line simulation. Introducing attenuation as caused by the local loop will induce the DSLAM into different power modes, an important feature of the DSLAM that should be tested. Using individual CPE modems is not scalable for testing. This setup quickly becomes very difficult to manage as large racks of modems and associated wiring complicate the testing process and increase the actual overall cost of test set up and ongoing test bed maintenance. As the density of DSLAM blades continues to rise, test beds must be able to scale accordingly. While testing DSLAM performance and functionality using real modems was acceptable when Internet was the only application, another solution is required for Triple-Play enabled DSLAMs. Testing Voice With a huge variety of voice services, if voice services don't work righ t,  users will jump ship. Unlike the data on IP networks that can tolerate delay well, voice is vastly different. Voice is very latency sensitive. The definition of latency is as follows:! The time it takes for a packet to travel from sender to receiver! The period of time that a frame is held by a network device (i.e.: DSLAM) before it is forwarded. Packets within IP networks will experience latency due to the processing time taken by equipment in the network. While low- bandwidth  applic ations, such as email, can tolerate latency, even a small delay equates to a major nuisance for VoIP users. Consider a two-way phone conversation. Delays in voice traffic create gaps in the transmission that may be heard by the receiver, resulting in unhappy customers. To achieve high quality voice the maximum desired one-way latency is 150ms. If round trip delays exceed 250ms voice users will notice delays, and callers will start to talk over each other. Anything beyond 500ms deems the call impractical. It is important to measure the latency caused by the DSLAM to ensure it will not affect voice quality when the system is deployed. AccelerateAssure DATA IP VOICE IP VIDEO Modem IP MULTICAST NETWORK MIDDLEWARE SERVER VIDEO SERVERDSLAM ADSL2+ OC-3 STM-1 PPPoEoA Gig E Gig E Gig E ASBR INTERNET Gig EIGMP VOIP SERVICE PROVIDER IGMP IGMP SNOOPING SIP Sales Information Call North America: (800) 927 2660 International: +33(0) 1 61 37 2250 Spirent DLS/AE Products Tel: (613) 592 2661 Fax: (613) 592 0522 ae.spirentcom.com Packet loss will also substantially impact the quality of voice services. While loss of data packets can be remedied by re- transmission, voice applications use the UDP protocol, which does not support packet re-transmission. The quality of the conversation will lag if packet loss reaches more than 5%. The high sensitivity of voice service requires that all network equipment, including the DSLAM, be tested to determine the latency and packet loss of the device. It is important to test the DSLAM performance with a variety of load conditions, i.e.: Will the DSLAM prioritize voice packets over data packets? Will a subscriber's high-bandwidth activity affect another subscriber's voice service? How does voice service degrade when the DSLAM is experiencing a high load? These questions are difficult to answer due to the limitations of existing DSLAM test beds. Testing Video Fast channel changes and excellent picture quality are the name of the game. There are a few different types of video commonly provided, each with it's own QoS requirements and testing needs. Broadcast video or TVoDSL, requires a higher QoS than data or internet services. Since lucrative opportunities exist in offering digital-quality television services to subscribers, the end customer must receive video that can compete with the quality of cable and satellite. A typical digital CATV quality video with MPEG-2 encoding and CD-quality audio requires approximately 3.75 Mbps of bandwidth per channel. HDTV requires even more bandwidth, in the range of 20Mbps. Broadcast video is multicast, using the IGMP protocol to allow users to join and leave a video stream. The DSLAM must be IGMP-aware, so that redundant video flows to the DSLAM WAN connection can be eliminated. Studies show that on a system with 200 users, up to 80% will be watching the same 6 channels. Thus, multicasting from the DSLAM results in a great deal of bandwidth savings on the WAN connection (see Figure 4). Users must be able to switch channels with minimal delay. When a 'channel change' is requested, the user is leaving one multi-cast video stream, and joining another. In order to compete with cable and satellite, the 'channel change delay' must be short. The time it takes from when the user presses the button on the remote to change channels to when they see the new channel must be minimized. If channel change delay is higher than 500 milliseconds users will notice a difference between TVoDSL and traditional video services. To further complicate the DSLAM's role in TVoDSL, with picture-in-picture and an average of 3 TVs per household, users expect to seamlessly receive multiple channels at the same time. Spirent s Triple-Play DSLAM Testing White Paper 3 TVoDSL is less sensitive to latency than video conferencing and voice. Traffic is one way, so as long as the end-point buffer is longer than the maximum latency, the end customer will not experience degradation in video quality due to latency. If the jitter (variation in latency) exceeds the length of the end point buffer, the buffer will be emptied and show poor video quality, pixelization or even a blank screen. The loss of an IP packet containing video will be noticeable to viewers, so these losses must be minimized. Retransmission of missing packets is usually not viable, especially when the service is being multicast to a wide audience. Mis- inserted packets are generally discarded by the set-top box and will also lead to poor video quality. Also, if jitter is high, the end-point buffer can also overflow, causing loss of packets. Testing the DSLAM's performance for TVoDSL requires loading the system with many customer premises, each with multiple set-top boxes, then testing the DSLAM's ability to deal with multiple channel change patterns (sequential bursts or random skipping between channels). The DSLAM's effect on multicast data streams must be tested at the receive end for packet loss, packet mis-insertion, latency, jitter and data integrity. Due to the sensitive nature of TVoDSL, accurate measurements must be made to determine how well a DSLAM can provide multicast video, i.e.: How quickly the DSLAM can respond to multi-cast join and leave requests, allowing the user to change channels quickly? How much packet loss is caused by the DSLAM? What happens when multiple users in a home are all switching channels at once? Like voice testing, accurate testing on video traffic cannot be made in the current types of DSLAM test beds. 4: Figure AccelerateAssure NETWORK Spirent DSLAM Test Solution with 168 ports per chassis How fast can you change channels? How is your voice quality? How fast is your data transfer? i QoS for voice? 16 8 l ine s o f A DS L2 + T raf fic / C ha ss is 16 8 l ine s o f A DS L2 + T raf fic / C ha ss is Video-on-demand (VoD) and Pay Per View services are similar to broadcast video in that they must be high quality and consume a large bandwidth. The difference is that VoD content is watched continuously, so there is no need to test channel change delay. However, latency and packet loss are just as important. Like TVoDSL, the jitter must be less than the length of the end-point buffer. Packet loss, jitter and mis-inserted packets must be minimized to ensure VoD subscribers receive high-quality video. VoD subscribers expect DVD-quality picture and sound. The DSLAM must be tested to ensure it can provide the quality of service required to keep subscribers happy. Video conferencing requires two-way (or 3-way and higher) communication. Similar to voice, it is very sensitive to delay. Desktop video conferencing (i.e. web cams) can be of rather rough quality supporting a small picture and round-trip delay of up to 750 ms. In contrast, expectations for conference room video are that picture quality and resolution will be only moderately worse than broadcast TV (round-trip delay should be less than 450 ms). If video conferencing is to be offered as a revenue generating service it will have to use QoS to ensure that latency, jitter and packet loss are minimized and that it is prioritized over other less sensitive types of traffic. The DSLAM must be tested to ensure that it's contribution to delay and packet loss is acceptable. Testing Data It's all about speed. Data services are the most tolerant of latency, jitter and loss. Most applications like email, web browsing and file transfer will allow packet loss, since it can be remedied through re-transmission. Also, since data services are not time-sensitive, latency and jitter will not noticeably affect the users. The most important measurement is throughput. How much data can a user send/receive? What types of downstream rates do they experience? Testing Quality of Service for Triple Play Bringing it all together. Currently, most subscribers receive only Internet traffic through their DSL connection. Quality of Service has not been a big issue since retransmission of data, as implemented by TCP, has been able to make up for lost or errored packets. Unfortunately, the same 'best-effort' service cannot be used for voice and video. As DSLAMs move into a triple-play world, it is vital to look at the different services that are delivered and the testing requirements for each. Testing a DSLAM's QoS capabilities requires loading the system to capacity both in terms of number of connected DSL modems and the amount of traffic flowing through the system. Ideally this traffic would resemble the real world scenarios of voice, video and data. Traffic for these services would be incremented up until the DSLAM's capacity was exceeded, then measurements would be taken to ensure that voice is prioritized over video, and video is prioritized over data. How can Spirent's new mAX SLAM DSLAM Test System Help? mAX SLAM is an ADSL/2/2+ interface module for the Spirent AX/4000 test system. Each interface connects directly to the DSLAM via twisted pair and emulates the CPE modem and the control and data plane traffic from service termination devices like IP phones, set-top boxes and computers. Designed to address all of the limitations in current DSLAM test beds, the mAX SLAM system has been designed to test Triple-Play DSLAMs. Each mAX SLAM chassis contains traffic generator/analyzer(s), and up to 168 ADSL2++ modem ports. These ports are configurable to all North American and European ADSL, ADSL2 and ADSL2+ operating modes. With multiple chassis, the mAX SLAM can scale to thousands of ports, providing a direct connection to the DSLAM enabling complete performance, functionality and QoS test capabilities which until now has been impossible. The mAX SLAM system (shown in figure 4) is able to emulate the control and data plane traffic of the Triple- Play network (shown in figure 3). Figure 4: Spirent Triple-Play DSLAM Test Solution Isolation of DSLAM PerformanceAccelerateAssure Spirent s Triple-Play DSLAM Testing White Paper 4 DSLAM Gig E Sales Information Call North America: (800) 927 2660 International: +33(0) 1 61 37 2250 Spirent DLS/AE Products Tel: (613) 592 2661 Fax: (613) 592 0522 ae.spirentcom.com © 2004 Spirent Communications Inc. All of the company names and/or brand names and/or product names referred to in this document, in particular the name S pirent  and it s logo device, AE and DLS are either registered trademarks or pending registration in accordance with relevant national laws. All rights reserved. Spirent AE/DLS Products 750 Palladium Drive Ottawa, ON K2V 1C7 Canada Tel: +1 (613) 592 2661 Fax: +1 (613) 592 0522 ae.spirentcom.com Email: ae@spirentcom.com Sales Information Call North America: (800) 927 2660 International: +33(0) 1 61 37 2250 Specifications on this product are subject to change and the Product Manual and release notes are the governing specifications. AccelerateAssure Spirent s Triple-Play DSLAM Testing White Paper 5 Each modem port on a mAX SLAM module contains a processor, which is responsible for time stamping, packet management and modem internal control. This processor ensures that measurements made are a very accurate representation of the DSLAM's performance. Unlike current test set-ups, which cannot distinguish between modem and DSLAM performance, the mAX SLAM eliminates the uncertainty caused by CPE modems, and allows precise and accurate measurement of latency, loss and jitter. Layer 3 Testing Supporting PPP, DHCP, IGMP, VLANs and the ability to add additional protocols via technology licenses, the mAX SLAM system is targeted towards testing the performance and functionality of layer 3 enabled Triple-Play DSLAMs. Port Grouping Testing Triple-Play DSLAMs requires real-world traffic scenarios. The mAX SLAM interface allows the tester to group ports together and assign multiple service types to each group. A simple example of this would be the creation of two groups; one of power users with voice, video and data and another with just data. The systems performance and QoS capability could then be tested by incrementing the traffic rate up in steps until the DSLAM's capacity is exceeded and it must begin prioritizing traffic by ensuring the voice and video get through while the data is dropped. While this is running, the system is providing detailed metrics such as packet loss, latency, latency variation, packet errors etc. Verification of ADSL Functionality Unlike conventional CPE modems the user has full control over the mAX SLAM modem interface. This allows the creation of advanced test scenarios like rolling brown outs where groups of ports flap (lose power). The system also reports DSL statistics, which can be used to verify the DSLAM's statistics. Each mAX SLAM port has a built-in attenuator that emulates the load from the copper loop and allows tests to be run with 0 dB, 40 dB or infinite attenuation. Space-saving Each 12-port module in the mAX SLAM system occupies about the same space as a single CPE. Thus a mAX SLAM system can replace thousands of CPE modems and rooms full of cabling and associated wiring. Maintaining a test system with real modems is complicated and time-consuming. With the streamlined mAX SLAM system, lab-space is optimized and set-up is simple. Scaleable The architecture of the mAX SLAM system has been designed to be flexible and scaleable. Users can easily upgrade their systems to add additional ports without spending valuable time reconfiguring the set-up. In addition, the mAX SLAM set-up has been designed to allow integration of new multi-port access modules as they become available (i.e. VDSL, VDSL2, A-PON). The GUI is also designed for scalability. A single PC can control thousands of modem ports. Modems can be grouped, and modem properties can be applied to the entire group easily and quickly. Programmability The mAX SLAM system is designed with ease of automation in mind. Programmers can configure service providers and subscribers in the GUI, and then export the configuration to a script. TCL libraries are provided with the equipment for easy integration into a scripting environment. Repeatability By providing a direct connection to the DSLAM and eliminating variability in results due to CPE modems, mAX SLAM test results are highly repeatable. This allows comparisons to be made from location-to-location as well as over time. Conclusion DSLAM systems are evolving from basic layer 2 aggregation devices to layer 3 enabled Triple-Play capable systems. It is no longer acceptable to just ensure that the link will come up and data will flow. It is now necessary to fully exercise the DSLAM under fully loaded conditions. Many complicated questions arise, such as: What happens when multiple users start changing channels at the same time? What happens to voice and video quality when loads approach and exceed the speed of the WAN connection? What happens when the power flickers? What happens when all of this happens at the same time (remember Murphy's law, E verything that can go wrong will )? Service providers are going to want to know the answers to these and many more questions prior to deploying Triple-Play DSLAMs. The move from a single basic Internet service to supporting voice, video and data requires a significant shift in testing paradigm. Spirent's mAX SLAM test system is designed to stress Triple-Play DSLAMs with real world traffic scenarios so that you'll know the answers before the system is deployed!