CC: Ed Eckert, Technical Subcommittee T1E1 Chairman attachment: DSL-Forum WT-051v4 (ADSL Dynamic Interoperability Testing)

Transcription

1 DSL Forum Liaison to: Jack Douglass, Chairman TIA TR30.3 From: Gavin Young, DSL Forum Technical Committee Chair Date: March 16, 2001 Subject: DSL Forum Liaison regarding DSL testing and interoperability Dear Mr. Douglass, Thank you for your liaisons since our meeting in December We are very pleased to learn of and help progress draft EIA/TIA 876 (formerly PN4254). The session we invited you to on March 14 th was very well attended and productive. Your presentation was well received, and the discussions with other members of TIA TR30.3 were most helpful. The TR30.3 liaisons were reviewed and discussed among the members of the Testing & Interoperability Working Group during its teleconferences and our meeting this week. The DSL Forum would appreciate receiving copies of draft EIA/TIA 876 and any other updates from your meeting in April. The ability to compare dynamic interoperability (performance) of many xdsl modems, for loops on a worldwide scope, is of interest and we would like to discuss the details of your approach further (during our proposed joint session in June). We are interested in applying the NMC methodology specified in draft EIA/TIA 876 in future DSL Forum technical reports and testplans. What experiences have you had in the application of the methods of draft EIA/TIA 876 in comparison of modems? The DSL Forum Testing & Interoperability Working Group would like to hold a joint session with TR30.3 regarding the DSL Forum WT-051 (ADSL Dynamic Interoperability Testing) and network models for xdsl testing. We propose this session from 3:30 PM to 5:00 PM on Wednesday, June 20 th. Members of TR30.3 are invited to participate in this DSL Forum joint session. Please find attached the most recent draft of WT-051. We look forward to continued cooperation between our groups. The next DSL Forum meeting will take place in Oslo, Norway, from June 19 to 22, We invite members of TIA TR30.3 to attend. Thank you for your consideration of these matters. Sincerely, Gavin Young DSL Forum Technical Chair CC: Ed Eckert, Technical Subcommittee T1E1 Chairman ejeckert@nortelnetworks.com attachment: DSL-Forum WT-051v4 (ADSL Dynamic Interoperability Testing)

2 PROJECT: DSL Forum Testing & Interoperability Working Group SOURCE: DSL Forum Testing & Interoperability Working Group TITLE: Working Text 051v4 - ADSL Dynamic Interoperability Testing DATE: March 14, 2001 DISTRIBUTION: DSL Forum Testing & Interoperability Working Group members. EDITOR: Douglas Hay Admit Systems Ltd. 2 St David s Dr. St. David s Business Park Dalgety Bay Fife. KY11 9PF Scotland, UK. Tel Fax douglas@admit.com NOTICE: This Working Text represents work in progress by the DSL Forum, and must not be construed as an official DSL Forum Technical Report. Nothing in this document is binding on the DSL Forum or any of its members. The document is offered as a basis for discussion and communication, both within and outside the DSL Forum. WT-051v4-3/14/01-1 -

3 DSL Forum Working Text WT-051 Version 4 ADSL Dynamic Interoperability Testing March Digital Subscriber Line Forum. All Rights Reserved. DSL Forum working texts may be copied, downloaded, stored on a server or otherwise re-distributed in their entirety only. Notwithstanding anything to the contrary, the DSL Forum makes no representation or warranty, expressed or implied, concerning this publication, its contents or the completeness, accuracy, or applicability of any information contained in this publication. No liability of any kind shall be assumed by the DSL Forum as a result of reliance upon any information contained in this publication. The DSL Forum does not assume any responsibility to update or correct any information in this publication. The receipt or any use of this document or its contents does not in any way create by implication or otherwise any express or implied license or right to or under any patent, copyright, trademark or trade secret rights which are or may be associated with the ideas, techniques, concepts or expressions contained herein. WT-051v4-3/14/01-2 -

4 Table of contents 1. REVISION HISTORY 4 2. INTRODUCTION 5 3. STANDARDS REFERENCED FOR DYNAMIC INTEROPERABILITY TESTING T1.413 systems ITU-T systems G [GDMT] G [GLITE] 6 4. TEST SETUP 6 5. TEST SUITES Parameters Sample Test Suite description format Test Suite for T Test Suite for ITU G Test suite for ITU G Annex C Test suite for ITU G Annex H Test Suite for ITU G Test suite for ITU G Annex C 9 6. TEST CASES Sample Test Case description format Loop reach with external crosstalk and noise Loop reach with external crosstalk and noise for ITU G Annex C & H Capacity on Standard Loops with external crosstalk and noise Capacity on standard loops with external crosstalk and noise for ITU G Annex C & H BER with external crosstalk and noise BER with external crosstalk and noise for ITU G Annex C & H Capacity on loop with bridged taps under external crosstalk and noise conditions Margin with external crosstalk and noise Margin with external crosstalk and noise for G Annex C & H Transmit Power Spectral Density REFERENCES 21 ANNEX A : BIT ERROR RATIO TESTING OF ATM BASED ADSL SYSTEMS 22 A.1 General description of BER testing 22 A.2 Description 22 A.3 Test Requirements 23 A.3.1 External BER test requirements 23 WT-051v4-3/14/01-3 -

5 ANNEX B : A METHOD TO PERFORM ATM BASED BIT ERROR RATIO TESTS WITHOUT EXTERNAL BER TOOLS. 25 B.1 Requirements of an internal BER tool 25 B.1.1 Traffic Generator 25 B.1.2 Traffic Analyzer 26 B.2 Measurement results 27 ANNEX C : REFERENCE TEST SETUP FOR ATM BASED ADSL SYSTEMS 29 C.1 Introduction 29 C.2 Description C.2.1 Cabling C.2.2 Cable simulator 32 C.2.3 Noise generators 34 C.2.4 BER test equipment 34 C.3 Conclusion 35 ANNEX D : SYSTEM PERFORMANCE FOR G ANNEX C & ANNEX H & G ANNEX C 36 D.1 System Performance and test conditions in an environment co-existing with TCM-ISDN DSL 36 D.2 Synchronized TTR and crosstalk injection timing requirements LIST OF TABLES AND FIGURES Revision History Date (M/D/Y) Version Major Changes. 5/17/00 1 Added as changes or as notes the living list items from Section 5, from contributions & and from TIA liaison to a change reset version of (has editorial figure and table caption/cross-reference differences with TR-029). 8/30/00, 9/8/00 2 Update all Living List Issues from ; editing 12/6/00 3 Added G Annex C & H / G Annex C requirement. Place holder added for PSD measurement (in Section 6.7). 3/14/01 4 Editorial notes added; further editing, including adding cover page more like TR. WT-051v4-3/14/01-4 -

6 2. Introduction This document describes ADSL Dynamic Interoperability Test Suites and Test Cases for the standards [ANSI], [GDMT] and [GLITE]. The Test Suites for the ITU-T standards [GDMT] and [GLITE] draw heavily on [GTEST]. Relationships among the tests for Dynamic Interoperability, Static Interoperability and Conformance are described in [TR-023]. An ATU-C and an ATU-R are dynamically interoperable if they implement a common and compatible set of features, functions and options and can demonstrate satisfactory mutual communication in a real network architecture environment as performance test conditions are varied and exercised. The term "compatible" is used to mean that there are no conflicting requirements that will prevent the ADSL system from achieving interoperability. Dynamic Interoperability testing is also described as performance testing in some ADSL and other telecommunication standards [TR-023]. Systems can be tested for Dynamic Interoperability both on standard loops and on a set of additional loops. The procedures for each Test Case record those features used from the referenced standards. Section 6 differentiates between those test groups required for Dynamic Interoperability testing and those using non-standard loops or conditions. Results from test groups using non-standard loops or conditions are optional but can be used to increase the completeness of Dynamic Interoperability characterization. Annex A provides information on how to do Bit Error Ratio (BER) testing in an ATM based ADSL environment. Annex B provides information on a method to perform ATM based BER testing without external BER tools. Annex C provides a reference test setup for ATM based ADSL systems. Annex D provides system performance and test conditions for G Annex C and Annex H and G Annex C, including synchronized TTR and crosstalk injection timing requirements. 3. Standards referenced for Dynamic Interoperability testing 3.1 T1.413 systems Systems claiming compliance to [ANSI] should be tested for performance using the loops and noise environment as specified in Section 11 of [ANSI]. Section 11 of [ANSI] also describes the testing method and gives the required performance data. 3.2 ITU-T systems G [GDMT] Region A (Other than Europe) Systems claiming compliance to [GDMT] Region A should be tested for performance using the loops and noise environment as specified in Annex F of [GDMT]. The required performance data is also given in Annex F of [GDMT] while the testing method is described in [GTEST] Region B (Europe) Systems claiming compliance to [GDMT] Region B should be tested for performance using the loops and noise environment as specified in Annex G of [GDMT]. The required performance data is also given in Annex G of [GDMT] while the testing method is described in [GTEST]. WT-051v4-3/14/01-5 -

7 Annex C and Annex H System claiming compliance to [GDMT] Annex C or Annex H should be tested for performance using the loops and noise environment as described in [GTEST] and specified in Annex D of this document in detail. The required performance data is given in Annex D of this document while the testing method is described in [GTEST] G [GLITE] North America Systems claiming compliance to [GLITE] North America should be tested for performance using the loops and noise environment as specified in Annex D of [GLITE]. The required performance data is also given in Annex D of [GLITE] while the testing method is described in [GTEST] Europe Systems claiming compliance to [GLITE] Europe should be tested for performance using the loops and noise environment as specified in Annex E of [GLITE]. The required performance data is also given in Annex E of [GLITE] while the testing method is described in [GTEST] Annex C System claiming compliance to [GLITE] Annex C should be tested for performance using the loops and noise environment as described in [GTEST] and specified in Annex D of this document in detail. The required performance data is also given in Annex D of this document while the testing method is described in [GTEST]. 4. Test Setup The test setup shall be as in Figure C - 1: Typical ADSL test setup. The minimum test periods to give statistical significance for Bit Error Ratio tests are defined in Table 1 (below). For testing [GDMT Annex C], [GDMT Annex H] and [GLITE Annex C], it is required to synchronize with TTR (TCM-ISDN Timing Reference) as described in [GTEST] and specified in Annex D of this document in detail, where TTR is provided by DCS (Digital Clock Supply). Editorial Note: Following the contribution from the TIA of PN4254, are the following minimum period times excessive? 5. Test Suites 5.1 Parameters Table 1: Minimum Test Period for each BER test Bit Rate Minimum Test Period > 6 Mbps 100 Seconds >1.544 Mbps and < 6Mbps 500 Seconds <1.544 Mbps 20 Minutes Parameters are a means to provide variable input conditions to Test Cases. Currently defined parameters are: MRG: margin (db) LAT: latency (Fast or Interleaved) XBM: Bitmap (Dual or FEXT) for Annex C WT-051v4-3/14/01-6 -

8 XFT: Frequency band Transmission (AFT or optional EFT) for Annex H 5.2 Sample Test Suite description format Test Group Number Test Group Description Test Cases Test Parameters 5.3 Test Suite for T The following two Test Groups shall be executed using the loops and noises referenced in Section 3.1. The results of these Test Groups shall be provided as the minimum required to demonstrate Dynamic Interoperability. Note: The data for the Test Case using category 1 T1 noise on the Mid-CSA loop shall be taken at 3 db margin. Test Group Number Test Group Description Test Cases Test Parameters Test Group Number Test Group Description: Test Cases Test Parameters ANSI-TG1 Capacity vs. standard loop TC2 MRG = 6, LAT = fast or interleaved ANSI-TG2 Stability & BER TC3 MRG = 6, LAT = fast or interleaved The following Test Group provides additional performance information, using loops and noises appropriate to the two Test Cases as referenced in section 6.2 (TC1) and section 6.5 (TC4). The results of these test groups may be provided to increase the completeness of the demonstrated Dynamic Interoperability. Test Group Number Test Group Description Test Cases Test Parameters ANSI-TG3 Capacity vs. non-standard loops TC1, TC4 MRG = 6, LAT = fast or interleaved 5.4 Test Suite for ITU G The following two Test Groups shall be executed using loops and noises as referenced in section or The results of these Test Groups shall be provided as the minimum required to demonstrate Dynamic Interoperability. Note: The data for the Test Case using category 1 T1 noise on the Mid-CSA loop shall be taken at 3 db margin. Test Group Number Test Group Description Test Cases Test Parameters Test Group Number Test Group Description Test Cases Test Parameters G TG1 Capacity vs. standard loops TC2 MRG = 6, LAT = fast or interleaved G TG2 Stability & BER TC3 MRG = 6, LAT = fast or interleaved WT-051v4-3/14/01-7 -

9 The following Test Group provides additional performance information, using loops and noises appropriate to the two Test Cases as referenced in section 6.2 (TC1) and section 6.5 (TC4). The results of these Test Groups may be provided to increase the completeness of the demonstrated Dynamic Interoperability. Test Group Number Test Group Description Test Cases Test Parameters G TG3 Capacity vs. non-standard loops TC1, TC4 MRG = 6, LAT = fast or interleaved Test suite for ITU G Annex C The following two TEST Groups shall be executed using the loops and noises referenced in Section The results of theses Test Groups shall be provided as the minimum requirement to demonstrate Dynamic Interoperability. Test Group Number Test Group Description Test Cases Test Parameters Test Group Number Test Group Description Test Cases Test Parameters G.992.1(AnnexC)-TG1 Capacity vs. standard loops TC2c MRG= 4 (for upstream) & 6 (for downstream), LAT= fast or interleaved, XBM= Dual or FEXT. G.992.1(AnnexC)-TG2 Stability & BER TC3c (or TC5c when TC3c failed) MRG= 4 (for upstream) & 6 (for downstream), LAT= fast or interleaved, XBM= Dual or FEXT. The following Test Group provides additional performance information, using loops and noises appropriate to the two TEST Cases as reference in section 6.2c (TC1c) and section 6.5c (TC4c). The results of these Test Groups may be provided to increase the completeness of the demonstrated Dynamic Interoperability. Test Group Number Test Group Description Test Cases Test Parameters G.992.1(AnnexC)-TG3 Capacity vs. non-standard loops TC1c and/or TC4c MRG= 4 (for upstream) & 6 (for downstream), LAT= fast or interleaved, XBM= Dual or FEXT Test suite for ITU G Annex H The following two Test Groups shall be executed using the loops and noises referenced in Section The results of theses Test Groups shall be provided as the minimum requirement to demonstrate Dynamic Interoperability. Test Group Number Test Group Description Test Cases Test Parameters G.992.1(AnnexH)-TG1 Capacity vs. standard loops TC2c MRG= 6 (for downstream and upstream), LAT= fast or interleaved, XFT= AFT or optional EFT. WT-051v4-3/14/01-8 -

10 Test Group Number Test Group Description Test Cases Test Parameters G.992.1(AnnexH)-TG2 Stability & BER TC3c (or TC5c when TC3c failed) MRG= 6 (for downstream and upstream), LAT= fast or interleaved, XFT= AFT or optional EFT. The following Test Group provides additional performance information, using loops and noises appropriate to the two TEST Cases as reference in section 6.2c (TC1c) and section 6.5c (TC4c). The results of these Test Groups may be provided to increase the completeness of the demonstrated Dynamic Interoperability. Test Group Number Test Group Description Test Cases Test Parameters G.992.1(AnnexH)-TG3 Capacity vs. non-standard loops TC1c and/or TC4c MRG= 6 (for downstream and upstream), LAT= fast or interleaved, XFT= AFT or optional EFT. 5.5 Test Suite for ITU G The following two Test Groups shall be executed using loops and noises as referenced in section or The results of these Test Groups shall be provided as the minimum required to demonstrate Dynamic Interoperability. Test Group Number Test Group Description Test Cases Test Parameters Test Group Number Test Group Description Test Cases Test Parameters G TG1 Capacity vs. standard loops TC2 MRG = 4, LAT = interleaved G TG2 Stability & BER TC3 MRG = 4, LAT = interleaved The following Test Group provides additional performance information, using loops and noises appropriate to the two Test Cases as referenced in section 6.2 (TC1) and section 6.5 (TC4). The results of these Test Groups may be provided to increase the completeness of the demonstrated Dynamic Interoperability. Test Group Number Test Group Description Test Cases Test Parameters G TG3 Capacity vs. non-standard loops TC1, TC4 MRG = 4, LAT = interleaved Test suite for ITU G Annex C The following two TEST Groups shall be executed using the loops and noises referenced in Section The results of theses Test Groups shall be provided as the minimum requirement to demonstrate Dynamic Interoperability. WT-051v4-3/14/01-9 -

11 Test Group Number Test Group Description Test Cases Test Parameters Test Group Number Test Group Description Test Cases Test Parameters G.992.2(AnnexC)-TG1 Capacity vs. standard loops TC2c MRG= 4 (for downstream and upstream), LAT= interleaved, XBM= Dual or FEXT. G.992.2(AnnexC)-TG2 Stability & BER TC3c (or TC5c when TC3c failed) MRG= 4 (for downstream and upstream), LAT= interleaved, XBM= Dual or FEXT. The following Test Group provides additional performance information, using loops and noises appropriate to the two TEST Cases as reference in section 6.2c (TC1c) and section 6.5c (TC4c). The results of these Test Groups may be provided to increase the completeness of the demonstrated Dynamic Interoperability. Test Group Number Test Group Description Test Cases Test Parameters G.992.2(AnnexC)-TG3 Capacity vs. non-standard loops TC1c and/or TC4c MRG= 4 (for downstream and upstream), LAT= interleaved, XBM= Dual or FEXT. 6. Test Cases Contribution introduces some problems with the BER testing in the following test cases. [5/18/00 update: Notes incorporated which should clarify the questions] 6.1 Sample Test Case description format Test Case Number Test Case Name Test Purpose Input Parameters Test Procedure and Setup Success Criteria Results WT-051v4-3/14/

12 6.2 Loop reach with external crosstalk and noise Test Case Number TC1 Test Case Description: loop_xtalk_reach Test Purpose Determine capacity vs. reach of a system on a variable length 26 AWG loop. Input Parameters MRG, LAT Test Procedure and Setup For each noise model defined in Table 2: 1. Set line simulator to 0 kft 2. Inject noise 3. Initialize modems using LAT latency path with MRG db margin 4. Note negotiated framing mode and Trellis coding option 5. Note Downstream and Upstream Net Data Rate 6. Disconnect 7. Increase line simulator length by 1 kft 8. Repeat steps When maximum reach has been obtained, repeat steps 1-8 with another noise type. Success Criteria Results Showtime reached with good data transport (i.e., no CRC superframe errors, no LOS or LOF failures). Note: To guarantee proper operation at the envisaged quality, BER (shall be < 10 E-7) shall be observed over the time period given in Table 1. During the interim process of finding the limit the monitored time period can be reduced, but shall not be less than 10 % of the periods given in Table 1. At the systems limit (highest achieved capacity) it shall be proven over the period given in Table 1 that the performance requirement is met. Note: Evaluation of the proper operation (BER) should be started after reaching showtime. It is recommended to wait for at least 500 ms after reaching showtime. This would allow approx. 30 superframes to be exchanged before the evaluation starts. Table/graph of capacity vs. distance and noise type for the same framing mode and Trellis option. Editorial Note: T1 same binder noise type, does it exist and if so where is it defined? Table 2: Noise types used for Test Cases TC1 & TC2 Noise types for TC1 and TC2 White -140 dbm/hz (agwn) 24 DSL + agwn 24 HDSL + agwn 5 T1 adjacent binder + agwn 1 T1 same binder + agwn WT-051v4-3/14/

13 6.2.1 Loop reach with external crosstalk and noise for ITU G Annex C & H Test Case Number Test Case Description Test Purpose Input Parameters Test Procedure and Setup Success Criteria TC1c loop_xtalk_reach Determine capacity vs. reach of a system on a variable length loop. XBM (for Annex C), XFT (for Annex H), MRG, LAT. For each noise type defined in Table 4 and for the loop type defined in Table 5: 1. Set line simulator to 0 km, 2. Inject noise, 3. Initialize modems using LAT latency path with MRG db margin, and selected XBM bitmap mode, and selected XFT transmission mode, 4. Note negotiated framing mode and Trellis coding option, 5. Note Downstream and Upstream Net Data Rate, 6. Disconnect, 7. Increase line simulator length by 250 m, 8. Repeat steps 1-7, 9. When maximum reach has been obtained, repeat steps 1-8 with another noise type. Showtime reached with good data transport (i.e., no CRC superframe errors, no LOS or LOF failures). Note: To guarantee proper operation at the envisaged quality, BER (shall be < 1e-7) shall be observed over the time period given in Table 1. During the interim process of finding the limit, the monitored time period can be reduced, but shall not be less than 10 % of the period given in Table 1. At the systems limit (highest achieved capacity) it shall be proven over the period given in Table 1 that the performance requirement is met. Results Note: Evaluation of the proper operation (BER) should be started after reaching showtime. It is recommended to wait for at least 500 ms after reaching showtime. This would allow approx. 30 superframes to be exchanged before the evaluation starts. Table/graph of Net Data Rate vs. distance and noise type described in Annex D of this document for the same framing mode and Trellis option. WT-051v4-3/14/

14 6.3 Capacity on Standard Loops with external crosstalk and noise Test Case Number Test Case Name Test Purpose Input Parameters Test Procedure and Setup Success Criteria Results TC2 loop_xtalk_cap Determine capacity of a system on standard loops and crosstalk noises. MRG, LAT For each loop/noise model as defined in the appropriate standard: 1. Set line simulator to first standard loop 2. Inject the corresponding standard noise 3. Initialize modems using LAT latency path with MRG db margin 4. Note negotiated framing mode and Trellis option 5. Note Downstream and Upstream Net Data Rate 6. Repeat steps 1-5 for other standard loop and noise. Showtime reached with good data transport (i.e., no CRC superframe errors, no LOS or LOF failures). Note: To guarantee proper operation at the envisaged quality, BER (< 10 E-7) shall be observed over the time period given in Table 1. Note: Evaluation of the proper operation (BER) should be started after reaching showtime. It is recommended to wait for at least 500 ms after reaching showtime. This would allow approx. 30 superframes to be exchanged before the evaluation starts. Table of Net Data Rate vs. standard loop and noise type for same framing mode and Trellis option. WT-051v4-3/14/

15 6.3.1 Capacity on standard loops with external crosstalk and noise for ITU G Annex C & H Test Case Number Test Case Description Test Purpose Input Parameters Test Procedure and Setup Success Criteria TC2c loop_xtalk_capacity Determine capacity vs. reach of a system on standard loops and crosstalk noises. XBM (for Annex C), XFT (for Annex H), MRG, LAT. For each loop/noise type defined in Table 4 and Table 5: 1. Set line simulator to the first standard loop, 2. Inject noise, 3. Initialize modems using LAT latency path with MRG db margin, and selected XBM bitmap mode, and selected XFT transmission mode, 4. Note negotiated framing mode and Trellis coding option, 5. Note Downstream and Upstream Net Data Rate, 6. Repeat steps 1-5 for other defined loops and noises. Showtime reached with good data transport (i.e., no CRC superframe errors, no LOS or LOF failures). Note: To guarantee proper operation at the envisaged quality, BER (shall be < 1e-7) shall be observed over the time period given in Table 1. During the interim process of finding the limit, the monitored time period can be reduced, but shall not be less than 10 % of the period given in Table 1. At the systems limit (highest achieved capacity) it shall be proven over the period given in Table 1 that the performance requirement is met. Results Note: Evaluation of the proper operation (BER) should be started after reaching showtime. It is recommended to wait for at least 500 ms after reaching showtime. This would allow approx. 30 superframes to be exchanged before the evaluation starts. Table/graph of Net Data Rate vs. loop/noise type described in Annex D of this document for the same framing mode and Trellis option. WT-051v4-3/14/

16 6.4 BER with external crosstalk and noise Test Case Number TC3 Test Name: Loop_xtalk_ber Test Purpose Determine BER of a system under different loops and crosstalk noises Input Parameters MRG, LAT Test Procedure and Setup For each loop/noise model as defined in the appropriate standard: 1. Initialize modems using LAT latency path with MRG db Margin 2. Increase the noise by MRG db 3. Measure BER 4. Disconnect. Success Criteria BER 1e-7 and CLR 4e-6 for a sufficiently long period ( For testing [GDMT Annex C], [GDMT Annex H] and [GLITE Annex C], it is required to synchronize with TTR (TCM-ISDN Timing Reference) as described in [GTEST] and specified in Annex D of this document in detail, where TTR is provided by DCS (Digital Clock Supply). Results Editorial Note: Following the contribution from the TIA of PN4254, are the following minimum period times excessive? Table 1). Note: Please refer to Annex A for further information on BER and CLR. Pass/Fail BER with external crosstalk and noise for ITU G Annex C & H Test Case Number TC3c Test Case Description loop_xtalk_ber Test Purpose Determine BER of a system under different loops and crosstalk noises Input Parameters XBM (for Annex C), XFT (for Annex H), MRG, LAT. Test Procedure and For each loop/noise type defined in Table 4 and Table 5: Setup 1. Initialize modems using LAT latency path with MRG db margin, and selected XBM bitmap mode, and selected XFT transmission mode, 2. Increase the noise by MRG db, 3. Measure BER, 4. Disconnect. Success Criteria BER <= 1e-7 and CLR <= 4e-6 for a sufficiently long period (Table 1). Results Note: Refer to Annex A for further information on BER and CLR. Pass/Fail 6.5 Capacity on loop with bridged taps under external crosstalk and noise conditions Living List Issue: 5.1. Remove following paragraph or provide a reference for the Telcordia study [sect. 6.5, para 1] (13/C5) [3/8/00 update: Fred to ask Telcordia (Sandra L.?) if reference paragraph is available.] [5/17/00 update: paragraph put into a note, reference to specific investigation of Telecordia removed] Note: Various Investigations of subscriber loop characteristics have shown that "Bridged Taps" occur in some WT-051v4-3/14/

17 specific networks quite frequently. It has been shown that Bridged Taps of lengths between 250 and 500 feet (approx m) do have a significant effect on the performance of ADSL systems. The set of test loops that should be used to demonstrate Dynamic Interoperability in the presence of short bridged taps is given in Table 3. The addition of a 750 foot 26 AWG bridged tap to a 26 AWG test loop may be used to measure the performance degradation in the upstream direction. The 9 kft, 12 kft, 15 kft straight 26 AWG gauge loops without bridged taps that may be used as reference are covered by TC1. To reduce the number of test cases, these loops shall be tested with the -140 dbm/hz white noise model. Test Case Number TC4 Test Case Name loop_tap_xtalk_cap Test Purpose Determine capacity of a system on loops containing short bridged taps Input Parameters MRG, LAT Test Procedure and Setup For each bridged tap loop configuration defined in Table 3: 1. Set bridged tap length to the first tap length in Table 3, column 2 2. Inject 140 dbm/hz white noise 3. Initialize modem using LAT latency path with MRG db margin 4. Note negotiated framing mode and Trellis coding option 5. Note Downstream and Upstream Net Data Rate 6. Disconnect 7. Set line simulator to next bridged tap length 8. Repeat steps 2-6 for all tap lengths in Table 3, column 2 Repeat steps 2-7 for next loop length in Table 3, column 1. Success Criteria Showtime reached with good data transport (i.e., no CRC superframe errors, no LOS or LOF failures). Note: To guarantee proper operation at the envisaged quality, BER (shall be < 10 E-7) shall be observed over the time period given in Table 1. During the interim process of finding the limit the monitored time period can be reduced, but shall not be less than 10 % of the periods given in Table 1. At the systems limit (highest achieved capacity) it shall be proven over the period given in Table 1 that the performance requirement is met. Results Note: Evaluation of the proper operation (BER) should be started after reaching showtime. It is recommended to wait for at least 500 ms after reaching showtime. This would allow approx. 30 superframes to be exchanged before the evaluation starts. Table of Net Data Rate vs. loop and tap length and noise type for same framing mode and Trellis option. * Capacity on loop with bridged taps under external noise for ITU G Annex C & H WT-051v4-3/14/

18 Test Case Number Test Case Description Test Purpose Input Parameters Test Procedure and Setup Success Criteria TC4c loop_tap_xtalk_capacity Determine capacity of a system on loops containing short bridged taps. XBM (for Annex C), XFT (for Annex H), MRG, LAT. For each bridged tap loop configuration defined in Table 4 and Table 5: 1. Set bridged tap length to the first length in Table 5, 2. Inject noise defined in Table 4, 3. Initialize modems using LAT latency path with MRG db margin, and selected XBM bitmap mode, and selected XFT transmission mode, 4. Note negotiated framing mode and Trellis coding option, 5. Note Downstream and Upstream Net Data Rate, 6. Disconnect, 7. Set line simulator to next bridged tap length, 8. Repeat steps 2-6 for all tap length in Table 5, Showtime reached with good data transport (i.e., no CRC superframe errors, no LOS or LOF failures). Note: To guarantee proper operation at the envisaged quality, BER (shall be < 1e-7) shall be observed over the time period given in Table 1. During the interim process of finding the limit, the monitored time period can be reduced, but shall not be less than 10 % of the period given in Table 1. At the systems limit (highest achieved capacity) it shall be proven over the period given in Table 1 that the performance requirement is met. Results Note: Evaluation of the proper operation (BER) should be started after reaching showtime. It is recommended to wait for at least 500 ms after reaching showtime. This would allow approx. 30 superframes to be exchanged before the evaluation starts. Table of Net Data Rate vs. loop and tap length and noise type described in Annex D of this document for the same framing mode and Trellis option. (8/30/00 update: Living List Issue 5.13 completed) WT-051v4-3/14/

19 Test Case Number Test Case Name Test Purpose Input Parameters Test Procedure and Setup TC5 Loop_xtalk_margin Determine margin of a system under different loops and crosstalk noises LAT For each loop/noise model as defined in the appropriate standard: 1. Initialize modems using LAT latency path at a chosen bit rate consistentwith the appropriate standard and at the appropriate reference noise level. 2. Verify BER 1e-7 3. Adjust the noise by 1 db 4. Repeat steps 2 and 3 until the maximum noise level has been reached where BER 1e-7 and CLR 4e-6 for a sufficiently long period (Table 1) 5. Disconnect. Success Criteria BER 1e-7 and CLR 4e-6 for a sufficiently long period (Table 1). Note: Please refer to Annex A for further information on BER and CLR. Results Note: To guarantee proper operation at the envisaged quality, BER shall be observed over the time period given in Table 1. During the interim process of finding the limit the monitored time period can be reduced, but shall not be less than 10 % of the periods given in Table 10. At the systems limit (highest achieved capacity) it shall be proven over the period given in Table 1 that the performance requirement is met Table of maximum noise level vs. loop/noise model for the same framing mode, Trellis option and bit rate. Table 3: Bridged Tap Test Loops 26AWG loop length 26AWG tap ATU-R [ft] 9 kft 250, 300, 350, kft 350, 400, 450, kft 350, 400, 450, 750 * Margin with external crosstalk and noise for G Annex C & H WT-051v4-3/14/

20 Test Case Number TC5c Test Case Description loop_xtalk_margin Test Purpose Determine margin of a system under different loops and crosstalk noises Input Parameters XBM (for Annex C), XFT (for Annex H), LAT Test Procedure and For each loop/noise type defined in Table 4 and Table 5: Setup 1. Initialize modems using LAT latency path at a chosen Net Data Rate consistent with the results of TC2c, and selected XBM bitmap mode, and selected XFT transmission mode, 2. Verify BER <= 1e-7, 3. Adjust the noise by 1 db, 4. Repeat steps 2 and 3 until the maximum noise level has been reached where BER <= 1e-7 and CLR <= 4e-6 for a sufficient long period (Table 1), 5. Disconnect. Success Criteria BER <= 1e-7 and CLR <= 4e-6 for a sufficiently long period (Table 1). Note: Refer to Annex A for further information on BER and CLR. Results Note: To guarantee proper operation at the envisaged quality, BER (shall be < 1e-7) shall be observed over the time period given in Table 1. During the interim process of finding the limit, the monitored time period can be reduced, but shall not be less than 10 % of the period given in Table 1. At the systems limit (highest achieved capacity) it shall be proven over the period given in Table 1 that the performance requirement is met. Table of maximum noise level vs. loop/noise type described in Annex D of this document for the same framing mode, Trellis option and Net Data Rate as TC2c. 6.6 Margin with external crosstalk and noise Margin with external crosstalk and noise for G Annex C & H Table 4: Noise type used for Test cases TC1c-TC5c Test case Noise type TC1c White noise (agwn) TC2c 24 TCM-ISDN DSL + awgn TC3c 24 ADSL (G Annex A with non-overlapped spectrum) TC5c + awgn (Note-1) Parameter -140 dbm/hz NPSL= khz FPSL= khz & 1 km 24 SSDSL (G Annex H) + awgn (Note-1) (Note-2) TC4c White noise (agwn) -140 dbm/hz Note-1: (1) When testing G.992.1/G Annex C, SSDSL disturber is applied, and ADSL disturber is not applied, (2) When testing G Annex H, ADSL disturber is applied, and SSDSL disturber is not applied. Note-2: The downstream and upstream transmit signal PSD of SSDSL is identical to the downstream transmit signal PSD of G Annex A with overlapped spectrum. The downstream and upstream burst-mode signal transmit timing of SSDSL is identical to G Annex C FBM. The downstream/upstream alternate NEXT/FEXT injection timing of SSDSL disturbers is identical to the case of TCM-ISDN DSL disturbers. WT-051v4-3/14/

21 Table 5: Loop type used for Test cases TC1c-TC5c Test case Test loop Parameter TC1c 0.4 mm paper insulated loop 250 m *n (n=0,1,...) 0.4 mm paper insulated loop (Loop TCM #5 defined in G.996.1) TC2c TC3c TC5c (Note-1) TC4c 0.4 mm paper insulated loop (2.19 km) mm polyethylene insulated loop (1.5 km) with 0.65 mm polyethylene insulated taps (Total loop length 3.69 km) (Loop TCM #2 defined in G.996.1) 0.4 mm paper insulated loop (X km) mm polyethylene insulated loop (1.5 km) with 0.65 mm polyethylene insulated taps (Loop TCM #2 defined in G.996.1) khz (2.07 km) khz (2.94 km) khz (3.97 km) Referred as Test Loop 1 in Annex D (Note-2) khz (3.69 km) (Note-2) a. BT1=0m & BT2=0m b. BT1=300m & BT2=300m Referred as Test Loop 2 in Annex D (Note-3) khz (X= 1.32 km) khz (X= 2.19 km) khz (X= 3.23 km) (Note-2) a. BT1= 0 m & BT2= 0 m b. BT1= 100 m & BT2= 0 m c. BT1= 300 m & BT2= 0 m d. BT1= 500 m & BT2= 0 m (Note-3) Note-1: TC3c examines whether a system operates by an achieved SNR margin greater than or equal to a setup margin MRG. When TC3c has failed, TC5c examines an achieved SNR margin (less than a setup margin MRG ). Note-2: Test loops shall be set up by the loss values in db, and the length values in km are for information. Note-3: BT1; Bridged tap connected to 0.65 mm loop at CO side, BT2; Bridged tap connected to 0.65 mm loop at CPE side. The injection FEXT noise shall be simulated on condition of detaching the BTs. WT-051v4-3/14/

22 6.7 Transmit Power Spectral Density Test Case Number TC6 Test Case Name Transmit_psd Test Purpose Determine the maximum transmit power spectral density of the system under test Input Parameters? Test Procedure and Setup The preferred test method would involve the use of a special test mode which enables the system to work single ended and still transmit a representative line signal at maximum power. Contributions on the exact test methodology based on access to this test mode are invited. If this special test mode is not available then measurement will need to be carried out whilst the system is fully operational. BT has proposed a test methodology in contribution DSLForum which addresses this. However, during the Portland meeting, it was acknowledged that there were some issues with this method and therefore, further contributions are requested on suitable test methods for the next meeting in Vancouver. Success Criteria Results Compliance to ITU G.992.1, ITU G or ANSI T PSD mask limits. Transmit PSD plots vs relevant standard masks. Editorial Note: A further request is made for contributions to define single ended PSD measurements and comments on the inclusion of contribution as an alternative measurement method. 7. References [ANSI] [GDMT] [GLITE] [GTEST] [TR-023] Committee T1 Telecommunications T International Telecommunication Union, Telecom standardization sector ITU-T G International Telecommunication Union, Telecom standardization sector ITU-T G International Telecommunication Union, Telecom standardization sector ITU-T G Digital Subscriber Line Forum TR-023: Overview of ADSL Testing WT-051v4-3/14/

23 ANNEX A : Bit Error Ratio testing of ATM based ADSL systems A.1 General description of BER testing Performance measurements are usually backed by Bit Error Ratio (BER) measurements. These tests are done end to end using external Bit Error Ratio test (BERT) equipment. This however, has some drawbacks: 1. The BER is measured end to end, requiring the full system to be present and active. 2. The BER equipment is typically complex. 3. The BER for packet based systems is not measured in the same way as BER for bitpipe based systems. A.2 Description The ANSI T1.413 standard requires a minimum Bit Error Ratio (BER) when operating ADSL systems. It specifies that the BER of the ADSL system be lower than or equal to 10e-7, assuming the STM system as described in [ANSI]. No BER or CLR (cell loss ratio) is given for ATM systems, but can be inferred as follows. Given a uniform distribution of errors, the probability that a bit error occurs in the ATM header is about 1 to 10. The requested CLR can be calculated as: ( 53 8) CLR = BER Or 5 53 CLR = 40 BER Note: For higher bit error ratios or when error bursts occur, CLR is not linearly related to BER. CLR will be significantly smaller than 40 x BER when multiple errors occur in a single dropped cell. Typically this BER is measured by an external BERT set, consisting of a traffic generator at the transmitter side and a traffic analyzer at the receiver side, both of which are complex test tools. The ADSL system is considered as a black box and must be completely configured and operational. It must also have all the necessary external interfaces to connect to the BERT. In particular, for DSLAM equipment, this means that either the network cards/devices must be present and operational or that a suitable test interface must be provided. A typical setup is shown in Figure A - 1. (8/30/00 Living List Issue 5.7 completed) WT-051v4-3/14/

24 To PSTN OC3-c or STM1 LPF ATU-C STP-5 x ft Hi-Z coupling cct Noise Generator Line simulator Hi-Z coupling cct STP-5 x ft Noise Generator LPF ATU-R STP-5 x ft To Phone see Note ATM DSLAM User interface ATM, Ethernet,... BERT TX-Down RX-UP BERT TX-Up RX-Down Figure A - 1: Typical ATM based BER measurement test setup Note: For testing of equipment according to ITU-T G (G.Lite) the CPE-side LPF is not used. Note that the use of an internal Bit Error Ratio test mechanism, as described in ANNEX B, removes the need for this BERT equipment and the need to have all the external interfaces fully active and configured. An internal test mechanism will also measure the BER of the physical ADSL link only rather than include possible additional BER contributions created in the network connection or the user interface. A.3 Test Requirements A.3.1 External BER test requirements The following requirements apply to ATM based BER measurement systems. The BERT must perform the measurements both in the upstream and in the downstream direction and these measurements must be made independently. The duration of the measurements shall comply with For testing [GDMT Annex C], [GDMT Annex H] and [GLITE Annex C], it is required to synchronize with TTR (TCM-ISDN Timing Reference) as described in [GTEST] and specified in Annex D of this document in detail, where TTR is provided by DCS (Digital Clock Supply). Editorial Note: Following the contribution from the TIA of PN4254, are the following minimum period times excessive? Table 1. A Traffic generator The ATM based BERTs must send traffic in AAL1 format with the same fixed payload per ATM cell. The bytes within the payload should not be identical - use, for example, the same PRBS sequence in each cell. A Traffic analyzer Three types of BER measurements are taken: WT-051v4-3/14/

25 Living List Issue: 5.2. Clarify inconsistency of AAL0/AAL1 in definition of BER-application [Annex A, sect. A.3.1.2, part 3)] (28/C6) [3/8/00 update: incomplete] [5/17/00 update: clarification needed about the definition of CLR] 1) BER-bitpipe The BER measured over an ADSL system considers that system to be a bit-pipe (as does [ANSI]), and not a cell-pipe (ATM cells). Thus a consequence of measuring BER-bitpipe over an ATM system is that discarded ATM cells, and bit errors in the discarded ATM cells, are not taken into account. The 47 byte payloads in the AAL1 cells are checked against the inserted content (which, because it is the same for all cells, renders the BER transparent to cell losses). Each wrong bit is counted and the total is divided by the number of checked bits. BER-bitpipe = measured seconds measured seconds ( Errored-bits) ( 47 8 Rx-cells) 2) CLR: Cell Loss Ratio When a bit error occurs in the header of an ATM cell, the complete cell is discarded. The traffic analyzer checks the sequence number in the first byte of the AAL1 payload, and counts the number of cells which are missing. The CLR is equal to this number divided by the total number of received cells. CLR = measured seconds measured seconds ( Lost-cells) ( Rx-cells) Editorial Note: Usually a Cell Loss Ratio is defined as the number of lost-cells devided by the number of sent-cells which would lead in any case to a ratio 1. The formula given in this section doesn t use the the number of sent cells but the number of received cells (Rx-cells). Clarification required. 3) BER-application This is the BER measured over the ADSL system, but as seen from the application, assuming AAL1. This means that when an ATM cell is lost, its whole payload of 47x8 bits is counted in the BER as 47x8 bits in error. BER-application BER-bitpipe Rx-bits CLR Rx-cells + ( ) 47 8 ( ) measured seconds measured seconds ( Rx-bits) measured seconds The BER-application is thus approximately equal to the BER-bitpipe plus the CLR. BER-application BER-bitpipe CLR + Editorial Note: Validity of this statement is dependent on the clarification required in section A.3.1.2, part 2. WT-051v4-3/14/

26 ANNEX B : A method to perform ATM based Bit Error Ratio tests without external BER tools. In ANNEX A, a generic description of BER testing is given. This section describes an internal BER measurement tool that performs a similar function. This internal tool is able to measure: 1. BER-bitpipe 2. Cell Loss Ratio 3. BER-application The use of an internal bit error ratio test mechanism removes the need for BERT equipment and the need for having all the external interfaces fully active and configured. Such use will also measure the BER of the physical ADSL link only rather than include the possible additional BER contributions created in the network connection or the user interface. B.1 Requirements of an internal BER tool An internal BER tool must be able to make the same measurements as the external BER tool, namely the BERbitpipe, the CLR and the BER-application. Some dedicated hardware counters are needed to store and count BER results, and some software to start/stop the BER test, process the results and to pass the results to an external PC or terminal. The measurements are based on idle cells, which means that the built-in functionality is placed at the ATM-TC layer. The measurement duration times given in For testing [GDMT Annex C], [GDMT Annex H] and [GLITE Annex C], it is required to synchronize with TTR (TCM-ISDN Timing Reference) as described in [GTEST] and specified in Annex D of this document in detail, where TTR is provided by DCS (Digital Clock Supply). Editorial Note: Following the contribution from the TIA of PN4254, are the following minimum period times excessive? Table 1 should be scaled to reflect the relative percentages of idle cells to user traffic in the payload. Note: As idle cells are used for the internal BER testing, the measuring time is dependent on the percentage of idle cells to user traffic cells. This ratio is dependent on the systems configuration as well as the actual user traffic which can be bursty in nature and vary significantly over the measuring period. All these circumstances have to be taken carefully into account when scaling the measuring times given in Table 1. B.1.1 Traffic Generator The ATM cells suited for BER measurements are the idle or unassigned cells. The BER generator is thus best placed at the idle cell insertion circuit before HEC generation and before cell payload scrambling. Figure B - 1 shows the position of the generator in the ATM-TC layer. The 48 byte payload of each idle cell shall be the same fixed pattern, known at the receiver. The traffic generator can be the same as the idle cell generator. When no user traffic is present, all payload cells will be idle cells and measurement duration times with the internal BER tool will match those with an external BERT ( For testing [GDMT Annex C], [GDMT Annex H] and [GLITE Annex C], it is required to synchronize with TTR (TCM-ISDN Timing Reference) as described in [GTEST] and specified in Annex D of this document in detail, where TTR is provided by DCS (Digital Clock Supply). Editorial Note: Following the contribution from the TIA of PN4254, are the following minimum period times excessive? Table 1). WT-051v4-3/14/

27 B.1.2 Traffic Analyzer (8/30/00 update: Living List Issue 5.4 completed) (8/30/00 update: Living List 5.6 completed) The receiver shall check the payload of the idle cells for bit errors, and the counts of errored bits and idle cells shall be on a per-second basis. The average BER shall be taken over the appropriate measurement time (scaled from Table 1 to reflect the dependence on the transmission of idle cells). When the traffic generator is enabled the BER receiver can be started or stopped at any time. No communication with the transmitter is needed. Note: As idle cells are used for the internal BER testing, the measuring time is dependent on the percentage of idle cells to user traffic cells. This ratio is dependent on the systems configuration as well as the actual user traffic which can be bursty in nature and vary significantly over the measuring period. All these circumstances have to be taken carefully into account when scaling the measuring time at hand of Table 1. 1) BER-bitpipe The BER-bitpipe shall only be measured on correctly received idle cells over the total measurement time. This will eliminate bit errors due to cell losses. The BER-bitpipe is expressed as a BER on a per second basis (i.e., the average BER is calculated over the total measurement time using a one second update rate). 2) CLR: Cell Loss Ratio All total cell counts and lost cell counts are performed over the total measurement time. The total cell count is done before executing the HEC check. Lost cells are counted when an incorrect HEC is seen. Incorrect HECs are never corrected. 3) BER-application The BER-application is approximately given by the sum of the BER-bitpipe and the CLR. Figure B - 1 shows the position of the BER tool in the ATM TC-Layer: WT-051v4-3/14/