Steering a Course Through DSL Forum Test Documents

High bandwidth is key to rapid Internet data transfer. For Internet users, digital subscriber line (DSL) technologies provide the speed needed to make web browsing truly interactive instead of merely slow and frustrating. Asymmetrical DSL (ADSL) is a popular form of DSL that features greater download speed than upload, which is very applicable to the typical Internet surfers’ needs, and a key focus of continuing work by the DSL Forum.

With nearly 200 members, the DSL Forum represents a wide range of companies and research and educational organizations that are shaping the future of high-speed, copper-based communications. Over several years, working groups within the DSL Forum have developed a framework of specifications and recommendations that supports interoperability between equipment from different manufacturers. This interoperability is a necessary step toward greater adoption of DSL.

Accelerating the growth of the DSL market is the forum’s real goal, with an ultimate target of 200 million DSL connections globally by the end of 2005. To reach that goal, the DSL Forum has produced 59 technical reports defining interoperability measurements and recommendations for various requirements such as flow-through provisioning and extended reach solutions. The reports, all available on the forum’s website, can be grouped under five broad headings: architecture/configuration, data structures/addressing/protocols, management/operation, recommendation to comply with an existing standard, and testing.

It’s not surprising that the first 22 reports, dating from May 1996, relate to only the first three topics. The initial forum requirement after its founding in 1994 was to define the core DSL technology. Later reports address the delivery of maximum effectiveness in its deployment and use, including uniform testing.

These test-plan specifications have set the stage for accelerated testing and modem approval; reduced testing costs for equipment manufacturers, service providers, and consumers; and opened the door to testing outsourcing. Understanding how the tests are defined and completed is critical to obtaining the full value of these tests.

DSL Testing

The eight documents dealing with testing are divided into four categories: overview, implementation conformance statement (ICS), interop-erability, and conformance (Table 1, see below). The distinctions among them relate to their intended purposes. The first of the eight, TR-023 Overview of ADSL Testing, defines static and dynamic interoperability testing and conformance testing and their differences.

Table 1. DSL Forum Technical Reports Relating to Test

Document Test Type Date Page
TR-023 Overview of ADSL Testing Overview May 1999 9
TR-026 T1.413 Issue 2 ATM based ADSL ICS ICS September 1999 36
TR-029 ADSL Dynamic Interoperability Testing Interoperability February 2000 24
TR-031 ADSL ANSI T1.413-1998 Conformance Testing Conformance March 2000 161
TR-033 ITU-T G.992.2 (G.lite) ICS ICS March 2000 60
TR-045 PPP Static Interoperability Testing Interoperability March 2002 64
TR-048 ADSL Interoperability Test Plan Interoperability April 2002 58
TR-049 VoDSL Interoperability Test Plan Interoperability May 2002 55

Conformance testing verifies the capabilities and options implemented by UUTs in a system architecture configuration when compared to specifications defined by standards-development organizations. Interoperability testing is performed to confirm that two units of equipment can communicate with each other. For the units to communicate correctly, it is not necessary that either completely conform to the relevant standard.

In addition, interoperability testing comes in two flavors: static and dynamic. Static interoperability testing takes place in a stable, benign laboratory environment and verifies the system behavior of two connected systems. It can be limited to specific protocols within the overall protocol stack. For static testing, the DSL modems are connected to relatively short lines with little or no injected noise.

Dynamic interoperability testing verifies the capability of equipment to interoperate in an environment closely modeling a real-world network architecture. This is a performance test that evaluates communications between the units as the test conditions are changed.

A large number of parameters may serve as performance metrics depending on the test suite performed.

  • Upstream and downstream transmission rates for certain line lengths and noise profiles

  • Noise margin

  • ADSL status

  • Transmitted forward error correction (FEC) blocks

  • Corrected FEC blocks

  • Transmitted superframes

  • Uncorrectable superframes

  • Counters for loss of signal, frame, power

  • Errored seconds

  • Bits per carrier

  • Interleave delay

  • Measures of rate adaptation

An ADSL terminal unit to be used in a central office (ATU-C) and one intended for use at a remote site (ATU-R) would be suitable for interoperability testing if they implemented the same mandatory features and functions. However, the test’s success is not guaranteed because their capability to interoperate may depend on differently implemented optional features.

The ICS

A list of specific tests is not presented in TR-023; however, the types of tests that would be required are generically described. The ICS is introduced as a means of quantitatively describing the ADSL equipment to be tested.

TR-026 provides good examples of ICSs in Appendix B: Physical Layer ADSL ICS and Appendix C: Electrical ADSL ICS. It also contains a guide to its use with instructions for filling in the proforma ICSs and detailed examples of typical ICS sections.

Before any implementation of a specification can be evaluated, a completed ADSL electrical ICS is needed. This document is a comprehensive checklist of parameters that describe requirements such as plain old telephone service (POTS) splitter characteristics, line termination, and ADSL electrical characteristics.

The abbreviations used in the ICS status column are particularly important:
m—mandatory; the capability is required to be supported.
o—optional; the capability may be supported or not.
n/a—not applicable; in the given context, it is impossible to use the capability.
x—prohibited (excluded); there is a requirement not to use this capability in the given context.
o.i.—qualified optional; for mutually exclusive or selectable options from a set.
c.i.—conditional; the requirement on the capability (m, o, x, or n/a) depends on the support of other optional or conditional items.

For example, the first table in the electrical ICS relates to the value of the DC resistance of the ATU-C high pass filter. It is mandatory (m) that the value be reported. The value allowed is ³5 MW and referenced to section 12.1 of ANSI T1.413 Issue 2. To indicate that the manufacturer has supported the requirement, a Y for yes should be entered in the support column.

In this manner, all relevant parameters are recorded in the electrical ICS. The last section of TR-026 Appendix A: Conformance Statement asks, “Are all mandatory capabilities implemented?” If something has not been implemented, the product does not conform to the ANSI specification. On the other hand, all mandatory capabilities may be supported but without meeting the individual electrical- or physical-layer allowed limits.

Electrical conformance test selection is guided by the electrical ICS information. For example, some supported capabilities may be testable and some not. In addition to the ICS data, a test lab has other test support and management requirements. These may be satisfied by a simple series interface to the UUT that can access relevant performance monitoring registers and provide a control mechanism to put the UUT in the appropriate test condition.

Rather than dealing with electrical parameters, TR-026 Appendix B: Physical Layer ICS relates to features specific to operation of the ADSL equipment. For example, Table B.29: ATU-R FEC Coding Support requires that certain aspects of Reed-Solomon encoding be implemented such as RF parity bytes (fast), RI parity bytes (interleaved), SF DMT symbols (fast), and SI DMT symbols (interleaved). A range of values is allowed for the number of bytes, except SF must be one.

Test Suites and Cases

Completed ICSs serve as a starting point for two equipment vendors to determine the degree of interoperability of their respective implementations. From the ICSs, appropriate test cases can be selected to build a test suite.

TR-029 defines a number of test suites and test cases designed to determine loop reach, capacity on standard loops, capacity on loops with bridged taps, and bit error rate (BER), all under external noise and crosstalk conditions. A test suite comprises several tests designed to assess a specific performance attribute, such as the ANSI-TG1 test group number one used to determine the capacity of standard loops. Similar tests are defined for ITU G.992.1 (G.DMT) and G.992.2 (G.lite) standards.

ANSI-TG1 has tests that are described by the generic test case TC2 with a margin of 6 dB and latency set to fast or interleaved. The TC2 test case is defined as loop_xtalk_cap with the purpose of determining the capacity of a system on standard loops and crosstalk noises. Five different types of noise are listed as inputs to the test setup:

  • White noise @ -140 dBm/Hz + additive Gaussian white noise (AGWN)

  • 24 DSL + AGWN

  • 24 HDSL + AGWN

  • 5 T1 adjacent binder + AGWN

  • 1 T1 same binder + AGWN

In addition, the test setup and procedure are specified. For each loop/noise model as defined in the appropriate standard:

  1. Set line simulator to the first standard loop.

  2. Inject the corresponding standard noise.

  3. Initialize modems using the specified latency path and margin.

  4. Note the negotiated framing mode and trellis option.

  5. Note the downstream and upstream net data rate.

  6. Repeat steps 1 through 5 for other standard loops and noise types.

Because the results of performance tests from different labs across the world may be difficult to compare, TR-029 Annex C: Reference Test Setup for ATM-Based ADSL Systems provides a suggested test setup. The required types of instruments are listed, and a typical ADSL test setup is shown schematically (Figure 1).

A great deal of technical background information is included in the eight test documents. For example, TR-029 ANNEX A: Bit Error Ratio Testing of ATM-Based ADSL Systems describes the three common types of BER measurements along with defining equations. Similarly, TR-029 ANNEX B: A Method to Perform ATM-Based Bit Error Ratio Tests Without External BER Tools discusses the use of idle cells to carry BER test signals.

TR-031 is a comprehensive conformance test specification. In contrast to TR-029, which deals with the combined performance of an ATU-C and an ATU-R, this conformance-testing document lists more than 100 specific tests that must be performed on individual ATU-C/R equipment—43 ADSL plus nine electrical for ATU-R and 45 ADSL plus nine electrical for ATU-C. In addition, eight tests deal with ATM cell-specific functionalities.

TR-033 is a proforma ICS specifically relating to G.lite systems. It has the same form as the ICSs presented in TR-026. In this case, only the physical-layer ICS is included, ANNEX A: Physical Layer ADSL ICS, with information from International Telecommunication Union, Telecommunications Standards Section (ITU-T) Recommendation G.994.1.

Higher Level Tests

As stated in the introduction to TR-045, “The DSL Forum has made much progress toward full interoperability at the physical layer. TR-023 extended that work toward higher protocol-layers testing and defined three areas of testability: conformance, static interoperability, and dynamic interoperability. This document [TR-045] addresses point-to-point protocol (PPP) static interoperability testing….”

PPP is important because of its security provisioning, muliprotocol support, IP dynamic address assignment, and capability to support both asynchronous and synchronous connections. Schematic diagrams of PPP protocol stacks are included in the document as well as details of three test groups.

Group_1_Test_1/llc_snap_encapsulation is an example of the different kind of test being proposed. This test is designed to verify the encapsulation of packets over the link using a logical link control/scaleable node address protocol (LLC/SNAP) header. Multiprotocol data units are transmitted over asynchronous transfer mode (ATM) links using LLC/SNAP encapsulation or virtual circuit (VC) multiplexing. LLC/SNAP encapsulation has a protocol identifier field to indicate the type of protocol data units transmitted.

Moving on to central-office equipment interoperability, TR-048 ADSL Interoperability Test Plan and TR-049 VoDSL Interoperability Test Plan deal with compatibility between remote equipment and digital subscriber line access multiplexers (DSLAMs) and voice gateways, respectively. The documents follow the organization of TR-029 and TR-045. Many physical and higher level test cases together with appropriate test setups are presented.

TR-048 is referenced by the ITU Recommendation G.992.3, the ADSL2 standard, as the mandatory conformance criteria for North America, demonstrating the industry’s recognition of the DSL Forum’s interoperability work. A set of interoperability tests is specified that encompass many more aspects than prior ADSL testing specifications, and a required level of rate vs. reach performance is established well beyond the prior ADSL performance requirements. Vendors and network providers throughout the world have adopted TR-048 as an essential requirement.

An updated ADSL testing specification being prepared by the forum will specify performance levels above the TR-048 requirements and include some new types of tests because the ADSL technology has improved greatly. The DSL Forum is working with independent testing laboratories (ITLs) to help provide an efficient means for vendors to verify the interoperability and performance of their products.

“Our role is to broaden DSL interoperability and reach, to ensure effective broadband support of emerging applications and content. The technical requirements are fundamental elements in achieving the next major steps in delivering DSL benefits to mass markets around the world, and the technical reports are vital for expediting these DSL advancements,” commented Tom Starr, president of the DSL Forum. “The strength of the forum is our ability to bring together experts from the service provider and vendor community to develop comprehensive interoperability plans to further DSL’s success.”

Presently, the DSL Forum is developing symmetric high-bit-rate DSL (SHDSL) and very-high-data-rate DSL (VDSL) interoperability testing specifications that will be analogous to TR-048. Work will start soon to develop an interoperability testing specification for ADSL2plus (ITU Recommendation G.992.5). ADSL2plus is the newest enhancement to ADSL that operates at downstream bit rates up to 18 Mb/s on shorter lines.

FOR MORE INFORMATION

on DSL Forum activities and technical reports
www.rsleads.com/311ee-178

Return to EE Home Page

Published by EE-Evaluation Engineering
All contents © 2003 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.

November 2003

Sponsored Recommendations

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!